Date: Sun, 30 Aug 2009 17:53:23 +0200 From: Daan Vreeken <Daan@vehosting.nl> To: freebsd-ppc@freebsd.org Cc: Michal Mazur <arg@semihalf.com>, Andrew Turner <andrew@fubar.geek.nz>, Hans Petter Selasky <hselasky@c2i.net> Subject: Re: FreeBSD/powerpc on MPC5200 Message-ID: <200908301753.24288.Daan@vehosting.nl> In-Reply-To: <200908301614.58264.Daan@vehosting.nl> References: <35914876-0CFF-427B-8F80-B1BEEA5A7A18@semihalf.com> <200908301549.18407.Daan@vehosting.nl> <200908301614.58264.Daan@vehosting.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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@semihalf.com> wrote: > > > > > >> On 2009-05-11, at 15:15, Peter Czanik wrote: > > > > > >>> Rafal Jaworowski =EDrta: > > > > > >>>> 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.t= ar > > > >.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 raci= ng > > > > through memory following corrupt/invalid 'next' pointers? > > > > > > Maybe busdma is not computing correct physical addresses for the kern= el > > > 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=3D0x00000010 control=3D0x00000093 > > command=3D0x00000002 > > ohci_dumpregs:603: intrstat=3D0x00000040 intre=3D0x8000005a intrd=3D0x= 8000005a > > ohci_dumpregs:607: hcca=3D0x01c12a00 percur=3D0x48000060 ctrlhd=3D0x01= c20880 > > ohci_dumpregs:611: ctrlcur=3D0x00000000 bulkhd=3D0x01c20800 > > bulkcur=3D0x00000000 ohci_dumpregs:615: done=3D0x00000000 fmival=3D0xa7= 782edf > > fmrem=3D0x800025e7 ohci_dumpregs:619: fmnum=3D0x000000e5 perst=3D0x0000= 2a2f > > lsthrs=3D0x00000628 ohci_dumpregs:623: desca=3D0x02001202 descb=3D0x000= 00000 > > stat=3D0x00000000 ohci_dumpregs:626: port1=3D0x00100303 port2=3D0x00010= 101 > > ohci_dumpregs:632: HCCA: frame_number=3D0x35fe0000 done_head=3D0x00000= 000 > > > > 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 s= ome=20 time ago by adding a member to struct ohci_softc called 'sc_endian'. Byte=20 swapping is done depending on it's value (which is set in attach routines=20 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=20 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? =2D-=20 Daan Vreeken VEHosting http://VEHosting.nl tel: +31-(0)40-7113050 / +31-(0)6-46210825 KvK nr: 17174380
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200908301753.24288.Daan>