[U-Boot] Atmel_usba_udc working (sort of)

[Marcel]

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 at 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