On 2014-12-26, Karsten Merker wrote:
> On Tue, Dec 23, 2014 at 02:17:16PM -0800, Vagrant Cascadian wrote:
>> On 2014-12-23, Karsten Merker wrote:
>> I don't think it's possible yet to have the device-independent parts
>> working with *all* platforms (at least for Jessie), but we can get close
>> with a few relatively simple workarounds:
>>
>> Some of the issues with "bootscr.mainline_common" are inconsistancies
>> across platforms with the u-boot console settings (particularly the baud
>> rate not being appended)
...
> I do not know what the default environment on those platforms
> looks like, but assuming that they define the fdtfile environment
> variable, how about adding stanzas like
>
> if test "${fdtfile}" = "am335x-boneblack.dtb" ; then
> (set the necessary environment variables)
> fi
>
> to bootscr.mainline_common for those special cases?
For the default serial console, yes, this could work (at least for
imx6q-wandboard.dtb and imx6q-cubox-i.dtb). For setting the framebuffer
or other console, it would still probably require manually (or through
uEnv.txt) setting the console variable.
It would get increasingly more complicated the more boards get supported
over time, but at the moment we're looking at only a handful of boards.
Alternately, could also check for specific values of console/baudrate,
which could support broader classes of systems:
# wandboard, cubox-i and possibly other imx systems may need to append
# the baud rate.
if test "${console}" = "ttymxc0" && test -n "${baudrate}" ; then
setenv console=${console},${baudrate}
fi
This way, if the user has manually configured the console value somehow
(such as console=tty0 for framebuffer), it doesn't blindly overwrite it
just because it detects a certain ${fdtfile}.
That doesn't address the conditionals that the BeagleBone Black would
need, which could potentially boot off of eMMC or an inserted SD card,
and thus ${devnum} and related variables would need to be set
conditionally...
I had planned on patching u-boot to emulate the config_distro_bootcmd
for BeagleBone Black (like with wandboard/cubox-i), but was unable to
resolve incompatible uses of ${bootpart}.
> Regarding uEnv.txt: is that file automatically read by the
> default environment of those platforms before executing boot.scr,
> or does boot.scr have to explicitly source uEnv.txt?
The BeagleBone Black, Wandboard* and CuBox-i systems should all load
uEnv.txt before the bootscript, at least with the u-boot in Debian. I've
added some patches for uEnv.txt support and changed the order on some of
those to make sure that they worked more-or-less consistantly.
I tried getting uEnv.txt support into mainline u-boot's
config_distro_bootcmd.h, but didn't get much favorable feedback about
that:
http://lists.denx.de/pipermail/u-boot/2014-October/190843.html
Though I do think it's generally useful to be able to make "generic"
images and tweak them with a few uEnv.txt variables to set things that
are not detectable.
>> The netboot images here seem more like the mini.iso netboot images on
>> x86, though I've tested several armhf installs with the boot.scr,
>> kernel, initrd, dtb all downloaded via TFTP (more like the pxe boot
>> images on x86).
...
> I have added support for building a netboot.tar.gz similar to the
> i386/amd64 PXE one in V2 of the patchset.
Excellent!
live well,
vagrant
Attachment:
signature.asc
Description: PGP signature