why? and NACK the start.S MUST be generic I'll rework the RM9200 code for this too
start.S is not generic already.
but it must not become more board specific with ifdef
what could you suggest instead this?
in your case the prelooder
and answer is: Gemini does NOT execute code from flash after start up. Some hardware copies 2048 bytes of code from flash to internal SRAM memory. After that it starts execute code from SRAM. We must use position independent code before reallocation. But start.S calls some functions, linked below (TEXT_BASE + 0x800) address. This copy loop copies code from 0x0 base address, which in case of Gemini is not Flash, but SRAM. I must add additional offset to copy code from Flash. Flash physical base is 0x30000000. Because of this specific Gemini feature, I must change start.S and create custom linker script. NOTE: this is not Faraday FA526 core specific, this is Gemini SoC specific. Other SoCs with FA526 core may use different boot approach.
so it will be better to use a PRELOADER such as we do for nand or onenand which will boot u-boot
you suggest to use two separate boot loaders? this is bad idea.
it does not
it's not better for users. they will have problems with firmware upgrade and similar.
no
Problem is solved with several code lines in u-boot, and it is working. Additional package (preloader) increases system complexity and decreases reliability. btw, It is not attractive to use u-boot if I need additional loader.
please take a look on the nand_spl and onenand_ipl the preloader is part of u-boot source when you build you u-boot it will result to only one binary with first the preloder and then concat u-boot itself we do this for nand and onenand controler which are allow to download in internal SRAM or so a small piece of code as example on samsung soc for onenand only 2KiB of code
and with what you describe it's clearly the same for you here
Best Regards, J.