About FreeBSD support one more mini-pc

[Weiß, Jürgen]

> -----Original Message-----
> From: owner-freebsd-arm at freebsd.org [mailto:owner-freebsd-arm at freebsd.org] On Behalf Of
> Ian Lepore
> Sent: Thursday, February 20, 2014 5:04 AM
> To: Tom Everett
> Cc: freebsd-arm at freebsd.org
> Subject: Re: About FreeBSD support one more mini-pc
> 
> On Wed, 2014-02-19 at 16:12 -0700, Ian Lepore wrote:
> > On Wed, 2014-02-19 at 15:12 -0700, Tom Everett wrote:
> > > Hey Ian, i am just about to ask for a pull from my repo with a working
> > > ubldr for wandboard, if you wanted to take a look:
> > >
> > > https://github.com/teverett/crochet-
> freebsd/commit/f61660c4134ef495cb5f7de26c2048fba1e65c8f
> > >
> >
> > My problem isn't with u-boot, it's in the ubldr->kernel handoff.  I'm
> > using u-boot-2014.01 these days and it needs no patching other than to
> > the wandboard config.h to turn on API and USB and a few other handy
> > things.  But when I boot, sometimes it works but more often it goes like
> > this:
> >
> >         U-Boot 2014.01 (Feb 19 2014 - 15:31:16)
> >
> >         CPU:   Freescale i.MX6Q rev1.2 at 792 MHz
> >         Reset cause: POR
> >         Board: Wandboard
> >         DRAM:  2 GiB
> >         MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> >         In:    serial
> >         Out:   serial
> >         Err:   serial
> >         Net:   FEC
> >         Hit any key to stop autoboot:  0
> >         FEC Waiting for PHY auto negotiation to complete... done
> >         BOOTP broadcast 1
> >         *** Unhandled DHCP Option in OFFER/ACK: 69
> >         ...
> >         *** Unhandled DHCP Option in OFFER/ACK: 42
> >         DHCP client bound to address 172.22.42.236
> >         Using FEC device
> >         TFTP from server 172.22.42.240; our IP address is 172.22.42.236
> >         Filename '/wand/boot/ubldr'.
> >         Load address: 0x11000000
> >         Loading: ##############
> >                  10.4 MiB/s
> >         done
> >         Bytes transferred = 195484 (2fb9c hex)
> >         ## Starting application at 0x11000054 ...
> >         Consoles: U-Boot console
> >         Compatible API signature found @8f564028
> >         Number of U-Boot devices: 2
> >
> >         FreeBSD/armv6 U-Boot loader, Revision 1.2
> >         (ilepore at revolution.hippie.lan, Wed Feb 19 15:41:25 MST 2014)
> >         DRAM:    2048MB
> >
> >         Device: disk
> >         -
> >         /boot/kernel/kernel text=0x42f3d0 data=0x31d14+0x2df1c
> syms=[0x4+0x923b0+0x4+0x6e34d]
> >         Hit [Enter] to boot immediately, or any other key for command prompt.
> >         Booting [/boot/kernel/kernel]...
> >         Using DTB compiled into kernel.
> >         Kernel entry at 0x12000100...
> >         Kernel args: (null)
> >         a
> >
> > And it hangs there forever.  The 'a' I just added, that shows me that it
> > gets into the kernel, I print that 'a' from the first few instructions
> > of locore.S.
> 
> Follow up on this... it is because I'm using a newer u-boot that has the
> dcache enabled by default.  If I use the "dcache off" command to disable
> it, it boots perfectly every time.  If I leave the cache enabled it
> fails to boot most of the time with symptoms that pretty much exactly
> match stale data in the caches.
> 
> We enable the MMU in locore.S without invalidating old cache contents
> first, and that appears to be a bad thing.
> 
> -- Ian
> 

Hm, I use an u-boot version from early December, which has already
enabled the L1 Dcache. I did not experience any problems with that
version. On Jan 29th code was committed to the u-boot repository to
enable the L2 cache. I have not checked that version yet.

But without a Dcache invalidate, I had problems to start the second
core.

Juergen

Juergen Weiss      |Universitaet Mainz, Zentrum fuer Datenverarbeitung,
weiss at uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-26407