Date: Thu, 20 Feb 2014 12:45:14 -0700 From: Ian Lepore <ian@FreeBSD.org> To: =?ISO-8859-1?Q?Wei=DF=2C_J=FCrgen?= <weiss@uni-mainz.de> Cc: "'freebsd-arm@freebsd.org'" <freebsd-arm@FreeBSD.org> Subject: RE: About FreeBSD support one more mini-pc Message-ID: <1392925514.1145.68.camel@revolution.hippie.lan> In-Reply-To: <38db362d34174f70a07c0b9ea39a54c4@e15be-03.zdv.Uni-Mainz.DE> References: <210081392741053@web22h.yandex.ru> <1392835264.1145.33.camel@revolution.hippie.lan> <CAB3ij4CKpp5hQWeKk5icq6dgxKX%2BtiFLho1TYKc%2BnTbufGzzFA@mail.gmail.com> <FD2977C2-7F98-4B48-81D6-87D2B81BEA78@bsdimp.com> <1392842988.1145.50.camel@revolution.hippie.lan> <CAB3ij4CHPjAspW%2BjDDOiG2bBsFZ6a5f3P9LbyDAcfxq3BYTLyw@mail.gmail.com> <1392851578.1145.55.camel@revolution.hippie.lan> <1392869044.1145.58.camel@revolution.hippie.lan> <38db362d34174f70a07c0b9ea39a54c4@e15be-03.zdv.Uni-Mainz.DE>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2014-02-20 at 19:08 +0000, Wei=DF, J=FCrgen wrote: > > -----Original Message----- > > From: owner-freebsd-arm@freebsd.org [mailto:owner-freebsd-arm@freebsd= .org] On Behalf Of > > Ian Lepore > > Sent: Thursday, February 20, 2014 5:04 AM > > To: Tom Everett > > Cc: freebsd-arm@freebsd.org > > Subject: Re: About FreeBSD support one more mini-pc > >=20 > > 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 wo= rking > > > > 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 =3D 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@revolution.hippie.lan, Wed Feb 19 15:41:25 MST 201= 4) > > > DRAM: 2048MB > > > > > > Device: disk > > > - > > > /boot/kernel/kernel text=3D0x42f3d0 data=3D0x31d14+0x2df1c > > syms=3D[0x4+0x923b0+0x4+0x6e34d] > > > Hit [Enter] to boot immediately, or any other key for comma= nd 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 th= at it > > > gets into the kernel, I print that 'a' from the first few instructi= ons > > > of locore.S. > >=20 > > 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 disa= ble > > 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. > >=20 > > We enable the MMU in locore.S without invalidating old cache contents > > first, and that appears to be a bad thing. > >=20 > > -- Ian > >=20 >=20 > 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. >=20 > But without a Dcache invalidate, I had problems to start the second > core. I think it is the enabling of the L2 cache that's causing the problem, because I added your code for invalidating L1 idcache to the first processor startup path, and that didn't help. =20 Flushing the L2 very early in startup is problematic, because we don't know its register addresses until we can read the fdt data (we don't even know what kind of l2 it is), and processing fdt while still running in physical address mode with only pc-relative addressing allowed is more or less impossible. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1392925514.1145.68.camel>