While trying to boot the .37 kernel I ran into an interesting problem.
The .37 kernel seems to detect the read-only switch on the SD card slot now, which the old kernel ignored and just assumed it to always be write-enabled.
This wouldn't be much of a problem, but on my pandora it seems to think it's always set to read-only, which causes a kernel panic when booting the kernel rw. (works when giving ro as a bootarg though) This would probably mean the sd card itself can't be written to once the kernel boots, which would mean pnd's wouldn't be able to run.
This far my pandora seems to be the only one to have these problems (as usual :) )
So I'd like to find out if it's just a case of me getting another broken pandora, or that it's a problem with a small number of pandoras, or even a whole batch that's somehow using other hardware.
A simple test is to extract the two files from this archive to an empty ext2 formatted sd card, and boot it.
http://wreck.k-n-p.org/pnd/kernel/kernel37test.zip
what you should see : http://wreck.k-n-p.org/pnd/pnd3/pscreen.jpg (it fails because there are no other files on the sd)
and what i get on my pandora : http://wreck.k-n-p.org/pnd/pnd3/37-kp1.jpeg (you get the same if you flip the switch on the sd card on a pandora where it does boot the kernel)
On 03/22/2011 02:06 AM, aTc wrote:
and what i get on my pandora : http://wreck.k-n-p.org/pnd/pnd3/37-kp1.jpeg
forgot to mention that the important part is the (ro) on the mmcblk0: mmc0: b368 SD 976 MiB (ro) line
hi, on my Pandora I experience correct behavior on your test kernel (as shown on http://wreck.k-n-p.org/pnd/pnd3/pscreen.jpg)
I also tested SD card lock protection: after switching to "lock" position I get http://wreck.k-n-p.org/pnd/pnd3/37-kp1.jpeg
On 2011.03.22 03:06, aTc wrote:
So I'd like to find out if it's just a case of me getting another broken pandora, or that it's a problem with a small number of pandoras, or even a whole batch that's somehow using other hardware.
A simple test is to extract the two files from this archive to an empty ext2 formatted sd card, and boot it.
http://wreck.k-n-p.org/pnd/kernel/kernel37test.zip
what you should see : http://wreck.k-n-p.org/pnd/pnd3/pscreen.jpg (it fails because there are no other files on the sd)
and what i get on my pandora : http://wreck.k-n-p.org/pnd/pnd3/37-kp1.jpeg (you get the same if you flip the switch on the sd card on a pandora where it does boot the kernel)
Firmware-dev mailing list Firmware-dev@openpandora.org http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev
While trying to boot the .37 kernel I ran into an interesting problem.
The .37 kernel seems to detect the read-only switch on the SD card slot
now,
which the old kernel ignored and just assumed it to always be
write-enabled.
This wouldn't be much of a problem, but on my pandora it seems to think
it's
always set to read-only, which causes a kernel panic when booting the
kernel
rw. (works when giving ro as a bootarg though) This would probably mean the sd card itself can't be written to once the kernel boots, which would mean pnd's wouldn't be able to run.
This far my pandora seems to be the only one to have these problems (as usual :) )
So I'd like to find out if it's just a case of me getting another broken
pandora,
or that it's a problem with a small number of pandoras, or even a whole
batch
that's somehow using other hardware.
<snip>
As I mentioned on IRC, I don't see this problem on my devices but assuming it is an issue I'll look into what we can do about disabling the write protect detection in the kernel for the images as it is going to cause all sorts of hard to track issues if this is a problem with more than one or two isolated devices.
If more people can run aTc's test I would appreciate it. It's a lot easier than putting a full image on an SD card just to prove a point ;).
Regards,
John