>> Nick and I have got somewhat further with the E1 build of loon 3s but
>> are still suffering some 2K-page-size-NAND-related problems. Summary of
>> discoveries:
>>
>> - udelay was not implemented in bootldr for PXA so NAND access was
>> sometimes premature (before the NAND was really ready after a command).
>> This explained all the blocks getting marked bad and is now fixed and
>> checked in on the bootldr36-pxa-sa1100 branch. Reading NAND_RNB doesn't
>> yet work because it's not mapped to a register in the FPGA.
>>
>> - checking out latest bootldr source from branch bootldr36-pxa-sa1100,
>> doing the mods for udelay and new FPGA, results in weird yaffs
>> behaviour: We can write a zImage in, but trying to boot it results in it
>> being detected as a BSD kernel image! Upon a reset all the files in
>> yaffs have disappeared.
>>
>> - for comparison, we took an old version of the bootldr from SVN
>> (release 76, before the balloon2/3 to balloon rename took place) and did
>> the same mods. This works properly and yaffs doesn't misbehave. We
>> haven't yet figured out the difference.
>
> Interesting - slightly different problems to the ones I'm having.
>
> I found that the code in branch bootldr36-pxa-sa1100 works OK on 512b
> balloons, and on 2K balloons it works for yaffs write <file> but not
> yaffs load <partition> (partition flash ends up totally blank -
> nothing written at all).
>
> I tried debugging this and broke it completely. :-( (currently my
> small and large builds are 250K bigger than they should be, for two
> different versions of bootldr, thw different chroots and two different
> compilers - very wierd).
>
> One thing that is a pain is that bootldr currently has it's own
> internal c-library and zlib but uses external headers. This is just
> asking for trouble IMHO. I'm moving to using a consistent external set.
>
The problem I had with the external set was .. that it made it 250K bigger
after all the library dependencies were added in.
>> - However, there remains some kernel oddness. The test-v0.1 kernel from
>> balloonboard.org grinds to a halt after initialising the serial ports
>> (it really does stop, not just change baud rate!). Trying a slightly
>> newer kernel and/or a 'known good' one from a random L3 dev board
>> results in most of the NAND getting reported as bad blocks. Nick thinks
>> this is a 2K page implementation issue in the kernel.
>
> I haven't been able to work out if the kernel is working right on 2K because
> I haven't managed to load a rootfs yet...
>
I fixed it (after a while). Changing this->chip_delay in
mtd/nand/balloon3.c from 15 to 50 did the job. This is a similar problem to
my pre balloon2->balloon version of bootldr where to final command byte
(value 0x30 that is only used in 2K NANDs) preceeding an oob read was read
back as the first oob byte, presumably because the NAND was not ready.
I'll put a zImage on the site tomorrow if I get time.
Trying a figure on 20 for chip_delay (as per bootldr but where udelay is a
bit rough and ready) was not enough but 25 was ok.
> Nick - come on IRC if you want to compare notes further.
>
Kids, Friday ... you know.
> Wookey
(text/plain)