[coreboot] On loongson CPU or MIPS ARCH

David Hendricks dhendrix at google.com
Mon Apr 29 21:40:18 CEST 2013

On Mon, Apr 29, 2013 at 1:56 AM, li guang <lig.fnst at cn.fujitsu.com> wrote:

> Hi, Paul
> 在 2013-04-29一的 10:47 +0200,Paul Menzel写道:
> > Am Montag, den 29.04.2013, 10:19 +0200 schrieb Paul Menzel:
> > > Am Sonntag, den 28.04.2013, 20:21 -0700 schrieb ron minnich:
> > > > On Sun, Apr 28, 2013 at 7:24 PM, Vladimir 'φ-coder/phcoder'
> Serbinenko
> > > > <phcoder at gmail.com> wrote:
> > > >
> > > > > Could we have a sane discussion about why it's not suitable for
> this or
> > > > > that scenario and what would need to be fixed? Not just
> quasi-fanatical
> > > > > "I don't want it".
> > > >
> > > > I guess I missed the part where not wanting something was considered
> insane.
> > >
> > > […]
> > >
> > > Could you all please read what Vladimir actually wrote and not put
> > > something in his mouth!
> > >
> > > »You need something as GRUB for it since the chip is too small
> > > to hold a kernel anyway.«
> > >
> > > The »something« makes a difference.
> > >
> > > He just informed Guang, that he needs a payload, which Guang did not
> > > consider yet. As Vladimir already knows coreboot due to his X201s work
> > > and dealt with Loongson I find it very nice of him to share his
> opinion.
> >
> > Guang, from all of the respondents I probably are the most inexperienced
> > one, so my answers might be incorrect. One of the strong points of
> > coreboot is its PCI initialization framework, the ability to configure
> > it with Kconfig and the ability to customize it
> Loongson platform be designed mostly like a PC, it also control PCI
> devices.

>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

In any case, adding a new architecture to coreboot is an educational
exercise and I highly encourage it if you have the time ;-)

> > because of the payload
> > concept, where coreboot only initializes only the minimum of the
> > hardware and a payload, like SeaBIOS, FILO and GRUB, can take over.
> I'm not quite clear about code flow between bootblock and payload
> for now, so, is there some document about it?
> or can you give some hints for code flow?
> Thanks!

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

5. src/mainboard/google/snow/ramstage.c: Set up MMU, framebuffer, exception
handler, etc, and load 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20130429/6f0a2370/attachment.html>

More information about the coreboot mailing list