FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 05-08-2011, 06:10 AM
Hector Oron
 
Default Bug#626031: debian-kernel-handbook: please support U-Boot format images.

Package: debian-kernel-handbook
Version: 1.0.10
Severity: wishlist
Tags: patch

Hello,

While looking to DebianBug#550584, I wonder why do we need to carry
with the burden of maintaining hardcoded stuff for some architectures,
while part of it is maintained by Linux kernel upstream developers.

Adding support for U-Boot image format ('uImage' kernel target) in
official kernel packages seem to me the right thing to do, it would
not only simplify `flash-kernel` (see #108 comments for a `flash-kernel`
summary of issues) but also `debian-installer` which currently have to
add extra code to support U-Boot image format per device. Part of that
extra code could be reduced by allowing U-Boot format images in official
packages.

Regarding initramfs generation, it could be generated as usual by initramfs
tools but if platform uses U-Boot format after creating, updating or deleting
initrd.img it should call the uinitrd.img handler (nowadays flash-kernel) with
a couple parameters:

The following patch against SVN trunk (r89) ammends kernel handbook policy
for allowing U-Boot image format support (and also fixes some indentation
to be coherent with writting style).


Index: chapter-initramfs.sgml
================================================== =================
--- chapter-initramfs.sgml (revision 89)
+++ chapter-initramfs.sgml (working copy)
@@ -63,7 +63,7 @@
<sect id="initramfs-gen-process">
<heading>Choosing the tool</heading>
<p>
- At the end of the kernel package installation a script is
+ At the end of the kernel package installation a script is
automatically invoked to determine the availability of the
initramfs-generating tools and run one of them. This script
contains the list of all such tools available in Debian.
@@ -96,20 +96,33 @@
be regenerated. This is achieved by the command
<example>
# dpkg-reconfigure linux-image-2.6.18-3-686
- </example>
- where <tt>linux-image-2.6.18-3-686</tt> is the name of the
+ </example>
+ where <tt>linux-image-2.6.18-3-686</tt> is the name of the
kernel package for which the initramfs regeneration is requested.
+ </p>
</sect>
<sect id="initramfs-exam">
<heading>Examining the initramfs contents</heading>
- <p>
+ <p>
Occasionally it is useful to examine the contents of initramfs
to diagnose a problem or for educational purposes. They are
compressed <tt>cpio</tt> archives, which may be extracted
using the command
<example>
$ zcat /boot/initrd.img-2.6.18-3-686 | cpio -i
- </example>
+ </example>
It will unpack the contents of the initramfs into the current directory.
+ </p>
</sect>
+ <sect id="initramfs-uimage">
+ <heading>Generating U-Boot format initramfs images (uinitrd.img)</heading>
+ <p>
+ If U-Boot format (<tt>uImage</tt>) Linux kernel image exists
+ initramfs generation tool must run to create, update or delete initramfs
+ after each one of those tasks it must pass control to the uinitrd.img
+ generation tool, nowadays the only known tool <tt>flash-kernel</tt> passing
+ two arguments: action performed (create, update, delete) and
+ <em>version</em>-<em>abiname</em>[-<em>featureset</em>]-<em>flavour</em>.
+ </p>
+ </sect>
</chapt>
Index: chapter-update-hooks.sgml
================================================== =================
--- chapter-update-hooks.sgml (revision 89)
+++ chapter-update-hooks.sgml (working copy)
@@ -28,7 +28,8 @@
optionally, the absolute path to the kernel image. If the
second argument is missing then the path is
either <tt>/boot/vmlinuz-<em>version</em></tt> or
- <tt>/boot/vmlinux-<em>version</em></tt>, according to
+ <tt>/boot/vmlinux-<em>version</em></tt> or
+ <tt>/boot/uImage-<em>version</em></tt>, according to
architecture convention. The environment variable
<tt>DEB_MAINT_PARAMS</tt> will contain the arguments given to
the kernel maintainer script, possibly single-quoted. In a
Index: chapter-packaging.sgml
================================================== =================
--- chapter-packaging.sgml (revision 89)
+++ chapter-packaging.sgml (working copy)
@@ -281,19 +281,35 @@
pre-built binary modules for a particular
arch/featureset/flavour combination. Names of the files
installed by this package are
- architecture-dependent. Typical locations of essential
- files for the <tt>i386</tt> architecture are:
+ architecture-dependent. Traditionally Debian Linux kernel uses
+ <tt>vmlinuz</tt>, a gzip compressed ELF, COFF or a.out image.
+ U-Boot format Linux kernel images, <tt>uImage</tt>, are supported as well
+ for architectures that use such format.
+ Typical locations of essential files are:
<taglist>
<tag><tt>/boot/vmlinuz-<em>version</em>-<em>abiname</em>[-<em>featureset</em>]-<em>flavour</em></tt></tag>
<item>
The binary (compressed) kernel image.
</item>
+ <tag><tt>/boot/uImage-<em>version</em>-<em>abiname</em>[-<em>featureset</em>]-<em>flavour</em></tt></tag>
+ <item>
+ The binary (compressed) kernel image (U-Boot format).
+ </item>
<tag><tt>/boot/initrd.img-<em>version</em>-<em>abiname</em>[-<em>featureset</em>]-<em>flavour</em></tt></tag>
<item>
Initial RAM filesystem (initramfs) image. Note, that this file is automatically generated
in the installation process and is <strong>not</strong> shipped as a part of the package.
+ This file is generated if <tt>vmlinuz</tt> image exists.
See <ref id="initramfs"> for more details.
</item>
+ <tag><tt>/boot/uinitrd.img-<em>version</em>-<em>abiname</em>[-<em>featureset</em>]-<em>flavour</em></tt></tag>
+ <item>
+ Initial RAM filesystem (initramfs) image (U-Boot format). Note, that this
+ file is automatically generated
+ in the installation process and is <strong>not</strong> shipped as a part of the package.
+ This file is generated if <tt>uImage</tt> image exists.
+ See <ref id="initramfs"> for more details.
+ </item>
<tag><tt>/boot/config-<em>version</em>-<em>abiname</em>[-<em>featureset</em>]-<em>flavour</em></tt></tag>
<item>
The kernel configuration file used to build this particular kernel. May be used

Best regards,
-- Hctor Orn

-- System Information:
Debian Release: wheezy/sid
APT prefers stable
APT policy: (700, 'stable'), (600, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.37-1-686 (SMP w/2 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110508061000.6122.17092.reportbug@tcldomain.offi ce">http://lists.debian.org/20110508061000.6122.17092.reportbug@tcldomain.offi ce
 
Old 05-08-2011, 09:49 AM
Martin Michlmayr
 
Default Bug#626031: debian-kernel-handbook: please support U-Boot format images.

* Hector Oron <zumbi@debian.org> [2011-05-08 08:10]:
> Adding support for U-Boot image format ('uImage' kernel target) in
> official kernel packages seem to me the right thing to do, it would

This was suggested before but there are some reasons why I don't
believe it will work:

- We need to hardcode the machine ID into the kernel and the machine
ID depends on a particular device, so shipping a uImage rather than
a normal kernel file will just make it harder.

- Some machines require different uImage settings (load address, etc).
For example, the mv2120 doesn't use a normal uImage but a
multi-boot uImage.

--
Martin Michlmayr
http://www.cyrius.com/



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110508094908.GU16036@jirafa.cyrius.com">http://lists.debian.org/20110508094908.GU16036@jirafa.cyrius.com
 
Old 05-08-2011, 10:27 AM
Hector Oron
 
Default Bug#626031: debian-kernel-handbook: please support U-Boot format images.

Hi,

2011/5/8 Martin Michlmayr <tbm@cyrius.com>:
> * Hector Oron <zumbi@debian.org> [2011-05-08 08:10]:
>> * Adding support for U-Boot image format ('uImage' kernel target) in
>> * official kernel packages seem to me the right thing to do, it would

> This was suggested before but there are some reasons why I don't
> believe it will work:
>
> *- We need to hardcode the machine ID into the kernel and the machine
> * ID depends on a particular device, so shipping a uImage rather than
> * a normal kernel file will just make it harder.

I think machine_ID and kernel_format (uImage|vmlinuz|vmlinux) could
easily be fields in the architecture config files (defines).
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
duplicated), plus we avoid to play with create, upgrade, delete
kernel hooks.

> *- Some machines require different uImage settings (load address, etc).
> * For example, the mv2120 doesn't use a normal uImage but a
> * multi-boot uImage.

What's a multi-boot uImage?

Best regards,
--
*Héctor Orón *-.. . -... .. .- -. * -.. . ...- . .-.. --- .--. . .-.

PS.- I have just built an uImage for tegra device and linux kernel
have all the needed information,
why Debian Linux kernel is unable to do the same?

zumbi@ts01:~/linux-2.6.39-rc6$ make uImage
CHK include/linux/version.h
CHK include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
Kernel: arch/arm/boot/Image is ready
SHIPPED arch/arm/boot/compressed/lib1funcs.S
AS arch/arm/boot/compressed/lib1funcs.o
LD arch/arm/boot/compressed/vmlinux
OBJCOPY arch/arm/boot/zImage
Kernel: arch/arm/boot/zImage is ready
UIMAGE arch/arm/boot/uImage
Image Name: Linux-2.6.39-rc6
Created: Sun May 8 09:47:21 2011
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2147104 Bytes = 2096.78 kB = 2.05 MB
Load Address: 00008000
Entry Point: 00008000
Image arch/arm/boot/uImage is ready


"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



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/BANLkTi�FxBxf+4nSYAgLbLj0PVfk9E5w@mail.gmail.com
 
Old 05-08-2011, 10:45 AM
Martin Michlmayr
 
Default Bug#626031: debian-kernel-handbook: please support U-Boot format images.

* 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?)

> 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?

> What's a multi-boot uImage?

Sorry, I mean an u-boot multi-boot image that contains both the kernel
and the ramdisk.

--
Martin Michlmayr
http://www.cyrius.com/



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110508104501.GC12292@jirafa.cyrius.com">http://lists.debian.org/20110508104501.GC12292@jirafa.cyrius.com
 
Old 05-08-2011, 11:19 AM
Hector Oron
 
Default 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,
--
*Hctor Orn *-.. . -... .. .- -. * -.. . ...- . .-.. --- .--. . .-.

"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



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTikF_VwjsvStxg70K-O9VcnSk3hFDA@mail.gmail.com">http://lists.debian.org/BANLkTikF_VwjsvStxg70K-O9VcnSk3hFDA@mail.gmail.com
 
Old 05-08-2011, 11:29 AM
Martin Michlmayr
 
Default Bug#626031: debian-kernel-handbook: please support U-Boot format images.

* Hector Oron <hector.oron@gmail.com> [2011-05-08 12:19]:
> Machine ID stuff cannot go in kernel package.

Right. And that's the reason why I don't understand why you'd want to
put an uImage into the kernel package. We just need to take the
uImage apart again, add the machine ID and generate an uImage again.

Can you describe what you intend to achieve by shipping the uImage in
the kernel package?

> 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.

Ok, good.
--
Martin Michlmayr
http://www.cyrius.com/



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110508112904.GG12292@jirafa.cyrius.com">http://lists.debian.org/20110508112904.GG12292@jirafa.cyrius.com
 
Old 05-08-2011, 11:47 AM
Hector Oron
 
Default 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 12:19]:
>> Machine ID stuff cannot go in kernel package.

> Right. *And that's the reason why I don't understand why you'd want to
> put an uImage into the kernel package. *We just need to take the
> uImage apart again, add the machine ID and generate an uImage again.

OK, I understand that, I did not had such a deep thought on machine ID stuff.
Maybe because I was not thinking it is the general case, do we always
change machine ID?
IIUC, few devices need to change ID, if I am wrong then it is probably
not worth to implement
such behaviour.

> Can you describe what you intend to achieve by shipping the uImage in
> the kernel package?

On device I can do: make uImage && cp arch/arm/boot/uImage /boot/ (more or less)
and it should work. Then I am trying to apt-get install kernel and
have an uImage installed, which
already triggers initramfs and initramfs triggers flash-kernel for
converting initrd.img into U-Boot format
and do all the tweaks we need to do on device. That should probably
work for creating, updating and
deleting kernel package without much hassle.

This proposal is really triggered by aiming to find a solution for
DebianBug#550584.

--
*Hctor Orn *-.. . -... .. .- -. * -.. . ...- . .-.. --- .--. . .-.

"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



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTinq06gBLMRBnhKkT5Jz_7rBy4Q4Dg@mail.gmail.com ">http://lists.debian.org/BANLkTinq06gBLMRBnhKkT5Jz_7rBy4Q4Dg@mail.gmail.com
 

Thread Tools




All times are GMT. The time now is 01:38 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org