Hi Benoît,
On Fri, 1 Mar 2013 13:10:40 +0100, Benoît Thébaudeau benoit.thebaudeau@advansee.com wrote:
Factorize start.S code as much as possible.
Functions that may need to be customized for some start.S are defined weak for that purpose.
relocate_code_prepare() and relocate_code_finish() are introduced as hooks to be executed at the beginning and at the end of relocate_code() if needed by some start.S, e.g. for special cache or MMU operations.
NAK.
1. I don't like this idea of planting hooks inside relocate-code(). This function is about relocating code, not about MMU stuff. If there are any MMU steps to be performed between calls to board_init_f(), relocate_code() or board_init_r(), I want them laid out as calls of their own right in crt0.S.
2. If we're going to factorize out relocate_code() from the various start.S files, I want it moved not in crt0.S but in its own file. This way, i) people can easily create binaries which use crt0.S but do not relocate, ii) people who want to make relocate_code() a C function will have it easier, and iii) crt0.S keeps being the ugly ASM glue needed for flash inits, relocation and RAM inits to have a C proper run-time environment.
Incidentally, CC:ing Simon:
Signed-off-by: Benoît Thébaudeau benoit.thebaudeau@advansee.com
Changes in v8:
- New patch.
Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None
Is this produced by patman? If so, is there a way to avoid it? We *know* it's a new patch in v8, so any history pre-v8 here is meaningless.
Amicalement,