I've barely glanced at this so far ... but one question is
how to test this with an existing DM355. (Some of the code
can be reviewed without testing, of course.)
My understanding is that if I run a kernel with these patches,
they'll want a "new style" badblock table, incompatible with
the one understood by current u-boot. So switching to this
code would be a one-way migration (except see option D below).
Which means that testing will pretty much involve not using
the current NAND boot framework. Thus either
(a) loading kernels via JTAG ... CCS only for now, though
maybe there's been progress on the OpenOCD front
(b) or boot from UART or MMC/SD card, sort of awkward ...
(c) new u-boot, replacing old one ... ideally 2009.01
version, ready for mainline u-boot :)
(d) put a different NAND chip in the socket, use that
with (c) ... but supports backward migration, by
putting the old chip there. The UBL might need to
be taught about this different NAND chip.
Is that correct?
- Dave
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
