On Mon, Apr 29, 2013 at 1:56 AM, li guang lig.fnst@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@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.
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.