U-Boot updated. new kernels >=3.2 ?

[moonman]

Just found out that U-Boot has been updated by Jeff to fix the >=3.2 kernel not booting problem. Will new kernel versions start to be finally put to repos?
Also, noticed that after installing new U-Boot, the front LED is always orange, even if I set arcNumber to 3542 on my E02

[WarheadsSE]

We need to a way to enforce the kernel not being updated without an updated u-boot first.

[moonman]

I am afraid my level of English doesn't allow me to understand what you just said. I re-read it multiple times and I swear I don't understand

[unclemike]

I think that the problem is: what happens if you upgrade the kernel and uboot remain at old version?
So they must find a method to make sure that uboot is ugraded before upgrade kernel

[WarheadsSE]

And a way to do it per-device, as is correct. Since the install methods differ per-device.

[kmihelich]

We will be relying on people not being retarded, which is a stretch, but it's the simplest solution. The 'linux' package will remain for compatibility purposes frozen at 3.1.10. It works, it's solid, no reason to do anything to it.

In the next couple days we'll be putting out a linux-kirkwood package with 3.4, containing a warning about u-boot compatibility. The package won't replace the linux package. This means it will be a conscious decision by the user to upgrade the kernel, which together with the warning implies they understand what's going on. If they don't, well, they were warned.

[unclemike]

And a way to do it per-device, as is correct. Since the install methods differ per-device.

I wouldn't want to be in your shoes

We will be relying on people not being retarded, which is a stretch, but it's the simplest solution. The 'linux' package will remain for compatibility purposes frozen at 3.1.10. It works, it's solid, no reason to do anything to it.

In the next couple days we'll be putting out a linux-kirkwood package with 3.4, containing a warning about u-boot compatibility. The package won't replace the linux package. This means it will be a conscious decision by the user to upgrade the kernel, which together with the warning implies they understand what's going on. If they don't, well, they were warned.

Agree

A question a bit useless now after the last post, it's teorically possibile for an arch package to read the enviroment variable at install time? And block it's installation if the uboot version is lesser or absent?

When CONFIG_VERSION_VARIABLE is set in your board config file, then
U-Boot will set the "ver" envrionment variable to the current version
ID string. If you run "saveenv" at least once, then you can read this
string from the U-Boot environment under Linux, using the fw_getenv
tool / function provided in tools/env/ .

Best regards,

Wolfgang Denk

PS: I'm relatively new to programming ( and english :p ) but I'm interested to know how devolopers think, so if you may answer like:
Not possible, because ...
Bad idea, beacase ...
I would really appreciate

[WarheadsSE]

Programatically reading the uboot version from inside a running system = nope.

[cyberic]

Maybe it could be possible to pass a variable to linux kernel, ie 'uboot-ver=xxx' and then check this variable during the kernel upgrade?

[WarheadsSE]

Then you have the issue of having uboots that are numbers as 1.x.x and 2011-XX, none of which necessarily tell us anything useful.

Seperating the problem and making it a concious effort to change over solves this altogether, like leming said.