Date: Sun, 30 Aug 2009 15:49:17 +0200 From: Daan Vreeken <Daan@vehosting.nl> To: Hans Petter Selasky <hselasky@c2i.net> Cc: Michal Mazur <arg@semihalf.com>, Andrew Turner <andrew@fubar.geek.nz>, freebsd-ppc@freebsd.org Subject: Re: FreeBSD/powerpc on MPC5200 Message-ID: <200908301549.18407.Daan@vehosting.nl> In-Reply-To: <200908282146.28715.hselasky@c2i.net> References: <35914876-0CFF-427B-8F80-B1BEEA5A7A18@semihalf.com> <200908282127.28482.Daan@vehosting.nl> <200908282146.28715.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Hans Petter, 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_but_= 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_but_= 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.gz > > (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=20 be the case (I think). The physical address of the HCCA (Host Controller=20 Communications Area) looks the same and the frame_number counter is advanci= ng=20 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=3D0x8000= 005a ohci_dumpregs:607: hcca=3D0x01c12a00 percur=3D0x48000060 ctrlhd=3D0x01c208= 80 ohci_dumpregs:611: ctrlcur=3D0x00000000 bulkhd=3D0x01c20800 bulkcur=3D0x00= 000000 ohci_dumpregs:615: done=3D0x00000000 fmival=3D0xa7782edf fmrem=3D0x800025e7 ohci_dumpregs:619: fmnum=3D0x000000e5 perst=3D0x00002a2f lsthrs=3D0x000006= 28 ohci_dumpregs:623: desca=3D0x02001202 descb=3D0x00000000 stat=3D0x00000000 ohci_dumpregs:626: port1=3D0x00100303 port2=3D0x00010101 ohci_dumpregs:632: HCCA: frame_number=3D0x35fe0000 done_head=3D0x00000000 The frame number at this particular moment is '0x35fe0000', though the OHCI= =20 spec says it should be a 16 bit counter, followed by 16 bits of padding (th= at=20 should read back as '0'). Could it be a big-endian controller, while the USB code expects little-endi= an? =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?200908301549.18407.Daan>