Dear Simon Glass, In message <CAPnjgZ1Zim6=u3rlcnake-0bw3so_hry+u67jkpknoni8g7...@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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de People have one thing in common: they are all different. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot