Date: Fri, 21 Nov 2014 20:26:32 -0700 From: Ian Lepore <ian@FreeBSD.org> To: ticso@cicely.de Cc: freebsd-arm@freebsd.org Subject: Re: Utilite support Message-ID: <1416626792.1147.325.camel@revolution.hippie.lan> In-Reply-To: <20141122030652.GD15350@cicely7.cicely.de> References: <ADE49E48-60F7-4626-BB1E-169B8478C842@waschbuesch.de> <1416503998.1147.185.camel@revolution.hippie.lan> <F88BEE72-032A-4A34-ABE7-679368694540@waschbuesch.de> <1416584156.1147.259.camel@revolution.hippie.lan> <20141122030652.GD15350@cicely7.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2014-11-22 at 04:06 +0100, Bernd Walter wrote: > On Fri, Nov 21, 2014 at 08:35:56AM -0700, Ian Lepore wrote: > > On Fri, 2014-11-21 at 14:04 +0100, Waschb=FCsch Martin wrote: > > > > Am 20.11.2014 um 18:19 schrieb Ian Lepore <ian@FreeBSD.org>: > > > >=20 > > > > There is some chance that "it might just work." Actually a bette= r > > > > chance now than when I originally wrote that. :) Try using croch= et for > > > > wandboard and in the wandboard kernel config file change FDT_DTS_= FILE to > > > > "imx6q-cm-fx6.dts". There's a good chance you'll end up with a b= ootable > > > > image on an sdcard. > > > >=20 > > > > You will need a serial console for debugging, we don't support a = video > > > > console yet on imx6 systems. The Compulab FitPc2 x86 systems nee= d a > > > > special serial debugging cable that you have to buy separately. = I hope > > > > that's not also the case with Utilite. > > > >=20 > > > > -- Ian > > >=20 > > > Hello Ian, > > >=20 > > > I tried to follow your suggestion, but realized that there might be > > > a significant difference between Wandboard and Utilite: Utilite doe= s > > > not read u-boot from disk. Instead, it holds u-boot as 'firmware' i= n > > > a flash module. > > > Don't know why I had not realized this earlier, but anyway, I guess > > > if I had compiled it before, I would have noticed. So far I had pla= yed > > > around with pre-built Wandboard images... > > > What this means is that the current crochet scripts will fail becau= se > > > the u-boot compilation for cm-fx6 will not output a u-boot.imx file= and > > > is probably not needed anyway. > > > What I will try next is make a copy of crochet's boards/Wandboard t= o > > > boards/Utilite and try to adapt the setup.sh script. > > > Questions: > > > Are there requirements that u-boot must meet in order to boot ubldr= ? If > > > so, I'll have to look into rebuilding u-boot plus flashing that. > > >=20 > > > Martin > >=20 > > I'll attach the patches I use for building u-boot (I use the uboot fo= r > > Technexion EDM modules for Wandboard too; wandboard uses technexion > > modules). The API option is the main one for running ubldr. > >=20 > > Check whether the uboot on the Utilite has the 'bmode' command. You = may > > be able to insert an sdcard with a new uboot and freebsd on it and sa= y > > "bmode mmc0" (or mmc1 or whatever) and the system will reset and boot > > from the sdcard instead of the flash. > >=20 > > My Cubox i4pro arrived yesterday. Its uboot doesn't have the API opt= ion > > (they almost never do; linux doesn't use it). I tried compiling the = dtb > > into the kernel and launching it directly, and that fails because the > > cubox dts doesn't have a memory=3D<> property. I think the uboot pro= bably > > figures out the amount of ram and modifies the dtb it passes to the > > kernel. Ick. I hacked around that and now the kernel hangs as soon = as > > initarm() installs new page tables. >=20 > So how is that uboot thing handled in this case? > Can you go and compile uboot from the same source as for a wandboard, o= r > do we need to have different source for each of the boards? > As you know I do own a bunch of different iMX6 boards and I'm happy to > do test boots and minor tweaking (if required by readin gschematics) on > all of them. >=20 I'm trying to figure that out at this very moment. A while back I came up with a single master u-boot-imx6 port that works for all flavors (solo, dual, quad) of wandboards and technexion edm modules. But the u-boot sources I used for that don't have the cubox stuff, so first I've got to get some sources that do. I think that's probably the world we're stuck in... more or less a separate u-boot port for every flavor of board we support, with maybe an occasional opportunity to collapse several similar boards into one port. A lot of times there are vendor-specific tweaks to u-boot and they don't always push them back to the u-boot project, they just publish them on github to comply with gpl (if you're lucky) and call it done. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1416626792.1147.325.camel>