Bug#626031: debian-kernel-handbook: please support U-Boot format images.
Hi,
2011/5/8 Martin Michlmayr <tbm@cyrius.com>:
> * Hector Oron <hector.oron@gmail.com> [2011-05-08 11:27]:
>> I think machine_ID and kernel_format (uImage|vmlinuz|vmlinux) could
>> easily be fields in the architecture config files (defines).
> How does this help? We ship one kernel image for a platform and this
> will run on several machines (which have their own machine IDs?)
Well, correct me if I am wrong, but in Linux kernel I find, i.e.:
arch/arm/mach-tegra/Makefile.boot:1:zreladdr-$(CONFIG_ARCH_TEGRA_2x_SOC)
:= 0x00008000
arch/arm/mach-mx5/Makefile.boot:1: zreladdr-$(CONFIG_ARCH_MX50)
:= 0x70008000
arch/arm/mach-mx5/Makefile.boot:4: zreladdr-$(CONFIG_ARCH_MX51)
:= 0x90008000
arch/arm/mach-mx5/Makefile.boot:7: zreladdr-$(CONFIG_ARCH_MX53)
:= 0x70008000
arch/arm/mach-kirkwood/Makefile.boot:1: zreladdr-y := 0x00008000
etc...
Load address and entry point is coded in kernel source used by mkimage
when uImage kernel target is called.
So having a field in debian/config/$arch/defines
kernel-format: uImage
should build uImage with default addresses provided by Linux kernel.
The rest of the magic still needs to happen in `flash-kernel`,
basically device dependent code.
Machine ID stuff cannot go in kernel package.
Note that if we are more comfortable using vmlinuz, we could allow:
kernel-format: uImage, vmlinuz
so both files get shipped in the package, having the posibility of
overriding default uImage if needed.
>> Having a kernel task that overrides machine ID (when needed) does not
>> seem to be a complicated task either. OTOH, we
>> simplify `debian-installer` and `flash-kernel` (where code is
> If I understand you correctly, you're basically proposing moving the
> flash-kernel code into the linux-2.6 postinst?
Just the uImage generation part. (And we gain hooks very cheap?)
uInitrd, boot scripts (boot.scr) and machine ID hackery probably needs
to live where it is now.
>> What's a multi-boot uImage?
> Sorry, I mean an u-boot multi-boot image that contains both the kernel
> and the ramdisk.
It can probably still be generated, as my proposal does not try to
conflict with current design,
but allow for simplification and both solutions are compatible at the same time.
Best regards,
--
Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."
-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html
Reply to: