On Tuesday, August 16, 2011 23:25:35 Simon Glass wrote: > When U-Boot starts up it initializes all the peripherals which are > enabled This might include USB, I2C, SD/MMC, LCD, Ethernet, UARTs, > etc.
i'm not sure about this statement. many frameworks decouple the "register" step from the "initialize the hardware" step. i believe USB, SD/MMC, and Ethernet (ignoring the MAC address issue) do already. arches calling i2c_init() in their arch/*/board.c are broken imo. only a few do it: arm, ppc, m68k. the common "i2c" command already takes care of exposing "i2c reset" for people to init this as necessary, and other arches havent had any troubles that i can see (certainly i know people have used i2c on Blackfin systems from u-boot). a UART gets initialized all the time as it is the serial console ... not much to do here i dont think, and the overhead here tends to be fairly low as you program a few regs without polling for status updates. LCDs should only get initialized if it's the splash screen, otherwise i cant think of any reason that hardware would ever get touched. so if you dont want the overhead of programming that hardware, then dont enable splash screen support ? i cant see a situation where you'd enable splash screen support but not actually show the splash screen ... > To save time, reduce the amount of code executed and thereby improve > security, we are wanting to initialize only some peripherals at the > start. For example we might start up I2C and SC/MMC. this is generally the policy now. init code should only be *registering* the availability of devices. it shouldnt be initializing the actual hardware until requested. i know NAND flashes misbehave, and i posted a few patches to fix that, but there was one or two edge cases that needed addressing before it could be merged. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
