No subject
will never happen. The code you are talking about is sometimes identical, sometimes slightly different. In some cases the order is different. I see many ways of introducing breakages. I do agree that doing one architecture at a time is best - with the proviso that we need to pick archs that have the most features (so ARM and PowerPC I suppose) to make sure we are not deluding ourselves as to the simplicity of the task.
So perhaps a generic board init that is the default can be switched off on board-by-board basic would be the right approach. Then we can flick the switch while providing for those affected to still get work done until bugs are reported and found?
Quoted 8 lines
Quoted 5 lines
Generic relocation is used (see previous series) but now rather than calling
relocate_code()to do everything, we call the individual relocation steps one by one. Again this makes it easier to leave things out, particularly for SPL.Note that not all arches need and/or use ELF relocation - Attacking this first does not move towards unity of
board.c
It is a feature used by about half, and it does include the complexity of jumping from pre-reloc to post-reloc init. I think it was a reasonable first target.
Quoted 2 lines
Quoted 2 lines
ARM is a relatively large
board.cfile and one which I can test, therefo=
re
Quoted 3 lines
Quoted 3 lines
I think it is a good target for this series. On the other hand, x86 is relatively small and simple, but different enough that it introduces a few issues to be solved. So I have chosen both ARM and x86 for this seri=
es.
Quoted 17 lines
Quoted 17 lines
The next target should probably be PowerPC, since it is large and has some additional features. I suspect we may want to leave some of these very architecture-specific functions in
arch/powerpc/lib/board.c, taking out only the generic code. I haven't felt a strong need to do this for ARM/x86, but we could even go as far as putting the initcall list into the architecture-specific board file if the architecture adds a lot of unusual calls.A generic
global_datastructure is also required. This might upset a few people. Here is my basic reasoning: most fields are the same, all architectures include and need it, mostglobal_data.hfiles already have =A0#ifdefs to select fields for a particular SOC, so it is hard to see why architecures are different in this area. We can perhaps add a way to put architecture-specific fields into a separate header file, but for now I have judged that to be counter-productive.
Quoted 5 lines
Quoted 3 lines
There was dicussion on the list about passing
gd_taround as a parameter to pre-relocation init functions. I think this makes sense, but it can be done as a separate change, and this series does not require it.This has been raised quite some time ago - The resulting code size increa=
se
Quoted 5 lines
is not worth it. x86 can now emulate the 'gd is a register' so gd is now available and writtable always on every arch. As I said before, gd access is slightly more expensive (one instruction) and initialising the gd pointer is _very_ expensive (rebuilding the Global Descriptor Table) but this only happens three times in total, so I am happy to accept the penal=
ty
Quoted 1 line
for a unified architecture.
OK, well it is a separate change as I said. I see a small code size increase also. Let's worry about that later.
Quoted 11 lines
Quoted 9 lines
While this series needs to stand on its own (as with the link script cleanup series and the generic relocation series) the goal is the unification of the board init code. So I hope we can address issues with this in mind, rather than focusing too narrowly on particular ARM or x86 issues.
Comments welcome. Note that the x86 side of this still needs a fair bit of work, sorry.
The big issue I have is that we now have two RFC's which have major impac=
ts
Quoted 1 line
on x86 and one of us is going to have to give way to the other :)
Well I posted my x86 patches so they are not just sitting in the long grass on my machine. They are not complete, and I would likely need your input on these anyway.
Quoted 4 lines
My patch set is mostly re-factoring and has no impact on anybody else and is practically complete - I'll do one last RFC, but I think it's already close to 'PATCH' status
That's a separate series from my point of view. I can't comment on the wierd x96-isms in the series, but I did read through each patch and it all seems sensible to me.
Quoted 22 lines
Quoted 13 lines
Simon Glass (19):
=A0 Introduce genericglobal_data
=A0 Make relocation functions global
=A0 Add basic initcall implementation
=A0 defineCONFIG_SYS_LEGACY_BOARDeverywhere =A0 Add generic post-relocationboard_r.c
=A0 Add generic pre-relocationboard_f.c
=A0 Add spl load feature
=A0 switch ARM over to generic board
=A0 arm: Remove unused code inboard.c,global_data.h=A0 AddCONFIG_SYS_SYM_OFFSETSto support offset symbols =A0 x86: Remove compiler warning insc520_timer.cQuoted 8 lines
=A0 x86: Remove dead code in eNET
=A0 x86: Add processor library and relocation functions =A0 Tidy up asm/genericsections.hto include x86 symbols =A0 Add fields required by x86 toglobal_data
=A0 x86: Change stub example to useasm-generic/sections.h=A0 x86: Add initial memory barrier macros
=A0 Bring in x86 to unified board architecture =A0 x86: Remove unused board/global_data code
Quoted 2 lines
There are several x86 patches which simply do not belong in this series (and some of which already have non-RFC patches submitted)
OK, these are the warnings I think. Probably I should build without -Werrors and try to ignore them!
Quoted 5 lines
I honestly think we should get the x86 init sequence patches finalised first for several reasons:
=A0- Because x86 is so small, it provides a good test-bed - ELF relocatio=
n
Quoted 4 lines
=A0 was first finalised on x86 (it came and went with varying levels of =A0 success previously)
=A0- They bring x86 in line with other arches re: global data =A0- They are now fully run-tested
No disagreement there, and anyway as you can see the relocation stuff mostly came from your x86 code. It will provide a good template for getting x86 working properly with the generic board init.
What do you need from me to get that through?
Per Wolfgang's request to go with PPC as an early-adopter, this is somewhat in conflict, since as you say, x86 is less feature-full than ARM and much less than PowerPC.
Can anyone recommend a PowerPC board with a quick U-Boot program-run cycle that I can easily get that will let me try out things there?
Regards,
Simon
Quoted 4 lines
Regards,
Graeme