Hi all,
I managed to create a pdf from http://coreboot.org/viewvc/coreboot-v3/doc/design/newboot.lyx by now.
It got some basic formatting only (no page numbers, no index, some unbroken lines). It lacks the images. But it is readable.
lyx used 433 MB of disk space for compilation, Qt asked for 1.6 GB (632 MB after make clean). Thus I'd like to suggest: please do provide an output format which is made for readability whenever possible (PDF, HTML). There's no need for everyone to install lyx.
I had a first glance at the docu. I got a much better insight now, although it seems to be written for people which know v2 and its basics. Carl-Daniel suggested to send some feedback here about how it could be improved.
What I missed most: If there's a ready solution for a motherboard, there´s no need to read this docu at all. It should run almost on its own.
There's no explanation how to build new devices and especially how to add a new motherboard. Very much seems to run automatically on one hand - and on the other hand coreboot claims that it wants to build a minimum BIOS only since all of the other initialisation should be done within the kernel.
Thus I do not know: which are the minimum requirements which I have to define. How may I begin. How may I test the inital setup and collect debugging information which does show me conflicts, devices, links, addresses, whatever.
Personally, I do not have any idea how to build a new motherboard definition from scratch. But fortunately I may take one of the Geode LX boards and try to find out which might suit me best for a Geode GX design. I do not know whether I have to build everything perfectly at once or how I may proceed step by step to debug my files and reach a final solution.
Much, much later on I might ask how to add this design to the coreboot tree...
Thanks, Martin
Hi Martin,
On Thu, Mar 13, 2008 at 01:10:06PM +0100, Martin Trautmann wrote:
lyx used 433 MB of disk space for compilation, Qt asked for 1.6 GB (632 MB after make clean).
This is unacceptable.
Thus I'd like to suggest: please do provide an output format which is made for readability whenever possible (PDF, HTML). There's no need for everyone to install lyx.
Agreed. Yesterday I emerged lyx, generated a PDF and have just this minute uploaded it and added a link on the http://www.coreboot.org/Coreboot_v3 page.
//Peter
On Thursday 13 March 2008 13:20, Peter Stuge wrote:
On Thu, Mar 13, 2008 at 01:10:06PM +0100, Martin Trautmann wrote:
lyx used 433 MB of disk space for compilation, Qt asked for 1.6 GB (632 MB after make clean).
This is unacceptable.
Thus I'd like to suggest: please do provide an output format which is made for readability whenever possible (PDF, HTML). There's no need for everyone to install lyx.
Agreed. Yesterday I emerged lyx, generated a PDF and have just this minute uploaded it and added a link on the http://www.coreboot.org/Coreboot_v3 page.
Uhhh, we must remove the bottom text (the reset part) of this page as it contains information that isn't valid for coreboot. I wasn't able to remove it, because login timed out.
Juergen
Peter Stuge wrote:
Agreed. Yesterday I emerged lyx, generated a PDF and have just this minute uploaded it and added a link on the http://www.coreboot.org/Coreboot_v3 page.
Thanks! It does not show the image(s), but is readily available now.
On Thu, Mar 13, 2008 at 01:10:06PM +0100, Martin Trautmann wrote:
What I missed most: If there's a ready solution for a motherboard, there´s no need to read this docu at all. It should run almost on its own.
Hmm, what do you mean by ready solution?
This is intended to be a design document, not the user's guide. I would like to have some kind of user's guide as well, but since we aren't really finished with the v3 design yet I think time is better spent elsewhere for now.
There's no explanation how to build new devices and especially how to add a new motherboard. Very much seems to run automatically on one hand - and on the other hand coreboot claims that it wants to build a minimum BIOS only since all of the other initialisation should be done within the kernel.
Devices and boards live in the northbridge,southbridge,superio and mainboard subdirectories respectively, in a vendor/device dir.
"Simple" PCI devices don't need custom initialization. v3 has generic PCI code that will do enough. Buses (bridges) need to be initialized, and they are usually part of the north- or southbridge.
Thus I do not know: which are the minimum requirements which I have to define. How may I begin. How may I test the inital setup and collect debugging information which does show me conflicts, devices, links, addresses, whatever.
Excellent question. The problem is that there is no generic answer since most PC hardware out there has unique creative ideas on how to get a competitive edge.
Personally, I do not have any idea how to build a new motherboard definition from scratch.
My goal is for a board definition in v3 to only consist of data. I think this is an attainable goal, we are not far from it.
The board is described by a dts file, which says what components are on it and the addresses they have, and an irq_tables.h file which describes the interrupt routing. Ideally I would like the interrupt routing to go into the dts, but I don't yet know if it's possible or how it should look. I'll think more about this for the first K8 board in v3.
I want the dts to be postprocessed bom+netlist and eventually have a tool to do it automatically.
But fortunately I may take one of the Geode LX boards and try to find out which might suit me best for a Geode GX design. I do not know whether I have to build everything perfectly at once or how I may proceed step by step to debug my files and reach a final solution.
Everything most certainly does not have to be perfect at once, what you do need to get right is completely device specific.
Much, much later on I might ask how to add this design to the coreboot tree...
What design? Do you mean how to contribute back the mainboard? The procedure for that is actually documented already: :) http://www.coreboot.org/Development_Guidelines
Hope this helps.
//Peter