在 2013-04-29一的 12:40 -0700，David Hendricks写道： > On Mon, Apr 29, 2013 at 1:56 AM, li guang <[email protected]> > wrote:
[...] > > A very simplified overview of each stage: > - bootblock is the very first instructions executed by the CPU. It > does very basic CPU setup. It has also been used to detect if the > previous boot succeeded and, if not, select a fallback (or "failover") > firmware to boot. > - romstage usually consists of code which runs before RAM is ready to > use, for example to initialize the DRAM controller interface. > - ramstage consists of everything else. > > > Overall we try to avoid assembly after the bootblock stage. For > romstage, we use a technique called "cache-as-RAM" to exploit the > processor cache (or embedded SRAM, if available) as a temporary > location to set up a stack and run C code. > > > If you're interested in following the code flow for ARMv7, the Snow > mainboard is the current example. Here are the files you should look > at in order of usage: > 1. src/arch/armv7/bootblock.inc: Assembly code which sets ARM chip in > service mode, puts non-bootstrap CPU cores to sleep, initializes > stack. > > > 2. src/arch/armv7/bootblock_simple.c: Generic ARM cache setup, calls > mainboard-specific routines, jumps to romstage > > > 3. src/mainboard/google/snow/bootblock.c: Determine if we are resuming > and can jump to resume vector. > > > > 4. src/mainboard/google/snow/romstage.c: Set up PMIC, clocks, and RAM, > jump to ramstage. x86 platforms will also copy ramstage code into DRAM > at this point for the next stage, but the Exynos5250 CPU on the Snow > mainboard has a large enough embedded SRAM which we continue to use > for ramstage on this platform. > > > 5. src/mainboard/google/snow/ramstage.c: Set up MMU, framebuffer, > exception handler, etc, and load payload. Thanks! follow your pointing, I know execution flow, I want to know why coreboot force to boot a payload? can't we skip this payload(by changing hardwaremain())? or can we write a simple pseudo payload? > > > > > > > > > As I do not know the Loongson/MIPS architecture, I have no > idea if the > > coreboot “framework” is suitable or not for it. From > coreboot’s > > perspective it would be nice if you could spend the time > trying to do a > > Loongson/MIPS port. I also cannot remember if that has been > tried in the > > past. > > > > > seems there's no conflict with coreboot's framework. > > > I tend to agree. The real question is whether it might be useful for > future MIPS-based laptops. I suspect coreboot is overkill for current > MIPS-based products. However, we may see more complex systems where > the Loongson is only a small part of the system as a whole, and where > you may need flexibility to customize for different products with > shared components. > > > ARM is similar in that regard. Fundamentally, ARMv7 setup is very easy > and could be done in a few hundred lines of assembly code. However, > each CPU implementation (ie Exynos5250) includes dozens of peripherals > and each product requires customization. So in that case it's useful > to have a framework which is flexible enough to account for > differences in CPU implementation, mainboard components, and overall > product design. > > > -- > David Hendricks (dhendrix) > Systems Software Engineer, Google Inc. > -- > coreboot mailing list: [email protected] > http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
