new kernel 3.2 does not boot on the dockstar

[davygravy]

kk, again, thanks.

I glanced at a changelog in a Debian kernel package, and it mentioned a switch to xz (lzma2, IIUC). I've been wondering if that could be the problem...

[kmihelich]

Switching away from gzip does seem to help matters, but not entirely. I'm hoping the final 3.3 brings some order back into the world.

[davygravy]

Hmmm... I'm actually running... erhhmm ... ahem... Debian ... on my Dockstar. The standard kernel packages & config use lzma. Debian usually sticks w/ older kernels, so I built my 3.2.y and 3.3-rcN's with the same basic config, using lzma. That didn't work. Neither did gzip. Weird.

[kmihelich]

I had the same results here moving in our 3.1 config to 3.2/3.3, don't be disappointed. Since I don't have the time, I'm just waiting for someone to come across the magic bullet to make it all work.

There isn't a whole lot we really need out of 3.2 though, everything so far has just been requests for new drivers that got included.

[davygravy]

Just an FYI to all kirkwood users...

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

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658759


If anyone has ideas about how to really fix this problem ... please post back, provide a patch we can test, or submit it yourself...

I'll gladly test any proposed patch...

ATM, I'm not really held back by it anymore, as user "Mugabe" at doozan forums showed me the workaround.
$this->bbcode_second_pass_code('', '
root@sandbox:~# uname -r
3.3.0-rc2-kirkwood

') But it will certainly give many users headaches.

[davygravy]

@ kmihelich & any other users : Not 100% sure until I see a fix and it is permanently/durably implemented on _my_ dockstar [ ] , but it looks like the culprit/cause of nonbooting 3.2.y and 3.3-rcN kernels may have been found.

Back in early 3.2rc1, a there was commit in the kernel that enabled ARM_PATCH_PHYS_VIRT by default - IIUC, this enables the L2 cache. The problem is that on kirkwood machines (at least some of them?), the decompressor stub decompressor expects the L2 cache to be disabled.

http://lists.denx.de/pipermail/u-boot/2 ... 17020.html shows some background... and

http://bugs.debian.org/658759 at Debian also has some of the discussion regarding this...

and it would be incomplete without mentioning : https://bugzilla.kernel.org/show_bug.cgi?id=42680 ...

It doesn't seem there is a consensus yet as to whether the "fault/blame" is a regression in the kernel, or a latent bug in u-boot. Hopefully someone will step up soon with either a kernel patch, or a fresh roll of u-boot for any kirkwood machine that needs it.

[kmihelich]

That's interesting.. though I don't think the root cause, since that's not enabled in 3.1 for us and when I brought it into 3.2 I didn't enable it.. unless it enabled it itself. *shrug*

U-Boot is still a very very small possibility in my mind, since my PPv4 U-Boot replacement doesn't care what you do to the kernel.. it boots it. But it could also be that the specific generation/setup of the SoC is what doesn't care. Either way, I'm waiting until someone discovers a definitive fix.. there's no rush.

[davygravy]

$this->bbcode_second_pass_quote('kmihelich', 'T')hat's interesting.. though I don't think the root cause, since that's not enabled in 3.1 for us and when I brought it into 3.2 I didn't enable it.. unless it enabled it itself. *shrug*

U-Boot is still a very very small possibility in my mind, since my PPv4 U-Boot replacement doesn't care what you do to the kernel.. it boots it.

[kmihelich]

I built it based on CE's source dump, which is 1.1.4 with whatever modifications they've done. All we needed was the ext2load return value fix, and some command sets enabled. I'm not sure offhand what Jeff used for the original Dockstar U-Boot, or what was used for UBIT.

The source has all the triggers for building redstone and discovery if you wanted to poke around and see if it makes a difference.

[ax0r7ag0z]

So, I finally got the courage to update and after that butt clenching moment
during boot, where it kinda waits of a couple of seconds, it finally came on!!

The steps I took were:

A kernel update, because i had the 3.1.7 and pacman thought I had
3.2 I "downdated" to 3.1.10 ignoring pacman's prompt to first
update it (it's a mess to figure out, I know ) Before I could do that
I had to remove the old modules from the file system by hand (go figure...)!

$this->bbcode_second_pass_code('', 'rm -r /lib/modules/extramodules-3.1-ARCH
pacman -S linux linux-headers')

then I rebooted just to be safe...

After the reboot, I tried to update pacman

$this->bbcode_second_pass_code('', 'pacman -S')

and got

$this->bbcode_second_pass_code('', 'error: error while reading package /var/cache/pacman/pkg/ca-certificates-20110421-3-any.pkg.tar.xz: Pathname in pax header can't be converted to current locale.
error: failed to commit transaction (invalid or corrupted package)
ca-certificates-20110421-3-any.pkg.tar.xz is invalid or corrupted
Errors occurred, no packages were upgraded.')

so, I did this and got it to update pacman!!
Pay attention to the "export LANG=en_US.UTF-8" part, that got it to work for me!!

So, let's try a

$this->bbcode_second_pass_code('', 'pacman -Syu')

Haha, not so fast!!

$this->bbcode_second_pass_code('', 'error: failed retrieving file 'core.db' from mirror.archlinuxarm.org')

Yup!! Then, I had to edit pacman's mirrorlist

$this->bbcode_second_pass_code('', 'nano /etc/pacman.d/mirrorlist')

hash out

$this->bbcode_second_pass_code('', '##Geo-IP based mirror selection
#Server = http://mirror.archlinuxarm.org/arm/$repo')

and select the closest mirror to me

$this->bbcode_second_pass_code('', 'Server = http://eu.mirror.archlinuxarm.org/arm/$repo')

Then I did a

$this->bbcode_second_pass_code('', 'pacman -Syu')

and was prompted to update to kmod which with a heavy heart I did, crossed my fingers and waited!!
after a somewhat alarming warning

$this->bbcode_second_pass_code('', '[2012-02-12 12:32] udev-compat has been removed, and should be uninstalled.
[2012-02-12 12:32] --
[2012-02-12 12:32] Framebuffers are no longer blacklisted by default.
[2012-02-12 12:32] --
[2012-02-12 12:32] binaries moved from /sbin to /usr/bin
[2012-02-12 12:32] ---------------')

and a reboot, Lo and behold, everything works!!

Hell yeah!!