[U-Boot-Users] reg ISP 1561 integration with u-boot1.1.6

Matthias Fuchs matthias.fuchs at esd-electronics.com
Thu Jan 11 09:50:08 CET 2007

On Wednesday 10 January 2007 23:01, Markus Klotzbücher wrote:
> Hi Matthias,
> Matthias Fuchs <matthias.fuchs at esd-electronics.com> writes:
> > it's working. I modified the testing-USB branch to run against a PCI OHCI 
> > controller (Philips ISP1561) on the APC405 board (PowerPC PPC405GPr). 
> >
> > Enumeration and USB storage is working. I do not dare to say 'working well'.
> >
> > The main changes concern endianess fixes. The former code only supports OHCI 
> > controller with the same endianess as the CPU. The other fix allows a offset 
> IIRC same problem with the 440EP and MPC5200, thats what the extra
> #ifdef in drivers/usb_ohci.c:103 is for.
These are different issues! usb_ohci.c uses readl and writel to access the 
controller's registers from the CPU (e.g. ohci.regs). The original code never
swaps here. But a PCI OHCI controller on a PowerPC needs it. The mXX_swap 
macros are used to swap data fields in structures that are passed to the host 
controller indirectly.
> > to access the system RAM by the busmastering OHCI controller. I called this 
> > constant CFG_PCIRAM_BASE. But the name is a little bit confusion, isn't it?
> >
> > Here are my (first) questions: 
> > 1) What do I have to do in usb_board_stop() and usb_board_init_fail()?
> > My current code can only initialize the OHCI controller once. A 2nd 'usb 
> > start' does not find any devices.
> You might not have to do anything, but maybe you'll need to do some
> board dependant cleanup for example. If not just leave them empty.
I thought that I have to do something here because stopping and restarting 
the usb stuff does not work at the moment on my system. Does it work on other
systems? I do not have any target with onchip USB at the moment 
(...but comming soon :-). Did anyone test the merged code on a 440EP so far?
> > 2) I had to disable the 'return -1' statement for an unfinished urb in 
> > sohci_submit_job(). Why isn't it finished?
> I really don't know, I guess only you can answer this!
This answer helps me a lot. Why is the urb_finished stuff needed? I go better
without :-)
> > Please do not blame me for the board dependent code still in the usb_ohci.c 
> > file. I will move it later.
> Who else shall we blame then ;-) ?
So please blame be. I just though about leaving the generic PCI OHCI code 
in the file. When it has been made fully generic, it is not CPU or even board 
dependant. PCI device identification constants (better classcode) could be 
defined in the board config header and that's it for CONFIG_USB_OHCI_PCI.


More information about the U-Boot mailing list