ubifs/NAND problem?
Boudewijn
wankelwankel at yahoo.com
Sun Jan 15 23:29:58 CET 2012
On Sunday 15 January 2012 22:53:24 Boudewijn wrote:
> On Sunday 15 January 2012 21:56:04 Ivan Matveev wrote:
> > On Sun, 15 Jan 2012 18:10:11 +0100
> >
> > Boudewijn <wankelwankel at yahoo.com> wrote:
> > > Hi List,
> > >
> > > I have problems with NAND, it seems, but I don't know how to
> > > troubleshoot it.
> > >
> > > For a while I have been unable to boot SHR from NAND, but since I had
> > > another install on uSD, it didn't really matter. Lately I wanted to
> > > move to NAND anyway, to free up the relatively fast uSD for my
> > > Phoenux.
> > >
> > > The Freerunner still won't boot from NAND though. I reflashed with
> > > SHR-core (and SHR's ubi-qi), to no avail. After that I flashed QtMoko
> > > v35 (and QtMoko's qi v35). No better result either. (For a moment I
> > > thought the MD5 sum was incorrect, downloaded again and flashed, but
> > > it turned out Sourceforge hid part of the sum when there's no
> > > mouseover).
> >
> > Hi Boudewijn,
> > I had a similar problem, couldn't boot anything from NAND(qi or uboot
> > the same). Jffs worked fine.
> > While trying different UBIFS distributions I have accidently flashed
> > kernel to where bootloader should be. Reflashed everything as it should
> > be, and the phone started to boot from NAND.
> > The distrib was QtMoko v35.
> > I think there could be some wrong data or bad blocks somewhere that
> > were erased by flashing kernel to the wrong place. Or some bug was fixed
> > in qi or kernel. Cant check.
>
> Thanks for the suggestion! I actually started writing as a follow-up to
> your thread, but since you started out with v36 and ended with v35 I
> started a new one (I started with v35 a couple of times right away)
>
> If I understand correctly, you now use UBI, not jffs, don't you?
>
> If all goes well, I can send "success" in a couple of minutes :-)
What I did:
- flash kernel partition with random 27-meg PDF
- flash boot partition with kernel image
- "boot" in u-boot (NOR)
--> wrong image, returning to u-boot-menu
- "reboot" in u-boot (NOR)
--> booting SHR from uSD using Qi
--> Qi is not broken? I have not patched my u-boot (NOR) in any way to cope
with large kernels or other filesystems.
I used neotool for flashing. It seems it did not flash the kernel partition:
bytes_per_hash=539430
Copying data from PC to DFU device
Starting download: [Resetting USB to switch back to runtime mode
(there are no hashes showing the download, so maybe nothing is downloaded)
Some data got downloaded to the boot partition, but fewer hashes (of more
bytes) than usual:
bytes_per_hash=44949
Copying data from PC to DFU device
Starting download: [#####Resetting USB to switch back to runtime mode
On second try, I used a PDF of 3 MB for the kernel partition, and a <1 MB PDF
for boot.
This time the "kernel" downloaded as supposed, and the "boot loader" has "more
hashes", but Qi runs anyway.
Third time I skipped the kernel partition, and downloaded a 40k-log as boot
loader. That gave a long enough hash-line ("smaller hashes", of course). Funny
enough, this time DFU-util exited with an error (Thanks Thormod/Stephan!):
bytes_per_hash=806
Copying data from PC to DFU device
Starting download: [##################################################]
finished!
state(10) = dfuERROR, status(1) = File is not targeted for use by this
device
Finally I downloaded the QtMoko-files (kernel v35 and qi v35), removed USB and
battery, reconnected power supplies and sat back. SHR. No offense, SHR is nice
enough ;-) But not what I had in mind for tonight.
I did notice something I was looking for earlier on the u-boot screen. The
DFU-util log says:
Starting Atomic DFU DOWNLOAD to partition 'u-boot'
device 0 offset 0x40000, size 0x40000
....(BBT address? Too slow typing to catch it before FR shut down)...
At least I got some offset for dev 0 now, but I come to realize that it's not
UBI at all, so no gain here.
Sorry for the long story.
TL;DR:
I overwrote my boot partition and kernel partition with useless (in this
context) data multiple times. I expected Qi to break at some point, but it
didn't. It also did not become "unbroken": it refuses to boot the kernel in
NAND.
Any pointer?
Boudewijn
PS: For now I'll start reading about u-boot on the wiki.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmoko.org/pipermail/community/attachments/20120115/7d839857/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1967 bytes
Desc: not available
URL: <http://lists.openmoko.org/pipermail/community/attachments/20120115/7d839857/attachment.bin>
More information about the community
mailing list