[coreboot] On loongson CPU or MIPS ARCH

li guang lig.fnst at cn.fujitsu.com
Tue Apr 30 04:37:03 CEST 2013


在 2013-04-29一的 12:40 -0700,David Hendricks写道:
> On Mon, Apr 29, 2013 at 1:56 AM, li guang <lig.fnst at cn.fujitsu.com>
> 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: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot





More information about the coreboot mailing list