ubifs/NAND problem?

[Boudewijn]

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>