[U-Boot] [PATCH v7 09/11] arm: add customized boot command for Faraday Images

Albert ARIBAUD
2013-09-14T10:28:49Z

Hi Kuo-Jung,

On Mon, 29 Jul 2013 13:51:51 +0800, Kuo-Jung Su <dantesu@gmail.com>
wrote:

> + * At the time of writting, none of Faraday NAND & SPI controllers
> + * supports XIP (eXecute In Place). So the Faraday A360/A369 SoC has
> + * to implement a 1st level bootstrap code stored in the embedded ROM
> + * inside the SoC.
> + *
> + * After power-on, the ROM code (1st level bootstrap code) would load
> + * the 2nd bootstrap code into SRAM without any SDRAM initialization.
> + *
> + * The 2nd bootstrap code would then initialize SDRAM and load the
> + * generic firmware (u-boot/linux) into SDRAM, and finally make
> + * a long-jump to the firmware.
> + *
> + * Which means the SPL design of U-boot would never fit to A360/A369,
> + * since it's usually not possible to alter a embedded ROM code.

Sorry, but I don't see why SPL could not run in SRAM as the 2nd
bootloader in your description; SPL certainly does not try to "alter a
embedded ROM". So, please rewrite the paragraph with the correct reason
why SPL cannot be the 2nd bootloader, e.g., is it

- because the 2nd bootloader is actually in ROM?
- because the SRAM is too small?
- ...

In any case:

> + * And because both the 1st & 2nd level bootstrap code use the private
> + * Faraday Firmware Image Format, it would be better to drop U-boot
> + * image support to simplify the design.

"Drop"? Certainly not. "Introduce a new image format where U-Boot is
prepended with a header defined as follow...", yes -- you can even
make a case that, if SPL cannot be the 2nd bootloader, then SPL is
actually "dropped" for this platform. Please rewrite.

Also: could the whole description and rationale be moved to some
README.* file either arch/arm/cpu/faraday or in doc/ so that readers
oof the C file can see the start of the actual code without having to
scroll through hundreds of comment lines?

Amicalement,
--
Albert.