Vijay Kumar Avadhanula <[EMAIL PROTECTED]> writes: > Hello, > We are a group of people working on > > developing a system based on 32 bit RISC processor and > PCI based peripherals. Planned Configuration is like > this, > There is a host bus connecting processor and memory > which in turn is connected to PCI bus interfacing > SVGA, Ethernet (NIC)and SCSI controller. Floppy, CDROM > and Hard disk are SCSI based. Could you suggest to > what extent/ what level information is required in > order to use linux bios in the above mentioned > configuration. Means can we avoid any vendor specific > dependency while developing the system. Looking for > some guidelines, > With thanks
My apologies for the delay. Occasionally I get really busy and this is why I ask people to CC the LinuxBIOS mailing list. I have not specifically built hardware with LinuxBIOS in mind but I have certainly done a lot of ports, to varying hardware. So I will answer the question as what would need to be done to port LinuxBIOS to your proposed platform from which any design requirements should be straight forward to derive. When I start bringing LinuxBIOS up on a board there are thre things I worry about. Being able to flash new version of the firmware, being able to debug my code, and being able to find documentation for all of the hardware. If someone else manufactures the hardware Documentation exists. The big question for me is will the give it to me, and will it be sufficiently non-encumbered so I can write GPL'd code from the documntation I receive. So if you are designing a system with LinuxBIOS in mind it might be a good idea to verify the selected hardware parts meet this criterian. In some cases it is possible to look at the hardware and deduce how to set it up correctly from software but that is fairly time consuming. If the hardware is initially brought up with LinuxBIOS you want an ICE (In Circut Emulator), to debug the motherboard. An ICE gives you the flexibility very fine control and a lot of detailed information so you can determine if the hardware is setup wrong of if it is just a problem in the firmware. When I am not worrying about the hardware having a serial console is extremely convinient. On x86 the serial port interface is not dma driven, and quite simple so you can embed debugging output anywhere including the assembly code for doing memory setup. Additionally the fact that it is trivial to log and read all of the serial output makes debugging convinient. On the ROM side, at a minimum it should be socketed (at least for the development system). So that when a bad version of the firware is produced it is straight foward to test a different version. Another area to consider is ROM size. On x86 LinuxBIOS compiles into the 32 - 48 KByte range on a dual processor server board. So the core is small. When you enable advanced features like two copies of LinuxBIOS and the ability to boot from other devices beides your ROM chip the size can go up considerably. In particular having enough space to place a Linux kernel in flash so you can use it as a bootloader is very convienient. On alpha with a 2MByte flash I have succesfully placed 2 copys of the Linux kernel in my flash chip. In many cases it is not desireable to hard code all of the hardware settings into LinuxBIOS but instead provide the End-User with some control. On x86 this capability is provided with the CMOS and a clear CMOS jumper. There are 128 bytes of persistent data, are used to store various settings. And a clear cmos jumper that is used to signal the firmware to switch to it's safest default values. This option storage could also easily be provided in a flash chip. Once I have a setup for building LinuxBIOS, so that I can debug and update my code the next thing I do is to enable RAM. Generally this must be done in assembly language, because other programing languages require a stack. This can be implemented in C if you have the capability of locking cache blocks. The complexity of this process varies a lot with the question of is the memory replaceable or do you always use the same memory on the motherboard. If the user can plug in random memory modules things can get quite challeging. After memory is setup the rest of LinuxBIOS can be written in C. And we start getting into serious code reuse territory. After memory setup the current LinuxBIOS code assigns resources to PCI devices, and sets countless enable bits so the hardware will be useable. The a table is written to memory describing things such as memory size that are not hard coded by the architecture. And a simple bootloader boots something. The in memory table is designed to model the motherboard to motherboard differences, so simple design variations can easily be handled. I hope this helps, and be free to ask more questions, Eric > Vijay > --- "Eric W. Biederman" <[EMAIL PROTECTED]> wrote: > > Vijay Kumar Avadhanula <[EMAIL PROTECTED]> writes: > > > > > I am handling a work where linux is to be ported > > onto > > > a custom made processor. Before taking up the work > > we > > > also have to design the motherboard with minimum > > > peripheral support. > > > I need some help from anyone who must have had > > some > > > experience in this area, like what are the things > > > important in designing/ considering the mother > > board, > > > and what are the issues related to bios and then > > in > > > turn Linux. We would like to have some PCI based > > > contollers on the board. I will be thankful for > > some > > > pointers. > > > With best > > > > A big question piece of information you are giving > > is what > > processor architecture your custom made processor > > supports. Usually a > > processor architecture implies a set of standard > > devices that should > > be supported (like interrupt controllers). > > > > Today most motherboards contain just a handful of > > chips, a chipset > > that support memory and all of the standard > > perpherials. Instead of a > > having one chip for each individual device. > > > > So what architecture, and what kind of users are you > > targeting? We > > need that information before we can give any kind of > > good advice. > > > > The idea of a custom processor today I find > > questionable. My basic > > observation has been that the number of processors > > seems to > > consolidating on just a couple of designs so their > > builders can get > > good economies of scale. > > > > Eric > > > > > > > __________________________________________________ > Do You Yahoo!? > Got something to say? Say it better with Yahoo! Video Mail > http://mail.yahoo.com
