Hi,
I sort of have USB device functionality working on the SAM9G45. I mention "sort of" because I stripped the Linux driver down to a bare minimum I would say.
It boots a kernel image over USB using tftpboot.
As mentioned before I disabled all DMA and have implemented the driver with bits and pieces from the at91_udc driver (mainly requests part). This mainly because I found the at91_udc driver more easy to understand. Further more I have set up single buffer for the bulk endpoints.
What I got working is that I use tftboot to boot my kernel image, which probably means it does work reasonable enough for initial testing. I tested in a dozen times and it seems to work well. I still need to check some USB traces, but I think my main problem (NYET) was caused by enabling the debugging in the driver I think so I ran into some timing issues. This will be further investigated but I run a bit short on time in my project, so I'm not sure if I can do it at this point (time issue).
Anyway. I'm not sure about one thing since I'm not as familiar with u-boot startup than most people on this list.
I currently have this set : int board_eth_init(bd_t *bis) { int rc = -1;
#if defined(CONFIG_USB_ETHER) && defined(CONFIG_USB_GADGET_ATMEL_USBA) printf("USB probe \n");
rc = usba_udc_probe(&brd); if (!rc) rc = usb_eth_initialize(bis);
return rc; }
Now, someone (I think Albert) mentioned that this would not be preferred, but I have no idea what IS preferred. I would like to keep things as clean as possible, so I hope for some advice on this.
Also, I want to test the driver with DMA enabled, but I'm not sure if I can mange that because of a very tight time schedule (things must be working end of this week basically). I also wonder whether my current implementation wouldn't be preferred for U-boot as it is more compact than the Linux driver. Somehow I like this more for u-boot even though it may be a little slower in it's communication speed as I think for u-boot robustness and small code matter more than speed.
I have still a lot to test I guess, but the initial work is there. I also like to commit my code at some point this week or next week (after that I'm away on business and have no idea when I return - maybe months later). So, even when I think the code can be improved a lot, I want to post the current code already. Is that fine ?
Below is an output of the current status (tested with Fedora core 14 as host)
Best regards, Marcel
U-Boot 2010.12-09833-gb2c475d-dirty (Jan 24 2011 - 20:23:37)
CPU: AT91SAM9G45 Crystal frequency: 12 MHz CPU clock : 400 MHz Master clock : 133.333 MHz dram init DRAM: 128 MiB USB host init FLASH: 1 MiB NAND: 256 MiB In: serial Out: serial Err: serial Net: USB probe USB_ETH_INITIALIZE usb_ether Hit any key to stop autoboot: 0 Sam9g45> tftpboot uImage using atmel_usba_udc, OUT ep2 IN ep1 STATUS ep3 MAC 00:1f:e5:00:1c:7c HOST MAC 0a:fa:63:8b:e8:0a ETH set config high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet Issue start status USB network up! Using usb_ether device TFTP from server 192.168.1.1; our IP address is 192.168.1.2 Filename 'uImage'. Load address: 0x70400000 Loading: ################################################################# ################################################# done Bytes transferred = 1666648 (196e58 hex) Automatic boot of image at addr 0x70400000 ... ## Booting kernel from Legacy Image at 70400000 ... Image Name: Linux-2.6.33-rc4 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1666584 Bytes = 1.6 MiB Load Address: 70008000 Entry Point: 70008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel. Linux version 2.6.33-rc4 (marcel@p4) (gcc version 4.3.2 (GCC) ) #1 Sun Jan 23 15:25:19 CET 2011 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177