Debian Bug report logs - #658759
[kirkwood] decompressor doesn't disable l2 cache (need workaround for uboot bug#658904)

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: "purdyd tds.net" <purdyd@tds.net>

To: submit@bugs.debian.org

Subject: linux-image-3.2.0-1-kirkwood does not boot on some Kirkwood machines

Date: Sun, 5 Feb 2012 15:18:33 -0600

[Message part 1 (text/plain, inline)]

Package: linux-image-3.2.0-1-kirkwood
Version: 3.2.2-1


Problem:  This kernel package, when installed on many Kirkwood machines,
including the Dockstar, does not boot.  Various users have noticed this,
and it seems likely that it could be related to compression of the kernel
image into the uImage file.   Notably, an uncompressed vmlinux.bin (from
the same build/source) relabeled as uImage will boot correctly.
Unfortunately, the default for this package is a compressed image.

http://packages.debian.org/unstable/kernel/linux-image-3.2.0-1-kirkwood





Steps to reproduce, with output shown:


On my Dockstar:

==============================
================================
cd /

wget
http://ftp.us.debian.org/debian/pool/main/l/linux-2.6/linux-image-3.2.0-1-kirkwood_3.2.2-1_armel.deb

dpkg -i linux-image-3.2.0-1-kirkwood_3.2.2-1_armel.deb

mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n
Linux-3.2.0-1-kirkwood -d /boot/vmlinuz-3.2.0-1-kirkwood /boot/uImage

mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n
initramfs-3.2.0-1-kirkwood -d /boot/initrd.img-3.2.0-1-kirkwood
/boot/uInitrd
==================================================================





From serial connection:
==============================================================
U-Boot 2010.09 (Oct 23 2010 - 11:49:22)
Marvell-Dockstar/Pogoplug by Jeff Doozan

SoC:   Kirkwood 88F6281_A0
DRAM:  128 MiB
NAND:  256 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0
88E1116 Initialized on egiga0
Hit any key to stop autoboot:  0
(Re)start
USB...
USB:   Register 10011 NbrPorts
1
USB EHCI
1.00
scanning bus for devices... 4 USB Device(s)
found
       scanning bus for storage devices... 1 Storage Device(s)
found
Loading file "/rescueme" from usb device 0:1
(usbda1)
** File not found
/rescueme
reading
/rescueme.txt


** Unable to read "/rescueme.txt" from usb 0:1
**
Creating 1 MTD partitions on
"nand0":
0x000002500000-0x000010000000 :
"mtd=3"
UBI: attaching mtd1 to
ubi0
UBI: physical eraseblock size:   131072 bytes (128
KiB)
UBI: logical eraseblock size:    129024
bytes
UBI: smallest flash I/O unit:
2048
UBI: sub-page size:
512
UBI: VID header offset:          512 (aligned
512)
UBI: data offset:
2048
UBI: attached mtd1 to
ubi0
UBI: MTD device name:
"mtd=3"
UBI: MTD device size:            219
MiB
UBI: number of good PEBs:
1752
UBI: number of bad PEBs:
0
UBI: max. allowed volumes:
128
UBI: wear-leveling threshold:
4096
UBI: number of internal volumes:
1
UBI: number of user volumes:
0
UBI: available PEBs:
1731
UBI: total number of reserved PEBs:
21
UBI: number of PEBs reserved for bad PEB handling:
17
UBI: max/mean erase counter:
1/1
UBIFS error (pid 0): ubifs_get_sb: cannot open "ubi:rootfs", error
-19
Error reading superblock on volume
'ubi:rootfs'!
Loading file "/boot/uImage" from usb device 0:1
(usbda1)
1 bytes
read
Found bootable drive on usb
0:1
Loading file "/boot/uImage" from usb device 0:1
(usbda1)
1570456 bytes
read
Loading file "/boot/uInitrd" from usb device 0:1
(usbda1)
6621782 bytes
read
## Booting kernel from Legacy Image at 00800000
...
   Image Name:
Linux-3.2.0-1-kirkwood
   Image Type:   ARM Linux Kernel Image
(uncompressed)
   Data Size:    1570392 Bytes = 1.5
MiB
   Load Address:
00008000
   Entry Point:
00008000
   Verifying Checksum ...
OK
## Loading init Ramdisk from Legacy Image at 01100000
...
   Image Name:
initramfs-3.2.0-1-kirkwood
   Image Type:   ARM Linux RAMDisk Image (gzip
compressed)
   Data Size:    6621718 Bytes = 6.3
MiB
   Load Address:
00000000
   Entry Point:
00000000
   Verifying Checksum ...
OK
   Loading Kernel Image ...
OK
OK



Starting kernel
...


Uncompressing Linux... done, booting the kernel.
=================================================================

No further output is seen.


  I am using Debian GNU/Linux 6/Wheezy.  The same behavior shows up with
Squeeze.

[Message part 2 (text/html, inline)]

Message #10 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Donald Gordon <don@dis.org.nz>

To: 658759@bugs.debian.org

Subject: Also on Guruplug

Date: Mon, 6 Feb 2012 11:32:34 +1300

I've seen what looks like the same issue on my Guruplug.
linux-image-3.1.0-1-kirkwood (3.1.8-2) boots fine,
linux-image-3.2.0-1-kirkwood (3.2.2-1) doesn't get anywhere.

My U-boot banner looks like this:

----
U-Boot 2011.03 (Apr 26 2011 - 21:35:00)
Marvell-GuruPlug

SoC:   Kirkwood 88F6281_A1
DRAM:  512 MiB
NAND:  512 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0, egiga1
88E1121 Initialized on egiga0
88E1121 Initialized on egiga1
----

And when I boot 3.2.0-1, this is what I see:

----
Loading file "/uImage.bak" from ide device 0:1 (hda1)
1570456 bytes read
Loading file "/uInitrd.bak" from ide device 0:1 (hda1)
8211832 bytes read


Marvell>> bootm 0x00800000 0x01100000
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Debian kernel

   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1570392 Bytes = 1.5 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 01100000 ...
   Image Name:   Debian ramdisk
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    8211768 Bytes = 7.8 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
----

After this, no more messages are visible on the serial console, and
there is no other indication that the boot progresses.

Thanks

donald

Message #15 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Donald Gordon <don@dis.org.nz>

To: 658759@bugs.debian.org

Subject: More information

Date: Mon, 6 Feb 2012 13:25:09 +1300

Upgrading my u-boot to the version from here:

  http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html

made my boot progress futher.  Now the kernel starts. But the last
message I see is that udev has started; after this, the boot process
stalls again.

donald

Message #22 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: "purdyd tds.net" <purdyd@tds.net>

Cc: 658759@bugs.debian.org, Donald Gordon <don@dis.org.nz>

Subject: Re: [arm/kirkwood] compressed image does not boot

Date: Sun, 5 Feb 2012 23:18:59 -0600

purdyd tds.net wrote:

> Problem:  This kernel package, when installed on many Kirkwood machines,
> including the Dockstar, does not boot.

Thanks.  Am I correct in guessing that version
3.2~rc4-1~experimental.1 from http://snapshot.debian.org/ does not
reproduce the problem, while 3.2~rc7-1~experimental.1 does?

Curious,
Jonathan

Message #27 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: "purdyd tds.net" <purdyd@tds.net>

Cc: 658759@bugs.debian.org, Donald Gordon <don@dis.org.nz>

Subject: Re: [arm/kirkwood] compressed image does not boot

Date: Mon, 6 Feb 2012 09:34:04 -0600

purdyd tds.net wrote:

> Thnx for the response... I'm game to try both of those versions
> linux-image-kirkwood-3.2.0-rc[4,7], but I've been unable to actually find
> the binaries in snapshot.debian.org.

Oh, you're right.

After a little more investigation, the grounds for my guess were wrong
anyway.  I guess I would want to know instead:

 - where can I read a little about the many users experiencing this?
   (e.g., was there a mailing list discussion?)  That might help in
   pinning down relevant variables.

 - what is the newest version you know of that worked?  One can use
   https://buildd.debian.org/status/logs.php?pkg=linux-2.6&arch=armel to
   find which versions actually got built on arm, or something like

	fakeroot debian/rules source
	fakeroot make -f debian/rules.gen binary-arch_armel_none_kirkwood

to build a version if you have the source installed.

Sorry for the confusion,
Jonathan

Message #32 received at 658759@bugs.debian.org (full text, mbox, reply):

From: "purdyd tds.net" <purdyd@tds.net>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: 658759@bugs.debian.org, Donald Gordon <don@dis.org.nz>

Subject: Re: [arm/kirkwood] compressed image does not boot

Date: Mon, 6 Feb 2012 10:34:47 -0600

[Message part 1 (text/plain, inline)]

Jonathan,

The pointer towards

https://buildd.debian.org/status/logs.php?pkg=linux-2.6&ver=3.2~rc4-1~experimental.1&arch=armel
is a good one.  I read it and the build died because of a problem in
arch/arm/include/asm/bug.h  - quite a few of us have known about this
problem, but it has been taken care of in 3.3, IIRC.   It is my guess that
the 3.2~rc7 prolly died for the same reason.  This particular error,
though, I believe is a red herring.


I answered your queries below, inline.



On Mon, Feb 6, 2012 at 9:34 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:

>
> Oh, you're right.
>
> After a little more investigation, the grounds for my guess were wrong
> anyway.  I guess I would want to know instead:
>
>  - where can I read a little about the many users experiencing this?
>   (e.g., was there a mailing list discussion?)  That might help in
>   pinning down relevant variables.
>

Well, here are three different discussions:

1.  debian users @ doozan/dockstar/debian  forum
http://forum.doozan.com/read.php?2,6550,6550#msg-6550

**note: the thread title is __misleading__ ... 3.1.x is working fine, only
3.2 & greater are showing this compression problem



2.
http://archlinuxarm.org/forum/viewtopic.php?f=18&t=2314&sid=5bdde26688b00721aaaca66b564cd2a8
(there is an issue mentioned here regarding kmod and udev, but that, I
believe is unrelated to the noboot/compressedkernel problem)


3.   http://www.plugcomputer.org/plugforum/index.php?topic=6029.0



>
>  - what is the newest version you know of that worked?  One can use
>   https://buildd.debian.org/status/logs.php?pkg=linux-2.6&arch=armel to
>   find which versions actually got built on arm, or something like
>

3.1.10 works perfectly for me.   3.2 and beyond all seem to suffer from the
same problem w/ a stall/hang, as is shown in my serial output.   Again, we
cannot boot the uImage from either your official package 3.2.2 that is in
Sid, nor can we boot a uImage that we natively or w/ a toolchain.   Same
symptoms for all.  OTOH, an uncompressed vmlinux.bin  (from objcopy) does
when substituted for the uImage file.



>
>        fakeroot debian/rules source
>        fakeroot make -f debian/rules.gen binary-arch_armel_none_kirkwood
>
> to build a version if you have the source installed.
>
> Sorry for the confusion,
> Jonathan
>

[Message part 2 (text/html, inline)]

Message #37 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: "purdyd tds.net" <purdyd@tds.net>

Cc: 658759@bugs.debian.org, Donald Gordon <don@dis.org.nz>

Subject: Re: [arm/kirkwood] compressed image does not boot

Date: Mon, 6 Feb 2012 11:03:23 -0600

forwarded 658759 https://bugzilla.kernel.org/show_bug.cgi?id=42680
quit

purdyd tds.net wrote:

> Well, here are three different discussions:

Plus <https://bugzilla.kernel.org/show_bug.cgi?id=42680>. ;-)

I don't think the upstream developers monitor bugzilla, but at
least it's one place instead of lots of separate distro-specific
forums.  Let's continue this there.

Message #44 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Ian Campbell <ijc@hellion.org.uk>

To: Donald Gordon <don@dis.org.nz>, 658759@bugs.debian.org

Subject: Re: Bug#658759: Also on Guruplug

Date: Mon, 06 Feb 2012 18:05:23 +0100

On Mon, 2012-02-06 at 11:32 +1300, Donald Gordon wrote:
> I've seen what looks like the same issue on my Guruplug.
> linux-image-3.1.0-1-kirkwood (3.1.8-2) boots fine,
> linux-image-3.2.0-1-kirkwood (3.2.2-1) doesn't get anywhere.
> 
> My U-boot banner looks like this:
[...]
> After this, no more messages are visible on the serial console, and
> there is no other indication that the boot progresses.

I suspect this is due to the lack of this u-boot patch:
http://lists.denx.de/pipermail/u-boot/2012-February/117020.html

I found that without this my 3.2 dreamplug kernel would not boot (with
the 2011.12-2 package from debian). It's related to
CONFIG_ARM_PATCH_PHYS_VIRT.

Ian.

-- 
Ian Campbell

If the rich could pay the poor to die for them, what a living the poor
could make!

Message #49 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Ian Campbell <ijc@hellion.org.uk>

Cc: 658759@bugs.debian.org, Donald Gordon <don@dis.org.nz>, "purdyd tds.net" <purdyd@tds.net>

Subject: Re: [arm/kirkwood] compressed image does not boot

Date: Mon, 6 Feb 2012 11:42:01 -0600

Ian Campbell wrote:

> I suspect this is due to the lack of this u-boot patch:
> http://lists.denx.de/pipermail/u-boot/2012-February/117020.html
>
> I found that without this my 3.2 dreamplug kernel would not boot (with
> the 2011.12-2 package from debian). It's related to
> CONFIG_ARM_PATCH_PHYS_VIRT.

For the record, this proposed u-boot change has been filed as
<http://bugs.debian.org/658904>.

The inability to work with versions of u-boot without that change
(workaround?) in the default configuration still would seem to be a
regression in the kernel, so pointers toward solving it would be very
welcome.

Thanks very much for tracking this down,
Jonathan

Message #54 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Ian Campbell <ijc@hellion.org.uk>

To: Jonathan Nieder <jrnieder@gmail.com>, 658759@bugs.debian.org

Cc: Donald Gordon <don@dis.org.nz>, "purdyd tds.net" <purdyd@tds.net>

Subject: Re: Bug#658759: [arm/kirkwood] compressed image does not boot

Date: Mon, 06 Feb 2012 22:08:51 +0100

On Mon, 2012-02-06 at 11:42 -0600, Jonathan Nieder wrote:
> Ian Campbell wrote:
> 
> > I suspect this is due to the lack of this u-boot patch:
> > http://lists.denx.de/pipermail/u-boot/2012-February/117020.html
> >
> > I found that without this my 3.2 dreamplug kernel would not boot (with
> > the 2011.12-2 package from debian). It's related to
> > CONFIG_ARM_PATCH_PHYS_VIRT.
> 
> For the record, this proposed u-boot change has been filed as
> <http://bugs.debian.org/658904>.
> 
> The inability to work with versions of u-boot without that change
> (workaround?) in the default configuration still would seem to be a
> regression in the kernel, so pointers toward solving it would be very
> welcome.

I hacked my kernel (the Kconfig files) to allow me to turn off
PATCH_PHYS_VIRT and it also worked.

However AIUI PATCH_VIRT_PHYS is part of the infrastructure which allows
a single kernel flavour to boot on multiple machines so turning it off
is not a viable workaround.

I think this is just a latent bug in u-boot which has been exposed by a
recent kernel changes and should be treated as a bug to be fixed in
u-boot. I personally wouldn't consider it a regression in the kernel (at
least based on my understanding of what's going on).

Ian.

Message #59 received at 658759@bugs.debian.org (full text, mbox, reply):

From: "purdyd tds.net" <purdyd@tds.net>

To: Ian Campbell <ijc@hellion.org.uk>

Cc: Jonathan Nieder <jrnieder@gmail.com>, 658759@bugs.debian.org, Donald Gordon <don@dis.org.nz>

Subject: Re: Bug#658759: [arm/kirkwood] compressed image does not boot

Date: Mon, 6 Feb 2012 15:30:51 -0600

[Message part 1 (text/plain, inline)]

Thanks, Ian.

I understand.  Do any of you know if there are any ready-rolled u-boot
binaries for Dockstar available out there that incorporate this fix?

Perhaps tbm's u-boot upgrades here :  ??
http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html

thnx,
Davy




On Mon, Feb 6, 2012 at 3:08 PM, Ian Campbell <ijc@hellion.org.uk> wrote:

> On Mon, 2012-02-06 at 11:42 -0600, Jonathan Nieder wrote:
> > Ian Campbell wrote:
> >
> > > I suspect this is due to the lack of this u-boot patch:
> > > http://lists.denx.de/pipermail/u-boot/2012-February/117020.html
> > >
> > > I found that without this my 3.2 dreamplug kernel would not boot (with
> > > the 2011.12-2 package from debian). It's related to
> > > CONFIG_ARM_PATCH_PHYS_VIRT.
> >
> > For the record, this proposed u-boot change has been filed as
> > <http://bugs.debian.org/658904>.
> >
> > The inability to work with versions of u-boot without that change
> > (workaround?) in the default configuration still would seem to be a
> > regression in the kernel, so pointers toward solving it would be very
> > welcome.
>
> I hacked my kernel (the Kconfig files) to allow me to turn off
> PATCH_PHYS_VIRT and it also worked.
>
> However AIUI PATCH_VIRT_PHYS is part of the infrastructure which allows
> a single kernel flavour to boot on multiple machines so turning it off
> is not a viable workaround.
>
> I think this is just a latent bug in u-boot which has been exposed by a
> recent kernel changes and should be treated as a bug to be fixed in
> u-boot. I personally wouldn't consider it a regression in the kernel (at
> least based on my understanding of what's going on).
>
> Ian.
>
>
>

[Message part 2 (text/html, inline)]

Message #64 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Ian Campbell <ijc@hellion.org.uk>

To: "purdyd tds.net" <purdyd@tds.net>

Cc: Jonathan Nieder <jrnieder@gmail.com>, 658759@bugs.debian.org, Donald Gordon <don@dis.org.nz>

Subject: Re: Bug#658759: [arm/kirkwood] compressed image does not boot

Date: Thu, 09 Feb 2012 06:36:17 +0000

On Mon, 2012-02-06 at 15:30 -0600, purdyd tds.net wrote:
> Thanks, Ian.
> 
> I understand.  Do any of you know if there are any ready-rolled u-boot
> binaries for Dockstar available out there that incorporate this fix?

No idea I'm afraid.

Given that #658759 has been filed against u-boot in Debian I expect a
new package will be along shortly.

Ian.

> 
> Perhaps tbm's u-boot upgrades here :  ??
> http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html
> 
> thnx,
> Davy
> 
> 
> 
> 
> On Mon, Feb 6, 2012 at 3:08 PM, Ian Campbell <ijc@hellion.org.uk>
> wrote:
>         On Mon, 2012-02-06 at 11:42 -0600, Jonathan Nieder wrote:
>         > Ian Campbell wrote:
>         >
>         > > I suspect this is due to the lack of this u-boot patch:
>         > >
>         http://lists.denx.de/pipermail/u-boot/2012-February/117020.html
>         > >
>         > > I found that without this my 3.2 dreamplug kernel would
>         not boot (with
>         > > the 2011.12-2 package from debian). It's related to
>         > > CONFIG_ARM_PATCH_PHYS_VIRT.
>         >
>         > For the record, this proposed u-boot change has been filed
>         as
>         > <http://bugs.debian.org/658904>.
>         >
>         > The inability to work with versions of u-boot without that
>         change
>         > (workaround?) in the default configuration still would seem
>         to be a
>         > regression in the kernel, so pointers toward solving it
>         would be very
>         > welcome.
>         
>         I hacked my kernel (the Kconfig files) to allow me to turn off
>         PATCH_PHYS_VIRT and it also worked.
>         
>         However AIUI PATCH_VIRT_PHYS is part of the infrastructure
>         which allows
>         a single kernel flavour to boot on multiple machines so
>         turning it off
>         is not a viable workaround.
>         
>         I think this is just a latent bug in u-boot which has been
>         exposed by a
>         recent kernel changes and should be treated as a bug to be
>         fixed in
>         u-boot. I personally wouldn't consider it a regression in the
>         kernel (at
>         least based on my understanding of what's going on).
>         
>         Ian.
>         
>         
> 

-- 
Ian Campbell


It'll be a nice world if they ever get it finished.

Message #69 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: 658904@bugs.debian.org

Cc: 658759@bugs.debian.org

Subject: Re: u-boot: fails to boot compressed 3.2.y kernels

Date: Sun, 11 Mar 2012 15:50:37 -0500

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

Message #82 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Ben Hutchings <ben@decadent.org.uk>

Cc: 658759@bugs.debian.org, u-boot@packages.debian.org, Davy <purdyd@tds.net>, Donald Gordon <don@dis.org.nz>, Ian Campbell <ijc@hellion.org.uk>, Michael Walle <michael@walle.cc>, Prafulla Wadaskar <prafulla@marvell.com>

Subject: Re: u-boot: fails to boot compressed 3.2.y kernels

Date: Sun, 11 Mar 2012 16:29:53 -0500

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

Message #87 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Ben Hutchings <ben@decadent.org.uk>

To: Jonathan Nieder <jrnieder@gmail.com>, 658759@bugs.debian.org

Cc: 658904@bugs.debian.org

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

Date: Sun, 11 Mar 2012 21:12:41 +0000

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, inline)]

Message #92 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Michael Walle <michael@walle.cc>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: Ben Hutchings <ben@decadent.org.uk>, 658759@bugs.debian.org, u-boot@packages.debian.org, Davy <purdyd@tds.net>, Donald Gordon <don@dis.org.nz>, Ian Campbell <ijc@hellion.org.uk>, Prafulla Wadaskar <prafulla@marvell.com>

Subject: Re: u-boot: fails to boot compressed 3.2.y kernels

Date: Sun, 11 Mar 2012 23:12:18 +0100

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

Message #97 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Ian Campbell <ijc@hellion.org.uk>

To: Jonathan Nieder <jrnieder@gmail.com>, 658759@bugs.debian.org

Cc: Ben Hutchings <ben@decadent.org.uk>, u-boot@packages.debian.org, Davy <purdyd@tds.net>, Donald Gordon <don@dis.org.nz>, Michael Walle <michael@walle.cc>, Prafulla Wadaskar <prafulla@marvell.com>

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

Date: Mon, 12 Mar 2012 08:41:57 +0000

[Message part 1 (text/plain, inline)]

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"

[signature.asc (application/pgp-signature, inline)]

Message #102 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

To: Ian Campbell <ijc@hellion.org.uk>, 658759@bugs.debian.org

Cc: Jonathan Nieder <jrnieder@gmail.com>, Ben Hutchings <ben@decadent.org.uk>, u-boot@packages.debian.org, Davy <purdyd@tds.net>, Donald Gordon <don@dis.org.nz>, Michael Walle <michael@walle.cc>, Prafulla Wadaskar <prafulla@marvell.com>

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

Date: Mon, 12 Mar 2012 10:32:03 +0100

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

Message #107 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Ian Campbell <ijc@hellion.org.uk>

To: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

Cc: 658759@bugs.debian.org, Jonathan Nieder <jrnieder@gmail.com>, Ben Hutchings <ben@decadent.org.uk>, u-boot@packages.debian.org, Davy <purdyd@tds.net>, Donald Gordon <don@dis.org.nz>, Michael Walle <michael@walle.cc>, Prafulla Wadaskar <prafulla@marvell.com>

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

Date: Mon, 12 Mar 2012 09:55:02 +0000

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

Message #112 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Ian Campbell <ijc@hellion.org.uk>

To: 658759@bugs.debian.org

Cc: Jonathan Nieder <jrnieder@gmail.com>, Ben Hutchings <ben@decadent.org.uk>, u-boot@packages.debian.org, Davy <purdyd@tds.net>, Donald Gordon <don@dis.org.nz>, Michael Walle <michael@walle.cc>, Prafulla Wadaskar <prafulla@marvell.com>

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

Date: Mon, 12 Mar 2012 11:25:22 +0000

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.

Message #117 received at 658759@bugs.debian.org (full text, mbox, reply):

From: "purdyd tds.net" <purdyd@tds.net>

To: Ian Campbell <ijc@hellion.org.uk>

Cc: 658759@bugs.debian.org, Jonathan Nieder <jrnieder@gmail.com>, Ben Hutchings <ben@decadent.org.uk>, u-boot@packages.debian.org, Donald Gordon <don@dis.org.nz>, Michael Walle <michael@walle.cc>, Prafulla Wadaskar <prafulla@marvell.com>

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

Date: Thu, 15 Mar 2012 20:03:37 -0500

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

Message #124 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Ian Campbell <ijc@hellion.org.uk>

Cc: 658759@bugs.debian.org, Székelyi Szabolcs <cc@mail.3d.hu>

Subject: Re: [kirkwood] squeeze-backports kernel fails to boot on SheevaPlug

Date: Fri, 24 Aug 2012 00:31:21 -0700

forcemerge 658759 685713
quit

Hi Ian,

Ian Campbell wrote:
> On Thu, 2012-08-23 at 21:50 +0200, Székelyi Szabolcs wrote:

>> Linux version 3.2.0-0.bpo.2-kirkwood fails to boot on the SheevaPlug.
>
> This sounds a lot like
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658904

I agree, so merging.  Any ideas for how to word a hint about this for
the wheezy release-notes?

Thanks,
Jonathan

Message #139 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Ian Campbell <ijc@hellion.org.uk>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: 658759@bugs.debian.org, Székelyi Szabolcs <cc@mail.3d.hu>

Subject: Re: [kirkwood] squeeze-backports kernel fails to boot on SheevaPlug

Date: Fri, 24 Aug 2012 09:44:47 +0100

On Fri, 2012-08-24 at 00:31 -0700, Jonathan Nieder wrote:
> forcemerge 658759 685713
> quit
> 
> Hi Ian,
> 
> Ian Campbell wrote:
> > On Thu, 2012-08-23 at 21:50 +0200, Székelyi Szabolcs wrote:
> 
> >> Linux version 3.2.0-0.bpo.2-kirkwood fails to boot on the SheevaPlug.
> >
> > This sounds a lot like
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658904
> 
> I agree, so merging.  Any ideas for how to word a hint about this for
> the wheezy release-notes?

Hrm, how about:

        The version of u-boot shipped from the factory on many
        kirkwood(???) devices, as well as u-boot shipped in versions of
        Debian prior to Wheezy, contain a bug (#658759) which renders
        them unable to boot kernel versions 3.2(???) or newer. This
        includes the kernel in Wheezy.
        
        Users are advised to upgrade u-boot before upgrading their
        kernel. XXX link to suitable documentation?
        http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html and similar?

(??? fact needs checking). 
-- 
Ian Campbell
Current Noise: Kreator - Mars Mantra

For fast-acting relief, try slowing down.

Message #144 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Ian Campbell <ijc@hellion.org.uk>

Cc: debian-arm@lists.debian.org, debian-boot@lists.debian.org, 658759@bugs.debian.org

Subject: Re: disable l2 cache on kirkwood devices (workaround #658904)

Date: Mon, 10 Sep 2012 23:09:40 -0700

Hi Ian,

On Aug 30, 2012, Ian Campbell wrote:

> I've just tried injecting the following onto the head of the zImage (in
> a similar manner to flash-kernel's set_machine_id function):
[...]
> This works around the issue on my dreamplug (this is effectively the
> same code sequence as what the u-boot fix does).
>
> I can see two ways of distributing this fix. Either a kernel patch gated
> on CONFIG_ARCH_KIRKWOOD to some early bit of code or use devio in
> flash-kernel + the installer build.

Sorry I missed this before.  That sounds like an excellent idea for a
kernel patch.  A kind user on the linux-arm-kernel@ list[1] recently
mentioned he'd be willing to test patches, if you need a guinea pig,
and I assume once a patch is written and tested it should be possible
to get useful feedback from the list.

Thanks,
Jonathan

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

Message #149 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Ian Campbell <ijc@hellion.org.uk>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: debian-arm@lists.debian.org, debian-boot@lists.debian.org, 658759@bugs.debian.org

Subject: Re: disable l2 cache on kirkwood devices (workaround #658904)

Date: Tue, 11 Sep 2012 10:17:23 +0100

On Mon, 2012-09-10 at 23:09 -0700, Jonathan Nieder wrote:
> Hi Ian,
> 
> On Aug 30, 2012, Ian Campbell wrote:
> 
> > I've just tried injecting the following onto the head of the zImage (in
> > a similar manner to flash-kernel's set_machine_id function):
> [...]
> > This works around the issue on my dreamplug (this is effectively the
> > same code sequence as what the u-boot fix does).
> >
> > I can see two ways of distributing this fix. Either a kernel patch gated
> > on CONFIG_ARCH_KIRKWOOD to some early bit of code or use devio in
> > flash-kernel + the installer build.
> 
> Sorry I missed this before.  That sounds like an excellent idea for a
> kernel patch.  A kind user on the linux-arm-kernel@ list[1] recently
> mentioned he'd be willing to test patches, if you need a guinea pig,
> and I assume once a patch is written and tested it should be possible
> to get useful feedback from the list.

My main concern with doing this on the kernel side is that it will
eventually fall foul of the attempts to reduce everything to a single
kernel image, since the code will necessarily be quite kirkwood specific
and run very early on.

Martin's testing of di on ARM[0] suggests this issue isn't all that
widespread, which lead me to conclude that the risk of making a change
like this (either in the kernel or the installer/flash-kernel) for
Wheezy was not worth the chance of breaking some other kirkwood device.

Ian.

[0] https://lists.debian.org/debian-boot/2012/09/msg00052.html


-- 
Ian Campbell
Current Noise: Crowbar - To Build A Mountain

Sex is like air.  It's only a big deal if you can't get any.

Message #154 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Ian Campbell <ijc@hellion.org.uk>

Cc: debian-arm@lists.debian.org, debian-boot@lists.debian.org, 658759@bugs.debian.org

Subject: Re: disable l2 cache on kirkwood devices (workaround #658904)

Date: Tue, 11 Sep 2012 03:57:34 -0700

Ian Campbell wrote:

> My main concern with doing this on the kernel side is that it will
> eventually fall foul of the attempts to reduce everything to a single
> kernel image, since the code will necessarily be quite kirkwood specific
> and run very early on.

Is it possible to do something reasonable if the extra features
register is read first?  (Please forgive my ignorance.)

> Martin's testing of di on ARM[0] suggests this issue isn't all that
> widespread, which lead me to conclude that the risk of making a change
> like this (either in the kernel or the installer/flash-kernel) for
> Wheezy was not worth the chance of breaking some other kirkwood device.

I think that's ok --- the change would be valuable upstream anyway,
and it can filter into mainline and wheezy whenever it has had an
appropriate amount of testing.

Jonathan

Message #159 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Ian Campbell <ijc@hellion.org.uk>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: debian-arm@lists.debian.org, debian-boot@lists.debian.org, 658759@bugs.debian.org

Subject: Re: disable l2 cache on kirkwood devices (workaround #658904)

Date: Tue, 11 Sep 2012 14:27:41 +0100

On Tue, 2012-09-11 at 03:57 -0700, Jonathan Nieder wrote:
> Ian Campbell wrote:
> 
> > My main concern with doing this on the kernel side is that it will
> > eventually fall foul of the attempts to reduce everything to a single
> > kernel image, since the code will necessarily be quite kirkwood specific
> > and run very early on.
> 
> Is it possible to do something reasonable if the extra features
> register is read first?  (Please forgive my ignorance.)

I'm afraid I don't know either. Is this extra features register ARM
architectural or specific to the Kirkwood devices?

I think the cache control registers are implementation defined, so this
code would need to know it is running on a specific set of processors
before it would be safe to run it.

> > Martin's testing of di on ARM[0] suggests this issue isn't all that
> > widespread, which lead me to conclude that the risk of making a change
> > like this (either in the kernel or the installer/flash-kernel) for
> > Wheezy was not worth the chance of breaking some other kirkwood device.
> 
> I think that's ok --- the change would be valuable upstream anyway,
> and it can filter into mainline and wheezy whenever it has had an
> appropriate amount of testing.

Ian.
-- 
Ian Campbell
Current Noise: Faal - My Body Glows Red

A soft drink turneth away company.

Message #166 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Paul Gevers <elbrus@debian.org>

To: 658759@bugs.debian.org

Subject: Re: [kirkwood] squeeze-backports kernel fails to boot on SheevaPlug

Date: Mon, 4 Mar 2019 20:35:40 +0100

[Message part 1 (text/plain, inline)]

Hi all,

On Fri, 24 Aug 2012 09:44:47 +0100 Ian Campbell <ijc@hellion.org.uk> wrote:
> On Fri, 2012-08-24 at 00:31 -0700, Jonathan Nieder wrote:
> > Any ideas for how to word a hint about this for
> > the wheezy release-notes?
> 
> Hrm, how about:
> 
>         The version of u-boot shipped from the factory on many
>         kirkwood(???) devices, as well as u-boot shipped in versions of
>         Debian prior to Wheezy, contain a bug (#658759) which renders
>         them unable to boot kernel versions 3.2(???) or newer. This
>         includes the kernel in Wheezy.
>         
>         Users are advised to upgrade u-boot before upgrading their
>         kernel. XXX link to suitable documentation?
>         http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html and similar?
> 
> (??? fact needs checking). 

This bug is marked as affecting the release-notes. I don't think this is
relevant for stretch or buster anymore? If not, I'll like to remove the
"affects", to not clutter the release-notes bug list.

Paul
PS: please CC me, I am not subscribed to this bug.

[signature.asc (application/pgp-signature, attachment)]

Message #173 received at 658759@bugs.debian.org (full text, mbox, reply):

From: Ben Hutchings <ben@decadent.org.uk>

To: Paul Gevers <elbrus@debian.org>, 658759@bugs.debian.org

Subject: Re: Bug#658759: [kirkwood] squeeze-backports kernel fails to boot on SheevaPlug

Date: Mon, 04 Mar 2019 21:26:28 +0000

[Message part 1 (text/plain, inline)]

On Mon, 2019-03-04 at 20:35 +0100, Paul Gevers wrote:
> Hi all,
> 
> On Fri, 24 Aug 2012 09:44:47 +0100 Ian Campbell <ijc@hellion.org.uk> wrote:
> > On Fri, 2012-08-24 at 00:31 -0700, Jonathan Nieder wrote:
> > > Any ideas for how to word a hint about this for
> > > the wheezy release-notes?
> > 
> > Hrm, how about:
> > 
> >         The version of u-boot shipped from the factory on many
> >         kirkwood(???) devices, as well as u-boot shipped in versions of
> >         Debian prior to Wheezy, contain a bug (#658759) which renders
> >         them unable to boot kernel versions 3.2(???) or newer. This
> >         includes the kernel in Wheezy.
> >         
> >         Users are advised to upgrade u-boot before upgrading their
> >         kernel. XXX link to suitable documentation?
> >         http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html and similar?
> > 
> > (??? fact needs checking). 
> 
> This bug is marked as affecting the release-notes. I don't think this is
> relevant for stretch or buster anymore? If not, I'll like to remove the
> "affects", to not clutter the release-notes bug list.

Again, it should have been mentioned and I don't believe the kernel has
a workaround for this, but it would probably be pointless to mention
now.

Ben.

-- 
Ben Hutchings
A free society is one where it is safe to be unpopular.
                                                      - Adlai Stevenson

[signature.asc (application/pgp-signature, inline)]

Message #180 received at 658759-done@bugs.debian.org (full text, mbox, reply):

From: carnil@debian.org

To: 658759-done@bugs.debian.org

Cc: 658759-submitter@bugs.debian.org

Subject: Closing this bug (BTS maintenance for src:linux bugs)

Date: Sat, 01 May 2021 05:39:21 -0700 (PDT)

Hi

This bug was filed for a very old kernel or the bug is old itself
without resolution.

If you can reproduce it with

- the current version in unstable/testing
- the latest kernel from backports

please reopen the bug, see https://www.debian.org/Bugs/server-control
for details.

Regards,
Salvatore

Send a report that this bug log contains spam.