Re: [coreboot] On loongson CPU or MIPS ARCH

[li guang]

在 2013-04-29一的 12:40 -0700，David Hendricks写道：
> On Mon, Apr 29, 2013 at 1:56 AM, li guang 
> 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:
> src/arch/armv7/bootblock.inc: Assembly code which sets ARM chip in
>
> service mode, puts non-bootstrap CPU cores to sleep, initializes
> stack.
> src/arch/armv7/bootblock_simple.c: Generic ARM cache setup, calls
>
> mainboard-specific routines, jumps to romstage
> src/mainboard/google/snow/bootblock.c: Determine if we are resuming
>
> and can jump to resume vector.
> 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.
> 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.