Re: linuxbios and solaris
You might be able to use something like ADLO to emulate the interrupt. Greg On Mar 21, 2005, at 4:01 AM, jfaslist wrote: Hi, I was wondering if linuxbios would boot and work with solaris x86? From the following link, it seems that the BIOS INT 13 is required by the first stage boot: http://developers.sun.com/solaris/developer/support/driver/wps/ realmode_env/boot.html Is there a way around this? Thanks a lot, -jf simon ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: totalimpact briq?
Hi Stefan, I did it this way because the JTAG debugger understands elf headers, so can automatically work out where to program the image in rom. I guess it should really be called linuxbios.elf. Feel free to change things if you feel the need. Greg On Feb 13, 2005, at 3:55 PM, Stefan Reinauer wrote: Hi, how should the totalimpact briq target work? When I build it, I get an elf image as the resulting linuxbios.rom. Is this intended? Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: V2 questions
On Jan 20, 2005, at 9:19 AM, Richard Smith wrote: well, I am supposed to put my filo in there RSN, should I do that? My mistake ... What about fs_stream? What's fs_stream? It enables an embedded version of FILO, rather than using FILO as a payload. Greg ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
problem with PPC
Well, I have a problem. The PPC code, which was working in November, is now no longer working. I rebuilt the Sandpoint image using the same configuration file, but now I just get garbage on the screen. To help me track this down, can anyone who has made changes that are likely to have cause this, please let me know. Greg ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [PROPOSAL] enhanced table dumping
On Jan 18, 2005, at 4:51 AM, Eric W. Biederman wrote: Stefan Reinauer [EMAIL PROTECTED] writes: * ACPI tables need information on the Apics as well. Now the ACPI implementation I wrote a longer while ago is completely static and basically only works for systems with a single IOAPIC and not very well even on those. Autocreation of those tables should belong to the driver code of each supported device. No. The devices should have no idea about the format of the data we present to the user. We should push all of the information into the device tree so we can derive it from there. I agree. The right way to do this is to provide the device tree with a single method for serializing itself. If ACPI, MP, pirq information needs to be passed, then it should be included in the device tree. We may need to add additional device tree information to deal with the IOAPICs problem. The only issue really is what format to use for serialization. I'm leaning towards s-expressions for use with openbios. However, it's conceivable that different serialzation methods could be provided for different payloads, though probably not desirable. Greg ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [PROPOSAL] enhanced table dumping
On Jan 18, 2005, at 1:19 PM, Eric W. Biederman wrote: Greg Watson [EMAIL PROTECTED] writes: On Jan 18, 2005, at 4:51 AM, Eric W. Biederman wrote: The only issue really is what format to use for serialization. I'm leaning towards s-expressions for use with openbios. However, it's conceivable that different serialzation methods could be provided for different payloads, though probably not desirable. Please note this problem has to pieces. Which information should we represent and how should we represent it. Devices on a motherboard are not necessarily connect as a tree. I have never seen a tree structured schematic :) So the actual layout of the data is to some extent secondary to the data structures we will use to represent that data. So we need to drill down on that part as to how we represent logical devices and how we represent the logical connections between them. Eric An arbitrary graph seems to be adding additional complexity that we don't really need. Do you have an example of where a tree won't actually suffice? The nice thing about s-expressions is that it deals with both the structure and representation. Greg ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: work linuxbios with openbios
This is a work-in-progress, so there is no documentation. The major issue that needs to be addressed is that there is currently no mechanism for passing the linuxbios discovered device information to openbios. This is on my todo list. Openbios is an implementation of the IEEE-1275 standard for Open Firmware. This provides a standard means for loading an operating system image from a device, as well as a series of callbacks that an operating system can use to perform certain functions, such as writing to an attached display. It is similar to filo in some respects, such as the ability to load images from attached devices, but provides an architecture neutral layer that simplifies the interface between the operating system and the hardware. This means an Open Firmware enabled kernel will run on virtually any platform that provides Open Firmware support, without requiring kernel code that is specific to the platform. Greg On Jan 10, 2005, at 3:33 AM, zhu shi song wrote: How to use linuxbios together with openbios? Is there any clear howto doc? What's the main purpose of openbios? What's the main difference between openbios and filo? Now I'm using filo to boot my linux kernel. tks zhu __ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: VGABIOS is working under LinuxBIOS
On Jan 5, 2005, at 9:40 PM, Ronald G. Minnich wrote: On Wed, 5 Jan 2005, Li-Ta Lo wrote: No. The do_vgabios is depreciated and is removed from the CVS. It uses a real mode switch which is very difficult to to debug and not portable. The prefered way now is to use the emulator to execut the VBIOS. The emulator is acting as the .init method of a generic vga device driver. THe really cool thing about this is that it is portable to, e.g., Power PC. ron As soon as Ollie gets this into CVS, I'll try it on the sandpoint. Greg ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: RFC: linuxbios table fix
On Dec 9, 2004, at 10:49 PM, Eric W. Biederman wrote: Ronald G. Minnich [EMAIL PROTECTED] writes: On Thu, 9 Dec 2004, Eric W. Biederman wrote: I am still worried about ppc, and big endian architectures in general. But I don't think we currently have any users there. we do. I think I'd like to hear Greg Watson's take on this as he is working with the PPC 970 guys and this will impact him. Ron we have users of the LinxuBIOS table on PPC? It was my impression that we did not. I would be happy to hear what Greg has to say. If nothing uses this entry I will be happy to change this.Otherwise we need to know what the test program below reports on ppc. Nothing uses this currently, but I will be providing support to pass the entire device tree to a payload in the near future. Whether this will be using linuxbios tables, s-expressions or XML depends on the results of the current discussion. On ppc32, gcc-3.2.2 I get a size of 24. I'll try ppc64 later today. Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: jump to boot code
If you do an 'objdump -f' on the executable, what does it say is the start address? 0x1092e4 seems a bit strange. Greg On Dec 1, 2004, at 11:17 PM, Gin wrote: I tested my payload(FILO.elf) with linux loader Grub. It has no problem at all. So something must go wrong when linuxbios jumps to the payload. FILO doesn't seem to run at all. No debug message over the console. Dont know if there is anyone familiar with ELF. This is the message over the console at the end. It seems that there are 2 segments in the ELF. In the end, linuxbios jumps to an entry that looks like the in the middle of the first segment. Does it look right? Found ELF candiate at offset 0 (cleaned up) New segment addr 0x10 size 0x270f0 offset 0xa0 filesize 0xd068 (cleaned up) New segment addr 0x127100 size 0x48 offset 0xd120 filesize 0x48 Dropping non PT_LOAD segment Loading Segment: addr: 0x0010 memsz: 0x000270f0 filesz: 0x00 00d068 Loading Segment: addr: 0x00127100 memsz: 0x0048 filesz: 0x00 48 Jumping to boot code at 0x1092e4 entry = 0x001092e4 lb_start = 0x4000 lb_size = 0x00024000 adjust = 0xfe5d8400 buffer = 0xfe5b8400 elf_boot_notes = 0x00015680 adjusted_boot_notes = 0xfe5eda80 ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Alignment of LinuxBIOS table structures
On Nov 28, 2004, at 9:34 PM, Ronald G. Minnich wrote:
On Fri, 26 Nov 2004, Stefan Reinauer wrote:
The problem is that different compilers handle structure alignment
differently, ie 2.95.x and 3.x have fundamental differences here:
stepan, from the point of view of Plan 9, these are the same compiler.
Adding __attribute__ ((packed)) to the structures helps:
Sadly, Plan 9 compilers do not support this attribute for very good
technical reasons. The problem then is that these tables will be hard
for
Plan 9 to deal with.
struct lb_memory_range {
uint64_t start;
uint64_t size;
uint32_t type;
#define LB_MEM_RAM 1 /* Memory anyone can use */
#define LB_MEM_RESERVED 2 /* Don't use this memory region */
#define LB_MEM_TABLE 16 /* Ram configuration tables are kept in */
} __attribute__ ((packed));
There are two problems here.
The first problem is the use of binary structures, followed by the use
of
gcc attributes to make the structures have a certain shape. I've just
had a big tussle with this in Xen and Plan 9. Xen kind of assumes a gcc
world and things fall apart badly when your compiler is not gcc. This
is
going to happen with these binary structures when our payloads are not
built with gcc compatible compilers -- which is already the case with
Plan
9 payloads.
Second problem is, what happens if this or other LinuxBIOS tables need
to
change at some future point? We're going to have different versions.
Intel and Microsoft solve this versioning problem by putting a version
number in binary tables. Hence in the _MP_ table there is a version
flag.
This versioning of binary tables is a headache; what if you have to
boot a
very old OS that realizes it can't parse table version 2, only table
version 1? Oops. Trouble, that's what.
I think the big problem is the use of binary data structures. It shows
how
smart the Open Boot guys were to use strings, and they figured this
out 16
years ago!
I think we should look at having linuxbios create strings of data for
tables, not binary tables. Long term, the binary tables are going to
cause
us trouble, as they have already: having to use non-portable compiler
options/attributes is a recipe for disaster. You only parse them once
to
turn them into internal binary data structures in the OS; performance
is
not an issue here.
In Plan 9, the parameters are passed in as keyword-value pairs, viz:
totalmem=0x10
This is easy to generate, and both Linux and Plan 9 and other OSes have
more than enough functions in the kernel already to parse these. This
removes special needs for alignment, packing, and so on.
If you want you can generate Forth tables, which are also simple, but
in
the end, I think we need to avoid the problems of binary tables.
My real preference is for S-expressions, as they are totally
character-oriented tables that can still provide structure such as
trees
and tables, but I am not sure people will like S-expressions.
I agree, we need to get away from binary structures. Much as I like
S-expressions, strings containing key/value pairs is probably the most
common and easily understandable way to do it.
Greg
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: pnp_enable_resource not being called
YH,
Thanks, that seems to have fixed the problem.
Greg
On Nov 24, 2004, at 3:48 PM, YhLu wrote:
In the AMD8111_lpc.c
static void amd8111_lpc_enable_resources(device_t dev)
{
pci_dev_enable_resources(dev);
enable_childrens_resources(dev);
}
static struct device_operations lpc_ops = {
.read_resources = amd8111_lpc_read_resources,
.set_resources= pci_dev_set_resources,
.enable_resources = amd8111_lpc_enable_resources,
.init = lpc_init,
.scan_bus = scan_static_bus,
// .enable = amd8111_enable,
.ops_pci = lops_pci,
};
So I guess you need to add the device driver for the lpc in SB.
Then the scan_static_bus and enable_childrens_resources(dev) will be
called.
Regards
YH
-Original Message-
From: Greg Watson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 24, 2004 1:29 PM
To: 'LinuxBIOS'
Subject: pnp_enable_resource not being called
The sandpoint has the following structure:
Northbridge MPC107 -- Southbridge W83C553 -- Superio PC97307
The config file looks like:
chip northbridge/motorola/mpc107
device pci_domain 0 on
device pci 0.0 on end
device pci b.0 on
chip southbridge/winbond/w83c553
chip superio/NSC/pc97307
device pnp 15c.0 on end #
Kyeboard
device pnp 15c.1 on end #
Mouse
device pnp 15c.2 on end #
Real-time Cloc
k
device pnp 15c.3 on end #
Floppy
device pnp 15c.4 on end #
Parallel port
device pnp 15c.5 on end # com2
device pnp 15c.6 on end # com1
device pnp 15c.7 on end # gpio
device pnp 15c.8 on end #
Power
manageme
nt
end
end
end # pci to isa bridge
device pci b.1 on end # pci ide controller
end
device cpu_bus 0 on
chip cpu/ppc/mpc74xx
device cpu 0 on end
end
end
end
The dev_enumerate() code is calling the PNP enable routines and the
dev_initialize() code is calling the PNP init routine. However the
dev_enable() code never calls the PNP enable_resource routine, which
means the the PNP devices are never actually enabled.
The enable_dev routine for the superio device calls:
pnp_enable_devices(dev, ops,
sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]),
pnp_dev_info);
where ops is defined as:
static struct device_operations ops = {
.read_resources = pnp_read_resources,
.set_resources= pnp_set_resources,
.enable_resources = pnp_enable_resources,
.enable = pnp_enable,
.init = init,
};
Any ideas why this is not working? Is there something else that needs
to happen?
Greg
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: boot linux from an ide
If FILO is a payload in flash, then you need to set CONFIG_ROM_STREAM=1 and CONFIG_ROM_STREAM_START to the address you want to start looking for the payload ELF header (usually just after the LinuxBIOS image). CONFIG_IDE_STREAM is used to load a payload (such as FILO) from an attached IDE device. This is useful if the flash is not large enough to hold LinuxBIOS+payload, but is probably not what you are looking for. Sorry for the confusion. Greg On Nov 25, 2004, at 5:40 AM, Gin wrote: I use FILO as the payload to boot from a Hard Disk, which has a installed linux on it. I noticed if I enabled the ide stream. It tries to read the ELF header from my IDE drive. But I thought the FILO payload should be the one to load the image from the IDE drive. When does it come in and play the role? Anyone can explain the flow of booting if I try to load the INSTALLED linux from a IDE drive. Gin ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
pnp_enable_resource not being called
The sandpoint has the following structure:
Northbridge MPC107 -- Southbridge W83C553 -- Superio PC97307
The config file looks like:
chip northbridge/motorola/mpc107
device pci_domain 0 on
device pci 0.0 on end
device pci b.0 on
chip southbridge/winbond/w83c553
chip superio/NSC/pc97307
device pnp 15c.0 on end #
Kyeboard
device pnp 15c.1 on end # Mouse
device pnp 15c.2 on end #
Real-time Cloc
k
device pnp 15c.3 on end # Floppy
device pnp 15c.4 on end #
Parallel port
device pnp 15c.5 on end # com2
device pnp 15c.6 on end # com1
device pnp 15c.7 on end # gpio
device pnp 15c.8 on end # Power
manageme
nt
end
end
end # pci to isa bridge
device pci b.1 on end # pci ide controller
end
device cpu_bus 0 on
chip cpu/ppc/mpc74xx
device cpu 0 on end
end
end
end
The dev_enumerate() code is calling the PNP enable routines and the
dev_initialize() code is calling the PNP init routine. However the
dev_enable() code never calls the PNP enable_resource routine, which
means the the PNP devices are never actually enabled.
The enable_dev routine for the superio device calls:
pnp_enable_devices(dev, ops,
sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]),
pnp_dev_info);
where ops is defined as:
static struct device_operations ops = {
.read_resources = pnp_read_resources,
.set_resources= pnp_set_resources,
.enable_resources = pnp_enable_resources,
.enable = pnp_enable,
.init = init,
};
Any ideas why this is not working? Is there something else that needs
to happen?
Greg
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: ppc targets
On Nov 18, 2004, at 6:13 AM, Eric W. Biederman wrote: Just a progress update before I go to bed. I have the totalimpact/briq building now. There are a couple of things that are not quite right but nothing architectural. Looking at where the code is I should be able to get the sandpointx3+pmc/altimus/mpc7410 building. Since there is only one pmc supported things look much simpler :) Beyond that a lot of my confusion has been looking at code and expecting it to work, or to handle the general case when in fact it doesn't. As I settle for merely fixing the code so it continues to do what it did before, I can successfully make a lot of progress. Eric The problem with both the briq and the ep405pc is the lack of board-level documentation. This makes adding support painstakingly slow at best. I will be satisfied having the code back to the point where at least development can continue. Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: boot from ide
Actually, don't set CONFIG_FS_STREAM if you're using Filo as a payload. Use the CONFIG_IDE_STREAM instead. Greg On Nov 17, 2004, at 7:05 PM, Gin wrote: Hello, I've got my linuxbios run to the point it tries to load the image from an IDE drive. I use FILO as the payload. 1. What do I have to add in the Config.lb file to make it use filo? I know CONFIG_FS_STREAM should be set to true. What else? 2. I remembered linuxbios supports ROM image size larger than 64K now. But when got compiler errors when specifies it as 128K. Do I miss anything? Gin ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
recent changes
We now seem to have a chip keyword, in addition to config, device, driver and object keywords. We have a device_operations structure, a cpu_device_id structure and a cpu_driver structure as well as a pci_driver structure. The cpu tree has been reorganized to include vendor directories as well as architecture directories. We now seem to have a drivers directory tree. Can someone please provide the following information: 1. What does each keyword actually do now? 2. How do the keywords relate to the data structures? 3. What files are now auto generated, and how is everything linked together? 4. What keywords/data structures are actually needed, and by which devices? 5. How/where are the data structures used? 6. What is the rationale behind the reorganization of the cpu tree, and how is it supposed to work? 7. What is the purpose of the drivers tree, how do drivers differ from devices, and why is the console not included? The configuration process now seems so complicated that I can't see how we could expect someone to port to a new board without some basic description of how everything is supposed to work. I have a major vendor interested in doing this, but at the moment I can't offer them any help. Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
recent changes
We now seem to have a chip keyword, in addition to config, device, driver and object keywords. We have a device_operations structure, a cpu_device_id structure and a cpu_driver structure as well as a pci_driver structure. The cpu tree has been reorganized to include vendor directories as well as architecture directories. We now seem to have a drivers directory tree. Can someone please provide the following information: 1. What does each keyword actually do now? 2. How do the keywords relate to the data structures? 3. What files are now auto generated, and how is everything linked together? 4. What keywords/data structures are actually needed, and by which devices? 5. How/where are the data structures used? 6. What is the rationale behind the reorganization of the cpu tree, and how is it supposed to work? 7. What is the purpose of the drivers tree, how do drivers differ from devices, and why is the console not included? The configuration process now seems so complicated that I can't see how we could expect someone to port to a new board without some basic description of how everything is supposed to work. I have a major vendor interested in doing this, but at the moment I can't offer them any help. Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: ppc targets
Let me have a look. I'm back from travel tomorrow Greg On Nov 11, 2004, at 8:42 AM, Stefan Reinauer wrote: The ppc targets fail because of src/cpu/ppc/ppc4xx/mem.c struct mem_range is never ever defined. Is it struct lb_memory?! I have a bunch of other patches lying around that I will commit if nobody complains Stefan ppc.diff ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: 2 questions
On Oct 5, 2004, at 2:12 PM, Ronald G. Minnich wrote: i855GM/GMCH. I set up the registers, set up the MODE for a NOP, and on the first read, the whole thing hangs. Suggestions for what to do next, anyone :-0) Anybody seen good PC/104 or biscuit format Power PC systems? I'm getting a little tired of dealing with the intel side of the house, because the docs are so sparse nowadays. Pointers welcome. PPC 405 is no good: no floating point. http://www.cowboyindustries.com is supposed to have done a PC104+ board with the G4 (MPC7400) and G3(MPC750) processors, but I can't find anything useful on their web site. It might be worth an email. See here also: http://linuxdevices.com/news/NS9893837137.html Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [PROPOSAL] extended payload handling
Stefan, I think this is a reasonable idea, particularly your suggestion of making linuxbios more modular. One of my main beefs with the payload strategy is that each payload has to provide it's own set of, potentially buggy, driver code. If we have 5 payloads then we have 5 sets of drivers that all do the same thing slightly differently. If the drivers were modular enough so that a payload could call them directly, then this would go a long way to addressing these concerns. Regards, Greg On Jun 8, 2004, at 4:49 AM, Stefan Reinauer wrote: There has been a similar proposal on this list a while ago, but nothing happened so far, so I want to put this pack to discussion. Objectives -- 1.) LinuxBIOS is kind of hard to set up for project newbies, since it does not only require manually tweaking the configuration files for basically every situation, but also necessarily needs an external payload to do anything useful. LinuxBIOS currently sets a high barrier due to the modular concepts it uses. - LinuxBIOS itself is sometimes very sensitive to the build environment. See requirement for setting LANG for example. - For a project outsider it is hard to determine the best payload solution for a specific purpose. There is basically no information except the mailing list archives. - Config files have to be tweaked to explicitly suit the user's directory structure. There is no proposal, nothing that works out of the box. One just _has to_ edit the config files. - LinuxBIOS requires the user to specify a size for the payload instead of determining the required size and doing the needed calculations itself. This is very hand-crufted and can be pretty mind wasting. 2.) LinuxBIOS can currently execute one payload. For greater flexibility and isolated development cycles of the firmware related code parts/projects LinuxBIOS should allow payload chains, ie. executing multiple payloads one after the other. LinuxBIOS wants to keep up it's modularity, letting each module do it's job. This possibility of not doing more than one task should be passed on to the payloads. Solution Feature plugins like testbios should not be merged into LinuxBIOS' core code. Instead they should be implemented as a payload. Since we want to load an operating system later on, we also need to be able to load more than one payload. Implementing ELFLOAD in each such plugin is inadequate. Instead LinuxBIOS should execute multiple payloads the same way it executes multiple drivers now. * LinuxBIOS therefore needs a way to automatically determine payload sizes when building the image and later when executing payloads. Hardcoding the size values in the config files is inadequate and will lead to unnecessary overhead * LinuxBIOS at runtime needs to go through the list of available payloads, either by having a linked list of payload start points or by scanning the flash rom. * LinuxBIOS should, to be consequent, remove all streaming code except CONFIG_ROM_STREAM * Payloads should have the possibility to add their own enhancements to the LinuxBIOS table. * A least one payload should be default payload with the possibility to build this automatically and link it into the image. This is why I checked the util/extensions directory into v2 during the last discussion. It should hold possible choices to payloads that can automatically be built and included. Potentially one could add more payloads by symlinking their source tree to this directory to make it available to LinuxBIOS without major reconfiguration. People feel a lot safer with creating a symlink than with changing config files they do not fully understand. Since these can later be executed in row by elfboot, the minimum overhead design of LinuxBIOS itself will not be hurt. At this point I want to put an idea to discussion: If we are going more and more modular and some of us think the current tree is too bloated: Why do we not modularize code like pci resource allocation into a payload as well. My favorite bootloader may already do this and I can't stand this bloat everywhere, you know ;) Even though this may sound funny, I am serious about this issue. I do not see why allocating PCI resources should really be part of the lowlevel code, except for the fact that the NEXT payload in row, potentially Linux itself is too stupid to do that. Bummer. * LinuxBIOS configuration should have an easier mechanism for choosing payloads from the default directory, allowing them to be built automatically. Right now I am doing: cd filo-0.4.2 linux32 make CC=gcc -m32 LD=ld -melf_i386 cd .. freebios2/targets/buildtarget amd/solo $PWD/freebios2 cd build-solo make cd .. cp build-solo/solo.rom . My target Config.lb comes with these constructs: target ../../../../build-solo payload ../../filo-0.4.2/filo.elf So I build
Re: [PROPOSAL] extended payload handling
On Jun 8, 2004, at 7:59 AM, Stefan Reinauer wrote: * Greg Watson [EMAIL PROTECTED] [040608 15:22]: I think this is a reasonable idea, particularly your suggestion of making linuxbios more modular. One of my main beefs with the payload strategy is that each payload has to provide it's own set of, potentially buggy, driver code. If we have 5 payloads then we have 5 sets of drivers that all do the same thing slightly differently. If the drivers were modular enough so that a payload could call them directly, then this would go a long way to addressing these concerns. As far as I can tell the only drivers involved would be output drivers, ie. video output and serial output. There the extensible LinuxBIOS table could come into play. The video driver could store a pointer to the framebuffer, the resolution and maybe even a font, to save duplicates. Serial is only a kilobyte or so of a driver i think. Have I forgotten something? PCI device code and resource information should be available for payloads to use. A payload should not have to re-probe for devices on the PCI bus. Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
briQ status
For those interested in PPC boards, I just managed to get the briQ talking over serial console. (More on the board at http://www.totalimpact.com/products/the_briq/the_briq.html). Output below. Hopefully we'll demo this board running Clustermatic at the USENIX BOF. Greg Board initialized... LinuxBIOS-1.1.6 Fri Jun 4 16:13:35 MDT 2004 rebooting... Finding PCI configuration type. Enumerating static devices... Enumerating buses... PCI: pci_scan_bus for bus 0 PCI: 00:00.0 [1014/0105] enabled PCI: 00:06.0 [10ad/0565] ops PCI: 00:06.0 [10ad/0565] enabled PCI: 00:06.1 [10ad/0105] ops PCI: 00:06.1 [10ad/0105] enabled PCI: 00:07.0 [1022/2000] enabled PCI: pci_scan_bus returning with max=00 done Allocating resources... ASSIGN RESOURCES, bus 0 PCI: 00:06.1 10 - [0x1040 - 0x1047] io PCI: 00:06.1 14 - [0x1050 - 0x1053] io PCI: 00:06.1 18 - [0x1048 - 0x104f] io PCI: 00:06.1 1c - [0x1054 - 0x1057] io PCI: 00:06.1 20 - [0x1020 - 0x102f] io PCI: 00:06.1 24 - [0x1030 - 0x103f] io PCI: 00:07.0 10 - [0x1000 - 0x101f] io PCI: 00:07.0 14 - [0xfebfffe0 - 0xfebf] mem ASSIGNED RESOURCES, bus 0 done. Enabling resourcess... PCI: 00:00.0 cmd - 147 PCI: 00:06.0 cmd - 147 PCI: 00:06.1 cmd - 145 PCI: 00:07.0 cmd - 143 done. Initializing devices... PCI: 00:06.0 init Configure W83C553F ISA Bridge (Function 0) W83C553F configuration complete PCI: 00:06.1 init Configure W83C553F IDE (Function 1) ide bus offset = 0x1f1 IDE configuration complete Devices initialized totalram: 1024M Initializing CPU #0 PowerPC 7400 CPU, version 2.9 CPU #0 Initialized Wrote linuxbios table at: 0010 - 0174 checksum 9bf0 Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3 Trying polled ide Waiting for ide disks to spin up This is a hard coded delay and longer than necessary. .. found PCI IDE controller 10ad:0105 prog_if=0x8f primary channel: native PCI mode ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Enable v.s. Enabled
Was it annoying you or something :-) Greg On 29/04/2004, at 2:28 PM, Li-Ta Lo wrote: Hi, I changed the device:enable and chip_device_path::enable to device:enabled and chip_device_path::enabled because they are acutally verbs describe the status of the devices. I also change all the affected code I can find, there should be no problems except you have to re-run the config tool. Ollie ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: LinuxBios official requirements.
Mathieu, I think you misunderstood. I wasn't implying RH9 as the default distribution for LinuxBIOS. I was simply suggesting that the development tools (gcc, libc, python, etc.) that are supplied with RH9 are a good approximation of the versions required to guarantee a successful build. Greg On 13/04/2004, at 2:28 AM, Mathieu Deschamps wrote: Hum ... under certains embedded conditions redhat is somewhat heavy to handle... ... anyway Linuxbios aims to work on various hardware device (provided that we make it work :) so it is on various linux distribution, isn't it so ? if not, IMHO, it should be :) And more over, seriously, it will gain even more credibility if it's proven to work on other distrib. It is again the same crosspoint : portability on every layer, down from hardware conformance and standards, up to software versions and use conventions. Enough bla-bla'ing, as soon as I got it compiled and proven work on my SuSE 6.2 modified (from tail to head), I post the enumeration soft-components, I'am sure it will be appreciated. mathieu Le lun 12/04/2004 à 14:44, Greg Watson a écrit : Yes, most of us are too busy getting LinuxBIOS working to spare the time to write much documentation. I can say that I've built most of the targets successfully using a stock RH9 (YD3.0.1 for PPC) machine. That's probably as good a base-line as any. Greg On 09/04/2004, at 7:53 AM, Mathieu Deschamps wrote: I've read several documentation on LinuxBios and related projects, though I didn't find out a LinuxBios requirements true paper. I still have the 2.4.xx kernel compiling oriented slab that is to say : GNU Make 3.77, ECGS 1.1.2 (GCC 2.91.66), Binutils 2.10, util-linux 2.10. Also I had a quite old python version (1.1 or so), i got it updated to 2.2.3 when I've seen the python script insulted me while running buildtarget. What are the official requirements ? What I try to say is that a REQUIEREMENTS file in the source tree LACKS, Maybe it lacks also in the site page (IMHO, the early page info should mention this)... cordialy, mathieu ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Newbie with epia M-II
Not sure what the biggest PLCC is, but it's probably not much over 1MB. We use a 64MB IDE FLASH on some of our EPIA's which is easily big enough for a kernel and RAM disk. The nice thing about the IDE FLASH is that it can easily be replaced by a disk if you want. It seems the main difference between the EPIA and the EPIA-M (and possibly the EPIA-1) is the type of RAM used (SDRAM/DDR). It's going to take some work to add DDR support to current EPIA image. Greg On 12/04/2004, at 5:57 AM, Ignacio Verona wrote: hi! This is my first post. I'm trying to develop my own Car PC and using LinuxBios I hope to get faster boot times. I'm using a Via EPIA M-II 1. What are the first steps I should take? The epia bios is socketed on 32-lead PLCC format. What is the biggest rom size I could get? It is possible to use DOC on this motherboard (may be, I could fit a usable linux system on... less than 64mb). I've reading the list archive but I'm still a little lost. All help will be aprecciated. Thanks!! ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: LinuxBios official requirements.
Yes, most of us are too busy getting LinuxBIOS working to spare the time to write much documentation. I can say that I've built most of the targets successfully using a stock RH9 (YD3.0.1 for PPC) machine. That's probably as good a base-line as any. Greg On 09/04/2004, at 7:53 AM, Mathieu Deschamps wrote: I've read several documentation on LinuxBios and related projects, though I didn't find out a LinuxBios requirements true paper. I still have the 2.4.xx kernel compiling oriented slab that is to say : GNU Make 3.77, ECGS 1.1.2 (GCC 2.91.66), Binutils 2.10, util-linux 2.10. Also I had a quite old python version (1.1 or so), i got it updated to 2.2.3 when I've seen the python script insulted me while running buildtarget. What are the official requirements ? What I try to say is that a REQUIEREMENTS file in the source tree LACKS, Maybe it lacks also in the site page (IMHO, the early page info should mention this)... cordialy, mathieu ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: LinuxBios and Openbios's dev/bios capacity
This seems like an openbios issue to me. Greg On 08/04/2004, at 7:23 AM, Mathieu Deschamps wrote: I've found in OpenBios dev/bios a good reason to hope i could spare the cost of a physical flashing device , and a ease using. That is to say getting LinuxBios building the .bin and flash the onboard BIOS via the dev/bios mechanism. I have a via/epia and a SST39 series 20A (256Ko) bios chip on I'd thought I could read/write this bios with cat my.bin /dev/bios but by insmoding bios.o. But i got a kmess coming from lines 123-126 printk code of bios.c BIOS : No flash devices found This resulting in a console message Device busy (that is, though, a bit paradoxal notfound != busy isn't it ? :) ) I can't catch what have missed me... Is dev/bios couldn't be used in my aim ? Gratefull if experienced people could help me. Cordialy. Mathieu ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: FILO 0.4 [PMX:#]
Stefan, I think this is a great idea. I'll talk it over with Ron and Ollie this week and look at how it might be implemented. Greg On 05/04/2004, at 6:46 AM, Stefan Reinauer wrote: * Eric W. Biederman [EMAIL PROTECTED] [040405 05:02]: If we want to take a snapshot of the source tree of FILO or any other bootloader into the LinuxBIOS tree under util. Build that part of the build and build a complete romimage that works. I am fine with that. It is even reasonable to make it so you can drop in external trees like etherboot and have everything build together nicely. Actual linking things together instead of including them together is unacceptable. What about the following: Currently LinuxBIOS divides into 2 fundamental parts: 1) hardware initialization 2) getting and starting the payload This second part consists of two parts, again: i) elfloader ii) payload Note, this is only one possible design. Maybe, this design is bloated for some application cases. Eric, you want to make a hard cut between what is LinuxBIOS and what is not. This is generally a good idea, as it keeps the different initialization steps distinct from reach other. What, if we add another cut by dividing hardware initialization frin the payload-loader? Instead of packing stuff like filo to util, we could do: * create a directory loader which can hold all loaders * move the elf loader with a Config.lb to a subdirectory in there * create other directories for other loaders like filo. If done right, filo can still be compiled as a payload, or built in if the win in size is noticable. A target config file could probably choose which method to use, without overhead. Also, syncing with other trees, like Takeshi's filo tree could be fairly easy, too. I don't think we really have a conflict in direction here at all. LinuxBIOS itself should be as small as possible, and the different parts should be as independent as possible. But we also want to be a lot more flexible than the existing solutions.. In addition we have had way to many questions of what is the right policy for a bootloader to implement, on this list. I refuse to couple that to the LinuxBIOS core. And I don't want some stupid policy in there like FILO's that would require me to upgrade my firmware just to upgrade my OS. Please explain, how is filo worse here than putting linux in flash? Stefan ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: XScale Port
On 12/04/2004, at 8:44 AM, ron minnich wrote: On Mon, 12 Apr 2004, Bari Ari wrote: they have nvidia working with the x86 emulator, so I'll be trying that next. x86 emulator will probably be to ugly a path to use on an ARM platform. I'm not sure I agree. I think it is doable. ron Yes, I think it will work with PPC. If it does then there's no reason it won't for the ARM. We should know soon :-) Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Clustermatic 4 wins ClusterWorld Award
Hi all, I'm pleased to announce that yesterday Clustermatic 4 won the ClusterWorld Excellence in Cluster Technology Award for Open Source Software. I'd like to thank everyone who worked so hard to achieve this outstanding result. Thanks also to Daniel Gruner and Jim Phillips for agreeing to act as reference sites for Clustermatic. Best regards, Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: VIA EPIA Build Error MAX_REBOOT_CT
Check the Makefile.settings in the fallback directory and see if MAX_REBOOT_CNT is defined. If it isn't then there's some problem with the configuration. If it is, then it's not getting passed to the gcc command line. Greg On 08/04/2004, at 10:23 AM, Mathieu Deschamps wrote: I'am building a new rom but now,I got stuck because of #error MAX_REBOOT_CNT not defined in make process of build target even though i defined this in Config.lb Here is a process trace : ### if (cd fallback; \ make linuxbios.rom)\ then true; else exit 1; fi; make[1]: Entering directory `/home/root/projet-07042004/freebios/freebios2/build/epia/fallbac k' cp /home/root/projet/freebios/freebios2/src/arch/i386/config/crt0.base crt0.S gcc -no-gcc -x assembler-with-cpp -DASSEMBLY -E -I/home/root/projet/freebios/freebios2/src -D __ROMCC__=0 -D__ROMCC_MINOR__=38 -I/home/root/projet/freebios/freebios2/src/include -I/home/r oot/projet/freebios/freebios2/src/arch/i386/include -I/usr/lib/gcc-lib/i486-linux/egcs-2.91.6 6/include /home/root/projet/freebios/freebios2/src/mainboard/via/epia/failover.c ./failover.E gcc: unrecognized option `-no-gcc' In file included from /home/root/projet/freebios/freebios2/src/mainboard/via/epia/failover.c: 7: /home/root/projet/freebios/freebios2/src/pc80/mc146818rtc_early.c:5: #error MAX_REBOOT_CNT n ot defined make[1]: *** [failover.E] Error 1 make[1]: Leaving directory `/home/root/projet-07042004/freebios/freebios2/build/epia/fallback ' make: *** [fallback-rom] Error 1 # What is that pc80 directory in which it errors ? The parameter MAX_BOOT_CT is the counter that holds the survival of kernel messages after # boots, isn't it ? I've also joined the Config file on which i haven't made much changes except what it asked for. Please mail me a clue, just ask if you need moer info on the slab. Thanks in advance. # Sample config file for EPIA # This will make a target directory of ./epia # # Change for experimentation MD # loadoptions target epia uses ARCH uses CONFIG_COMPRESS uses CONFIG_IOAPIC uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START uses CONFIG_UDELAY_TSC uses CPU_FIXUP uses FALLBACK_SIZE uses HAVE_FALLBACK_BOOT uses HAVE_MP_TABLE uses HAVE_PIRQ_TABLE uses HAVE_HARD_RESET uses i586 uses i686 uses INTEL_PPRO_MTRR uses HEAP_SIZE uses IRQ_SLOT_COUNT uses MAINBOARD_PART_NUMBER uses MAINBOARD_VENDOR uses CONFIG_SMP uses CONFIG_MAX_CPUS uses MEMORY_HOLE uses PAYLOAD_SIZE uses _RAMBASE uses _ROMBASE uses ROM_IMAGE_SIZE uses ROM_SECTION_OFFSET uses ROM_SECTION_SIZE uses ROM_SIZE uses STACK_SIZE uses USE_FALLBACK_IMAGE uses USE_OPTION_TABLE uses HAVE_OPTION_TABLE uses MAXIMUM_CONSOLE_LOGLEVEL uses DEFAULT_CONSOLE_LOGLEVEL # Sample config file for EPIA # This will make a target directory of ./epia # # Change for experimentation MD # loadoptions target epia uses ARCH uses CONFIG_COMPRESS uses CONFIG_IOAPIC uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START uses CONFIG_UDELAY_TSC uses CPU_FIXUP uses FALLBACK_SIZE uses HAVE_FALLBACK_BOOT uses HAVE_MP_TABLE uses HAVE_PIRQ_TABLE uses HAVE_HARD_RESET uses i586 uses i686 uses INTEL_PPRO_MTRR uses HEAP_SIZE uses IRQ_SLOT_COUNT uses MAINBOARD_PART_NUMBER uses MAINBOARD_VENDOR uses CONFIG_SMP uses CONFIG_MAX_CPUS uses MEMORY_HOLE uses PAYLOAD_SIZE uses _RAMBASE uses _ROMBASE uses ROM_IMAGE_SIZE uses ROM_SECTION_OFFSET uses ROM_SECTION_SIZE uses ROM_SIZE uses STACK_SIZE uses USE_FALLBACK_IMAGE uses USE_OPTION_TABLE uses HAVE_OPTION_TABLE uses MAXIMUM_CONSOLE_LOGLEVEL uses DEFAULT_CONSOLE_LOGLEVE uses CONFIG_CONSOLE_SERIAL8250 uses MAINBOARD uses CONFIG_CHIP_CONFIGURE uses XIP_ROM_SIZE uses XIP_ROM_BASE uses LINUXBIOS_EXTRA_VERSION uses TTYS0_BAUD uses MAX_REBOOT_CNT option TTYS0_BAUD=19200 option CONFIG_CHIP_CONFIGURE=1 option MAXIMUM_CONSOLE_LOGLEVEL=7 option DEFAULT_CONSOLE_LOGLEVEL=7 option CONFIG_CONSOLE_SERIAL8250=1 option CPU_FIXUP=1 option CONFIG_UDELAY_TSC=0 option i686=1 option i586=1 option INTEL_PPRO_MTRR=1 option ROM_SIZE=256*1024 option HAVE_OPTION_TABLE=1 option CONFIG_ROM_STREAM=1 option HAVE_FALLBACK_BOOT=1 # # More Options # option MAX_REBOOT_CNT=10 ### ### Compute the location and size of where this firmware image ### (linuxBIOS plus bootloader) will live in the boot rom chip. ### option FALLBACK_SIZE=131072 ## LinuxBIOS C code runs at this location in RAM option _RAMBASE=0x4000 # ### ### Compute the start location and size size of ### The linuxBIOS bootloader. ### # # Arima hdama romimage normal option USE_FALLBACK_IMAGE=0 option ROM_IMAGE_SIZE=0x1 option LINUXBIOS_EXTRA_VERSION=.0Normal mainboard via/epia # payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf # payload ../../../../tg3--ide_disk.zelf payload ../../../../../lnxieepro100.ebi end romimage fallback
Re: FILO 0.4 [PMX:#]
Correct. I haven't included linux_load, though it would probably be easy to do. FILO simply calls elfboot to load the image from a filesystem. Merging FILO with etherboot is a fine idea, but it doesn't solve the loader problem for PPC. At this point I don't see any requirement to port etherboot to PPC, but if anyone would like to take it on then feel free. :-) I think the case for including a simple FILO-like loader in linuxbios is a strong one. Apart from instant PPC loader support and reducing the difficulty of deploying linuxbios, it's possible to make use of much of the existing linuxbios code which significantly reduces duplication and complexity in the payload. Greg On 04/04/2004, at 2:57 PM, Yinghai Lu wrote: Eric, Greg just move the fs support from filo to linuxbios, and create fs_stream. It still calls the elfboot to load the elfimage in HD. And it doesn't support linux_load. So it is some kind of boot loader you said. It is really enhancement to ide_stream.c Regards YH -- : Eric W. Biederman [mailto:[EMAIL PROTECTED] Eric W. Biederman : 200443 20:33 : Greg Watson : Yinghai Lu; 'SONE Takeshi'; [EMAIL PROTECTED] : Re: g-e$: FILO 0.4 [PMX:#] Greg Watson [EMAIL PROTECTED] writes: Yeah sorry, I kind of did that by stealth. Ron and I get lots of requests from people wanting to use LB but who don't know how to deal with the payload issue. We decided that it would be really nice to have a simple bootloader that understands some basic filesystems built into LB. That way people can get going without having to deal with etherboot or FILO directly. A nice side effect is that it simplifies the FILO code significantly - in fact the only code that is really required is the filesystem support. Also, another major plus is that the code supports PPC as well as x86. Up to now I've had no bootloaders (etherboot or FILO) that work on PPC. Then we refactor and make building the bootloader part of the tree. These things are policy engines. We need to separate mechanism and policy. As far as I can tell this level of support crosses the line. etherboot is portable and would not be hard to get running on ppc. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: FILO 0.4 [PMX:#]
On 04/04/2004, at 9:02 PM, Eric W. Biederman wrote: Greg Watson [EMAIL PROTECTED] writes: Correct. I haven't included linux_load, though it would probably be easy to do. FILO simply calls elfboot to load the image from a filesystem. Feature bloat. No, it's functionality that is needed for PPC but is not available anywhere else. If we want to take a snapshot of the source tree of FILO or any other bootloader into the LinuxBIOS tree under util. Build that part of the build and build a complete romimage that works. I am fine with that. It is even reasonable to make it so you can drop in external trees like etherboot and have everything build together nicely. Actual linking things together instead of including them together is unacceptable. Merging FILO with etherboot is a fine idea, but it doesn't solve the loader problem for PPC. At this point I don't see any requirement to port etherboot to PPC, but if anyone would like to take it on then feel free. :-) It is a half way decent stand alone portable bootloader. There are a lot of other ones out there as well. Etherboot is something simple and small that exists as an alternative. Etherboot should be a fairly trivial port which is why I suggest it. I think the case for including a simple FILO-like loader in linuxbios is a strong one. Apart from instant PPC loader support and reducing the difficulty of deploying linuxbios, it's possible to make use of much of the existing linuxbios code which significantly reduces duplication and complexity in the payload. I have not seen it yet. The reason FILO simplifies is because it a simple first pass. But this complicates LinuxBIOS, and includes policy. Both of which are bad. I don't get this policy stuff. This code is doing no more that adding another stream device, of which there are already two. Someone building LinuxBIOS is perfectly liberty to choose to load an ELF image from ROM, directly from an IDE device, or from a filesystem mounted on an IDE device. Any builtin policy more complicated than slurp in one hard coded executable and run it I refuse to touch, and elfload gives us that. This is a line I refuse to cross and will delete code from CVS if necessary to enforce. Bootloaders can and should be board independent. That makes then easier to test and develop. And it very much simplifies the test of the whole thing. I agree. It would be nice if they were architecture independent as well. In addition we have had way to many questions of what is the right policy for a bootloader to implement, on this list. I refuse to couple that to the LinuxBIOS core. And I don't want some stupid policy in there like FILO's that would require me to upgrade my firmware just to upgrade my OS. By policy, do you mean a file name in a valid filesystem? As opposed to a valid ELF header? The distinction seems pretty fine to me. Being able to mount a compact flash device on another machine and drop multiple kernel versions onto it certainly helped me to get the EPIA going though. Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: No output on EPIA-M serial port
Does the EPIA-M have a 256KB flash or a 512KB flash? I just ran into this problem with the EPIA. If you flash the wrong size image then nothing works at all. Greg On 24/03/2004, at 3:02 PM, Shawn Perkin wrote: Hello all, Im currently in the process of trying to get Linuxbios to work on my Via EPIA-M with no success. I have successfully complied Etherboot 5.2.0 as my payload, and performed a successful build of Linuxbios. I burned the image without any errors and rebooted the system. I then had absolutely no output on either serial port, or local display. I currently have 256 MB of ram in the unit, and have tried a build with and without the extracted vgabios.bin. I have included my config file for your review. Any help would be greatly appreciated. Shawn # # LinuxBIOS config file for: VIA epia-m mini-itx # target /usr/local/build/epia-m # via epia mainboard via/epia-m # Enable Serial Console for debugging option SERIAL_CONSOLE=1 #option SERIAL_POST=1 option TTYS0_BAUD=115200 #option TTYS0_BAUD=57600 option HAVE_FRAMEBUFFER=1 option CONFIG_VGABIOS=1 option CONFIG_REALMODE_IDT=1 dir src/bioscall option CONFIG_PCIBIOS=1 option VGABIOS_START=0xfffe #addaction romimage dd if=../vgabios.bin of=romimage bs=65536 seek=2 conv=sync conv=notrunc option CONFIG_EPIAMVERSIONSTRING=5.0.0E- __DATE__ __TIME__ #target /ram/freebios/obj #payload /code/bootfiles/etherboot/via6105m.ebi option DEFAULT_CONSOLE_LOGLEVEL=9 option DEBUG=1 # Use 256KB Standard Flash as Normal BIOS option RAMTEST=1 option USE_GENERIC_ROM=1 option STD_FLASH=1 #option ZKERNEL_START=0xfffc option ROM_SIZE=262144 # payload size = 192KB option PAYLOAD_SIZE=196608 # use ELF Loader to load Etherboot option USE_ELF_BOOT=1 # Use Etherboot as our payload payload /home/shawnp/bios/etherboot-5.2.0/src/bin/via-rhine.elf # payload /opt/cwlinux/memtest86/memtest ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: EPIA always-on system
On 24/03/2004, at 8:51 PM, ron minnich wrote: On Wed, 24 Mar 2004, Joshua Wise wrote: I am considering building a backpack computer that does MP3 playing, etcetera... I was planning on using the EPIA because LinuxBIOS supports it. Is the EPIA in a state right now where it would be usable for such activity? I believe so. Greg Watson just built linuxbios images today and they are working fine. If you need help just let us know. We can also just send you some 'epia+filo' images which load linux from an attached ext2 formatted CF. Of course, this doesn't mean that I've in any way abandoned PPC for x86... :-) Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: EPIA always-on system
San Jose, 6-8 April. Greg On 24/03/2004, at 8:56 PM, ron minnich wrote: On Wed, 24 Mar 2004, Greg Watson wrote: I'll have 15 or so EPIA's running LinuxBIOS at Clusterworld if you want to take a look :-) oh yeah, reference that, we're in a booth at clusterworld in san francisco. Stop by if you can! it's the DOE booth, sandia+livermore+lanl. Should be good fun. ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: All K8 builds now broken
On 23/03/2004, at 12:50 AM, Eric W. Biederman wrote: Ok I suspect that code came early on and never got cleaned up. What this sounded like was a bug in existing code that caused things to work incorrectly. So at least on the Opteron things worked correctly. We need to go in and add better cpu selection support in the code. What I am thinking it to extract the vendor and model number for the cpu and with that select the code to run similarly to how we handle other devices. Given the number of small details that need to be verified when a new cpu comes out. Microcode on the Xeons, memory controller enhancements on the Opterons, etc I would rather have the build break on a new cpu than have everything just almost work silently. This is probably a good idea, but note that the x86 and ppc architectures do things very differently. To start with ppc doesn't have the hierarchical arrangement that is used in x86. This leads to a much simpler setup, though it does duplicate some code, but in any event I don't want this to change. Also, the pre-C configuration is completely different (romcc is not used). However this is done, it will need to take these architectural differences into account. Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: AMD64+FILO - Detected floating bus
Stefan, Is the floating bus message coming from Filo or LinuxBIOS? Greg On 22/03/2004, at 8:26 AM, Stefan Reinauer wrote: Hi, with LinuxBIOS 1.1.6 and Filo 0.4.1 I am getting a floating IDE bus on the Solo machines now. This has worked before with older versions, but I am not sure what might cause this breakage.. Any ideas? Best regards, Stefan Reinauer -- Stefan Reinauer, SUSE LINUX AG Head of Architecture Development ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: AMD64+FILO - Detected floating bus
Good. That means it wasn't my fault :-). I updated the IDE support in LinuxBIOS recently, so I thought it may have been that. Looks like something must have changed in Filo. Greg On 22/03/2004, at 10:04 AM, Stefan Reinauer wrote: * Greg Watson [EMAIL PROTECTED] [040322 18:01]: Stefan, Is the floating bus message coming from Filo or LinuxBIOS? From Filo. It seems that there are no devices detected on the bus. Strange enough, since the Maxtor harddrive was installed using LinuxBIOS and Filo a while ago.. Stefan -- Stefan Reinauer, SUSE LINUX AG Head of Architecture Development ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: two changes to make building EPIA work
Close, but no banana.
The new rules for options are as follows:
1. Options declared as 'default none' and 'export always' MUST have a
value set or a default value assigned. Any options of this type that
are still undefined when processing of config files is finished will
result in a fatal error.
2. All options declared as 'export always' and those declared as
'export used' that have a value set, or the default value altered, will
result in an entry in Makefile.settings and ldoptions (for numeric
values only.)
3. The appropriate way to test for a variable is '#if VAR==0' or '#if
VAR==1'. Tests using '#ifdef VAR' or '#if defined(VAR)' may produced
incorrect results.
So far I've checked the epia and arima configurations and they build
ok. I'll check the others tomorrow before I commit the changes.
Regards,
Greg
On 22/03/2004, at 3:00 PM, ron minnich wrote:
First, src/include/cpu/cpufixup.h is changed to follow the common
linuxbios usage.
#if CPU_FIXUP == 1
# if (k8==1)
#warning Temporary notice that we are using k8 cpufixup
#define cpufixup(mem) k8_cpufixup(mem)
# elif (k7==1)
#warning Temporary notice that we are using k7 cpufixup
#define cpufixup(mem) k7_cpufixup(mem)
# elif (i786==1)
#warning Temporary notice that we are using i786 cpufixup
#define cpufixup(mem) i786_cpufixup(mem)
# elif (i686==1)
#warning Temporary notice that we are using i686 cpufixup
#define cpufixup(mem) p6_cpufixup(mem)
# endif
#else
#warning YOU DID NOT DEFINE ONE OF: k8, k7, i786, i686
# define cpufixup(mem) do {} while(0)
#endif
note that it is compare to 1, not just an #ifdef. We are leaving the
warning in for a while to make sure people see this. In the EPIA, the
symbol k8 even if defined to 1 would end up needing k8_cpufixup, which
is
wrong.
Just a reminder, make your stuff testing against ==1, not ifdef.
Second, a subtle change in the config tool.
IF: a symbol is always exported and has no default value, AND the
value is
not set by the time the config tool is generating makefile settings,
then
you will get an error, not just a warning.
One error in the EPIA build process was because the symbol 'k8' was
defined but had no value.
I don't think this will break anything, but you never know. Watch your
K8
builds carefully. We're hoping this fixes the latest EPIA problems.
ron
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Updated PPC support
For those interested in PPC issues, I have updated support for the Motorola Sandpoint (G4 processor) in the V2 tree. Over the next few days I will tidy up a few remaining things, but as of now I have the Sandpoint booting a 2.4.24-pre2 kernel. Regards, Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Updated PPC support
At 10:25 AM -0700 1/28/04, Li-Ta Lo wrote: On Wed, 2004-01-28 at 10:03, Greg Watson wrote: For those interested in PPC issues, I have updated support for the Motorola Sandpoint (G4 processor) in the V2 tree. Over the next few days I will tidy up a few remaining things, but as of now I have the Sandpoint booting a 2.4.24-pre2 kernel. Regards, What have you done ? You said you can't boot it yesterday. Ollie A lot can happen in a day... I've actually had LinuxBIOS loading a kernel for a while, but I was trying to get a kernel that would work on the Sandpoint. The main problem was that the startup code was running out of stack space while trying to decompress the kernel (inflate returns FFFD!). Since the stack size is hardcoded in some assembly, it took a while to work out this was the problem. The next thing was that LinuxBIOS was not initializing the superio properly, so even though the kernel re-does this initialization, it was happening too late and causing all kinds of screwy behavior. I'm fixing this now. Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: IDEA: Linux kernel and pcbios compatibility...
At 11:20 AM -0700 12/19/03, Eric W. Biederman wrote: Stefan Reinauer [EMAIL PROTECTED] writes: * Eric W. Biederman [EMAIL PROTECTED] [031219 01:36]: Brainstorming earlier today I think I have found a way to use an linux kernel for the boot loader and to implement pcbios compatibility without too much cost. The idea is to use a uclinux kernel. And implement a ``user space'' aplication that is a user space shim that makes kernel calls. What functionality is it exactly that we need the uclinux kernel for? We won't do any scheduling, and we won't need source code drivers if we implement a pcbios emulation What I liked most about the LinuxBIOS2 approach is that code was only introduced in the tree when it was specifically needed. Since I had my hands at the Alpha bootloader Milo, everything that uses a Linux kernel for it's operations kind of scares me... So this is for the bootloader, the payload and it will be optional. This will not go into the linuxBIOS tree, this is an alternative to etherboot. I would like to see this from the PPC perspective. Since neither filo nor etherboot work on PPC, this might be a good way of booting from, say, a disk. Which would be nice. Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: config - default
I'm looking at it. Greg At 2:27 PM -0700 12/2/03, Eric W. Biederman wrote: ron minnich [EMAIL PROTECTED] writes: this fixup is at the top of next week's list now that sc '03 is over. sc '03 is a major event that pretty much eats up nov. for us, so sorry for the inconvenience. Any head way on this. Especially the formulas which look like they will need a second pass to get right? And of course we still have some dependency problems with the makefiles. I'm not quite there but this is quickly becoming and itch I want to scratch, unless someone is working on this. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
SC03
If any LinuxBIOS'ers are planning to attend Supercomputing'03 in Phoenix next week, please drop by the LANL booth. Ron, Ollie and I will be there with various bits and pieces of hardware to look at, and it would be great to meet some of you in person. If there is enough interest, we could even have an informal BOF. Cheers, Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: config - default
Stefan, Which builds are broken? I thought I checked all configurations built after the change (apart from the VIA which Ron was working on.) and modified any that had problems. My hope was that this change would make the use of options more logical and consistent. The intention is that parts set default values for any options that they require or are specific to the part. Then when all the parts are put together in a target configuration file, these default values can be overridden for the specific build. I was also toying with the idea of allowing some options to be read-only, which I think would address your concern. Apologies for breaking things. I try to build all targets after any change like this to make sure things are still working. Greg At 4:16 PM +0100 11/6/03, Stefan Reinauer wrote: Hi, most of the builds are broken again since config in the mainboard config file now has to be renamed to default. On the one hand I see the reason for most of these changes, even though I am not sure if we want to suggest that some stuff can be overridden in the target config file, like: -option CONFIG_IOAPIC=1 +default CONFIG_IOAPIC=1 Can those changing elementary stuff like this that breaks all builds try to apply some regexps on the Config files so that other builds don't break? Getting further is somewhat hard currently since the code almost instantly breaks after the last fixes are checked in.. Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
device configuration
Hi, Can someone please provide some assistance on the new device configuration setup? For example, how do I configure the IDE controller on a Winbond chip? I used to do this through the enable routine in the chip_control structure but this is no longer used. I've tried using the enable_dev routine, but it never seems to get called. Do I need to do something with the 'pci' configuration statement? What is the purpose of these? I've tried defining 'pci 0:9.0 on' and 'pci 0:9.1 on' but it doesn't make any difference. Thanks, Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Fwd: via datasheets
Can anyone help this guy out? Greg Status: U To: [EMAIL PROTECTED] Subject: via datasheets From: Yugesh [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Date: Mon, 20 Oct 2003 13:07:38 -0700 X-Spam-Score: 0.0 (/) X-Spam-Report: 0.0/5.0 Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to https://sf.net/tracker/?func=addgroup_id=1atid=21 Hi, I don't know if you are able to help or not... I'm trying to get a hold of via datasheets to write some drivers. Specifically I need info on the VT8235 southbridge and vt82623 northbridge (CLE266 on an epia m1). I noticed there was some via / epia code in your freebios code. Do you know where I can obtain information on the via chipsets ? I've tried requesting it from via with no response. Thanks.! ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: V2 Epia report
In the interests of moving forward here, I will see if I can get this
to work with dynamic device tree.
Greg
At 7:25 PM -0600 9/10/03, Eric W. Biederman wrote:
On the PPC, much of what must be done in assembly or romcc on
Intel/AMD, can be
done in C in hardwaremain. The architecture needs to be flexible enough to
accommodate this.
I concur. And the really weird stuff either needs to happen before
we enter hardwaremain or as the first function we call. I have no problem
with doing that. But it should be done that way because it is weird
motherboard dependent code.
For example, I want to be able to configure the serial port on
the superio chip
so that console logging will work. This has to happen before
console_init() is
called. Other things that I want to be able to do that I don't
want tied to PCI
setup are:
- flash setup
- NVRAM setup
- on-board network interface setup
- SDRAM setup
The order goes something like this:
hardwaremain() {
pre_console:
superio()
console_init()
pre_pci:
nvram()
sdram()
flash()
pci:
pci()
usb()
ide()
pre_boot:
fenet()
elfboot()
}
Ok. If everything is working out of ram I can see modifying things
so there is both a hook before console_init, and a hook after it so generic
console code can be used. It is possible to define motherboard
specific console drivers but proposing that as a solution to your
problem is silly.
The ethernet case is not a case I currently understand. I would be
highly surprised if something is needed there. My gut feel is a
simple init method should be all that is needed. Unless you are doing
an ethernet device driver and that is something else again.
In addition, I probably don't want to call cpu_initialize() after
PCI setup. I
would prefer if the cpu (or cpu's) was treated much the same as
any other static
device, then I could choose where cpu_init() gets called, which may be in
multiple places.
I agree they way we are currently dealing with cpus is problematic, as
it does not follow the same model as the rest of the code. There has
not yet been much looking given to how to handle them correctly.
Doing cpu initialization late has not mattered much because if you can
run the code in C generally there are no show stopper cpu bugs or cpu
setup that needs to be worried about.
Otherwise the chip initialization happens twice: once from the call to
chip_configure() and once from dev_initialize(). And it happens at the wrong
place.
There are two kinds of devices. Devices that are highly motherboard
centric, and no matter what you do will have special rules and generic
code cannot cope with them. And then there are devices that are well
factored, and can be treated as independent pieces of hardware.
The generic device tree is aimed at hardware that is well factored, for
the rest we do need a different mechanism.
For a well factored device having it initialized at the wrong place
is almost impossible. Except in the rare cases where the devices is
needed to bootstrap another say the smbus controller for memory, and
in those cases it is the memory or whatever else it is that is not a
standalone device.
The current design is too tied to PCI setup.
I have to vent at this statement. Yes the code was derived from what
is needed to setup PCI devices. But no it is not tied to PCI devices,
and I believe this view is part of what is limiting this conversation.
In particular I see no problem setting up superio I/O devices with
this code.
I try and full fill a couple of requirements with the code.
1) Enable code reuse when the hardware is tied together on another
board in a different way.
2) Enable flexible resource allocation.
3) If I have multiples of the device allow the code to just work.
For an individual device knowing specifically when it is initialized
inspires brittle code.
If I have multiples of the same device the code needs to be able
to hand out dynamic resource assignments.
And yes this results in a little bit of duplicate setup for hardware
like a serial console that is both a generic piece of code and that
must be bootstrapped early.
, doesn't provide any means of doing
initialization other than when PCI devices are initialized and
doesn't give any
control over *when* devices are initialized.
It is assumed the dependencies can be represented in the device tree. If you
are higher up in the tree you are initialized first. And of devices in the
same level of the device tree the order in the static tree pretty much
rules.
chip_configure() allows devices to
choose when in the boot sequence they want to perform some action,
and allows
multiple actions to occur for a single device.
It also provides no structure and it solves none of the hard problems.
As for being able to do things in the boot sequence I have 6 methods
to your 8. Plenty of opportunity to do weird things if need be.
I guess what I would like to avoid
Re: V2 Epia report
At 8:45 AM -0600 9/10/03, ron minnich wrote: On 8 Oct 2003, Eric W. Biederman wrote: The current device resource assignment code should cope with static resource assignments, so hopefully it should be a matter of plugging hard codes into the device tree. no, greg and I will be talking to you about this. There is a problem with that code, which I have alluded to, in that you can not (in the current system) do device assignments etc. before pci enumeration, and it is essential that you be able to do that. Although looking at that code there is another issue. You are using dev_find_device in vt8231.c inappropriately. dev_find_device should be virtually unnecessary in the freebios2 tree. Except when you are very carefully using dev_find_device will fail to handle multiple instances of a device. This is a very bad example to set when doing things properly causes everything to work transparently. legacy code. Has to get fixed. Examples of proper usage welcomed. Although this actually points out a problem with the dynamic tree: it handles complex cases well, simple cases poorly. All I want to do is get into that device BEFORE pci enumeration and set some default values. You can't do that in the current scheme. Yes, I have a similar problem with the current setup. I need to be able to do static initialization on entry to hardwaremain, but before console_init(), and also prior to pci enumeration. Currently static device initialization can only be done during pci setup which is too late. I've started using chip_configure() again to get around this problem, but it means I have to skip the enumerate_static_devices() step or things go to hell. Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: V2 Epia report
At 12:11 PM -0600 9/10/03, Eric W. Biederman wrote:
Greg Watson [EMAIL PROTECTED] writes:
Yes, I have a similar problem with the current setup. I need to be
able to do
static initialization on entry to hardwaremain, but before
console_init(), and
also prior to pci enumeration.
The original conception was that such things would happen before
hardwaremain was actually called. But regardless.
On the PPC, much of what must be done in assembly or romcc on
Intel/AMD, can be done in C in hardwaremain. The architecture needs
to be flexible enough to accommodate this.
Currently static device initialization can only be done during pci
setup which is too late.
Why???
For example, I want to be able to configure the serial port on the
superio chip so that console logging will work. This has to happen
before console_init() is called. Other things that I want to be able
to do that I don't want tied to PCI setup are:
- flash setup
- NVRAM setup
- on-board network interface setup
- SDRAM setup
The order goes something like this:
hardwaremain() {
pre_console:
superio()
console_init()
pre_pci:
nvram()
sdram()
flash()
pci:
pci()
usb()
ide()
pre_boot:
fenet()
elfboot()
}
In addition, I probably don't want to call cpu_initialize() after PCI
setup. I would prefer if the cpu (or cpu's) was treated much the same
as any other static device, then I could choose where cpu_init()
gets called, which may be in multiple places.
I've started using chip_configure()
again to get around this problem, but it means I have to skip the
enumerate_static_devices() step or things go to hell.
Why???
Otherwise the chip initialization happens twice: once from the call
to chip_configure() and once from dev_initialize(). And it happens at
the wrong place.
I can feel that there is pain here. But I cannot see the source.
There are two possible solutions. Either the current structure
needs redesign or I need to more clearly document and explain
the current structure so it can be fully taken advantage of.
The current design is too tied to PCI setup, doesn't provide any
means of doing initialization other than when PCI devices are
initialized and doesn't give any control over *when* devices are
initialized. chip_configure() allows devices to choose when in the
boot sequence they want to perform some action, and allows multiple
actions to occur for a single device.
I'd be happy if the current scheme could provide this functionality,
but I don't see any easy way to do it.
The fundamental problem I see is that Intel/AMD architectures do a
lot more initialization prior to hardwaremain, so the functionality
that I'm looking for is not really needed. Once you're in
hardwaremain, basically all that's left to do is get PCI going. This
is not the case for PPC (and maybe other architectures.) The question
is really: should linuxbios be Intel/AMD specific and required other
architecture support grafted on, or should it be made general enough
to work with any architecture. I guess I'm suggesting the latter.
Greg
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: ep405pc
Update on the ep405pc: getting close! Fixed hardwired address and byte ordering issue with the low-level PIC routines. Now I see: LinuxBIOS-1.1.4 Sat Oct 4 16:54:15 MDT 2003 rebooting... Finding PCI configuration type. Enumerating: Winbond W83C553 Enumerating buses...PCI: pci_scan_bus for bus 0 PCI: 00:00.0 [1014/0156] enabled PCI: 00:09.0 [10ad/0565] enabled PCI: 00:0e.0 [1045/c861] enabled PCI: pci_scan_bus returning with max=00 done dev_configure: Allocating resources... ASSIGN RESOURCES, bus 0 PCI: 00:00.0 14 - [0xfe9ff000 - 0xfebfefff] prefmem PCI: 00:0e.0 10 - [0xfebff000 - 0xfebf] mem ASSIGNED RESOURCES, bus 0 done. Enabling resourcess... PCI: 00:00.0 cmd - 06 PCI: 00:09.0 cmd - 07 PCI: 00:0e.0 cmd - 02 done. Initializing devices... Devices initialized Found W83C553F controller Error: Cannot find W83C553F function 1 device No memory size information! Cheers, Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: V2 VIA EPIA
Oh, I can see what is going to happen to buildrom now that Ron has discovered it... :-) Greg At 11:44 PM -0600 30/9/03, ron minnich wrote: Changes: new epia target for 512k: targets/via/epia/Config.512kflash.lb epia defaults to 256k flash buildtarget now takes either a directory, and uses directory/Config.lb, or takes a file e.g. buildtarget via/epia will use via/epia/Config.lb, and buildtarget via/epia/Config.512kflash.lb will use that file. ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Patch for V2 new config
If my understanding is correct, you want to have an option value that
has a mainboard specific default value, but that can be overridden in
the target configuration file?
If this is the case, then my preference would be to do something like
the following in the mainboard file:
if ~ ROM_IMAGE_SIZE
option ROM_IMAGE_SIZE = 65536
end
where the '~' operator means hasn't been set.
It seems to me this would be clearer than changing a default value,
possibly after the value has already been set.
Greg
At 3:44 PM +0100 1/10/03, Mark Wilkinson wrote:
Hi Ron,
I started looking at building the Via/Epia with the v2, and
noticed that your
last snapshot said that the mainboard Config.lb should set the ROM_SIZE to
265K.
Here's a little patch that lets the config python use
'default OPTION value' tag in the Mainboard Config.lb overriding the value set
in config/Optins.lb (which has ROM_SIZE set to NONE)
or should the command be 'default OPTION=value' in which case, alter the
line for 'rule defaultC: ...' to read
rule defaultC: DEFAULT ID EQ value {{ if(C): mbdefault(ID,value) }}
Regards
Mark Wilkinson.
PS. Hope to burn a V2 epia bios tomorrow morning and test !!
Attachment converted: Macintosh HD:config.patch (TEXT/ttxt) (002EE9D4)
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Patch for V2 new config
Mark,
Understood. The thing I don't like about Ron's solution is that is
relies on an option effectively having two values simultaneously - a
default value and a set value. Being able to modify both these values
independently, then relying on a side effect to determine the actual
value seems a recipe for future problems and confusion. My original
intention was the that default value would just be the initial value
of the option, nothing more than that.
What Ron and you have highlighted is that there is a need for
part-specific default values for options (maybe more than just the
mainboard.) My suggestion is that these default values be dealt with
by either explicitly setting the option value (using the ~ operator)
or through some other explicit mechanism.
One possibility would be to add a Default.lb file in the part
directory (containing lines like 'ROM_SIZE=65536') then in the
target config file saying:
loadoptions
loaddefaults mainboard/via/epia
loaddefaults cpu/i386
The important thing is that these are loaded in the target config
file, before any option values are set.
Greg
At 4:44 PM +0100 1/10/03, Mark Wilkinson wrote:
Hi Greg,
On Wednesday 01 Oct 2003 16:25, Greg Watson wrote:
If my understanding is correct, you want to have an option value that
has a mainboard specific default value, but that can be overridden in
the target configuration file?
Not quite, Ron (I assume it was Ron) already added a line like
default ROM_SIZE 256*1024
to the src/mainboard/via/epia/Config.lb file (there are similar lines for
solo and one other I think) in the CVS snapshot (20031001-1400)
What my patch does is make that line work so that the buildtarget command will
work out of the box (or cvs snapshot) in the targets diretory for
./buildtarget via/epia
The solo and other one (hdama) both have 'option ROM_SIZE ' lines in
their target Config.lb files
I think what was trying to be achived is that the mainboard config file has a
default rom size for the flash part supplied with that mainboard, and if you
want to override it (say you have a larger flash part) you can in the target
config file.
If this is the case, then my preference would be to do something like
the following in the mainboard file:
if ~ ROM_IMAGE_SIZE
option ROM_IMAGE_SIZE = 65536
end
where the '~' operator means hasn't been set.
It seems to me this would be clearer than changing a default value,
possibly after the value has already been set.
Greg
At 3:44 PM +0100 1/10/03, Mark Wilkinson wrote:
Hi Ron,
I started looking at building the Via/Epia with the v2, and
noticed that your
last snapshot said that the mainboard Config.lb should set the ROM_SIZE to
265K.
Here's a little patch that lets the config python use
'default OPTION value' tag in the Mainboard Config.lb overriding the value
set in config/Optins.lb (which has ROM_SIZE set to NONE)
or should the command be 'default OPTION=value' in which case, alter the
line for 'rule defaultC: ...' to read
rule defaultC: DEFAULT ID EQ value {{ if(C):
mbdefault(ID,value) }}
Regards
Mark Wilkinson.
PS. Hope to burn a V2 epia bios tomorrow morning and test !!
Attachment converted: Macintosh HD:config.patch (TEXT/ttxt) (002EE9D4)
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Patch for V2 new config
At 10:20 AM -0600 1/10/03, ron minnich wrote: On Wed, 1 Oct 2003, Greg Watson wrote: If my understanding is correct, you want to have an option value that has a mainboard specific default value, but that can be overridden in the target configuration file? If this is the case, then my preference would be to do something like the following in the mainboard file: if ~ ROM_IMAGE_SIZE option ROM_IMAGE_SIZE = 65536 end where the '~' operator means hasn't been set. It seems to me this would be clearer than changing a default value, possibly after the value has already been set. well, guys, here is how it works not. ROM_IMAGE_SIZE is define in Options.lb (read first) with no default value. In the config (e.g. targets/via/epia/Config.lb) you can set something like: option ROM_IMAGE_SIZE=512*1024 If there is no setting, then what applies is in the mainboard file: default ROM_IMAGE_SIZE=256*1024 however, I did not know about this 'hasn't been set' stuff. Sorry. Greg, I have no problem with that. ron The problem is you're relying on obscure behavior of an option. You're setting (or not setting) an option in the target config file, then subsequently changing it's default value, then using whichever happens to override the other. See my reply to Mark. Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: A limit in V2 for PCI setup
in V1 I used to call the pci ops directly, e.g. extern pci_ops pci_direct; pci_direct.read_dword(...); Presumably this will work in V2 as well. Greg At 12:16 PM -0600 30/9/03, ron minnich wrote: In v2, it is pretty much impossible to do PCI setup BEFORE the PCI scan is called and device trees are built. Sometimes, however, you need to be able to work on PCI before the scan, e.g. to enable certain functions. I don't want this code in mainboard auto.c -- that's a bad way to go. See the below comment. /* we need to do things in this function so that PCI scan will find * them. One problem here is that we can't use ANY of the new device * stuff. This work here precedes all that. * Fundamental problem with linuxbios V2 architecture. * You can't do pci control in the C code without having done a PCI scan. * But in some cases you need to to pci control in the c code before doing * a PCI scan. But you can't use arch/romcc_io.h (the code you need) * because * that has functions with the same name but different type signatures * (e.g. device_t is a struct in C code, and is an unsigned long in * romcc code). * This needs to get fixed. We need low-level pci scans * in the C code. */ I think my fix is to make a copy of romcc_io.h, with different names and type signatures, for use by functions that need to work with PCI before the PCI scan has been done. comments welcome. I'll do this after lunch unless I hear strong counterarguments that will get me what I need. Thanks ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: why are we still doing this?
No need, since it's done automatically now. Greg At 11:26 AM -0600 25/9/03, ron minnich wrote: in arima/hdama/Config.lb ## ## Clean up the motherboard id strings ## option MAINBOARD_PART_NUMBER=HDAMA option MAINBOARD_VENDOR=ARIMA OK, the config tool will create this by default: MAINBOARD_PART_NUMBER=hdama MAINBOARD_VENDOR=arima why do we need to put this type of thing in the mainboard config file? just wondering ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Any story to boot from Hard Disk
Title: Re: Any story to boot from Hard Disk I've used the IDE stream code to boot Linux from and IDE flash. This should also work from any IDE device, though I've not tested it. See freebios2/src/ide_stream.c. Greg At 11:19 AM + 18/9/03, gimyung han wrote: Is anyone tried to boot LinuxBIOS from Hard Disk not using etherboot? I heard that etherboot can also boot ide devices... But I don't know how to do it. Thanks for any help _ ¡±« ¡§½ °¿Â ¸½£Ì Ì«¦' ½« º ¿÷¿¥¦¥. MSN ¡±«/¿ http://www.msn.co.kr/stock/ ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: nested description of chains
Stefan,
This should be a relatively straight forward change to config.g. I
would prefer to see the config format maintained, so I would suggest
using:
htlink 0 mc1
speed = 200
width = 8
end
htlink 0 amd8131-1 end
rather than
htlink 0 mc1 speed=200 width=8
htlink 0 amd8131-1
Let me know if you need any help in implementing it.
Regards,
Greg
At 4:57 PM +0200 12/9/03, Stefan Reinauer wrote:
* ron minnich [EMAIL PROTECTED] [030912 15:06]:
The config language only supports a parent-child relationship, and HT has
a much richer interconnection structure.
Yes. Currently the config tool only allows an acyclic graph for
describing hardware. this does not suit the machine description that
would be needed for hypertransport.
Are you saying that we should reflect this richer topology that HT has in
the config language?
Yes, and I think this does not need to be really complex. See the below
example. Then the romimage class could be extended to write a new file
htlinks.h in case it detects htlink keywords in any device. I'm
currently fighting myself a bit through config.g to see how this can be
done.
I don't think this necessarily should go to the static device tree,
since we would have to use the device tree in romcc code then, which
is not yet possible iirc. (And might bloat romcc code up)
typedef struct htlink
{
int direction; // 0,1,2 for LDT0,1,2
int speed;
int width;
int nodenum; // ht device number of remote component
} htlink_t;
enum {
NORTHBRIDGE,
SOUTHBRIDGE,
PCIBRIDGE,
} htdev_t;
typedev struct htdev
{
htdev_t type; // type
int num; // instance, i.e. the num'th device of type type
htlink_t links[3];
} htdev_t;
htdevs_t **get_htdevs()
{
htdevt_t htdevs[]={
{ NORTHBRIDGE, 0, {
{ 0, 800, 16, 1 },
{ 1, 800, 16, 3 },
{ 2, 800, 16, 4 }, // range 0-3 used by cpus
}
},
{ NORTHBRIDGE, 1, {
{ 0, 800, 16, 0 },
{ 1, 800, 16, 5 },
{ 2, 800, 16, 3 },
}
},
[..]
};
return htdevs;
}
generated from a config file like this:
northbridge amd/amdk8 mc0
pci 0:18.0
pci 0:18.0
pci 0:18.0
pci 0:18.1
pci 0:18.2
pci 0:18.3
htlink 0 mc1 [ speed=default|200|400.. ] [ width=default|8|16 ]
htlink 1 mc3 speed=default width=16
htlink 2 amd8111 speed=600 width=8
end
northbridge amd/amdk8 mc1
pci 0:19.0
pci 0:19.0
pci 0:19.0
pci 0:19.1
pci 0:19.2
pci 0:19.3
htlink 0 mc0
htlink 1 amd8131
htlink 2 mc3
end
northbridge amd/amdk8 mc2
pci 0:1a.0
pci 0:1a.0
pci 0:1a.0
pci 0:1a.1
pci 0:1a.2
pci 0:1a.3
htlink 0 mc3
htlink 2 mc0
end
northbridge amd/amdk8 mc3
pci 0:1b.0
pci 0:1b.0
pci 0:1b.0
pci 0:1b.1
pci 0:1b.2
pci 0:1b.3
htlink 0 mc2
htlink 1 mc1
end
southbridge amd/amd8131 amd8131-1
pci 0:0.0
pci 0:0.1
pci 0:1.0
pci 0:1.1
htlink 0 mc0
htlink 1 amd8131-2
end
southbridge amd/amd8131 amd8131-2
pci 0:0.0
pci 0:0.1
pci 0:1.0
pci 0:1.1
htlink 0 amd8131-1
end
southbridge amd/amd8111 amd8111
pci 0:0.0
pci 0:1.0
pci 0:1.1
pci 0:1.2
pci 0:1.3
pci 0:1.5
pci 0:1.6
superio NSC/pc87360
pnp 1:2e.0
pnp 1:2e.1
pnp 1:2e.2
pnp 1:2e.3
pnp 1:2e.4
pnp 1:2e.5
pnp 1:2e.6
pnp 1:2e.7
pnp 1:2e.8
pnp 1:2e.9
pnp 1:2e.a
register com1 = {1, 0, 0x3f8, 4}
register lpt = {1}
end
htlink 0 mc0 speed=200 width=8
end
Stefan
--
Architecture Team
SuSE Linux AG
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
init_timer()
K8 developers: I've moved init_timer() from hardwaremain.c to the static initialization code in cpu/k8/cpufixup.c as it prevents PPC code from building. Please check that everything still works ok. Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: coding
At 1:32 PM -0600 2/9/03, ron minnich wrote:
anybody object to anonymous enums? I've gotten used to them in Plan 9 and
like them. Instead of this:
#define FLOPPY_DEVICE 0
#define PARALLEL_DEVICE 1
#define COM2_DEVICE 2
#define COM1_DEVICE 3
#define SWC_DEVICE 4
#define MOUSE_DEVICE5
#define KBC_DEVICE 6
#define GPIO_DEVICE 7
#define ACB_DEVICE 8
#define FSCM_DEVICE 9
#define WDT_DEVICE 10
you get this:
enum {
FLOPPY_DEVICE=0,
PARALLEL_DEVICE,
COM2_DEVICE,
COM1_DEVICE,
SWC_DEVICE,
MOUSE_DEVICE,
KBC_DEVICE,
GPIO_DEVICE,
ACB_DEVICE,
FSCM_DEVICE,
WDT_DEVICE
};
The advantages I see
- somewhat less prone to error
- looks nicer
- the big one: enums are first-class objects to the compiler, and
#defines are pertty much ripped out by the compiler and disappear
into constant numbers.
comments?
ron
I think they work well when you have a sequence of numbers like this,
but I would rather see each enum explicitly given it's value as in:
enum {
FLOPPY_DEVICE=0,
PARALLEL_DEVICE=1,
COM2_DEVICE=2,
COM1_DEVICE=3,
SWC_DEVICE=4,
MOUSE_DEVICE=5,
KBC_DEVICE=6,
GPIO_DEVICE=7,
ACB_DEVICE=8,
FSCM_DEVICE=9,
WDT_DEVICE=10
};
Otherwise you're forever trying to work out what the actual value is.
Where it doesn't work is when you have a bunch of random defines with
unrelated values, or values that jump about all over the place.
Greg
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
new config version skew problem
I found the problem that was causing the error with python 2.1. Please test new version. Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Supporting extension ROMs and beyond...
At 6:04 PM -0600 10/8/03, ron minnich wrote: so, in the config file, we have something like: extension pcbios extension vgabios extension elfboot and the system linkes these in via src/extionsions/whatever. They are each run in turn. reasonable? Sounds good, but what does the 'extension' keyword actually do? Is there stuff that needs to be called early on, then after elfboot? Or can it all be done after elfboot? Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linking static to dynamic devices
I'm not on the plane yet... :-)
My suggestion was to add an 'optional' keyword to the cpu device. So
you would declare something like:
cpu k8 cpu0
...
end
cpu k8 cpu1
optional
...
end
cpu k8 cpu2
optional
...
end
cpu k8 cpu3
optional
...
end
The effect of the optional keyword is to call a special function
probe which is added to the chip_control structure. probe() is
called before any calls to enable() and the result (0=success, 0
fail) is used to set a present flag in the chip structure. probe()
should not do anything else except check for existence (any other
configuration is done in enable()). Non-optional devices always have
their present flag set to 1.
struct chip_control {
void (*enable)(struct chip *, enum chip_pass);
int (*probe)(struct chip *);
char *path; /* the default path. Can be overridden
* by commands in config
*/
// This is the print name for debugging
char *name;
};
struct chip {
struct chip_control *control; /* for this device */
int present; /* device is present */
char *path; /* can be 0, in which case the default is taken */
char *configuration; /* can be 0. */
int irq;
struct chip *next, *children;
/* there is one of these for each INSTANCE of a chip */
void *chip_info; /* the dreaded void * */
};
Greg
At 7:54 AM -0600 5/8/03, ron minnich wrote:
The next obvious step is to link static to dynamic devices.
One issue is that we define CPUs statically, up to the maximum the
mainboard can take. But they may not be there. How do we express this?
Greg had some ideas, so he may jump in once he gets off the plane.
I do think the new static architecture will allow for things like
cpufixup() calls per-cpu, etc. but we'll see.
ron
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Weird behaviour with new config method
At 2:56 PM -0600 4/8/03, ron minnich wrote: On 4 Aug 2003, Eric W. Biederman wrote: Previously when we had this conversation we tried for a minimum python of 1.5 and the old config tool manages that. We may need to bump the python requirement but we this needs investigation to see why the earlier versions of python have problems. we're going to have to bump minimums anyway. romcc fails for me on RH 7.3. ron It'll have to be version 2.0 at a minimum since yapps (and config.g) depends on some 2.0 features. It maybe a later version depending on what Eric's problem turns out to be. Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
static initialization
Stefan,
I've added the ability to name parts. This means that you can do the following:
cpu k8 cpu0
register south = sb0
register east = cpu1
end
cpu k8 cpu1
register south = ...
register east = ...
end
southbridge device/vendor sb0
end
In the k8 directory you will need to add 'config chip.h' to
Config.lb, then create a chip.h that contains something like:
#ifndef _CPU_K8
#define _CPU_K8
extern struct chip_control cpu_k8_control;
struct cpu_k8_config {
struct chip *south;
struct chip *east;
any other stuff
};
#endif /* _CPU_K8 */
Then add an object that contains the code that deals with
'cpu_k8_control' (see superio/NSC/pc97307/superio.c for an example).
Hopefully this will allow you to deal with the hyperchannel setup stuff.
Things that still need to be done/other changes:
1. The above scheme assumes that all cpu's actually exist, which may
not be the case. Only the first cpu can be relied on to exist. So we
need to think about the best way to indicate that subsequent cpu's
are optional. One way might be to add the keyword 'optional' to the
definition. e.g.
cpu k8 cpu1
optional
register south = ...
register east = ...
end
We could add an extra pass to the chip_configure() routine called
CHIP_PASS_PROBE that is called for all devices that are marked
optional. It would then be up to the individual device to check for
its existence. This could set a flag that means the enable() entry
point is called on subsequent passes for the device.
One problem with this approach is that you've already set the 'south'
field to point at cpu1. If cpu1 doesn't exist then the probe code
would need to set this field to 0.
Let me know what you think.
2. Ron is testing replacing:
cpu p5 end
cpu p6 end
cpu k7 end
cpu k8 end
with just 'cpu k8 end', then using the 'dir' command in the k8
Config.lb file to include support for k7, p6, p5. This will hopefully
prevent spurious devices from being included in the static tree.
3. You now must declare:
extern struct chip_control part_vendor_device_control;
in the part specific chip.h file.
Cheers,
Greg
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: new config tool, static and dynamic trees
Stefan,
Sorry about that. I'll #define this better so that it's not required
with the old configuration system.
The 'register' directive has changed slightly, but hasn't been
updated in the tree. I've checked in the new version now.
Greg
At 3:54 PM +0200 24/7/03, Stefan Reinauer wrote:
* ron minnich [EMAIL PROTECTED] [030724 01:02]:
Greg has implemented the static tree/dynamic tree code mentioned
yesterday, and today it passed its first test with flying colors.
I am still fighting this, since it broke NLBConfig in a way that is
probably not worth fixing (it's missing the static_root completely,
and we might not want to keep that in a generated file as well as in
the config file):
[..]
linuxbios_c.o(.text+0x203e): In function `hardwaremain':
: undefined reference to `static_root'
[...]
The new config method fails, but I can't seem to find the wrong line in
the config file.
~/LinuxBIOS/freebios2/targets ./buildtarget arima/hdama/
Configuring TARGET hdama
Will place Makefile, crt0.S, etc. in arima/hdama/hdama
Configuring ROMIMAGE fallback
Configuring DIR /config/Config.lb
Configuring DIR /lib/Config.lb
Configuring DIR /console/Config.lb
Configuring DIR /stream/Config.lb
Configuring DIR /devices/Config.lb
Configuring DIR /pc80/Config.lb
Configuring DIR /boot/Config.lb
Configuring PART mainboard, path arima/hdama
Configuring PART arch, path i386
Adding init file: config/crt0.base
Configuring DIR lib/Config.lb
Configuring DIR boot/Config.lb
Configuring DIR smp/Config.lb
End PART arch
WARNING: Option CONFIG_SMP using default value 0
Configuring PART northbridge, path amd/amdk8
End PART northbridge
Configuring PART southbridge, path amd/amd8111
End PART southbridge
Configuring PART southbridge, path amd/amd8131
End PART southbridge
Configuring PART superio, path NSC/pc87360
Trying to find one of '=' on line 153:
end
^
List of nearby tokens:
(@3368) SOUTHBRIDGE = 'southbridge'
(@3380) PATH = 'amd/amd8111'
(@3392) END = 'end'
(@3396) SOUTHBRIDGE = 'southbridge'
(@3408) PATH = 'amd/amd8131'
(@3420) END = 'end'
(@3466) SUPERIO = 'superio'
(@3474) PATH = 'NSC/pc87360'
(@3487) REGISTER = 'register'
(@3496) STR = '.com1={1}, .lpt=1'
=== ERROR: Could not parse file
arima/hdama/Config.lb:0
mainboard/arima/hdama/Config.lb:0
Any idea?
Thanks,
Stefan
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
AMD package/part numbers
Any idea how to translate an AMD package number to an AMD part number? I have a flash part that is marked D323GB90V1 but I can't find anything on the AMD site that helps translate this to a part number, short of reading every data sheet. Thanks, Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: static and dynamic devices (again)
At 2:54 PM +0800 23/7/03, ollie lho wrote: On Wed, 2003-07-23 at 12:08, ron minnich wrote: We thus have a static tree (representing the static resources) with links at certain places to the dynamic tree (representing dynamic resources). LinuxBIOS can do device-specific operations on devices in the static tree, and can attach dynamic devices to nodes in the static tree. On the whiteboard in Greg's office, this setup makes lots of sense. We'll see how it is in practice. Does this mean you have a device tree with STATIC nodes and DYNAMIC nodes ? Does your code have to distinguish between static nodes from dynamic ones when traveling the tree ? Is my imaginary of the scenario as the following correct ? 1. Device tree with static node is build at compile time. (with some nodes marked dynamic extensible). 2. Travel the tree to init static node, for dynamic extensible nodes, grow the tree. 2.1 Init the dynamic nodes. 3. Travel the tree again to do post-pci (whatever you call it) init for static nodes. Originally I was going to try using a single node type for both dynamic and static devices, but it turns out that there is very little in common and it seems to make more sense to keep them separate. Your scenario is correct, though I'm thinking that the static tree will be the primary data structure and the dynamic tree will be attached to a node the same way as other device-specific data. So the static tree will not grow, just be populated with data. Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: static and dynamic devices (again)
Thanks Ron, post this tome at 10pm so I have to stay up late... As Ron points out, I spent some time today seeing if it was possible to unify the static and dynamic device code. It certainly is possible, but it turns out that we're trying to do things in two fundamentally different ways. The result is that we just push the separation between the two types of devices down another level. I'm not sure is something that we want to do, because it just makes things more difficult to understand. My feeling is that keeping them separate is probably the way to go. Modifying the current device code so that dynamic trees can hang off a static device (such as a northbridge) will solve some problems that are on the horizon. This will also allow code development to move forward without major changes, but not preclude unifying the two schemes in the future if it becomes necessary. I'm also interested in any comments on this approach. Greg At 10:08 PM -0600 22/7/03, ron minnich wrote: Greg has spent the day exploring options for how to merge the static and dynamic device trees in LinuxBIOS, per Eric's comments. He wrote a substantial amount of code, which at this point we may not commit. The goal of the code was to see if it makes sense to merge the static and dynamic trees. I am not convinced such a merger makes sense. Discussion follows. The problem is this: on a given motherboard, there are a static set of devices, such as northbridges, southbridges, so on: these are soldered to the board. Then there are dynamic devices, plugged into PCI slots. On a motherboard, we know that the static devices are there, and we even know a lot about them, such as what certain registers do. We need on the motherboard to initialize components of the static devices. In other words, we have knowledge about: o the type of the device; o instances ofthe device; o special operations we need to do to the device to modify internal state (e.g. turn off the IDE controller, turn on Ethernet, etc.) o special control information that is highly device-specific These operations are operations that we have to do because the OS assumes they will be finished when the OS starts, or we need to do them to initialize things, such as DRAM. Dynamic devices are known only in a generic fashion. In LinuxBIOS, the sum total of our knowledge of dynamic devices is the Base Address Register set, the Command register, and possibly (in future) the IRQ. LinuxBIOS has no knowledge of device-specific I/O registers. For dynamic devices, LinuxBIOS does a few generic operations and lets the OS do the rest. So for dynamic devics we know about: o instances of the device o Generic control information that is not device-specific So, to sum up: for static devices, LinuxBIOS needs knowledge that goes beyond what the OS knows, and will perform device-specific operations based on internal knowledge LinuxBIOS has about the device. LinuxBIOS will maintain information about the type of the device and all instances of the device. In many cases, LinuxBIOS will do operations on the device that the OS is not capable of doing. For dynamic devices, LinuxBIOS only does the most general configuration, and has no knowledge of device internals. The OS manages device-specific operations. The dichotomy is pretty clear. It is kind of like a house. There are walls and floors and outlets and phone jacks. These are fixed (static). Then there are chairs and lights and phones. These are dynamic. You know all about the phone jacks, but you don't know about what phones are plugged in, and the phones change all the time, especially if you have children in the house. The static devices (walls) are a fundamentally different thing than the dynamic devices (chairs). We are calling static devices 'chips'. Chips are structured as follows: there is a chip_control structure for a TYPE of a chip, with generic information about the chip and a pointer to a control function that is specific to that chip. Then, for each instance of the chip, there is a chip structure that contains a pointer to the chip_control structure and information specific to the INSTANCE of the chip. Think of chip_info as the class definition, and chip as instantiations of the chip. Chips are statically declared and initialized, and form a tree with a root at the mainboard, with sibling pointers for chips at the same level -- e.g., two devices hung off the same southbridge are siblings. These structures are filled out at compile time. Dynamic devices are called struct device. There is (currently) a device struct allocated dynamically for each function on a device. [digression: The PCI heritage of devices is very clear once you start looking at them. This is reasonable, as even on HyperTransport everything looks like a PCI device. But it may bite us at some point.] Devices also form a tree, with children, parents, siblings, etc. One assumption we've noticed in the device code is that of a 'root bus'. Properly, this should
Re: Assembly code errors [PMX:#]
This is what the new configuration scheme in freebios2 does. Greg At 2:25 PM -0700 18/7/03, Dave Ashley wrote: When I write some assembly code and I've got the syntax wrong, the build fails but the line numbers reported in error messages don't relate to the source I'm working on. I'm wondering could the build process for the assembly code be changed so the python script creates a global toplevel.asm file that has within it #includes for all the source files? So rather than cat'ing all the files, you let the compiler include them, so its error messages will be informative. There's nothing especially bad about ASM code development, but things like accurate error reporting can make it easier (or harder when absent). -Dave ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: ppc linuxbios support
Title: Re: ppc linuxbios support Hi Ramkumar, Ports to new boards, or suggestions on how to make the PPC code more modular and robust are always appreciated. You might want to start by getting linuxbios booting a linux kernel on the 755. This shouldn't be too difficult, as the 755 appears to use the same northbridge as the 7410. I used the MontiVista linux as it was already ported to the Sandpoint, though I had to make a few patches to get it to boot with linuxbios. Let me know when you get to this point and I can send you the patches. I've just ordered an EP405PC from EmbeddedPlanet which will be my next port. It uses the IBM PPC 405Gpr chip which is sufficiently different to the 7410 to be challenging. Hopefully this week I'll have the PPC version working under the new configuration system (check out freebios2 instead of freebios). This is going to allow us to build a static device tree which can be passed to linux. Heiko Schick and I have been discussing the possibility of mapping this device tree to an Open Firmware device tree that can then be used to boot linux on an OF system (such as Power Mac's). Stefan Reinauer has reminded me that we should work with the openbios community on this, though looking at the IEEE 1275 spec (all 250+ pages) I think they've got a big job ahead. :-) Cheers, Greg I would be interested in helping out in the testing/development of the PPC BIOS. Also, have access to sandpoint 755. Let me know if I can help. Thanks Ramkumar
RE: LinuxBios PPC-support.. U-Boot project
Yes, and the nice thing about the linuxbios architecture is that the CLI can just be a payload, so you can have any CLI that you want - forth, tcl, whatever. No changes are required to linuxbios at all. Greg At 6:03 PM -0700 24/6/03, Frank wrote: As I said before, If you want to convert the u-boot users, you have to provide an option to go to a command line instead of just unconditionally booting linux. Getting to a command line is not rocket science... --- Gregg C Levine [EMAIL PROTECTED] wrote: Hello again from Gregg C Levine I agree in principle Ron, but I am curious as to why they thought that. After all, Linux BIOS does more for a system then U-Boot. It's my guess that after seeing the appropriate demonstrations that group will change their minds, collectively or otherwise. For that matter, Greg W, I applaud your efforts regarding the PPC port. --- Gregg C Levine [EMAIL PROTECTED] The Force will be with you...Always. Obi-Wan Kenobi Use the Force, Luke.Ý Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) -Original Message- From: [EMAIL PROTECTED] [mailto:linuxbios- [EMAIL PROTECTED] On Behalf Of ron minnich Sent: Monday, June 23, 2003 5:47 PM To: David Eliasson Cc: [EMAIL PROTECTED] Subject: Re: LinuxBios PPC-support.. U-Boot project On Tue, 3 Jun 2003, David Eliasson wrote: I read on the linuxbios webpage about PPC-support.. Aren t you guys aware of the U-boot project? Sure. They've been running the GNU Linux kernel 2.4.19 and 2.4 21 in firmware for a while now.. Maybe I m just missing something, but I thought some merging of efforts might be in place.. I tried to have a conversation with somebody from u-boot about some sort of merge, but it never got beyond the why u-boot is better than linuxbios stage, so I dropped it. ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: LinuxBios PPC-support.. U-Boot project
At 3:47 PM -0600 23/6/03, ron minnich wrote: On Tue, 3 Jun 2003, David Eliasson wrote: I read on the linuxbios webpage about PPC-support.. Aren t you guys aware of the U-boot project? Sure. They've been running the GNU Linux kernel 2.4.19 and 2.4 21 in firmware for a while now.. Maybe I m just missing something, but I thought some merging of efforts might be in place.. I tried to have a conversation with somebody from u-boot about some sort of merge, but it never got beyond the why u-boot is better than linuxbios stage, so I dropped it. I spent some time looking at PPCBoot (now called u-boot) before I did the PPC port of linuxbios, but in the end I didn't use much. Most of the hard stuff came from another open source bios project called GBios, particularly the PCI code. The major advantages that linuxbios has over u-boot is the flexibility it provides in configuration management, and now that it has been ported to 3+ architectures, the architecture dependencies are particularly well defined. Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: timer.h - No such file or directory
Sorry, my fault. This a new version of ide.c (and .h) which I've backported from Etherboot 5.1.8. You can just remove the #include. I'll check in the new version now. Greg At 1:19 PM -0700 8/6/03, roger wrote: Using the smartcore-p5 tree: gcc ... -o ide.o /home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c /home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:27:19: timer.h: No such file or directory I'm seeing a freebios/src/etherboot/timer.h freebios/src/arch/ppc/include/timer.h but nothing for the i386/ -- Roger http://www.eskimo.com/~roger/index.html ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: timer.h - No such file or directory
Actually there was some other stuff that was PPC dependent. Hopefully the version I've just checked in isn't. Greg At 3:03 PM -0600 8/6/03, Greg Watson wrote: Sorry, my fault. This a new version of ide.c (and .h) which I've backported from Etherboot 5.1.8. You can just remove the #include. I'll check in the new version now. Greg At 1:19 PM -0700 8/6/03, roger wrote: Using the smartcore-p5 tree: gcc ... -o ide.o /home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c /home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:27:19: timer.h: No such file or directory I'm seeing a freebios/src/etherboot/timer.h freebios/src/arch/ppc/include/timer.h but nothing for the i386/ -- Roger http://www.eskimo.com/~roger/index.html ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: PPC
Andrew, Current version is checked in. I'll be making some changes to the startup code over the next few days though. Cheers, Greg At 3:49 PM +0800 6/6/03, Andrew Ip wrote: Hi Greg, Just thought you might like to know that I booted a linux kernel using linuxbios on a PPC yesterday. There are still a few issues to sort out, but it's looking very promising. Sounds great. I have a TX3927(MIPS) with me and would like to see if it is possible to port LinuxBIOS on it. Are all the PPC code in the cvs? -Andrew -- Andrew Ip Email: [EMAIL PROTECTED] Tel:(852) 2542 2046 Fax:(852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
PPC
Just thought you might like to know that I booted a linux kernel using linuxbios on a PPC yesterday. There are still a few issues to sort out, but it's looking very promising. For those that are attending USENIX next week, I'll have the machine at the BOF so you can see it really works! Cheers, Greg ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Information about BIOS and the boot process
Other people probably know much more about this than me, but here's
my experience.
There seem to be two main parts to linuxbios. The first is
arch/{arch}/config/ctr0.base which does the very low level
initialization, like turning on memory, etc. The second is
arch/{arch}/lib/c_start.S which does whatever else is necessary to
call the C function hardwaremain(). hardwaremain() then does whatever
else is necessary to load linux.
c_start.S is linked with linuxbios.a, a library containing generic
support routines (those found in the lib directory) and anything
specified using the 'object' directive in a Config file (and other
stuff). The resultant 'executable' is called linuxbios_c. The loader
script used to link linuxbios_c is config/linuxbios_c.ld, and is
configured to be loaded relative to _RAMBASE.
crt0.base is not linked against anything. Any additional assembly
routines you need must be specified using the 'mainboardinit'
directive in a Config file. This causes the specified assembly file
to be added to crt0_includes.h which is in turn included at the
start of crt0.base (or at the end in the case of the ppc version).
The loader script used to link crt0.base is in
arch/{arch}/config/ldscript.base. The resultant 'executable' is
called linuxbios and will be loaded at _ROMBASE. The tricky thing is
that this loader script will also load the linuxbios_c 'executable'
at a location called _payload in this file. The main task of
crt0.base is then to initialize enough hardware so that this payload
can be copied from rom into ram (which may also involve uncompressing
code). Then control is transferred to _start, which is the first
location in linuxbios_c.
To get an idea of how crt0.base works, look at the following files.
This is the order of execution specified by the configuration file
for sis735.
cpu/i386/entry16.inc
cpu/i386/entry32.inc
superio/sis/950/setup_serial.inc
pc80/serial.inc
arch/i386/lib/console.inc
cpu/k7/earlymtrr.inc
northsouthbridge/sis/735/raminit.inc
arch/i386/config/crt0.base
Next look at c_start.S which will show you what happens once control
is transferred to _start. Finally, look at
arch/{arch}/lib/hardwaremain.c to see what other stuff is done to get
linux loaded.
Most other files are specific to particular hardware, so it can be
pretty confusing to just browse the tree.
Hope this helps,
Greg
At 7:00 PM +0500 3/28/03, [EMAIL PROTECTED] wrote:
Agreed, I am also looking for a good documention.
Atleast the flow in terms of implemented functions
or assembly code and some kind of Do's and Dont's
if any.
One good advantage would be more and more people
would be easily aware about the code architecture and
would get invovled in LinuxBIOS if one is interested.
[EMAIL PROTECTED] wrote
I am writing some code to fixup the video chipset trident
cyberblade and V1621 RGB-CS encoder ,
and also trying to fix the IDE_BOOT for my mainboard (B860T or EPIA), so
I am looking for information
about the real bios process, and about the layout of the common bios
files, and of course, any information
about bios as possible.
My main problem is to find good documentation about the post, the boot
process.
I read on some places which the CS is set F000 and EIP FFF0, so
in other websites I had seen CS is FFF0,
in other 000F , causing some confusion with me.
I need some documentation about 20bits addressing lines, and the GATE
A20 function also.
Tanks in advance.
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
