Re: [Angstrom-devel] [RFC] Get rid of adhoc machine-specific messing with [linux-handhelds-2.6] kernel packages

[Marcin Juszkiewicz <openembedded@hrw.one.pl>]

Dnia czwartek, 4 stycznia 2007 20:03, Paul Sokolovsky napisał:

> >> 2) Argue to Angstrom maintainers to stop killing zImage from rootfs
> >> at all - consistently for all machines.
> >
> > So we start to waste 1.2MB disk space on at least 50% of the machines
> > Angstrom supports? Thats a lot of space on a machine with a 32MB root
> > partition.
>
>   It's not going to be waste, as it is supposed to be used by LAB,
> eventually. Also, while 1.2MB seems like a figure, here's the paradox -
> the difference of what you can fit into 32MB and 30.8MB is pretty
> small. 

I can see difference in fitting in 14.4MB which collie offers (or 21-23M 
of poodle, tosa, c700, c750). Keeping not needed files in rootfs hurts. 
We currently have problems with generating rootfs small enough.

> In this regard, why not adopt another convention - instead of
> fitting yet another cool app, why not provide solid
> upgrade/bootloading/troubleshooting/diagnostics solution by default,
> and teach users that a kernel upgrade is piece of cake, you can't
> brick a device by doing that, and generally, Linux on PDA foundation
> is as solid as on desktop?

pdaX people tried to switch to u-boot on Zaurus line. Look into OESF 
forums to check how many users failed to follow 'simple' 2 step reflash.

> > Also, it creates a user support problem. "I upgraded the zImage file
> > on my rootfs but my device still uses my old kernel?".
>
>   Well, that's the crucial point. Could you gentlemen describe how you
> handle kernel upgrade on Zaurus now? I imagine it's shipping a separate
> zImage file together with some upgrade script, or rely on native
> bootloader to install it somehow.

On PXA models you flash two files: kernel and rootfs. Any of them can be 
flashed without second one. There is a 'encrypted' script built by 
zaurus-updater recipe which do it under rescue 2.4 system (kernel + 
rootfs) which is stored in 2 others flash partitions.

>   With my proposal to use full kernel-image packages it would
> be instead:
>
> 1. One does "ipkg install kernel-image"
> 2. One prays and with shaking hands runs
> "adhoc_kernel_update_script.sh /boot/zImage"

This step is impossible under 2.6 on Zaurus due to limitations of Sharp 
bootloader.

>   As for "user support problem", how that differs from what you have
> now? User installs empty kernel-image package and also doesn't get
> upgraded kernel. You likely solved this for Zaurus by telling users
> that installing kernel-image doesn't really upgrade their kernel.
> Well, "Zaurus" appears to be the keyword here.

Under OpenZaurus user gets message on boot that he run incorrect kernel. 
I do not know will Angstrom adopt it or not.

> > Also, on the Zaurus it means wasting a couple of megabytes of flash
> > for the extra copies of kernels you'll need.

>   As for LAB, that's exactly its strength - if you have support for
> some device (like funky flash) in kernel, LAB will be able to use it,
> as it's just kind of module for the kernel itself. The price of this
> is that LAB is indeed too big as for bootloader - ~1Mb instead of
> usual 256Mb/128Mb.

So why not u-boot or Apex? They are much smaller but maybe does not 
provide some stuff which LAB do.

> > Machine config files set information that is specific to the machine.
> > Whether of not a given machine has a sucky bootloader is a property
> > of the machine.

>   Point of view. It's all just point of view. Many-many people would
> consider you crazy for wanting to install something else, handmade,
> instead of vendor-carved-in stuff. But you smile and do just that. And
> yet you tell that /home partition and bootloader are carved in stone.
> But someone else will flash them away just as easily.
>
>   That of course doesn't mean I disagree with the current
> state-of-affairs of mostly adhoc bootloaders to be used, and need to
> account for that somehow. It's just one day it may become a limitation
> to have it in machine config.

OE support machines in a way which maintainers want. If some Joe Dev 
decided to change his machine to work in other way he is free to create 
own variations of configs/recipes. Flash resizing needs changing kernel 
CMDLINE which some bootloaders (like Zaurus one) does not support.

>   Ok, so it's clear that Zaurus machines need to keep using existing
> methods, and those methods should not be touched. On the other hand, I
> hope I was able to argue that other machines might have other
> requirements. In this regard, I'll still need to argue to machine
> mentors of (PocketPC!) machines in question to drop
> FILES_kernel-image_MACH = "".

I'm open to changes for machines which CAN support it. I do not like to 
have machine which do:

1. 1st stage bootloader (small, usually vendor provided)
2. 2nd stage bootloader (big LAB)
3. kernel (also big)

Think about booting time...

>   But anyway, I think that ROOTFS_POSTPROCESS_COMMAND += 
> "remove_zimages; " thing is still useful. It doesn't mean that machines
> should switch to it, but it offers nice, potentially
> machine-independent, way to remove zImage file from the image. 

Which will get back when user update kernel-image package. Which is BAD.

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

      catholic god himself invented autotools just for amusement
      first there was the great flood, then the plague, now autotools