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.
Thanks,
Paul
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 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.
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.
Thanks,
Paul
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.
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!
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.
Thanks,
Paul
Dear Guang,
Am Montag, den 29.04.2013, 16:56 +0800 schrieb li guang:
在 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 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.
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?
coreboot has its own filesystem for the ROM called CBFS (coreboot filesystem). If I am right, coreboot by default loads the file `fallback/payload` stored in there and jumps to it/executes it [1].
or can you give some hints for code flow? Thanks!
Some talks about coreboot were recorded. Peter Stuge’s talk »2008/12/27 coreboot at 25C3 in Berlin, Germany« linked from [2] is often recommended to watch to get an overview.
[…]
Thanks,
Paul
[1] http://www.coreboot.org/Payloads [2] http://www.coreboot.org/News
The payload is an ELF file. It can be anything that will fit in the flash.
In the beginning, the only payload we supported was a linux kernel. Over the years, we have supported many different payloads, including non-linux kernels, many bootloaders, and even a VM.
The last time I used a kernel as a payload was 2007, on an Ultra 32 box. Worked fine.
All these payloads ran on our initial systems: x86, Alpha, and PowerPC.
A MIPS system does not look like a hard problem.
It is not correct to say that a kernel payload can not fit in 512KB.
ron
OK, Thanks!
在 2013-04-29一的 11:18 +0200,Paul Menzel写道:
Dear Guang,
Am Montag, den 29.04.2013, 16:56 +0800 schrieb li guang:
在 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 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.
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?
coreboot has its own filesystem for the ROM called CBFS (coreboot filesystem). If I am right, coreboot by default loads the file `fallback/payload` stored in there and jumps to it/executes it [1].
or can you give some hints for code flow? Thanks!
Some talks about coreboot were recorded. Peter Stuge’s talk »2008/12/27 coreboot at 25C3 in Berlin, Germany« linked from [2] is often recommended to watch to get an overview.
[…]
Thanks,
Paul
[1] http://www.coreboot.org/Payloads [2] http://www.coreboot.org/News -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Loongson platform be designed mostly like a PC, it also control PCI
devices.
It has just one PCI bus with all devices fixed. That hardly requires the whole complexity of coreboot.
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?
It's simple: coreboot does hardware init, bringing devices to usable state. Payload does everything else.
在 2013-04-29一的 11:19 +0200,Vladimir 'φ-coder/phcoder' Serbinenko写 道:
Loongson platform be designed mostly like a PC, it also control PCI
devices.
It has just one PCI bus with all devices fixed. That hardly requires the whole complexity of coreboot.
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?
It's simple: coreboot does hardware init, bringing devices to usable state. Payload does everything else.
Yes, but, let's say payload is pmon, so, what's the role of coreboot? pmon can do everything, coreboot seems be useless here, isn't it?
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.
OK, some of us just went through this exercise for armv7a and we've decided we're going to help you get this done.
So, the first step is to get a working toolchain via crossgcc. And the first step in that, we found, is to pick the "name" of the CPU. For x86, it was x86 :-)
For our current arm, it was armv7a-eabi.
It needs to be the architecture name known to gcc for this particular architecture and CPU. So what is that for the Loongson?
Once that is done, I'll help you with the next steps. It's not hard, now that we know how it's done.
Thanks
ron
On Mon, Apr 29, 2013 at 1:19 AM, Paul Menzel paulepanter@users.sourceforge.net wrote:
Could you all please read what Vladimir actually wrote and not put something in his mouth!
well, I did. I said i did not want grub2, and the response was, quite simply: "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 don't see my response as either lacking sanity or quasi-fanatical. Do you?
Why is the immediate response to "I don't want it" to assume that i'm not wanting it for reasons of fanaticism?
The »something« makes a difference.
OK, a little history here: we have in the past fit a kernel in 512KB flash. I realize that seems impossible, but it's not. So it makes no sense to rule it out.
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.
Believe it or not, I do understand the need for a payload.
ron