CSUD - Chadderz's Simple USB Driver (Source)

[Chadderz]

Hi everyone. I've just uploaded the source code for CSUD the USB driver from my Baking Pi tutorials at http://www.cl.cam.ac.uk/freshers/raspbe ... orials/os/. You can find it at GitHub here: https://github.com/Chadderz121/csud.

It's a fully self contained USB stack designed for the Pi, featuring a Hub, HID and Keyboard driver. At the moment I only have polling, and control transfers implemented, which is a poor subset of the actual USB standard, but it's enough to get reasonable support for a simple keyboard driver. Note: The header files have changed since the library in the tutorials, so it won't be directly compatible. It compiles to a static library that you can then link into your OSs.

I'll try to improve it in time, particularly with the aim of improving keyboard support, and I would be interested to collaborate with anyone who can help.

[DexOS]

Thanks Chadderz, nice work, i got your original driver working in my OS, i will give you credits etc, when i release it.

[dwelch67]

I prefer polling solutions anyway...going to try your code, let you know if there are problems.

Any luck or insight into how to talk to the on board ethernet yet? That is connected to usb yes?

Keep up the good work,
David

[Chadderz]

I haven't looked at ethernet, the documentation on the datasheet doesn't seem at all sufficient, but perhaps the Linux driver would be. I think you would need more than just control transfers to make it work though! You're right though, the device tree of the Pi on my driver is always:

Code: Select all

1 USB Virtual Root Hub (480 Mb/s)
|
+-2 USB 2.0 Hub (480 Mb/s, Not removable)
  |
  +-3 SMSC LAN9512 (480 Mb/s, Not removable)
  |
  +-0 No Device (Removable)
  |
  +-0 No Device (Removable)

[asb]

I have wondered how long it might take for someone to build upon CSUD enough to hook up the lwIP stack to the smsc9512 ethernet. That would be just a little bit cool.

[piglet]

I wish I knew enough to have a clue what you just said!

[dwelch67]

I didnt say I was going to use lwip, maybe after it is hooked up and moving packets someone else may want to put lwip on top of that..

[gertk]

I am trying to compile libcsud but after compiling and using it in my 'Bare Metal' code I get this (in DEBUG mode)

HCD: Incorrectly compiled driver. HostGlobalRegs: 0x400 (0x400), CoreGlobalRegs: 0x401 (0x400), PowerReg: 0x7ffff14 (0x4).
USBD: Abort, HCD failed to initialise.

using
arm-none-eabi-gcc (Sourcery G++ Lite 2008q3-66) 4.3.2

on Ubuntu 10.0.4 LTS

compiled csud with:

make driver CONFIG=DEBUG TYPE=LOWLEVEL TARGET=RPI GNU=arm-none-eabi-

It looks like the structs have a different size than expected.. Any ideas ?

P.S. I also seem to have conflicts with my timer init and libcsud

[Chadderz]

Hi,

Yes indeed looks to be the struct sizes (also have I messed up a format there, 0x7ffff14 seems a tad excessive!). I only ever complied it using the toolchain in the tutorials under Windows, but things like struct packing and size are compiler specific, so that's the issue. If you figure out what's causing it let me know, it'd be nice to have a more universal version if possible. If you just want a solution; compile from Windows.

[gertk]

Hmm, no Windows here except for the window panes here

But will investigate further..

[gertk]

You use type 'bool' in types.h but when I use in my code a type 'bool' I get a compiler error that 'bool' is undeclared, could this be the culprit ?

[Chadderz]

Shouldn't be, bool is defined in types.h so it becomes valid in the rest of the code.

[gertk]

Hmm.. totally stumped.. Is the compiler messing up or what...

I added a completely similar structure definition in designware20.h:

Code: Select all

extern volatile struct PowerReg {
	volatile bool StopPClock : 1; // @0
	volatile bool GateHClock : 1; // @1
	volatile bool PowerClamp : 1; // @2
	volatile bool PowerDownModules : 1; // @3
	volatile bool PhySuspended : 1; // @4
	volatile bool EnableSleepClockGating : 1; // @5
	volatile bool PhySleeping : 1; // @6
	volatile bool DeepSleep : 1; // @7
	volatile unsigned _reserved8_31 : 24; // @8
} *PowerPhysical, *Power;

extern volatile struct MyStruct {
	volatile bool StopPClock : 1; // @0
	volatile bool GateHClock : 1; // @1
	volatile bool PowerClamp : 1; // @2
	volatile bool PowerDownModules : 1; // @3
	volatile bool PhySuspended : 1; // @4
	volatile bool EnableSleepClockGating : 1; // @5
	volatile bool PhySleeping : 1; // @6
	volatile bool DeepSleep : 1; // @7
	volatile unsigned _mypadding : 24;
} *MyStruct1, *MyStruct2;

And if I run with debug on and an added line to print the sizeof my structure this is what I get:

myHCD: size of MyStruct: 0x4

HCD: Incorrectly compiled driver. HostGlobalRegs: 0x400 (0x400),CoreGlobalRegs: 0x401 (0x400), PowerReg: 0x7ffff14 (0x4).

[Chadderz]

No, the PowerReg struct (probably) isn't the problem, if you look at line 588 of designware20.c it reads

Code: Select all

			sizeof(struct HostGlobalRegs), sizeof(struct CoreGlobalRegs));

but should read

Code: Select all

			sizeof(struct HostGlobalRegs), sizeof(struct CoreGlobalRegs), sizeof(struct PowerReg));

The problem is the CoreGlobalRegs structure.

[gertk]

Totally overlooked the missing argument...

[gertk]

Tried shorting the reserved140_400 area by 1 byte and then it gives me an out of memory error (heap),
then tried shortening the reserved58_80 area by one byte and it gave me:

CSUD: USB driver version 0.1
CSUD: HID driver version 0.1
CSUD: Hub driver version 0.1
CSUD: Keyboard driver version 0.1
CSUD: Mouse driver version 0.1
HCD: Reserving memory.
Platform: First memory allocation, reserving 32768B of heap, 256 entries.
Platform: malloc(0x400) = 0x40158. (1024/32768)
Platform: malloc(0x400) = 0x40558. (2048/32768)
Platform: malloc(0x8) = 0x40958. (2056/32768)
HCD: Hardware: Platform: free(0x40158) (1032/32768)
Platform: free(0x40558) (8/32768)
Platform: free(0x40958) (0/32768)
USBD: Abort, HCD failed to initialize

Getting close but still no clue where the extra byte in the CoreGlobalRegs is coming from... Must be some padding trick the compiler is doing.. (BTW: I increased heap size to 32k to see if it would continue on the first error)

[Chadderz]

Whenever I have alignment issues, the easiest way to find them is a binary chop; delete exactly half of the data structure according to the correct size (given in the comments), and see if the extra byte is before or after what you deleted. Repeat as necessary. Just removing random bytes from the structure will be very unpredicatable, as it is used to communicate with hardware, and so the order and sizing must be exact matches of the comments.

[gertk]

Yes I understand that, already tried the chopping method. But if I remove some part of the struct which is later referenced, the library will not compile. Other than compiling and running the created library on the Pi I see no way to determine the size of the struct.
Also tried to LOGF the size of some of the inner structs but the compiler complains that it cannot determine the size of incomplete structs..

[Chadderz]

To play with the struct, simply duplicate it and alter the duplicated version. One way to test if the size was correct without going to the Pi is to include an if statement round some substantial block of code which checks it, e.g.:

Code: Select all

Result HcdInitialise() {	
  volatile Result result;
  if (sizeof(struct HostGlobalRegs) == 0x400) {
    LOG_DEBUG("HCD: Reserving memory.\n");
    CorePhysical = MemoryReserve(sizeof(struct CoreGlobalRegs), HCD_DESIGNWARE_BASE);
    Core = MemoryAllocate(sizeof(struct CoreGlobalRegs));
    // ...
    return OK;
  } else return ErrorCompiler;
deallocate:
  if (Core != NULL) MemoryDeallocate((void *)Core);
  if (Host != NULL) MemoryDeallocate((void *)Host);
  if (Power != NULL) MemoryDeallocate((void *)Power);
  return result;
}

Then by using a dissassembler, e.g:

Code: Select all

arm-none-eabi-objdump -d -j .text.HcdInitialise build/designware20.c.o

It should be pretty obvious if the condition evaluated to true or false because the assembly code will be significantly shorter or longer depending. I've typed that from memory, so apologies for mistakes.

[gertk]

This seems to be the problemzone, one way or another it expands this to 1 byte too many..

Code: Select all

	volatile struct CoreReset {
		volatile bool CoreSoft : 1; // @0
		volatile bool HclkSoft : 1; // @1
		volatile bool HostFrameCounter : 1; // @2
		volatile bool InTokenQueueFlush : 1; // @3
		volatile bool ReceiveFifoFlush : 1; // @4
		volatile bool TransmitFifoFlush : 1; // @5
		volatile enum CoreFifoFlush {
			FlushNonPeriodic = 0,
			FlushPeriodic1 = 1,
			FlushPeriodic2 = 2,
			FlushPeriodic3 = 3,
			FlushPeriodic4 = 4,
			FlushPeriodic5 = 5,
			FlushPeriodic6 = 6,
			FlushPeriodic7 = 7,
			FlushPeriodic8 = 8,
			FlushPeriodic9 = 9,
			FlushPeriodic10 = 10,
			FlushPeriodic11 = 11,
			FlushPeriodic12 = 12,
			FlushPeriodic13 = 13,
			FlushPeriodic14 = 14,
			FlushPeriodic15 = 15,
			FlushAll = 16,
		} TransmitFifoFlushNumber : 5; // @6
		volatile unsigned _reserved11_29 : 19; // @11
		volatile bool DmaRequestSignal : 1; // @30
		volatile bool AhbMasterIdle : 1; // @31
	} __attribute__ ((__packed__)) Reset;  // +0x10

Struct length is 0x15 instead of 0x14

[Chadderz]

Hmm.. the enum could be causing problems, you could try replacing it with an int.

[gertk]

I ditched the old compiler toolchain I used and git-cloned the latest.
Now it compiles correctly but.....

In file included from include/hcd/hcd.h:67:0,
from source/usbd/usbd.c:12:
include/hcd/dwc/designware20.h:296:2: note: offset of packed bit-field 'TransmitFifoFlushNumber' has changed in GCC 4.4

Sizes are correct now, still when run it gives:

CSUD: USB driver version 0.1
CSUD: HID driver version 0.1
CSUD: Hub driver version 0.1
CSUD: Keyboard driver version 0.1
CSUD: Mouse driver version 0.1
HCD: Reserving memory.
Platform: First memory allocation, reserving 32768B of heap, 256 entries.
Platform: Out of memory! We should've had more heap space in platform.c.
Platform: Out of memory! We should've had more heap space in platform.c.
Platform: Out of memory! We should've had more heap space in platform.c.
HCD: Hardware: OT2.80a (BCM2708a).
HCD: Internal DMA mode.
HCD: Hardware configuration: 00000000 228ddd50 0ff000e8 1ff00020
HCD: Host configuration: 00010000
HCD: Disabling interrupts.
HCD: Powering USB on.
HCD: Load completed.
HCD: Start core.
HCD: HCD uninitialised. Cannot be started.
USBD: Abort, HCD failed to USB keyboard initialized

Using:
arm-none-eabi-gcc (32-bit ARM EABI Toolchain JBS-2012.03-56-v2011.09-69-18-gd53ce5a) 4.6.3

[gertk]

update:

compiled as 'STANDALONE' it starts and I have a USB keyboard... Yay!

[Chadderz]

Great, glad you've got it. Pity we couldn't get another compiler to work, but you can't have everything in life!

[gertk]

Yes, but at least I have a fresh new toolchain now
(when watching this toolchain compile I am still amazed how much stuff is going through there..)