On Mon, Feb 6, 2012 at 12:27 PM, Mike Frysinger <vap...@gentoo.org> wrote: > On Monday 06 February 2012 09:49:27 Tom Rini wrote: >> On Mon, Feb 6, 2012 at 1:43 AM, Graeme Russ wrote: >> > On 02/06/2012 06:51 PM, Wolfgang Denk wrote: >> >> Graeme Russ wrote: >> >>> I think the immediate focus should be on centralising the init sequence >> >>> processing into /common/init.c and then bringing the new'initcall' >> >>> architecture online >> >> >> >> Agreed. >> >> >> >>> Once these have been done, any board can just specific: >> >>> >> >>> SKIP_INIT(RELOC) >> >> >> >> I will probably object to his, too - for the same reasons. >> > >> > Considering this is a 'free' artefact of how the init sequence functions, >> > and that it is board specific and totally non-invasive for anyone else >> > (i.e. no ugly ifdef's anywhere else in the code) I'm surprised you would >> > object... >> >> To pick up Wolfgang's argument, but why do we want to skip relocation? >> You can debug through it, it's documented (official wiki has GDB, >> over in TI-land, the wiki page for CCS has the bits for doing it in >> that Eclipse-based env, other debuggers I'm sure have a similar "now >> add symbols at this offset from link" option) and the end result makes >> it very easy for end-users to break their world (default kernel load >> addrs being where U-Boot would be). > > if you have a static platform which never changes, isn't the relocation a > waste of time ? i can understand wanting relocation by default for platforms > where memory sizes are unknown, but it's not uncommon for people to have fixed > hardware when they deploy. > > although, with SPL picking up direct-to-Linux booting, this argument might not > matter that much anymore.
Yes, there's lots of tricks a deployment system can take to speed things up, and I agree, SPL loading Linux will make some of these less desirable. -- Tom _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
