<div dir="ltr">On Mon, Apr 29, 2013 at 1:56 AM, li guang <span dir="ltr"><<a href="mailto:lig.fnst@cn.fujitsu.com" target="_blank">lig.fnst@cn.fujitsu.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi, Paul<br>
<br>
在 2013-04-29一的 10:47 +0200，Paul Menzel写道：<br>
<div class="im">> Am Montag, den 29.04.2013, 10:19 +0200 schrieb Paul Menzel:<br>
> > Am Sonntag, den 28.04.2013, 20:21 -0700 schrieb ron minnich:<br>
> > > On Sun, Apr 28, 2013 at 7:24 PM, Vladimir 'φ-coder/phcoder' Serbinenko<br>
> > > <<a href="mailto:phcoder@gmail.com">phcoder@gmail.com</a>> wrote:<br>
> > ><br>
> > > > Could we have a sane discussion about why it's not suitable for this or<br>
> > > > that scenario and what would need to be fixed? Not just quasi-fanatical<br>
> > > > "I don't want it".<br>
> > ><br>
> > > I guess I missed the part where not wanting something was considered insane.<br>
> ><br>
> > […]<br>
> ><br>
> > Could you all please read what Vladimir actually wrote and not put<br>
> > something in his mouth!<br>
> ><br>
> > »You need something as GRUB for it since the chip is too small<br>
> > to hold a kernel anyway.«<br>
> ><br>
> > The »something« makes a difference.<br>
> ><br>
> > He just informed Guang, that he needs a payload, which Guang did not<br>
> > consider yet. As Vladimir already knows coreboot due to his X201s work<br>
> > and dealt with Loongson I find it very nice of him to share his opinion.<br>
><br>
> Guang, from all of the respondents I probably are the most inexperienced<br>
> one, so my answers might be incorrect. One of the strong points of<br>
> coreboot is its PCI initialization framework, the ability to configure<br>
> it with Kconfig and the ability to customize it<br>
<br>
</div>Loongson platform be designed mostly like a PC, it also control PCI<br>
devices.<br></blockquote><div><br></div><div style>From what Vladimir mentions, the Yeeloong netbook implementation seems very simple. Do you intend to add support for more complicated platform? As Ron pointed out, coreboot's framework provides a lot of flexibility which might be useful if you intend to support more Loongson (or other MIPS) based systems.</div>

<div style><br></div><div style>In any case, adding a new architecture to coreboot is an educational exercise and I highly encourage it if you have the time ;-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div class="im"><br>
> because of the payload<br>
> concept, where coreboot only initializes only the minimum of the<br>
> hardware and a payload, like SeaBIOS, FILO and GRUB, can take over.<br>
<br>
</div>I'm not quite clear about code flow between bootblock and payload<br>
for now, so, is there some document about it?<br>
or can you give some hints for code flow?<br>
Thanks!<br></blockquote><div><br></div><div style>A very simplified overview of each stage:</div><div style>- 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.</div>

<div style>- romstage usually consists of code which runs before RAM is ready to use, for example to initialize the DRAM controller interface.</div><div style>- ramstage consists of everything else.</div><div style><br></div>

<div style>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.</div>

<div style><br></div><div style>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:</div><div style>1. src/arch/armv7/bootblock.inc: Assembly code which sets ARM chip in service mode, puts non-bootstrap CPU cores to sleep, initializes stack.</div>

<div style><br></div><div style>2. src/arch/armv7/bootblock_simple.c: Generic ARM cache setup, calls mainboard-specific routines, jumps to romstage</div><div style><br></div><div style>3. src/mainboard/google/snow/bootblock.c: Determine if we are resuming and can jump to resume vector.<br>

</div><div style><br></div><div style>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.</div>

<div style><br></div><div style>5. src/mainboard/google/snow/ramstage.c: Set up MMU, framebuffer, exception handler, etc, and load payload.<br></div><div style><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div class="im"><br>
><br>
> As I do not know the Loongson/MIPS architecture, I have no idea if the<br>
> coreboot “framework” is suitable or not for it. From coreboot’s<br>
> perspective it would be nice if you could spend the time trying to do a<br>
> Loongson/MIPS port. I also cannot remember if that has been tried in the<br>
> past.<br>
><br>
<br>
</div>seems there's no conflict with coreboot's framework.<br></blockquote><div><br></div><div style>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.</div>

<div style><br></div><div style>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.</div>

</div><div><br></div>-- <br>David Hendricks (dhendrix)<br>Systems Software Engineer, Google Inc.
</div></div>