On Sunday, February 10, 2013 1:02:58 AM, Benoît Thébaudeau wrote:
Dear Marek Vasut,
On Sunday, February 10, 2013 12:24:04 AM, Marek Vasut wrote:
Dear Benoît Thébaudeau,
On Saturday, February 9, 2013 2:53:44 PM, Benoît Thébaudeau wrote:
On Saturday, February 9, 2013 12:47:25 AM, Benoît Thébaudeau wrote:
On Friday, February 8, 2013 11:49:27 PM, Benoît Thébaudeau wrote:
Subject: [PATCH v5 8/8] nand: mxc: Switch NAND SPL to generic SPL
Signed-off-by: Benoît Thébaudeau benoit.thebaudeau@advansee.com
Changes in v5:
- Remove spaces between function name and open parenthesis.
- Fix mx31pdk and tx25 Makefile-s and SPL linker scripts.
- Remove the useless definition of CONFIG_SPL_LDSCRIPT.
- Fix the call to nand_boot().
Changes in v4:
- New patch.
Changes in v3: None Changes in v2: None
This is now supposed to be working and compile-tested.
Custodians, please review and advise.
Board maintainers, please test.
Tell me if I should split away some stuff.
Should doc/README.arm-relocation be updated, and how since tx25 no longer uses NAND SPL, which is also deprecated?
Note that mx31pdk and tx25 had been broken by commit e05e5de7fae5bec79617e113916dac6631251156. After this commit, for those boards, _main called board_init_f, which called relocate_code, which unexpectedly (for their users) returned to nowhere in ctr0.S instead of calling nand_boot. Also, crt0.S calls nand_boot if CONFIG_SPL_BUILD is not defined but CONFIG_NAND_SPL is, which is not normal for NAND SPL. Other NAND SPL boards may be broken too, but that's not too much of an issue since they are supposed to migrate to generic SPL.
I am also wondering if board_init_f should not be moved out of mxc_nand_spl.c to either <board>/lowlevel_init.S or <board>/<board>.c. That would make mxc_nand_spl.c more generic if for some reason a board needs to do specific things. Any opinion?
For the start.S files, since it's not possible to know from CONFIG_SPL_BUILD and CONFIG_NAND_SPL if relocate_code is needed or not, I see the following choices:
- Let it defined in all cases. It's quite small, so it won't hurt
much. 2) Create a specific SPL #define (e.g. CONFIG_SPL_RELOCATE_CODE) to define it
for generic SPL only if needed.
- Just create a specific linker section for it so that it's
automatically
garbage-collected if unneeded.
Any opinion?
How much of start.S can be actually rewritten in pure-C ?
I would say only relocate_code(). Apart from this function, start.S only deals with preprocessor register accesses and IRQ / exception handling that require assembly.
s/preprocessor/coprocessor/
As to relocate_code(), it would still be tricky in pure C because it mixes absolute addresses with position-independent code and data accesses, so one would have to be very careful about the C coding of this function in order to avoid a dependency on compiler choices. Having it written in assembly guarantees a correct result and emphasizes the absolute/relative access constraints for easier maintenance.
But this is only my opinion.
Best regards, Benoît