Chadderz CSUD USB Driver

[mark_3094]

I'm trying to test out the USB driver in my simple OS.

So far, my OS can print to the screen but that's about it. However, as I understand it there should be no special OS requirements as the driver can be compiled as stand alone, so nothing additional is required from the OS.

I downloaded the driver source, and compiled like this:

Code: Select all

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

In main.c I have added this:

Code: Select all

extern UsbInitialise();
int main (void) {
	kprintf ("Test\n");
	UsbInitialise();
	kprintf ("USB\n");
}

The makefile I use is something like this:

Code: Select all

CC=arm-none-eabi-gcc
AS=arm-none-eabi-as
CFLAGS=-nostartfiles -nodefaultlibs -fno-builtin -Wall -T linker.ld $(HEADERS)
objects=$(addprefix $(OBJDIR)/,main.o gpiopins.o framebuffer.o drawchar.o putchar.o intconv.o strlen.o kprintf.o kputchar.o)
kernel.img: $(objects)
	arm-none-eabi-as -o crt0.o crt0.s
	$(CC) -o kernel.img $(objects) libcsud.a $(CFLAGS)

When I compile my OS, I do get error like this, but I don't think they're much to worry about:

Code: Select all

warning: libcsud.a(armv6.c.o) uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail

When I start up, I don't get anything on the screen, except the 'Test' and 'USB' messages that I wrote there.

Is there something I'm missing?


Thank you

[jamesh]

Try compiling your code with fshort-wchar, which should be safe since you are using your own OS. gcc defaults to 4 byte wchar_t which is the Linux standard.

[mark_3094]

Try compiling your code with fshort-wchar

Thanks, this has solved the warnings. However I still have the issue where the USB driver doesn't seem to initialise.

I have tried this:

Code: Select all

UsbInitialise();
for (;;) {
	UsbCheckForChange();
	kprintf("%u\n", KeyboardCount());
};

I thought that maybe the driver was working, but it wasn't printing to the screen, so I added the loop to return the number of connected keyboards, however it remains at zero. I have tried starting with a keyboard connected, and I have tried connecting the keyboard later, but the count stays at zero.

[jamesh]

I'm not familiar with the driver - can you turn on any logging in it to see where it's failing internally?

[mark_3094]

Looks like a function called 'LogPrint' is used to print debugging information to the screen.
Problem is that I can't find this function anywhere in the source.

Perhaps I need to implement this myself? It is declared like this:

Code: Select all

void LogPrint(char* message, u32 messageLength)

So, I guess I could implement it by printing a 'messageLength' number of characters from the 'message' pointer.

Has anyone else done this? Am I on the right track?
I'll have a go at this tomorrow. It's getting late here.

[DexOS]

The way i do it is to compile the usb driver to run at a certain offset address eg:
.init 0x00008010
Than add the compiled .bin file in my main OS code to be at that address, then use the kernel.map out put to get the address of the function eg:
0x0000f4a0 UsbInitialise
0x000140e4 KeyboardUpdate
0x00014198 KeyboardGetChar
Then you can call the above function by call those address.
This works fine, i am coding in asm (fasmarm).

[mark_3094]

I found out that the reason I wasn't getting any debug messages is that I had compliled the library as 'standalone', which disables logging.

I manually enabled logging, and now I can get some useful information. For some reason it is saying that the device is not ready:

Code: Select all

USBD: Allocating new device, address 0x2.
HUB: USB Root Hub.Port1 Status 503:12
USBD: Scanning 2. 480 Mb/s.
USBD: Verifying New Device (Not Ready) is still connected.
USBD: Yes, New Device (Not Ready) is still connected.
USBD: Failed to get descriptor 0x1:0x0 for device New Device (Not Ready). Result 0xfffffffc.
USBD: Failed to read device descriptor for 2.
HUB: Could not connect to new device in USB Root Hub.Port1. Disabling.
USBD: Deallocating device 2: New Device (Not Ready).
Platform: free(0x1e540) (4288/16384)

This seems to happen if the keyboard is connected or not.

[mark_3094]

I can get this a step further now. However, there are still problems.

If I compile the driver with 'FINAL', I get this:

Code: Select all

HCD: Stall error in transfer
HCD: Request to New Device (Not Ready) failed.
...
HCD: Could not send DATA to New Device (Not Ready).

If I compile with 'DEBUG', it seems to work, however the characters print funny (pixels missing, etc) and after about 30s, it starts drawing lines on screen. It seems that something has gone wrong with the framebuffer.

Has anyone seen this before?

Could it be that I need to allocate memory to the framebuffer with 'MemoryAllocate()'? Can MemoryAllocate allocate memory to a pointer that already has an address assigned?

[mark_3094]

I think I have it sorted. It was difficult to make it stable, but there is one thing that seems to have helped (pending more thorough testing of course).

I have found that disabling processor caching has helped. To do this, I changed the addresses that are used for the mailbox and USB registers.

That is, use these values:

• USB Registers = 0xE0980000
  Mailbox Read = 0xE000B880
  Mailbox Status = 0xE000B898
  Mailbox Write = 0xE000B8A0

There is more information about caching on page 5 of the BCM2835 manual.
Hopefully this proves to be permanant and not just the placebo effect

[grilotc]

I guess I'm going to revive this thread...

I'm having the same issues, and the debug prints from CSUD are very similar to the ones previously posted.
Nevertheless, the solution of changing the mailbox and USB pointers did not work.

Does anyone have any clue how to solve this issue?