FreeBSD/powerpc on MPC5200

Sun Aug 30 15:53:23 UTC 2009

Hi Hans Petter,

On Sunday 30 August 2009 16:14:57 Daan Vreeken wrote:
> On Sunday 30 August 2009 15:49:17 Daan Vreeken wrote:
> > On Friday 28 August 2009 21:46:27 Hans Petter Selasky wrote:
> > > On Friday 28 August 2009 21:27:28 Daan Vreeken wrote:
> > > > Hi Rafal (and the list),
> > > >
> > > > On Sunday 24 May 2009 21:15:44 Rafal Jaworowski wrote:
> > > > > On 2009-05-23, at 07:21, Andrew Turner wrote:
> > > > > > On Fri, 22 May 2009 12:21:01 +0200
> > > > > >
> > > > > > Rafal Jaworowski <raj at semihalf.com> wrote:
> > > > > >> On 2009-05-11, at 15:15, Peter Czanik wrote:
> > > > > >>> Rafal Jaworowski írta:
> > > > > >>>> I'd like to let people know that FreeBSD/powerpc is now able
> > > > > >>>> to boot into single user on the Freescale MPC5200
> > > > > >>>> system-on-chip (EFIKA board). The environment is very
> > > > > >>>> simplistic: RAM disk based root fs, as
> > > > > >>>> there's no peripherals drivers besides serial console and the
> > > > > >>>> built- in
> > > > > >>>> PIC. See this log:
> > > > > >>>> http://people.freebsd.org/~raj/logs/efika.log
> > > > > >>>
> > > > > >>> Wow, great news! Two questions:
> > > > > >>> - are there any plans to support additional devices?
> > > > > >>
> > > > > >> We don't have immediate plans for other devices drivers, but
> > > > > >> this basic support will be merged into SVN, and it would be
> > > > > >> greatly welcome to see people help with remaining items.
> > > > > >
> > > > > > Is there a patch available? I would like to get back to working
> > > > > > on the EFIKA.
> > > > >
> > > > > Preliminary diff against 2009.04.06 HEAD is here:
> > > > > http://people.freebsd.org/~raj/patches/powerpc/efika.diff
> > > > >
> > > > > Comments or questions welcome. Some bits need to be streamlined so
> > > > > that all AIM/OF variations work together, and the code has to be
> > > > > rebased against up-to-date HEAD.
> > > >
> > > > I have downloaded your diff and succesfully patched it to -HEAD
> > > > (checked out on 2009-08-25).
> > > > Right now I'm looking into getting the USB controller working. (That
> > > > would allow me to use network & disks all in one go.)
> > > >
> > > > I have written the OHCI attachment code (inspired by a mix of
> > > > Warner's atmel version, mpc5xxx/ic.c and uart_dev_psc.c) and gotten
> > > > it to succesfully attach to the OHCI controller when booting the
> > > > Efika board. USB is not (yet) working correctly. Near the end of
> > > > ohci_init(), the board seems to halt completely for about 30 seconds
> > > > and after that, the OHCI controller sets the 'unrecoverable error'
> > > > flag.
> > > >
> > > > A complete dmesg dump can be found here :
> > > > http://vehosting.nl/pub_diffs/efika-daan-2009-08-28-ohci_attaching_bu
> > > >t_ fa il ing.txt The kernel that produced this can be downloaded here
> > > > :
> > > > http://vehosting.nl/pub_diffs/efika-daan-2009-08-28-ohci_attaching_bu
> > > >t_ fa il ing.kernel
> > > >
> > > > The files I added/changed to get the attachment of the OHCI
> > > > controller to 'work' can be found here :
> > > > http://vehosting.nl/pub_diffs/efika-daan-2009-08-28_changed_files.tar
> > > >.g z (Warning : Ugly! and full of printf's for now!)
> > > > (I could have missed one, let me know if you can't get it to work.)
> > > >
> > > > The above dmesg shows a number of printf's I've added to ohci.c . My
> > > > mutilated version can be found here :
> > > > http://vehosting.nl/pub_diffs/efika-daan-2009-08-28_ohci.c
> > > >
> > > > As you can see, I printf() the interrupt status register at various
> > > > points during ohci_init(). The 'unrecoverable error' flag gets set
> > > > just a couple of miliseconds after the following command has been
> > > > executed :
> > > >
> > > > 	/* And finally start it! */
> > > > 	OWRITE4(sc, OHCI_CONTROL, ctl);
> > > >
> > > > After that OWRITE4(), the board sits for about 30 seconds and then
> > > > continues. I'm just guessing what's going on here, but could it be
> > > > that (one of?) the endpoint lists isn't properly setup and that the
> > > > OHCI controller keeps the CPU from accessing memory while it's racing
> > > > through memory following corrupt/invalid 'next' pointers?
> > >
> > > Maybe busdma is not computing correct physical addresses for the kernel
> > > virtual memory loaded into DMA.
> >
> > I've looking closely at the logs I generated earlier and this doesn't
> > seem to be the case (I think). The physical address of the HCCA (Host
> > Controller Communications Area) looks the same and the frame_number
> > counter is advancing in this memory area as soon as the controller is
> > enabled. One thing that strikes me is the value of the frame number
> > though :
> >
> > 	ohci_dumpregs:599: ohci_dumpregs: rev=0x00000010 control=0x00000093
> > 		command=0x00000002
> > 	ohci_dumpregs:603: intrstat=0x00000040 intre=0x8000005a intrd=0x8000005a
> > 	ohci_dumpregs:607: hcca=0x01c12a00 percur=0x48000060 ctrlhd=0x01c20880
> > 	ohci_dumpregs:611: ctrlcur=0x00000000 bulkhd=0x01c20800
> > bulkcur=0x00000000 ohci_dumpregs:615: done=0x00000000 fmival=0xa7782edf
> > fmrem=0x800025e7 ohci_dumpregs:619: fmnum=0x000000e5 perst=0x00002a2f
> > lsthrs=0x00000628 ohci_dumpregs:623: desca=0x02001202 descb=0x00000000
> > stat=0x00000000 ohci_dumpregs:626: port1=0x00100303 port2=0x00010101
> > 	ohci_dumpregs:632: HCCA: frame_number=0x35fe0000 done_head=0x00000000
> >
> > The frame number at this particular moment is '0x35fe0000', though the
> > OHCI spec says it should be a 16 bit counter, followed by 16 bits of
> > padding (that should read back as '0').
> >
> > Could it be a big-endian controller, while the USB code expects
> > little-endian?
>
> Yes, that was it. Changing every 'htole32' into 'htobe32' and every
> 'le32toh' into 'be32toh' in  sys/dev/usb/controller/ohci.c gets the USB
> controller to work :

Looking at the NetBSD USB code, I see they have tackled this same problem some 
time ago by adding a member to struct ohci_softc called 'sc_endian'. Byte 
swapping is done depending on it's value (which is set in attach routines 
where needed).
Based on NetBSD's code, I've put together a diff against our current ohci.[ch]
that adds the same functionality. With this change, I can get the OHCI 
controller on the Efika board to work, without breaking other controllers.
The diff can be found here :

	http://vehosting.nl/pub_diffs/ohci-patch-endianness-2009-08-30.diff

Could you consider adding it?

-- 
Daan Vreeken
VEHosting
http://VEHosting.nl
tel: +31-(0)40-7113050 / +31-(0)6-46210825
KvK nr: 17174380