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.thebaud...@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: > 1) 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. > 3) Just create a specific linker section for it so that it's automatically > garbage-collected if unneeded. > Any opinion?
I'm also considering to factorize relocate_code to crt0.S. There's not really a good reason for it to be depending on each ARM processor. Any opinion? Best regards, Benoît _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot