Dear Simon Glass,
In message CAPnjgZ1Zim6=u3rLcnAKE-0Bw3sO_hRY+U67jkpkNoNi8g7ctw@mail.gmail.com you wrote:
Also it does depend on expectations. I would hope that moving an architecture over would be a fairly small task:
- getting generic relocation working
I don;t see why this would be a direct prerequisite here. We want to have that, no boubt about that. But it appears to be an unrelated change to me.
- adding functions for anything that is missing from board init code
"anything that is missing from board init code" ?
- removing things which don't work on the architecture?
That would probably reander systems broken that need these things?
- worrying about differences in ordering between functions
This is indeed the biggest issue.
Keep in mind that my original ida of providing a function call table was to allow to define this table in a board specific way (i. e. in the board config file).
[Not that this idea found many friends...]
pull out common init code like init_baudrate() and hang() and change the function signatures of the functions that require wrappers and move some #ifdef's into more appropriate locations - One example in board.c:
Well it seems like a lot of work to refactor each arch/xxx/board.c file into functions with a function pointer list, then later remove this code function by function.
Would that really be a clever approach?
My feeling is that with a generic board, it should hopefully be a fairly small amount of work for someone familiar with an architecture to find the bugs and patch the generic code to suit their architecture. It is something that needs to be done once, not every time there is a new patch removing (almost) common code.
It is definitely not that easy. You fix one thing here, and break another board there. Ideally you would have to re-test any change on _all_ boards.
From previous discussions, if something is optional then the switch 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
And I bet most of them _will_ introduce breakages.
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.
I would suggest to attempt to merge ARM into PPC.
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?
Heh! Board specific init tables!
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.
What exactly is the problem here?
Per Wolfgang's request to go with PPC as an early-adopter, this is
No. It's the other way round. PPC is what should be adopted to.
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?
Define "get easily".
Best regards,
Wolfgang Denk