On 2006-10-06 16:07 +0100, Chris Jones wrote:
> 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.
 
> - 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...

Nick - come on IRC if you want to compare notes further.

Wookey
-- 
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK  Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/                 play: http://wookware.org/