Unable To Load Kernel 3.2 - Updating to 1.76?


troydenite

Still Fresh
Joined
Jul 25, 2013
Messages
12
So, I ran into a little problem with my CC Pandora - it appears to be one of those defective Craig units that only loads kernel 2.6. There was a bootable SD card that came with the unit, running 1.74 with the old kernel patched in - unfortunately, I didn't actually know this at the time, and managed to wipe the card in a spectacular display of dumb.

This means, of course, that I can't actually flash anything newer than about SZ 1.50 or so.

I understand I can still boot the newer SZ releases from an SD installation, but not having another Pandora, I'm not sure how to create a bootable SD with 1.76 on it. Would anyone be so kind as to help me with this?
 
IIRC you need to download this archive and unpack to the root of an EXT formatted SD card (you can probably use EXT3, but the instruction suggest EXT2, so that's probably safest). If you've got a linux PC or can boot a live image on your PC then you can almost certainly do that with the built-in tools.

There's some more stuff in the README.txt but it's a little out of date; I suspect that wiki link is crusty by now for example. I'd disregard what it says about including a kernel - the last time I did this the image already had a perfectly good kernel inside it, but the boot.txt instructions are needed still.

FWIW, I'm not sure how you can boot a newer kernel from SD if you can't boot the 3.x kernel included in NAND, unless the NAND kernel is from a really old and slightly broken image. In which case updating the NAND would fix it for you, although I can understand doing that without prior testing is a high risk strategy if you think your unit is at all likely to brick itself.
 
Thanks for the reply! I'll try that as soon as I get home. Just to clarify, but by 'updating the NAND,' do you mean by reflashing, or in another way?
 
After a bit of poking around, I was able to extract the archive with the Pandora SD installer and replace the uImage with the old kernel. Everything works great now - only thing is a little battery problem, which I think might be a contact issue. Thanks so much for your help!
 
Interesting. Did you also move/install the older kernel modules (usually in /usr/lib/modules)? The first thing you notice if you've a mismatch there on Pandora is all your PNDs will fail to mount suddenly (actually that's true on most linux machines; I notice that I suddenly can't mount anything - most other drivers I use are already loaded in the old kernel, but on the Pandora we're even more dependent on the loop mount than in most other linux distros).
 
I can't say I did - I'll try that right now. The main issue is that my Pandora refuses to boot from battery, only when charging from mains, which is odd because I've tried a few batteries and I've stuffed almost the entire case with tissue. Not entirely sure what's going on, but hey - guess you can never really trust a first batch. :p

EDIT: I can also boot while plugged in and the battery will show 66%, but then unplug and get an immediate shutdown. Hmm.
 
Last edited:
Do you have the system info pnd from _wb_ installed? It's only rendering the files in /sys/class/power_supply nicely, but it's an excellent way to see things like if the battery is actually charging.

It does sound as if the charge chip in your pandora is a little screwy though. But if it's charging that suggests to me it can get a decent amount of current down the power traces to the battery, so it wouldn't be that.

FWIW, if my memory serves, ISTR two sets of modules in /usr/lib/kernel on my Pandora, so it's possible if you installed the right old kernel you've already got the working set of kernel modules. Moving them from one version to another is extrememly hacky and only something to try if you're really in a hole and need to get the system up to download something better.
 
Alright, so I loaded up System Info and it informed me that the battery was indeed at 93% and that it was in fact charging - notably, however, when I unplugged it from mains, the mwH dropped rapidly from 8 to 0 and the unit shut down. Health was also undetectable. Any ideas?
 
If you're sure the battery is making good contact, I think that narrows it down to a duff charge chip. Reportedly, it's possible to confuse the charge chip to such a degree that it will fry itself if you insert a battery after the unit is already on charge, but I've never actually seen that happen in reality before. But perhaps that has happened here, or perhaps it was always on the verge of failure since manufacture.
 
That does sound like it could be it - I did do that unwittingly a week or so ago. Is there any way to fix it?
 
Not that I know of, but I don't think I've ever heard of anyone successfully bricking their charge chip before.

It doesn't seem completely dead though, given it had a stab at deducing the battery charge presumably from its output voltage, and it still seems to be charging the battery. I think it calculates the battery health primarily on its maximum charge, which it won't have seen yet so it can't make a guess. The fact it shuts off power rather than draining the battery is likely to stop it really learning any more.

It may be looking at your /sys/class/power_supply/bq* folder yourself. While the /sys folder is primarily meant for reading, it usually has some writable files; look using ls -l. My own Pandora is out of action at the moment, but looking at the mains charger of my laptop, I can see writable files called uevent, as well as power/control, power/wakeup, power/async and power/autosuspend_delay_ms. You could try echo 1>power/wakeup for example, assuming the pandora has a similar file of course, which might kick it into behaving better. Any writeable files there are the primary means of controlling system devices like the charge chip.
 
There are indeed files marked uevent, voltage_now, and the like in the /sys/class/power_supply/bq27500-0 folder. When I try to open any one of them, however, I get an error message stating 'Failed to map /sys/class/power_supply/bq27500-0/uevent': mmap() failed: No such device.' This is while the charge light is on, mind you. I'm a bit of a computer newb, so I have no idea what this means.

Thanks so much for your patience, by the way - this is probably the only device on the planet that gets this type of support five years after official discontinuation, and from the community too. :)
 
No problem. I only check here periodically, and if I can help I always like to.

Sounds like driver issues, which could well be the case if you've a kernel and a kernel module mismatch. If you want to actually debug this, do a uname -a to see what kernel you're running then look in /usr/lib/modules to see what modules you've actually availble.
 
Alright, this is going to sound strange, but by changing the boot.txt and directing it at the new kernel, the crashes have somehow stopped - despite the fact that the splash screen still displays kernel 2.6. I'm not entirely sure the problem is solved, but hopefully this is the start of something. Thanks so much for your help so far, and I'll be back with another report after a while. You've been a great help!
 
Good to hear. Maybe your kernel modules match up now. The splash screen by the way is just a png file (or some kind of image) in /etc (or possibly /opt) so won't get changed by a simple change to the kernel pointed out in your boot.txt config. If you want confirmation, 'uname -a' from a terminal should tell you.
 
Back
Top