coreboot

coreboot@coreboot.org

12 participants
39779 discussions

romcc ramblings...
by ebiederman＠lnxi.com 25 Jun '03

25 Jun '03

Romcc is coming along quite nicely. I keep fixing a corner case here and there but it quite usable and getting more so. One area where it falls short is in it's handling of lots of small variables. The classic question is: If I declare my small variables to be chars will romcc be able to store them in both AL and AH? And unfortunately the answer is no. Using the AH, BH, CH, and DH at least when I tried it did not work well. Treating all of the registers the same seems to work much better. A similar question is can romcc pack 2 byte values in a random register? The answer again is no. But for a different reason extracting and reinserting the values requires an extra register, so it is not a transformation I want to perform automatically. With that being said I do think it is worth having romcc support keeping multiple values in a register. Otherwise I will wind up writing a bunch of macros like: #define LATENCY(MIN) (((MIN) >> 8) & 0xff) #define SET_LATENCY(MIN, LATENCY) ((MIN) = (((MIN) & ~(0xff << 8)) | (((LATENCY) & 0xFF) << 8))) #define CYCLE_TIME(MIN) ((MIN) & 0xff) #define SET_CYCLE_TIME(MIN, CYCLE_TIME) ((MIN) = (((MIN) & ~0xff) | ((CYCLE_TIME) & 0xFF))) Which look ugly are a bit of a pain to write. I looked an C actually has a mechanism to do this already. bit fields in structures. For doing I/O to the outside world they are not portable. So their use is discouraged. For internal values that are just going to be used internally by a program, say packing multiple values in a single register they are portable and a decent way to describe what is going on. So to keep 2 byte values in I register I could do: struct { unsigned latency:8; unsigned cycle_time:8; } min; I have not implemented this but I plan to. For both programmer control and ease of use it looks like a win. Eric

1 0

romcc ramblings...
by ebiederman＠lnxi.com 25 Jun '03

25 Jun '03

Romcc is coming along quite nicely. I keep fixing a corner case here and there but it quite usable and getting more so. One area where it falls short is in it's handling of lots of small variables. The classic question is: If I declare my small variables to be chars will romcc be able to store them in both AL and AH? And unfortunately the answer is no. Using the AH, BH, CH, and DH at least when I tried it did not work well. Treating all of the registers the same seems to work much better. A similar question is can romcc pack 2 byte values in a random register? The answer again is no. But for a different reason extracting and reinserting the values requires an extra register, so it is not a transformation I want to perform automatically. With that being said I do think it is worth having romcc support keeping multiple values in a register. Otherwise I will wind up writing a bunch of macros like: #define LATENCY(MIN) (((MIN) >> 8) & 0xff) #define SET_LATENCY(MIN, LATENCY) ((MIN) = (((MIN) & ~(0xff << 8)) | (((LATENCY) & 0xFF) << 8))) #define CYCLE_TIME(MIN) ((MIN) & 0xff) #define SET_CYCLE_TIME(MIN, CYCLE_TIME) ((MIN) = (((MIN) & ~0xff) | #((CYCLE_TIME) & 0xFF))) So many times while in your registers you have enough bits to hold everything you want to hold Theoretically

1 0

re: coherent hypertransport enumeration on opteron
by YhLu 25 Jun '03

25 Jun '03

Eric, The RAM on CPU1's northbridge can go through now. I mistype several 0x19 to 0x18. I have enabled the SMP support in Config file. option CONFIG_SMP=1 option MAX_CPUS=2 option SMP=1 As for the missing functions. I have copied secondCPU.S and udelay related files to the freebios2. The result is it can not jumping into LinuxBIOS again. In the Config last line you said something need to be fixed up. Do I need to change the START_CPU_SEG ? Regards Yinghai Lu

3 2

Re: coherent hypertransport enumeration on opteron
by YhLu 25 Jun '03

25 Jun '03

Eric, Do you plan use CONFIG_SMP to substitute SMP? Regards Yinghai Lu -----邮件原件----- 发件人: YhLu 发送时间: 2003年6月24日 16:37 收件人: 'ebiederman(a)lnxi.com' 抄送: ron minnich; Stefan Reinauer; linuxbios(a)clustermatic.org 主题: re: coherent hypertransport enumeration on opteron Eric, The RAM on CPU1's northbridge can go through now. I mistype several 0x19 to 0x18. I have enabled the SMP support in Config file. option CONFIG_SMP=1 option MAX_CPUS=2 option SMP=1 As for the missing functions. I have copied secondCPU.S and udelay related files to the freebios2. The result is it can not jumping into LinuxBIOS again. In the Config last line you said something need to be fixed up. Do I need to change the START_CPU_SEG ? Regards Yinghai Lu

2 1

Re: Laptops?
by Bari Ari 25 Jun '03

25 Jun '03

Jeff Carr wrote: >I don't know any more than the output of lspci. I've not tried to open >up the case to see the full board. I've still not been able to get power >management to work after re-installing it with debian. (sound, USB 2.0 >and ethernet work ok.) > >Jeff > >FYI: The portable came without any sources. I sent a inquiry about how >to get them on the website of the people that sold the machine to me, >but no one responded. (A HUGE GPL violation.) When I re-installed with >debian, I found the power management(and several other drivers) were >only in the lindows kernel and I not been able to get them to work >since. It doens't look like they drivers from the lindows kernel are in >any of the kernel sources I can find. So, in that regard, angry about >how "linux support" was provided for this portable would be too light of >a description. > > Not surprising on the loss of power management when you dropped Lindows. They are probably using a laptop super I/O with a keyboard controller (8051 micro with lots of GPIO) by SMSC or a micro by Renasas or Fujitsu to handle the keyboard scan and power management. Some descriptions of the firmware and what they use these micros for: http://www.insydesw.com/solutions/pc/keyboard.htm http://www.phoenix.com/en/products/phoenix+cme+firstbios/system+firmware/te… -Bari

1 0

Re: K7SEM Serial Boot Log....What next...
by Alex Scarbro 24 Jun '03

24 Jun '03

Based on the Sis 630 HOWTO by Ron Minnich. HOWTO written by Brenden Bixler This file contains instructions for the K7SEM, Socket 7 (k7/Duron) based mainboards. Unfortunately, there is a step in this HOWTO that could be hazardous. The hazards include (but are not limited to) 1) destroying your motherboard 2) hurting yourself 3) killing yourself Because of these hazards, you must take full responsibility if you decide to install LinuxBIOS following these procedures. Neither Los Alamos National Labs or any lab personnel can be held responsible for any adverse consequences of your attempt to follow these procedures. WARNING: We assume you've built kernels, know how to open up your PC, and how to yank the flash part out while power is on and put in a different part. There is NO WARRANTY, express or implied, with this software. In fact, if you don't know what you're doing, and you get careless, you're going to end up with a nice paperweight instead of a motherboard, an emergency room bill, or a funeral service. YOU HAVE BEEN WARNED. Additional information available at: http://www.acl.lanl.gov/linuxbios/ Linux distribution: Most modern distributions are supported. This HOWTO tested using RedHat 7.2 Other software notes: You MUST have 'as' version 2.9.5 or later. You MUST have ssh to connect to sourceforge Recommended: you might want to get a 32-DIP Zero Insertion Force (ZIF) socket for the flash part. This makes taking out flash and putting in Disk On Chip much easier. You need to have a LinuxBIOS machine (the machine that runs LinuxBIOS) and a build machine (which will let you build LinuxBIOS). These can be one and the same machine. In this HOWTO we assume they're the same. We nevertheless refer to a 'build' machine and 'LinuxBIOS' machine in case you want to use a different machine. Also, freebios and LinuxBIOS still share the same source tree. We use the name 'LinuxBIOS' where it makes sense, and 'freebios' otherwise. But they are the same source base. ---- The steps for loading LinuxBIOS are simple: 1) Get Linux installed on your LinuxBIOS machine. 2) Get LinuxBIOS source from Sourceforge. 3) Get a 2.4.0 kernel, patch it, then compile. 4) Configure and build LinuxBIOS. 5) Get the MTD utilities from http://www.linux-mtd.infradead.org/ and build the 'erase' utility. 6) Set up the 'flash_on' program in your path. 7) Put a Disk On Chip into the flash socket. 8) Burn the chip. 9) Reset the machine -- did it work? --- Step 1) Get Linux installed on your LinuxBIOS machine. Tested on RedHat 7.2 Note: Do not format disk partitions as ext3! It's not supported by the LinuxBIOS kernel patch for 2. 4.7. Stick with ext2 -- it makes things much easier. Step 2) Grab the LinuxBIOS source. cd to the directory you want the source tree to be. Note: This HOWTO uses /usr/src as the base directory. After running the following commands from this directory, you should have a directory (/usr/src/freebios) with all the source code. export CVS_RSH=ssh (or in tcsh setenv CVS_RSH ssh) cvs -d:pserver:anonymous@cvs.freebios.sourceforge.net:/cvsroot/freebios login (at the password prompt, just hit <return>) cvs -z3 -d:pserver:anonymous@cvs.freebios.sourceforge.net:/cvsroot/freebios co freebios Step 3) Surf to www.kernel.org and get linux-2.4.7.tar.gz from the kernel archives. Once you have pulled this file down and untar'ed it, apply the proper patch from the freebios/src/kernel_patches directory. (tar xzvf linux-2.4.7.tar.gz; mv linux linux_2.4.7; cd /usr/src/linux_2.4.7) The patch is: linux-2.4.7-sis.patch Your patch command will look like this: patch -p1 < /usr/src/freebios/src/kernel_patches/linux-2.4.7-sis.patch Now cp /usr/src/freebios/src/kernel_patches/config-2.4.7-sis to .config make oldconfig make dep make vmlinux make modules make modules_install make bzdisk (You should test boot this floppy disk just to be safe) You now have a kernel for LinuxBIOS. Now, try booting the floppy to ensure that the LinuxBIOS kernel works. On our machine, we received a few errors but the machine did boot completely. We were without networking, so you certainly want to keep your original kernel if you need to boot back to pull files of the Internet. If you want, you can also install this kernel on the LinuxBIOS machine, and install the modules as well, since you will need the Disk On Chip modules to burn the Disk On Chip part. In our experience, we found it's easiest to work within your stock kernel and only boot the LinuxBIOS kernel off the floppy when you're ready to burn the DOC. Step 4) You now need to figure out where you want to put your build images. We used /usr/src/build a directory we created. DO NOT PUT THESE IN THE LinuxBIOS SOURCE TREE. You want to put them OUTSIDE THE TREE, so you can always cvs update and not lose any of your build directory. LinuxBIOS does all the builds in a single directory, much as BSD does. To build LinuxBIOS requires a Makefile, a crt0.S file, and a ld script file. These are generated by a config tool located in freebios/utils/config. The config tool is a Python program originally written by Dean Risinger of the ACL. To build the initial Makefile, assembly stub, and ld script, you need to build a config file, run the config tool, cd to the build directory, and type 'make'. That said, first create your config file using the text editor of your choice. This file can be located anywhere... we used /usr/src/sis.config. Here is the config file for the k7SEM: # This will dump all the files in /usr/src/build target /usr/src/build # Elitegroup K7sem mainboard elitegroup/k7sem # Request this level of debugging output option DEFAULT_CONSOLE_LOGLEVEL=8 # At a maximum only compile in this level of debugging option MAXIMUM_CONSOLE_LOGLEVEL=8 #option DEBUG # Enable Serial Console for debugging # It will come up at 115200,8n1 option SERIAL_CONSOLE=1 option SERIAL_POST=1 # Use the internal VGA frame buffer device option HAVE_FRAMEBUFFER=1 #floppy is nice option MUST_ENABLE_FLOPPY=1 # We're using disk on chip. Tell it where to find the docipl code option USE_DOC_MIL=1 docipl northsouthbridge/sis/730/ipl.S # Path to your kernel (vmlinux) # NOTE; you need a path to your kernel here. linux /usr/src/linux_2.4.7/ # Kernel command line parameters commandline root=/dev/hda3 single console=ttyS0,115200 console=tty0 video=sisfb:1024x768-8@60 The target command names the build directory. The mainboard command names the mainboard. We have set options for a serial console which will get you LinuxBIOS debug output via the serial port. You have to tell it where to find the vmlinux you build (the 'linux' command); and finally you need a commandline for now. To run the config tool, you need two arguments: the first is the name of a config file, and the second is the (absolute) pathname of the freebios source tree. The config tool is NLBConfig.py. Make sure you use that and not LBConfig.py, the older version. Now, just run the configuration tool to generate the Makefile. python /usr/src/freebios/util/config/NLBConfig.py sis.config /usr/src/freebios Assuming no errors, cd into /usr/src/build and type make. If you receive an error message then verify your configuration file is correct and/or consult the LinuxBios website. After running make, we now have three files to be loaded into the Disk On Chip. The first is called docipl. It is 512 bytes. The second is called LinuxBIOS.strip, and is the binary image of the LinuxBIOS that gets loaded into Doc. The third file is your kernel, and is stripped and compressed, linux.bin.gz -rw------- 1 rminnich CIC-ACL 512 Dec 20 08:41 docipl -rwx------ 1 rminnich CIC-ACL 33494 Dec 20 08:41 LinuxBIOS.strip* -rwx------ 1 rminnich CIC-ACL 756069 Dec 20 08:41 linux.bin.gz* Ensure that all of the above files exist. Very important: mv linux.bin.gz vmlinux.bin.gz This is your compressed kernel image. You're now ready to burn the Disk On Chip, but first .... Step 5) Get the MTD utilities from http://www.linux-mtd.infradead.org/ cd /usr/src (this is going to create another sub-directory) cvs -d :pserver:anoncvs@cvs.infradead.org:/home/cvs login (password: anoncvs) cvs -d :pserver:anoncvs@cvs.infradead.org:/home/cvs co mtd cd /mtd/util/ sh -x MAKEDEV make This creates the 'erase' utility. Install the erase utility where it is in your path. One such method is to use vi and edit the .bashrc PATH=$PATH:/usr/src/mtd/util; export PATH . .bashrc (run in the same directory as the .bashrc file is located) Step 6) Set up flash_on utility. cd /usr/src/freebios/util/sis/ flash_on.c is found in freebios/util/sis/flash_on.c Make the utility, and put it in your path. Path in the .bashrc file should look like this now: PATH=$PATH:/usr/src/mtd/util:/usr/src/freebios/util/sis; export PATH Make sure to re-read the path by running the file again: . .bashrc echo $PATH to ensure both directories are included. Step 7) NOTE: BE ADVISED THAT THIS STEP CAN HURT OR KILL YOU! YOU ARE WORKING WITH A POWERED-ON COMPUTER AT THIS POINT. THE COMPUTER NEEDS TO BE OPENED UP, AND YOU NEED TO REMOVE A CHIP WHILE THE COMPUTER IS ON. IF YOU HAVE NOT DONE THIS TYPE OF WORK, DO NOT DO IT! WE TAKE NO RESPONSIBILITY FOR ANYTHING THAT HAPPENS AT THIS STEP. BEFORE DOING THIS STEP WITH POWER ON, YOU SHOULD TRY IT WITH POWER OFF. Reboot the machine and boot off the floppy. You need to be running the LinuxBIOS kernel with all the loaded DOC modules to successfully burn the chip. Open the machine (LEAVE THE POWER ON), yank the flash, and plug in the DoC. We recommend you practice this first with the power off. Make sure that whatever you do, you are not shorting things out. Avoid using a metal tool! NOTE: YOU CAN HURT YOURSELF AT THIS STEP. We can't take any responsibility for what happens to you here. If you haven't done this, or are not trained, or have a history of getting hurt by hardware, DON'T DO IT. Step 8) cd to /usr/src/build (imperative -- won't burn correctly unless you run the script while inside this directory) Run /usr/src/freebios/util/mtd/burn_mtd Step 9) POWER OFF THE MACHINE. DoC requires this. Turn it back on. LinuxBIOS should come up in a few seconds. DEBUGGING ___________ If you can, hook up a serial line to your LinuxBIOS machine, settings 115200,8n1 and see what messages come out. If you can capture them, send them to linuxbios(a)lanl.gov with a description of your problem.

3 5

K7SEM Serial Boot Log....What next...
by Alex Scarbro 24 Jun '03

24 Jun '03

4 9

mtd drivers and diskonchip millenium
by roger 24 Jun '03

24 Jun '03

hey all. just dropping a note here that I'm having a problem getting the doc2001 module(s) to recognize a diskonchip millenium being placed in the old motherboard bios chip socket. seems I have to induce a kernel oops to get the diskonchip recognized. i've already emailed the problem to the mtd mailling lists and david mentioned something about using a memory map module prior to loading. so my installation of linuxbios has been stalled. basically, on reboot, the both boxes act similar to as if there is no bios chip installed. also have the docipl + 440bx support issue. As a work around tho, I plan on buying spare bios chips. However, mtd is still buggy. So far, openbios/devbios is the only thing that will actively let me read/write to the device. (Tyan Tiger 1832DL 440BX with a second 440BX board laying around. Both with the same problem. So much for spending the extra buck on intel boards to ensure compatability eh?) -- Roger http://www.eskimo.com/~roger/index.html

2 2

the freeze
by ron minnich 24 Jun '03

24 Jun '03

OK, I just committed the earlymtrr patch for faster boots. I think at this point we stop taking patches to the core stuff, with one remaining issue: we need the ecc patch so K7s won't blow up. So, once that's in, I think we should try to declare 1.0.1 closed. People who own various mainboards, please test with the latest cvs, save for those of you with K7 boards. ron

2 5

I just updated the web page at www.linuxbios.org
by ron minnich 24 Jun '03

24 Jun '03

look at any STATUS you might own and see if it is right. Sorry for the delay. ron

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot