Dear Simon Glass, In message <CAPnjgZ1eutEboyvEtYcxcZcv=1z_3tkq_45wbrgndpsnxrt...@mail.gmail.com> you wrote: > > >> - getting generic relocation working > > > > I don;t see why this would be a direct prerequisite here. =A0We want to > > have that, no boubt about that. =A0But it appears to be an unrelated > > change to me. > > I don't think it's essential, but it is desirable, which I why it is > on the list.
I recommend to put this on a different list. Please keep changes orthogonal and restict this discussion and patch series to things dealing with the normalization of the board init code. This is complicated enough, and it does not good to include additional, unrelated tasks. > >> - adding functions for anything that is missing from board init code > > > > "anything that is missing from board init code" ? > > By that I mean that if the architecture has its own little things > which aren't supported by generic board init, then these would need to > be worked into the generic board init somehow, perhaps initially with > a new function in the initcall list. Such an approach will most probable result in a mess of code that is even more dificult to maintain than the current split we have now. > >> - removing things which don't work on the architecture? > > > > That would probably reander systems broken that need these things? > > Sorry for being so vague. What I mean is that if an arch does not > support a feature, then we don't want to call the init functions for > it on that architecture. Sometimes this is handled automatically - > e.g. if an arch does not support CONFIG_POST then the generic board > init code will skip this anyway. But there may be other cases where > features available in the generic board init cannot be supported in > all archs. This is the same problem as above, right? Each architecture, and actually each board may or may not require certain initializations, and actually may require them to happen in a certain order (which may be different from other boards). > > 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...] > > With this series I have moved over to purely having a function call > table, with no actual init code in board_init_f() and board_init_r(). This was the original plan. > Having done this, I have found that the list of functions is very > long, So we probably don't want boards to duplicate this list and > #ifdefs may be the lesser of two evils. If we can move to Graham' I don't really see this as an practical approach. Did you look at the PPC code? init_sequence[] has a total of 29 entries, "decorated" with 21 conditionals. If we merge in ARM and x86, we will have a mess nobody is able to understand. > For now I have tried to simply move the code into separate functions, > since this makes it easier to compare against the original code in the > arch/xxx/lib/board.c files, to make sure nothing is left out and the > ordering is OK. Agreed. > I'm not convinced it is the best idea. A trivial change of just > removing duplicated code from all the archs and inserting it into > generic board should be safe enough. But is that really a common case? > I have found lots of subtle differences that need to be worked out, > and there is the ordering to worry about. Every time there is a patch > we need to re-test all boards. It might be easier to just create a > generic board implementation one, and then test it once on each board, > rather than testing on each board with every patch. Of course every > time you patch generic board you might introduce a breakage in an > existing (previously working) board, but that is the normal situation > with development so I don't see a problem there. > > Perhaps the biggest problem is the difficulty of testing, and if we > can avoid months of little patches (each one potentially breaking lots > of boards at run-time) then I would prefer that. I am not sure that the whole approach makes sense. The resulkting mess of #ifdef's is not there because people didn't care, but because of very specific requirements of specific hardware, that - at least given the tools of the respective point of time - could not be solved more efficiently. I see two options here: - We can take the existing code and try to unify it, and make all boards (including a large number of EOLed and unmaintained ones) to that new code base. This will be a lot of work, and the resulting code will probably messy again. - We could as well try to come up with a new, cleaned up implementa- tion that maybe doesn't fit all, but only 80 or 90% of the existing boards. We could then (1) convert existing code step by step to the new implementation and (2) accept new submissions only when using the new code. There may be a number of boards where conversion is non trivial, or where nobody is willing or able to perform the changes and / or the testing. My gut feeling tis that this would be a relatively small number of boards, and mostly old and unmaintained ones. We might give them some grace period and then remove them. > Well I suppose that's what I'm saying. Doing this once, accepting that > some boards will thereby be broken, and then accepting patches to fix > them feels easier than trying to keep everything working through a > long series of little changes. You appear to assume that onlly a small percentage of boards would be broken. My expectations are different. Intentionally causing breakage may be useful here and there, but I don;t think it;s the right thing here. > >> 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? > > The problem is the code duplication inherent in relocation - each > architecture has its own way of doing it, but really it can mostly be > written generically in C. ARM is even worse with each CPU implementing > essentially the same code! I suggect we leave relocation out of this discussion here. It is an area that needs to be cleaned up, definitely. But it is another, unrelated topic. 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 "No problem is so formidable that you can't walk away from it." - C. Schulz _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
