Hi,
On 14-06-15 13:31, Boris Brezillon wrote:
Roy, Yassin,
On Mon, 08 Jun 2015 13:35:04 +0200 Roy Spliet r.spliet@ultimaker.com wrote:
Hello Yassin,
Op 08-06-15 om 12:48 schreef Yassin:
Hi Roy Thank you for working on this, I would like to suggest if you could implement separate control commands to switch ECC and Randomisation modes per partitions. I know this is not the best approach but it will provide more controls.
Thanks for the suggestion. However, for now I do not see the immediate need for this in U-boot. U-boot should really only care about one thing: load Linux. Therefore, the only partition it needs to be able to read is whatever partition is used for storing boot data on. And if we only care about one NAND partition, we don't need per-partition settings. I agree that it would be nice to have eventually, but I think this problem first needs to be solved in Linux properly. Then in U-boot we can sync MTD up with Linux and we get the support we need "for free". I'd personally recommend to take this approach over now first hacking up all sorts of new commands in U-boot, as the latter will create more problems with syncing up MTD and doing the right thing on the longer run.
Actually, the more I think about the more I agree with Yassin's suggestion. We currently don't have any standard way to attach a specific setting to a partition (even in Linux, and I hope I'll be able to work on this aspect soon). So for now, I really think we should reuse the existing/standard way of declaring partitions in u-boot (mtdparts + mtdids variables + the mtdparts command) and a sunxi specific commands to configure the ECC and Randomizer config. Once we have settled on something in Linux, we will be able to port it to u-boot and get rid of these sunxi specific command, but in the meantime this will allow us to boot a linux kernel (and even flash an SPL) from u-boot without introducing heavy changes in the u-boot MTD layer.
Ack, note we do not even need any sunxi specific commands, we will have separate nand code for the SPL and uboot itself, since the SPL needs a simple mini read-only implementation. So we can compile the parameters for the boot block vs the rest into the spl resp. uboot binary directly.
Regards,
Hans