qtomoko v31 boot ploblems

Gennady Kupava gb at bsdmn.com
Sat Feb 5 19:59:03 CET 2011


В Сбт, 05/02/2011 в 19:31 +0100, Radek Polak пишет:
> Ivan Matveev wrote:
> 
> > So everyone who installs QtMoko v31 to NAND and uses Qi shell have this
> > problem?
> 
> I am personally using this configuration and it works for me. I am wondering 
> why it thinks it's lzo. All qtmoko ubifs images are created with:
> 
> mkfs.ubifs -r /tmp/qtmoko-debian -o qtmoko-debian.ubifs -x zlib -m 2048 -e 
> 126976 -c 2047
> 
> Note the -zlib option. I think your bootloader is ok, because it tries to 
> mount ubi. So the problem is most likely in rootfs NAND partition. Kernel 
> probably reads the compression type (lzo) from your old SHR installation (SHR 
> uses lzo). But i have no idea why.
> 
> Maybe it would be interesting to reflash it and then boot from SD card and 
> check if it's flashed ok by dumping the rootfs NAND partition and comparing 
> with the downloaded image.
> 
> Another option could be booting from SD card and flashing rootfs to NAND with 
> nandwrite, but i have never done this so cant help much.
> 
> Maybe i could still do jffs2 images for stable releases, if that would help.

Hi Radek & Ivan.

I just described why that kernel message appears, wants lzo -> no lzo
module -> no mount -> panic.

Most probably David just did some mistake flashing Qi, kernel or rootfs.
He should first just recheck everything. Othewise for me only
questionable part is bootloader which load some options from some places
and contains some options which only known to person who compiled it.

Booting from SD just attempt to mount you NAND fs is next step to solve
issue. Other alternative is to boot with NAND u-boot with kernel option
and see if it will work. Other alternative to recompile Qi with that
option and see if it will work.

> I am wondering why it thinks it's lzo.

Only idea that this preference is not stored somehow, of it 'attempts'
to use lzo somehow before reading that preference. But this is only wild
guesses.

> Maybe i could still do jffs2 images for stable releases, if that would
help.

IMHO, this is actually bad idea, as UBI is much better from any point of
view, and providing jffs2 version actually will confuse users. Also,
where is no reason for ubi not to work, at least it is good idea to
figure out what is cause of current issue before providing such
'workarounds'.

Best regards,
Gennady.





More information about the community mailing list