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:
>         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
>     > > > <[e-mail]> 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:
> 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.
>     >
>     > 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.