How .cb files are created? and what they are used for?
Am 03.01.2011 13:14, schrieb ali hagigat:
How .cb files are created?
Creative work of human beings.
and what they are used for?
All kinds of things.
In case you're wondering (which might qualify you for the creative work mentioned above at least): Yes, these answers are mostly useless - I'm a proponent of the garbage-in-garbage-out principle.
Patrick
LMFAO !!!
"Patrick Georgi" patrick@georgi-clan.de wrote:
Am 03.01.2011 13:14, schrieb ali hagigat:
How .cb files are created?
Creative work of human beings.
and what they are used for?
All kinds of things.
In case you're wondering (which might qualify you for the creative work mentioned above at least): Yes, these answers are mostly useless - I'm a proponent of the garbage-in-garbage-out principle.
Patrick
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
ali hagigat wrote:
How .cb files are created?
As was pointed out already, by hand.
and what they are used for?
Describing fixed parts of a system. What buses there are and what devices are on them.
Please suggest how we can improve the syntax of .cb files. I want them to be self-documenting enough so that you can understand the above from just looking at the files. Can you help?
//Peter
Peter, Thank you. So devicetree.cb files are written by hand and the compilation process does not use them? They are just some information for the developers? About: file:///root/build/coreboot/coreboot-v4/src/mainboard/kontron/986lcd-m/devicetree.cb: #device pci 1e.2 off end # AC'97 Audio It means that AC'97 Audio is on Bus#=1 and Function#=2? But all the devices of the south bridge, ICH7 are on Bus number 0, as far as I know. Why you have not written, Bus number, Function number, Device number, Register number clearly. device pci 1d.0 on end, What does it mean, 1d.0? Regards
On Mon, Jan 3, 2011 at 6:37 PM, Peter Stuge peter@stuge.se wrote:
ali hagigat wrote:
How .cb files are created?
As was pointed out already, by hand.
and what they are used for?
Describing fixed parts of a system. What buses there are and what devices are on them.
Please suggest how we can improve the syntax of .cb files. I want them to be self-documenting enough so that you can understand the above from just looking at the files. Can you help?
//Peter
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Hi ali hagigat,
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of ali hagigat Sent: Tuesday, January 04, 2011 1:30 PM To: coreboot@coreboot.org Cc: peter@stuge.se Subject: Re: [coreboot] .cb files
Peter, Thank you. So devicetree.cb files are written by hand and the compilation process does not use them? They are just some information for the developers? [She, Kerry] no, during the compilation, sconfig will use it to generate the static device tree, Please see util/sconfig, and build/mainboard/kontron/986lcd-m/static.c after your compilation.
About: file:///root/build/coreboot/coreboot-v4/src/mainboard/kontron/986lcd-m/devicetree.cb: #device pci 1e.2 off end # AC'97 Audio It means that AC'97 Audio is on Bus#=1 and Function#=2? But all the devices of the south bridge, ICH7 are on Bus number 0, as far as I know. Why you have not written, Bus number, Function number, Device number, Register number clearly. device pci 1d.0 on end, What does it mean, 1d.0? Regards
On Mon, Jan 3, 2011 at 6:37 PM, Peter Stuge peter@stuge.se wrote:
ali hagigat wrote:
How .cb files are created?
As was pointed out already, by hand.
and what they are used for?
Describing fixed parts of a system. What buses there are and what devices are on them.
Please suggest how we can improve the syntax of .cb files. I want them to be self-documenting enough so that you can understand the above from just looking at the files. Can you help?
//Peter
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
ali hagigat wrote:
So devicetree.cb files are written by hand and the compilation process does not use them? They are just some information for the developers?
Of course not, that would be redundant. As Kerry pointed out, they are very much part of the build process. You can also see this very clearly when watching the make output.
#device pci 1e.2 off end # AC'97 Audio It means that AC'97 Audio is on Bus#=1 and Function#=2?
I don't know about the bus number because you took the above line out of context, but device 0x1e function 2 yes.
But all the devices of the south bridge, ICH7 are on Bus number 0, as far as I know. Why you have not written, Bus number, Function number, Device number, Register number clearly.
Because it is not a list of registers. Device and function is there and bus is implicit, but the file encodes more complex knowledge about the board than simply a list of register/value pairs.
device pci 1d.0 on end, What does it mean, 1d.0?
Device 0x1d function 0. I would hope that this is obvious with a little knowledge about the respective chipset. If you have the lspci next to you I think that devicetree.cb is rather clear.
The bus number is implicit because the file is structured rather than a simple list. The indentation and the "end" keywords try to make this obvious.
Again, please say how you think the information can be structured in a better way.
//Peter
Peter Stuge peter@stuge.se writes:
Of course not, that would be redundant. As Kerry pointed out, they are very much part of the build process. You can also see this very clearly when watching the make output.
#device pci 1e.2 off end # AC'97 Audio It means that AC'97 Audio is on Bus#=1 and Function#=2?
I don't know about the bus number because you took the above line out of context, but device 0x1e function 2 yes.
But all the devices of the south bridge, ICH7 are on Bus number 0, as far as I know. Why you have not written, Bus number, Function number, Device number, Register number clearly.
Because it is not a list of registers. Device and function is there and bus is implicit, but the file encodes more complex knowledge about the board than simply a list of register/value pairs.
The bus number is implicit because the file is structured rather than a simple list. The indentation and the "end" keywords try to make this obvious.
Bus numbers should be a deliberately not specified because in general we need to wait until all of the devices are present both static and dynamic before we can reasonably assign bus numbers. There might be a plugin card with a pci-pci bridge that changes our bus numbering scheme.
Eric
-
ali hagigat -
ebiederm＠xmission.com -
Joseph Smith -
Patrick Georgi -
Peter Stuge -
She, Kerry