Bug#658759: u-boot: fails to boot compressed 3.2.y kernels
 

reassign 658759 src:linux-2.6 3.2.2-1
tags 658759 + upstream
quit

Loïc Minier wrote:

> * kirkwood: disable L2 cache before Linux boot; thanks to Ian Campbell.
> closes: #658904

Thanks!

The next question is what to do to handle Linux upgrades.

Should the kirkwood kernel have "Breaks: u-boot (<< 2011.12-3)" to
encourage people to update their bootloader when they are lucky enough
to be on a machine where the bootloader is installed through the
package management system?

Should there be a flavor-specific NEWS.Debian.gz to warn sysadmins
about the problem? (I think "yes".)

Should the kirkwood flavor disable CONFIG_ARM_PATCH_PHYS_VIRT? (My
hunch is "no, it shouldn't", but that possibility's available if we
wanted to return to the behavior of the good old days of 3.1.y.)

Context: [1]

| Okay, so this should mean that the kernel's own decompressor has run,
| which should turn on/off the mmu and caches, cleaning and invalidating
| them, which will take the boot loader completely out of the picture at
| this stage.

Could the decompressor disable the L2 cache itself as a workaround?

Given that no one with the right familiarity with the decompressor
code has volunteered to do that, I'd suggest:

- teaching u-boot in stable to follow the boot protocol correctly
- adding a NEWS.Debian.gz in the kernel package to warn people
- mentioning this in the armel variant of the wheezy release notes.

Jonathan

[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/143666/focus=143875



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

Bug#658759: u-boot: fails to boot compressed 3.2.y kernels
 

On Sun, 2012-03-11 at 15:50 -0500, Jonathan Nieder wrote:
> reassign 658759 src:linux-2.6 3.2.2-1
> tags 658759 + upstream
> quit
>
> Loïc Minier wrote:
>
> > * kirkwood: disable L2 cache before Linux boot; thanks to Ian Campbell.
> > closes: #658904
>
> Thanks!
>
> The next question is what to do to handle Linux upgrades.
>
> Should the kirkwood kernel have "Breaks: u-boot (<< 2011.12-3)" to
> encourage people to update their bootloader when they are lucky enough
> to be on a machine where the bootloader is installed through the
> package management system?
[...]

My understanding is that in general we cannot assume that uboot is
upgradable at all, because:

1. Linux may not have access to the flash partition containing it.
2. The factory-installed uboot may have board-specific setup code which
is not included in mainline uboot.
3. A power failure during an upgrade may be unrecoverable without
specialist hardware.

Do we know that none of these apply to the Kirkwood platform? If not,
the kernel must retain compatibility with older versions of uboot.

Ben.

--
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison

Bug#658759: u-boot: fails to boot compressed 3.2.y kernels
 

Ben Hutchings wrote[1]:

> My understanding is that in general we cannot assume that uboot is
> upgradable at all, because:
>
> 1. Linux may not have access to the flash partition containing it.
> 2. The factory-installed uboot may have board-specific setup code which
> is not included in mainline uboot.
> 3. A power failure during an upgrade may be unrecoverable without
> specialist hardware.
>
> Do we know that none of these apply to the Kirkwood platform? If not,
> the kernel must retain compatibility with older versions of uboot.

Cc-ing submitters, Ian, Michael, and Prafulla in case they have hints.
Thanks to all for your work on this so far. [1] has context.

Thanks,
Jonathan

[1] http://bugs.debian.org/658759



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

Bug#658759: u-boot: fails to boot compressed 3.2.y kernels
 

Am Sonntag 11 März 2012, 22:29:53 schrieb Jonathan Nieder:
> Ben Hutchings wrote[1]:
> > My understanding is that in general we cannot assume that uboot is
> > upgradable at all, because:
> >
> > 1. Linux may not have access to the flash partition containing it.
> > 2. The factory-installed uboot may have board-specific setup code which
> > is not included in mainline uboot.
> > 3. A power failure during an upgrade may be unrecoverable without
> > specialist hardware.
> >
> > Do we know that none of these apply to the Kirkwood platform? If not,
> > the kernel must retain compatibility with older versions of uboot.

I guess all three points may be valid for any kirkwood based board. Also keep
in mind, that vendor branches of uboot may not be affected from this bug. Eg.
i had a longer discussion on the arm lkml about this issue and Nicolas Pitre
wasnt able to reproduce the bug on his boards, which had some uboot version
patched by the vendor.

BTW, i don't think this bug is kirkwood specific.

--
Michael



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201203112312.18392.michael@walle.cc">http://lists.debian.org/201203112312.18392.michael@walle.cc

Bug#658759: u-boot: fails to boot compressed 3.2.y kernels
 

On Sun, 2012-03-11 at 16:29 -0500, Jonathan Nieder wrote:
> Ben Hutchings wrote[1]:
>
> > My understanding is that in general we cannot assume that uboot is
> > upgradable at all, because:
> >
> > 1. Linux may not have access to the flash partition containing it.

On the dreamplug I have:
$ cat /proc/mtd
dev: size erasesize name
mtd0: 00080000 00001000 "u-boot"
mtd1: 00010000 00001000 "u-boot env"

Although I must confess that I've only ever updated u-boot via the
u-boot command line (not for any particular reason, just the method I
first discovered).

I don't know about other kirkwood platforms, although I can see some
relevant MTD partition declarations for GuruPlug and SheevaPlug and a
handful of other boards under the relevant
arch/arm/mach-kirkwood/foo-setup.c.

> > 2. The factory-installed uboot may have board-specific setup code which
> > is not included in mainline uboot.

I've been using the Debian supplied u-boot on my DreamPlug basically
since I got it.

One unfortunate wrinkle with the factory supplied image is that it
reuses the GuruPlug machine id instead of defining a new one. This has
the potential to make thing a bit tricky and is the reason I switched to
the Debian supplied u-boot ASAP. Fortunately the upstream Dreamplug
support is now being implemented via DT so I suppose this is not going
to be an issue in practice.

> > 3. A power failure during an upgrade may be unrecoverable without
> > specialist hardware.

The specialist hardware in this case is the JTAG dongle which is £27 if
bought with the dreamplug or £32 if bought separately later. The same
dongle also exposes the serial UART (both that and the JTAG appear as
USB devices) so I think it wouldn't be so unusual for folks to have one
nor all that onerous to require it. Although I suppose £27 is rather
large compared to the £139 cost of the dreamplug itself.

FWIW the required software (openocd) is present in Debian. A fact for
which I am very grateful since I've "bricked" my Dreamplug more than
once ;-)

> > Do we know that none of these apply to the Kirkwood platform? If not,
> > the kernel must retain compatibility with older versions of uboot.

I don't know how relevant this is but so far there has been no kernel
with DreamPlug support in Debian itself, patches are only just going
into mainline now.

Ian.

>
> Cc-ing submitters, Ian, Michael, and Prafulla in case they have hints.
> Thanks to all for your work on this so far. [1] has context.
>
> Thanks,
> Jonathan
>
> [1] http://bugs.debian.org/658759
>
>
>

--
Ian Campbell


Government [is] an illusion the governed should not encourage.
-- John Updike, "Couples"

Bug#658759: u-boot: fails to boot compressed 3.2.y kernels
 

Hello,

On Mon, Mar 12, 2012 at 08:41:57AM +0000, Ian Campbell wrote:
> One unfortunate wrinkle with the factory supplied image is that it
> reuses the GuruPlug machine id instead of defining a new one. This has
depending on how old the factory supplied U-Boot is, it supports
overwriting the machine id by setting the environment variable machid to
the desired value (in hex).

> the potential to make thing a bit tricky and is the reason I switched to
> the Debian supplied u-boot ASAP. Fortunately the upstream Dreamplug
> support is now being implemented via DT so I suppose this is not going
> to be an issue in practice.
Yeah, with dt the machine is ignored AFAICT.

Best regards
Uwe

--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120312093203.GE19497@pengutronix.de">http://lists.debian.org/20120312093203.GE19497@pengutronix.de

Bug#658759: u-boot: fails to boot compressed 3.2.y kernels
 

On Mon, 2012-03-12 at 10:32 +0100, Uwe Kleine-König wrote:
> Hello,
>
> On Mon, Mar 12, 2012 at 08:41:57AM +0000, Ian Campbell wrote:
> > One unfortunate wrinkle with the factory supplied image is that it
> > reuses the GuruPlug machine id instead of defining a new one. This has
> depending on how old the factory supplied U-Boot is, it supports
> overwriting the machine id by setting the environment variable machid to
> the desired value (in hex).

Right, I only discovered this feature after I'd switched to the Debian
u-boot with the correct machid. IIRC the factory supplied one was Circa
early 2009.

> > the potential to make thing a bit tricky and is the reason I switched to
> > the Debian supplied u-boot ASAP. Fortunately the upstream Dreamplug
> > support is now being implemented via DT so I suppose this is not going
> > to be an issue in practice.
> Yeah, with dt the machine is ignored AFAICT.

I've not tried byt perhaps only if you use CONFIG_ARM_APPENDED_DTB or
have a DT aware u-boot otherwise u-boot is going to place atags for
whichever machine id it thinks it supports.

Ian.

--
Ian Campbell
Current Noise: Cynic - Bija!

War is delightful to those who have had no experience of it.
-- Desiderius Erasmus




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1331546102.23971.2.camel@zakaz.uk.xensource.com">h ttp://lists.debian.org/1331546102.23971.2.camel@zakaz.uk.xensource.com

Bug#658759: u-boot: fails to boot compressed 3.2.y kernels
 

On Mon, 2012-03-12 at 08:41 +0000, Ian Campbell wrote:
> On Sun, 2012-03-11 at 16:29 -0500, Jonathan Nieder wrote:
> > Ben Hutchings wrote[1]:
> >
> > > My understanding is that in general we cannot assume that uboot is
> > > upgradable at all, because:
> > >
> > > 1. Linux may not have access to the flash partition containing it.
>
> On the dreamplug I have:

I suppose it went slightly over my head that this issue applies to other
platforms than dreamplug. Oh well, I hope what followed was useful
nonetheless.

BTW I wonder if a suitable workaround might be to have the kernel
disable these same caches early on?

Ian.
--
Ian Campbell
Current Noise: Earth - The Rakehell

A couple of kids tried using pickles instead of paddles for a Ping-Pong
game. They had the volley of the Dills.




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1331551522.23971.44.camel@zakaz.uk.xensource.com"> http://lists.debian.org/1331551522.23971.44.camel@zakaz.uk.xensource.com

Bug#658759: u-boot: fails to boot compressed 3.2.y kernels
 

For what its worth, many of us are now in the process of flashing in new u-boot binaries...

http://forum.doozan.com/read.php?3,6965,6965#msg-6965
I went ahead and posted revised binaries for 3 affected kirkwood
machines: Seagate Dockstar, Pogoplug V1/E01 and Pogoplug V2/E02.*** I haven't yet done anything in terms of a new binary for the Seagate GoFlex Net/Home series.* The Pogoplug V4 series seems to be unaffected by the problem.


Users from both forums.doozan.com and archlinuxarm.org are aware of it and I haven't seen any reports of problems, only of "booting" (the desired behavior).* These two communities are a large slice of users, but I haven't contacted anyone from plugcomputers.org (or whatever they call themselves).




With netconsole enabled, it is a pretty painless procedure (not more
inherently risky than the original installation of Jeff Doozan's
original u-boot replacement).* The process is not obtrusive or overly
invasive - it is a true drop-in flash/bootloader upgrade.* The env vars are not
affected.



Dave

On Mon, Mar 12, 2012 at 6:25 AM, Ian Campbell <ijc@hellion.org.uk> wrote:

On Mon, 2012-03-12 at 08:41 +0000, Ian Campbell wrote:

> On Sun, 2012-03-11 at 16:29 -0500, Jonathan Nieder wrote:

> > Ben Hutchings wrote[1]:

> >

> > > My understanding is that in general we cannot assume that uboot is

> > > upgradable at all, because:

> > >

> > > 1. Linux may not have access to the flash partition containing it.

>

> On the dreamplug I have:



I suppose it went slightly over my head that this issue applies to other

platforms than dreamplug. Oh well, I hope what followed was useful

nonetheless.



BTW I wonder if a suitable workaround might be to have the kernel

disable these same caches early on?



Ian.

--

Ian Campbell

Current Noise: Earth - The Rakehell



* * * *A couple of kids tried using pickles instead of paddles for a Ping-Pong

game. *They had the volley of the Dills.