在 2013-04-29一的 12:40 -0700，David Hendricks写道： > On Mon, Apr 29, 2013 at 1:56 AM, li guang <[email protected]> > 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 > > > > <[email protected]> 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: [email protected] > http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
