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?

>
>> 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.

>
>> ARM is a relatively large board.c file and one which I can test, therefo=
re
>> 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.
>>
>> 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_data structure 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, most global_data.h files 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.
>>
>> There was dicussion on the list about passing gd_t around 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
> 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
> 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.

>
>> 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
> 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.

>
> 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.

>
>> Simon Glass (19):
>> =A0 Introduce generic global_data
>> =A0 Make relocation functions global
>> =A0 Add basic initcall implementation
>> =A0 define CONFIG_SYS_LEGACY_BOARD everywhere
>> =A0 Add generic post-relocation board_r.c
>> =A0 Add generic pre-relocation board_f.c
>> =A0 Add spl load feature
>> =A0 switch ARM over to generic board
>> =A0 arm: Remove unused code in board.c, global_data.h
>> =A0 Add CONFIG_SYS_SYM_OFFSETS to support offset symbols
>> =A0 x86: Remove compiler warning in sc520_timer.c
>> =A0 x86: Remove dead code in eNET
>> =A0 x86: Add processor library and relocation functions
>> =A0 Tidy up asm/generic sections.h to include x86 symbols
>> =A0 Add fields required by x86 to global_data
>> =A0 x86: Change stub example to use asm-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
>
> 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!

>
> 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
> =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

>
> Regards,
>
> Graeme