multiple links. The way this was done in v2 was a big confusing; this way is
less so.
The changes are easy. Getting them right has been hard :-)
First, for a k8 north that has three links, you can name each one as follows:
pci0@18,0
pci1@18,0
pci2@18,0
We have to have the same pcidevfn on these because that is how the k8 works.
But the unit numbers (pci0, pci1, etc.) distinguish them.
The dts will properly generate a "v3 device code"
compatible static tree that puts the links in the right place in the
data structure.
The changes to dts are trivial.
As before, dts nodes with children are understood to be a bridge.
But what if there is a dts entry like this:
pci1@18,0 {/config/("northbridge/amd/k8/pci");};
This entry has no children in the dts.
How does dt compiler know it is a bridge? It can not know unless
we add information to the dts for that northbridge part.
To ensure that all bridge devices are detected, we support the following:
if a dts node for a device has a bridge property, e.g.:
{
device_operations = "k8_ops";
bridge;
};
The dt compiler will treat it as a bridge whether it has children or not.
Why would a device not have children? Because it might be attached to a
pci or other socket, and we don't know at build time if the socket is empty,
or what might be in the socket.
This code has been tested on dbe62 and k8 simnow, and works on each.
It is minimal in size and it does what we need. I hope it resolves our
discussion for now. We might want to improve or change the device code
later but, at this point, forward motion is important -- I'm on a deadline for
a very important demo Oct. 22!
Also included in this patch are new debug prints in k8 north.
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
git-svn-id: svn://coreboot.org/repository/coreboot-v3@865 f3766cd6-281f-0410-b1cd-43a5c92072e9
This is necessary for the 'unwanted_vpci' field on geode-based boards.
Signed-off-by: Ward Vandewege <ward@gnu.org>
Acked-by: Jordan Crouse <jordan.crouse@amd.com>
git-svn-id: svn://coreboot.org/repository/coreboot-v3@661 f3766cd6-281f-0410-b1cd-43a5c92072e9
/config/ = "northbridge/amd/geodelx";
Then the file northbridge/amd/geodelx/dts is read in and processed.
Magic(TM) appends the name "/dts" to the path.
This hack is fine with chips that only do one thing.
But some (all) northbridge parts play several roles: APIC cluster, PCI domain
device, and PCI device. The result is a need for more than one dts, since
there are three possible devices, with three types of IDs, and so on.
To keep things sane, I am proposing to enable multiple dts files in a
directory, names (e.g., nothing required here):
domaindts
pcidts
apicdts
(of course these names can be anything, this is just an example).
This change will require a change to the dtc, since we can no longer
assume just one dts file, and hence need a way to name these different
files.
The proposed change is very simple. We now require the full path name
for the file, and eliminate the Magic(TM).
So,
/config/ = "northbridge/amd/geodelx/pcidts";
will open the pcidts file.
/config/ = "northbridge/amd/geodelx/domaindts";
will open the domain dts.
Maybe we should just call it domain and pci and apic? works for me.
/config/ = "northbridge/amd/geodelx/domain";
/config/ = "northbridge/amd/geodelx/pcibridge";
/config/ = "northbridge/amd/geodelx/apic";
Changes:
dtc.c: create a new function, fopenfile, that will only open a path if it
really is a file. Modify dtc_open_file to use this function. fopenfile
assumes "-" means stdin; should it, or should I move that assumption back
to dtc_open_file?
dtc.h: add prototypes
dtc-parser.y: Given a config path, open the path.
southbridge/amd/cs5536/cs5536.c: example of how C code changes
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Please see the comments below, but they do not have to be addressed for
this commit, just keep them in mind for future commits in that area.
git-svn-id: svn://coreboot.org/repository/coreboot-v3@566 f3766cd6-281f-0410-b1cd-43a5c92072e9
- I left LB_TAG_ intact because they are used by the payloads
- file renames are still missing. see next commit
- some lb_ renames might be missing. feel free to provide patches.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://coreboot.org/repository/coreboot-v3@564 f3766cd6-281f-0410-b1cd-43a5c92072e9
tree. Now requires newer flex, 2.5.4 at least.
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
M dtc/dtc-lexer.l
M dtc/flattree.c
M dtc/dtc.h
M dtc/livetree.c
M dtc/fstree.c
M dtc/dtc-parser.y
git-svn-id: svn://coreboot.org/repository/LinuxBIOSv3@361 f3766cd6-281f-0410-b1cd-43a5c92072e9
which just includes those two files on linux, and provides a
compatibility wrapper on Solaris, with room for other systems.
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://coreboot.org/repository/LinuxBIOSv3@309 f3766cd6-281f-0410-b1cd-43a5c92072e9
If this is a hard OFW limitation, let's fix OFW.
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://coreboot.org/repository/LinuxBIOSv3@161 f3766cd6-281f-0410-b1cd-43a5c92072e9
expect to hear about this change. Note that Stefan and I have discussed
this change and feel it is at least worth trying.
Also, please be aware that this change is backed by a
lot of experience with LinuxBIOS users and usage of the last 7 years.
First I detail changes, then I detail why.
Major changes for the new config system.
Selection of object files, and variable setting, is now controlled by
Kconfig.
There is only one dts now. It is in the mainboard file. It may later
move to the target file -- we will see.
The dts is in two parts, seperated by %%. The first part is a
fairly standard dts, and the dtc will automatically generate a device
tree from it. The device tree is composed of generic structures. These
structures are identical to those of the old V2 device tree. All the
hierarchy and parent/child/sibling relationships appear to be correctly
generated. This means that all the v2 code will work without change.
For each node in the tree, if the node has a property named 'config',
then the dtc will generate a reference to a structure and an include
directive for a path -- much as in the old Config tool.
Example: here is a fragment of a dts
==========
north {
config = "northbridge,intel,i440bx";
};
%%
struct northbridge_intel_i440bx_config north = {
.whatever = 1;
};
===========
The dtc will create:
#include <northbridge/intel/i440gx/config.h>
struct northbridge_intel_i440bx_config north = {
.whatever = 1;
};
struct device dev_north {
.chip_ops = &northbridge_intel_i440bx_ops;
.chip_info = &north;
.
.
.
};
So the programmer specifies the tree structure in dts form, indicates
which devices have a config entry, and sets up the C code for the
config. I have worked with this and am finding it very easy to use. I
think this is the way to go. Plus, we are getting rid of most of the
include hell of the old Config system.
Note that the config node is OPTTONAL! If you do not set it then no
structure usage/include will occur.
WHY?
Here is my setup for v3. I think this is good. I like it and am
finding it easy to work with.
Basically, the old config system combined makefile generation, tree
generation, and chip struct initialization in one file -- config.lb.
What we need are four things:
1. selection of .c files to build the bios with
2. the device tree -- this is built with generic structures defined in
include/device/device.h
3. The per-chip structures, usually defined in, e.g.,
northbridge/intel/i440bx/chip.h
4. setting of variables such as baud rate, etc.
Again, this was all done in Config.lb, spread all over the place, like this:
config chip.h
object superio.o
This was hard for people. So we moved the makefile stuff out into the
Kconfig system. This change eliminates (1) and (4) above.
OK, what's left? Well, with our plans from last October, we had device
object model tree stuff, AND still had chip struct initialization in
one file. (2) and (3) above. This is tough, because I was fighting the
mapping of DTS stuff to the C code. It was getting just as ugly as the
old Config.lb. I have been struggling with this for months and it just
wasn't going anywhere.
But it's way too hard to set up the device tree by hand -- I've tried
it. OTOH, it's really easy to set up the per-chip stuff by hand --
I've tried that too. I did a search via:
find ~/src/LinuxBIOSv2/src/ -name chip.h -print
and looked at them all. These files are really simple. There's no
reason to get too tricky, as there is nothing worth getting tricky
about. The problem is the device tree, not these simple chip info
structs.
So, here's the solution.
The ONLY dts is in the mainboard directory. There is no equivalent of
Config.lb in the south, north, cpu, all that stuff any more. The
Kconfig and Makefile in those directories replaced the build-related
functions of Config.lb.-- (1) and (4) above. The only thing left was
chip.h anyway (3) above.
But how can we express the settings in chip.h via the DTS? IT's been
very hard to get this going.
So, here is the trick. The dts in the mainboard directory divides into
two parts. The first part is the standard dts. The second part is the
C code. They are seperated, as in lex and yacc, with a %%.
Here is the dts for qemu (note that the cpus keyword is still not
right, and maybe this structure needs to change; i'm not that worried
about that too much, just the big picture I'm discussing here). Also,
note I'm working with some new properties, e.g. pcipath and pcidomain
-- if these properties exist ina node, then I create initialized
structure members for them. Also see enabled and on_mainboard --
properties, but I catch them and use them.
/{
cpus {
config="mainboard,emulation,qemu-i386";
emulation,qemu-i386@0{
enabled;
on_mainboard;
device_type = "cpu";
name = "emulation,qemu-i386";
pcidomain = "0";
/* the I/O stuff */
northbridge,intel,440bx{
pcipath = "0,0";
southbridge,intel,piix4{
};
};
};
};
};
%%
/* the user sets up these structs */
struct mainboard_emulation_qemu_i386_config cpus = {
.nothing = 1,
};
You can see the device tree stuff at top. If a given node has a
property named 'config', then that means what the old 'chip' thing
meant in Config.lb. The dtc will generate an #include to pull in a
file with the path name specified in the config property. The dtc will
not set up the per-chip struct, but it will set up a pointer to a
struct when it sets up the device tree. Note that at bottom, it's up
to you to set up the initialized struct. But this was always the easy
part anyway. Instead of wacky pseudo-C like we had in config.lb, we
just do real C. It's easy. Here is what the dtc generates.
#include <device/device.h>
#include <device/pci.h>
#include <mainboard/emulation/qemu-i386/config.h>
struct device dev_southbridge_intel_piix4;
struct device dev_northbridge_intel_440bx;
struct device dev_emulation_qemu_i386_0;
struct device dev_cpus;
struct device dev_root;
extern struct chip_operations mainboard_emulation_qemu_i386_ops;
struct mainboard_emulation_qemu_i386_config cpus = {
.nothing = 1,
};
struct device dev_root = {
.path = { .type = DEVICE_PATH_ROOT },
.links = 1,
.link = {
[0] = {
.dev = &dev_root,
.link = 0,
.children = &dev_cpus
},
},
.bus = &dev_root.link[0],
};
struct device dev_cpus = {
.chip_ops = &mainboard_emulation_qemu_i386_ops,
.chip_info = &cpus,
.links = 1,
.link = {
[0] = {
.dev = &dev_cpus,
.link = 0,
.children = &dev_emulation_qemu_i386_0
},
},
.bus = &dev_root.link[0],
.next = &dev_root,
};
struct device dev_emulation_qemu_i386_0 = {
.enabled = 1,
.on_mainboard = 1,
.path = {.type=DEVICE_PATH_PCI_DOMAIN,.u={.pci_domain={ .domain = 0 }}}
,
.links = 1,
.link = {
[0] = {
.dev = &dev_emulation_qemu_i386_0,
.link = 0,
.children = &dev_northbridge_intel_440bx
},
},
.bus = &dev_cpus.link[0],
.next = &dev_cpus,
};
struct device dev_northbridge_intel_440bx = {
.path = {.type=DEVICE_PATH_PCI,.u={.pci={ .devfn = PCI_DEVFN(0,0)}}},
.links = 1,
.link = {
[0] = {
.dev = &dev_northbridge_intel_440bx,
.link = 0,
.children = &dev_southbridge_intel_piix4
},
},
.bus = &dev_emulation_qemu_i386_0.link[0],
.next = &dev_emulation_qemu_i386_0,
};
struct device dev_southbridge_intel_piix4 = {
.bus = &dev_northbridge_intel_440bx.link[0],
.next = &dev_northbridge_intel_440bx,
};
This compiles just fine.
I think this is the right way to go, comments to me.
But, note, IT COMPILES. And it's simple. And, it will work with our
current device tree code!
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://coreboot.org/repository/LinuxBIOSv3@59 f3766cd6-281f-0410-b1cd-43a5c92072e9
and see if the -O lb produces structs that are in the least sensible?
signed-off-by: Ronald G. minnich
git-svn-id: svn://coreboot.org/repository/LinuxBIOSv3@30 f3766cd6-281f-0410-b1cd-43a5c92072e9
