[coreboot] On loongson CPU or MIPS ARCH
li guang
lig.fnst at cn.fujitsu.com
Tue Apr 30 03:38:48 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:
> 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 systems.
>
Yes, I will try to add support of them one by one if it's possible.
>
> 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 platform.
>
>
> 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.
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
More information about the coreboot
mailing list