Re: Providing (armhf) u-boot images together with d-i images?
On Tue, Dec 23, 2014 at 02:17:16PM -0800, Vagrant Cascadian wrote:
> On 2014-12-23, Karsten Merker wrote:
> > If space and bandwidth use is too high
> > for the "full" images, we could use the "concatenateable"
> > variant, although this makes installing the images more
> > complicated for the end user and is only possible if we can
> > manage to boot _all_ armhf platforms with a single boot script,
> > as this boot script is in the device-independent part.
>
> 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) not actually being consistant with the kernel
> boot argument for "console=", or for doing a framebuffer console install
> vs. a serial console install. This affects both the wandboard and
> cubox-i platforms, but can be worked around with a uEnv.txt file or
> setting directly from the u-boot prompt.
>
> The beaglebone black and I suspect mx53loco don't have patches to
> emulate the variables (${boot_targets}, ${devtype}, ${devnum} ...)
> needed to work with "bootscr.mainline_common". This might be possible to
> work around with a uEnv.txt file, but may require some know-how on the
> user's part to set appropriately the emulated variables.
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?
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 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 see both use-cases as valid, as a few boards have broken networking
> support within u-boot, and some users might not want to set up a TFTP
> server.
I have added support for building a netboot.tar.gz similar to the
i386/amd64 PXE one in V2 of the patchset.
> > diff --git a/build/boot/arm/u-boot-image-config b/build/boot/arm/u-boot-image-config
> > new file mode 100644
> > index 0000000..1d0208a
> > --- /dev/null
> > +++ b/build/boot/arm/u-boot-image-config
> ...
> > +# Images from u-boot-omap
> > +BeagleBoneBlack /usr/lib/u-boot/am335x_boneblack/MLO 256 /usr/lib/u-boot/am335x_boneblack/u-boot.img 768
> > +PandaBoard /usr/lib/u-boot/am335x_boneblack/MLO 256 /usr/lib/u-boot/omap4_panda/u-boot.bin 768
>
> I suspect this is a cut-and-paste typo and you want omap4_panda for both
> the MLO and u-boot.bin. :)
Thanks, I have fixed that in V2.
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Reply to: