Hi Graeme, On Wed, Mar 14, 2012 at 8:02 PM, Graeme Russ <graeme.r...@gmail.com> wrote: > Hi Simon, > > On Thu, Mar 15, 2012 at 1:50 PM, Simon Glass <s...@chromium.org> wrote: >> Hi Graeme, >> >> On Wed, Mar 14, 2012 at 7:35 PM, Graeme Russ <graeme.r...@gmail.com> wrote: >>> Hi Simon, >>> > > [snip] > >>> >>> IMHO, global data should contain only globally common members and an arch- >>> specific struct and ditch (most of) the #ifdefs >> >> My thinking here was to try to bring everything into a single file. It >> then should be clearer when things are common between different >> architectures. Patches to the generic file can be made without also >> having to patch the non-generic files, etc. >> >> A fair number of the #ifdefs are not needed, or are there because some >> archs don't implement all the features of U-Boot. >> >> You have an example right there: cpu_clk_rate_hz is similar to cpu_clk >> and core_clk. >> >> That said it is a bit of a daunting task to amalgamate them. >> >> Also there is the purely practical consideration that if we continue >> to have an asm/global_data.h then we end up with two global datas. One >> is for CONFIG_SYS_GENERIC_BOARD and contains just the non-common >> fields. The other is for non-CONFIG_SYS_GENERIC_BOARD and contains all >> fields. Ick. >> >> So what do you think? > > Do you really need to unify global data to achieve what the title of the > patch series suggests (i.e. to unify the init processing loop)? Maybe you > could leave global data as is (or slightly tweak the odd arch) and leave > the resolution of just how bad global data is becoming for another day
It's not that easy, because in board_f.c and board_r.c and other files there are certain fields required. It doesn't make a huge amount of sense to have generic code which accesses a different global structure depending on what architecture it is built for. Then there are fields are are only used when certain options are defined. Ick. If I am going to pull this off I need a bit of flexibility. I've looked into this quite a bit and mapped a path through this which I think will work. It requires doing things in stages, or it will never happen. > > I only say this because this is turning into "let's do a dirty hack now to > partially fix it and leave the rest for later (it'll get done, really, > honestly, I promise)" ;) It was always like that. Although I wouldn't characterise it as a dirty hack. If there was a requirement to do all of this in one big bang then I wouldn't have even started. It is just too hard :-( > > There will always be arch specific global data members - I see a few > options: > > - Move them into bd I recall talk of getting rid of this (Mike?) > - Move them into an arch_global_data struct inside gd This was Mike's idea. It is probably the easiest thing to do. > - Move them into an arch_global_data struct totally seperate from gd I sort-of like this except it would slow down access and maybe increase code size. Then again perhaps that's a good thing if it provides an incentive to reduce the number of arch-specific fields. > - Question how many are really required to be in gd (remember, gd is > only there to cart around writable global variable before .bss and > .data are available after relocation) Well yes, I feel there are far more at present than are needed. Having them all there in the open feels like a nice way to draw attention to the mess. Regards, Simon > > Regards, > > Graeme _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
