From phanig at gmail.com Tue Jan 1 05:36:38 2008 From: phanig at gmail.com (Phani Babu Giddi) Date: Mon, 31 Dec 2007 20:36:38 -0800 Subject: [LinuxBIOS] flashrom on the host or target ? Message-ID: Hello All, I am trying to understand how to access the flash chip on the mainboard for the very first time. Most of the documentation on Linux BIOS talks about using "flashrom" but I am confused, are we suppose to use this on the target ( mainboard) or host. If its host are is there a way one can access the flash disk from the host, I have looked into the Hardware Tools that have been suggested for Linux BIOS but I could not find anything related to this. If flashrom utility is supposed to be used on the target, then how is that possible because there is no image on the flash device. BIOS Saviour and other tools come into picuture if there is some thing already on the flash chip. So am I suppose to select the payload as etherboot and then try flashing the device for the first time. Or else I am suppose to use an external programmer for this. If we succeed in getting the BIOS with the payload into the flash device what about the root file system and partitions and any other info. The question might sound elementary to most of you but I would appreciate your help. To summarize the question is about getting bare bones board up and running for the very first time. Regards, Phani -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey.osgood at gmail.com Tue Jan 1 08:07:15 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Tue, 01 Jan 2008 02:07:15 -0500 Subject: [LinuxBIOS] flashrom on the host or target ? In-Reply-To: References: Message-ID: <4779E6A3.7000503@gmail.com> Phani Babu Giddi wrote: > Hello All, > > I am trying to understand how to access the flash chip on > the mainboard for the very first time. Most of the documentation on > Linux BIOS talks about using "flashrom" but I am confused, are we > suppose to use this on the target ( mainboard) or host. If its host > are is there a way one can access the flash disk from the host, I have > looked into the Hardware Tools that have been suggested for Linux BIOS > but I could not find anything related to this. If flashrom utility is > supposed to be used on the target, then how is that possible because > there is no image on the flash device. > > BIOS Saviour and other tools come into picuture if there is some thing > already on the flash chip. > > So am I suppose to select the payload as etherboot and then try > flashing the device for the first time. Or else I am suppose to use an > external programmer for this. > > If we succeed in getting the BIOS with the payload into the flash > device what about the root file system and partitions and any other > info. The question might sound elementary to most of you but I would > appreciate your help. > > To summarize the question is about getting bare bones board up and > running for the very first time. > > Regards, > Phani It doesn't matter. As long as you have the chip that you intend to flash in the system you run flashrom on, and use compatible hardware (both with the chip and flashrom), then you can flash literally any image onto any flash chip. It doesn't matter if the system you use to flash has completely different hardware then the image's intended target. -Corey PS Happy new year, everyone! From phanig at gmail.com Tue Jan 1 17:32:41 2008 From: phanig at gmail.com (Phani Babu Giddi) Date: Tue, 1 Jan 2008 08:32:41 -0800 Subject: [LinuxBIOS] Fwd: flashrom on the host or target ? In-Reply-To: References: <4779E6A3.7000503@gmail.com> Message-ID: ---------- Forwarded message ---------- From: Phani Babu Giddi Date: Jan 1, 2008 8:29 AM Subject: Re: [LinuxBIOS] flashrom on the host or target ? To: Corey Osgood Hi Corey, Thanks for your reply but I am not clear. Let me list the steps, may be that will explain the problem I see. 1. I have a host target environment 2. I build Linux Kernel image with initrd on the host 3. I also build the root file system on the host 4. Now I build Linux BIOS and specify the Linux Kernel as payload. 5. So at this point I have the .bin/.rom for Linux BIOS and an image file for the root file system. 6. So my question was how do I get this on the flash device. Do I have to use an external programmer for this ? Because there is nothing on the target for me to run flashrom. Regards, Phani On Dec 31, 2007 11:07 PM, Corey Osgood wrote: > Phani Babu Giddi wrote: > > Hello All, > > > > I am trying to understand how to access the flash chip on > > the mainboard for the very first time. Most of the documentation on > > Linux BIOS talks about using "flashrom" but I am confused, are we > > suppose to use this on the target ( mainboard) or host. If its host > > are is there a way one can access the flash disk from the host, I have > > looked into the Hardware Tools that have been suggested for Linux BIOS > > but I could not find anything related to this. If flashrom utility is > > supposed to be used on the target, then how is that possible because > > there is no image on the flash device. > > > > BIOS Saviour and other tools come into picuture if there is some thing > > already on the flash chip. > > > > So am I suppose to select the payload as etherboot and then try > > flashing the device for the first time. Or else I am suppose to use an > > external programmer for this. > > > > If we succeed in getting the BIOS with the payload into the flash > > device what about the root file system and partitions and any other > > info. The question might sound elementary to most of you but I would > > appreciate your help. > > > > To summarize the question is about getting bare bones board up and > > running for the very first time. > > > > Regards, > > Phani > > It doesn't matter. As long as you have the chip that you intend to flash > in the system you run flashrom on, and use compatible hardware (both > with the chip and flashrom), then you can flash literally any image onto > any flash chip. It doesn't matter if the system you use to flash has > completely different hardware then the image's intended target. > > -Corey > > PS Happy new year, everyone! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey.osgood at gmail.com Tue Jan 1 18:32:44 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Tue, 01 Jan 2008 12:32:44 -0500 Subject: [LinuxBIOS] flashrom on the host or target ? In-Reply-To: References: <4779E6A3.7000503@gmail.com> Message-ID: <477A793C.9090201@gmail.com> Phani Babu Giddi wrote: > Hi Corey, > > Thanks for your reply but I am not clear. Let me list the steps, may > be that will explain the problem I see. > > 1. I have a host target environment > 2. I build Linux Kernel image with initrd on the host > 3. I also build the root file system on the host > 4. Now I build Linux BIOS and specify the Linux Kernel as payload. > 5. So at this point I have the .bin/.rom for Linux BIOS and an image > file for the root file system. > 6. So my question was how do I get this on the flash device. Do I have > to use an external programmer for this ? Because there is nothing on > the target for me to run flashrom. Yep, you can use an external programmer, or you can use some other board that's compatible with flashrom and your flash chip, by hot swapping the flash chips. -Corey From phanig at gmail.com Tue Jan 1 21:24:03 2008 From: phanig at gmail.com (Phani Babu Giddi) Date: Tue, 1 Jan 2008 12:24:03 -0800 Subject: [LinuxBIOS] flashrom on the host or target ? In-Reply-To: <477A793C.9090201@gmail.com> References: <4779E6A3.7000503@gmail.com> <477A793C.9090201@gmail.com> Message-ID: Hi Corey, Is there a way by which I can use the external programmer to flash the complete chip at once. I mean There is the Linux BIOS image which includes the kernel and then there is the root file system and a fall back image. So that I can have a single file which I can generate and distribute. Have this been done before ? Regards, Phani On Jan 1, 2008 9:32 AM, Corey Osgood wrote: > Phani Babu Giddi wrote: > > Hi Corey, > > > > Thanks for your reply but I am not clear. Let me list the steps, may > > be that will explain the problem I see. > > > > 1. I have a host target environment > > 2. I build Linux Kernel image with initrd on the host > > 3. I also build the root file system on the host > > 4. Now I build Linux BIOS and specify the Linux Kernel as payload. > > 5. So at this point I have the .bin/.rom for Linux BIOS and an image > > file for the root file system. > > 6. So my question was how do I get this on the flash device. Do I have > > to use an external programmer for this ? Because there is nothing on > > the target for me to run flashrom. > > Yep, you can use an external programmer, or you can use some other board > that's compatible with flashrom and your flash chip, by hot swapping the > flash chips. > > -Corey > -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey.osgood at gmail.com Wed Jan 2 04:48:00 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Tue, 01 Jan 2008 22:48:00 -0500 Subject: [LinuxBIOS] flashrom on the host or target ? In-Reply-To: References: <4779E6A3.7000503@gmail.com> <477A793C.9090201@gmail.com> Message-ID: <477B0970.9040507@gmail.com> Phani Babu Giddi wrote: > Hi Corey, > > Is there a way by which I can use the external programmer to flash the > complete chip at once. I mean There is the Linux BIOS image which > includes the kernel and then there is the root file system and a fall > back image. So that I can have a single file which I can generate and > distribute. > > Have this been done before ? Yes, you can use an external programmer. Just use the software that's included with the programmer. I have a Willem programmer, highly recommend avoiding it, it's junk for any sort of real work, although it does work in a pinch. I've heard others speak highly of the Galep 5, but I don't have one. -Corey From aaron.lwe at gmail.com Wed Jan 2 08:47:32 2008 From: aaron.lwe at gmail.com (aaron lwe) Date: Wed, 2 Jan 2008 15:47:32 +0800 Subject: [LinuxBIOS] problem about dram init In-Reply-To: <476B51E4.8060207@gmail.com> References: <476B51E4.8060207@gmail.com> Message-ID: On Dec 21, 2007 1:40 PM, Corey Osgood wrote: > > And now you're where I am. For some reason there's a reserved memory > range _somewhere_ at the tolm, of some unknown size. I've found that > reserving an extra 1MB doesn't work, but 32MB does. I've found nothing > in the documentation I have to explain this. BTW, have you had to make > any code changes other than the MA Map, and board-specific fixes? I'm > wondering how generic that code really is. > > -Corey > Corey, I think I've found the cause of this problem, it's agp aperture memory that caused this memory unusable. When I set agp aperture memory size to 128MB, I found I could only use the tolm - 128 * 1024 memory, and you set agp aperture memory size to 32MB, so reserving 32MB worked for you. The smallest size I can set for agp apertur memory size is 4MB and after setting that, memtest now reports 508MB(512MB - 4MB) is working fine ;-) Only I don't know why agp aperture memory would interfere with physical memory. From corey.osgood at gmail.com Wed Jan 2 09:16:46 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Wed, 02 Jan 2008 03:16:46 -0500 Subject: [LinuxBIOS] problem about dram init In-Reply-To: References: <476B51E4.8060207@gmail.com> Message-ID: <477B486E.1070601@gmail.com> aaron lwe wrote: > On Dec 21, 2007 1:40 PM, Corey Osgood wrote: > >> And now you're where I am. For some reason there's a reserved memory >> range _somewhere_ at the tolm, of some unknown size. I've found that >> reserving an extra 1MB doesn't work, but 32MB does. I've found nothing >> in the documentation I have to explain this. BTW, have you had to make >> any code changes other than the MA Map, and board-specific fixes? I'm >> wondering how generic that code really is. >> >> -Corey >> >> > > Corey, I think I've found the cause of this problem, it's agp aperture memory > that caused this memory unusable. When I set agp aperture memory > size to 128MB, I found I could only use the tolm - 128 * 1024 memory, > and you set agp aperture memory size to 32MB, so reserving 32MB > worked for you. The smallest size I can set for agp apertur memory size > is 4MB and after setting that, memtest now reports 508MB(512MB - 4MB) > is working fine ;-) > Only I don't know why agp aperture memory would interfere with physical memory. Are you configuring the system for AGP 2.0 or 3.0, ie are you configuring dev 0.0 or 1.0? The way I had it set up, I thought, was 32MB for video, 32MB for agp, and the rest for the system, using AGP 3.0. I could very well have messed something up somewhere, though. -Corey From aaron.lwe at gmail.com Wed Jan 2 09:44:59 2008 From: aaron.lwe at gmail.com (aaron lwe) Date: Wed, 2 Jan 2008 16:44:59 +0800 Subject: [LinuxBIOS] problem about dram init In-Reply-To: <477B486E.1070601@gmail.com> References: <476B51E4.8060207@gmail.com> <477B486E.1070601@gmail.com> Message-ID: > Are you configuring the system for AGP 2.0 or 3.0, ie are you > configuring dev 0.0 or 1.0? The way I had it set up, I thought, was 32MB > for video, 32MB for agp, and the rest for the system, using AGP 3.0. I > could very well have messed something up somewhere, though. > > -Corey > I'm configuring the system for AGP 3.0. AFAIK, frame buffer uses physical memory but agp aperture memory do not use physical memory. We could set agp aperture memory size to be 128MB even we only have 64MB physical memory. and I've disabled the integrated graphics card, reserving no memory for it. From libv at skynet.be Wed Jan 2 10:16:38 2008 From: libv at skynet.be (Luc Verhaegen) Date: Wed, 2 Jan 2008 10:16:38 +0100 Subject: [LinuxBIOS] [Patch] Fix CONFIG_CONSOLE_VGA handling in default pci_dev_init. Message-ID: <20080102091638.GA11860@skynet.be> The CONFIG_CONSOLE_VGA and CONFIG_PCI_ROM_RUN logic in src/devices/pci_device.c:pci_dev_init is messed up. First of all, pci_dev_init should only do anything when the pci rom should be run. Secondly, vga_inited should only be set when the rom has been run, and never otherwise as this should be done by the relevant init function of possible (future) VGA setup drivers. Signed-off-by: Luc Verhaegen -------------- next part -------------- Index: src/devices/pci_device.c =================================================================== --- src/devices/pci_device.c (revision 3031) +++ src/devices/pci_device.c (working copy) @@ -643,23 +643,13 @@ ((device & 0xffff) << 16) | (vendor & 0xffff)); } +/** default handler: only runs the relevant pci bios. */ void pci_dev_init(struct device *dev) { -#if CONFIG_CONSOLE_VGA == 1 - extern int vga_inited; -#endif -#if CONFIG_PCI_ROM_RUN == 1 || CONFIG_CONSOLE_VGA == 1 + +#if CONFIG_PCI_ROM_RUN == 1 struct rom_header *rom, *ram; -#if CONFIG_PCI_ROM_RUN != 1 - /* We want to execute VGA option ROMs when CONFIG_CONSOLE_VGA - * is set but CONFIG_PCI_ROM_RUN is not. In this case we skip - * all other option ROM types. - */ - if (dev->class!=PCI_CLASS_DISPLAY_VGA) - return; -#endif - rom = pci_rom_probe(dev); if (rom == NULL) return; @@ -671,14 +661,14 @@ run_bios(dev, ram); #if CONFIG_CONSOLE_VGA == 1 - /* vga_inited is a trigger of the VGA console code. - * - * Only set it if we enabled VGA console, and if we - * just initialized a VGA card. - */ - vga_inited|=dev->class==PCI_CLASS_DISPLAY_VGA; -#endif -#endif + /* vga_inited is a trigger of the VGA console code. */ + if (dev->class == PCI_CLASS_DISPLAY_VGA) { + extern int vga_inited; + vga_inited = TRUE; + } +#endif /* CONFIG_CONSOLE_VGA */ + +#endif /* CONFIG_PCI_ROM_RUN */ } /** Default device operation for PCI devices */ From duarte at vonbraunlabs.com.br Wed Jan 2 12:32:50 2008 From: duarte at vonbraunlabs.com.br (Omar Esteves Duarte Filho) Date: Wed, 2 Jan 2008 09:32:50 -0200 Subject: [LinuxBIOS] RES: RES: VGA Support on AMD DB800 In-Reply-To: <20071228210310.GB6768@cosmic.amd.com> Message-ID: Thank you for the support and sorry for the inconvenience, Jordan. You are right: this is off-topic. Video is working now and if someone is interested in the solution, please read below. After some investigation here, i've finally got VGA output (both text console and X)! In the end, it seems that there is some problem with the lxfb driver. I was trying to set up the VGA with the video boot parameter in the kernel command line ("lxfb.mode_option=..."). But, it did not work. However, the video output works if "fbset 640x480-60", for instance, was previously typed. The fbset tool initializes the VGA with different timing parameters. Below is the VGA timing parameters right after the boot process is complete and there's still no VGA output: root at ubuntu-LX800:~# fbset -i mode "640x480-60" # D: 25.175 MHz, H: 31.469 kHz, V: 59.940 Hz geometry 640 480 640 480 16 timings 39682 48 8 25 2 88 2 rgba 5/11,6/5,5/0,0/0 endmode Then, fbset is used to adjust the video mode: root at ubuntu-LX800:~# fbset 640x480-60 root at ubuntu-LX800:~# After that, VGA output works and timing parameters are checked again: root at ubuntu-LX800:~# fbset -i mode "640x480-60" # D: 25.175 MHz, H: 31.469 kHz, V: 59.940 Hz geometry 640 480 640 480 16 timings 39722 48 16 33 10 96 2 rgba 5/11,6/5,5/0,0/0 endmode So, I changed the drivers\video\geode\lxfb_core.c file to match the 'working' timing parameters: const struct fb_videomode geode_modedb[] __initdata = { /* 640x480-60 */ { NULL, 60, 640, 480, 39722, 48, 16, 33, 10, 96, 2, 0, FB_VMODE_NONINTERLACED, 0 }, Now that video is working, the only issue is the long delay (~90s) between turning on the platform and getting some video output, which is the time needed for the kernel to be executed and to load the lxfb driver. I'll try to speed this up a little bit. Regards, Omar Esteves Duarte Filho Embedded Software Engineer Wernher von Braun Center for Advanced Research Av. Alice de Castro P. N. Mattosinho, 301 13098-381 Alphaville Campinas, SP - Brasil Phone No. +55 19 3262 2207 http://www.vonbraunlabs.com.br -----Mensagem original----- De: Jordan Crouse [mailto:jordan.crouse at amd.com] Enviada em: sexta-feira, 28 de dezembro de 2007 19:03 Para: Omar Esteves Duarte Filho Cc: linuxbios at linuxbios.org Assunto: Re: RES: VGA Support on AMD DB800 On 26/12/07 10:50 -0200, Omar Esteves Duarte Filho wrote: > Jordan, > > Thank you again! > > I removed splash and quiet form the menu.lst and added "console=tty0 > console=ttyS0,115200", as you can see below: > > title Ubuntu 7.10, kernel 2.6.23.9-geodelx-fb > root (hd0,0) > kernel /boot/vmlinuz-2.6.23.9-geodelx-fb > root=UUID=a4e4ac87-c677-45e1-a > a21-1e4654feac95 ro vga=771 console=tty0 console=ttyS0,115200 > initrd /boot/initrd.img-2.6.23.9-geodelx-fb > > I got some success here: startx works, but there's still no vga > console before X starts. I think there is some problem with the lxfb > driver because, if i switch the line " Device "AMD" " by "Device > "Generic Video Card"" in the xorg.conf file, I get no result. lxfb and > fbcon are built into the kernel. This is starting to get off topic for the linuxbios list, but I'll answer it here since others might have the same problem. X and the kernel have nothing to do with one-another - they are completely seperate entities. If you do not see the text console (and the penguin) once the kernel has started, then something has gone wrong. Please send the dmesg output from your kernel, and your kernel config. Jordan From myles at pel.cs.byu.edu Wed Jan 2 17:37:50 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Wed, 2 Jan 2008 09:37:50 -0700 Subject: [LinuxBIOS] flashrom on the host or target ? In-Reply-To: References: <4779E6A3.7000503@gmail.com> <477A793C.9090201@gmail.com> Message-ID: <2831fecf0801020837h615f6417p515c509624e76c85@mail.gmail.com> On Jan 1, 2008 1:24 PM, Phani Babu Giddi wrote: > Hi Corey, > > Is there a way by which I can use the external programmer to flash the > complete chip at once. I mean There is the Linux BIOS image which includes > the kernel and then there is the root file system and a fall back image. So > that I can have a single file which I can generate and distribute. > > Have this been done before ? It sounds like your problem is not how to flash the BIOS, but how to generate a single image including LinuxBIOS, the filesystem, and the kernel. If this is your question, then you should look at a LAB (Linux As Bootloader) implementation. It puts everything in a single ROM image. The easiest way to do this is to get buildrom and follow one of the configurations for LAB. You need to have at least a 1MB chip to fit LinuxBIOS and a kernel. With a 2MB chip you wouldn't have to strip it down so much. Good luck, Myles > Regards, > Phani > > > > On Jan 1, 2008 9:32 AM, Corey Osgood wrote: > > > > > Phani Babu Giddi wrote: > > > Hi Corey, > > > > > > Thanks for your reply but I am not clear. Let me list the steps, may > > > be that will explain the problem I see. > > > > > > 1. I have a host target environment > > > 2. I build Linux Kernel image with initrd on the host > > > 3. I also build the root file system on the host > > > 4. Now I build Linux BIOS and specify the Linux Kernel as payload. > > > 5. So at this point I have the .bin/.rom for Linux BIOS and an image > > > file for the root file system. > > > 6. So my question was how do I get this on the flash device. Do I have > > > to use an external programmer for this ? Because there is nothing on > > > the target for me to run flashrom. > > > > Yep, you can use an external programmer, or you can use some other board > > that's compatible with flashrom and your flash chip, by hot swapping the > > flash chips. > > > > -Corey > > > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > From jordan.crouse at amd.com Wed Jan 2 18:52:14 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 2 Jan 2008 10:52:14 -0700 Subject: [LinuxBIOS] RES: RES: VGA Support on AMD DB800 In-Reply-To: <20080102113335.C9619D20082@mail82-dub.bigfish.com> References: <20071228210310.GB6768@cosmic.amd.com> <20080102113335.C9619D20082@mail82-dub.bigfish.com> Message-ID: <20080102175214.GA11840@cosmic.amd.com> On 02/01/08 09:32 -0200, Omar Esteves Duarte Filho wrote: > Thank you for the support and sorry for the inconvenience, Jordan. You are > right: this is off-topic. First - please - stop using the term 'VGA'. VGA is a very specific standard for video display (http://en.wikipedia.org/wiki/VGA). There is no VGA here. By using the term, you muddle the discussion. > After some investigation here, i've finally got VGA output (both text > console and X)! In the end, it seems that there is some problem with the > lxfb driver. I was trying to set up the VGA with the video boot parameter in > the kernel command line ("lxfb.mode_option=..."). But, it did not work. > However, the video output works if "fbset 640x480-60", for instance, was > previously typed. The fbset tool initializes the VGA with different timing > parameters. Below is the VGA timing parameters right after the boot process > is complete and there's still no VGA output: mode_option is only valid when you load the driver as a module. When running with the driver built in, then you specify the mode on the command line, as detailed in Documentation/fb/modedb.txt. The correct way to specify the mode on the command line is as follows: video=lxfb:--@ I also noted that you were specifying vga= on your command line - if the vesa framebuffer is also installed in your kernel (as it would be with a normal Ubuntu kernel), then that will cause the VESA framebuffer to be loaded first (which would of course, fail). The lxfb would be loaded as well, but registered as the second framebuffer (if you have your kernel output from dmesg, you should be able to see this happen). The fbset you did below would kick the second driver and have it take over the console from the failed primary driver. > root at ubuntu-LX800:~# fbset -i > > mode "640x480-60" > # D: 25.175 MHz, H: 31.469 kHz, V: 59.940 Hz > geometry 640 480 640 480 16 > timings 39682 48 8 25 2 88 2 > rgba 5/11,6/5,5/0,0/0 > endmode This is the mode specified in lxfb_core.c - this is the correct timings for the Geode for the VESA mode 640x480 at 60. > Then, fbset is used to adjust the video mode: > > root at ubuntu-LX800:~# fbset 640x480-60 > root at ubuntu-LX800:~# > > > After that, VGA output works and timing parameters are checked again: > > root at ubuntu-LX800:~# fbset -i > > mode "640x480-60" > # D: 25.175 MHz, H: 31.469 kHz, V: 59.940 Hz > geometry 640 480 640 480 16 > timings 39722 48 16 33 10 96 2 > rgba 5/11,6/5,5/0,0/0 > endmode This is the mode that is listed in the file /etc/fb.modes - which is a set of generic timings provided by Ubuntu. Both timings are actually correct - if you were to run fbset and set the previous timings, they would work. What you are seeing is a side effect of a poorly configured kernel. Jordan From duarte at vonbraunlabs.com.br Wed Jan 2 20:36:08 2008 From: duarte at vonbraunlabs.com.br (Omar Esteves Duarte Filho) Date: Wed, 2 Jan 2008 17:36:08 -0200 Subject: [LinuxBIOS] RES: RES: RES: VGA Support on AMD DB800 In-Reply-To: <20080102175214.GA11840@cosmic.amd.com> Message-ID: > > First - please - stop using the term 'VGA'. VGA is a very > specific standard for video display > (http://en.wikipedia.org/wiki/VGA). There is no VGA here. > By using the term, you muddle the discussion. Ok. > > mode_option is only valid when you load the driver as a > module. When running with the driver built in, then you > specify the mode on the command line, > as detailed in Documentation/fb/modedb.txt. The correct way > to specify the > mode on the command line is as follows: > > video=lxfb:--@ Yes, my fault! Actually, I did use the correct way of specifying the mode on the command line. However, when composing the email, i wrongly wrote the 'mode_option'. lxfb driver is compiled into the kernel and the current command line is: kernel /boot/vmlinuz-2.6.23.9-geodelx-fb root=UUID=a4e4ac87-c677-45e1-aa21-1e4654feac95 ro console=tty0 console=ttyS0,115200 video=lxfb:640x480 at 60 > > I also noted that you were specifying vga= on your > command line - if the vesa framebuffer is also installed in > your kernel (as it would be with a normal Ubuntu kernel), > then that will cause the VESA framebuffer to be loaded first > (which would of course, fail). The lxfb would be loaded as > well, but registered as the second framebuffer (if you have > your kernel output from dmesg, you should be able to see this happen). > > The fbset you did below would kick the second driver and have > it take over the console from the failed primary driver. VESA VGA Support is -not- enabled. So, lxfb is registered as the first framebuffer (/dev/fb0): root at ubuntu-LX800:~# cat /proc/fb 0 Geode LX > > This is the mode that is listed in the file /etc/fb.modes - > which is a set of generic timings provided by Ubuntu. Both > timings are actually correct - if you were to run fbset and > set the previous timings, they would work. What you are > seeing is a side effect of a poorly configured kernel. > > Jordan > I tried to check both timings sets using "fbset --timings" command. The only set that works is: root at ubuntu-LX800:~# fbset -i mode "640x480-60" # D: 25.175 MHz, H: 31.469 kHz, V: 59.940 Hz geometry 640 480 640 480 16 timings 39722 48 16 33 10 96 2 rgba 5/11,6/5,5/0,0/0 Endmode The other set (the "original" one") provides VSYNC=63Hz, instead of 60Hz: root at ubuntu-LX800:~# fbset -i mode "640x480-63" # D: 25.200 MHz, H: 32.143 kHz, V: 63.150 Hz geometry 640 480 640 480 16 timings 39682 48 8 25 2 88 2 rgba 5/11,6/5,5/0,0/0 Endmode Omar. From duwe at lst.de Wed Jan 2 20:37:43 2008 From: duwe at lst.de (Torsten Duwe) Date: Wed, 2 Jan 2008 20:37:43 +0100 Subject: [LinuxBIOS] [Patch] Fix CONFIG_CONSOLE_VGA handling in default pci_dev_init. In-Reply-To: <20080102091638.GA11860@skynet.be> References: <20080102091638.GA11860@skynet.be> Message-ID: <200801022037.44116.duwe@lst.de> Hi Luc, welcome to the List! On Wednesday 02 January 2008, Luc Verhaegen wrote: > The CONFIG_CONSOLE_VGA and CONFIG_PCI_ROM_RUN logic in > src/devices/pci_device.c:pci_dev_init is messed up. Well, it's not as clear as it could be, but I see no flaw so far. Keep in mind the logic: CONFIG_PCI_ROM_RUN means run all PCI ROMs. CONFIG_CONSOLE_VGA means console might be on VGA, run "the" VGA ROM _regardless_ of the setting of CONFIG_PCI_ROM_RUN. > First of all, pci_dev_init should only do anything when the pci rom > should be run. Yes? As far as I can see pci_rom_probe, pci_rom_load and run_bios are always run in sequence, unless there is an error. > Secondly, vga_inited should only be set when the rom has > been run, and never otherwise as this should be done by the relevant > init function of possible (future) VGA setup drivers. Besides the fact that in case of multiple VGAs it is not possible to specify which one is the console, vga_inited is only set iff "the" VGA's ROM has been run. Your patch admittedly improves readability, but breaks the logic above. Torsten From rminnich at gmail.com Wed Jan 2 22:26:10 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 2 Jan 2008 13:26:10 -0800 Subject: [LinuxBIOS] [Patch] Fix CONFIG_CONSOLE_VGA handling in default pci_dev_init. In-Reply-To: <20080102091638.GA11860@skynet.be> References: <20080102091638.GA11860@skynet.be> Message-ID: <13426df10801021326v64bee348ic601555df6b31337@mail.gmail.com> On Jan 2, 2008 1:16 AM, Luc Verhaegen wrote: > The CONFIG_CONSOLE_VGA and CONFIG_PCI_ROM_RUN logic in > src/devices/pci_device.c:pci_dev_init is messed up. It may be hard to read, but I am pretty sure it is doing the right thing. Can you provide an instance in which it does the wrong thing? Thanks ron From duwe at lst.de Thu Jan 3 00:04:21 2008 From: duwe at lst.de (Torsten Duwe) Date: Thu, 3 Jan 2008 00:04:21 +0100 Subject: [LinuxBIOS] [Patch] Fix CONFIG_CONSOLE_VGA handling in default pci_dev_init. In-Reply-To: <200801022037.44116.duwe@lst.de> References: <20080102091638.GA11860@skynet.be> <200801022037.44116.duwe@lst.de> Message-ID: <200801030004.21619.duwe@lst.de> On Wednesday 02 January 2008, I wrote: > Your patch admittedly improves readability, but breaks the logic above. I'd like to apply the beautifying part. What do you think? [ "trivial" by Russ' definition, BTW ;-] Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: ROM-run-readable Type: text/x-diff Size: 1139 bytes Desc: not available URL: From rminnich at gmail.com Thu Jan 3 00:46:15 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 2 Jan 2008 15:46:15 -0800 Subject: [LinuxBIOS] [Patch] Fix CONFIG_CONSOLE_VGA handling in default pci_dev_init. In-Reply-To: <200801030004.21619.duwe@lst.de> References: <20080102091638.GA11860@skynet.be> <200801022037.44116.duwe@lst.de> <200801030004.21619.duwe@lst.de> Message-ID: <13426df10801021546w10aa424aq5a8a2edab331a706@mail.gmail.com> you need a signed-off by ... Acked-by: Ronald G. Minnich beautifying is always a good idea. ron On Jan 2, 2008 3:04 PM, Torsten Duwe wrote: > On Wednesday 02 January 2008, I wrote: > > > Your patch admittedly improves readability, but breaks the logic above. > > I'd like to apply the beautifying part. What do you think? > [ "trivial" by Russ' definition, BTW ;-] > > Torsten > > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > From libv at skynet.be Thu Jan 3 02:02:59 2008 From: libv at skynet.be (Luc Verhaegen) Date: Thu, 3 Jan 2008 02:02:59 +0100 Subject: [LinuxBIOS] [Patch] Fix CONFIG_CONSOLE_VGA handling in default pci_dev_init. In-Reply-To: <13426df10801021546w10aa424aq5a8a2edab331a706@mail.gmail.com> References: <20080102091638.GA11860@skynet.be> <200801022037.44116.duwe@lst.de> <200801030004.21619.duwe@lst.de> <13426df10801021546w10aa424aq5a8a2edab331a706@mail.gmail.com> Message-ID: <20080103010259.GA14445@skynet.be> On Wed, Jan 02, 2008 at 03:46:15PM -0800, ron minnich wrote: > you need a signed-off by ... > > Acked-by: Ronald G. Minnich > > beautifying is always a good idea. > > ron How bloody insulting. Luc Verhaegen. From libv at skynet.be Thu Jan 3 02:03:03 2008 From: libv at skynet.be (Luc Verhaegen) Date: Thu, 3 Jan 2008 02:03:03 +0100 Subject: [LinuxBIOS] [Patch] Fix CONFIG_CONSOLE_VGA handling in default pci_dev_init. In-Reply-To: <13426df10801021326v64bee348ic601555df6b31337@mail.gmail.com> References: <20080102091638.GA11860@skynet.be> <13426df10801021326v64bee348ic601555df6b31337@mail.gmail.com> Message-ID: <20080103010303.GA14090@skynet.be> On Wed, Jan 02, 2008 at 01:26:10PM -0800, ron minnich wrote: > On Jan 2, 2008 1:16 AM, Luc Verhaegen wrote: > > The CONFIG_CONSOLE_VGA and CONFIG_PCI_ROM_RUN logic in > > src/devices/pci_device.c:pci_dev_init is messed up. > > It may be hard to read, but I am pretty sure it is doing the right > thing. Can you provide an instance in which it does the wrong thing? pci_dev_init is the default pci device initialisation routine. It is a dumb pci device initialisation routine, lacking all device specific knowledge. It can only try to achieve anything when there is a pci rom present which can do the initialisation for us. When we choose to not run pci roms, we do not initialise anything, and we certainly shouldn't go claiming we did either. When we choose to not run pci roms, why do we still run pci roms of devices if they just happen to be VGA devices? So why bother setting vga_inited outside of PCI_ROM_RUN? If you still do not believe logic, then please set CONFIG_CONSOLE_VGA without setting CONFIG_PCI_ROM_RUN and then build your rom. The build will fail due to missing symbols. This is how i came across this issue in the first place. What i am trying to do is implement native VGA bring-up for unichrome. I have had userspace code doing this on top of a clean linuxbios for more than 8 months. This is not just my X driver, i can also set up standard vga text mode, so it is not a pipe dream. In that light it is perfectly valid to claim CONFIG_CONSOLE_VGA without setting CONFIG_PCI_ROM_RUN, because: * i have no need for a vga rom, as i provide the necessary code for a full vga text mode bringup myself. * i have no need to run any other rom either. * i do want vga console logging. So when i initialise the unichrome, i set vga_inited myself, like any device driver should when it initialises a vga compatible device to a vga compatible state and expects the console code to make use of it as a vga compatible console. Since the lunacy that is the northbridge/via/vt8623/vgabios code never bothered to set up vga_inited, i am not breaking this either. Because how does one break what is already broken, and why should i bother fixing what isn't worth fixing? It will eventually be tossed anyway, as it will be done properly. Since I am trailblazing native vga bringup, it is perfectly understandable that some bumps are encountered along the way. What i do not understand is how something so perfectly logical is rejected without proper consideration, tossed aside as if it were a mindless cleanup. I do not do mindless cleanups. Feel free to read over my tiny and trivial patch again. Thank you for making my day, and a happy 2008 to you too. Luc Verhaegen. A now very agitated SUSE/Novell X Driver Developer. From rminnich at gmail.com Thu Jan 3 02:08:49 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 2 Jan 2008 17:08:49 -0800 Subject: [LinuxBIOS] [Patch] Fix CONFIG_CONSOLE_VGA handling in default pci_dev_init. In-Reply-To: <20080103010259.GA14445@skynet.be> References: <20080102091638.GA11860@skynet.be> <200801022037.44116.duwe@lst.de> <200801030004.21619.duwe@lst.de> <13426df10801021546w10aa424aq5a8a2edab331a706@mail.gmail.com> <20080103010259.GA14445@skynet.be> Message-ID: <13426df10801021708w1eaf01d8v57d8706a69b553bf@mail.gmail.com> On Jan 2, 2008 5:02 PM, Luc Verhaegen wrote: > On Wed, Jan 02, 2008 at 03:46:15PM -0800, ron minnich wrote: > > you need a signed-off by ... > > > > Acked-by: Ronald G. Minnich > > > > beautifying is always a good idea. > > > > ron > > How bloody insulting. Well, no insult was intended. ron From rminnich at gmail.com Thu Jan 3 02:31:27 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 2 Jan 2008 17:31:27 -0800 Subject: [LinuxBIOS] [Patch] Fix CONFIG_CONSOLE_VGA handling in default pci_dev_init. In-Reply-To: <20080103010303.GA14090@skynet.be> References: <20080102091638.GA11860@skynet.be> <13426df10801021326v64bee348ic601555df6b31337@mail.gmail.com> <20080103010303.GA14090@skynet.be> Message-ID: <13426df10801021731l31ebe422y2ef6567de06fd2be@mail.gmail.com> On Jan 2, 2008 5:03 PM, Luc Verhaegen wrote: > pci_dev_init is the default pci device initialisation routine. > > It is a dumb pci device initialisation routine, lacking all device > specific knowledge. > Right. By design. > It can only try to achieve anything when there is a pci rom present > which can do the initialisation for us. > > When we choose to not run pci roms, we do not initialise anything, and > we certainly shouldn't go claiming we did either. OK. Where precisely are we making that claim? What is the path by which we will claim to initialise something when we did not. Sorry, I am looking at the code and not seeing it. > > When we choose to not run pci roms, why do we still run pci roms of > devices if they just happen to be VGA devices? Because that was what the user community asked for. The VGA ROM stuff came first. Later, people wanted all option roms to be run. Then, it turned out there is a need for some platforms to run VGA option ROMS only. Finally, there can be a need for ALL option roms to be run but NO VGA consoles to be set up. The logic in this function is twisted because it grew by accretion. I make no claims that it is clean -- it is not. But I have not yet seen the case that it is wrong. > > So why bother setting vga_inited outside of PCI_ROM_RUN? Because, once you reach that line, you've run the vga bios. I don't understand the question. > > If you still do not believe logic, then please set CONFIG_CONSOLE_VGA > without setting CONFIG_PCI_ROM_RUN and then build your rom. The build > will fail due to missing symbols. That's a prolem. Which symbols? Which mainboards? This is an error but it has been a long enough time since I did this that I can easily believe it will happen. > What i am trying to do is implement native VGA bring-up for unichrome. I > have had userspace code doing this on top of a clean linuxbios for more > than 8 months. This is not just my X driver, i can also set up standard > vga text mode, so it is not a pipe dream. That's great to hear. Be aware that SiS also did native vga text mode in 2000, by Ollie Lo. So, we know that it is possible to have this work. We have done a fair amount of native and emulated VGA bringup over the years. > > In that light it is perfectly valid to claim CONFIG_CONSOLE_VGA > without setting CONFIG_PCI_ROM_RUN, because: > * i have no need for a vga rom, as i provide the necessary code for a > full vga text mode bringup myself. > * i have no need to run any other rom either. > * i do want vga console logging. > Ah. Now I see what you are trying to do. I misunderstood from your first message. No argument. We've been doing this for years. And if you can't do it, then something is broken for sure. So I'm happy to see it fixed. At the same time, let's suppose for the sake of argument that you set BOTH CONFIG_CONSOLE_VGA and CONFIG_PCI_ROM_RUN AND you have the native hardware bringup. How does that hurt your native device? There's no option rom for it --> it won't be run. I'd like to understand this. We have had cases where people had native bringup and installed a vga card, and both were needed. In that case we would want roms to run. > So when i initialise the unichrome, i set vga_inited myself, like any > device driver should when it initialises a vga compatible device to a > vga compatible state and expects the console code to make use of it as a > vga compatible console. OK. It's fine to set it there I suppose. > Since I am trailblazing native vga bringup, it is perfectly > understandable that some bumps are encountered along the way. What i do > not understand is how something so perfectly logical is rejected without > proper consideration, tossed aside as if it were a mindless cleanup. It was considered. I think there is a bigger picture than you might have realised. Torsten also pointed out a secondary issue. I read your patch. I am still unsure of the case where there are vga class devices but we don't want a vga console (hint: GPU computing). It seems there is no way in your code to allow us to run the option ROMs for a "vga" device and not enable a vga console. This is a cooperative project and some patience from all sides is important. So please bear with us as we try to make sure we understand your needs and what you are doing. Very trivial changes can turn into problems in ways we do not expect, and VGA and ROM issues have been a headache. thanks ron From markw at wolfenet.org Thu Jan 3 03:15:36 2008 From: markw at wolfenet.org (markw) Date: Wed, 02 Jan 2008 18:15:36 -0800 Subject: [LinuxBIOS] Kino LX800 AMD Geode based board In-Reply-To: <4777EA30.9010406@gmail.com> References: <4776CCA6.6060803@wolfenet.org> <4777EA30.9010406@gmail.com> Message-ID: <477C4548.7010501@wolfenet.org> Tom Sylla wrote: > markw wrote: >> Ok, talking to guys on IRC and they said to post up here. I've been >> challenged to see if I can come up with a system that boots in sub 10 >> seconds to a command prompt with networking. I'm sitting on a few Kino >> LX800 boards that we use for other projects, but I'm willing to >> sacrifice one for this. > > I would bet you can achieve that goal with that board. > >> The board has sata onboard using an ALI M5281 controller. It also uses >> the geode CS5536 ide controller, so the sata stuff may not be an issue. > > A Compactflash card on the IDE interface is you best bet for easy speed. > >> I'd like to to LB and kernel in flash, but if the hardware won't suppor >> a 16mbit flash, then I'll do lb/filo and boot from CF over the standard >> ide channel. The board currently has a 49fl004 socketed flash. Plan on >> using a stripped down debian install, since that's the only one I can >> reliably shrink. > > The 5536 on that board will support up to a 256MB boot ROM, and 2MB LPC > ROMs are pretty accessible now. > Ok, the board has a plcc 32 rom socket on it, so it looks like I'm limited to 8mbit without constructive surgery and adding address lines. Looks like a LB/Filo setup booting off parallel compact flash. Any good sources for spare flash roms? Digikey? Thanks, Mark From corey.osgood at gmail.com Thu Jan 3 04:41:21 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Wed, 02 Jan 2008 22:41:21 -0500 Subject: [LinuxBIOS] [Patch] Fix CONFIG_CONSOLE_VGA handling in default pci_dev_init. In-Reply-To: <13426df10801021731l31ebe422y2ef6567de06fd2be@mail.gmail.com> References: <20080102091638.GA11860@skynet.be> <13426df10801021326v64bee348ic601555df6b31337@mail.gmail.com> <20080103010303.GA14090@skynet.be> <13426df10801021731l31ebe422y2ef6567de06fd2be@mail.gmail.com> Message-ID: <477C5961.7060207@gmail.com> ron minnich wrote: > On Jan 2, 2008 5:03 PM, Luc Verhaegen wrote: > >> If you still do not believe logic, then please set CONFIG_CONSOLE_VGA >> without setting CONFIG_PCI_ROM_RUN and then build your rom. The build >> will fail due to missing symbols. >> > > That's a prolem. Which symbols? Which mainboards? This is an error but > it has been a long enough time since I did this that I can easily > believe it will happen. > On any board. Just an example: gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T /home/corey/linuxbios/msi_945g/LinuxBIOSv2/src/config/linuxbios_ram.ld linuxbios_ram.o linuxbios_ram.o: In function `pci_dev_init': (.text+0x33f2): undefined reference to `pci_rom_probe' linuxbios_ram.o: In function `pci_dev_init': (.text+0x3402): undefined reference to `pci_rom_load' linuxbios_ram.o: In function `pci_dev_init': (.text+0x3412): undefined reference to `run_bios' collect2: ld returned 1 exit status make[1]: *** [linuxbios_ram] Error 1 make[1]: Leaving directory `/home/corey/linuxbios/msi_945g/LinuxBIOSv2/targets/gigabyte/m57sli/m57sli/normal' make: *** [normal/linuxbios.rom] Error 1 From rminnich at gmail.com Thu Jan 3 06:41:18 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 2 Jan 2008 21:41:18 -0800 Subject: [LinuxBIOS] [Patch] Fix CONFIG_CONSOLE_VGA handling in default pci_dev_init. In-Reply-To: <477C5961.7060207@gmail.com> References: <20080102091638.GA11860@skynet.be> <13426df10801021326v64bee348ic601555df6b31337@mail.gmail.com> <20080103010303.GA14090@skynet.be> <13426df10801021731l31ebe422y2ef6567de06fd2be@mail.gmail.com> <477C5961.7060207@gmail.com> Message-ID: <13426df10801022141u413578f0r26c28e472cf38185@mail.gmail.com> This patch fixes the problem. It's not elegant but v2 is on the path to obsolescence and I would rather not do something more complex. Comments welcome. Luc, thanks for raising this issue. ron -------------- next part -------------- A non-text attachment was scrubbed... Name: fixdev.diff Type: text/x-patch Size: 683 bytes Desc: not available URL: From libv at skynet.be Thu Jan 3 08:38:08 2008 From: libv at skynet.be (Luc Verhaegen) Date: Thu, 3 Jan 2008 08:38:08 +0100 Subject: [LinuxBIOS] [Patch] Fix CONFIG_CONSOLE_VGA handling in default pci_dev_init. In-Reply-To: <13426df10801022141u413578f0r26c28e472cf38185@mail.gmail.com> References: <20080102091638.GA11860@skynet.be> <13426df10801021326v64bee348ic601555df6b31337@mail.gmail.com> <20080103010303.GA14090@skynet.be> <13426df10801021731l31ebe422y2ef6567de06fd2be@mail.gmail.com> <477C5961.7060207@gmail.com> <13426df10801022141u413578f0r26c28e472cf38185@mail.gmail.com> Message-ID: <20080103073807.GA14556@skynet.be> On Wed, Jan 02, 2008 at 09:41:18PM -0800, ron minnich wrote: > This patch fixes the problem. It's not elegant but v2 is on the path > to obsolescence and I > would rather not do something more complex. > > Comments welcome. Luc, thanks for raising this issue. > > ron Grep the tree. Find out where CONFIG_PCI_ROM_RUN is used. Find out where CONFIG_CONSOLE_VGA is used. Find out where vga_inited is used. Find out that my patch was actually rather trivial, and that there really is nothing to be afraid of. Needlessly including the pci_rom and emulator code is rather bad. Especially when i am working hard to not include a 64kB vga bios and instead limit the size for equal functionality to several kB. As for complexity, i am looking at a +4400 -1000 diff for native unichrome already. How useful is linuxbiosv3 at this point? Can it be used to boot something as well-known as the epia-m already? I really do not see what you continue to keep having against this trivial and rather sane fix. Luc Verhaegen. From libv at skynet.be Thu Jan 3 09:21:25 2008 From: libv at skynet.be (Luc Verhaegen) Date: Thu, 3 Jan 2008 09:21:25 +0100 Subject: [LinuxBIOS] [Patch] Fix CONFIG_CONSOLE_VGA handling in default pci_dev_init. In-Reply-To: <13426df10801021731l31ebe422y2ef6567de06fd2be@mail.gmail.com> References: <20080102091638.GA11860@skynet.be> <13426df10801021326v64bee348ic601555df6b31337@mail.gmail.com> <20080103010303.GA14090@skynet.be> <13426df10801021731l31ebe422y2ef6567de06fd2be@mail.gmail.com> Message-ID: <20080103082125.GB14556@skynet.be> On Wed, Jan 02, 2008 at 05:31:27PM -0800, ron minnich wrote: > On Jan 2, 2008 5:03 PM, Luc Verhaegen wrote: > > > What i am trying to do is implement native VGA bring-up for unichrome. I > > have had userspace code doing this on top of a clean linuxbios for more > > than 8 months. This is not just my X driver, i can also set up standard > > vga text mode, so it is not a pipe dream. > > That's great to hear. Be aware that SiS also did native vga text mode > in 2000, by Ollie Lo. So, we know that it is possible to have this > work. We have done a fair amount of native and emulated VGA bringup > over the years. Where did this code go? > > In that light it is perfectly valid to claim CONFIG_CONSOLE_VGA > > without setting CONFIG_PCI_ROM_RUN, because: > > * i have no need for a vga rom, as i provide the necessary code for a > > full vga text mode bringup myself. > > * i have no need to run any other rom either. > > * i do want vga console logging. > > > > Ah. Now I see what you are trying to do. I misunderstood from your > first message. No argument. We've been doing this for years. And if > you can't do it, then something is broken for sure. So I'm happy to > see it fixed. > > At the same time, let's suppose for the sake of argument that you set > BOTH CONFIG_CONSOLE_VGA and CONFIG_PCI_ROM_RUN AND you have the native > hardware bringup. How does that hurt your native device? It doesn't, except that it makes this whole exercise rather useless. What point is there in a fully free bios when one still uselessly includes emulator code? > There's no > option rom for it --> it won't be run. I'd like to understand this. We > have had cases where people had native bringup and installed a vga > card, and both were needed. In that case we would want roms to run. What about providing both CONFIG_PCI_ROM_RUN and CONFIG_CONSOLE_VGA, at the same time? In the case a standalone card is used, the target Config.lb should have CONFIG_PCI_ROM_RUN. But it should never be forced by the motherboard or a device Config.lb when not needed. > > So when i initialise the unichrome, i set vga_inited myself, like any > > device driver should when it initialises a vga compatible device to a > > vga compatible state and expects the console code to make use of it as a > > vga compatible console. > > OK. It's fine to set it there I suppose. Why "I suppose"? vga_inited is from the console code. We are currently only setting it, as an extern, in the device code. What could stop anyone from setting it in any other code? > It was considered. I think there is a bigger picture than you might > have realised. Torsten also pointed out a secondary issue. CONFIG_CONSOLE_VGA is not the right solution in that case. Maybe CONFIG_VGA_ROM_RUN should be trivially introduced. > I read your patch. I am still unsure of the case where there are vga > class devices but we don't want a vga console (hint: GPU computing). As one of the main radeonhd driver developers, i am rather acutely aware of gpgpu. But i fail to see the relevance of this here. > It seems there is no way in your code to allow us to run the option > ROMs for a "vga" device and not enable a vga console. My patch allows this in the exact same manner as before. Please look at the resulting code. The real question is: What happens the unerring linuxbios user only specificies only CONFIG_CONSOLE_VGA, and still expects it to work with a vga rom. But this is a purely an issue of bad former practice and bad documentation. Both options should be specified if both are needed. > This is a cooperative project and some patience from all sides is > important. So please bear with us as we try to make sure we understand > your needs and what you are doing. Very trivial changes can turn into > problems in ways we do not expect, and VGA and ROM issues have been a > headache. Heh. Luc Verhaegen. From joe at smittys.pointclark.net Thu Jan 3 10:50:29 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Thu, 03 Jan 2008 04:50:29 -0500 Subject: [LinuxBIOS] [Patch] Fix CONFIG_CONSOLE_VGA handling in default pci_dev_init. In-Reply-To: <20080103082125.GB14556@skynet.be> References: <20080102091638.GA11860@skynet.be> <13426df10801021326v64bee348ic601555df6b31337@mail.gmail.com> <20080103010303.GA14090@skynet.be> <13426df10801021731l31ebe422y2ef6567de06fd2be@mail.gmail.com> <20080103082125.GB14556@skynet.be> Message-ID: <20080103045029.9fzx7f700sgg00wo@www.smittys.pointclark.net> > > The real question is: > What happens the unerring linuxbios user only specificies only > CONFIG_CONSOLE_VGA, and still expects it to work with a vga rom. But > this is a purely an issue of bad former practice and bad documentation. > > Both options should be specified if both are needed. > I think it is pretty clearly stated here: http://linuxbios.org/VGA_support Also this might help some: http://www.linuxbios.org/data/vgabios/ Thanks - Joe From duwe at lst.de Thu Jan 3 12:05:02 2008 From: duwe at lst.de (Torsten Duwe) Date: Thu, 3 Jan 2008 12:05:02 +0100 Subject: [LinuxBIOS] [Patch] Fix CONFIG_CONSOLE_VGA handling in default pci_dev_init. In-Reply-To: <20080103082125.GB14556@skynet.be> References: <20080102091638.GA11860@skynet.be> <13426df10801021731l31ebe422y2ef6567de06fd2be@mail.gmail.com> <20080103082125.GB14556@skynet.be> Message-ID: <200801031205.02320.duwe@lst.de> On Thursday 03 January 2008, Luc Verhaegen wrote: > > It was considered. I think there is a bigger picture than you might > > have realised. Torsten also pointed out a secondary issue. > > CONFIG_CONSOLE_VGA is not the right solution in that case. Maybe > CONFIG_VGA_ROM_RUN should be trivially introduced. To not increase the obvious confusion further, I would call the option something negative, like ...SKIP_NON_VGA, so nobody assumes it enables any ROM execution. Maybe introduce this for v3. > > I read your patch. I am still unsure of the case where there are vga > > class devices but we don't want a vga console (hint: GPU computing). > > As one of the main radeonhd driver developers, i am rather acutely aware > of gpgpu. But i fail to see the relevance of this here. Indeed. PCI_ROM_RUN will do, regardless of the console. > > It seems there is no way in your code to allow us to run the option > > ROMs for a "vga" device and not enable a vga console. > > My patch allows this in the exact same manner as before. Please look at > the resulting code. > > The real question is: > What happens the unerring linuxbios user only specificies only > CONFIG_CONSOLE_VGA, and still expects it to work with a vga rom. But > this is a purely an issue of bad former practice and bad documentation. Nope, it's a *bug* noone has noticed until you tried. We can now fix the code or redefine the semantics. Your patch implicitly does the latter, and without further explanation I assumed you didn't understand them. Ron already mentioned this is v2, so I'd say let's go for it; original patch ACKed. If you had mentioned that CONSOLE_VGA=1 PCI_ROM_RUN=0 does not compile and you are working on a free standing driver, that would have saved us from the irrelevant part of this discussion. So if nobody objects I'll commit the original patch, after the west coast has had a chance to comment ;-) Torsten From tsylla at gmail.com Thu Jan 3 15:18:12 2008 From: tsylla at gmail.com (Tom Sylla) Date: Thu, 3 Jan 2008 09:18:12 -0500 Subject: [LinuxBIOS] Kino LX800 AMD Geode based board In-Reply-To: <477C4548.7010501@wolfenet.org> References: <4776CCA6.6060803@wolfenet.org> <4777EA30.9010406@gmail.com> <477C4548.7010501@wolfenet.org> Message-ID: <57947bf80801030618x728b7094t9ed5bad0467f1374@mail.gmail.com> On Jan 2, 2008 9:15 PM, markw wrote: > Ok, the board has a plcc 32 rom socket on it, so it looks like I'm > limited to 8mbit without constructive surgery and adding address lines. I can't quite read the part number of the PMC flash device on any of the on-line pictures of the Kino board. My guess is that it is an LPC/FWH ROM, not a parallel ROM. ROMs on LPC have 4 muxed address/data lines. You don't need to worry about adding address wires, all memory/FWH reads/writes are 32-bit addressed. > Looks like a LB/Filo setup booting off parallel compact flash. > Any good sources for spare flash roms? Digikey? Search Mouser for "LPC", and look at the memory ICs category. I see a couple of 4 and 8Mb parts in stock. You can use the 16Mb parts, if you can find them to buy. I can't find any on-line, but a distributor may be able to get them (SST49LF016C {FWH} or SST49LF160C {LPC}) Make sure you purchase the correct version of ROM for how your board is strapped. Boot your board, and check the PRI_BOOT_LOC field to know where 5536 is booting from. (the PMC part in the pictures of the Kino board can work in either mode) From Marc.Karasek at Sun.COM Thu Jan 3 15:34:04 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Thu, 03 Jan 2008 09:34:04 -0500 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... Message-ID: <477CF25C.7070901@sun.com> Here is the patch file that should create a Makefile.distro in the target directory and then include this file as part of the make process. It checks for the buildid option for ld using awk in buildtarget script. Then sets the appropriate flag in the file. I do not check to see if the Makefile.distro is "current". It just checks to see if one is present or not. -- /********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 *********************/ -------------- next part -------------- A non-text attachment was scrubbed... Name: ld.patch Type: text/x-patch Size: 5200 bytes Desc: not available URL: From rminnich at gmail.com Thu Jan 3 17:19:23 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 3 Jan 2008 08:19:23 -0800 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: <477CF25C.7070901@sun.com> References: <477CF25C.7070901@sun.com> Message-ID: <13426df10801030819p5fa4f8enc9bc2aa6557ad460@mail.gmail.com> Marc, did you see my earlier patch that fixed this problem? I submitted it almost two weeks ago. You patch has a larger footprint and I would like you to look at mine. It is waiting on an ACK from *someone* but I think it would solve your problem. I think here in the US everyone is still on vacation, so we should wait until next week to resolve this. thanks ron From rminnich at gmail.com Thu Jan 3 17:25:12 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 3 Jan 2008 08:25:12 -0800 Subject: [LinuxBIOS] Fwd: Possible stack protect solutions (RESEND) Message-ID: <13426df10801030825q634ce66fsb3ed6389158fbb71@mail.gmail.com> This patch will enable setting distro variables such as -fno_stack_protector as needed. It is a simple patch to buildtarget and can be extended for other uses. If this patch is acceptable then we can fix the various makefiles to include the variable. The only remaining question is the name -- is CPU_OPT really appropriate? Signed-off-by: Ronald G. Minnich ---------- Forwarded message ---------- From: ron minnich Date: Dec 20, 2007 11:24 AM Subject: Re: [LinuxBIOS] Possible stack protect solutions To: Jordan Crouse Cc: linuxbios at linuxbios.org Try this. This patch to buildtarget 1. sets up cpu opt for the no stack protector thing 2. sets up the makefiles for the target 3. the target builds But it's not picking up CPU_OPT. So we MUST have the other patch that ALWAYS includes CPU_OPT. That said, I'd rather make the variable DISTRO_CC_OPT or some such. Thanks ron -------------- next part -------------- A non-text attachment was scrubbed... Name: buildtarget.diff Type: text/x-patch Size: 661 bytes Desc: not available URL: From stepan at coresystems.de Thu Jan 3 18:12:58 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 3 Jan 2008 18:12:58 +0100 Subject: [LinuxBIOS] Fwd: Possible stack protect solutions (RESEND) In-Reply-To: <13426df10801030825q634ce66fsb3ed6389158fbb71@mail.gmail.com> References: <13426df10801030825q634ce66fsb3ed6389158fbb71@mail.gmail.com> Message-ID: <20080103171258.GA22798@coresystems.de> * ron minnich [080103 17:25]: > This patch will enable setting distro variables such as > -fno_stack_protector as needed. It is a simple patch to buildtarget > and can be extended for other uses. > > If this patch is acceptable then we can fix the various makefiles to > include the variable. > > The only remaining question is the name -- is CPU_OPT really appropriate? Why not make it CFLAGS? The C compiler is called CC in our environment, too. > Signed-off-by: Ronald G. Minnich Acked-by: Stefan Reinauer Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From joe at smittys.pointclark.net Thu Jan 3 18:15:05 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Thu, 03 Jan 2008 12:15:05 -0500 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: <477CF25C.7070901@sun.com> References: <477CF25C.7070901@sun.com> Message-ID: <20080103121505.6lg6anehskkco0o4@www.smittys.pointclark.net> Quoting Marc Karasek : > Here is the patch file that should create a Makefile.distro in the > target directory and then include this file as part of the make > process. It checks for the buildid option for ld using awk in > buildtarget script. Then sets the appropriate flag in the file. > > I do not check to see if the Makefile.distro is "current". It just > checks to see if one is present or not. > Excellent work Marc. I have been waiting for this to test on my new AMD Athlon X2 x86_64 Fedora Core 8 Laptop. Unfortunatly, I won't be able to try it out until this weekend. If all goes well, you will definatly have my ACK:-) Thanks - Joe From joe at smittys.pointclark.net Thu Jan 3 18:18:08 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Thu, 03 Jan 2008 12:18:08 -0500 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: <13426df10801030819p5fa4f8enc9bc2aa6557ad460@mail.gmail.com> References: <477CF25C.7070901@sun.com> <13426df10801030819p5fa4f8enc9bc2aa6557ad460@mail.gmail.com> Message-ID: <20080103121808.jjslvx19xcs84g88@www.smittys.pointclark.net> Quoting ron minnich : > Marc, did you see my earlier patch that fixed this problem? > > I submitted it almost two weeks ago. > > You patch has a larger footprint and I would like you to look at mine. > It is waiting on an ACK from *someone* but I think it would solve your > problem. > > I think here in the US everyone is still on vacation, so we should > wait until next week to resolve this. > > thanks > > ron > Sorry Ron I must have missed that one??? Could you re-attach it? Thanks - Joe From stepan at coresystems.de Thu Jan 3 18:22:37 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 3 Jan 2008 18:22:37 +0100 Subject: [LinuxBIOS] [lbv2][patch]Support i18n'd GCCs In-Reply-To: References: Message-ID: <20080103172236.GA26568@coresystems.de> * Patrick Georgi [071230 18:20]: > Hi, > > attached patch fixes build on i18n'd GCCs which might not emit "install:" > as expected. > > > Regards, > Patrick Georgi > Ubuntu's gcc doesn't write "install:" in german locales. > Signed-off-by: Patrick Georgi Acked-by: Stefan Reinauer -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From rminnich at gmail.com Thu Jan 3 18:30:06 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 3 Jan 2008 09:30:06 -0800 Subject: [LinuxBIOS] Fwd: Possible stack protect solutions (RESEND) In-Reply-To: <20080103171258.GA22798@coresystems.de> References: <13426df10801030825q634ce66fsb3ed6389158fbb71@mail.gmail.com> <20080103171258.GA22798@coresystems.de> Message-ID: <13426df10801030930u4a8b1ef7m5db8ecd8d89b3297@mail.gmail.com> On Jan 3, 2008 9:12 AM, Stefan Reinauer wrote: > * ron minnich [080103 17:25]: > > This patch will enable setting distro variables such as > > -fno_stack_protector as needed. It is a simple patch to buildtarget > > and can be extended for other uses. > > > > If this patch is acceptable then we can fix the various makefiles to > > include the variable. > > > > The only remaining question is the name -- is CPU_OPT really appropriate? > > Why not make it CFLAGS? The C compiler is called CC in our environment, > too. like this? Tested on FC8 and works fine. ron -------------- next part -------------- A non-text attachment was scrubbed... Name: fixflags.diff Type: text/x-patch Size: 822 bytes Desc: not available URL: From rminnich at gmail.com Thu Jan 3 18:37:54 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 3 Jan 2008 09:37:54 -0800 Subject: [LinuxBIOS] RESEND: patch: fix the problem with CONFIG_CONSOLE_VGA not pulling in the emulator Message-ID: <13426df10801030937k5ffecaabndc421bbd5e0a1ce0@mail.gmail.com> This is a resend from yesterday, I am hoping for an ack :-) ron -------------- next part -------------- A non-text attachment was scrubbed... Name: fixdev.diff Type: text/x-patch Size: 683 bytes Desc: not available URL: From rminnich at gmail.com Thu Jan 3 18:50:58 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 3 Jan 2008 09:50:58 -0800 Subject: [LinuxBIOS] RESEND: v3 patch for console functions, and mods to lib/lar.c to support a void * parameter for running functions. Message-ID: <13426df10801030950r65b36e0he3552fd94828ac5f@mail.gmail.com> attached. I need an ack, we have discussed these already. ron -------------- next part -------------- A non-text attachment was scrubbed... Name: libconsolelar.diff Type: text/x-patch Size: 4031 bytes Desc: not available URL: From stepan at coresystems.de Thu Jan 3 19:03:35 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 3 Jan 2008 19:03:35 +0100 Subject: [LinuxBIOS] RESEND: v3 patch for console functions, and mods to lib/lar.c to support a void * parameter for running functions. In-Reply-To: <13426df10801030950r65b36e0he3552fd94828ac5f@mail.gmail.com> References: <13426df10801030950r65b36e0he3552fd94828ac5f@mail.gmail.com> Message-ID: <20080103180335.GC4142@coresystems.de> * ron minnich [080103 18:50]: > +void banner(int level, char *s) > +{ > + printk(level, "===========================%s===========================\n", s); > +} I don't like this function all too much.. I'd prefer something where the width of the banner stays constant. > void die(const char *str) > { > printk(BIOS_EMERG, str); > while (1) > - hlt(); > + console_tx_byte(0, (void *)0); > } Will this not lead to the CPU consuming cycles and becoming/staying really hot? Can't we clear the FIFO any other way and go to CPU hlt afterwards? Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From jordan.crouse at amd.com Thu Jan 3 18:47:35 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Thu, 3 Jan 2008 10:47:35 -0700 Subject: [LinuxBIOS] Fwd: Possible stack protect solutions (RESEND) In-Reply-To: <13426df10801030930u4a8b1ef7m5db8ecd8d89b3297@mail.gmail.com> References: <13426df10801030825q634ce66fsb3ed6389158fbb71@mail.gmail.com> <20080103171258.GA22798@coresystems.de> <13426df10801030930u4a8b1ef7m5db8ecd8d89b3297@mail.gmail.com> Message-ID: <20080103174735.GA14422@cosmic.amd.com> On 03/01/08 09:30 -0800, ron minnich wrote: > On Jan 3, 2008 9:12 AM, Stefan Reinauer wrote: > > * ron minnich [080103 17:25]: > > > This patch will enable setting distro variables such as > > > -fno_stack_protector as needed. It is a simple patch to buildtarget > > > and can be extended for other uses. > > > > > > If this patch is acceptable then we can fix the various makefiles to > > > include the variable. > > > > > > The only remaining question is the name -- is CPU_OPT really appropriate? > > > > Why not make it CFLAGS? The C compiler is called CC in our environment, > > too. > > > like this? > > Tested on FC8 and works fine. Looks good to me. Jordan From c-d.hailfinger.devel.2006 at gmx.net Thu Jan 3 19:20:42 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 03 Jan 2008 19:20:42 +0100 Subject: [LinuxBIOS] RESEND: v3 patch for console functions, and mods to lib/lar.c to support a void * parameter for running functions. In-Reply-To: <13426df10801030950r65b36e0he3552fd94828ac5f@mail.gmail.com> References: <13426df10801030950r65b36e0he3552fd94828ac5f@mail.gmail.com> Message-ID: <477D277A.3090302@gmx.net> On 03.01.2008 18:50, ron minnich wrote: > Add a void * parameter to the LAR run functions; needed for some cases, > in particular CAR. > I still do not like that because it works around a bug in our code. It should work just fine without that parameter. Regards, Carl-Daniel From rminnich at gmail.com Thu Jan 3 19:26:40 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 3 Jan 2008 10:26:40 -0800 Subject: [LinuxBIOS] RESEND: v3 patch for console functions, and mods to lib/lar.c to support a void * parameter for running functions. In-Reply-To: <477D277A.3090302@gmx.net> References: <13426df10801030950r65b36e0he3552fd94828ac5f@mail.gmail.com> <477D277A.3090302@gmx.net> Message-ID: <13426df10801031026t234d74abw9950ad761ea9717b@mail.gmail.com> On Jan 3, 2008 10:20 AM, Carl-Daniel Hailfinger wrote: > On 03.01.2008 18:50, ron minnich wrote: > > > Add a void * parameter to the LAR run functions; needed for some cases, > > in particular CAR. > > > > I still do not like that because it works around a bug in our code. It > should work just fine without that parameter. I don't agree. There are limits on where the stack ends up in CAR. I would be more comfortable having the option of starting with a new function with a new stack once CAR is turned off. That said, I will hold off and let others fix CAR. Let me know when it is ready and I will test on Alix. However, please don't fix the problem by moving the stack. You can't relocate the stack in a general way due to things like pointers to auto. Thanks ron From rminnich at gmail.com Thu Jan 3 19:37:45 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 3 Jan 2008 10:37:45 -0800 Subject: [LinuxBIOS] [Patch] Fix CONFIG_CONSOLE_VGA handling in default pci_dev_init. In-Reply-To: <200801031205.02320.duwe@lst.de> References: <20080102091638.GA11860@skynet.be> <13426df10801021731l31ebe422y2ef6567de06fd2be@mail.gmail.com> <20080103082125.GB14556@skynet.be> <200801031205.02320.duwe@lst.de> Message-ID: <13426df10801031037s51923b12h5a020ccddb9bb5bf@mail.gmail.com> On Jan 3, 2008 3:05 AM, Torsten Duwe wrote: > If you had mentioned that CONSOLE_VGA=1 PCI_ROM_RUN=0 does not compile and you > are working on a free standing driver, that would have saved us from the > irrelevant part of this discussion. Exactly. Simple, clear bug reports are always useful. Took me a few minutes to fix. > > So if nobody objects I'll commit the original patch, after the west coast has > had a chance to comment ;-) Luc's patch is unnecessary as submitted; it will eliminate an option that, in the past, was deemed desirable by some users (they may no longer care, it may no longer matter). You can just use the patch I sent, which fixes the problem and preserves behavior which, at one point, somebody wanted. When the code got broken I am not sure. That said, if the feeling is that we should go with Luc's patch, I have no objection. I should comment on the "who wants an emulator in a free BIOS" argument; that discussion was resolved years ago, in favor or "lots of people need it, whether they want it or not" -- I don't like it either, but that's the way it goes. I was one of the strongest opponents of using the option ROMs. I no longer see any way out of using the option ROMs in some cases. It's the same reason we have binary blobs in the linux kernel (e.g. microcode patches); sometimes there is no choice. So, even if we have a totally free driver for graphics, we will probably see continuing demand for the emulator, to support cards with option ROMs. ron From rminnich at gmail.com Thu Jan 3 19:52:14 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 3 Jan 2008 10:52:14 -0800 Subject: [LinuxBIOS] RESEND: v3 patch for console functions, and mods to lib/lar.c to support a void * parameter for running functions. In-Reply-To: <20080103180335.GC4142@coresystems.de> References: <13426df10801030950r65b36e0he3552fd94828ac5f@mail.gmail.com> <20080103180335.GC4142@coresystems.de> Message-ID: <13426df10801031052s7767d53ct238b22737f4b2a12@mail.gmail.com> On Jan 3, 2008 10:03 AM, Stefan Reinauer wrote: > Will this not lead to the CPU consuming cycles and becoming/staying > really hot? yeah but, hey, it should never happen. CPUs don't melt any more when you push them that hard anyway, usually they slow themselves down or in some cases reset. I don't think it's a real issue. Also, recall that it will be doing a lot of IO, not computing pi :-) > > Can't we clear the FIFO any other way and go to CPU hlt afterwards? > No, because of JTAG. I've had really terrible problems with JTAG debuggers when CPUs halt. Even a tight loop (while (1);) can be hard to break into on some CPUs. But if the CPU is in a call/return-with-IO type mode, it is pretty easy to grab it with JTAG, stop it, and debug it. thanks ron From rminnich at gmail.com Thu Jan 3 19:53:15 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 3 Jan 2008 10:53:15 -0800 Subject: [LinuxBIOS] RESEND: v3 patch for console functions, and mods to lib/lar.c to support a void * parameter for running functions. In-Reply-To: <20080103180335.GC4142@coresystems.de> References: <13426df10801030950r65b36e0he3552fd94828ac5f@mail.gmail.com> <20080103180335.GC4142@coresystems.de> Message-ID: <13426df10801031053tfe0c69s118c5e6ed1c90890@mail.gmail.com> On Jan 3, 2008 10:03 AM, Stefan Reinauer wrote: > * ron minnich [080103 18:50]: > > +void banner(int level, char *s) > > +{ > > + printk(level, "===========================%s===========================\n", s); > > +} > > > I don't like this function all too much.. I'd prefer something where the > width of the banner stays constant. hmm. OK, that means a strlen call but I guess we can do it. ron From rminnich at gmail.com Thu Jan 3 20:00:54 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 3 Jan 2008 11:00:54 -0800 Subject: [LinuxBIOS] april meeting in denver Message-ID: <13426df10801031100t34f51dd4jb8064c2a029fe159@mail.gmail.com> I've got some questions from people pending re: the meeting in Denver. Most of the US of A seems to still be on vacation, I am not getting answers from the organizers about the denver meeting. I hope to have more info next week. thanks ron From markw at wolfenet.org Thu Jan 3 20:34:20 2008 From: markw at wolfenet.org (mark wolfe) Date: Thu, 03 Jan 2008 11:34:20 -0800 Subject: [LinuxBIOS] Kino LX800 AMD Geode based board In-Reply-To: <57947bf80801030618x728b7094t9ed5bad0467f1374@mail.gmail.com> References: <4776CCA6.6060803@wolfenet.org> <4777EA30.9010406@gmail.com> <477C4548.7010501@wolfenet.org> <57947bf80801030618x728b7094t9ed5bad0467f1374@mail.gmail.com> Message-ID: <477D38BC.2070803@wolfenet.org> The bios on the board is a PMC 49FL004t-33jce. Found a data sheet for that, and it does use the LPC. I'm looking at the SST parts right now. Googling for PRI_BOOT_LOC brings me right back to the list. :) Looks like this is shown with flash rom? Guess it's time to fire up svn and grab some code. This stuff has come a long way since the 27cxxx chips. :) Mark Tom Sylla wrote: > On Jan 2, 2008 9:15 PM, markw wrote: >> Ok, the board has a plcc 32 rom socket on it, so it looks like I'm >> limited to 8mbit without constructive surgery and adding address lines. > > I can't quite read the part number of the PMC flash device on any of > the on-line pictures of the Kino board. My guess is that it is an > LPC/FWH ROM, not a parallel ROM. ROMs on LPC have 4 muxed address/data > lines. You don't need to worry about adding address wires, all > memory/FWH reads/writes are 32-bit addressed. > >> Looks like a LB/Filo setup booting off parallel compact flash. >> Any good sources for spare flash roms? Digikey? > > Search Mouser for "LPC", and look at the memory ICs category. I see a > couple of 4 and 8Mb parts in stock. You can use the 16Mb parts, if you > can find them to buy. I can't find any on-line, but a distributor may > be able to get them (SST49LF016C {FWH} or SST49LF160C {LPC}) > > Make sure you purchase the correct version of ROM for how your board > is strapped. Boot your board, and check the PRI_BOOT_LOC field to know > where 5536 is booting from. (the PMC part in the pictures of the Kino > board can work in either mode) > From Marc.Karasek at Sun.COM Thu Jan 3 22:15:42 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Thu, 03 Jan 2008 16:15:42 -0500 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: <13426df10801031043o3ea5df06r62f51e7c63fabaaa@mail.gmail.com> References: <477CF25C.7070901@sun.com> <13426df10801030819p5fa4f8enc9bc2aa6557ad460@mail.gmail.com> <477D2366.7090500@sun.com> <13426df10801031028y3dce3f53g15e336f1df8907b1@mail.gmail.com> <477D2A90.3070001@sun.com> <13426df10801031043o3ea5df06r62f51e7c63fabaaa@mail.gmail.com> Message-ID: <477D507E.4030106@sun.com> Here is the patch with the ld option check as well. I had to make a few changes to Ron's original patch. One of the problems was that CFLAGS was being set as a := in the Makefile and was overwriting the += that was in Makefile.settings. So I added DISTRO_CFLAGS and DISTRO_LFLAGS for the two additonal flags. The reason for two was that the build-id option is only used during linking and generated warnings if used on a compile line and was not being pulled in for the linker lines. These defines were added to the appropriate places in the Makefile via the Config.lb file. /********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 *********************/ ron minnich wrote: > On Jan 3, 2008 10:33 AM, Marc Karasek wrote: > > >> I could add the check to this patch (using awk to check ld) to add the >> -Wl option to the EXTRA_CFLAGS. >> > > cool! I'll take it and add it. > > ron > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fixflags2.diff Type: text/x-patch Size: 4053 bytes Desc: not available URL: From myles at pel.cs.byu.edu Thu Jan 3 22:58:05 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Thu, 3 Jan 2008 14:58:05 -0700 Subject: [LinuxBIOS] VGA help under QEMU Message-ID: <00c001c84e53$b7e83640$a023040a@chimp> On Jan 3, 2008 12:51 PM, Myles Watson wrote: > > On Jan 3, 2008 10:24 AM, ron minnich wrote: > > attached are: > > output from boot > > bios > > .config > > all .bin files qemu might have used. > > > > I ran this with: > > qemu -serial stdio -L . -kernel linux-2.6.15-bochs/vmlinux -hdc hda > > -hda hda | tee out > > > > thanks > > ron > > > > Thanks. The difference is indeed the vga bios. The one I have > attached is the latest one distributed with qemu. It works with v2, > but not v3. Yours works with v2 and v3. > > The obvious work-around for me is to use your vga bios, but it's a > pain to keep the old one around for everyone. > > I tried changing the emulator, but it didn't make a difference whether > I used x86emu or vm86. > > Do you have any suggestions? > > Myles > It turns out that LinuxBIOSv3 doesn't play well with the new vgabios-cirrus.bin from qemu. I've attached both versions so that people can play with them. LinuxBIOSv2 works with either one. Myles -------------- next part -------------- A non-text attachment was scrubbed... Name: vgabios-cirrus.bin.works Type: application/octet-stream Size: 35840 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vgabios-cirrus.bin.new Type: application/octet-stream Size: 35328 bytes Desc: not available URL: From duwe at lst.de Fri Jan 4 00:15:04 2008 From: duwe at lst.de (Torsten Duwe) Date: Fri, 4 Jan 2008 00:15:04 +0100 Subject: [LinuxBIOS] RESEND: patch: fix the problem with CONFIG_CONSOLE_VGA not pulling in the emulator In-Reply-To: <13426df10801030937k5ffecaabndc421bbd5e0a1ce0@mail.gmail.com> References: <13426df10801030937k5ffecaabndc421bbd5e0a1ce0@mail.gmail.com> Message-ID: <200801040015.04502.duwe@lst.de> On Thursday 03 January 2008, ron minnich wrote: > This is a resend from yesterday, I am hoping for an ack :-) Not yet. This fixes the problem Luc found along the way, and which nobody has cared about for a while. How do we want to express now that the console is on a VGA-compatible device without the necessity for any emulator (e.g. onboard SiS300, unichrome, i810 or maybe RS480)? Torsten From rminnich at gmail.com Fri Jan 4 00:23:46 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 3 Jan 2008 15:23:46 -0800 Subject: [LinuxBIOS] RESEND: patch: fix the problem with CONFIG_CONSOLE_VGA not pulling in the emulator In-Reply-To: <200801040015.04502.duwe@lst.de> References: <13426df10801030937k5ffecaabndc421bbd5e0a1ce0@mail.gmail.com> <200801040015.04502.duwe@lst.de> Message-ID: <13426df10801031523h3adbc50ajab4435f58d31d3de@mail.gmail.com> On Jan 3, 2008 3:15 PM, Torsten Duwe wrote: > On Thursday 03 January 2008, ron minnich wrote: > > This is a resend from yesterday, I am hoping for an ack :-) > > Not yet. This fixes the problem Luc found along the way, and which nobody has > cared about for a while. > > How do we want to express now that the console is on a VGA-compatible device > without the necessity for any emulator (e.g. onboard SiS300, unichrome, i810 > or maybe RS480)? well, will those on-board devices have an option ROM associated with them? If not, there is no issue; the option ROM won't be run. Luc has already set up his native code to set the vga_inited variable. There's a harder problem. What if we're on a a system with a unichrome and, for whatever reason, somebody drops in a different graphics card and wants that to be the console? Of the set of devices that *could* be the console, which one *should* be the console? For this latter case, in which there is a native non-option-ROM VGA device and a VGA device with an option ROM, you are going to need to leave the emulator in, I am afraid. I'm happy to be shown wrong, because I don't much like this situation. We never had a good solution to the latter problem. Standard bios rules are to use the one in the slot, ignoring the on-board device. Maybe this issue will never come up with a unichrome, but we need to solve it for other systems with native devices and pci-e slots that can take non-native cards with option roms. ron From duwe at lst.de Fri Jan 4 00:49:26 2008 From: duwe at lst.de (Torsten Duwe) Date: Fri, 4 Jan 2008 00:49:26 +0100 Subject: [LinuxBIOS] RESEND: patch: fix the problem with CONFIG_CONSOLE_VGA not pulling in the emulator In-Reply-To: <13426df10801031523h3adbc50ajab4435f58d31d3de@mail.gmail.com> References: <13426df10801030937k5ffecaabndc421bbd5e0a1ce0@mail.gmail.com> <200801040015.04502.duwe@lst.de> <13426df10801031523h3adbc50ajab4435f58d31d3de@mail.gmail.com> Message-ID: <200801040049.26921.duwe@lst.de> On Friday 04 January 2008, ron minnich wrote: > There's a harder problem. What if we're on a a system with a unichrome > and, for whatever reason, somebody drops in a different graphics card > and wants that to be the console? Of the set of devices that *could* > be the console, which one *should* be the console? > > For this latter case, in which there is a native non-option-ROM VGA > device and a VGA device with an option ROM, you are going to need to > leave the emulator in [...] True. Even those Epia-boards have a slot. Luc, or anyone else, have a board with VGA and totally without PCI, AGP or the like? Or is this a ROM space issue? My main concern is that console on VGA and ROM emulators are orthogonal, and one should not pull in the other, for design reasons. But if there is no hardware, I'll be quiet. Torsten From rminnich at gmail.com Fri Jan 4 00:57:22 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 3 Jan 2008 15:57:22 -0800 Subject: [LinuxBIOS] RESEND: patch: fix the problem with CONFIG_CONSOLE_VGA not pulling in the emulator In-Reply-To: <200801040049.26921.duwe@lst.de> References: <13426df10801030937k5ffecaabndc421bbd5e0a1ce0@mail.gmail.com> <200801040015.04502.duwe@lst.de> <13426df10801031523h3adbc50ajab4435f58d31d3de@mail.gmail.com> <200801040049.26921.duwe@lst.de> Message-ID: <13426df10801031557q39180981rd836b5a503c9b14c@mail.gmail.com> On Jan 3, 2008 3:49 PM, Torsten Duwe wrote: > My main concern is that console on VGA and ROM emulators are orthogonal, and > one should not pull in the other, for design reasons. But if there is no > hardware, I'll be quiet. I don't understand the comment. Console on VGA may in some cases depend on the ROM emulator. So they are not necessarily orthogonal I think. ron From c-d.hailfinger.devel.2006 at gmx.net Fri Jan 4 01:11:33 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 04 Jan 2008 01:11:33 +0100 Subject: [LinuxBIOS] RESEND: v3 patch for console functions, and mods to lib/lar.c to support a void * parameter for running functions. In-Reply-To: <13426df10801031026t234d74abw9950ad761ea9717b@mail.gmail.com> References: <13426df10801030950r65b36e0he3552fd94828ac5f@mail.gmail.com> <477D277A.3090302@gmx.net> <13426df10801031026t234d74abw9950ad761ea9717b@mail.gmail.com> Message-ID: <477D79B5.1040404@gmx.net> On 03.01.2008 19:26, ron minnich wrote: > On Jan 3, 2008 10:20 AM, Carl-Daniel Hailfinger > wrote: > >> On 03.01.2008 18:50, ron minnich wrote: >> >> >>> Add a void * parameter to the LAR run functions; needed for some cases, >>> in particular CAR. >>> >>> >> I still do not like that because it works around a bug in our code. It >> should work just fine without that parameter. >> > > I don't agree. There are limits on where the stack ends up in CAR. I > would be more comfortable having the option of starting with a new > function with a new stack once CAR is turned off. > A new stack would be OK, but not as a workaround for a bug. Being able to drop parts of the stack when CAR is disabled is an interesting feature, but I fear it will lead to a lot of headaches later on. I still have some code pending which uses part of the stack as a printk buffer right from the beginning of stage1, making it available for inspection by later stages or even a payload. Sorry, can't find that code right now. I'll try to come up with a concept that works for architectures where we must move the stack as well as architectures where we don't want to move the stack. > That said, I will hold off and let others fix CAR. Let me know when it > is ready and I will test on Alix. > Unfortunately, I do not have any Geode LX hardware, so I can't really test, but I can deliver patches. IIRC your problem was that the wbinvd only invalidated the CAR area without writing contents back to RAM, right? > However, please don't fix the problem by moving the stack. You can't > relocate the stack in a general way due to things like pointers to > auto. > I will find the root cause of the problem, and no, the fix will not involve moving the stack during runtime unless that is a hardware requirement. Regards, Carl-Daniel From duwe at lst.de Fri Jan 4 01:22:12 2008 From: duwe at lst.de (Torsten Duwe) Date: Fri, 4 Jan 2008 01:22:12 +0100 Subject: [LinuxBIOS] RESEND: patch: fix the problem with CONFIG_CONSOLE_VGA not pulling in the emulator In-Reply-To: <13426df10801031557q39180981rd836b5a503c9b14c@mail.gmail.com> References: <13426df10801030937k5ffecaabndc421bbd5e0a1ce0@mail.gmail.com> <200801040049.26921.duwe@lst.de> <13426df10801031557q39180981rd836b5a503c9b14c@mail.gmail.com> Message-ID: <200801040122.12720.duwe@lst.de> On Friday 04 January 2008, ron minnich wrote: > On Jan 3, 2008 3:49 PM, Torsten Duwe wrote: > > My main concern is that console on VGA and ROM emulators are orthogonal, > > and one should not pull in the other, for design reasons. But if there is > > no hardware, I'll be quiet. > > I don't understand the comment. Console on VGA may in some cases > depend on the ROM emulator. So they are not necessarily orthogonal I > think. For the board config, I meant. Some boards will have both ROM emu and VGA, some neither, some one of them but not the other. The big question is: do all 4 cases really exist out there? So far we're missing the case with open source onboard VGA, and not a single slot were an x86 ROM could appear. If not all 4 cases exist, orthogonality is academic. Torsten From c-d.hailfinger.devel.2006 at gmx.net Fri Jan 4 02:32:45 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 04 Jan 2008 02:32:45 +0100 Subject: [LinuxBIOS] april meeting in denver In-Reply-To: <13426df10801031100t34f51dd4jb8064c2a029fe159@mail.gmail.com> References: <13426df10801031100t34f51dd4jb8064c2a029fe159@mail.gmail.com> Message-ID: <477D8CBD.5050603@gmx.net> On 03.01.2008 20:00, ron minnich wrote: > I've got some questions from people pending re: the meeting in Denver. > Most of the US of A seems to still be on vacation, I am not getting > answers from the organizers about the denver meeting. I hope to have > more info next week. > April will be a time when I'm totally busy with finalizing my thesis, so I'd appreciate if someone could set up a live feed from the meeting. Is there any other event (preferably in Europe) where most of us will meet? Regards, Carl-Daniel From rminnich at gmail.com Fri Jan 4 02:43:34 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 3 Jan 2008 17:43:34 -0800 Subject: [LinuxBIOS] RESEND: v3 patch for console functions, and mods to lib/lar.c to support a void * parameter for running functions. In-Reply-To: <477D79B5.1040404@gmx.net> References: <13426df10801030950r65b36e0he3552fd94828ac5f@mail.gmail.com> <477D277A.3090302@gmx.net> <13426df10801031026t234d74abw9950ad761ea9717b@mail.gmail.com> <477D79B5.1040404@gmx.net> Message-ID: <13426df10801031743k5cfe98dcqe947aa97b7165d96@mail.gmail.com> I am restarting the CAR discussion a bit. I want to get a resync. One part of the discussion involves the idea that I am trying to avoid return from disable_car because of some "bug" in our code. It is not that simple. The issue is that, when the code enters disable_car,the CPU has been using cache as ram, and using "memory" at non-memory addresses. In disable_car, the CPU is supposed to disable cache as ram, and continue -- should it return? The return is on the stack. The function that called disable_car has its own stack variables. They're actually in cache, not ram. So if the code is going to return, it will need a working stack. It will need to restore the stack from cache to ram. But where is the stack? at c000 in one case. Where is ram? Somewhere else. So it is possible that variables on stack are wrong, if they are pointers to variables on the stack, and there is the problem of changing esp, ss, and then fixing up the stack for the RET. Here's a useful comment: x86/car/cache_as_ram_post.c: /* FIXME: I hope we don't need to change esp and ebp value here, so we can restore value from mmx sse back But the problem is the range is some io related, So don't go back */ If you look at the cache as ram for the amd and x86, you will find something interesting: it does not go back. x86: leal _iseg, %edi jmp *%edi For AMD, at the end of the mainboard cache as ram main, it calls post_cache_as_ram(void). At the end of that function is this: /*copy and execute linuxbios_ram */ copy_and_run(); /* We will not return */ in other words, once CAR is disabled, we chain to copy_and_run, and never return. We've also set up a new ESP. To put it simply, the most current CAR code *does not return* --because getting that right, for all CPUs, is tricky and not always possible. So, expecting a return from disable car is not really in line with what we do now. In fact, what we do now on most of v2 -- certainly on opteron -- is merely what I'm proposing we do on V3. I'm pasting in some old mail now, with my comments in[[[]]] ================================================================= Marc Jones wrote: > > Carl-Daniel Hailfinger wrote: > >> Dumb question: We know the location of the stack when we enter >> disable_car(). We also know that all memory belongs to us. Can we copy >> CAR stack contents to some safe location and restore them after wbinvd()? >> > > This shouldn't be needed. If the stack needed to be moved you would want > to do it before the wbinvd so you were copying from cache to memory. > Much faster than memory to memory. > > Marc > and I am too smart for my own good..... Here is the deal. Look in cpu/amd/model_lx/cache_as_ram.inc. /* If you wanted to maintain the stack in memory you would need to set the tags as dirty [[[ Good point here! For the wbinvd to push the stack out, we need to set cache tags! This is going to be tough on some CPUs -- how do we do it on LX? ]]] so the wbinvd would push out the old stack contents to memory */ /* Clear the cache, the following code from crt0.S.lb will setup a new stack*/ wbinvd For LX we didn't need to maintain the stack or any variables beyond CAR. [[[[ But on v3 we do .... ]]]] That meant that we didn't need to do any stack copy like the K8 post_cache_as_ram()(that never returns). The LX cache_as_ram_main returns and the LB copy function is back in cache_as_ram.inc. Since there is nothing on the stack and everything is running out of the ROM a new stack is easily created. [[[ Please note the comment: "that never returns"]]] [[[ and, note: if you look at that code, round about line 313, you'll notice that it does not return either]]] Sooo, if you want to maintain the stack in v3... I left a comment in the v2 code. Recall that they cache is disabled so the way doesn't get reallocated and thus the tags are never marked dirty and written back. Since the tags are never marked dirty the wbind won't wb but it will invd. [[[meaning: stack cache lines will be invalidated but NOT written back ...]]] There are a couple ways to address this. 1. copy the stack to a new location. 2. Set the tags dirty with by writing the way MSRs. [[[ This is how you set the tags ]]] 3. enable the cache and copy the stack back on it's self to dirty the tags. [[[This might work too to set the tags BUT -- the stack really has to be running at the right location. We would have to change this.]]] I am least sure about number three. I think that sums it up. I still think that it is best/fastest if the code returned to the CAR function and it setup a new stack in memory and then launched the next stage. [[[ Which is pretty much what I am proposing]]] ============================================================= I hope this additional discussion is helpful. Now, getting back to where we were: I am still arguing for what Marc argues in the last paragraph, stating "I still think that it is best/fastest if the code returned to the CAR function and it setup a new stack in memory and then launched the next stage.". Carl-Daniel, I believe you are hoping we can do the return from disable_car, but as Marc points out in options 1-3 above, it's really not simple. This is not a "bug" per se. Fixing it will be complex. It is possible that you will need different solutions for each CPU *implementation* in some cases, not just each CPU type -- for example, the Intel CAR had to be changed for AMD, and different types of Opteron may well need different CAR return code. Thanks ron From c-d.hailfinger.devel.2006 at gmx.net Fri Jan 4 04:14:52 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 04 Jan 2008 04:14:52 +0100 Subject: [LinuxBIOS] RESEND: v3 patch for console functions, and mods to lib/lar.c to support a void * parameter for running functions. In-Reply-To: <13426df10801031743k5cfe98dcqe947aa97b7165d96@mail.gmail.com> References: <13426df10801030950r65b36e0he3552fd94828ac5f@mail.gmail.com> <477D277A.3090302@gmx.net> <13426df10801031026t234d74abw9950ad761ea9717b@mail.gmail.com> <477D79B5.1040404@gmx.net> <13426df10801031743k5cfe98dcqe947aa97b7165d96@mail.gmail.com> Message-ID: <477DA4AC.1040001@gmx.net> On 04.01.2008 02:43, ron minnich wrote: > I am restarting the CAR discussion a bit. I want to get a resync. > Thanks. > One part of the discussion involves the idea that I am trying to avoid > return from disable_car because of some "bug" in our code. It is not > that simple. The issue is that, when the code enters disable_car,the > CPU has been using cache as ram, and using "memory" at non-memory > addresses. In disable_car, the CPU is supposed to disable cache as > ram, and continue -- should it return? The return is on the stack. The > function that called disable_car has its own stack variables. They're > actually in cache, not ram. So if the code is going to return, it will > need a working stack. It will need to restore the stack from cache to > ram. But where is the stack? at c000 in one case. Where is ram? > Somewhere else. That's something I don't understand. Are you saying that there might be no RAM at address 0xC000? (Or at 0xC0000, IIRC.) That's well below 1MB and on my local system 0xC0000-0xCFFFF is claimed by the Video ROM of the embedded ATI graphics. Then again, I seem to remember that this area can be RAM as well. > So it is possible that variables on stack are wrong, > if they are pointers to variables on the stack, and there is the > problem of changing esp, ss, and then fixing up the stack for the RET. > > Here's a useful comment: > x86/car/cache_as_ram_post.c: > /* > FIXME: I hope we don't need to change esp and ebp value here, > so we can restore value from mmx sse back > But the problem is the range is some io related, So > don't go back > */ > > If you look at the cache as ram for the amd and x86, you will find > something interesting: it does not go back. > x86: > leal _iseg, %edi > jmp *%edi > > > For AMD, at the end of the mainboard cache as ram main, it calls > post_cache_as_ram(void). At the end of that function is this: > /*copy and execute linuxbios_ram */ > copy_and_run(); > /* We will not return */ > > in other words, once CAR is disabled, we chain to copy_and_run, and > never return. We've also set up a new ESP. > > To put it simply, the most current CAR code *does not return* > --because getting that right, for all CPUs, is tricky and not always > possible. > OK. > So, expecting a return from disable car is not really in line with > what we do now. In fact, what we do now on most of v2 -- certainly on > opteron -- is merely what I'm proposing we do on V3. > > I'm pasting in some old mail now, with my comments in[[[]]] > Thanks for that. It seems I missed the essence of that mail back then. > ================================================================= > Marc Jones wrote: > >> Carl-Daniel Hailfinger wrote: >> >> >>> Dumb question: We know the location of the stack when we enter >>> disable_car(). We also know that all memory belongs to us. Can we copy >>> CAR stack contents to some safe location and restore them after wbinvd()? >>> >>> >> This shouldn't be needed. If the stack needed to be moved you would want >> to do it before the wbinvd so you were copying from cache to memory. >> Much faster than memory to memory. >> >> Marc >> >> > > and I am too smart for my own good..... > > > Here is the deal. Look in cpu/amd/model_lx/cache_as_ram.inc. > /* If you wanted to maintain the stack in memory you would need to set > the tags as dirty > [[[ Good point here! For the wbinvd to push the stack out, we need to > set cache tags! > This is going to be tough on some CPUs -- how do we do it on LX? > ]]] > I assumed from one of the mails in that old thread that setting the cache tags would be easy. > so the wbinvd would push out the old stack contents to memory */ > /* Clear the cache, the following code from crt0.S.lb will setup a new > stack*/ > wbinvd > > For LX we didn't need to maintain the stack or any variables beyond CAR. > [[[[ But on v3 we do .... ]]]] > That meant that we didn't need to do any stack copy like the K8 > post_cache_as_ram()(that never returns). The LX cache_as_ram_main > returns and the LB copy function is back in cache_as_ram.inc. Since > there is nothing on the stack and everything is running out of the ROM a > new stack is easily created. > > [[[ Please note the comment: "that never returns"]]] > OK. > [[[ and, note: if you look at that code, round about line 313, you'll > notice that it does not return either]]] > > Sooo, if you want to maintain the stack in v3... I left a comment in the > v2 code. Recall that they cache is disabled so the way doesn't get > reallocated and thus the tags are never marked dirty and written back. > Since the tags are never marked dirty the wbind won't wb but it will invd. > > [[[meaning: stack cache lines will be invalidated but NOT written back ...]]] > And that means the void * parameter to the running functions will be invalidated as well because it is passed on the stack. BOOM. You might be lucky enough that gcc generates code which loads the parameter into a register before the wbinvd and does not try to reload that parameter from your now-defunct old stack, but depending on luck is not an option here. If we kill our stack by making the wbinvd essentially an invd (because tags are not dirty), no function arguments nor any local variables will be available directly after the wbinvd. The only way out is to directly call a function (not by pointer) whose address is known during link time. Something like the call to copy_and_run() from v2 is needed here as well. > There are a couple ways to address this. > 1. copy the stack to a new location. > 2. Set the tags dirty with by writing the way MSRs. > [[[ This is how you set the tags ]]] > That's the way I'd prefer to handle things. > 3. enable the cache and copy the stack back on it's self to dirty the tags. > [[[This might work too to set the tags BUT -- the stack really has to > be running at the right location. We would have to change this.]]] > > I am least sure about number three. > > I think that sums it up. I still think that it is best/fastest if the > code returned to the CAR function and it setup a new stack in memory and > then launched the next stage. > > [[[ Which is pretty much what I am proposing]]] > ============================================================= > I hope this additional discussion is helpful. > Indeed, thanks! > Now, getting back to where we were: I am still arguing for what Marc > argues in the last paragraph, stating "I still think that it is > best/fastest if the > code returned to the CAR function and it setup a new stack in memory and > then launched the next stage.". > As long as I can salvage the old stack contents in some way, that would be acceptable for me as well. > Carl-Daniel, I believe you are hoping we can do the return from > disable_car, but as Marc points out in options 1-3 above, it's really > not simple. This is not a "bug" per se. Fixing it will be complex. It > is possible that you will need different solutions for each CPU > *implementation* in some cases, not just each CPU type -- for example, > the Intel CAR had to be changed for AMD, and different types of > Opteron may well need different CAR return code. > An explosion of code variants for CAR disabling would seriously compromise maintainability of our code. Regards, Carl-Daniel From rminnich at gmail.com Fri Jan 4 05:04:56 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 3 Jan 2008 20:04:56 -0800 Subject: [LinuxBIOS] RESEND: v3 patch for console functions, and mods to lib/lar.c to support a void * parameter for running functions. In-Reply-To: <477DA4AC.1040001@gmx.net> References: <13426df10801030950r65b36e0he3552fd94828ac5f@mail.gmail.com> <477D277A.3090302@gmx.net> <13426df10801031026t234d74abw9950ad761ea9717b@mail.gmail.com> <477D79B5.1040404@gmx.net> <13426df10801031743k5cfe98dcqe947aa97b7165d96@mail.gmail.com> <477DA4AC.1040001@gmx.net> Message-ID: <13426df10801032004h234ff10dgc21c7a6259b4a240@mail.gmail.com> Carl-Daniel, I admire your determination and hence I am willing to try making return work. I would recommend we try to figure out how to get the stack to live where real memory lives, then copy the stack to itself, then wbinvd. regards. ron From rminnich at gmail.com Fri Jan 4 05:28:01 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 3 Jan 2008 20:28:01 -0800 Subject: [LinuxBIOS] patch: enable ga_2761gxdk flash enable Message-ID: <13426df10801032028w5d6d213ana4fa09f42e3c09cf@mail.gmail.com> This is to enable flashrom on the ga_2761gxdk. I have tested it and it works. ron From joe at smittys.pointclark.net Fri Jan 4 05:38:28 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Thu, 03 Jan 2008 23:38:28 -0500 Subject: [LinuxBIOS] april meeting in denver In-Reply-To: <477D8CBD.5050603@gmx.net> References: <13426df10801031100t34f51dd4jb8064c2a029fe159@mail.gmail.com> <477D8CBD.5050603@gmx.net> Message-ID: <20080103233828.q8jy2mf6swg0kcs8@www.smittys.pointclark.net> Quoting Carl-Daniel Hailfinger : > On 03.01.2008 20:00, ron minnich wrote: >> I've got some questions from people pending re: the meeting in Denver. >> Most of the US of A seems to still be on vacation, I am not getting >> answers from the organizers about the denver meeting. I hope to have >> more info next week. >> > > April will be a time when I'm totally busy with finalizing my thesis, so > I'd appreciate if someone could set up a live feed from the meeting. > A live feed would be very cool for the East-Coasters too:-) Thanks - Joe From rminnich at gmail.com Fri Jan 4 05:40:01 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 3 Jan 2008 20:40:01 -0800 Subject: [LinuxBIOS] april meeting in denver In-Reply-To: <477D8CBD.5050603@gmx.net> References: <13426df10801031100t34f51dd4jb8064c2a029fe159@mail.gmail.com> <477D8CBD.5050603@gmx.net> Message-ID: <13426df10801032040p42c619f7ib47d16020160fe3a@mail.gmail.com> On Jan 3, 2008 5:32 PM, Carl-Daniel Hailfinger wrote: > April will be a time when I'm totally busy with finalizing my thesis, so > I'd appreciate if someone could set up a live feed from the meeting. > hmm. can't we just sabotage your thesis somehow and then you can come to denver :-) We'll miss you ... > Is there any other event (preferably in Europe) where most of us will meet? > we are planning a european event, hopefully in june or so. My son graduates from MIT june 6, so I can not miss that. Other than that, I should be open. Yes, I'm that old. ron From corey.osgood at gmail.com Fri Jan 4 06:31:17 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Fri, 04 Jan 2008 00:31:17 -0500 Subject: [LinuxBIOS] RESEND: patch: fix the problem with CONFIG_CONSOLE_VGA not pulling in the emulator In-Reply-To: <200801040049.26921.duwe@lst.de> References: <13426df10801030937k5ffecaabndc421bbd5e0a1ce0@mail.gmail.com> <200801040015.04502.duwe@lst.de> <13426df10801031523h3adbc50ajab4435f58d31d3de@mail.gmail.com> <200801040049.26921.duwe@lst.de> Message-ID: <477DC4A5.4040106@gmail.com> Torsten Duwe wrote: > On Friday 04 January 2008, ron minnich wrote: > > >> There's a harder problem. What if we're on a a system with a unichrome >> and, for whatever reason, somebody drops in a different graphics card >> and wants that to be the console? Of the set of devices that *could* >> be the console, which one *should* be the console? >> >> For this latter case, in which there is a native non-option-ROM VGA >> device and a VGA device with an option ROM, you are going to need to >> leave the emulator in [...] >> > > True. Even those Epia-boards have a slot. Luc, or anyone else, have a board > with VGA and totally without PCI, AGP or the like? Or is this a ROM space > issue? This is, I believe, a moot point. Saying that all boards have a PCI slot doesn't mean that a user/developer wants to or has any intention of using it. Think of situations where an embedded board is dropped into a specialized case and sold as a project, for instance, the msntv2. The board inside (rca rm4100) does have a PCI "slot", but no header, and the case is designed such that pci cards are not meant to be used. In such a case, there's no reason to include the rom emulator, increasing the size (if ever so slightly), nor a reason to search for a video option rom, increasing the boot time, if there is no rom to run. BTW, thanks for getting back to this Luc, I know you're busy with the new job. I apologize for the rather scalding response your patch has had, these are the types of responses to patches this community does not need, because we will scare away very experienced and good developers. I think that we need a 3rd option, something like CONFIG_NATIVE_VGA_INIT, to do what you want and skip the video option rom search. I think that would make everyone happy ;) -Corey From rminnich at gmail.com Fri Jan 4 06:34:49 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 3 Jan 2008 21:34:49 -0800 Subject: [LinuxBIOS] another try at the lib/console patch in v3 Message-ID: <13426df10801032134r55abda82v62ef98fb59c6545c@mail.gmail.com> I have changed banner so it makes a uniform width message. It is now more complex. ron -------------- next part -------------- A non-text attachment was scrubbed... Name: console.diff Type: text/x-patch Size: 2040 bytes Desc: not available URL: From rminnich at gmail.com Fri Jan 4 06:44:34 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 3 Jan 2008 21:44:34 -0800 Subject: [LinuxBIOS] RESEND: patch: fix the problem with CONFIG_CONSOLE_VGA not pulling in the emulator In-Reply-To: <477DC4A5.4040106@gmail.com> References: <13426df10801030937k5ffecaabndc421bbd5e0a1ce0@mail.gmail.com> <200801040015.04502.duwe@lst.de> <13426df10801031523h3adbc50ajab4435f58d31d3de@mail.gmail.com> <200801040049.26921.duwe@lst.de> <477DC4A5.4040106@gmail.com> Message-ID: <13426df10801032144t686dbf6bp7ba74925599fe73b@mail.gmail.com> On Jan 3, 2008 9:31 PM, Corey Osgood wrote: > This is, I believe, a moot point. Saying that all boards have a PCI slot > doesn't mean that a user/developer wants to or has any intention of > using it. Think of situations where an embedded board is dropped into a > specialized case and sold as a project, for instance, the msntv2. The > board inside (rca rm4100) does have a PCI "slot", but no header, and the > case is designed such that pci cards are not meant to be used. In such a > case, there's no reason to include the rom emulator, increasing the size > (if ever so slightly), nor a reason to search for a video option rom, > increasing the boot time, if there is no rom to run. Very true. But it's also not saying they do NOT want to be able to do it. That's what makes this so messy. But that's what the targets config file is for -- so you can reset an option that doesn't fit a particular case. It's why those files were set up that way in the first place. >I apologize for the rather scalding response your patch has > had, these are the types of responses to patches this community does not > need, because we will scare away very experienced and good developers. I'm sorry if it sounded that way, but the problem was and remains that Luc's patch removes a capability that people asked us for. It really is not unusual (it just happened to me recently) for someone to come to me with a 5 year old motherboard and need a new build. When we remove options we need to be aware of the ramifications. > I think that we need a 3rd option, something like > CONFIG_NATIVE_VGA_INIT, to do what you want and skip the video option > rom search. I think that would make everyone happy ;) Well, we have several cases in fact. - native vga init, - option roms for vga - option roms for everything not vga So we need something that supports these combinations, as users come up with new ways of combining them. thanks ron From rminnich at gmail.com Fri Jan 4 07:04:37 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 3 Jan 2008 22:04:37 -0800 Subject: [LinuxBIOS] patch: move defines from a .S to a .h Message-ID: <13426df10801032204o2ca21719h8eb64e27dd4fbb0b@mail.gmail.com> This is so we can attempt to return from disable_car: we need these definitions in C. Besides, they make more sense in a .h I think. ron -------------- next part -------------- A non-text attachment was scrubbed... Name: fixlxinclude.diff Type: text/x-patch Size: 2216 bytes Desc: not available URL: From paulepanter at users.sourceforge.net Fri Jan 4 09:46:09 2008 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Fri, 04 Jan 2008 09:46:09 +0100 Subject: [LinuxBIOS] patch: enable ga_2761gxdk flash enable In-Reply-To: <13426df10801032028w5d6d213ana4fa09f42e3c09cf@mail.gmail.com> References: <13426df10801032028w5d6d213ana4fa09f42e3c09cf@mail.gmail.com> Message-ID: <1199436369.3654.5.camel@mattotaupa.home.familie-menzel.de> Good morning, Am Donnerstag, den 03.01.2008, 20:28 -0800 schrieb ron minnich: > This is to enable flashrom on the ga_2761gxdk. I guess, you missed the attachment. Paul From c-d.hailfinger.devel.2006 at gmx.net Fri Jan 4 13:45:24 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 04 Jan 2008 13:45:24 +0100 Subject: [LinuxBIOS] [PATCH] flashrom: SST25VF040B support Message-ID: <477E2A64.90904@gmx.net> Add support for the SST25VF040B 4 Mbit SPI flash chip. Straight from the data sheet, not tested. Signed-off-by: Carl-Daniel Hailfinger Index: flashrom-ron/flashchips.c =================================================================== --- flashrom-ron/flashchips.c (Revision 3031) +++ flashrom-ron/flashchips.c (Arbeitskopie) @@ -52,6 +52,8 @@ probe_29f002, erase_29f002, write_29f002}, {"MX25L4005", MX_ID, MX_25L4005, 512, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, + {"SST25VF040B", SST_ID, SST_25VF040B, 512, 256, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, {"SST25VF016B", SST_ID, SST_25VF016B, 2048, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, {"SST29EE020A", SST_ID, SST_29EE020A, 256, 128, From svn at openbios.org Fri Jan 4 13:53:10 2008 From: svn at openbios.org (svn at openbios.org) Date: Fri, 4 Jan 2008 13:53:10 +0100 Subject: [LinuxBIOS] r543 - in LinuxBIOSv3: arch/x86/geodelx include/arch/x86 Message-ID: Author: hailfinger Date: 2008-01-04 13:53:09 +0100 (Fri, 04 Jan 2008) New Revision: 543 Modified: LinuxBIOSv3/arch/x86/geodelx/stage0.S LinuxBIOSv3/include/arch/x86/amd_geodelx.h Log: Move AMD Geode LX defines for CAR from a .S to a .h so they are available to C. Signed-off-by: Ronald G. Minnich Acked-by: Carl-Daniel Hailfinger Modified: LinuxBIOSv3/arch/x86/geodelx/stage0.S =================================================================== --- LinuxBIOSv3/arch/x86/geodelx/stage0.S 2007-12-11 01:24:52 UTC (rev 542) +++ LinuxBIOSv3/arch/x86/geodelx/stage0.S 2008-01-04 12:53:09 UTC (rev 543) @@ -28,24 +28,6 @@ #include "../macros.h" #include -/* This is where the DCache will be mapped and be used as stack. It would be - * cool if it was the same base as LinuxBIOS normal stack. - */ -#define LX_STACK_BASE DCACHE_RAM_BASE -#define LX_STACK_END LX_STACK_BASE + (DCACHE_RAM_SIZE - 4) - -#define LX_NUM_CACHELINES 0x080 /* There are 128 lines per way. */ -#define LX_CACHELINE_SIZE 0x020 /* There are 32 bytes per line. */ -#define LX_CACHEWAY_SIZE (LX_NUM_CACHELINES * LX_CACHELINE_SIZE) -#define CR0_CD 0x40000000 /* Bit 30 = Cache Disable */ -#define CR0_NW 0x20000000 /* Bit 29 = Not Write Through */ - -#define ROM_CODE_SEG 0x08 -#define ROM_DATA_SEG 0x10 - -#define CACHE_RAM_CODE_SEG 0x18 -#define CACHE_RAM_DATA_SEG 0x20 - .code16 .globl _stage0 _stage0: Modified: LinuxBIOSv3/include/arch/x86/amd_geodelx.h =================================================================== --- LinuxBIOSv3/include/arch/x86/amd_geodelx.h 2007-12-11 01:24:52 UTC (rev 542) +++ LinuxBIOSv3/include/arch/x86/amd_geodelx.h 2008-01-04 12:53:09 UTC (rev 543) @@ -567,7 +567,24 @@ /* ------------------------ */ #define DCACHE_RAM_SIZE 0x08000 #define DCACHE_RAM_BASE 0xc8000 +/* This is where the DCache will be mapped and be used as stack. It would be + * cool if it was the same base as LinuxBIOS normal stack. + */ +#define LX_STACK_BASE DCACHE_RAM_BASE +#define LX_STACK_END LX_STACK_BASE + (DCACHE_RAM_SIZE - 4) +#define LX_NUM_CACHELINES 0x080 /* There are 128 lines per way. */ +#define LX_CACHELINE_SIZE 0x020 /* There are 32 bytes per line. */ +#define LX_CACHEWAY_SIZE (LX_NUM_CACHELINES * LX_CACHELINE_SIZE) +#define CR0_CD 0x40000000 /* Bit 30 = Cache Disable */ +#define CR0_NW 0x20000000 /* Bit 29 = Not Write Through */ + +#define ROM_CODE_SEG 0x08 +#define ROM_DATA_SEG 0x10 + +#define CACHE_RAM_CODE_SEG 0x18 +#define CACHE_RAM_DATA_SEG 0x20 + /* POST CODES */ /* standard AMD post definitions -- might as well use them. */ From c-d.hailfinger.devel.2006 at gmx.net Fri Jan 4 13:54:22 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 04 Jan 2008 13:54:22 +0100 Subject: [LinuxBIOS] patch: move defines from a .S to a .h In-Reply-To: <13426df10801032204o2ca21719h8eb64e27dd4fbb0b@mail.gmail.com> References: <13426df10801032204o2ca21719h8eb64e27dd4fbb0b@mail.gmail.com> Message-ID: <477E2C7E.5070609@gmx.net> On 04.01.2008 07:04, ron minnich wrote: > This is so we can attempt to return from disable_car: we need these > definitions in C. Besides, they make more sense in a .h I think. > > Move defines from a .S to a .h so they are available to C. > > Signed-off-by: Ronald G. Minnich > Acked-by: Carl-Daniel Hailfinger and committed in r543 with a slightly more verbose changelog. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Fri Jan 4 14:24:25 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 04 Jan 2008 14:24:25 +0100 Subject: [LinuxBIOS] [PATCH] flashrom: add generic vendor ID printing for SPI chips Message-ID: <477E3389.1040502@gmx.net> Print at least the vendor for SPI flash chips if the exact chip ID is unknown. Signed-off-by: Carl-Daniel Hailfinger Index: flashrom-generic/flash.h =================================================================== --- flashrom-generic/flash.h (Revision 3031) +++ flashrom-generic/flash.h (Arbeitskopie) @@ -59,10 +59,13 @@ * entry of each section should be the manufacturer ID, followed by the * list of devices from that manufacturer (sorted by device IDs). * - * All LPC/FWH parts (parallel flash) have 8-bit device IDs. + * All LPC/FWH parts (parallel flash) have 8-bit device IDs if there is no + * continuation code. * All SPI parts have 16-bit device IDs. */ +#define GENERIC_DEVICE_ID 0xffff /* Only match the vendor ID */ + #define ALLIANCE_ID 0x52 /* Alliance Semiconductor */ #define AMD_ID 0x01 /* AMD */ Index: flashrom-generic/flashchips.c =================================================================== --- flashrom-generic/flashchips.c (Revision 3031) +++ flashrom-generic/flashchips.c (Arbeitskopie) @@ -185,5 +185,13 @@ probe_jedec, erase_chip_jedec, write_49f002}, {"S29C31004T", SYNCMOS_ID, S29C31004T, 512, 128, probe_jedec, erase_chip_jedec, write_49f002}, + {"EON unknown SPI chip", EON_ID_NOPREFIX, GENERIC_DEVICE_ID, 0, 0, + probe_spi, NULL, NULL}, + {"MX unknown SPI chip", MX_ID, GENERIC_DEVICE_ID, 0, 0, + probe_spi, NULL, NULL}, + {"SST unknown SPI chip", SST_ID, GENERIC_DEVICE_ID, 0, 0, + probe_spi, NULL, NULL}, + {"ST unknown SPI chip", ST_ID, GENERIC_DEVICE_ID, 0, 0, + probe_spi, NULL, NULL}, {NULL,} }; Index: flashrom-generic/spi.c =================================================================== --- flashrom-generic/spi.c (Revision 3031) +++ flashrom-generic/spi.c (Arbeitskopie) @@ -263,13 +263,16 @@ model_id = (readarr[1] << 8) | readarr[2]; printf_debug("%s: id1 0x%x, id2 0x%x\n", __FUNCTION__, manuf_id, model_id); if (manuf_id == flash->manufacture_id && model_id == flash->model_id) { - /* Print the status register before erase to tell the + /* Print the status register to tell the * user about possible write protection. */ generic_spi_prettyprint_status_register(flash); return 1; } + /* Test if this is a pure vendor match. */ + if (manuf_id == flash->manufacture_id && GENERIC_DEVICE_ID == flash->model_id) + return 1; } return 0; From libv at skynet.be Fri Jan 4 15:32:54 2008 From: libv at skynet.be (Luc Verhaegen) Date: Fri, 4 Jan 2008 15:32:54 +0100 Subject: [LinuxBIOS] [Patch] Fix CONFIG_CONSOLE_VGA handling in default pci_dev_init. In-Reply-To: <13426df10801031037s51923b12h5a020ccddb9bb5bf@mail.gmail.com> References: <20080102091638.GA11860@skynet.be> <13426df10801021731l31ebe422y2ef6567de06fd2be@mail.gmail.com> <20080103082125.GB14556@skynet.be> <200801031205.02320.duwe@lst.de> <13426df10801031037s51923b12h5a020ccddb9bb5bf@mail.gmail.com> Message-ID: <20080104143254.GA17998@skynet.be> On Thu, Jan 03, 2008 at 10:37:45AM -0800, ron minnich wrote: > On Jan 3, 2008 3:05 AM, Torsten Duwe wrote: > > > If you had mentioned that CONSOLE_VGA=1 PCI_ROM_RUN=0 does not compile and you > > are working on a free standing driver, that would have saved us from the > > irrelevant part of this discussion. > > Exactly. Simple, clear bug reports are always useful. Took me a few > minutes to fix. How long do you think it took me to fix in the first place? The difference is that one fix uses CONSOLE_VGA as the name obviously suggests, and the other continues non-obvious side effects, which might be desired for 95% of the cases, but which completely rules out building without those non-obvious side-effects. > > > > So if nobody objects I'll commit the original patch, after the west coast has > > had a chance to comment ;-) > > Luc's patch is unnecessary as submitted; it will eliminate an option > that, in the past, was deemed desirable by some users (they may no > longer care, it may no longer matter). Those users can either use both PCI_ROM_RUN _and_ CONSOLE_VGA, or a now often suggested third option (VGA_ROM_RUN or similar, maybe VGA_PCI_ROM_RUN, or the inverse logic?) can be introduced for the other case. I am specifically not removing an option, i am simply sanitising the usage of an option, to match its linguistical and logical meaning, as there are cases where the non-obvious side-effects are not needed. > You can just use the patch I > sent, which fixes the problem and preserves behavior which, at one > point, somebody wanted. It exacerbates the problem. > When the code got broken I am not sure. I do not care when it got broken or who did so. I do know that the code got broken because the side-effect was non-obvious. And i do want to see it become obvious. > That > said, if the feeling is that we should go with Luc's patch, I have no > objection. > > I should comment on the "who wants an emulator in a free BIOS" > argument; that discussion was resolved years ago, in favor or "lots of > people need it, whether they want it or not" -- I don't like it > either, but that's the way it goes. I was one of the strongest > opponents of using the option ROMs. I no longer see any way out of > using the option ROMs in some cases. It's the same reason we have > binary blobs in the linux kernel (e.g. microcode patches); sometimes > there is no choice. I never said i do not want emulators in free BIOSes. I said that, when a board doesn't require the emulator, and when the linuxbios user doesn't add the requirement later on through the target config.lb, then there is no real need to force inclusion of the emulator. > So, even if we have a totally free driver for graphics, we will > probably see continuing demand for the emulator, to support cards with > option ROMs. Of course. But does this mean that we should always impose the emulator on everybody all the time? Or do we leave this up to: * whichever chip driver that might require it. * whichever board that might require it. * whichever user that might see a point in it when building his target image. For the EPIA-M, the hardware present doesn't require pci roms. And the typical use case, with a single pci slot, does not involve pci roms. So why impose the emulator? Tonight or tomorrow, whenever i will have the time, i will go over _all_ instances of CONSOLE_VGA and prepend this with either PCI_ROM_RUN (when this isn't already done), or something VGA specific, whatever the consensus will be. So, to those interested, please come to some consensus on this. For the EPIA-M, I will add a commented out PCI_ROM_RUN option to the Config.lb with a comment beforehand explaining that, when desired, this should be enabled. It should not be enabled per default, as those building an image should at least read and alter the target Config.lb file. I do hope that this will finally satisfy you so that i can finally move on and fix the remaining issues with my native vga textmode bringup. Luc Verhaegen. SUSE/Novell X Driver Developer. From rminnich at gmail.com Fri Jan 4 17:05:17 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 4 Jan 2008 08:05:17 -0800 Subject: [LinuxBIOS] patch: enable ga_2761gxdk flash enable In-Reply-To: <1199436369.3654.5.camel@mattotaupa.home.familie-menzel.de> References: <13426df10801032028w5d6d213ana4fa09f42e3c09cf@mail.gmail.com> <1199436369.3654.5.camel@mattotaupa.home.familie-menzel.de> Message-ID: <13426df10801040805t7b470a3agad54f50c05115e70@mail.gmail.com> man, this is weird. I sent two emails with attachments last night, and I can guarantee they were attached, and both got sent sans attachment. Gee, am I seeing the first gmail bugs? ron From rminnich at gmail.com Fri Jan 4 17:07:31 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 4 Jan 2008 08:07:31 -0800 Subject: [LinuxBIOS] [PATCH] flashrom: add generic vendor ID printing for SPI chips In-Reply-To: <477E3389.1040502@gmx.net> References: <477E3389.1040502@gmx.net> Message-ID: <13426df10801040807y6c3e284dm82d918261a1921b@mail.gmail.com> Acked-by: Ronald G. Minnich From rminnich at gmail.com Fri Jan 4 17:14:17 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 4 Jan 2008 08:14:17 -0800 Subject: [LinuxBIOS] patch: enable ga_2761gxdk flash enable In-Reply-To: <1199436369.3654.5.camel@mattotaupa.home.familie-menzel.de> References: <13426df10801032028w5d6d213ana4fa09f42e3c09cf@mail.gmail.com> <1199436369.3654.5.camel@mattotaupa.home.familie-menzel.de> Message-ID: <13426df10801040814n6e7afca8sfe7fa6114dab7deb@mail.gmail.com> Let's try this patch again. ron -------------- next part -------------- A non-text attachment was scrubbed... Name: ga2761en.diff Type: text/x-patch Size: 847 bytes Desc: not available URL: From svn at openbios.org Fri Jan 4 17:22:09 2008 From: svn at openbios.org (svn at openbios.org) Date: Fri, 4 Jan 2008 17:22:09 +0100 Subject: [LinuxBIOS] r3032 - trunk/util/flashrom Message-ID: Author: hailfinger Date: 2008-01-04 17:22:09 +0100 (Fri, 04 Jan 2008) New Revision: 3032 Modified: trunk/util/flashrom/flash.h trunk/util/flashrom/flashchips.c trunk/util/flashrom/spi.c Log: Print at least the vendor for SPI flash chips if the exact chip ID is unknown. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Ronald G. Minnich Modified: trunk/util/flashrom/flash.h =================================================================== --- trunk/util/flashrom/flash.h 2007-12-31 14:05:08 UTC (rev 3031) +++ trunk/util/flashrom/flash.h 2008-01-04 16:22:09 UTC (rev 3032) @@ -59,10 +59,13 @@ * entry of each section should be the manufacturer ID, followed by the * list of devices from that manufacturer (sorted by device IDs). * - * All LPC/FWH parts (parallel flash) have 8-bit device IDs. + * All LPC/FWH parts (parallel flash) have 8-bit device IDs if there is no + * continuation code. * All SPI parts have 16-bit device IDs. */ +#define GENERIC_DEVICE_ID 0xffff /* Only match the vendor ID */ + #define ALLIANCE_ID 0x52 /* Alliance Semiconductor */ #define AMD_ID 0x01 /* AMD */ Modified: trunk/util/flashrom/flashchips.c =================================================================== --- trunk/util/flashrom/flashchips.c 2007-12-31 14:05:08 UTC (rev 3031) +++ trunk/util/flashrom/flashchips.c 2008-01-04 16:22:09 UTC (rev 3032) @@ -185,5 +185,13 @@ probe_jedec, erase_chip_jedec, write_49f002}, {"S29C31004T", SYNCMOS_ID, S29C31004T, 512, 128, probe_jedec, erase_chip_jedec, write_49f002}, + {"EON unknown SPI chip", EON_ID_NOPREFIX, GENERIC_DEVICE_ID, 0, 0, + probe_spi, NULL, NULL}, + {"MX unknown SPI chip", MX_ID, GENERIC_DEVICE_ID, 0, 0, + probe_spi, NULL, NULL}, + {"SST unknown SPI chip", SST_ID, GENERIC_DEVICE_ID, 0, 0, + probe_spi, NULL, NULL}, + {"ST unknown SPI chip", ST_ID, GENERIC_DEVICE_ID, 0, 0, + probe_spi, NULL, NULL}, {NULL,} }; Modified: trunk/util/flashrom/spi.c =================================================================== --- trunk/util/flashrom/spi.c 2007-12-31 14:05:08 UTC (rev 3031) +++ trunk/util/flashrom/spi.c 2008-01-04 16:22:09 UTC (rev 3032) @@ -262,14 +262,19 @@ manuf_id = readarr[0]; model_id = (readarr[1] << 8) | readarr[2]; printf_debug("%s: id1 0x%x, id2 0x%x\n", __FUNCTION__, manuf_id, model_id); - if (manuf_id == flash->manufacture_id && model_id == flash->model_id) { - /* Print the status register before erase to tell the + if (manuf_id == flash->manufacture_id && + model_id == flash->model_id) { + /* Print the status register to tell the * user about possible write protection. */ generic_spi_prettyprint_status_register(flash); return 1; } + /* Test if this is a pure vendor match. */ + if (manuf_id == flash->manufacture_id && + GENERIC_DEVICE_ID == flash->model_id) + return 1; } return 0; From c-d.hailfinger.devel.2006 at gmx.net Fri Jan 4 17:23:45 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 04 Jan 2008 17:23:45 +0100 Subject: [LinuxBIOS] [PATCH] flashrom: add generic vendor ID printing for SPI chips In-Reply-To: <13426df10801040807y6c3e284dm82d918261a1921b@mail.gmail.com> References: <477E3389.1040502@gmx.net> <13426df10801040807y6c3e284dm82d918261a1921b@mail.gmail.com> Message-ID: <477E5D91.6070902@gmx.net> On 04.01.2008 17:07, ron minnich wrote: > Acked-by: Ronald G. Minnich > Thanks, r3032. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Fri Jan 4 17:25:46 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 04 Jan 2008 17:25:46 +0100 Subject: [LinuxBIOS] patch: enable ga_2761gxdk flash enable In-Reply-To: <13426df10801040814n6e7afca8sfe7fa6114dab7deb@mail.gmail.com> References: <13426df10801032028w5d6d213ana4fa09f42e3c09cf@mail.gmail.com> <1199436369.3654.5.camel@mattotaupa.home.familie-menzel.de> <13426df10801040814n6e7afca8sfe7fa6114dab7deb@mail.gmail.com> Message-ID: <477E5E0A.3060100@gmx.net> On 04.01.2008 17:14, ron minnich wrote: > Add board enable for the gigabyte ga_2761gxdk board > > Signed-off-by: Ronald G. Minnich > > Index: board_enable.c > =================================================================== > --- board_enable.c (revision 3031) > +++ board_enable.c (working copy) > @@ -381,6 +381,8 @@ > "gigabyte", "m57sli", "GIGABYTE GA-M57SLI-S4", it87xx_probe_spi_flash}, > {0x10de, 0x03e0, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, > "gigabyte", "m61p", "GIGABYTE GA-M61P-S3", it87xx_probe_spi_flash}, > + {0x1039, 0x0761, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, > + "gigabyte", "ga_2761gxdk", "GIGABYTE GA-2761GXDK", it87xx_probe_spi_flash}, > Use "2761gxdk" instead of "ga_2761gxdk"? This would be more in line with the other boards... Your decision. > {0x1022, 0x7468, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, > "iwill", "dk8_htx", "IWILL DK8-HTX", w83627hf_gpio24_raise_2e}, > {0x10de, 0x005e, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, > Acked-by: Carl-Daniel Hailfinger Regards, Carl-Daniel From info at coresystems.de Fri Jan 4 18:10:42 2008 From: info at coresystems.de (LinuxBIOS information) Date: Fri, 04 Jan 2008 18:10:42 +0100 Subject: [LinuxBIOS] r3032 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "hailfinger" checked in revision 3032 to the LinuxBIOS source repository and caused the following changes: Change Log: Print at least the vendor for SPI flash chips if the exact chip ID is unknown. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Ronald G. Minnich Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3032&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in hailfinger's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From svn at openbios.org Fri Jan 4 18:22:44 2008 From: svn at openbios.org (svn at openbios.org) Date: Fri, 4 Jan 2008 18:22:44 +0100 Subject: [LinuxBIOS] r3033 - trunk/util/flashrom Message-ID: Author: rminnich Date: 2008-01-04 18:22:44 +0100 (Fri, 04 Jan 2008) New Revision: 3033 Modified: trunk/util/flashrom/board_enable.c Log: Add board enable for the gigabyte ga_2761gxdk board Signed-off-by: Ronald G. Minnich Acked-by: Carl-Daniel Hailfinger Modified: trunk/util/flashrom/board_enable.c =================================================================== --- trunk/util/flashrom/board_enable.c 2008-01-04 16:22:09 UTC (rev 3032) +++ trunk/util/flashrom/board_enable.c 2008-01-04 17:22:44 UTC (rev 3033) @@ -381,6 +381,8 @@ "gigabyte", "m57sli", "GIGABYTE GA-M57SLI-S4", it87xx_probe_spi_flash}, {0x10de, 0x03e0, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, "gigabyte", "m61p", "GIGABYTE GA-M61P-S3", it87xx_probe_spi_flash}, + {0x1039, 0x0761, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + "gigabyte", "2761gxdk", "GIGABYTE GA-2761GXDK", it87xx_probe_spi_flash}, {0x1022, 0x7468, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, "iwill", "dk8_htx", "IWILL DK8-HTX", w83627hf_gpio24_raise_2e}, {0x10de, 0x005e, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, From rminnich at gmail.com Fri Jan 4 18:23:44 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 4 Jan 2008 09:23:44 -0800 Subject: [LinuxBIOS] patch: enable ga_2761gxdk flash enable In-Reply-To: <477E5E0A.3060100@gmx.net> References: <13426df10801032028w5d6d213ana4fa09f42e3c09cf@mail.gmail.com> <1199436369.3654.5.camel@mattotaupa.home.familie-menzel.de> <13426df10801040814n6e7afca8sfe7fa6114dab7deb@mail.gmail.com> <477E5E0A.3060100@gmx.net> Message-ID: <13426df10801040923q1b09cfedpeaae92813bbb35c2@mail.gmail.com> On Jan 4, 2008 8:25 AM, Carl-Daniel Hailfinger wrote > Use "2761gxdk" instead of "ga_2761gxdk"? This would be more in line with > the other boards... Your decision. Right, I went with your change, > Acked-by: Carl-Daniel Hailfinger > Committed revision 3033. thanks again. ron From rminnich at gmail.com Fri Jan 4 18:25:14 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 4 Jan 2008 09:25:14 -0800 Subject: [LinuxBIOS] fiddly MSRs on lx Message-ID: <13426df10801040925p193317afm5e4f26618dd1074f@mail.gmail.com> attached are two files: a list of all the LX settings and MSRs and their values, and the program I used to generate them (which is just the .h files all mashed into C code). This is a lifesaver when you're trying to figure out "which the @@@@ MSR IS THAT ANYWAY?" thanks ron -------------- next part -------------- A non-text attachment was scrubbed... Name: lxreglist Type: application/octet-stream Size: 26973 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: x.c Type: text/x-csrc Size: 126368 bytes Desc: not available URL: From Marc.Karasek at Sun.COM Fri Jan 4 18:25:35 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Fri, 04 Jan 2008 12:25:35 -0500 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: <477D507E.4030106@sun.com> References: <477CF25C.7070901@sun.com> <13426df10801030819p5fa4f8enc9bc2aa6557ad460@mail.gmail.com> <477D2366.7090500@sun.com> <13426df10801031028y3dce3f53g15e336f1df8907b1@mail.gmail.com> <477D2A90.3070001@sun.com> <13426df10801031043o3ea5df06r62f51e7c63fabaaa@mail.gmail.com> <477D507E.4030106@sun.com> Message-ID: <477E6C0F.60403@sun.com> Think this got lost in the noise.. /********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 *********************/ Marc Karasek wrote: > Here is the patch with the ld option check as well. > > I had to make a few changes to Ron's original patch. One of the > problems was that CFLAGS was being set as a := in the Makefile and was > overwriting the += that was in Makefile.settings. So I added > DISTRO_CFLAGS and DISTRO_LFLAGS for the two additonal flags. The > reason for two was that the build-id option is only used during > linking and generated warnings if used on a compile line and was not > being pulled in for the linker lines. These defines were added to the > appropriate places in the Makefile via the Config.lb file. > > > > /********************* > Marc Karasek > MTS > Sun Microsystems > mailto:marc.karasek at sun.com > ph:770.360.6415 > *********************/ > > > > ron minnich wrote: >> On Jan 3, 2008 10:33 AM, Marc Karasek wrote: >> >> >>> I could add the check to this patch (using awk to check ld) to add the >>> -Wl option to the EXTRA_CFLAGS. >>> >> >> cool! I'll take it and add it. >> >> ron >> From rminnich at gmail.com Fri Jan 4 18:40:21 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 4 Jan 2008 09:40:21 -0800 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: <477D507E.4030106@sun.com> References: <477CF25C.7070901@sun.com> <13426df10801030819p5fa4f8enc9bc2aa6557ad460@mail.gmail.com> <477D2366.7090500@sun.com> <13426df10801031028y3dce3f53g15e336f1df8907b1@mail.gmail.com> <477D2A90.3070001@sun.com> <13426df10801031043o3ea5df06r62f51e7c63fabaaa@mail.gmail.com> <477D507E.4030106@sun.com> Message-ID: <13426df10801040940i31fd46dcob066a76d48a3cee8@mail.gmail.com> I like it. You've tested it I assume. I like separating out the DISTRO flags the way you have done. It makes it very clear what flag is related to what function. I realized this fix took a while, but I think the slow nature of the process got us to the ideal result. We're really using the buildtarget script in the way we originally intended it to used. I really appreciate your patience while we figured this problem out. Thanks Acked-by: Ronald G. Minnch ron p.s. do you need me to do the commit or can you? From info at coresystems.de Fri Jan 4 19:09:55 2008 From: info at coresystems.de (LinuxBIOS information) Date: Fri, 04 Jan 2008 19:09:55 +0100 Subject: [LinuxBIOS] r3033 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "rminnich" checked in revision 3033 to the LinuxBIOS source repository and caused the following changes: Change Log: Add board enable for the gigabyte ga_2761gxdk board Signed-off-by: Ronald G. Minnich Acked-by: Carl-Daniel Hailfinger Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3033&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in rminnich's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From Marc.Karasek at Sun.COM Fri Jan 4 19:17:58 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Fri, 04 Jan 2008 13:17:58 -0500 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: <13426df10801040940i31fd46dcob066a76d48a3cee8@mail.gmail.com> References: <477CF25C.7070901@sun.com> <13426df10801030819p5fa4f8enc9bc2aa6557ad460@mail.gmail.com> <477D2366.7090500@sun.com> <13426df10801031028y3dce3f53g15e336f1df8907b1@mail.gmail.com> <477D2A90.3070001@sun.com> <13426df10801031043o3ea5df06r62f51e7c63fabaaa@mail.gmail.com> <477D507E.4030106@sun.com> <13426df10801040940i31fd46dcob066a76d48a3cee8@mail.gmail.com> Message-ID: <477E7856.3040708@sun.com> I have tested it on my fedora 8 machine. It would be nice to have it testd on a different disto that has a older ld version. Just as a sanity check. I think I can do the commit from here. I have not used svn before but it seems to be pretty easy. Basically, I should do a fresh checkout from tip, then apply the patch and do a commit from there, right? No problem on the wait. I always say i it is worth doing it is worth doing right the first time! /********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 *********************/ ron minnich wrote: > I like it. You've tested it I assume. > > I like separating out the DISTRO flags the way you have done. It makes > it very clear what flag is related to what function. > > I realized this fix took a while, but I think the slow nature of the > process got us to the ideal result. We're really using the buildtarget > script in the way we originally intended it to used. I really > appreciate your patience while we figured this problem out. > > Thanks > > Acked-by: Ronald G. Minnch > > ron > p.s. do you need me to do the commit or can you? > From eswierk at arastra.com Fri Jan 4 20:25:16 2008 From: eswierk at arastra.com (Ed Swierk) Date: Fri, 4 Jan 2008 11:25:16 -0800 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: <477D507E.4030106@sun.com> References: <477CF25C.7070901@sun.com> <13426df10801030819p5fa4f8enc9bc2aa6557ad460@mail.gmail.com> <477D2366.7090500@sun.com> <13426df10801031028y3dce3f53g15e336f1df8907b1@mail.gmail.com> <477D2A90.3070001@sun.com> <13426df10801031043o3ea5df06r62f51e7c63fabaaa@mail.gmail.com> <477D507E.4030106@sun.com> Message-ID: On 1/3/08, Marc Karasek wrote: > Here is the patch with the ld option check as well. > > I had to make a few changes to Ron's original patch. One of the problems > was that CFLAGS was being set as a := in the Makefile and was overwriting > the += that was in Makefile.settings. So I added DISTRO_CFLAGS and > DISTRO_LFLAGS for the two additonal flags. The reason for two was that the > build-id option is only used during linking and generated warnings if used > on a compile line and was not being pulled in for the linker lines. These > defines were added to the appropriate places in the Makefile via the > Config.lb file. Are you sure the buildtarget change is right? It seems to be doing just the opposite of what we want, adding --build-id=none only if build-id is _not_ found in ld --help. Also it would be very helpful if you could submit patches in a form that patch or quilt can grok; they both choked on the one you sent. --Ed From Marc.Karasek at Sun.COM Fri Jan 4 20:34:40 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Fri, 04 Jan 2008 14:34:40 -0500 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: References: <477CF25C.7070901@sun.com> <13426df10801030819p5fa4f8enc9bc2aa6557ad460@mail.gmail.com> <477D2366.7090500@sun.com> <13426df10801031028y3dce3f53g15e336f1df8907b1@mail.gmail.com> <477D2A90.3070001@sun.com> <13426df10801031043o3ea5df06r62f51e7c63fabaaa@mail.gmail.com> <477D507E.4030106@sun.com> Message-ID: <477E8A50.2080408@sun.com> Ed sorry for the duplicate, but I only originally replied to you. I will take a look at it. When I ran it it did add the option on my system. The only question I had was for an older ld version would it behave properly. I did the patch using svn diff from the tree. Is there another way to generate it? /********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 *********************/ Ed Swierk wrote: > On 1/3/08, Marc Karasek wrote: > >> Here is the patch with the ld option check as well. >> >> I had to make a few changes to Ron's original patch. One of the problems >> was that CFLAGS was being set as a := in the Makefile and was overwriting >> the += that was in Makefile.settings. So I added DISTRO_CFLAGS and >> DISTRO_LFLAGS for the two additonal flags. The reason for two was that the >> build-id option is only used during linking and generated warnings if used >> on a compile line and was not being pulled in for the linker lines. These >> defines were added to the appropriate places in the Makefile via the >> Config.lb file. >> > > Are you sure the buildtarget change is right? It seems to be doing > just the opposite of what we want, adding --build-id=none only if > build-id is _not_ found in ld --help. > > Also it would be very helpful if you could submit patches in a form > that patch or quilt can grok; they both choked on the one you sent. > > --Ed > From myles at pel.cs.byu.edu Fri Jan 4 21:53:33 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Fri, 4 Jan 2008 13:53:33 -0700 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: <477E8A50.2080408@sun.com> References: <477CF25C.7070901@sun.com><13426df10801030819p5fa4f8enc9bc2aa6557ad460@mail.gmail.com><477D2366.7090500@sun.com><13426df10801031028y3dce3f53g15e336f1df8907b1@mail.gmail.com><477D2A90.3070001@sun.com><13426df10801031043o3ea5df06r62f51e7c63fabaaa@mail.gmail.com><477D507E.4030106@sun.com> <477E8A50.2080408@sun.com> Message-ID: <00f201c84f13$dece15c0$a023040a@chimp> > I did the patch using svn diff from the tree. Is there another way to > generate it? If you have just the changes you want to include in the tree, you can go one level up and do svn diff LinuxBIOSv2 This makes it easier for me. Then I use the -p1 option to patch and it finds the files correctly. It looks like you did svn diff file1 >diff1 svn diff file2 >diff2 svn diff file3 >diff3 And then put the resulting files together. Because a line got deleted from the end of the src/config/Config.lb diff, it complains about a malformed patch and doesn't do the next two. Then again, maybe that line disappeared another way. Myles From eswierk at arastra.com Fri Jan 4 22:20:15 2008 From: eswierk at arastra.com (Ed Swierk) Date: Fri, 4 Jan 2008 13:20:15 -0800 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: <477E8A50.2080408@sun.com> References: <477CF25C.7070901@sun.com> <13426df10801030819p5fa4f8enc9bc2aa6557ad460@mail.gmail.com> <477D2366.7090500@sun.com> <13426df10801031028y3dce3f53g15e336f1df8907b1@mail.gmail.com> <477D2A90.3070001@sun.com> <13426df10801031043o3ea5df06r62f51e7c63fabaaa@mail.gmail.com> <477D507E.4030106@sun.com> <477E8A50.2080408@sun.com> Message-ID: On 1/4/08, Marc Karasek wrote: > Ed sorry for the duplicate, but I only originally replied to you. > > I will take a look at it. When I ran it it did add the option on my > system. The only question I had was for an older ld version would it > behave properly. Try running this snippet from buildtarget in a shell and you'll see what I mean: ld --help | awk '{for (i=1;i<=NF;i++) if ($i ~ /build-id/){n++} }; END {exit n}'; build_id=$?; echo -n 'ld supports --build-id? '; if [ $build_id \ ]; then echo 'yes'; else echo 'no'; fi > I did the patch using svn diff from the tree. Is there another way to > generate it? Not sure... --Ed From rminnich at gmail.com Fri Jan 4 23:05:31 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 4 Jan 2008 14:05:31 -0800 Subject: [LinuxBIOS] PATCH: lx car that returns from disable_car Message-ID: <13426df10801041405h1d3e0f1eocdfba04c34144eb9@mail.gmail.com> This patch set allows disable_car to return. Comments welcome. Thanks to Carl-Daniel and Stefan for not accepting my earlier patches, and arguing me into the ground. They were right. [I hope :-) we still have not solved opteron.] This discussion began quite some time ago. I thought it would never end. But I think we're there. Sometimes, no matter how much sense you think you are making, you've got to listen to other people to get it right ... and it doesn't always get done as soon as you might wish. thanks ron -------------- next part -------------- A non-text attachment was scrubbed... Name: fixlxcar.diff Type: text/x-patch Size: 9863 bytes Desc: not available URL: From Marc.Karasek at Sun.COM Fri Jan 4 23:48:01 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Fri, 04 Jan 2008 17:48:01 -0500 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: References: <477CF25C.7070901@sun.com> <13426df10801030819p5fa4f8enc9bc2aa6557ad460@mail.gmail.com> <477D2366.7090500@sun.com> <13426df10801031028y3dce3f53g15e336f1df8907b1@mail.gmail.com> <477D2A90.3070001@sun.com> <13426df10801031043o3ea5df06r62f51e7c63fabaaa@mail.gmail.com> <477D507E.4030106@sun.com> <477E8A50.2080408@sun.com> Message-ID: <477EB7A1.80406@sun.com> Sorry about the patch, I had to edit it out for some other changes that got pulled into the file and accidentally deleted a line that should have been there. This patch should be better. And I also did a svn diff one level up in the tree (flags.patch) I made a test script and ran it and it sets build_id = 1 properly. I have also included this script. /********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 *********************/ Ed Swierk wrote: > On 1/4/08, Marc Karasek wrote: > >> Ed sorry for the duplicate, but I only originally replied to you. >> >> I will take a look at it. When I ran it it did add the option on my >> system. The only question I had was for an older ld version would it >> behave properly. >> > > Try running this snippet from buildtarget in a shell and you'll see what I mean: > > ld --help | awk '{for (i=1;i<=NF;i++) if ($i ~ /build-id/){n++} }; END > {exit n}'; build_id=$?; echo -n 'ld supports --build-id? '; if [ > $build_id \ > ]; then echo 'yes'; else echo 'no'; fi > > >> I did the patch using svn diff from the tree. Is there another way to >> generate it? >> > > Not sure... > > --Ed > -------------- next part -------------- A non-text attachment was scrubbed... Name: fixflags2.diff Type: text/x-patch Size: 4054 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.patch Type: text/x-patch Size: 201 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: flags.patch Type: text/x-patch Size: 4162 bytes Desc: not available URL: From myles at pel.cs.byu.edu Sat Jan 5 00:04:36 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Fri, 4 Jan 2008 16:04:36 -0700 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: <477EB7A1.80406@sun.com> References: <477CF25C.7070901@sun.com> <477D2366.7090500@sun.com> <13426df10801031028y3dce3f53g15e336f1df8907b1@mail.gmail.com> <477D2A90.3070001@sun.com> <13426df10801031043o3ea5df06r62f51e7c63fabaaa@mail.gmail.com> <477D507E.4030106@sun.com> <477E8A50.2080408@sun.com> <477EB7A1.80406@sun.com> Message-ID: <2831fecf0801041504l664b9eb2x168dedce6a50548a@mail.gmail.com> It doesn't work for me. It says build-id is supported, and it's not. The script I attached works for me, though. Myles On Jan 4, 2008 3:48 PM, Marc Karasek wrote: > Sorry about the patch, I had to edit it out for some other changes that > got pulled into the file and accidentally deleted a line that should > have been there. This patch should be better. > > And I also did a svn diff one level up in the tree (flags.patch) > > I made a test script and ran it and it sets build_id = 1 properly. I > have also included this script. > > /********************* > Marc Karasek > MTS > Sun Microsystems > mailto:marc.karasek at sun.com > ph:770.360.6415 > *********************/ > > > > Ed Swierk wrote: > > > On 1/4/08, Marc Karasek wrote: > > > >> Ed sorry for the duplicate, but I only originally replied to you. > >> > >> I will take a look at it. When I ran it it did add the option on my > >> system. The only question I had was for an older ld version would it > >> behave properly. > >> > > > > Try running this snippet from buildtarget in a shell and you'll see what I mean: > > > > ld --help | awk '{for (i=1;i<=NF;i++) if ($i ~ /build-id/){n++} }; END > > {exit n}'; build_id=$?; echo -n 'ld supports --build-id? '; if [ > > $build_id \ > > ]; then echo 'yes'; else echo 'no'; fi > > > > > >> I did the patch using svn diff from the tree. Is there another way to > >> generate it? > >> > > > > Not sure... > > > > --Ed > > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > -------------- next part -------------- A non-text attachment was scrubbed... Name: test.patch Type: text/x-patch Size: 221 bytes Desc: not available URL: From svn at openbios.org Sat Jan 5 00:12:22 2008 From: svn at openbios.org (svn at openbios.org) Date: Sat, 5 Jan 2008 00:12:22 +0100 Subject: [LinuxBIOS] r544 - in LinuxBIOSv3: include lib northbridge/amd/geodelx Message-ID: Author: hailfinger Date: 2008-01-05 00:12:22 +0100 (Sat, 05 Jan 2008) New Revision: 544 Modified: LinuxBIOSv3/include/console.h LinuxBIOSv3/lib/console.c LinuxBIOSv3/northbridge/amd/geodelx/raminit.c Log: Add a banner function to lib/console.c that is SHARED so all code can use it. Signed-off-by: Ronald G. Minnich Acked-by: Carl-Daniel Hailfinger Modified: LinuxBIOSv3/include/console.h =================================================================== --- LinuxBIOSv3/include/console.h 2008-01-04 12:53:09 UTC (rev 543) +++ LinuxBIOSv3/include/console.h 2008-01-04 23:12:22 UTC (rev 544) @@ -48,5 +48,6 @@ SHARED_WITH_ATTRIBUTES(printk, int, __attribute__((format (printf, 2, 3))), int msg_level, const char *fmt, ...); +SHARED(banner, void, int msg_level, const char *msg); #endif /* CONSOLE_H */ Modified: LinuxBIOSv3/lib/console.c =================================================================== --- LinuxBIOSv3/lib/console.c 2008-01-04 12:53:09 UTC (rev 543) +++ LinuxBIOSv3/lib/console.c 2008-01-04 23:12:22 UTC (rev 544) @@ -46,6 +46,29 @@ return i; } +/** + * Print a nice banner so we know what step we died on. + * + * @param level The printk level (e.g. BIOS_EMERG) + * @param s String to put in the middle of the banner + */ + +void banner(int level, const char *s) +{ + int i; + /* 10 = signs and a space. */ + printk(level, "========== "); + for(i = 11; *s; i++, s++) + printk(level, "%c", *s); + /* trailing space */ + printk(level, " "); + i++; + /* fill it up to 80 columns */ + for(; i < 80; i++) + printk(level, "="); + printk(level, "\n"); +} + void console_init(void) { static const char console_test[] = Modified: LinuxBIOSv3/northbridge/amd/geodelx/raminit.c =================================================================== --- LinuxBIOSv3/northbridge/amd/geodelx/raminit.c 2008-01-04 12:53:09 UTC (rev 543) +++ LinuxBIOSv3/northbridge/amd/geodelx/raminit.c 2008-01-04 23:12:22 UTC (rev 544) @@ -36,19 +36,6 @@ u8 spd_read_byte(u16 device, u8 address); /** - * Print a nice banner so we know what step we died on. - * - * @param s String to put in the middle of the banner - */ - -void banner(char *s) -{ - printk(BIOS_DEBUG, "==========================="); - printk(BIOS_DEBUG, s); - printk(BIOS_DEBUG, "======================================\n"); -} - -/** * Halt and Catch Fire. Print an error, then loop, sending NULLs on serial port, * to ensure the message is visible. * @@ -83,14 +70,14 @@ dimm_setting = 0; - banner("Check present"); + banner(BIOS_DEBUG, "Check present"); /* Check that we have a DIMM. */ if (spd_read_byte(dimm, SPD_MEMORY_TYPE) == 0xFF) return; /* Field: Module Banks per DIMM */ /* EEPROM byte usage: (5) Number of DIMM Banks */ - banner("MODBANKS"); + banner(BIOS_DEBUG, "MODBANKS"); spd_byte = spd_read_byte(dimm, SPD_NUM_DIMM_BANKS); if ((MIN_MOD_BANKS > spd_byte) && (spd_byte > MAX_MOD_BANKS)) { printk(BIOS_EMERG, "Number of module banks not compatible\n"); @@ -101,7 +88,7 @@ /* Field: Banks per SDRAM device */ /* EEPROM byte usage: (17) Number of Banks on SDRAM Device */ - banner("FIELDBANKS"); + banner(BIOS_DEBUG, "FIELDBANKS"); spd_byte = spd_read_byte(dimm, SPD_NUM_BANKS_PER_SDRAM); if ((MIN_DEV_BANKS > spd_byte) && (spd_byte > MAX_DEV_BANKS)) { printk(BIOS_EMERG, "Number of device banks not compatible\n"); @@ -117,7 +104,7 @@ *; (31) Module Bank Density *; Size = Module Density * Module Banks */ - banner("SPDNUMROWS"); + banner(BIOS_DEBUG, "SPDNUMROWS"); if ((spd_read_byte(dimm, SPD_NUM_ROWS) & 0xF0) || (spd_read_byte(dimm, SPD_NUM_COLUMNS) & 0xF0)) { @@ -127,7 +114,7 @@ } /* Size = Module Density * Module Banks */ - banner("SPDBANKDENSITY"); + banner(BIOS_DEBUG, "SPDBANKDENSITY"); dimm_size = spd_read_byte(dimm, SPD_BANK_DENSITY); /* Align so 1 GB (bit 0) is bit 8. This is a little weird to get gcc @@ -143,9 +130,9 @@ /* Module Density * Module Banks */ /* Shift to multiply by the number of DIMM banks. */ dimm_size <<= (dimm_setting >> CF07_UPPER_D0_MB_SHIFT) & 1; - banner("BEFORT CTZ"); + banner(BIOS_DEBUG, "BEFORT CTZ"); dimm_size = __builtin_ctz(dimm_size); - banner("TEST DIMM SIZE>8"); + banner(BIOS_DEBUG, "TEST DIMM SIZE>8"); if (dimm_size > 8) { /* 8 is 1 GB only support 1 GB per DIMM */ printk(BIOS_EMERG, "Only support up to 1 GB per DIMM\n"); post_code(ERROR_DENSITY_DIMM); @@ -177,9 +164,9 @@ * example, #col_addr_bits = 7 (06h), it adds 3 to get 10, then does * 2^10=1K. Get it? */ - banner("PAGESIZE"); + banner(BIOS_DEBUG, "PAGESIZE"); spd_byte = num_col_addr[spd_read_byte(dimm, SPD_NUM_COLUMNS) & 0xF]; - banner("MAXCOLADDR"); + banner(BIOS_DEBUG, "MAXCOLADDR"); if (spd_byte > MAX_COL_ADDR) { printk(BIOS_EMERG, "DIMM page size not compatible\n"); post_code(ERROR_SET_PAGE); @@ -193,9 +180,9 @@ /* 0 = 1k, 1 = 2k, 2 = 4k, etc. */ dimm_setting |= spd_byte << CF07_UPPER_D0_PSZ_SHIFT; - banner("RDMSR CF07"); + banner(BIOS_DEBUG, "RDMSR CF07"); msr = rdmsr(MC_CF07_DATA); - banner("WRMSR CF07"); + banner(BIOS_DEBUG, "WRMSR CF07"); if (dimm == dimm0) { msr.hi &= 0xFFFF0000; msr.hi |= dimm_setting; @@ -203,7 +190,7 @@ msr.hi &= 0x0000FFFF; msr.hi |= dimm_setting << 16; } - banner("ALL DONE"); + banner(BIOS_DEBUG, "ALL DONE"); wrmsr(MC_CF07_DATA, msr); } From svn at openbios.org Sat Jan 5 00:14:10 2008 From: svn at openbios.org (svn at openbios.org) Date: Sat, 5 Jan 2008 00:14:10 +0100 Subject: [LinuxBIOS] r545 - LinuxBIOSv3/lib Message-ID: Author: hailfinger Date: 2008-01-05 00:14:10 +0100 (Sat, 05 Jan 2008) New Revision: 545 Modified: LinuxBIOSv3/lib/console.c Log: Change die() to make it JTAG friendly. Signed-off-by: Ronald G. Minnich Acked-by: Carl-Daniel Hailfinger Modified: LinuxBIOSv3/lib/console.c =================================================================== --- LinuxBIOSv3/lib/console.c 2008-01-04 23:12:22 UTC (rev 544) +++ LinuxBIOSv3/lib/console.c 2008-01-04 23:14:10 UTC (rev 545) @@ -82,9 +82,31 @@ printk(BIOS_INFO, console_test); } +/** + * Halt and loop due to a fatal error. + * There have been several iterations of this function. + * The first simply did a hlt(). Doing a hlt() can make jtag debugging + * very difficult as one can not break into a hlt instruction on some CPUs. + * Second was to do a console_tx_byte of a NULL character. + * A number of concerns were raised about doing this idea. + * Third idea was to do an inb from port 0x80, the POST port. That design + * makes us very CPU-specific. + * The fourth idea was just POSTING the same + * code over and over. That would erase the most recent POST code, + * hindering diagnosis. + * + * For now, for lack of a good alternative, + * we will continue to call console_tx_byte. We call with a NULL since + * it will clear any FIFOs in the path and won't clutter up the output, + * since NULL doesn't print a visible character on most terminal + * emulators. + * + * @param str A string to print for the error + * + */ void die(const char *str) { printk(BIOS_EMERG, str); while (1) - hlt(); + console_tx_byte(0, (void *)0); } From eswierk at arastra.com Sat Jan 5 00:16:48 2008 From: eswierk at arastra.com (Ed Swierk) Date: Fri, 4 Jan 2008 15:16:48 -0800 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: <477EB7A1.80406@sun.com> References: <477CF25C.7070901@sun.com> <477D2366.7090500@sun.com> <13426df10801031028y3dce3f53g15e336f1df8907b1@mail.gmail.com> <477D2A90.3070001@sun.com> <13426df10801031043o3ea5df06r62f51e7c63fabaaa@mail.gmail.com> <477D507E.4030106@sun.com> <477E8A50.2080408@sun.com> <477EB7A1.80406@sun.com> Message-ID: On 1/4/08, Marc Karasek wrote: > I made a test script and ran it and it sets build_id = 1 properly. I > have also included this script. The problem is that on Planet Bourne, zero means true and nonzero means false. --Ed From svn at openbios.org Sat Jan 5 00:19:49 2008 From: svn at openbios.org (svn at openbios.org) Date: Sat, 5 Jan 2008 00:19:49 +0100 Subject: [LinuxBIOS] r546 - in LinuxBIOSv3: arch/x86/geodelx include/arch/x86 Message-ID: Author: hailfinger Date: 2008-01-05 00:19:49 +0100 (Sat, 05 Jan 2008) New Revision: 546 Modified: LinuxBIOSv3/arch/x86/geodelx/stage1.c LinuxBIOSv3/include/arch/x86/amd_geodelx.h Log: These changes implement a fixed Geode LX Cache As Ram that allows a return from disable_car. - Move the cache as ram memory to 0x80000 instead of 0xc8000, as the C range is really tricky to get right :-) - Modify the geode disable_car to ensure the cache is flushed to ram on the wbinvd. With these changes, I get a payload loaded. Signed-off-by: Ronald G. Minnich Acked-by: Carl-Daniel Hailfinger Modified: LinuxBIOSv3/arch/x86/geodelx/stage1.c =================================================================== --- LinuxBIOSv3/arch/x86/geodelx/stage1.c 2008-01-04 23:14:10 UTC (rev 545) +++ LinuxBIOSv3/arch/x86/geodelx/stage1.c 2008-01-04 23:19:49 UTC (rev 546) @@ -22,6 +22,7 @@ #include #include #include +#include static const struct msrinit msr_table[] = { /* Setup access to cache under 1MB. */ @@ -59,5 +60,12 @@ for (i = 0; i < ARRAY_SIZE(msr_table); i++) wrmsr(msr_table[i].msrnum, msr_table[i].msr); - __asm__("wbinvd\n"); + /* OK, here is the theory: we should be able to copy + * the data back over itself, and the wbinvd should then + * flush to memory. Let's see. + */ + __asm__ __volatile__("cld; rep movsl" ::"D" (DCACHE_RAM_BASE), "S" (DCACHE_RAM_BASE), "c" (DCACHE_RAM_SIZE/4): "memory"); + __asm__ __volatile__ ("wbinvd\n"); + banner(BIOS_DEBUG, "Disable_car: done wbinvd"); + banner(BIOS_DEBUG, "disable_car: done"); } Modified: LinuxBIOSv3/include/arch/x86/amd_geodelx.h =================================================================== --- LinuxBIOSv3/include/arch/x86/amd_geodelx.h 2008-01-04 23:14:10 UTC (rev 545) +++ LinuxBIOSv3/include/arch/x86/amd_geodelx.h 2008-01-04 23:19:49 UTC (rev 546) @@ -566,12 +566,17 @@ /* ------------------------ */ #define DCACHE_RAM_SIZE 0x08000 -#define DCACHE_RAM_BASE 0xc8000 +#define DCACHE_RAM_BASE 0x80000 /* This is where the DCache will be mapped and be used as stack. It would be * cool if it was the same base as LinuxBIOS normal stack. */ #define LX_STACK_BASE DCACHE_RAM_BASE #define LX_STACK_END LX_STACK_BASE + (DCACHE_RAM_SIZE - 4) +/* This is where the DCache will be mapped and be used as stack. It would be + * cool if it was the same base as LinuxBIOS normal stack. + */ +#define LX_STACK_BASE DCACHE_RAM_BASE +#define LX_STACK_END LX_STACK_BASE + (DCACHE_RAM_SIZE - 4) #define LX_NUM_CACHELINES 0x080 /* There are 128 lines per way. */ #define LX_CACHELINE_SIZE 0x020 /* There are 32 bytes per line. */ From rminnich at gmail.com Sat Jan 5 01:35:44 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 4 Jan 2008 16:35:44 -0800 Subject: [LinuxBIOS] v3 Message-ID: <13426df10801041635y39d3c002y18fe82a134df5732@mail.gmail.com> bringing along other files in lar. i want to bring vsa into lar. And I don't recall how we want to do this. Any ideas? thanks ron From rminnich at gmail.com Sat Jan 5 01:59:54 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 4 Jan 2008 16:59:54 -0800 Subject: [LinuxBIOS] empty payload Message-ID: <13426df10801041659k3448eb91p10259b1c245b7cd1@mail.gmail.com> I'm writing an 'empty' payload for testing. It will do nothing but POST and send out chars in a tight loop. I am wondering about making it part of v3 tree. Just make an emptypayload directory. This would make testing easier. I don't know, comments? ron From c-d.hailfinger.devel.2006 at gmx.net Sat Jan 5 02:06:27 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 05 Jan 2008 02:06:27 +0100 Subject: [LinuxBIOS] empty payload In-Reply-To: <13426df10801041659k3448eb91p10259b1c245b7cd1@mail.gmail.com> References: <13426df10801041659k3448eb91p10259b1c245b7cd1@mail.gmail.com> Message-ID: <477ED813.9080603@gmx.net> On 05.01.2008 01:59, ron minnich wrote: > I'm writing an 'empty' payload for testing. It will do nothing but > POST and send out chars in a tight loop. > > I am wondering about making it part of v3 tree. Just make an > emptypayload directory. This would make testing easier. > > I don't know, comments? > Absolutely. You have my ack even without seeing the code ;-). Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Sat Jan 5 02:10:13 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 05 Jan 2008 02:10:13 +0100 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member Message-ID: <477ED8F5.1030807@gmx.net> Check for a terminating LAR member which tells us that no further LAR member except the bootblock will be found after this member. The LAR member has a normal MAGIC, but all other parts of struct lar_header are 0xff. That way, adding a new member in place of the terminating member will not need an erase cycle. Signed-off-by: Carl-Daniel Hailfinger Index: LinuxBIOSv3-larplaceholder/lib/lar.c =================================================================== --- LinuxBIOSv3-larplaceholder/lib/lar.c (Revision 546) +++ LinuxBIOSv3-larplaceholder/lib/lar.c (Arbeitskopie) @@ -58,7 +58,7 @@ int find_file(const struct mem_file *archive, const char *filename, struct mem_file *result) { - char *walk, *fullname; + char *walk, *fullname, *tmp; struct lar_header *header; printk(BIOS_INFO, "LAR: Attempting to open '%s'.\n", filename); @@ -105,10 +105,24 @@ for (walk = archive->start; (walk < (char *)(archive->start + archive->len - sizeof(struct lar_header))) && (walk >= (char *)archive->start); walk += 16) { - if (strncmp(walk, MAGIC, 8) != 0) + if (strncmp(walk, MAGIC, sizeof(header->magic)) != 0) continue; header = (struct lar_header *)walk; + /* The loop below deserves an explanation: The final iteration + * of the loop will access the byte after the header. If that + * iteration has been reached, all checked bytes in the header + * were 0xff. This saves one state variable. + */ + for (tmp = walk + sizeof(header->magic); + tmp <= walk + sizeof(*header); tmp++) { + if (*tmp != (char)0xff) + break; + } + if (tmp == walk + sizeof(*header)) { + printk(BIOS_SPEW, "LAR: termination pseudomember reached.\n"); + break; + } fullname = walk + sizeof(struct lar_header); printk(BIOS_SPEW, "LAR: seen member %s\n", fullname); From r.marek at assembler.cz Sat Jan 5 02:11:08 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Sat, 05 Jan 2008 02:11:08 +0100 Subject: [LinuxBIOS] Suspend to RAM with LinuxBIOSv2 Message-ID: <477ED92C.4030300@assembler.cz> Hi all, I'm pleased to announce that I got S3 working with LinuxBIOSv2 on ASUS A8V-E SE (K8 + VT8237 + K8T890)! I'm attaching the patch which is a big mess, but perhaps all are curious how is it done. To be able to do S3 we must first set the register values used for sleep in ACPI DSDT table: + Name (\_S3, Package () {0x01, 0x01, 0x00, 0x00 }) Plus we need some callbacks to SB code which tells LinuxBIOS if it is normal startup or Wakeup and if it is a wakeup we need to know the vector to return to OS. This vector is stored in one ACPI table and because LinuxBIOSv2 puts tables on same place I will take the vector value just before I overwrite it ;) So how it works? LinuxBIOS will boot as usual if S3, but not executing payload but jumping to real mode waking vector from OS. During memory initialization we need to exit the self-refresh mode instead of training the memory again. Plus we need to adjust the K8 registers to listen for SMAF messages from SB that we go S3. The serious problem is that LinuxBIOS overwrites a lot of memory - lowmem, highmem (1M above). So how to protect it for OS? I booted linux with custom memory map 2M-1GB and LinuxBIOS had 0M-2M for its own stuff. But If I reserved memory for linux this way, ACPI code refuses to work, because OS waking code must be in 1MB range. I decided to patch the kernel and put always waking code to 0xE000:0000 /linux-2.6.23.1/arch/x86_64/kernel/acpi/sleep.c void __init acpi_reserve_bootmem(void) { acpi_wakeup_address = phys_to_virt(0xE0000); //(unsigned long)alloc_bootmem_low(PAGE_SIZE*2); printk("ACpi wakeup %x\n", acpi_wakeup_address); if ((&wakeup_end - &wakeup_start) > (PAGE_SIZE*2)) printk(KERN_CRIT "ACPI: Wakeup code way too big, will crash on attempt" " to suspend\n"); } Getting close to have working implementation but one thing was still missing. The exit from Self refresh seemed not to work. But, booting with original BIOS, rebooting to LB and then suspend/resume in LB did work! Hum something was wrong with some chip, but not with memory itself. Today I found out. There seems to be some undocumented bit in Winbond W83627EHF which will leave power to right parts of the system :) The attached script fix_ehf has a workaround ;) In the meanwhile I found out how to blink with the power LED and how to overclock the motherboard + most GPIO meaning, so I updated the Wiki page with that too. So what needs to be done? 1) consolidate the memory usage of LinuxBIOSv2 2) dont clean arbitrary memory Perhaps we could reserve last 1MB of RAM or something after 8MB of mem and put linuxBIOS heap there when using S3 we would just reserve the region + (some region bellow the 1MB for AP CPU boot + ACPI tables etc) The patch has some errata update of code too, I will publish this as separate patch - I did it because I thought I got still some memory related problem. Unfortunately I do not have much time for this fun, very busy with other stuff, but I needed some break ;) Oh I forgot - the real mode switcher and A20 handler are from Linux kernel. Thanks, Rudolf -------------- next part -------------- A non-text attachment was scrubbed... Name: s3.patch Type: text/x-patch Size: 22908 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fix_ehf URL: From rminnich at gmail.com Sat Jan 5 02:22:41 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 4 Jan 2008 17:22:41 -0800 Subject: [LinuxBIOS] patch a trivial error in stage1.c Message-ID: <13426df10801041722l342f1abata4767ba0a617cb61@mail.gmail.com> attached ron -------------- next part -------------- A non-text attachment was scrubbed... Name: trivialstage1.diff Type: text/x-patch Size: 585 bytes Desc: not available URL: From rminnich at gmail.com Sat Jan 5 02:26:34 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 4 Jan 2008 17:26:34 -0800 Subject: [LinuxBIOS] v3: FIRST PAYLOAD RUN! Message-ID: <13426df10801041726t6e01e9dfha096907f177bb550@mail.gmail.com> I just ran the first actual payload on the alix1c with v3. I must admit, to my embarassment, that it was a RET instruction, but you have to start somewhere, right? It's a start. ron From svn at openbios.org Sat Jan 5 02:33:28 2008 From: svn at openbios.org (svn at openbios.org) Date: Sat, 5 Jan 2008 02:33:28 +0100 Subject: [LinuxBIOS] r547 - LinuxBIOSv3/include/arch/x86 Message-ID: Author: hailfinger Date: 2008-01-05 02:33:28 +0100 (Sat, 05 Jan 2008) New Revision: 547 Modified: LinuxBIOSv3/include/arch/x86/amd_geodelx.h Log: include/arch/x86/amd_geodelx.h had duplicated #defines by accident in r546. Remove them again. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Ronald G. Minnich Modified: LinuxBIOSv3/include/arch/x86/amd_geodelx.h =================================================================== --- LinuxBIOSv3/include/arch/x86/amd_geodelx.h 2008-01-04 23:19:49 UTC (rev 546) +++ LinuxBIOSv3/include/arch/x86/amd_geodelx.h 2008-01-05 01:33:28 UTC (rev 547) @@ -572,11 +572,6 @@ */ #define LX_STACK_BASE DCACHE_RAM_BASE #define LX_STACK_END LX_STACK_BASE + (DCACHE_RAM_SIZE - 4) -/* This is where the DCache will be mapped and be used as stack. It would be - * cool if it was the same base as LinuxBIOS normal stack. - */ -#define LX_STACK_BASE DCACHE_RAM_BASE -#define LX_STACK_END LX_STACK_BASE + (DCACHE_RAM_SIZE - 4) #define LX_NUM_CACHELINES 0x080 /* There are 128 lines per way. */ #define LX_CACHELINE_SIZE 0x020 /* There are 32 bytes per line. */ From svn at openbios.org Sat Jan 5 02:35:57 2008 From: svn at openbios.org (svn at openbios.org) Date: Sat, 5 Jan 2008 02:35:57 +0100 Subject: [LinuxBIOS] r548 - LinuxBIOSv3/arch/x86 Message-ID: Author: hailfinger Date: 2008-01-05 02:35:57 +0100 (Sat, 05 Jan 2008) New Revision: 548 Modified: LinuxBIOSv3/arch/x86/stage1.c Log: Fix a simple error in stage1.c (missing else). Signed-off-by: Ronald G. Minnich Acked-by: Carl-Daniel Hailfinger Modified: LinuxBIOSv3/arch/x86/stage1.c =================================================================== --- LinuxBIOSv3/arch/x86/stage1.c 2008-01-05 01:33:28 UTC (rev 547) +++ LinuxBIOSv3/arch/x86/stage1.c 2008-01-05 01:35:57 UTC (rev 548) @@ -176,9 +176,9 @@ entry = load_file_segments(&archive, "normal/payload"); if (entry != (void*)-1) run_address(entry); + else + die("FATAL: No usable payload found.\n"); - die("FATAL: No usable payload found.\n"); - die ("FATAL: Last stage returned to LinuxBIOS.\n"); } From c-d.hailfinger.devel.2006 at gmx.net Sat Jan 5 02:37:46 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 05 Jan 2008 02:37:46 +0100 Subject: [LinuxBIOS] patch a trivial error in stage1.c In-Reply-To: <13426df10801041722l342f1abata4767ba0a617cb61@mail.gmail.com> References: <13426df10801041722l342f1abata4767ba0a617cb61@mail.gmail.com> Message-ID: <477EDF6A.8040200@gmx.net> On 05.01.2008 02:22, ron minnich wrote: > Fix a simple error in stage1.c > > Signed-off-by: Ronald G. Minnich > Thanks, r548. Regards, Carl-Daniel From rminnich at gmail.com Sat Jan 5 02:36:57 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 4 Jan 2008 17:36:57 -0800 Subject: [LinuxBIOS] v3 status Message-ID: <13426df10801041736rdae8c21ubd3e1cc947a068d3@mail.gmail.com> v3 loads and runs on an alix1c. So far, the only payload that works is a RET. Even a simple OUTB followed by a RET fails. Any ideas on this? I'm flummoxed. Could it be the stack location? Stack is at 0x8fxxx. Also, I have to run at < 1 MB, the memory above 1 MB reads back as all ffffffff. that's all for today. First payload is a good day. fixing disable_car is even better :-) we're getting there. ron From c-d.hailfinger.devel.2006 at gmx.net Sat Jan 5 02:39:57 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 05 Jan 2008 02:39:57 +0100 Subject: [LinuxBIOS] v3: FIRST PAYLOAD RUN! In-Reply-To: <13426df10801041726t6e01e9dfha096907f177bb550@mail.gmail.com> References: <13426df10801041726t6e01e9dfha096907f177bb550@mail.gmail.com> Message-ID: <477EDFED.7020505@gmx.net> On 05.01.2008 02:26, ron minnich wrote: > I just ran the first actual payload on the alix1c with v3. > Congratulations! Out persistence has paid off. > I must admit, to my embarassment, that it was a RET instruction, but > you have to start somewhere, right? > > It's a start. > Indeed. I hope we can run memtest soon. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Sat Jan 5 02:48:10 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 05 Jan 2008 02:48:10 +0100 Subject: [LinuxBIOS] v3 status In-Reply-To: <13426df10801041736rdae8c21ubd3e1cc947a068d3@mail.gmail.com> References: <13426df10801041736rdae8c21ubd3e1cc947a068d3@mail.gmail.com> Message-ID: <477EE1DA.7000506@gmx.net> On 05.01.2008 02:36, ron minnich wrote: > v3 loads and runs on an alix1c. > > So far, the only payload that works is a RET. Even a simple OUTB > followed by a RET fails. > outb and ret in asm? If not, we may have problems with the state of the registers the called program expects. It would be interesting to see if the asm outb is successful. > Any ideas on this? I'm flummoxed. Could it be the stack location? > Stack is at 0x8fxxx. > > Also, I have to run at < 1 MB, the memory above 1 MB reads back as all ffffffff. We'll get there. The progress has been impressive, and executing a payload is really a sign that the code is good enough for everything before the payload. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Sat Jan 5 03:24:13 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 05 Jan 2008 03:24:13 +0100 Subject: [LinuxBIOS] v3 status In-Reply-To: <13426df10801041736rdae8c21ubd3e1cc947a068d3@mail.gmail.com> References: <13426df10801041736rdae8c21ubd3e1cc947a068d3@mail.gmail.com> Message-ID: <477EEA4D.5040202@gmx.net> On 05.01.2008 02:36, ron minnich wrote: > v3 loads and runs on an alix1c. > [...] > Also, I have to run at < 1 MB, the memory above 1 MB reads back as all ffffffff. > arch/x86/geodelx/stage1.c has two very interesting comments: /* Setup access to cache under 1MB. */ [...] /* Setup access to memory under 1MB. Note: VGA hole at 0xA0000-0xBFFFF */ Regards, Carl-Daniel From jordan.crouse at amd.com Sat Jan 5 03:38:34 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Fri, 4 Jan 2008 19:38:34 -0700 Subject: [LinuxBIOS] empty payload In-Reply-To: <13426df10801041659k3448eb91p10259b1c245b7cd1@mail.gmail.com> References: <13426df10801041659k3448eb91p10259b1c245b7cd1@mail.gmail.com> Message-ID: <20080105023834.GA16626@cosmic.amd.com> On 04/01/08 16:59 -0800, ron minnich wrote: > I'm writing an 'empty' payload for testing. It will do nothing but > POST and send out chars in a tight loop. > > I am wondering about making it part of v3 tree. Just make an > emptypayload directory. This would make testing easier. This would be a good start for the payload library idea that we've been tossing around. A few months ago, I rearranged bits and pieces of FILO into a C like library - I have a helloworld sitting around somewhere. Uwe and I have discussed in the past adding things like tinylib and his ncurses work from GSOC, and its not out of the realm of possibility to port something like directFB or TWIN in too. But believe it or not - if you want to start off rewriting code from scratch, that would be better. I think that if we had a payload library, it would behoove us all to licence it LGPL. As a vendor, I think our biggest selling point for LinuxBIOS is that the customer has control over the payload to do what they need to do, and sometimes, for better or worse, those payloads need to do things that customers cannot or will not expose with GPL. A great example is the long lamented CE loader. There are two measly variables in the information structure for CE that are not yet exposed by Microsoft (If you have the CE development kit, you can see the header, but its capped off by the usual nasty Microsoft copyright message). If the library was LGPL, then we could at least publish the binary payload, which would be a start until Microsoft moved on and saw fit to document the last few variables. I would be happy to work with you on the loader scripts and other fun that we would need to make it go. My thought is that we can make some shell wrappers around gcc to point to the right locations, and then it would be as easy as: libpayload-gcc -o mypayload mypayload.c just give us a main() and a pocket full of dreams and we'll do the rest. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From duwe at lst.de Sat Jan 5 17:42:06 2008 From: duwe at lst.de (Torsten Duwe) Date: Sat, 5 Jan 2008 17:42:06 +0100 Subject: [LinuxBIOS] RESEND: patch: fix the problem with CONFIG_CONSOLE_VGA not pulling in the emulator In-Reply-To: <13426df10801030937k5ffecaabndc421bbd5e0a1ce0@mail.gmail.com> References: <13426df10801030937k5ffecaabndc421bbd5e0a1ce0@mail.gmail.com> Message-ID: <200801051742.06358.duwe@lst.de> Here's the full story, which I'm hoping to address all related problems with. We agreed that a VGA console and the need to run any option ROMs is mutually not strictly dependent, Luc's problem was that LBv2 code doesn't reflect that. There are 6 combinations: * Console may be on VGA or not (e.g. serial) _independently_ * LB might run - no option ROMs - only VGA option ROMs - all option ROMs The combination "no option ROMs" / "VGA console" currently does not compile; Ron fixed that. I would now additionally introduce CONFIG_VGA_ROM_RUN, to map all 6 combinations. The implicit (broken) assumption that CONSOLE_VGA would also run the ROMs is lifted, and transferred to this new config option instead; the source code becomes less ambiguous. This change is minimally intrusive, because all board configs that previously assumed CONSOLE_VGA would also run the ROMs didn't compile, they had to also specify PCI_ROM_RUN, so this new option only offers 2 new opportunities which didn't work before or were impossible to specify, respectively. This part combines Luc's and Ron's patches, and adds the new option to clarify. Signed-off-by: Torsten Duwe -------------- next part -------------- A non-text attachment was scrubbed... Name: VGA_ROM_RUN-1 Type: text/x-diff Size: 3042 bytes Desc: not available URL: From duwe at lst.de Sat Jan 5 17:51:02 2008 From: duwe at lst.de (Torsten Duwe) Date: Sat, 5 Jan 2008 17:51:02 +0100 Subject: [LinuxBIOS] RESEND: patch: fix the problem with CONFIG_CONSOLE_VGA not pulling in the emulator In-Reply-To: <200801051742.06358.duwe@lst.de> References: <13426df10801030937k5ffecaabndc421bbd5e0a1ce0@mail.gmail.com> <200801051742.06358.duwe@lst.de> Message-ID: <200801051751.03058.duwe@lst.de> Walking through the code to distinguish between VGA_ROM_RUN and CONSOLE_VGA, I've seen assumptions about the memory layout and PCI_ROM_RUN, which I considered errors; CONSOLE_VGA || PCI_ROM_RUN was probably cut and pasted? I removed the PCI_ROM_RUN, please check. Signed-off-by: Torsten Duwe diff -BNurbp LinuxBIOSv2.orig/src/config/linuxbios_ram.ld LinuxBIOSv2/src/config/linuxbios_ram.ld --- LinuxBIOSv2.orig/src/config/linuxbios_ram.ld 2007-07-25 18:26:10.000000000 +0200 +++ LinuxBIOSv2/src/config/linuxbios_ram.ld 2008-01-05 17:14:27.000000000 +0100 @@ -92,8 +92,8 @@ SECTIONS _stack = .; .stack . : { /* Reserve a stack for each possible cpu */ - /* the stack for ap will be put after pgtbl in 1M to CONFIG_LB_MEM_TOPK range when VGA and ROM_RUN and CONFIG_LB_MEM_TOPK>1024*/ - . = ((CONFIG_CONSOLE_VGA || CONFIG_PCI_ROM_RUN)&&(_RAMBASE<0x100000)&&(CONFIG_LB_MEM_TOPK>(0x100000>>10)) ) ? STACK_SIZE : (CONFIG_MAX_CPUS*STACK_SIZE); + /* the stack for ap will be put after pgtbl in 1M to CONFIG_LB_MEM_TOPK range when VGA mem is used and CONFIG_LB_MEM_TOPK>1024*/ + . = (CONFIG_CONSOLE_VGA &&(_RAMBASE<0x100000)&&(CONFIG_LB_MEM_TOPK>(0x100000>>10)) ) ? STACK_SIZE : (CONFIG_MAX_CPUS*STACK_SIZE); } _estack = .; _heap = .; @@ -111,7 +111,7 @@ SECTIONS _bogus = ASSERT( ( (_eram_seg>>10) < (CONFIG_LB_MEM_TOPK)) , "please increase CONFIG_LB_MEM_TOPK"); - _bogus = ASSERT( !((CONFIG_CONSOLE_VGA || CONFIG_PCI_ROM_RUN) && ((_ram_seg<0xa0000) && (_eram_seg>0xa0000))) , "please increase CONFIG_LB_MEM_TOPK and if still fail, try to set _RAMBASE more than 1M"); + _bogus = ASSERT( !(CONFIG_CONSOLE_VGA && ((_ram_seg<0xa0000) && (_eram_seg>0xa0000))) , "please increase CONFIG_LB_MEM_TOPK and if still fail, try to set _RAMBASE more than 1M"); /DISCARD/ : { *(.comment) diff -BNurbp LinuxBIOSv2.orig/src/cpu/x86/lapic/lapic_cpu_init.c LinuxBIOSv2/src/cpu/x86/lapic/lapic_cpu_init.c --- LinuxBIOSv2.orig/src/cpu/x86/lapic/lapic_cpu_init.c 2007-07-25 18:25:59.000000000 +0200 +++ LinuxBIOSv2/src/cpu/x86/lapic/lapic_cpu_init.c 2008-01-05 17:11:43.000000000 +0100 @@ -226,7 +226,7 @@ int start_cpu(device_t cpu) index = ++last_cpu_index; /* Find end of the new processors stack */ -#if (CONFIG_LB_MEM_TOPK>1024) && (_RAMBASE < 0x100000) && ((CONFIG_CONSOLE_VGA==1) || (CONFIG_PCI_ROM_RUN == 1)) +#if (CONFIG_LB_MEM_TOPK>1024) && (_RAMBASE < 0x100000) && (CONFIG_CONSOLE_VGA==1) if(index<1) { // only keep bsp on low stack_end = ((unsigned long)_estack) - (STACK_SIZE*index) - sizeof(struct cpu_info); } else { diff -BNurbp LinuxBIOSv2.orig/src/cpu/x86/pae/pgtbl.c LinuxBIOSv2/src/cpu/x86/pae/pgtbl.c --- LinuxBIOSv2.orig/src/cpu/x86/pae/pgtbl.c 2007-07-25 18:25:59.000000000 +0200 +++ LinuxBIOSv2/src/cpu/x86/pae/pgtbl.c 2008-01-05 17:11:20.000000000 +0100 @@ -54,7 +54,7 @@ void *map_2M_page(unsigned long page) struct pde pdp[512]; } __attribute__ ((packed)); -#if (CONFIG_LB_MEM_TOPK>1024) && (_RAMBASE<0x100000) && ((CONFIG_CONSOLE_VGA==1) || (CONFIG_PCI_ROM_RUN == 1)) +#if (CONFIG_LB_MEM_TOPK>1024) && (_RAMBASE<0x100000) && (CONFIG_CONSOLE_VGA==1) /* pgtbl is too big, so use last one 1M before CONFIG_LB_MEM_TOP, otherwise for 8 way dual core with vga support will push stack and heap cross 0xa0000, and that region need to be used as vga font buffer. Please make sure set CONFIG_LB_MEM_TOPK=2048 in MB Config diff -BNurbp LinuxBIOSv2.orig/src/stream/rom_stream.c LinuxBIOSv2/src/stream/rom_stream.c --- LinuxBIOSv2.orig/src/stream/rom_stream.c 2007-07-25 18:26:00.000000000 +0200 +++ LinuxBIOSv2/src/stream/rom_stream.c 2008-01-05 17:06:01.000000000 +0100 @@ -79,7 +79,7 @@ int stream_init(void) #if _RAMBASE<0x00100000 olen = *(unsigned int *)dest; -#if (CONFIG_CONSOLE_VGA==1) || (CONFIG_PCI_ROM_RUN == 1) +#if CONFIG_CONSOLE_VGA==1 if((dest < 0xa0000) && ((dest+olen)>0xa0000)) { dest = (CONFIG_LB_MEM_TOPK<<10); } From duwe at lst.de Sat Jan 5 17:55:45 2008 From: duwe at lst.de (Torsten Duwe) Date: Sat, 5 Jan 2008 17:55:45 +0100 Subject: [LinuxBIOS] RESEND: patch: fix the problem with CONFIG_CONSOLE_VGA not pulling in the emulator In-Reply-To: <200801051751.03058.duwe@lst.de> References: <13426df10801030937k5ffecaabndc421bbd5e0a1ce0@mail.gmail.com> <200801051742.06358.duwe@lst.de> <200801051751.03058.duwe@lst.de> Message-ID: <200801051755.46159.duwe@lst.de> Mailers... -------------- next part -------------- A non-text attachment was scrubbed... Name: VGA_ROM_RUN-2 Type: text/x-diff Size: 3624 bytes Desc: not available URL: From c-d.hailfinger.devel.2006 at gmx.net Sat Jan 5 22:32:15 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 05 Jan 2008 22:32:15 +0100 Subject: [LinuxBIOS] RESEND: patch: fix the problem with CONFIG_CONSOLE_VGA not pulling in the emulator In-Reply-To: <200801051742.06358.duwe@lst.de> References: <13426df10801030937k5ffecaabndc421bbd5e0a1ce0@mail.gmail.com> <200801051742.06358.duwe@lst.de> Message-ID: <477FF75F.80509@gmx.net> On 05.01.2008 17:42, Torsten Duwe wrote: > Here's the full story, which I'm hoping to address all related problems with. > We agreed that a VGA console and the need to run any option ROMs is mutually > not strictly dependent, Luc's problem was that LBv2 code doesn't reflect > that. There are 6 combinations: > > * Console may be on VGA or not (e.g. serial) > > _independently_ > > * LB might run > - no option ROMs > - only VGA option ROMs > - all option ROMs > I'm missing the "all option ROMs except VGA" choice for machines with a native video driver/init and some plugged-in SCSI cards. > The combination "no option ROMs" / "VGA console" currently does not compile; > Ron fixed that. > > I would now additionally introduce CONFIG_VGA_ROM_RUN, to map all 6 > combinations. The implicit (broken) assumption that CONSOLE_VGA would also > run the ROMs is lifted, and transferred to this new config option instead; > the source code becomes less ambiguous. > Agreed. How about an additional CONFIG_NONVGA_ROM_RUN? > This change is minimally intrusive, because all board configs that previously > assumed CONSOLE_VGA would also run the ROMs didn't compile, they had to also > specify PCI_ROM_RUN, so this new option only offers 2 new opportunities which > didn't work before or were impossible to specify, respectively. > > This part combines Luc's and Ron's patches, and adds the new option to > clarify. > > Signed-off-by: Torsten Duwe > This is a good start. I assume you have tested it with abuild. Please try to get another ack from Ron or Luc as well. Acked-by: Carl-Daniel Hailfinger Regards, Carl-Daniel From libv at skynet.be Sat Jan 5 22:59:14 2008 From: libv at skynet.be (Luc Verhaegen) Date: Sat, 5 Jan 2008 22:59:14 +0100 Subject: [LinuxBIOS] RESEND: patch: fix the problem with CONFIG_CONSOLE_VGA not pulling in the emulator In-Reply-To: <477FF75F.80509@gmx.net> References: <13426df10801030937k5ffecaabndc421bbd5e0a1ce0@mail.gmail.com> <200801051742.06358.duwe@lst.de> <477FF75F.80509@gmx.net> Message-ID: <20080105215914.GA26958@skynet.be> On Sat, Jan 05, 2008 at 10:32:15PM +0100, Carl-Daniel Hailfinger wrote: > > I'm missing the "all option ROMs except VGA" choice for machines with a > native video driver/init and some plugged-in SCSI cards. With native init, with the native device becoming VGA Primary, the vga rom doesn't get run, unless the native driver itself call the relevant functions, and specifies CONFIG_PCI_ROM_RUN in its Config.lb. Maybe, in V3, a way to specify which roms to run, partly during buildtime, partly through rtc cmos, could be looked into. > Agreed. How about an additional CONFIG_NONVGA_ROM_RUN? > > This is a good start. I assume you have tested it with abuild. Please > try to get another ack from Ron or Luc as well. > > Acked-by: Carl-Daniel Hailfinger It looks very good from an initial glance, but i will take a more in depth look first before ack :) Luc Verhaegen. SUSE/Novell X Driver Developer. From rminnich at gmail.com Sat Jan 5 23:11:52 2008 From: rminnich at gmail.com (ron minnich) Date: Sat, 5 Jan 2008 14:11:52 -0800 Subject: [LinuxBIOS] RESEND: patch: fix the problem with CONFIG_CONSOLE_VGA not pulling in the emulator In-Reply-To: <20080105215914.GA26958@skynet.be> References: <13426df10801030937k5ffecaabndc421bbd5e0a1ce0@mail.gmail.com> <200801051742.06358.duwe@lst.de> <477FF75F.80509@gmx.net> <20080105215914.GA26958@skynet.be> Message-ID: <13426df10801051411n3c46357dh6a31eb079822f430@mail.gmail.com> On Jan 5, 2008 1:59 PM, Luc Verhaegen wrote: > Maybe, in V3, a way to specify which roms to run, partly during > buildtime, partly through rtc cmos, could be looked into. Yes, a move to cmos control is an excellent idea. > It looks very good from an initial glance, but i will take a more in > depth look first before ack :) Thanks ron From stepan at coresystems.de Sat Jan 5 23:13:41 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 05 Jan 2008 23:13:41 +0100 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <477ED8F5.1030807@gmx.net> References: <477ED8F5.1030807@gmx.net> Message-ID: <47800115.1060301@coresystems.de> Carl-Daniel Hailfinger wrote: > Check for a terminating LAR member which tells us that no further LAR > member except the bootblock will be found after this member. > The LAR member has a normal MAGIC, but all other parts of struct > lar_header are 0xff. That way, adding a new member in place of the > terminating member will not need an erase cycle. > I don't see a gain in this. Since we know the position and size of the lar archive anyways, we know nothing will come after the bootblock. There should not be any headers that do not belong to real "files" in the lar, that would be breaking our model. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From stepan at coresystems.de Sat Jan 5 23:14:31 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 05 Jan 2008 23:14:31 +0100 Subject: [LinuxBIOS] patch a trivial error in stage1.c In-Reply-To: <13426df10801041722l342f1abata4767ba0a617cb61@mail.gmail.com> References: <13426df10801041722l342f1abata4767ba0a617cb61@mail.gmail.com> Message-ID: <47800147.3040906@coresystems.de> ron minnich wrote: > attached > > ron > Acked-by: Stefan Reinauer -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From rminnich at gmail.com Sat Jan 5 23:15:29 2008 From: rminnich at gmail.com (ron minnich) Date: Sat, 5 Jan 2008 14:15:29 -0800 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <47800115.1060301@coresystems.de> References: <477ED8F5.1030807@gmx.net> <47800115.1060301@coresystems.de> Message-ID: <13426df10801051415q69c0b3er4e6efabcdbe5c3e3@mail.gmail.com> On Jan 5, 2008 2:13 PM, Stefan Reinauer wrote: > I don't see a gain in this. Since we know the position and size of the > lar archive anyways, we know nothing will come after the bootblock. > > There should not be any headers that do not belong to real "files" in > the lar, that would be breaking our model. the issue is that, before cache is enabled, we lose many, many seconds as the lar code scans all of flash. So we need an 'end of headers' entry. We need to know when to stop scanning. more later, gotta go. ron From rminnich at gmail.com Sat Jan 5 23:23:21 2008 From: rminnich at gmail.com (ron minnich) Date: Sat, 5 Jan 2008 14:23:21 -0800 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <47800115.1060301@coresystems.de> References: <477ED8F5.1030807@gmx.net> <47800115.1060301@coresystems.de> Message-ID: <13426df10801051423h5c9426f8p549d2874359dfb09@mail.gmail.com> On Jan 5, 2008 2:13 PM, Stefan Reinauer wrote: > Carl-Daniel Hailfinger wrote: > > Check for a terminating LAR member which tells us that no further LAR > > member except the bootblock will be found after this member. > > The LAR member has a normal MAGIC, but all other parts of struct > > lar_header are 0xff. That way, adding a new member in place of the > > terminating member will not need an erase cycle. > > > I don't see a gain in this. Since we know the position and size of the > lar archive anyways, we know nothing will come after the bootblock. OK, I'm back. Stefan, we don't really need this for correctness. But on the alix1c I am observing huge delays at startup while find_file iterates through 512KB of empty FLASH looking for entries that are not there. So the goal here is to have a header which says "I'm the last one" so we can short-circuit scanning all of flash. This one change will shave quite a few seconds from boot time. > There should not be any headers that do not belong to real "files" in > the lar, that would be breaking our model. The model is fine, it's just slow. This is a performance patch.None of us anticipated the slowness of walking FLASH looking for LAR headers. thanks ron From libv at skynet.be Sat Jan 5 23:25:06 2008 From: libv at skynet.be (Luc Verhaegen) Date: Sat, 5 Jan 2008 23:25:06 +0100 Subject: [LinuxBIOS] RESEND: patch: fix the problem with CONFIG_CONSOLE_VGA not pulling in the emulator In-Reply-To: <20080105215914.GA26958@skynet.be> References: <13426df10801030937k5ffecaabndc421bbd5e0a1ce0@mail.gmail.com> <200801051742.06358.duwe@lst.de> <477FF75F.80509@gmx.net> <20080105215914.GA26958@skynet.be> Message-ID: <20080105222506.GA27116@skynet.be> On Sat, Jan 05, 2008 at 10:59:14PM +0100, Luc Verhaegen wrote: > > > Agreed. How about an additional CONFIG_NONVGA_ROM_RUN? > > > > This is a good start. I assume you have tested it with abuild. Please > > try to get another ack from Ron or Luc as well. > > > > Acked-by: Carl-Daniel Hailfinger > > It looks very good from an initial glance, but i will take a more in > depth look first before ack :) Acked-by: Luc Verhaegen From stepan at coresystems.de Sat Jan 5 23:27:29 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 05 Jan 2008 23:27:29 +0100 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <13426df10801051415q69c0b3er4e6efabcdbe5c3e3@mail.gmail.com> References: <477ED8F5.1030807@gmx.net> <47800115.1060301@coresystems.de> <13426df10801051415q69c0b3er4e6efabcdbe5c3e3@mail.gmail.com> Message-ID: <47800451.3080805@coresystems.de> ron minnich wrote: > On Jan 5, 2008 2:13 PM, Stefan Reinauer wrote: > > >> I don't see a gain in this. Since we know the position and size of the >> lar archive anyways, we know nothing will come after the bootblock. >> >> There should not be any headers that do not belong to real "files" in >> the lar, that would be breaking our model. >> > > the issue is that, before cache is enabled, we lose many, many seconds > as the lar code scans all of flash. So we need an 'end of headers' > entry. We need to know when to stop scanning. > Many seconds, though just scanning for an 8 byte signature at a 16byte aligned address? That's a max of 32k string compares for every file that is _not_ found. Otherwise the number of compares is as high as the number of files in the lar minus 1. (ie. below 10) We should fix linuxbios, so we do not look for files that are not there. rather than invent broken pseudo files. This is stuff that people will look at in 1-2 years and not understand why it went in, and someone is going to say "I don't remember but there was a nasty reason why we did it. We better keep it." -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From rminnich at gmail.com Sat Jan 5 23:29:36 2008 From: rminnich at gmail.com (ron minnich) Date: Sat, 5 Jan 2008 14:29:36 -0800 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <47800451.3080805@coresystems.de> References: <477ED8F5.1030807@gmx.net> <47800115.1060301@coresystems.de> <13426df10801051415q69c0b3er4e6efabcdbe5c3e3@mail.gmail.com> <47800451.3080805@coresystems.de> Message-ID: <13426df10801051429o44b18cd4j8f21d6dd976d7f90@mail.gmail.com> On Jan 5, 2008 2:27 PM, Stefan Reinauer wrote: > > Many seconds, though just scanning for an 8 byte signature at a 16byte > aligned address? it's depressing, but yes. It's also surprising. > > That's a max of 32k string compares for every file that is _not_ found. > Otherwise the number of compares is as high as the number of files in > the lar minus 1. (ie. below 10) no, it walks all of flash. see lib/lar.c -- or it seems to, it takes so long. > > We should fix linuxbios, so we do not look for files that are not there. > rather than invent broken pseudo files. works for me ... how? ron From stepan at coresystems.de Sat Jan 5 23:40:19 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 05 Jan 2008 23:40:19 +0100 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <13426df10801051429o44b18cd4j8f21d6dd976d7f90@mail.gmail.com> References: <477ED8F5.1030807@gmx.net> <47800115.1060301@coresystems.de> <13426df10801051415q69c0b3er4e6efabcdbe5c3e3@mail.gmail.com> <47800451.3080805@coresystems.de> <13426df10801051429o44b18cd4j8f21d6dd976d7f90@mail.gmail.com> Message-ID: <47800753.6020900@coresystems.de> ron minnich wrote: > On Jan 5, 2008 2:27 PM, Stefan Reinauer wrote: > >> Many seconds, though just scanning for an 8 byte signature at a 16byte >> aligned address? >> > > it's depressing, but yes. It's also surprising. > > >> That's a max of 32k string compares for every file that is _not_ found. >> Otherwise the number of compares is as high as the number of files in >> the lar minus 1. (ie. below 10) >> > > no, it walks all of flash. see lib/lar.c -- or it seems to, it takes so long. > I can't find the behavior you describe in find_file(). It returns as soon as the file is found. Your delay must come from some other issue. I suspect we are looking for files that are not there yet. Probably some normal/fallback stuff that our makefiles don't do yet, but stage1.c does. We should not look for fallback files if we don't compile any. Or, we just add an "empty" lar with a correct header containing all of 0xff, having a correct size etc. Then we don't use pseudo headers at least. But this would break our design idea to allow files with holes in them so this should really be the last resort. Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From rminnich at gmail.com Sat Jan 5 23:44:55 2008 From: rminnich at gmail.com (ron minnich) Date: Sat, 5 Jan 2008 14:44:55 -0800 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <47800753.6020900@coresystems.de> References: <477ED8F5.1030807@gmx.net> <47800115.1060301@coresystems.de> <13426df10801051415q69c0b3er4e6efabcdbe5c3e3@mail.gmail.com> <47800451.3080805@coresystems.de> <13426df10801051429o44b18cd4j8f21d6dd976d7f90@mail.gmail.com> <47800753.6020900@coresystems.de> Message-ID: <13426df10801051444y5ca97762xd67c07783a9af478@mail.gmail.com> On Jan 5, 2008 2:40 PM, Stefan Reinauer wrote: > I can't find the behavior you describe in find_file(). It returns as > soon as the file is found. Your delay must come from some other issue. it comes when a file is NOT found, which can happen. > I suspect we are looking for files that are not there yet. Probably some > normal/fallback stuff that our makefiles don't do yet, but stage1.c > does. We should not look for fallback files if we don't compile any. you can't count on that .Suppose somebody builds a bios with fallback files, and then removes them later. And then adds them back. that's the beauty of lar -- we can change things. NOT finding a file should be efficient. Also, the code looks for payload/segment0, 1, 2, and stops when no more are found. That 'not found' really takes time. And, we can't compile this in -- payloads can change too, and the # segments can change. So we need an efficient way to terminate the search. Carl-Daniel's idea is not too bad. ron From r.marek at assembler.cz Sun Jan 6 01:16:39 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Sun, 06 Jan 2008 01:16:39 +0100 Subject: [LinuxBIOS] [PATCH] document the GPIO setup of A8V-E and fix power sequencing for suspend Message-ID: <47801DE7.3020205@assembler.cz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Attached patch documents the GPIO setup of the board (check board wiki page) and fixes the W83627EHF settings for suspend. Signed-off-by: Rudolf Marek Thanks, Rudolf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHgB3n3J9wPJqZRNURAqEWAJ9xjgUJLuOu4+71eUIx+XR37lPyRQCgyy/o /GF966Lx1IMR4yLm+p3Y9rA= =YGr3 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_gpio_susp.patch Type: text/x-patch Size: 3971 bytes Desc: not available URL: From peter at stuge.se Sun Jan 6 02:00:01 2008 From: peter at stuge.se (Peter Stuge) Date: Sun, 6 Jan 2008 02:00:01 +0100 Subject: [LinuxBIOS] empty payload In-Reply-To: <13426df10801041659k3448eb91p10259b1c245b7cd1@mail.gmail.com> References: <13426df10801041659k3448eb91p10259b1c245b7cd1@mail.gmail.com> Message-ID: <20080106010001.18807.qmail@stuge.se> On Fri, Jan 04, 2008 at 04:59:54PM -0800, ron minnich wrote: > I am wondering about making it part of v3 tree. Just make an > emptypayload directory. This would make testing easier. > > I don't know, comments? It will eventually become the panic room, right? ;) //Peter From svn at openbios.org Sun Jan 6 02:10:54 2008 From: svn at openbios.org (svn at openbios.org) Date: Sun, 6 Jan 2008 02:10:54 +0100 Subject: [LinuxBIOS] r3034 - in trunk/LinuxBIOSv2/src: config devices Message-ID: Author: duwe Date: 2008-01-06 02:10:54 +0100 (Sun, 06 Jan 2008) New Revision: 3034 Modified: trunk/LinuxBIOSv2/src/config/Options.lb trunk/LinuxBIOSv2/src/devices/Config.lb trunk/LinuxBIOSv2/src/devices/pci_device.c Log: Since a VGA console and the need to run any option ROMs are rather independent, lift the implicit (broken) assumption that CONSOLE_VGA would also run the ROMs, and transfer it to a new config option VGA_ROM_RUN. This change is minimally intrusive, because all board configs that previously assumed CONSOLE_VGA would also run the ROMs didn't compile, they had to also specify PCI_ROM_RUN. Based on patches by Ron Minnich (fix the compile) and Luc Verhaegen (separate ROM_RUN from VGA console). Signed-off-by: Torsten Duwe Acked-by: Carl-Daniel Hailfinger Acked-by: Luc Verhaegen Modified: trunk/LinuxBIOSv2/src/config/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/config/Options.lb 2008-01-04 17:22:44 UTC (rev 3033) +++ trunk/LinuxBIOSv2/src/config/Options.lb 2008-01-06 01:10:54 UTC (rev 3034) @@ -415,7 +415,7 @@ define CONFIG_CONSOLE_VGA default 0 export always - comment "Log messages to VGA" + comment "Log messages to any VGA-compatible device (may require *_ROM_RUN to bring up)" end define CONFIG_CONSOLE_VGA_MULTI default 0 @@ -1027,10 +1027,16 @@ comment "CPU hardware address lines num, for AMD K8 could be 40, and AMD family 10 could be 48" end +define CONFIG_VGA_ROM_RUN + default 0 + export always + comment "Init x86 ROMs on VGA-class PCI devices" +end + define CONFIG_PCI_ROM_RUN default 0 export always - comment "Init PCI device option rom" + comment "Init x86 ROMs on all PCI devices" end define CONFIG_PCI_64BIT_PREF_MEM Modified: trunk/LinuxBIOSv2/src/devices/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/devices/Config.lb 2008-01-04 17:22:44 UTC (rev 3033) +++ trunk/LinuxBIOSv2/src/devices/Config.lb 2008-01-06 01:10:54 UTC (rev 3034) @@ -1,4 +1,5 @@ uses CONFIG_PCI_ROM_RUN +uses CONFIG_VGA_ROM_RUN object device.o object root_device.o object device_util.o @@ -15,4 +16,9 @@ if CONFIG_PCI_ROM_RUN object pci_rom.o dir emulator +else +if CONFIG_VGA_ROM_RUN + object pci_rom.o + dir emulator end +end Modified: trunk/LinuxBIOSv2/src/devices/pci_device.c =================================================================== --- trunk/LinuxBIOSv2/src/devices/pci_device.c 2008-01-04 17:22:44 UTC (rev 3033) +++ trunk/LinuxBIOSv2/src/devices/pci_device.c 2008-01-06 01:10:54 UTC (rev 3034) @@ -643,16 +643,14 @@ ((device & 0xffff) << 16) | (vendor & 0xffff)); } +/** default handler: only runs the relevant pci bios. */ void pci_dev_init(struct device *dev) { -#if CONFIG_CONSOLE_VGA == 1 - extern int vga_inited; -#endif -#if CONFIG_PCI_ROM_RUN == 1 || CONFIG_CONSOLE_VGA == 1 +#if CONFIG_PCI_ROM_RUN == 1 || CONFIG_VGA_ROM_RUN == 1 struct rom_header *rom, *ram; #if CONFIG_PCI_ROM_RUN != 1 - /* We want to execute VGA option ROMs when CONFIG_CONSOLE_VGA + /* We want to execute VGA option ROMs when CONFIG_VGA_ROM_RUN * is set but CONFIG_PCI_ROM_RUN is not. In this case we skip * all other option ROM types. */ @@ -671,14 +669,13 @@ run_bios(dev, ram); #if CONFIG_CONSOLE_VGA == 1 - /* vga_inited is a trigger of the VGA console code. - * - * Only set it if we enabled VGA console, and if we - * just initialized a VGA card. - */ - vga_inited|=dev->class==PCI_CLASS_DISPLAY_VGA; -#endif -#endif + /* vga_inited is a trigger of the VGA console code. */ + if (dev->class == PCI_CLASS_DISPLAY_VGA) { + extern int vga_inited; + vga_inited = 1; + } +#endif /* CONFIG_CONSOLE_VGA */ +#endif /* CONFIG_PCI_ROM_RUN || CONFIG_VGA_ROM_RUN */ } /** Default device operation for PCI devices */ From peter at stuge.se Sun Jan 6 02:11:52 2008 From: peter at stuge.se (Peter Stuge) Date: Sun, 6 Jan 2008 02:11:52 +0100 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <13426df10801051444y5ca97762xd67c07783a9af478@mail.gmail.com> References: <477ED8F5.1030807@gmx.net> <47800115.1060301@coresystems.de> <13426df10801051415q69c0b3er4e6efabcdbe5c3e3@mail.gmail.com> <47800451.3080805@coresystems.de> <13426df10801051429o44b18cd4j8f21d6dd976d7f90@mail.gmail.com> <47800753.6020900@coresystems.de> <13426df10801051444y5ca97762xd67c07783a9af478@mail.gmail.com> Message-ID: <20080106011152.21774.qmail@stuge.se> On Sat, Jan 05, 2008 at 02:44:55PM -0800, ron minnich wrote: > NOT finding a file should be efficient. Yes. Where do the delay come from? Can anyone measure the LPC? //Peter From peter at stuge.se Sun Jan 6 02:12:46 2008 From: peter at stuge.se (Peter Stuge) Date: Sun, 6 Jan 2008 02:12:46 +0100 Subject: [LinuxBIOS] r3034 - in trunk/LinuxBIOSv2/src: config devices Message-ID: <20080106011246.21988.qmail@stuge.se> On Sun, Jan 06, 2008 at 02:10:54AM +0100, svn at openbios.org wrote: > Author: duwe > Date: 2008-01-06 02:10:54 +0100 (Sun, 06 Jan 2008) > New Revision: 3034 What about all the boards that this affects? //Peter From duwe at lst.de Sun Jan 6 02:19:41 2008 From: duwe at lst.de (Torsten Duwe) Date: Sun, 6 Jan 2008 02:19:41 +0100 Subject: [LinuxBIOS] =?iso-8859-1?q?RESEND=3A_patch=3A_fix_the_problem_wit?= =?iso-8859-1?q?h=09CONFIG=5FCONSOLE=5FVGA_not_pulling_in_the_emula?= =?iso-8859-1?q?tor?= In-Reply-To: <20080105222506.GA27116@skynet.be> References: <13426df10801030937k5ffecaabndc421bbd5e0a1ce0@mail.gmail.com> <20080105215914.GA26958@skynet.be> <20080105222506.GA27116@skynet.be> Message-ID: <200801060219.42021.duwe@lst.de> On Saturday 05 January 2008, Luc Verhaegen wrote: > On Sat, Jan 05, 2008 at 10:59:14PM +0100, Luc Verhaegen wrote: > > > Agreed. How about an additional CONFIG_NONVGA_ROM_RUN? > > > > > > This is a good start. I assume you have tested it with abuild. Please Since I don't touch any board specifics, I checked 3 of the 4 old config combinations on my working target to make sure it does not break anything. But abuild didn't show anything either now. > > > try to get another ack from Ron or Luc as well. > > > > > > Acked-by: Carl-Daniel Hailfinger > > > > It looks very good from an initial glance, but i will take a more in > > depth look first before ack :) > > Acked-by: Luc Verhaegen Thanks, revision 3034. *Please* also look at part 2 of the patch I followed up with. These are ambiguous parts of the code I spotted, and am unsure what is meant there. I assume it's about VGA resource allocation, namely 0xA0000 to 0xBFFFF memory getting into the way of AP stacks, which would clearly depend on CONSOLE_VGA, and no ROM_RUNs From duwe at lst.de Sun Jan 6 02:27:40 2008 From: duwe at lst.de (Torsten Duwe) Date: Sun, 6 Jan 2008 02:27:40 +0100 Subject: [LinuxBIOS] r3034 - in trunk/LinuxBIOSv2/src: config devices In-Reply-To: <20080106011246.21988.qmail@stuge.se> References: <20080106011246.21988.qmail@stuge.se> Message-ID: <200801060227.41023.duwe@lst.de> On Sunday 06 January 2008, Peter Stuge wrote: > On Sun, Jan 06, 2008 at 02:10:54AM +0100, svn at openbios.org wrote: > > Author: duwe > > Date: 2008-01-06 02:10:54 +0100 (Sun, 06 Jan 2008) > > New Revision: 3034 > > What about all the boards that this affects? All boards that might have CONSOLE_VGA and not PCI_ROM_RUN currently wouldn't compile, so all compiling boards have both, or no VGA console. From now on, you _can_ specify to only run VGA option ROMs, and independently whether you want output to VGA. You can now create new configs (like Luc), or change old ones finer grained. HTH, Torsten From peter at stuge.se Sun Jan 6 02:47:03 2008 From: peter at stuge.se (Peter Stuge) Date: Sun, 6 Jan 2008 02:47:03 +0100 Subject: [LinuxBIOS] r3034 - in trunk/LinuxBIOSv2/src: config devices In-Reply-To: <200801060227.41023.duwe@lst.de> References: <20080106011246.21988.qmail@stuge.se> <200801060227.41023.duwe@lst.de> Message-ID: <20080106014703.29951.qmail@stuge.se> On Sun, Jan 06, 2008 at 02:27:40AM +0100, Torsten Duwe wrote: > > What about all the boards that this affects? > > All boards that might have CONSOLE_VGA and not PCI_ROM_RUN > currently wouldn't compile, so all compiling boards have both, or no > VGA console. Right, thanks for clarifying. //Peter From info at coresystems.de Sun Jan 6 02:57:13 2008 From: info at coresystems.de (LinuxBIOS information) Date: Sun, 06 Jan 2008 02:57:13 +0100 Subject: [LinuxBIOS] r3034 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "duwe" checked in revision 3034 to the LinuxBIOS source repository and caused the following changes: Change Log: Since a VGA console and the need to run any option ROMs are rather independent, lift the implicit (broken) assumption that CONSOLE_VGA would also run the ROMs, and transfer it to a new config option VGA_ROM_RUN. This change is minimally intrusive, because all board configs that previously assumed CONSOLE_VGA would also run the ROMs didn't compile, they had to also specify PCI_ROM_RUN. Based on patches by Ron Minnich (fix the compile) and Luc Verhaegen (separate ROM_RUN from VGA console). Signed-off-by: Torsten Duwe Acked-by: Carl-Daniel Hailfinger Acked-by: Luc Verhaegen Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3034&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in duwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From peter at stuge.se Sun Jan 6 03:14:40 2008 From: peter at stuge.se (Peter Stuge) Date: Sun, 6 Jan 2008 03:14:40 +0100 Subject: [LinuxBIOS] Fwd: Possible stack protect solutions (RESEND) In-Reply-To: <13426df10801030930u4a8b1ef7m5db8ecd8d89b3297@mail.gmail.com> References: <13426df10801030825q634ce66fsb3ed6389158fbb71@mail.gmail.com> <20080103171258.GA22798@coresystems.de> <13426df10801030930u4a8b1ef7m5db8ecd8d89b3297@mail.gmail.com> Message-ID: <20080106021440.3415.qmail@stuge.se> On Thu, Jan 03, 2008 at 09:30:06AM -0800, ron minnich wrote: > Add the ability to extend CFLAGS as needed for several new distros > Signed-off-by: Ronald G. Minnich Acked-by: Peter Stuge > Index: targets/buildtarget > =================================================================== > --- targets/buildtarget (revision 3031) > +++ targets/buildtarget (working copy) > @@ -53,4 +53,25 @@ > export PYTHONPATH=$config_dir > $PYTHON $config_py $config_lb $lbpath > > +# now start checking for distro-specific breakage. > +## This check is for the no stack protector mess. > +EXTRA_CFLAGS= > + > +if [ -z "$CC" ]; then > + CC=gcc > +fi > + > +$CC -fno-stack-protector -S -xc /dev/null -o .$$.tmp > + > +if [ $? -eq 0 ]; then > + EXTRA_CFLAGS=-fno-stack-protector > +fi > + > +rm -rf .$$.tmp > + > +for i in $build_dir/Makefile.settings $build_dir/*/Makefile.settings > +do > + echo CFLAGS+=$EXTRA_CFLAGS >>$i > +done > + > exit $? From rminnich at gmail.com Sun Jan 6 05:52:49 2008 From: rminnich at gmail.com (ron minnich) Date: Sat, 5 Jan 2008 20:52:49 -0800 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <20080106011152.21774.qmail@stuge.se> References: <477ED8F5.1030807@gmx.net> <47800115.1060301@coresystems.de> <13426df10801051415q69c0b3er4e6efabcdbe5c3e3@mail.gmail.com> <47800451.3080805@coresystems.de> <13426df10801051429o44b18cd4j8f21d6dd976d7f90@mail.gmail.com> <47800753.6020900@coresystems.de> <13426df10801051444y5ca97762xd67c07783a9af478@mail.gmail.com> <20080106011152.21774.qmail@stuge.se> Message-ID: <13426df10801052052q416a8532g72e8478190763bfa@mail.gmail.com> On Jan 5, 2008 5:11 PM, Peter Stuge wrote: > On Sat, Jan 05, 2008 at 02:44:55PM -0800, ron minnich wrote: > > NOT finding a file should be efficient. > > Yes. > > Where do the delay come from? Can anyone measure the LPC? I will try to measure for you but remember it is running uncached. Each and every access is a full LPC cycle, which is not really fast. ron From rminnich at gmail.com Sun Jan 6 06:04:51 2008 From: rminnich at gmail.com (ron minnich) Date: Sat, 5 Jan 2008 21:04:51 -0800 Subject: [LinuxBIOS] [PATCH] document the GPIO setup of A8V-E and fix power sequencing for suspend In-Reply-To: <47801DE7.3020205@assembler.cz> References: <47801DE7.3020205@assembler.cz> Message-ID: <13426df10801052104j779e460dmb87d41ae2059f1d7@mail.gmail.com> On Jan 5, 2008 4:16 PM, Rudolf Marek wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > Attached patch documents the GPIO setup of the board (check board wiki page) and > fixes the W83627EHF settings for suspend. > > Signed-off-by: Rudolf Marek > You might want one other acked by but, that said, I think this is a really excellent patch. Acked-by: Ronald G. Minnich From stepan at coresystems.de Sun Jan 6 12:29:46 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 6 Jan 2008 12:29:46 +0100 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <13426df10801051423h5c9426f8p549d2874359dfb09@mail.gmail.com> References: <477ED8F5.1030807@gmx.net> <47800115.1060301@coresystems.de> <13426df10801051423h5c9426f8p549d2874359dfb09@mail.gmail.com> Message-ID: <20080106112946.GA31641@coresystems.de> * ron minnich [080105 23:23]: > OK, I'm back. Stefan, we don't really need this for correctness. But > on the alix1c I am observing huge delays at startup while find_file > iterates through 512KB of empty FLASH looking > for entries that are not there. So the goal here is to have a header > which says "I'm the last one" so we can short-circuit scanning all of > flash. This one change will shave quite a few seconds from boot time. And we can't cache the ROM because of CAR? I am not convinced that failing to find files has to be a performance critical path - While I generally agree it must not take several seconds, something's wrong with our logic if we fail to find files before we have RAM and Cache enabled. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From stepan at coresystems.de Sun Jan 6 13:00:53 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 6 Jan 2008 13:00:53 +0100 Subject: [LinuxBIOS] Suspend to RAM with LinuxBIOSv2 In-Reply-To: <477ED92C.4030300@assembler.cz> References: <477ED92C.4030300@assembler.cz> Message-ID: <20080106120053.GA12539@coresystems.de> * Rudolf Marek [080105 02:11]: > I'm pleased to announce that I got S3 working with LinuxBIOSv2 on ASUS A8V-E SE > (K8 + VT8237 + K8T890)! Rudolf, this is wonderful! Thank you very much for your work! > 1) consolidate the memory usage of LinuxBIOSv2 What needs to be done here? > 2) dont clean arbitrary memory This should at least be the case when waking up from S3. > Perhaps we could reserve last 1MB of RAM or something after 8MB of mem and put > linuxBIOS heap there when using S3 we would just reserve the region + (some > region bellow the 1MB for AP CPU boot + ACPI tables etc) Sounds reasonable. How do others do this? > The patch has some errata update of code too, I will publish this as separate > patch - I did it because I thought I got still some memory related problem. Thank you. > Index: src/mainboard/asus/a8v-e_se/dsdt.asl > =================================================================== > --- src/mainboard/asus/a8v-e_se/dsdt.asl (revision 2978) > +++ src/mainboard/asus/a8v-e_se/dsdt.asl (working copy) > @@ -44,6 +179,7 @@ > */ > Name (\_S0, Package () {0x00, 0x00, 0x00, 0x00 }) > Name (\_S5, Package () {0x02, 0x02, 0x00, 0x00 }) > + Name (\_S3, Package () {0x01, 0x01, 0x00, 0x00 }) > > /* Root of the bus hierarchy */ > Scope (\_SB) How nice ACPI _can_ be :) > Index: src/mainboard/asus/a8v-e_se/wakeup.c > =================================================================== > --- src/mainboard/asus/a8v-e_se/wakeup.c (revision 0) > +++ src/mainboard/asus/a8v-e_se/wakeup.c (revision 0) > @@ -0,0 +1,267 @@ > +//reboot.c from linux > + > +#include > +#include > +#include > +#include > + [..] A quick glimpse tells me that wakeup.c is mostly x86 generic code. We should put it somewhere else. Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From duwe at lst.de Sun Jan 6 15:01:47 2008 From: duwe at lst.de (Torsten Duwe) Date: Sun, 6 Jan 2008 15:01:47 +0100 Subject: [LinuxBIOS] [PATCH] beautify m57sli mptable.c (Was: Fix FireWire...) In-Reply-To: <200712211823.27392.duwe@lst.de> References: <200712172314.37483.duwe@lst.de> <13426df10712200923n734958c4q4224f89cd8eac09e@mail.gmail.com> <200712211823.27392.duwe@lst.de> Message-ID: <200801061501.47959.duwe@lst.de> I still owe you a beautification patch. On Thursday 20 December 2007, ron minnich wrote: > Hi Torsten, why not add the comments and readable indentation right > now? once it is committed, it won't happen :-) It's not indentation. I found the extra long lines and useless comments extremely ugly and obfuscating. This patch would again qualify as trivial by Russ' definition, but coding style matters so I want to bring this to discussion. IMO this is what preprocessor macros were invented for. We now have bus,dev,fn tuples together, and can easily see that 1:0a.0 maps to "pin" 18. Removing all that redundant blurb also makes room for meaningful comments 8-) Signed-off-by: Torsten Duwe -------------- next part -------------- A non-text attachment was scrubbed... Name: beautify-mptable Type: text/x-diff Size: 5375 bytes Desc: not available URL: From c-d.hailfinger.devel.2006 at gmx.net Sun Jan 6 17:17:31 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 06 Jan 2008 17:17:31 +0100 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <13426df10801052052q416a8532g72e8478190763bfa@mail.gmail.com> References: <477ED8F5.1030807@gmx.net> <47800115.1060301@coresystems.de> <13426df10801051415q69c0b3er4e6efabcdbe5c3e3@mail.gmail.com> <47800451.3080805@coresystems.de> <13426df10801051429o44b18cd4j8f21d6dd976d7f90@mail.gmail.com> <47800753.6020900@coresystems.de> <13426df10801051444y5ca97762xd67c07783a9af478@mail.gmail.com> <20080106011152.21774.qmail@stuge.se> <13426df10801052052q416a8532g72e8478190763bfa@mail.gmail.com> Message-ID: <4780FF1B.2010308@gmx.net> On 06.01.2008 05:52, ron minnich wrote: > On Jan 5, 2008 5:11 PM, Peter Stuge wrote: > >> On Sat, Jan 05, 2008 at 02:44:55PM -0800, ron minnich wrote: >> >>> NOT finding a file should be efficient. >>> >> Yes. >> >> Where do the delay come from? Can anyone measure the LPC? >> > > I will try to measure for you but remember it is running uncached. > Each and every access is a full LPC cycle, which is not really fast. > IIRC the PCEngines alix.1c has parallel flash, so the following does not apply to our current problem. However, for all boards with LPC-to-SPI translation through a IT8716F Super I/O chip, the following applies: My calculations suggest that for optimal reads (4 bytes at a 4 byte boundary) with the IT8716F SPI translation function, we need (1 byte opcode + 3 bytes addr + 4 bytes data)* 8 = 64 clock cycles on the SPI bus alone. With a maximum of 33 MHz for the SPI clock on that particular chip (MUST verify that the chip is set to 33 MHz and not 16 MHz!), this optimal read takes 2 usec. Smaller reads take at least 1.25 usec. On top of the pure SPI bus time we have to add the time to transmit and receive that data over LPC. In case we don't use the automatic LPC-to-SPI translation and use the embedded SPI controller directly, the LPC overhead is replaced by 6+ ISA port byte reads and 5 ISA port byte writes, which is probably even slower. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Sun Jan 6 17:26:07 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 06 Jan 2008 17:26:07 +0100 Subject: [LinuxBIOS] [PATCH] beautify m57sli mptable.c (Was: Fix FireWire...) In-Reply-To: <200801061501.47959.duwe@lst.de> References: <200712172314.37483.duwe@lst.de> <13426df10712200923n734958c4q4224f89cd8eac09e@mail.gmail.com> <200712211823.27392.duwe@lst.de> <200801061501.47959.duwe@lst.de> Message-ID: <4781011F.1080309@gmx.net> On 06.01.2008 15:01, Torsten Duwe wrote: > I still owe you a beautification patch. > > On Thursday 20 December 2007, ron minnich wrote: > >> Hi Torsten, why not add the comments and readable indentation right >> now? once it is committed, it won't happen :-) >> > > It's not indentation. I found the extra long lines and useless comments > extremely ugly and obfuscating. > > This patch would again qualify as trivial by Russ' definition, but coding > style matters so I want to bring this to discussion. IMO this is what > preprocessor macros were invented for. We now have bus,dev,fn tuples > together, and can easily see that 1:0a.0 maps to "pin" 18. Removing all that > redundant blurb also makes room for meaningful comments 8-) > > Signed-off-by: Torsten Duwe > This is a much needed simplification and readability improvement. Thanks! Generated code seems to be unchanged. If you drop the #undef lines (or explain why we absolutely need them), you can take the ack from below. Acked-by: Carl-Daniel Hailfinger Bonus points if you manage to convert all mptable.c files for MCP55 (or even, if that task is not too daring, all mptable.c files). MCP55 mptable.c would be: src/mainboard/msi/ms7260/mptable.c src/mainboard/msi/ms9282/mptable.c src/mainboard/tyan/s2912/mptable.c src/mainboard/supermicro/h8dmr/mptable.c src/mainboard/nvidia/l1_2pvv/mptable.c src/mainboard/gigabyte/m57sli/mptable.c Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Sun Jan 6 18:32:10 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 06 Jan 2008 18:32:10 +0100 Subject: [LinuxBIOS] [RFC] Macros vs. functions for better readability Message-ID: <4781109A.7000905@gmx.net> Hi, it seems we sometimes have lots of repetitive code sequences which could be simplified by use of macros or functions. For a really shining example see Torsten Duwe's recent patch titled "beautify m57sli mptable.c". Cut-and-paste errors can happen and eliminating repetitive code reduces the risk of such errors. Besides that, having code with shorter lines through factoring out open-coded functions makes understanding the code easier. How do we factor out such code? I prefer macros for simple function wrappers and functions for multiline sequences. Comments? Regards, Carl-Daniel From r.marek at assembler.cz Sun Jan 6 19:06:02 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Sun, 06 Jan 2008 19:06:02 +0100 Subject: [LinuxBIOS] Suspend to RAM with LinuxBIOSv2 In-Reply-To: <20080106120053.GA12539@coresystems.de> References: <477ED92C.4030300@assembler.cz> <20080106120053.GA12539@coresystems.de> Message-ID: <4781188A.6070608@assembler.cz> Hi, > this is wonderful! Thank you very much for your work! Yeah I'm happy that it works too. It costs me lot of time and I would rather win then lose ;) I'm taking this as broading up my know-how. It goes well because I got nearly all datasheets for all chips on the board except the marvel gigabit controller. I have in plan to add overclocking options, because I know how they work on this board - its on wiki now. >> 1) consolidate the memory usage of LinuxBIOSv2 > What needs to be done here? Well I think secondary CPUS (APs) are started by some code (secondary.S) Which is loaded to some location.Plus for example all memory from 0K-1M is clean etc etc. For S3 we cant act "as an elephant in the pottery" >> 2) dont clean arbitrary memory > > This should at least be the case when waking up from S3. Well we should just clean our heap, without the purge, resource management gets hoosed for some reason. We should not touch all the memory, only to defined regions. We are missing the "reserved" memory infrastructure in LB. For the mmconfig and also for S3 we should pass via LB tables parts of memory which are reserved, and then build e820 based map on in in filo/grub. > >> Perhaps we could reserve last 1MB of RAM or something after 8MB of mem and put >> linuxBIOS heap there when using S3 we would just reserve the region + (some >> region bellow the 1MB for AP CPU boot + ACPI tables etc) > > Sounds reasonable. How do others do this? Award is reserving last 1MB of memory for its SMM/resume handler. LB is not relocatable, and ACPI specs says reserved memory can start at 8MB. Or we can try to put all linuxbios and its heap to A0000-FFFFF if we want to support the S3. (we can switch on VGA when we are done with heap). My system has fairly lot of devices, so I need lot of heap memory. I can try to measure how much actually (I'm using 256K now). I dont know if 384KB is enough for all the code. Maybe we can just move everything to 1MB somewhere in system RAM, but question is if APs can be started on 1MB above (this needs to be checked) >> The patch has some errata update of code too, I will publish this as separate >> patch - I did it because I thought I got still some memory related problem. > > Thank you. I will try to publish it in near future. > > How nice ACPI _can_ be :) Well some parts still missing and ACPI core in Linux is bit complaining: sd 0:0:0:0: [sda] Stopping disk ACPI: PCI interrupt for device 0000:06:00.0 disabled sky2 eth0: disabling interface ACPI handle has no context! ACPI handle has no context! ACPI: PCI interrupt for device 0000:00:11.5 disabled ACPI handle has no context! ACPI: PCI interrupt for device 0000:00:10.4 disabled ACPI: PCI interrupt for device 0000:00:10.3 disabled ACPI: PCI interrupt for device 0000:00:10.2 disabled ACPI: PCI interrupt for device 0000:00:10.1 disabled ACPI: PCI interrupt for device 0000:00:10.0 disabled ACPI: PCI interrupt for device 0000:00:0f.1 disabled ACPI: PCI interrupt for device 0000:00:0f.0 disabled ACPI handle has no context! pci_set_power_state(): 0000:00:00.0: state=3, current state=5 Disabling non-boot CPUs ... But it works fine. The difference between full off and S3 is just one Watt ;) so everything is shut off. For specific wakeups some ACPI AML code should be added. I'm waking up system with power button. > >> Index: src/mainboard/asus/a8v-e_se/wakeup.c >> =================================================================== >> --- src/mainboard/asus/a8v-e_se/wakeup.c (revision 0) >> +++ src/mainboard/asus/a8v-e_se/wakeup.c (revision 0) >> @@ -0,0 +1,267 @@ >> +//reboot.c from linux >> + >> +#include >> +#include >> +#include >> +#include >> + > > [..] > > A quick glimpse tells me that wakeup.c is mostly x86 generic code. We > should put it somewhere else. Yeah, that patch is quite experimental so I put it to that dir. Better layout of systems calls needs to be proposed/implemented. Rudolf From r.marek at assembler.cz Sun Jan 6 19:10:36 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Sun, 06 Jan 2008 19:10:36 +0100 Subject: [LinuxBIOS] [PATCH] document the GPIO setup of A8V-E and fix power sequencing for suspend In-Reply-To: <13426df10801052104j779e460dmb87d41ae2059f1d7@mail.gmail.com> References: <47801DE7.3020205@assembler.cz> <13426df10801052104j779e460dmb87d41ae2059f1d7@mail.gmail.com> Message-ID: <4781199C.7040802@assembler.cz> > You might want one other acked by but, that said, I think this is a > really excellent patch. Well nope the other one is just experimental, showing how it is done. It might be useful for v3 development. Hum this patch has one minor glitch in the comment /* set memory voltage to 2.75V chipset voltage, vcore offset + 100mV, 1.5V Chipset voltage */ Should be without the first "chipset voltage" (and this is there 2 times). So I guess it is not good at all :) Or maybe even the whole SIO setup should deserve one function :) ? Rudolf From rminnich at gmail.com Sun Jan 6 20:29:58 2008 From: rminnich at gmail.com (ron minnich) Date: Sun, 6 Jan 2008 11:29:58 -0800 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <20080106112946.GA31641@coresystems.de> References: <477ED8F5.1030807@gmx.net> <47800115.1060301@coresystems.de> <13426df10801051423h5c9426f8p549d2874359dfb09@mail.gmail.com> <20080106112946.GA31641@coresystems.de> Message-ID: <13426df10801061129k202bf432gca91b051a3399813@mail.gmail.com> On Jan 6, 2008 3:29 AM, Stefan Reinauer wrote: > And we can't cache the ROM because of CAR? yes. > > I am not convinced that failing to find files has to be a performance > critical path - While I generally agree it must not take several > seconds, something's wrong with our logic if we fail to find files > before we have RAM and Cache enabled. I think we should eliminate all unnnecessary overhead. Scanning (e.g.) 2 Mbytes of memory for each failed lookup -- all the other BIOSes are going to point at us and make rude comments :-) I really would like us to have a reasonable termination instead of searching all of memory. It can be anything -- make a file name called EOF. Carl-Daniel's design was nice because it was very flash-friendly, but I'm not picky. thanks ron From rminnich at gmail.com Sun Jan 6 20:49:13 2008 From: rminnich at gmail.com (ron minnich) Date: Sun, 6 Jan 2008 11:49:13 -0800 Subject: [LinuxBIOS] [RFC] Macros vs. functions for better readability In-Reply-To: <4781109A.7000905@gmx.net> References: <4781109A.7000905@gmx.net> Message-ID: <13426df10801061149p2f54c09ledf50f6aa39a3552@mail.gmail.com> On Jan 6, 2008 9:32 AM, Carl-Daniel Hailfinger wrote: > How do we factor out such code? I prefer macros for simple function > wrappers and functions for multiline sequences. I spend a lot of time with Plan 9 code nowadays. These are the Bell Labs guys who invented it all. I am (re)-learning a lot about style. The Plan 9 code is so clean and sparse, it' s a real joy to read. I think macros are OK for bits like convenience in struct deref and such things. Spin locks and stuff like outb maybe make sense too. I think the value of putting a one line function into a macro is over-rated. It can badly bloat the code, in unexpected ways, And, look at linux nowadays: lots of code living in .h files, making it a real headache to figure out where things get done. So I vote for your code cleanup idea, but I'd like to see it weighed in favor of functions, unless a macro is somehow absolutely essential. Thanks, it is a great idea, don't let me sound discouraging! The only question is, should we be really trying to apply this lesson to V3? ron From juergen127 at kreuzholzen.de Sun Jan 6 22:43:54 2008 From: juergen127 at kreuzholzen.de (Juergen Beisert) Date: Sun, 6 Jan 2008 22:43:54 +0100 Subject: [LinuxBIOS] [RFC] Macros vs. functions for better readability In-Reply-To: <4781109A.7000905@gmx.net> References: <4781109A.7000905@gmx.net> Message-ID: <200801062243.54719.juergen127@kreuzholzen.de> On Sunday 06 January 2008 18:32, Carl-Daniel Hailfinger wrote: > How do we factor out such code? I prefer macros for simple function > wrappers and functions for multiline sequences. As we are working with hardware we should avoid any macros for function replacement. There are ugly side effects. Refer the getCx86()/setCx86() disaster in the kernel for Geode-GX1 chipset programming: What wrong with that? #define getCx86(reg) ({ outb((reg), 0x22); inb(0x23); }) #define setCx86(reg, data) do { \ outb((reg), 0x22); \ outb((data), 0x23); \ } while (0) This works: x = getCx86(0x20); x |= 0x01; setCx86(0x20, x); This fails badly: setCx86(0x20, getCx86(0x20) | 0x01); getCx86 and setCx86 defined as inline functions are working in all cases. So: Do not use macros as functions. Juergen From rminnich at gmail.com Sun Jan 6 23:41:03 2008 From: rminnich at gmail.com (ron minnich) Date: Sun, 6 Jan 2008 14:41:03 -0800 Subject: [LinuxBIOS] [RFC] Macros vs. functions for better readability In-Reply-To: <200801062243.54719.juergen127@kreuzholzen.de> References: <4781109A.7000905@gmx.net> <200801062243.54719.juergen127@kreuzholzen.de> Message-ID: <13426df10801061441m39d71b6djeb63d05c155ba113@mail.gmail.com> On Jan 6, 2008 1:43 PM, Juergen Beisert wrote: > getCx86 and setCx86 defined as inline functions are working in all cases. So: > Do not use macros as functions. That's a good point. It's easy to get fooled by macros. Thanks ron From c-d.hailfinger.devel.2006 at gmx.net Sun Jan 6 23:55:42 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 06 Jan 2008 23:55:42 +0100 Subject: [LinuxBIOS] [RFC] Macros vs. functions for better readability In-Reply-To: <13426df10801061441m39d71b6djeb63d05c155ba113@mail.gmail.com> References: <4781109A.7000905@gmx.net> <200801062243.54719.juergen127@kreuzholzen.de> <13426df10801061441m39d71b6djeb63d05c155ba113@mail.gmail.com> Message-ID: <47815C6E.7010802@gmx.net> On 06.01.2008 23:41, ron minnich wrote: > On Jan 6, 2008 1:43 PM, Juergen Beisert wrote: > > >> getCx86 and setCx86 defined as inline functions are working in all cases. So: >> Do not use macros as functions. >> > > That's a good point. It's easy to get fooled by macros. > Macros have one big advantage as function wrappers, though: Their arguments do not have to contain all arguments to the wrapped functions. However, a macros MUST be easily visible as such to avoid "clever" usage. Regards, Carl-Daniel From russ at ashlandhome.net Mon Jan 7 02:08:29 2008 From: russ at ashlandhome.net (Russell Whitaker) Date: Sun, 6 Jan 2008 17:08:29 -0800 (PST) Subject: [LinuxBIOS] [RFC] Macros vs. functions for better readability In-Reply-To: <13426df10801061441m39d71b6djeb63d05c155ba113@mail.gmail.com> References: <4781109A.7000905@gmx.net> <200801062243.54719.juergen127@kreuzholzen.de> <13426df10801061441m39d71b6djeb63d05c155ba113@mail.gmail.com> Message-ID: On Sun, 6 Jan 2008, ron minnich wrote: > On Jan 6, 2008 1:43 PM, Juergen Beisert wrote: > >> getCx86 and setCx86 defined as inline functions are working in all cases. So: >> Do not use macros as functions. > > That's a good point. It's easy to get fooled by macros. How about something a little more simple-minded yet keeping it readable? Thus: #define EDGE MP_IRQ_TRIGGER_EDGE #define LEVEL MP_IRQ_TRIGGER_LEVEL #define HIGH MP_IRQ_POLARITY_HIGH #define LOW MP_IRO_PLOARITY_LOW Russ From Libo.Feng at amd.com Mon Jan 7 04:19:32 2008 From: Libo.Feng at amd.com (Feng, Libo) Date: Mon, 7 Jan 2008 11:19:32 +0800 Subject: [LinuxBIOS] The device number of PCIe Message-ID: Hi, all, In PCI, the IDSEL pin defines the device number. But in PCIe, there is no such pin, how is the device number defined? Best Regards ??? Feng Libo @ AMD Ext: 20906 Mobile Phone: 13683249071 Office Phone: 0086-010-62801406 -------------- next part -------------- An HTML attachment was scrubbed... URL: From svn at openbios.org Mon Jan 7 07:48:05 2008 From: svn at openbios.org (LinuxBIOS) Date: Mon, 07 Jan 2008 06:48:05 -0000 Subject: [LinuxBIOS] #69: Fix mptable util so the output will compile In-Reply-To: <074.008a03f2e7f42df57503fa8675665886@openbios.org> References: <074.008a03f2e7f42df57503fa8675665886@openbios.org> Message-ID: <083.f7a87206c30f5b80cf86f46cb29a1305@openbios.org> #69: Fix mptable util so the output will compile ------------------------------------------------------+--------------------- Reporter: Jon Dufresne | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Resolution: | Keywords: Dependencies: | Patchstatus: patch needs review ------------------------------------------------------+--------------------- Comment (by cozzie): The current mptable output doesn't compile, and with this patch, it does. That's not to say that the output is perfect, but it's one step closer ;) Unless there's some reason not to fix this: Acked-by: Corey Osgood I'll let someone else do the commit, just in case there's some reason not to do this, but I can't think of any. Thanks for the patches Jon, sorry they've sat here in limbo for so long. -- Ticket URL: LinuxBIOS From c-d.hailfinger.devel.2006 at gmx.net Mon Jan 7 10:40:02 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 07 Jan 2008 10:40:02 +0100 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <13426df10801061129k202bf432gca91b051a3399813@mail.gmail.com> References: <477ED8F5.1030807@gmx.net> <47800115.1060301@coresystems.de> <13426df10801051423h5c9426f8p549d2874359dfb09@mail.gmail.com> <20080106112946.GA31641@coresystems.de> <13426df10801061129k202bf432gca91b051a3399813@mail.gmail.com> Message-ID: <4781F372.7080204@gmx.net> On 06.01.2008 20:29, ron minnich wrote: > On Jan 6, 2008 3:29 AM, Stefan Reinauer wrote: > > >> And we can't cache the ROM because of CAR? >> > > yes. > Well, we can't use CPU cache, but we can abuse CAR memory as cache (ironic, isn't it? I'll call it CARAC.) for the first few (or all) members in the LAR. The cost estimate would be 8-32 bytes per LAR member, depending on your personal opinion on memory usage vs. speed tradeoff. >> I am not convinced that failing to find files has to be a performance >> critical path - While I generally agree it must not take several >> seconds, something's wrong with our logic if we fail to find files >> before we have RAM and Cache enabled. >> > > I think we should eliminate all unnnecessary overhead. Scanning (e.g.) > 2 Mbytes of memory for each failed lookup -- all the other BIOSes are > going to point at us and make rude comments :-) > I have another orthogonal design pending which incurs the lookup cost only on the first lookup. See above for the basic idea. The first failed lookup will incur the (almost) full cost of walking the LAR, all subsequent lookups (whether successful or failed) will cost O(larmembers) RAM/CARAC accesses. > I really would like us to have a reasonable termination instead of > searching all of memory. It can be anything -- make a file name called > EOF. Carl-Daniel's design was nice because it was very flash-friendly, > but I'm not picky. > I guess I need to explain the rationale in more detail. Our routines work just fine and with almost maximum efficiency achievable for a linear search as long as there are no empty (erased) areas before the LAR member we try to find. If there are empty areas in flash, we walk those empty areas in 16 byte steps. That is horribly inefficient and makes failed lookups slow, especially if your flash is almost empty. The bootblock will always be the last member of the lar. We also try to fill the lar from the bottom up. That means unless the lar is completely full, we will walk an empty are in 16 byte increments. Since we know the location of the boot block (top of flash) and we also know we never have to lookup or load the bootblock during LB execution, there should be an easy way to specify "from here to the beginning of the bootblock there will be no file" which is equivalent to "stop searching here". The "no file till bootblock" functionality can be implemented in three ways: 1. Explicit "stop searching here" marker or lar member. 2. Explicit lar member covering the free space. 3. List free space somehere in flash. Two of these ways fail in practice: 3. Listing free space in flash means erasing and/or rewriting that list everytime the lar changes. The only reasonable place for such a list would be the bootblock and we don't want to touch it during partial reflash. 2. Explicit free space covering lar member is fine, but to add any new file to the archive, you have to erase the part covered by the exlusive space. That leaves way #1: 1. Explicit "stop searching here" marker. Either we arrange for the marker bit pattern to be overwritable without erasing or not. Using the "normal" LAR header infrastructure, that would be an entry starting with "LARCHIVE" followed by a series of 0xFF bytes . That way, we can create a new LAR member without having to erase anything because the "LARCHIVE" magic stays the same and all other bits are still 1 and can be written to. Regards, Carl-Daniel From r.marek at assembler.cz Mon Jan 7 10:39:24 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Mon, 07 Jan 2008 10:39:24 +0100 Subject: [LinuxBIOS] The device number of PCIe In-Reply-To: References: Message-ID: <4781F34C.4010506@assembler.cz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > In PCI, the IDSEL pin defines the device number. But in PCIe, there is > no such pin, how is the device number defined? Imho for each slot there is PCI-PCI bridge. 00:02.0 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller 00:03.0 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller 00:03.1 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller 00:03.2 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller 00:03.3 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller You can turn on/off in the bridge if the bridge decodes just one address - otherwise you will see it as all devices possible behind the bridge. xx:00-xx:31 Thats all I know. :) Maybe you can take a look to PCIe express specs. Rudolf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHgfNM3J9wPJqZRNURAtEJAKDO7HTC//7ugs+5slIl9OsLStuQCQCfY84V BYgOzL63AA7JLtgabtAXDRU= =TVfF -----END PGP SIGNATURE----- From svn at openbios.org Mon Jan 7 12:13:16 2008 From: svn at openbios.org (svn at openbios.org) Date: Mon, 7 Jan 2008 12:13:16 +0100 Subject: [LinuxBIOS] r3035 - trunk/LinuxBIOSv2/src/mainboard/gigabyte/m57sli Message-ID: Author: duwe Date: 2008-01-07 12:13:16 +0100 (Mon, 07 Jan 2008) New Revision: 3035 Modified: trunk/LinuxBIOSv2/src/mainboard/gigabyte/m57sli/mptable.c Log: Improve readability and remove redundancy by wrapping similar smp_write_intsrc calls in preprocessor macros. Also add some comments about the actual devices the INTs belong to. Signed-off-by: Torsten Duwe Acked-by: Carl-Daniel Hailfinger Modified: trunk/LinuxBIOSv2/src/mainboard/gigabyte/m57sli/mptable.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/gigabyte/m57sli/mptable.c 2008-01-06 01:10:54 UTC (rev 3034) +++ trunk/LinuxBIOSv2/src/mainboard/gigabyte/m57sli/mptable.c 2008-01-07 11:13:16 UTC (rev 3035) @@ -98,46 +98,60 @@ } } -/*I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# -*/ smp_write_intsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x0, apicid_mcp55, 0x0); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x1, apicid_mcp55, 0x1); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x0, apicid_mcp55, 0x2); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x3, apicid_mcp55, 0x3); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x4, apicid_mcp55, 0x4); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x6, apicid_mcp55, 0x6); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x7, apicid_mcp55, 0x7); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x8, apicid_mcp55, 0x8); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0xc, apicid_mcp55, 0xc); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0xd, apicid_mcp55, 0xd); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0xe, apicid_mcp55, 0xe); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0xf, apicid_mcp55, 0xf); + /*I/O Ints: Type Trigger Polarity Bus ID IRQ APIC ID PIN# */ + smp_write_intsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x0, apicid_mcp55, 0x0); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_mcp55[0], ((sbdn+1)<<2)|1, apicid_mcp55, 0xa); +/* ISA ints are edge-triggered, and usually originate from the ISA bus, + * or its remainings. + */ +#define ISA_INT(intr, pin)\ + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, (intr), apicid_mcp55, (pin)) - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_mcp55[0], ((sbdn+2)<<2)|0, apicid_mcp55, 0x16); // 22 + ISA_INT(1,1); + ISA_INT(0,2); + ISA_INT(3,3); + ISA_INT(4,4); + ISA_INT(6,6); + ISA_INT(7,7); + ISA_INT(8,8); + ISA_INT(12,12); + ISA_INT(13,13); + ISA_INT(14,14); + ISA_INT(15,15); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_mcp55[0], ((sbdn+2)<<2)|1, apicid_mcp55, 0x17); // 23 +/* PCI interrupts are level triggered, and are + * associated with a specific bus/device/function tuple. + */ +#define PCI_INT(bus, dev, fn, pin) \ + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW,\ + bus_mcp55[bus], (((dev)<<2)|(fn)), apicid_mcp55, (pin)) - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_mcp55[0], ((sbdn+6)<<2)|1, apicid_mcp55, 0x17); // 23 + PCI_INT(0,sbdn+1,1, 10); /* SMBus */ + PCI_INT(0,sbdn+2,0, 22); /* USB */ + PCI_INT(0,sbdn+2,1, 23); /* USB */ + PCI_INT(0,sbdn+6,1, 23); /* HD Audio */ + PCI_INT(0,sbdn+5,0, 20); /* SATA */ + PCI_INT(0,sbdn+5,1, 23); /* SATA */ + PCI_INT(0,sbdn+5,2, 21); /* SATA */ - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_mcp55[0], ((sbdn+5)<<2)|0, apicid_mcp55, 0x14); // 20 - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_mcp55[0], ((sbdn+5)<<2)|1, apicid_mcp55, 0x17); // 23 - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_mcp55[0], ((sbdn+5)<<2)|2, apicid_mcp55, 0x15); // 21 + PCI_INT(0,sbdn+8,0, 22); /* GBit Ether */ - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_mcp55[0], ((sbdn+8)<<2)|0, apicid_mcp55, 0x16); // 22 - + /* The PCIe slots, each on its own bus */ for(j=7; j>=2; j--) { if(!bus_mcp55[j]) continue; - for(i=0;i<4;i++) { - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_mcp55[j], (0x00<<2)|i, apicid_mcp55, 0x10 + (1+j+i)%4); + for(i=0;i<4;i++) { /* map all functions */ + PCI_INT(j,0,i, 16+(1+j+i)%4); } } - for(j=0; j<2; j++) - for(i=0;i<4;i++) { - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_mcp55[1], ((0x07+j)<<2)|i, apicid_mcp55, 0x10 + (3+i+j)%4); + /* On bus 1: the physical PCI bus slots... */ + for(j=0; j<2; j++) /* on a Rev 1.x board, they are devs 7 and 8 */ + for(i=0;i<4;i++) { /* map all functions */ + PCI_INT(1,7+j,i, 16+(3+i+j)%4); } - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_mcp55[1], ((0x0a)<<2)|0, apicid_mcp55, 0x12); + /* ... and OB FireWire */ + PCI_INT(1,0x0a,0, 18); + /*Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN#*/ smp_write_intsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x0, MP_APIC_ALL, 0x0); smp_write_intsrc(mc, mp_NMI, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x0, MP_APIC_ALL, 0x1); From duwe at lst.de Mon Jan 7 12:21:42 2008 From: duwe at lst.de (Torsten Duwe) Date: Mon, 7 Jan 2008 12:21:42 +0100 Subject: [LinuxBIOS] [PATCH] beautify m57sli mptable.c (Was: Fix FireWire...) In-Reply-To: <4781011F.1080309@gmx.net> References: <200712172314.37483.duwe@lst.de> <200801061501.47959.duwe@lst.de> <4781011F.1080309@gmx.net> Message-ID: <200801071221.43184.duwe@lst.de> On Sunday 06 January 2008, Carl-Daniel Hailfinger wrote: > This is a much needed simplification and readability improvement. Thanks! > Generated code seems to be unchanged. > > If you drop the #undef lines (or explain why we absolutely need them), > you can take the ack from below. I consider it good practise to undef such readability macros as soon as they are not needed any more, like freeing unused memory. But I really have no strong opinion about them, no problem. > Acked-by: Carl-Daniel Hailfinger Thanks, revision 3035. > > Bonus points if you manage to convert all mptable.c files for MCP55 (or > even, if that task is not too daring, all mptable.c files). You mean something like perl -pe s:smp_write_intsrc\(mc,\s*mp_INT,\s*MP_IRQ[^,]*,\s*bus_isa\s*,(([^,]*),[^,]*, ([^)]*)):ISA_INT($2, $3):g; and so on? Turn it into a full-blown script and run it per board? Maybe. Torsten From info at coresystems.de Mon Jan 7 13:00:44 2008 From: info at coresystems.de (LinuxBIOS information) Date: Mon, 07 Jan 2008 13:00:44 +0100 Subject: [LinuxBIOS] r3035 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "duwe" checked in revision 3035 to the LinuxBIOS source repository and caused the following changes: Change Log: Improve readability and remove redundancy by wrapping similar smp_write_intsrc calls in preprocessor macros. Also add some comments about the actual devices the INTs belong to. Signed-off-by: Torsten Duwe Acked-by: Carl-Daniel Hailfinger Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3035&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in duwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From stepan at coresystems.de Mon Jan 7 13:20:11 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 7 Jan 2008 13:20:11 +0100 Subject: [LinuxBIOS] [PATCH] flashrom: SST25VF040B support In-Reply-To: <477E2A64.90904@gmx.net> References: <477E2A64.90904@gmx.net> Message-ID: <20080107122011.GA4697@coresystems.de> * Carl-Daniel Hailfinger [080104 13:45]: > Add support for the SST25VF040B 4 Mbit SPI flash chip. > Straight from the data sheet, not tested. > > Signed-off-by: Carl-Daniel Hailfinger Acked-by: Stefan Reinauer -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From stepan at coresystems.de Mon Jan 7 14:01:11 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 7 Jan 2008 14:01:11 +0100 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <4781F372.7080204@gmx.net> References: <477ED8F5.1030807@gmx.net> <47800115.1060301@coresystems.de> <13426df10801051423h5c9426f8p549d2874359dfb09@mail.gmail.com> <20080106112946.GA31641@coresystems.de> <13426df10801061129k202bf432gca91b051a3399813@mail.gmail.com> <4781F372.7080204@gmx.net> Message-ID: <20080107130111.GA12633@coresystems.de> Carl-Daniel, thanks for bringing this up. * Carl-Daniel Hailfinger [080107 10:40]: > The bootblock will always be the last member of the lar. We also try to > fill the lar from the bottom up. That means unless the lar is completely > full, we will walk an empty are in 16 byte increments. Since we know the > location of the boot block (top of flash) and we also know we never have > to lookup or load the bootblock during LB execution, there should be an > easy way to specify "from here to the beginning of the bootblock there > will be no file" which is equivalent to "stop searching here". > The "no file till bootblock" functionality can be implemented in three ways: > 1. Explicit "stop searching here" marker or lar member. > 2. Explicit lar member covering the free space. > 3. List free space somehere in flash. > > Two of these ways fail in practice: > 3. Listing free space in flash means erasing and/or rewriting that list > everytime the lar changes. The only reasonable place for such a list > would be the bootblock and we don't want to touch it during partial reflash. > 2. Explicit free space covering lar member is fine, but to add any new > file to the archive, you have to erase the part covered by the exlusive > space. I don't think this is such a bit problem. Lar could remove this entry automatically, and recreate it. This is not more special code in lar than 1. But I start thinking that those two are pretty much the same in the end. What about a linked list in the header? Each file could explicitly point to the next file. If the pointer is 0 or -1, we stop. This way we would not lock out the "bootblock" file in our lar search. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From c-d.hailfinger.devel.2006 at gmx.net Mon Jan 7 14:17:39 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 07 Jan 2008 14:17:39 +0100 Subject: [LinuxBIOS] [PATCH] beautify m57sli mptable.c (Was: Fix FireWire...) In-Reply-To: <200801071221.43184.duwe@lst.de> References: <200712172314.37483.duwe@lst.de> <200801061501.47959.duwe@lst.de> <4781011F.1080309@gmx.net> <200801071221.43184.duwe@lst.de> Message-ID: <47822673.1040708@gmx.net> On 07.01.2008 12:21, Torsten Duwe wrote: > On Sunday 06 January 2008, Carl-Daniel Hailfinger wrote: > > >> This is a much needed simplification and readability improvement. Thanks! >> Generated code seems to be unchanged. >> >> If you drop the #undef lines (or explain why we absolutely need them), >> you can take the ack from below. >> > > I consider it good practise to undef such readability macros as soon as they > are not needed any more, like freeing unused memory. But I really have no > strong opinion about them, no problem. > OK, that is a good reason. >> Acked-by: Carl-Daniel Hailfinger >> > > Thanks, revision 3035. > >> Bonus points if you manage to convert all mptable.c files for MCP55 (or >> even, if that task is not too daring, all mptable.c files). >> > > You mean something like perl -pe > s:smp_write_intsrc\(mc,\s*mp_INT,\s*MP_IRQ[^,]*,\s*bus_isa\s*,(([^,]*),[^,]*, > ([^)]*)):ISA_INT($2, $3):g; > and so on? Turn it into a full-blown script and run it per board? > Maybe. > Yes, that would be cool. However, the needed macros even differ for different mcp55 boards, so scripted replacement may need a human to look over the results. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Mon Jan 7 14:37:02 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 07 Jan 2008 14:37:02 +0100 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <20080107130111.GA12633@coresystems.de> References: <477ED8F5.1030807@gmx.net> <47800115.1060301@coresystems.de> <13426df10801051423h5c9426f8p549d2874359dfb09@mail.gmail.com> <20080106112946.GA31641@coresystems.de> <13426df10801061129k202bf432gca91b051a3399813@mail.gmail.com> <4781F372.7080204@gmx.net> <20080107130111.GA12633@coresystems.de> Message-ID: <47822AFE.3060405@gmx.net> On 07.01.2008 14:01, Stefan Reinauer wrote: > Carl-Daniel, > > thanks for bringing this up. > You're welcome. > * Carl-Daniel Hailfinger [080107 10:40]: > >> The bootblock will always be the last member of the lar. We also try to >> fill the lar from the bottom up. That means unless the lar is completely >> full, we will walk an empty are in 16 byte increments. Since we know the >> location of the boot block (top of flash) and we also know we never have >> to lookup or load the bootblock during LB execution, there should be an >> easy way to specify "from here to the beginning of the bootblock there >> will be no file" which is equivalent to "stop searching here". >> The "no file till bootblock" functionality can be implemented in three ways: >> 1. Explicit "stop searching here" marker or lar member. >> 2. Explicit lar member covering the free space. >> 3. List free space somehere in flash. >> >> Two of these ways fail in practice: >> 3. Listing free space in flash means erasing and/or rewriting that list >> everytime the lar changes. The only reasonable place for such a list >> would be the bootblock and we don't want to touch it during partial reflash. >> > > >> 2. Explicit free space covering lar member is fine, but to add any new >> file to the archive, you have to erase the part covered by the exlusive >> space. >> > > I don't think this is such a bit problem. Lar could remove this entry > automatically, and recreate it. This is not more special code in lar > than 1. But I start thinking that those two are pretty much the same in > the end. > Yes, 1 and 2 are very similar. Your proposal is almost exactly what I had in mind. This "dummy" member would be removed once a file was added to the lar and the new entry would "overwrite" the dummy header. If we have an explicit size in the dummy header, we can point to the next header easily without having to stop. However, once we use an explicit size (setting some bits to 0), we have to erase the flash block to add a new entry in place of the dummy. If we don't specify the size and keep all header entries (except magic) at value 0xff (all bits set), we still can write the new archive member without erasing because setting bits to 0 is always possible. My proposed code change is not very flexible and really only serves as "end of interesting lar members" marker, but it is flash-friendly. Besides that, the code can be overridden so if you really want to look at the boot block, you can do so easily. > What about a linked list in the header? Each file could explicitly point > to the next file. If the pointer is 0 or -1, we stop. > Nice idea, but it may not work in all cases. Requirements for this to work cleanly are: - The next pointer needs to have all bits set to 1 in the "stop pointer" case, or it is impossible to add a member after the member with a stop pointer without erasing the sector containing the header with the stop pointer. - The next pointer needs a way to be changed to a "stop pointer" without erasing (so the "stop pointer" must have at least one bit set to 0), or it is impossible to remove one archive member (and setting the previous next pointer to "stop pointer") without erasing the sector containing the header of the last member before the erased member. Conclusion: All bits must be set to 1 in the "stop pointer" value for adding to work, but at least one bit must be set to 0 in the "stop pointer" value for erasing to work. That's a conflict. > This way we would not lock out the "bootblock" file in our lar search. The "stop member" recognition could be disabled on a per-case basis. Regards, Carl-Daniel From svn at openbios.org Mon Jan 7 14:48:51 2008 From: svn at openbios.org (svn at openbios.org) Date: Mon, 7 Jan 2008 14:48:51 +0100 Subject: [LinuxBIOS] r3036 - trunk/util/flashrom Message-ID: Author: hailfinger Date: 2008-01-07 14:48:51 +0100 (Mon, 07 Jan 2008) New Revision: 3036 Modified: trunk/util/flashrom/flashchips.c Log: Add support for the SST25VF040B 4 Mbit SPI flash chip. Straight from the data sheet, not tested. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Stefan Reinauer Modified: trunk/util/flashrom/flashchips.c =================================================================== --- trunk/util/flashrom/flashchips.c 2008-01-07 11:13:16 UTC (rev 3035) +++ trunk/util/flashrom/flashchips.c 2008-01-07 13:48:51 UTC (rev 3036) @@ -52,6 +52,8 @@ probe_29f002, erase_29f002, write_29f002}, {"MX25L4005", MX_ID, MX_25L4005, 512, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, + {"SST25VF040B", SST_ID, SST_25VF040B, 512, 256, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, {"SST25VF016B", SST_ID, SST_25VF016B, 2048, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, {"SST29EE020A", SST_ID, SST_29EE020A, 256, 128, From c-d.hailfinger.devel.2006 at gmx.net Mon Jan 7 14:50:25 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 07 Jan 2008 14:50:25 +0100 Subject: [LinuxBIOS] [PATCH] flashrom: SST25VF040B support In-Reply-To: <20080107122011.GA4697@coresystems.de> References: <477E2A64.90904@gmx.net> <20080107122011.GA4697@coresystems.de> Message-ID: <47822E21.4010101@gmx.net> On 07.01.2008 13:20, Stefan Reinauer wrote: > * Carl-Daniel Hailfinger [080104 13:45]: > >> Add support for the SST25VF040B 4 Mbit SPI flash chip. >> Straight from the data sheet, not tested. >> >> Signed-off-by: Carl-Daniel Hailfinger >> > Acked-by: Stefan Reinauer > Thanks, r3036. Regards, Carl-Daniel From info at coresystems.de Mon Jan 7 15:35:56 2008 From: info at coresystems.de (LinuxBIOS information) Date: Mon, 07 Jan 2008 15:35:56 +0100 Subject: [LinuxBIOS] r3036 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "hailfinger" checked in revision 3036 to the LinuxBIOS source repository and caused the following changes: Change Log: Add support for the SST25VF040B 4 Mbit SPI flash chip. Straight from the data sheet, not tested. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Stefan Reinauer Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3036&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in hailfinger's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From c-d.hailfinger.devel.2006 at gmx.net Mon Jan 7 16:18:11 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 07 Jan 2008 16:18:11 +0100 Subject: [LinuxBIOS] [PATCH] v3: use #define for POST codes Message-ID: <478242B3.8000602@gmx.net> The current parameter situation of post_code() is rather mixed between numeric constants and #defines for such constants. Since grepping the tree shouldn't be necessary to find a POST code and we already have too many duplicated POST codes, gather almost all of them in a common header file. Signed-off-by: Carl-Daniel Hailfinger Index: LinuxBIOSv3-postcode/include/post_code.h =================================================================== --- LinuxBIOSv3-postcode/include/post_code.h (Revision 548) +++ LinuxBIOSv3-postcode/include/post_code.h (Arbeitskopie) @@ -25,6 +25,41 @@ SHARED(post_code, void, u8 value); -#define POST_START_OF_MAIN 0x01 +/* This is a collection of existing POST values used by post_code(). + * port80_post() and Geode specific codes are not (yet?) listed here. + * FIXME: Conflicts remain. + */ +#define POST_START_OF_MAIN 0x01 +#define POST_KBD_EMPTY_INPUT_BUFFER 0x00 +#define POST_KBD_EMPTY_OUTPUT_BUFFER 0x00 +#define POST_STAGE1_STOP_AP 0xf0 +#define POST_STAGE1_ENABLE_ROM 0xf2 +#define POST_STAGE1_MAIN 0x02 +#define POST_STAGE2_BEGIN 0x20 +#define POST_STAGE2_PHASE1_START 0x30 +#define POST_STAGE2_PHASE1_ENTER 0x31 +#define POST_STAGE2_PHASE1_DONE 0x3e +#define POST_STAGE2_PHASE1_EXIT 0x3f +#define POST_STAGE2_PHASE2_PCI_SET_METHOD 0x5f +#define POST_STAGE2_PHASE2_START 0x40 +#define POST_STAGE2_PHASE2_ENTER 0x41 +#define POST_STAGE2_PHASE2_DONE 0x4e +#define POST_STAGE2_PHASE2_EXIT 0x4f +#define POST_STAGE2_PHASE3_START 0x30 +#define POST_STAGE2_PHASE3_MIDDLE 0x41 +#define POST_STAGE2_PHASE3_SCAN_ENTER 0x42 +#define POST_STAGE2_PHASE3_SCAN_EXIT 0x4e +#define POST_STAGE2_PHASE4_START 0x40 +#define POST_STAGE2_PHASE5_START 0x50 +#define POST_STAGE2_PHASE6_START 0x60 +#define POST_STAGE2_WRITE_TABLES 0x70 +#define POST_STAGE2_ARCH_WRITE_TABLES_ENTER 0x9a +#define POST_STAGE2_ARCH_WRITE_TABLES_MIDDLE 0x96 +#define POST_STAGE2_PCISCANBUS_ENTER 0x24 +#define POST_STAGE2_PCISCANBUS_DONEFORLOOP 0x25 +#define POST_STAGE2_PCISCANBUS_EXIT 0x55 +#define POST_ELFBOOT_JUMPING_TO_BOOTCODE 0xfe +#define POST_ELFBOOT_LOADER_STARTED 0xf8 +#define POST_ELFBOOT_LOADER_IMAGE_FAILED 0xff #endif /* POST_CODE_H */ Index: LinuxBIOSv3-postcode/device/device.c =================================================================== --- LinuxBIOSv3-postcode/device/device.c (Revision 548) +++ LinuxBIOSv3-postcode/device/device.c (Arbeitskopie) @@ -698,16 +698,16 @@ { struct device *dev; - post_code(0x31); + post_code(POST_STAGE2_PHASE1_ENTER); printk(BIOS_DEBUG, "Phase 1: Very early setup...\n"); for (dev = all_devices; dev; dev = dev->next) { if (dev->ops && dev->ops->phase1_set_device_operations) { dev->ops->phase1_set_device_operations(dev); } } - post_code(0x3e); + post_code(POST_STAGE2_PHASE1_DONE); printk(BIOS_DEBUG, "Phase 1: done\n"); - post_code(0x3f); + post_code(POST_STAGE2_PHASE1_EXIT); } /** @@ -721,7 +721,7 @@ { struct device *dev; - post_code(0x41); + post_code(POST_STAGE2_PHASE2_ENTER); printk(BIOS_DEBUG, "Phase 2: Early setup...\n"); for (dev = all_devices; dev; dev = dev->next) { printk(BIOS_SPEW, "%s: dev %s: ", __FUNCTION__, dev->dtsname); @@ -734,9 +734,9 @@ printk(BIOS_SPEW, "\n"); } - post_code(0x4e); + post_code(POST_STAGE2_PHASE2_DONE); printk(BIOS_DEBUG, "Phase 2: Done.\n"); - post_code(0x4f); + post_code(POST_STAGE2_PHASE2_EXIT); } /** @@ -754,7 +754,7 @@ { unsigned int new_max; int do_phase3; - post_code(0x42); + post_code(POST_STAGE2_PHASE3_SCAN_ENTER); if (!busdevice || !busdevice->enabled || !busdevice->ops || !busdevice->ops->phase3_scan) { printk(BIOS_INFO, "%s: %s: busdevice %p enabled %d ops %p\n", @@ -786,7 +786,7 @@ } } } - post_code(0x4e); + post_code(POST_STAGE2_PHASE3_SCAN_EXIT); printk(BIOS_INFO, "%s: returning %d\n", __FUNCTION__, max); return new_max; } @@ -825,7 +825,7 @@ if (root->ops && root->ops->phase3_enable_scan) { root->ops->phase3_enable_scan(root); } - post_code(0x41); + post_code(POST_STAGE2_PHASE3_MIDDLE); if (!root->ops) { printk(BIOS_ERR, "dev_root_phase3 missing 'ops' initialization\nPhase 3: Failed.\n"); Index: LinuxBIOSv3-postcode/device/pci_device.c =================================================================== --- LinuxBIOSv3-postcode/device/pci_device.c (Revision 548) +++ LinuxBIOSv3-postcode/device/pci_device.c (Arbeitskopie) @@ -1096,7 +1096,7 @@ __func__, old_devices, bus->dev, bus->dev->dtsname); bus->children = 0; - post_code(0x24); + post_code(POST_STAGE2_PCISCANBUS_ENTER); printk(BIOS_SPEW, "PCI: scan devfn 0x%x to 0x%x\n", min_devfn, max_devfn); /* Probe all devices/functions on this bus with some optimization for @@ -1129,7 +1129,7 @@ } } printk(BIOS_SPEW, "PCI: Done for loop\n"); - post_code(0x25); + post_code(POST_STAGE2_PCISCANBUS_DONEFORLOOP); /* Die if any leftover static devices are are found. * There's probably a problem in the Config.lb. @@ -1155,7 +1155,7 @@ * Return how far we've got finding sub-buses. */ printk(BIOS_DEBUG, "PCI: pci_scan_bus returning with max=%03x\n", max); - post_code(0x55); + post_code(POST_STAGE2_PCISCANBUS_EXIT); return max; } Index: LinuxBIOSv3-postcode/lib/stage2.c =================================================================== --- LinuxBIOSv3-postcode/lib/stage2.c (Revision 548) +++ LinuxBIOSv3-postcode/lib/stage2.c (Arbeitskopie) @@ -46,13 +46,13 @@ /* TODO: Add comment. */ void show_all_devs(void); - post_code(0x20); + post_code(POST_STAGE2_BEGIN); dev_init(); /* Phase 1 was console init and making printk work. Both functions are * now performed by stage 1 code. Phase 1 is now without purpose. */ - post_code(0x30); + post_code(POST_STAGE2_PHASE1_START); dev_phase1(); show_all_devs(); @@ -60,34 +60,34 @@ * done. This is for ANYTHING that might have to happen before * device enumeration but that needs a printk. */ - post_code(0x40); + post_code(POST_STAGE2_PHASE2_START); dev_phase2(); show_all_devs(); /* Walk physical devices and add any dynamic devices to the * device tree. */ - post_code(0x30); + post_code(POST_STAGE2_PHASE3_START); dev_root_phase3(); show_all_devs(); /* Compute and assign the bus resources. */ - post_code(0x40); + post_code(POST_STAGE2_PHASE4_START); dev_phase4(); show_all_devs(); /* Now actually enable devices on the bus. */ - post_code(0x50); + post_code(POST_STAGE2_PHASE5_START); dev_root_phase5(); show_all_devs(); /* Initialize devices on the bus. */ - post_code(0x60); + post_code(POST_STAGE2_PHASE6_START); dev_phase6(); show_all_devs(); /* TODO: Add comment. */ - post_code(0x70); + post_code(POST_STAGE2_WRITE_TABLES); write_tables(); show_all_devs(); Index: LinuxBIOSv3-postcode/lib/elfboot.c =================================================================== --- LinuxBIOSv3-postcode/lib/elfboot.c (Revision 548) +++ LinuxBIOSv3-postcode/lib/elfboot.c (Arbeitskopie) @@ -146,7 +146,7 @@ //boot_successful(); printk(BIOS_DEBUG, "Jumping to boot code at %p\n", entry); - post_code(0xfe); + post_code(POST_ELFBOOT_JUMPING_TO_BOOTCODE); /* Jump to kernel */ /* most of the time, jmp_to_elf_entry is just a call. But this hook gives us @@ -169,7 +169,7 @@ result = 0; printk(BIOS_INFO, "ELF loader started.\n"); - post_code(0xf8); + post_code(POST_ELFBOOT_LOADER_STARTED); /* Scan for an elf header */ header_offset = -1; @@ -209,7 +209,7 @@ printk(BIOS_ERR, "Cannot load ELF image\n"); - post_code(0xff); + post_code(POST_ELFBOOT_LOADER_IMAGE_FAILED); } return 0; } Index: LinuxBIOSv3-postcode/arch/x86/keyboard.c =================================================================== --- LinuxBIOSv3-postcode/arch/x86/keyboard.c (Revision 548) +++ LinuxBIOSv3-postcode/arch/x86/keyboard.c (Arbeitskopie) @@ -7,7 +7,7 @@ { unsigned long timeout; for(timeout = 1000000; timeout && (inb(0x64) & 0x02); timeout--) { - post_code(0); + post_code(POST_KBD_EMPTY_INPUT_BUFFER); } return !!timeout; } @@ -16,7 +16,7 @@ { unsigned long timeout; for(timeout = 1000000; timeout && ((inb(0x64) & 0x01) == 0); timeout--) { - post_code(0); + post_code(POST_KBD_EMPTY_OUTPUT_BUFFER); } return !!timeout; } Index: LinuxBIOSv3-postcode/arch/x86/archtables.c =================================================================== --- LinuxBIOSv3-postcode/arch/x86/archtables.c (Revision 548) +++ LinuxBIOSv3-postcode/arch/x86/archtables.c (Arbeitskopie) @@ -77,7 +77,7 @@ low_table_start = 0; low_table_end = 16; - post_code(0x9a); + post_code(POST_STAGE2_ARCH_WRITE_TABLES_ENTER); /* This table must be betweeen 0xf0000 & 0x100000 */ // rom_table_end = write_pirq_routing_table(rom_table_end); @@ -92,7 +92,7 @@ // rom_table_end = (rom_table_end+1023) & ~1023; /* copy the smp block to address 0 */ - post_code(0x96); + post_code(POST_STAGE2_ARCH_WRITE_TABLES_MIDDLE); /* The smp table must be in 0-1K, 639K-640K, or 960K-1M */ // new_low_table_end = write_smp_table(low_table_end); Index: LinuxBIOSv3-postcode/arch/x86/pci_ops_auto.c =================================================================== --- LinuxBIOSv3-postcode/arch/x86/pci_ops_auto.c (Revision 548) +++ LinuxBIOSv3-postcode/arch/x86/pci_ops_auto.c (Arbeitskopie) @@ -88,5 +88,5 @@ { printk(BIOS_INFO, "Finding PCI configuration type.\n"); dev->ops->ops_pci_bus = pci_check_direct(); - post_code(0x5f); + post_code(POST_STAGE2_PHASE2_PCI_SET_METHOD); } Index: LinuxBIOSv3-postcode/arch/x86/stage1.c =================================================================== --- LinuxBIOSv3-postcode/arch/x86/stage1.c (Revision 548) +++ LinuxBIOSv3-postcode/arch/x86/stage1.c (Arbeitskopie) @@ -41,13 +41,13 @@ static void stop_ap(void) { // nothing yet - post_code(0xf0); + post_code(POST_STAGE1_STOP_AP); } static void enable_rom(void) { // nothing here yet - post_code(0xf2); + post_code(POST_STAGE1_ENABLE_ROM); } @@ -90,7 +90,7 @@ mem->map[0].type = LB_MEM_RAM; - post_code(0x02); + post_code(POST_STAGE1_MAIN); // before we do anything, we want to stop if we dont run // on the bootstrap processor. From Marc.Karasek at Sun.COM Mon Jan 7 16:15:30 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Mon, 07 Jan 2008 10:15:30 -0500 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: References: <477CF25C.7070901@sun.com> <477D2366.7090500@sun.com> <13426df10801031028y3dce3f53g15e336f1df8907b1@mail.gmail.com> <477D2A90.3070001@sun.com> <13426df10801031043o3ea5df06r62f51e7c63fabaaa@mail.gmail.com> <477D507E.4030106@sun.com> <477E8A50.2080408@sun.com> <477EB7A1.80406@sun.com> Message-ID: <47824212.3030307@sun.com> After looking at the script Myles sent, I immediately saw the problem. I forgot that if [ $build_id ] will always be true because it checks to see if it is defined not the value of build_id. My bad, sorry. I have made the changes and added an == 1 to the if statement. Attached is the new and I hope final patch file for this. /********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 *********************/ Ed Swierk wrote: > On 1/4/08, Marc Karasek wrote: > >> I made a test script and ran it and it sets build_id = 1 properly. I >> have also included this script. >> > > The problem is that on Planet Bourne, zero means true and nonzero means false. > > --Ed > -------------- next part -------------- A non-text attachment was scrubbed... Name: flags_final.patch Type: text/x-patch Size: 4167 bytes Desc: not available URL: From rminnich at gmail.com Mon Jan 7 16:36:55 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 7 Jan 2008 07:36:55 -0800 Subject: [LinuxBIOS] Sponsor for day 3 of linuxbios summit? Message-ID: <13426df10801070736n51d6cca2od7097da3deed422a@mail.gmail.com> Calling all commercial LinuxBIOS users: I am hoping some of you can rise to the occasion and kick in some money :-) Here is the issue. Day 3 will have $7500 in costs, and it is a headache for the conference manager to collect that extra money. So, they have asked me: "Is there is a sponsor we could contact to contribute to the Linux Bios meeting to help cover costs for the extra day....they get credit for sponsoring entire summit but in particular the extra costs. We would rather not collect a separate registration fee from those staying for Saturday.?" If anyone out there can help, please contact me privately. Thanks ron From rminnich at gmail.com Mon Jan 7 17:27:57 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 7 Jan 2008 08:27:57 -0800 Subject: [LinuxBIOS] [PATCH] v3: use #define for POST codes In-Reply-To: <478242B3.8000602@gmx.net> References: <478242B3.8000602@gmx.net> Message-ID: <13426df10801070827r4391d333xe7ff8ec9c52dd3ea@mail.gmail.com> Acked-by: Ronald G. Minnich From svn at openbios.org Mon Jan 7 17:34:34 2008 From: svn at openbios.org (svn at openbios.org) Date: Mon, 7 Jan 2008 17:34:34 +0100 Subject: [LinuxBIOS] r549 - in LinuxBIOSv3: arch/x86 device include lib Message-ID: Author: hailfinger Date: 2008-01-07 17:34:34 +0100 (Mon, 07 Jan 2008) New Revision: 549 Modified: LinuxBIOSv3/arch/x86/archtables.c LinuxBIOSv3/arch/x86/keyboard.c LinuxBIOSv3/arch/x86/pci_ops_auto.c LinuxBIOSv3/arch/x86/stage1.c LinuxBIOSv3/device/device.c LinuxBIOSv3/device/pci_device.c LinuxBIOSv3/include/post_code.h LinuxBIOSv3/lib/elfboot.c LinuxBIOSv3/lib/stage2.c Log: The current parameter situation of post_code() is rather mixed between numeric constants and #defines for such constants. Since grepping the tree shouldn't be necessary to find a POST code and we already have too many duplicated POST codes, gather almost all of them in a common header file. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Ronald G. Minnich Modified: LinuxBIOSv3/arch/x86/archtables.c =================================================================== --- LinuxBIOSv3/arch/x86/archtables.c 2008-01-05 01:35:57 UTC (rev 548) +++ LinuxBIOSv3/arch/x86/archtables.c 2008-01-07 16:34:34 UTC (rev 549) @@ -77,7 +77,7 @@ low_table_start = 0; low_table_end = 16; - post_code(0x9a); + post_code(POST_STAGE2_ARCH_WRITE_TABLES_ENTER); /* This table must be betweeen 0xf0000 & 0x100000 */ // rom_table_end = write_pirq_routing_table(rom_table_end); @@ -92,7 +92,7 @@ // rom_table_end = (rom_table_end+1023) & ~1023; /* copy the smp block to address 0 */ - post_code(0x96); + post_code(POST_STAGE2_ARCH_WRITE_TABLES_MIDDLE); /* The smp table must be in 0-1K, 639K-640K, or 960K-1M */ // new_low_table_end = write_smp_table(low_table_end); Modified: LinuxBIOSv3/arch/x86/keyboard.c =================================================================== --- LinuxBIOSv3/arch/x86/keyboard.c 2008-01-05 01:35:57 UTC (rev 548) +++ LinuxBIOSv3/arch/x86/keyboard.c 2008-01-07 16:34:34 UTC (rev 549) @@ -7,7 +7,7 @@ { unsigned long timeout; for(timeout = 1000000; timeout && (inb(0x64) & 0x02); timeout--) { - post_code(0); + post_code(POST_KBD_EMPTY_INPUT_BUFFER); } return !!timeout; } @@ -16,7 +16,7 @@ { unsigned long timeout; for(timeout = 1000000; timeout && ((inb(0x64) & 0x01) == 0); timeout--) { - post_code(0); + post_code(POST_KBD_EMPTY_OUTPUT_BUFFER); } return !!timeout; } Modified: LinuxBIOSv3/arch/x86/pci_ops_auto.c =================================================================== --- LinuxBIOSv3/arch/x86/pci_ops_auto.c 2008-01-05 01:35:57 UTC (rev 548) +++ LinuxBIOSv3/arch/x86/pci_ops_auto.c 2008-01-07 16:34:34 UTC (rev 549) @@ -88,5 +88,5 @@ { printk(BIOS_INFO, "Finding PCI configuration type.\n"); dev->ops->ops_pci_bus = pci_check_direct(); - post_code(0x5f); + post_code(POST_STAGE2_PHASE2_PCI_SET_METHOD); } Modified: LinuxBIOSv3/arch/x86/stage1.c =================================================================== --- LinuxBIOSv3/arch/x86/stage1.c 2008-01-05 01:35:57 UTC (rev 548) +++ LinuxBIOSv3/arch/x86/stage1.c 2008-01-07 16:34:34 UTC (rev 549) @@ -41,13 +41,13 @@ static void stop_ap(void) { // nothing yet - post_code(0xf0); + post_code(POST_STAGE1_STOP_AP); } static void enable_rom(void) { // nothing here yet - post_code(0xf2); + post_code(POST_STAGE1_ENABLE_ROM); } @@ -90,7 +90,7 @@ mem->map[0].type = LB_MEM_RAM; - post_code(0x02); + post_code(POST_STAGE1_MAIN); // before we do anything, we want to stop if we dont run // on the bootstrap processor. Modified: LinuxBIOSv3/device/device.c =================================================================== --- LinuxBIOSv3/device/device.c 2008-01-05 01:35:57 UTC (rev 548) +++ LinuxBIOSv3/device/device.c 2008-01-07 16:34:34 UTC (rev 549) @@ -698,16 +698,16 @@ { struct device *dev; - post_code(0x31); + post_code(POST_STAGE2_PHASE1_ENTER); printk(BIOS_DEBUG, "Phase 1: Very early setup...\n"); for (dev = all_devices; dev; dev = dev->next) { if (dev->ops && dev->ops->phase1_set_device_operations) { dev->ops->phase1_set_device_operations(dev); } } - post_code(0x3e); + post_code(POST_STAGE2_PHASE1_DONE); printk(BIOS_DEBUG, "Phase 1: done\n"); - post_code(0x3f); + post_code(POST_STAGE2_PHASE1_EXIT); } /** @@ -721,7 +721,7 @@ { struct device *dev; - post_code(0x41); + post_code(POST_STAGE2_PHASE2_ENTER); printk(BIOS_DEBUG, "Phase 2: Early setup...\n"); for (dev = all_devices; dev; dev = dev->next) { printk(BIOS_SPEW, "%s: dev %s: ", __FUNCTION__, dev->dtsname); @@ -734,9 +734,9 @@ printk(BIOS_SPEW, "\n"); } - post_code(0x4e); + post_code(POST_STAGE2_PHASE2_DONE); printk(BIOS_DEBUG, "Phase 2: Done.\n"); - post_code(0x4f); + post_code(POST_STAGE2_PHASE2_EXIT); } /** @@ -754,7 +754,7 @@ { unsigned int new_max; int do_phase3; - post_code(0x42); + post_code(POST_STAGE2_PHASE3_SCAN_ENTER); if (!busdevice || !busdevice->enabled || !busdevice->ops || !busdevice->ops->phase3_scan) { printk(BIOS_INFO, "%s: %s: busdevice %p enabled %d ops %p\n", @@ -786,7 +786,7 @@ } } } - post_code(0x4e); + post_code(POST_STAGE2_PHASE3_SCAN_EXIT); printk(BIOS_INFO, "%s: returning %d\n", __FUNCTION__, max); return new_max; } @@ -825,7 +825,7 @@ if (root->ops && root->ops->phase3_enable_scan) { root->ops->phase3_enable_scan(root); } - post_code(0x41); + post_code(POST_STAGE2_PHASE3_MIDDLE); if (!root->ops) { printk(BIOS_ERR, "dev_root_phase3 missing 'ops' initialization\nPhase 3: Failed.\n"); Modified: LinuxBIOSv3/device/pci_device.c =================================================================== --- LinuxBIOSv3/device/pci_device.c 2008-01-05 01:35:57 UTC (rev 548) +++ LinuxBIOSv3/device/pci_device.c 2008-01-07 16:34:34 UTC (rev 549) @@ -1096,7 +1096,7 @@ __func__, old_devices, bus->dev, bus->dev->dtsname); bus->children = 0; - post_code(0x24); + post_code(POST_STAGE2_PCISCANBUS_ENTER); printk(BIOS_SPEW, "PCI: scan devfn 0x%x to 0x%x\n", min_devfn, max_devfn); /* Probe all devices/functions on this bus with some optimization for @@ -1129,7 +1129,7 @@ } } printk(BIOS_SPEW, "PCI: Done for loop\n"); - post_code(0x25); + post_code(POST_STAGE2_PCISCANBUS_DONEFORLOOP); /* Die if any leftover static devices are are found. * There's probably a problem in the Config.lb. @@ -1155,7 +1155,7 @@ * Return how far we've got finding sub-buses. */ printk(BIOS_DEBUG, "PCI: pci_scan_bus returning with max=%03x\n", max); - post_code(0x55); + post_code(POST_STAGE2_PCISCANBUS_EXIT); return max; } Modified: LinuxBIOSv3/include/post_code.h =================================================================== --- LinuxBIOSv3/include/post_code.h 2008-01-05 01:35:57 UTC (rev 548) +++ LinuxBIOSv3/include/post_code.h 2008-01-07 16:34:34 UTC (rev 549) @@ -25,6 +25,41 @@ SHARED(post_code, void, u8 value); -#define POST_START_OF_MAIN 0x01 +/* This is a collection of existing POST values used by post_code(). + * port80_post() and Geode specific codes are not (yet?) listed here. + * FIXME: Conflicts remain. + */ +#define POST_START_OF_MAIN 0x01 +#define POST_KBD_EMPTY_INPUT_BUFFER 0x00 +#define POST_KBD_EMPTY_OUTPUT_BUFFER 0x00 +#define POST_STAGE1_STOP_AP 0xf0 +#define POST_STAGE1_ENABLE_ROM 0xf2 +#define POST_STAGE1_MAIN 0x02 +#define POST_STAGE2_BEGIN 0x20 +#define POST_STAGE2_PHASE1_START 0x30 +#define POST_STAGE2_PHASE1_ENTER 0x31 +#define POST_STAGE2_PHASE1_DONE 0x3e +#define POST_STAGE2_PHASE1_EXIT 0x3f +#define POST_STAGE2_PHASE2_PCI_SET_METHOD 0x5f +#define POST_STAGE2_PHASE2_START 0x40 +#define POST_STAGE2_PHASE2_ENTER 0x41 +#define POST_STAGE2_PHASE2_DONE 0x4e +#define POST_STAGE2_PHASE2_EXIT 0x4f +#define POST_STAGE2_PHASE3_START 0x30 +#define POST_STAGE2_PHASE3_MIDDLE 0x41 +#define POST_STAGE2_PHASE3_SCAN_ENTER 0x42 +#define POST_STAGE2_PHASE3_SCAN_EXIT 0x4e +#define POST_STAGE2_PHASE4_START 0x40 +#define POST_STAGE2_PHASE5_START 0x50 +#define POST_STAGE2_PHASE6_START 0x60 +#define POST_STAGE2_WRITE_TABLES 0x70 +#define POST_STAGE2_ARCH_WRITE_TABLES_ENTER 0x9a +#define POST_STAGE2_ARCH_WRITE_TABLES_MIDDLE 0x96 +#define POST_STAGE2_PCISCANBUS_ENTER 0x24 +#define POST_STAGE2_PCISCANBUS_DONEFORLOOP 0x25 +#define POST_STAGE2_PCISCANBUS_EXIT 0x55 +#define POST_ELFBOOT_JUMPING_TO_BOOTCODE 0xfe +#define POST_ELFBOOT_LOADER_STARTED 0xf8 +#define POST_ELFBOOT_LOADER_IMAGE_FAILED 0xff #endif /* POST_CODE_H */ Modified: LinuxBIOSv3/lib/elfboot.c =================================================================== --- LinuxBIOSv3/lib/elfboot.c 2008-01-05 01:35:57 UTC (rev 548) +++ LinuxBIOSv3/lib/elfboot.c 2008-01-07 16:34:34 UTC (rev 549) @@ -146,7 +146,7 @@ //boot_successful(); printk(BIOS_DEBUG, "Jumping to boot code at %p\n", entry); - post_code(0xfe); + post_code(POST_ELFBOOT_JUMPING_TO_BOOTCODE); /* Jump to kernel */ /* most of the time, jmp_to_elf_entry is just a call. But this hook gives us @@ -169,7 +169,7 @@ result = 0; printk(BIOS_INFO, "ELF loader started.\n"); - post_code(0xf8); + post_code(POST_ELFBOOT_LOADER_STARTED); /* Scan for an elf header */ header_offset = -1; @@ -209,7 +209,7 @@ printk(BIOS_ERR, "Cannot load ELF image\n"); - post_code(0xff); + post_code(POST_ELFBOOT_LOADER_IMAGE_FAILED); } return 0; } Modified: LinuxBIOSv3/lib/stage2.c =================================================================== --- LinuxBIOSv3/lib/stage2.c 2008-01-05 01:35:57 UTC (rev 548) +++ LinuxBIOSv3/lib/stage2.c 2008-01-07 16:34:34 UTC (rev 549) @@ -46,13 +46,13 @@ /* TODO: Add comment. */ void show_all_devs(void); - post_code(0x20); + post_code(POST_STAGE2_BEGIN); dev_init(); /* Phase 1 was console init and making printk work. Both functions are * now performed by stage 1 code. Phase 1 is now without purpose. */ - post_code(0x30); + post_code(POST_STAGE2_PHASE1_START); dev_phase1(); show_all_devs(); @@ -60,34 +60,34 @@ * done. This is for ANYTHING that might have to happen before * device enumeration but that needs a printk. */ - post_code(0x40); + post_code(POST_STAGE2_PHASE2_START); dev_phase2(); show_all_devs(); /* Walk physical devices and add any dynamic devices to the * device tree. */ - post_code(0x30); + post_code(POST_STAGE2_PHASE3_START); dev_root_phase3(); show_all_devs(); /* Compute and assign the bus resources. */ - post_code(0x40); + post_code(POST_STAGE2_PHASE4_START); dev_phase4(); show_all_devs(); /* Now actually enable devices on the bus. */ - post_code(0x50); + post_code(POST_STAGE2_PHASE5_START); dev_root_phase5(); show_all_devs(); /* Initialize devices on the bus. */ - post_code(0x60); + post_code(POST_STAGE2_PHASE6_START); dev_phase6(); show_all_devs(); /* TODO: Add comment. */ - post_code(0x70); + post_code(POST_STAGE2_WRITE_TABLES); write_tables(); show_all_devs(); From c-d.hailfinger.devel.2006 at gmx.net Mon Jan 7 17:36:16 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 07 Jan 2008 17:36:16 +0100 Subject: [LinuxBIOS] [PATCH] v3: use #define for POST codes In-Reply-To: <13426df10801070827r4391d333xe7ff8ec9c52dd3ea@mail.gmail.com> References: <478242B3.8000602@gmx.net> <13426df10801070827r4391d333xe7ff8ec9c52dd3ea@mail.gmail.com> Message-ID: <47825500.1000004@gmx.net> On 07.01.2008 17:27, ron minnich wrote: > Acked-by: Ronald G. Minnich > Thanks, r549. Regards, Carl-Daniel From myles at pel.cs.byu.edu Mon Jan 7 17:37:44 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Mon, 7 Jan 2008 09:37:44 -0700 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: <47824212.3030307@sun.com> References: <477CF25C.7070901@sun.com> <477D2A90.3070001@sun.com> <13426df10801031043o3ea5df06r62f51e7c63fabaaa@mail.gmail.com> <477D507E.4030106@sun.com> <477E8A50.2080408@sun.com> <477EB7A1.80406@sun.com> <47824212.3030307@sun.com> Message-ID: <2831fecf0801070837n4c22d036t38254f5ee02d14d1@mail.gmail.com> On Jan 7, 2008 8:15 AM, Marc Karasek wrote: > After looking at the script Myles sent, I immediately saw the problem. > I forgot that if [ $build_id ] will always be true because it checks to > see if it is defined not the value of build_id. My bad, sorry. > > I have made the changes and added an == 1 to the if statement. Attached > is the new and I hope final patch file for this. > It works for me (it doesn't add the load option.) Sorry to be picky, but it seems like this breaks if they mention build-id more than once in the help in the future. I think >0 would be better than ==1. With that fixed, or if no one thinks that will ever happen: Acked-by: Myles Watson > > /********************* > Marc Karasek > MTS > Sun Microsystems > mailto:marc.karasek at sun.com > ph:770.360.6415 > *********************/ > > > > Ed Swierk wrote: > > > On 1/4/08, Marc Karasek wrote: > > > >> I made a test script and ran it and it sets build_id = 1 properly. I > >> have also included this script. > >> > > > > The problem is that on Planet Bourne, zero means true and nonzero means false. > > > > --Ed > > > From rminnich at gmail.com Mon Jan 7 17:40:31 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 7 Jan 2008 08:40:31 -0800 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <4781F372.7080204@gmx.net> References: <477ED8F5.1030807@gmx.net> <47800115.1060301@coresystems.de> <13426df10801051423h5c9426f8p549d2874359dfb09@mail.gmail.com> <20080106112946.GA31641@coresystems.de> <13426df10801061129k202bf432gca91b051a3399813@mail.gmail.com> <4781F372.7080204@gmx.net> Message-ID: <13426df10801070840u786eaf23n6b41bc0462970996@mail.gmail.com> On Jan 7, 2008 1:40 AM, Carl-Daniel Hailfinger wrote: > Well, we can't use CPU cache, but we can abuse CAR memory as cache > (ironic, isn't it? I'll call it CARAC.) for the first few (or all) > members in the LAR. The cost estimate would be 8-32 bytes per LAR > member, depending on your personal opinion on memory usage vs. speed > tradeoff. > I would rather not walk all of empty space ever at any time. I like the end marker best. We can do it many ways, I leave it to you folks, but let's try to not look at 2^16-2^4 entries in search of something :-) I still find the explicit termination marker very interesting, esp. since it is flash rewrite friendly. Pointers, let's not do them, instead, if we want such a thing, let's do indices. If we start doing pointers, LAR is no longer location-independent. thanks ron From c-d.hailfinger.devel.2006 at gmx.net Mon Jan 7 17:47:29 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 07 Jan 2008 17:47:29 +0100 Subject: [LinuxBIOS] [PATCH] rewrite generic x86 CAR code In-Reply-To: <4776D885.7060800@gmx.net> References: <4776D885.7060800@gmx.net> Message-ID: <478257A1.8000809@gmx.net> Marc? While the patch is against the generic x86 CAR code, it can also be easily modified to work with AMD K8/K9/K10 CAR code. Especially the recent K10 commit made AMD CAR an #ifdef mess which could be sorted out nicely. This patch is part of my quest to clean up those v2 code parts which will someday end up in v3. Regards, Carl-Daniel On 30.12.2007 00:30, Carl-Daniel Hailfinger wrote: > This patch is an attempt at introducing 4k CAR size granularity for the > generic x86 code. For the old supported CAR sizes, the newly generated > code is equivalent, so it should be a no-brainer. > > Add a copyright header to the code, the header is derived from the one > found in the same piece of code in v3. > > Signed-off-by: Carl-Daniel Hailfinger > > Index: LinuxBIOSv2-CARx86/src/cpu/x86/car/cache_as_ram.inc > =================================================================== > --- LinuxBIOSv2-CARx86/src/cpu/x86/car/cache_as_ram.inc (Revision 3026) > +++ LinuxBIOSv2-CARx86/src/cpu/x86/car/cache_as_ram.inc (Arbeitskopie) > @@ -1,3 +1,28 @@ > +/* > + * This file is part of the LinuxBIOS project. > + * > + * Copyright (C) 2000,2007 Ronald G. Minnich > + * Copyright (C) 2005 Eswar Nallusamy, LANL > + * Copyright (C) 2005 Tyan > + * (Written by Yinghai Lu for Tyan) > + * Copyright (C) 2007 coresystems GmbH > + * (Written by Stefan Reinauer for coresystems GmbH) > + * Copyright (C) 2007 Carl-Daniel Hailfinger > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; version 2 of the License. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > + */ > + > /* We will use 4K bytes only */ > /* disable HyperThreading is done by eswar*/ > /* other's is the same as AMD except remove amd specific msr */ > @@ -106,39 +131,61 @@ > jmp clear_fixed_var_mtrr > clear_fixed_var_mtrr_out: > > -#if CacheSize == 0x10000 > - /* enable caching for 64K using fixed mtrr */ > +/* 0x06 is the WB IO type for a given 4k segment. > + * segs is the number of 4k segments we want to use for CAR. > + * subpart is the nth 32-bit window into IO type configuration. > + * reg is the register where the IO type should be stored. > + */ > +.macro extractmask segs, subpart, reg > +.if \segs - (\subpart * 4) <= 0 > + xorl \reg, \reg > +.elseif \segs - (\subpart * 4) == 1 > + movl $0x06000000, \reg > +.elseif \segs - (\subpart * 4) == 2 > + movl $0x06060000, \reg > +.elseif \segs - (\subpart * 4) == 3 > + movl $0x06060600, \reg > +.elseif \segs - (\subpart * 4) >= 4 > + movl $0x06060606, \reg > +.endif > +.endm > +.macro simplemask_helper segs, subpart > +.if \subpart & 0x1 > + extractmask \segs, \subpart, %eax > +.else > + extractmask \segs, \subpart, %edx > +.endif > +.endm > +/* size is the cache size in bytes we want to use for CAR. > + * part is the nth 64-bit window into IO type configuration. > + */ > +.macro simplemask size, part > + simplemask_helper (\size / 0x1000), (\part * 2 + 1) > + simplemask_helper (\size / 0x1000), (\part * 2) > +.endm > + > +#if CacheSize > 0x10000 > +#error Invalid CAR size, must be at most 64k. > +#endif > +#if CacheSize < 0x1000 > +#error Invalid CAR size, must be at least 4k. This is a processor limitation. > +#endif > +#if (CacheSize & (0x1000 - 1)) > +#error Invalid CAR size, is not a multiple of 4k. This is a processor limitation. > +#endif > + > +#if CacheSize > 0x8000 > + /* enable caching for 32K-64K using fixed mtrr */ > movl $0x268, %ecx /* fix4k_c0000*/ > - movl $0x06060606, %eax /* WB IO type */ > - movl %eax, %edx > + simplemask CacheSize, 1 > wrmsr > - movl $0x269, %ecx > - wrmsr > #endif > > -#if CacheSize == 0x8000 > - /* enable caching for 32K using fixed mtrr */ > + /* enable caching for 0-32K using fixed mtrr */ > movl $0x269, %ecx /* fix4k_c8000*/ > - movl $0x06060606, %eax /* WB IO type */ > - movl %eax, %edx > + simplemask CacheSize, 0 > wrmsr > -#endif > > - /* enable caching for 16K/8K/4K using fixed mtrr */ > - movl $0x269, %ecx /* fix4k_cc000*/ > -#if CacheSize == 0x4000 > - movl $0x06060606, %edx /* WB IO type */ > -#endif > -#if CacheSize == 0x2000 > - movl $0x06060000, %edx /* WB IO type */ > -#endif > -#if CacheSize == 0x1000 > - movl $0x06000000, %edx /* WB IO type */ > -#endif > - xorl %eax, %eax > - wrmsr > - > - > #else > /* disable cache */ > movl %cr0, %eax > > > > -- http://www.hailfinger.org/ From eswierk at arastra.com Mon Jan 7 17:59:16 2008 From: eswierk at arastra.com (Ed Swierk) Date: Mon, 7 Jan 2008 08:59:16 -0800 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: <2831fecf0801070837n4c22d036t38254f5ee02d14d1@mail.gmail.com> References: <477CF25C.7070901@sun.com> <13426df10801031043o3ea5df06r62f51e7c63fabaaa@mail.gmail.com> <477D507E.4030106@sun.com> <477E8A50.2080408@sun.com> <477EB7A1.80406@sun.com> <47824212.3030307@sun.com> <2831fecf0801070837n4c22d036t38254f5ee02d14d1@mail.gmail.com> Message-ID: On 1/7/08, Myles Watson wrote: > Sorry to be picky, but it seems like this breaks if they mention > build-id more than once in the help in the future. I think >0 would > be better than ==1. Using grep instead of awk would address this issue, and is a bit simpler (see attached). Also, is it appropriate to commit the change to src/arch/i386/lib/id.lds as a "temporary fix" with a magic value for _ROMTEMP if no one really understands why the commented-out code doesn't work? --Ed -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fixflags2.diff URL: From rminnich at gmail.com Mon Jan 7 18:06:02 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 7 Jan 2008 09:06:02 -0800 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: References: <477CF25C.7070901@sun.com> <477D507E.4030106@sun.com> <477E8A50.2080408@sun.com> <477EB7A1.80406@sun.com> <47824212.3030307@sun.com> <2831fecf0801070837n4c22d036t38254f5ee02d14d1@mail.gmail.com> Message-ID: <13426df10801070906i38600ad8j9019ff5bc6a0708d@mail.gmail.com> On Jan 7, 2008 8:59 AM, Ed Swierk wrote: > On 1/7/08, Myles Watson wrote: > > Sorry to be picky, but it seems like this breaks if they mention > > build-id more than once in the help in the future. I think >0 would > > be better than ==1. > > Using grep instead of awk would address this issue, and is a bit > simpler (see attached). This patch is not ready, let's give it one or two more iterations. Marc, can you try Ed's change? > > Also, is it appropriate to commit the change to > src/arch/i386/lib/id.lds as a "temporary fix" with a magic value for > _ROMTEMP if no one really understands why the commented-out code > doesn't work? No. Thanks ron From rminnich at gmail.com Mon Jan 7 18:07:15 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 7 Jan 2008 09:07:15 -0800 Subject: [LinuxBIOS] pciE spec Message-ID: <13426df10801070907l540ad3dpa00c429a30f6aea0@mail.gmail.com> Well, I had thought PCI SIG had stopped this nonsense, but the PCIe spec is still "members only". Is there a .pdf *somewhere* that one can look at? thanks ron From c-d.hailfinger.devel.2006 at gmx.net Mon Jan 7 18:08:11 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 07 Jan 2008 18:08:11 +0100 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <13426df10801070840u786eaf23n6b41bc0462970996@mail.gmail.com> References: <477ED8F5.1030807@gmx.net> <47800115.1060301@coresystems.de> <13426df10801051423h5c9426f8p549d2874359dfb09@mail.gmail.com> <20080106112946.GA31641@coresystems.de> <13426df10801061129k202bf432gca91b051a3399813@mail.gmail.com> <4781F372.7080204@gmx.net> <13426df10801070840u786eaf23n6b41bc0462970996@mail.gmail.com> Message-ID: <47825C7B.8050005@gmx.net> On 07.01.2008 17:40, ron minnich wrote: > On Jan 7, 2008 1:40 AM, Carl-Daniel Hailfinger > wrote: > > >> Well, we can't use CPU cache, but we can abuse CAR memory as cache >> (ironic, isn't it? I'll call it CARAC.) for the first few (or all) >> members in the LAR. The cost estimate would be 8-32 bytes per LAR >> member, depending on your personal opinion on memory usage vs. speed >> tradeoff. >> > > I would rather not walk all of empty space ever at any time. I like > the end marker best. We can do it many ways, I leave it to you folks, > but let's try to not look at 2^16-2^4 entries in search of something > :-) > My cache idea is completely orthogonal to the "walk empty space or not" issue. lib/lar.c would set up a cache of all LAR entries it encountered so far, making subsequent lookups almost pure cache memory operations. > I still find the explicit termination marker very interesting, esp. > since it is flash rewrite friendly. > > Pointers, let's not do them, instead, if we want such a thing, let's > do indices. If we start doing pointers, LAR is no longer > location-independent. > Agreed, but even for indices, the reasoning from my other mail applies. It is almost impossible to do without erasing unaffected flash sectors. There is one way to use indices sensibly without erasing the block containing the previous LAR header, but it will require an erase of the placeholder member. No-erase adding of LAR members with the requirement of no-collateral-erase-ever is not possible unless you allow me to add a dozen lines of code and uglify the central LAR parsing loop in a way that nobody ever is going to be able to verify the code. And I need 8 additional bytes in the header. There will be lots of special cases and people will have a strong urge to start v4 ;-) Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Mon Jan 7 18:14:46 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 07 Jan 2008 18:14:46 +0100 Subject: [LinuxBIOS] AMD RS690 Register Reference Guide released Message-ID: <47825E06.3090506@gmx.net> Hi, I was made aware of the following doc release: AMD RS690 Register Reference Guide http://www.x.org/docs/AMD/43372_rs690_rrg_3.00o.pdf While the public SB600 documentation is still missing a Register Reference Guide, at least we have some way to start a port to the RS690 or make ourselves familiar with it. Regards, Carl-Daniel From eswierk at arastra.com Mon Jan 7 18:16:49 2008 From: eswierk at arastra.com (Ed Swierk) Date: Mon, 7 Jan 2008 09:16:49 -0800 Subject: [LinuxBIOS] The device number of PCIe In-Reply-To: References: Message-ID: On 1/6/08, Feng, Libo wrote: > In PCI, the IDSEL pin defines the device number. But in PCIe, there is no > such pin, how is the device number defined? "Each PCI Express Link is equivalent to a logical PCI bus. In other words, each Link is assigned a bus number by the bus enumerating software. A PCI Express endpoint is device 0 on a PCI Express Link of a given bus number. Only one device (device 0) exists per PCI Express Link." -- PCI Express System Architecture, p. 51 --Ed From tsylla at gmail.com Mon Jan 7 18:43:41 2008 From: tsylla at gmail.com (Tom Sylla) Date: Mon, 7 Jan 2008 12:43:41 -0500 Subject: [LinuxBIOS] pciE spec In-Reply-To: <13426df10801070907l540ad3dpa00c429a30f6aea0@mail.gmail.com> References: <13426df10801070907l540ad3dpa00c429a30f6aea0@mail.gmail.com> Message-ID: <57947bf80801070943k6aa53237yd0e369b7e97e17ff@mail.gmail.com> On Jan 7, 2008 12:07 PM, ron minnich wrote: > Well, I had thought PCI SIG had stopped this nonsense, but the PCIe > spec is still "members only". > > Is there a .pdf *somewhere* that one can look at? Well, yes, you can pretty much always find them posted one someone's website if you google for the proper filename. But it is pretty questionable to use that information if you are not a PCI SIG member. All of the main PCI specs are still controlled by the SIG. Yes, it is annoying, but that is still the way it is. You can buy the mindshare PCIe book (they have electronic versions, too) to get a regurgitation of most of the information in the specification. From rminnich at gmail.com Mon Jan 7 18:46:35 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 7 Jan 2008 09:46:35 -0800 Subject: [LinuxBIOS] pciE spec In-Reply-To: <57947bf80801070943k6aa53237yd0e369b7e97e17ff@mail.gmail.com> References: <13426df10801070907l540ad3dpa00c429a30f6aea0@mail.gmail.com> <57947bf80801070943k6aa53237yd0e369b7e97e17ff@mail.gmail.com> Message-ID: <13426df10801070946h5a6ae753nc9c2f36b35d9acc8@mail.gmail.com> On Jan 7, 2008 9:43 AM, Tom Sylla wrote: > You can buy the mindshare PCIe book (they have electronic versions, > too) to get a regurgitation of most of the information in the > specification. > OK, will buy the book. I actually got admonished by a PCI guy several years ago when I complained on openib mailing list about the way PCI SIG handles the spec. "it's no longer members-only" I was told, "you can just download it". Hence I am disappointed to find out said PCI guy was wrong. thanks ron From c-d.hailfinger.devel.2006 at gmx.net Mon Jan 7 19:00:54 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 07 Jan 2008 19:00:54 +0100 Subject: [LinuxBIOS] [PATCH] Gigabyte GA-2761GXDK readability improvements Message-ID: <478268D6.2030906@gmx.net> Dear Morgan, please check the patch below to make LinuxBIOSv2/src/mainboard/gigabyte/ga_2761gxdk/mptable.c interrupt routing code easier to understand. If it is possible, lspci -nnvv of the board would be great to improve documentation. Regards, Carl-Daniel Use macros to improve readability of the device-to-pin IRQ assignments in GA-2761GXDK mptables.c. Thanks to Torsten Duwe for initial code. Signed-off-by: Carl-Daniel Hailfinger Index: LinuxBIOSv2-smpwriteintsrc/src/mainboard/gigabyte/ga_2761gxdk/mptable.c =================================================================== --- LinuxBIOSv2-smpwriteintsrc/src/mainboard/gigabyte/ga_2761gxdk/mptable.c (Revision 3036) +++ LinuxBIOSv2-smpwriteintsrc/src/mainboard/gigabyte/ga_2761gxdk/mptable.c (Arbeitskopie) @@ -100,44 +100,52 @@ } } -/*I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# -*/ smp_write_intsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x0, apicid_sis966, 0x0); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x1, apicid_sis966, 0x1); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x0, apicid_sis966, 0x2); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x3, apicid_sis966, 0x3); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x4, apicid_sis966, 0x4); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x6, apicid_sis966, 0x6); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x7, apicid_sis966, 0x7); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x8, apicid_sis966, 0x8); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0xc, apicid_sis966, 0xc); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0xd, apicid_sis966, 0xd); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0xe, apicid_sis966, 0xe); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0xf, apicid_sis966, 0xf); + /* I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# */ + smp_write_intsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x0, apicid_sis966, 0x0); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_sis966[0], ((sbdn+1)<<2)|1, apicid_sis966, 0xa); +/* ISA ints are edge-triggered, and usually originate from the ISA bus, + * or its remainings. + */ +#define ISA_INT(intr, pin)\ + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, (intr), apicid_sis966,(pin)) - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_sis966[0], ((sbdn+2)<<2)|0, apicid_sis966, 0x16); // 22 + ISA_INT(0x1, 0x1); + ISA_INT(0x0, 0x2); + ISA_INT(0x3, 0x3); + ISA_INT(0x4, 0x4); + ISA_INT(0x6, 0x6); + ISA_INT(0x7, 0x7); + ISA_INT(0x8, 0x8); + ISA_INT(0xc, 0xc); + ISA_INT(0xd, 0xd); + ISA_INT(0xe, 0xe); + ISA_INT(0xf, 0xf); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_sis966[0], ((sbdn+2)<<2)|1, apicid_sis966, 0x17); // 23 +/* PCI interrupts are level triggered, and are + * associated with a specific bus/device/function tuple. + */ +#define PCI_INT(bus, dev, fn, pin) \ + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_sis966[bus], (((dev)<<2)|(fn)), apicid_sis966, (pin)) - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_sis966[0], ((sbdn+6)<<2)|1, apicid_sis966, 0x17); // 23 + PCI_INT(0, sbdn+1, 1, 0xa); + PCI_INT(0, sbdn+2, 0, 0x16); // 22 + PCI_INT(0, sbdn+2, 1, 0x17); // 23 + PCI_INT(0, sbdn+6, 1, 0x17); // 23 + PCI_INT(0, sbdn+5, 0, 0x14); // 20 + PCI_INT(0, sbdn+5, 1, 0x17); // 23 + PCI_INT(0, sbdn+5, 2, 0x15); // 21 + PCI_INT(0, sbdn+8, 0, 0x16); // 22 - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_sis966[0], ((sbdn+5)<<2)|0, apicid_sis966, 0x14); // 20 - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_sis966[0], ((sbdn+5)<<2)|1, apicid_sis966, 0x17); // 23 - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_sis966[0], ((sbdn+5)<<2)|2, apicid_sis966, 0x15); // 21 - - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_sis966[0], ((sbdn+8)<<2)|0, apicid_sis966, 0x16); // 22 - for(j=7; j>=2; j--) { if(!bus_sis966[j]) continue; for(i=0;i<4;i++) { - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_sis966[j], (0x00<<2)|i, apicid_sis966, 0x10 + (2+j+i+4-sbdn%4)%4); + PCI_INT(j, 0x00, i, 0x10 + (2+j+i+4-sbdn%4)%4); } } for(j=0; j<2; j++) for(i=0;i<4;i++) { - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_sis966[1], ((0x06+j)<<2)|i, apicid_sis966, 0x10 + (2+i+j)%4); + PCI_INT(1, 0x06+j, i, 0x10 + (2+i+j)%4); } /*Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN#*/ From yasteve at gmail.com Mon Jan 7 19:13:47 2008 From: yasteve at gmail.com (Steve Isaacs) Date: Mon, 07 Jan 2008 10:13:47 -0800 Subject: [LinuxBIOS] fidvid_ap_stage1: time out while reading from BSP Message-ID: <1199729627.2777.16.camel@biosbreath> I'm seeing the following during early initialization. Does anyone have a suggestion for what to investigate? I've moved to a new board (first proto). This has BSP to AP on BSP link 1 and AP to BSP on AP link 2. (0,1) link=02 (1,0) link=01 02 nodes initialized. core0 started: 01 01 02 03SBLink=01 NC node|link=01 NC node|link=12 busn=40 fidvid_ap_stage1: time out while reading from BSP on 02 fidvid_ap_stage2: time out while reading from BSP on 02 fidvid_ap_stage3: time out while reading from BSP on 02 Thanks, Steve fyi: custom board with two Opterons and Broadcom chipset. From jordan.crouse at amd.com Mon Jan 7 20:21:45 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Mon, 7 Jan 2008 12:21:45 -0700 Subject: [LinuxBIOS] pciE spec In-Reply-To: <13426df10801070946h5a6ae753nc9c2f36b35d9acc8@mail.gmail.com> References: <13426df10801070907l540ad3dpa00c429a30f6aea0@mail.gmail.com> <57947bf80801070943k6aa53237yd0e369b7e97e17ff@mail.gmail.com> <13426df10801070946h5a6ae753nc9c2f36b35d9acc8@mail.gmail.com> Message-ID: <20080107192145.GB21480@cosmic.amd.com> On 07/01/08 09:46 -0800, ron minnich wrote: > On Jan 7, 2008 9:43 AM, Tom Sylla wrote: > > > You can buy the mindshare PCIe book (they have electronic versions, > > too) to get a regurgitation of most of the information in the > > specification. > > > > OK, will buy the book. I'll second the PCIe book from Mindshare - its most excellent. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From bishop.robinson at gmail.com Mon Jan 7 20:51:02 2008 From: bishop.robinson at gmail.com (Robinson Tryon) Date: Mon, 7 Jan 2008 14:51:02 -0500 Subject: [LinuxBIOS] pciE spec In-Reply-To: <13426df10801070946h5a6ae753nc9c2f36b35d9acc8@mail.gmail.com> References: <13426df10801070907l540ad3dpa00c429a30f6aea0@mail.gmail.com> <57947bf80801070943k6aa53237yd0e369b7e97e17ff@mail.gmail.com> <13426df10801070946h5a6ae753nc9c2f36b35d9acc8@mail.gmail.com> Message-ID: On Jan 7, 2008 12:46 PM, ron minnich wrote: > On Jan 7, 2008 9:43 AM, Tom Sylla wrote: > > > You can buy the mindshare PCIe book (they have electronic versions, > > too) to get a regurgitation of most of the information in the > > specification. > > > > OK, will buy the book. > > I actually got admonished by a PCI guy several years ago when I > complained on openib mailing list about the way PCI SIG handles the > spec. "it's no longer members-only" I was told, "you can just download > it". > > Hence I am disappointed to find out said PCI guy was wrong. Next time ask for a link and a license *immediately*. That way you either get the spec (Best Outcome) or it becomes immediately apparent that the spec is not actually open (Consolation Prize). This reminds me of when I trying to get free, open access to Adobe's Flash and FLV file format specifications. While doing research online, several people tried to convince me that the spec was "open" and that I could just get it "from over here or there," however no one could ever give me specifics. When I finally got through to actual people at Adobe (product managers and engineers), I was convinced that their file formats were, in fact, closed, and that they had no intention of allowing open access. So yeah -- get it in writing, or it doesn't mean a thing. From r.marek at assembler.cz Mon Jan 7 20:59:36 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Mon, 07 Jan 2008 20:59:36 +0100 Subject: [LinuxBIOS] pciE spec In-Reply-To: <13426df10801070907l540ad3dpa00c429a30f6aea0@mail.gmail.com> References: <13426df10801070907l540ad3dpa00c429a30f6aea0@mail.gmail.com> Message-ID: <478284A8.8040804@assembler.cz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi again, Yeah PDF are out there, only look to right place. Maybe not latest but something. Rudolf jjj.cpvfvt.pbz.fcrpvsvpngvbaf.cpvrkcerff.onfr.CPV_Rkcerff_Onfr_Fcrp_Reengn_1.0n_gb_1.cqs jjj.urc.hpy.np.hx.yp.pnyvpr.QND.Zrrgvatf.YbatGrez_040728.CPV_Rkcerff_Fcrpvsvpngvba_10.cqs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHgoSo3J9wPJqZRNURAlMRAKDg+eeQOaAVwg28pJnPFXt3QeuB2ACfR8XG oin3LlX9jLW2mO1aid5/M+E= =ppBw -----END PGP SIGNATURE----- From marc.jones at amd.com Mon Jan 7 23:18:42 2008 From: marc.jones at amd.com (Marc Jones) Date: Mon, 07 Jan 2008 15:18:42 -0700 Subject: [LinuxBIOS] PATCH: lx car that returns from disable_car In-Reply-To: <13426df10801041405h1d3e0f1eocdfba04c34144eb9@mail.gmail.com> References: <13426df10801041405h1d3e0f1eocdfba04c34144eb9@mail.gmail.com> Message-ID: <4782A542.6030109@amd.com> ron minnich wrote: > This patch set allows disable_car to return. Comments welcome. > > Thanks to Carl-Daniel and Stefan for not accepting my earlier patches, > and arguing me into the ground. They were right. > > [I hope :-) we still have not solved opteron.] > > This discussion began quite some time ago. I thought it would never > end. But I think we're there. > > Sometimes, no matter how much sense you think you are making, you've > got to listen to other people to get it right ... and it doesn't > always get done as soon as you might wish. > > thanks > > ron > The copy over and then wbinvd was a good idea. This should be fast and better than copy and then copy back.... It is fine to move the cache. I only used 0xC0000 because that is what K8 uses. For LX is doesn't matter where the stack is located. I don't like taking the hlt() out of die(). Can you describe when you where having issues? It could be coherency issues in CAR with die(). In FS2 check your config and set Coherent to off. You need it on/auto in normal operation. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From marc.jones at amd.com Mon Jan 7 23:45:34 2008 From: marc.jones at amd.com (Marc Jones) Date: Mon, 07 Jan 2008 15:45:34 -0700 Subject: [LinuxBIOS] v3 status In-Reply-To: <13426df10801041736rdae8c21ubd3e1cc947a068d3@mail.gmail.com> References: <13426df10801041736rdae8c21ubd3e1cc947a068d3@mail.gmail.com> Message-ID: <4782AB8E.1000706@amd.com> ron minnich wrote: > v3 loads and runs on an alix1c. > > So far, the only payload that works is a RET. Even a simple OUTB > followed by a RET fails. > > Any ideas on this? I'm flummoxed. Could it be the stack location? > Stack is at 0x8fxxx. > > Also, I have to run at < 1 MB, the memory above 1 MB reads back as all ffffffff. > > that's all for today. First payload is a good day. fixing disable_car > is even better :-) > we're getting there. > > ron > This is good news. Is it an _asm outb? The stack was working up to that point so I would assume it is good. Seems like a different problem. In your payload can you do a push/pop test? As for 1MB and above, it sounds like GLIUInit() isn't running correctly. Can you dump RCONF and GLIU MSRs? Something like v2 print_conf() in the norwich\mainboard.c. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From marc.jones at amd.com Mon Jan 7 23:50:32 2008 From: marc.jones at amd.com (Marc Jones) Date: Mon, 07 Jan 2008 15:50:32 -0700 Subject: [LinuxBIOS] v3 - vsa into lar In-Reply-To: <13426df10801041635y39d3c002y18fe82a134df5732@mail.gmail.com> References: <13426df10801041635y39d3c002y18fe82a134df5732@mail.gmail.com> Message-ID: <4782ACB8.2000306@amd.com> ron minnich wrote: > bringing along other files in lar. > > i want to bring vsa into lar. And I don't recall how we want to do > this. Any ideas? > > thanks > > ron > lar folks might have a better understanding but I think it can be done as another binary to jump to. It will return when it is finished. As for the build side I think this might be where buildrom comes in and does the wget etc. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From c-d.hailfinger.devel.2006 at gmx.net Tue Jan 8 00:05:14 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue, 08 Jan 2008 00:05:14 +0100 Subject: [LinuxBIOS] pciE spec In-Reply-To: <478284A8.8040804@assembler.cz> References: <13426df10801070907l540ad3dpa00c429a30f6aea0@mail.gmail.com> <478284A8.8040804@assembler.cz> Message-ID: <4782B02A.6000909@gmx.net> On 07.01.2008 20:59, Rudolf Marek wrote: > Yeah PDF are out there, only look to right place. Maybe not latest but > something. There's even a page which collects all legally available documentation. To be more exact, the remaining documents on that site seem to be OK with the PCI SIG. Other (unavailable) documents are listed on that site, but there is no link to these documents. http://members.datafast.net.au/dft0802/specs.htm @Ron: A quick google search for the relevant documents turned up your openib mail and the answer to it as one of the top results. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Tue Jan 8 00:11:42 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue, 08 Jan 2008 00:11:42 +0100 Subject: [LinuxBIOS] v3 - vsa into lar In-Reply-To: <4782ACB8.2000306@amd.com> References: <13426df10801041635y39d3c002y18fe82a134df5732@mail.gmail.com> <4782ACB8.2000306@amd.com> Message-ID: <4782B1AE.5010406@gmx.net> On 07.01.2008 23:50, Marc Jones wrote: > ron minnich wrote: > >> i want to bring vsa into lar. And I don't recall how we want to do >> this. Any ideas? >> >> > lar folks might have a better understanding but I think it can be done > as another binary to jump to. It will return when it is finished. As for > the build side I think this might be where buildrom comes in and does > the wget etc. > IIRC we now have the VSA sources available, so we should be able to build a custom VSA. For storing the VSA in the LAR, I have to know a few things. - Is the VSA a blob with no header and/or signature? - Do we have to load it at a specific address? - How do we determine the entry point? - What's the exact calling convention? If at all possible, I'd like to handle the VSA like any ELF file in the LAR, that means parsing and compressing it for storage in flash, then uncompressing and loading it to a specified address and executing it at the specified entry point. Regards, Carl-Daniel From marc.jones at amd.com Tue Jan 8 00:25:43 2008 From: marc.jones at amd.com (Marc Jones) Date: Mon, 07 Jan 2008 16:25:43 -0700 Subject: [LinuxBIOS] v3 - vsa into lar In-Reply-To: <4782B1AE.5010406@gmx.net> References: <13426df10801041635y39d3c002y18fe82a134df5732@mail.gmail.com> <4782ACB8.2000306@amd.com> <4782B1AE.5010406@gmx.net> Message-ID: <4782B4F7.1030604@amd.com> Carl-Daniel Hailfinger wrote: > IIRC we now have the VSA sources available, so we should be able to > build a custom VSA. > Yes, the source is out but it hasn't been ported to gcc so you don't want to do that. Just use the (nrv2b compressed) compiled binary. > For storing the VSA in the LAR, I have to know a few things. > - Is the VSA a blob with no header and/or signature? It would need a elf/lar header. > - Do we have to load it at a specific address? I don't think so but below 1MB to be safe. > - How do we determine the entry point? > - What's the exact calling convention? Same as used in v2 > > If at all possible, I'd like to handle the VSA like any ELF file in the > LAR, that means parsing and compressing it for storage in flash, then > uncompressing and loading it to a specified address and executing it at > the specified entry point. I agree, this is exactly how it should work. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From jordan.crouse at amd.com Tue Jan 8 00:37:27 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Mon, 7 Jan 2008 16:37:27 -0700 Subject: [LinuxBIOS] v3 - vsa into lar In-Reply-To: <4782ACB8.2000306@amd.com> References: <13426df10801041635y39d3c002y18fe82a134df5732@mail.gmail.com> <4782ACB8.2000306@amd.com> Message-ID: <20080107233727.GF21480@cosmic.amd.com> On 07/01/08 15:50 -0700, Marc Jones wrote: > > > ron minnich wrote: > > bringing along other files in lar. > > > > i want to bring vsa into lar. And I don't recall how we want to do > > this. Any ideas? > > > > thanks > > > > ron > > > > lar folks might have a better understanding but I think it can be done > as another binary to jump to. It will return when it is finished. As for > the build side I think this might be where buildrom comes in and does > the wget etc. It would probably have to be done slightly different, but yeah - thats the general idea. LAR is already set up for including arbitrary blobs for this very reason. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From jordan.crouse at amd.com Tue Jan 8 00:39:45 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Mon, 7 Jan 2008 16:39:45 -0700 Subject: [LinuxBIOS] v3 - vsa into lar In-Reply-To: <4782B1AE.5010406@gmx.net> References: <13426df10801041635y39d3c002y18fe82a134df5732@mail.gmail.com> <4782ACB8.2000306@amd.com> <4782B1AE.5010406@gmx.net> Message-ID: <20080107233945.GG21480@cosmic.amd.com> On 08/01/08 00:11 +0100, Carl-Daniel Hailfinger wrote: > On 07.01.2008 23:50, Marc Jones wrote: > > ron minnich wrote: > > > >> i want to bring vsa into lar. And I don't recall how we want to do > >> this. Any ideas? > >> > >> > > lar folks might have a better understanding but I think it can be done > > as another binary to jump to. It will return when it is finished. As for > > the build side I think this might be where buildrom comes in and does > > the wget etc. > > > > IIRC we now have the VSA sources available, so we should be able to > build a custom VSA. No, you are far, far away from being able to build the VSA, let alone a custom VSA. We've discussed this in the past, but in short, somebody will need to figure out how to port the current VSA to the GNU compiler. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From rminnich at gmail.com Tue Jan 8 00:46:54 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 7 Jan 2008 15:46:54 -0800 Subject: [LinuxBIOS] PATCH: lx car that returns from disable_car In-Reply-To: <4782A542.6030109@amd.com> References: <13426df10801041405h1d3e0f1eocdfba04c34144eb9@mail.gmail.com> <4782A542.6030109@amd.com> Message-ID: <13426df10801071546j3eaba5c8m6f7bcf3facb9f7f2@mail.gmail.com> On Jan 7, 2008 2:18 PM, Marc Jones wrote: > I don't like taking the hlt() out of die(). Can you describe when you > where having issues? In the early days of LinuxBIOS, using an American Arium JTAG debugger, I found that I could not examine memory or, in fact, do much of anything on JTAG once the CPU halts. It's a real hassle to get to a hlt() and know that the info you need is in memory, and you can't get to it. I'd really prefer not to have a hlt instruction in there, but if it is a problem, I guess we can put it back. As for the UART, similar issue: I had problems years ago where I had to intuit what got sent to the UART because it did not make it out -- it could get stuck in the FIFO or other intermediate places at times. I have found it handy to push a gazillion NULLS out to make sure I see all that is there (Actually, this is a decades old OS hacking trick ... dating back to, well, I'm embarrassed to say it). > It could be coherency issues in CAR with die(). In > FS2 check your config and set Coherent to off. You need it on/auto in > normal operation. It's not just an FS2 issue. I don't even have one any more -- it seems to have gotten lost in the move :-( ron From marc.jones at amd.com Tue Jan 8 00:57:15 2008 From: marc.jones at amd.com (Marc Jones) Date: Mon, 07 Jan 2008 16:57:15 -0700 Subject: [LinuxBIOS] PATCH: lx car that returns from disable_car In-Reply-To: <13426df10801071546j3eaba5c8m6f7bcf3facb9f7f2@mail.gmail.com> References: <13426df10801041405h1d3e0f1eocdfba04c34144eb9@mail.gmail.com> <4782A542.6030109@amd.com> <13426df10801071546j3eaba5c8m6f7bcf3facb9f7f2@mail.gmail.com> Message-ID: <4782BC5B.4000504@amd.com> ron minnich wrote: > On Jan 7, 2008 2:18 PM, Marc Jones wrote: > >> I don't like taking the hlt() out of die(). Can you describe when you >> where having issues? > > In the early days of LinuxBIOS, using an American Arium JTAG debugger, > I found that I could not examine memory or, in fact, do much of > anything on JTAG once the CPU halts. It's a real hassle to get to a > hlt() and know that the info you need is in memory, and you can't get > to it. > > I'd really prefer not to have a hlt instruction in there, but if it is > a problem, I guess we can put it back. > > As for the UART, similar issue: I had problems years ago where I had > to intuit what got sent to the UART because it did not make it out -- > it could get stuck in the FIFO or other intermediate places at times. > I have found it handy to push a gazillion NULLS out to make sure I see > all that is there (Actually, this is a decades old OS hacking trick > ... dating back to, well, I'm embarrassed to say it). > >> It could be coherency issues in CAR with die(). In >> FS2 check your config and set Coherent to off. You need it on/auto in >> normal operation. > > It's not just an FS2 issue. I don't even have one any more -- it seems > to have gotten lost in the move :-( > > ron > The hlt is really the right thing to do and I would rather it be in there. Correctly behaving jtag should be able to handle it. I understand clearing the fifo so do it before the hlt. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From rminnich at gmail.com Tue Jan 8 01:10:05 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 7 Jan 2008 16:10:05 -0800 Subject: [LinuxBIOS] PATCH: lx car that returns from disable_car In-Reply-To: <4782BC5B.4000504@amd.com> References: <13426df10801041405h1d3e0f1eocdfba04c34144eb9@mail.gmail.com> <4782A542.6030109@amd.com> <13426df10801071546j3eaba5c8m6f7bcf3facb9f7f2@mail.gmail.com> <4782BC5B.4000504@amd.com> Message-ID: <13426df10801071610s568a8d22yb3247551bdc4a1af@mail.gmail.com> On Jan 7, 2008 3:57 PM, Marc Jones wrote: > The hlt is really the right thing to do and I would rather it be in > there. Correctly behaving jtag should be able to handle it. I understand > clearing the fifo so do it before the hlt. OK. How about we do a bunch of outs and a hlt(). I'll ack any patch you want to make. ron From marc.jones at amd.com Tue Jan 8 01:40:18 2008 From: marc.jones at amd.com (Marc Jones) Date: Mon, 07 Jan 2008 17:40:18 -0700 Subject: [LinuxBIOS] [PATCH] rewrite generic x86 CAR code In-Reply-To: <478257A1.8000809@gmx.net> References: <4776D885.7060800@gmx.net> <478257A1.8000809@gmx.net> Message-ID: <4782C672.6040805@amd.com> Carl-Daniel Hailfinger wrote: > Marc? > > While the patch is against the generic x86 CAR code, it can also be > easily modified to work with AMD K8/K9/K10 CAR code. Especially the > recent K10 commit made AMD CAR an #ifdef mess which could be sorted out > nicely. > Yes, It would be good to clean them all up. > This patch is part of my quest to clean up those v2 code parts which > will someday end up in v3. A good cause :) >> >> -#if CacheSize == 0x10000 >> - /* enable caching for 64K using fixed mtrr */ >> +/* 0x06 is the WB IO type for a given 4k segment. >> + * segs is the number of 4k segments we want to use for CAR. >> + * subpart is the nth 32-bit window into IO type configuration. >> + * reg is the register where the IO type should be stored. >> + */ >> +.macro extractmask segs, subpart, reg >> +.if \segs - (\subpart * 4) <= 0 >> + xorl \reg, \reg >> +.elseif \segs - (\subpart * 4) == 1 >> + movl $0x06000000, \reg >> +.elseif \segs - (\subpart * 4) == 2 >> + movl $0x06060000, \reg >> +.elseif \segs - (\subpart * 4) == 3 >> + movl $0x06060600, \reg >> +.elseif \segs - (\subpart * 4) >= 4 >> + movl $0x06060606, \reg >> +.endif >> +.endm Why not just pass in the number of 4k pieces, \segs - (\subpart * 4)? >> +.macro simplemask_helper segs, subpart >> +.if \subpart & 0x1 >> + extractmask \segs, \subpart, %eax >> +.else >> + extractmask \segs, \subpart, %edx >> +.endif >> +.endm >> +/* size is the cache size in bytes we want to use for CAR. >> + * part is the nth 64-bit window into IO type configuration. >> + */ >> +.macro simplemask size, part >> + simplemask_helper (\size / 0x1000), (\part * 2 + 1) >> + simplemask_helper (\size / 0x1000), (\part * 2) >> +.endm >> + The \part stuff isn't really intuitive. I think an .if size > 32K would be better and then the caller doesn't have to know \part. Building on that the macro could fill in ecx as well. What do you think? Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From c-d.hailfinger.devel.2006 at gmx.net Tue Jan 8 02:49:54 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue, 08 Jan 2008 02:49:54 +0100 Subject: [LinuxBIOS] [PATCH] rewrite generic x86 CAR code In-Reply-To: <4782C672.6040805@amd.com> References: <4776D885.7060800@gmx.net> <478257A1.8000809@gmx.net> <4782C672.6040805@amd.com> Message-ID: <4782D6C2.5080602@gmx.net> On 08.01.2008 01:40, Marc Jones wrote: > > > Carl-Daniel Hailfinger wrote: >> Marc? >> >> While the patch is against the generic x86 CAR code, it can also be >> easily modified to work with AMD K8/K9/K10 CAR code. Especially the >> recent K10 commit made AMD CAR an #ifdef mess which could be sorted out >> nicely. >> > Yes, It would be good to clean them all up. OK, will prepare a patch to do so after we have finalized the generic x86 CAR patch. >> This patch is part of my quest to clean up those v2 code parts which >> will someday end up in v3. > A good cause :) Thanks. >>> >>> -#if CacheSize == 0x10000 - /* enable caching for 64K using >>> fixed mtrr */ >>> +/* 0x06 is the WB IO type for a given 4k segment. >>> + * segs is the number of 4k segments we want to use for CAR. >>> + * subpart is the nth 32-bit window into IO type configuration. >>> + * reg is the register where the IO type should be stored. >>> + */ >>> +.macro extractmask segs, subpart, reg >>> +.if \segs - (\subpart * 4) <= 0 >>> + xorl \reg, \reg >>> +.elseif \segs - (\subpart * 4) == 1 >>> + movl $0x06000000, \reg >>> +.elseif \segs - (\subpart * 4) == 2 >>> + movl $0x06060000, \reg >>> +.elseif \segs - (\subpart * 4) == 3 >>> + movl $0x06060600, \reg >>> +.elseif \segs - (\subpart * 4) >= 4 >>> + movl $0x06060606, \reg >>> +.endif >>> +.endm > > Why not just pass in the number of 4k pieces, \segs - (\subpart * 4)? To simplify understanding the formula for readers of the code. But I agree moving calculations makes the code more readable in the function above. >>> +.macro simplemask_helper segs, subpart >>> +.if \subpart & 0x1 >>> + extractmask \segs, \subpart, %eax >>> +.else >>> + extractmask \segs, \subpart, %edx >>> +.endif >>> +.endm >>> +/* size is the cache size in bytes we want to use for CAR. >>> + * part is the nth 64-bit window into IO type configuration. >>> + */ >>> +.macro simplemask size, part >>> + simplemask_helper (\size / 0x1000), (\part * 2 + 1) >>> + simplemask_helper (\size / 0x1000), (\part * 2) >>> +.endm >>> + > > The \part stuff isn't really intuitive. I think an .if size > 32K > would be better and then the caller doesn't have to know \part. > Building on that the macro could fill in ecx as well. I'll rewrite the patch a bit to make it more intuitive. I disagree with the ".if size > 32k" part, though. But once you see my new code, it may be elegant enough to not worry about the 32k boundary anymore. Regards, Carl-Daniel From corey.osgood at gmail.com Tue Jan 8 10:00:49 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Tue, 08 Jan 2008 04:00:49 -0500 Subject: [LinuxBIOS] [PATCH] remove duplicated microcode updates for some Intel processors In-Reply-To: <13426df10712292150n6f48ed54ya803992f2171c563@mail.gmail.com> References: <47770D5D.7060108@gmx.net> <47771C26.9050001@gmail.com> <20071230000012.kli0uxn3ksosskc8@www.smittys.pointclark.net> <13426df10712292150n6f48ed54ya803992f2171c563@mail.gmail.com> Message-ID: <47833BC1.3090708@gmail.com> ron minnich wrote: > On Dec 29, 2007 9:00 PM, wrote: > >> Quoting Corey Osgood : >> >>> Acked-by: Corey Osgood >>> >>> how long has it been since we've updated the microcode updates? >>> >>> >> No idea, but remember the email below from 12/12/07? Looks like an >> update is in order, but I wouldn't know where to start. >> >> Thanks - Joe >> >> >>> Quoting Martin.Karlsson at emerson.com: >>> >>> >>>> Hello, >>>> >>>> Yesterday I wrote some code for the Syslinux boot loader that is meant >>>> to boot different images based on which revision of the CPU microcode >>>> that is currently loaded in the CPU (yes, this is a bit strange but we >>>> have a very good reason for it). I then compared my implementation with >>>> a few others an ran across yours, in >>>> http://www.openbios.org/viewvc/trunk/LinuxBIOSv2/src/cpu/intel/microcode >>>> /microcode.c?view=markup >>>> >>>> Question to you guys: why is the first wrmsr instruction there? From my >>>> understanding, by not properly initialising ECX, EAX and EDX this will >>>> overwrite whatever is in the MSR pointed to by ECX?! >>>> >>>> BTW I tried out your code on our target hardware (Intel Celeron M, 600 >>>> MHz) and with that first wrmsr line in place it hangs and without it, it >>>> runs just fine. >>>> >>>> Just wanted to let you know. >>>> >>>> Best regards, >>>> Martin Karlsson >>>> >> -- >> linuxbios mailing list >> linuxbios at linuxbios.org >> http://www.linuxbios.org/mailman/listinfo/linuxbios >> >> > > I submitted the patch to remove this extraneous wrmsr a while back. I > can't recall if it was acked and committed, but I thought it was. > No, this doesn't seem to have been taken care of yet. Is it read_microcode_rev() or intel_update_microcode() that needs the wrmsr removed? Microcode updates coming in the morning, if the abuild passes. -Corey From svn at openbios.org Tue Jan 8 11:28:06 2008 From: svn at openbios.org (svn at openbios.org) Date: Tue, 8 Jan 2008 11:28:06 +0100 Subject: [LinuxBIOS] r3037 - trunk/LinuxBIOSv2/src/config Message-ID: Author: oxygene Date: 2008-01-08 11:28:06 +0100 (Tue, 08 Jan 2008) New Revision: 3037 Modified: trunk/LinuxBIOSv2/src/config/Config.lb Log: Ubuntu's gcc doesn't write "install:" in german locales. Normalize used locale to "C" before parsing output. Signed-off-by: Patrick Georgi Acked-by: Stefan Reinauer Modified: trunk/LinuxBIOSv2/src/config/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/config/Config.lb 2008-01-07 13:48:51 UTC (rev 3036) +++ trunk/LinuxBIOSv2/src/config/Config.lb 2008-01-08 10:28:06 UTC (rev 3037) @@ -5,7 +5,7 @@ makedefine CPP:= $(CC) -x assembler-with-cpp -DASSEMBLY -E makedefine LIBGCC_FILE_NAME := $(shell $(CC) -print-libgcc-file-name) -makedefine GCC_INC_DIR := $(shell $(CC) -print-search-dirs | sed -ne "s/install: \(.*\)/\1include/gp") +makedefine GCC_INC_DIR := $(shell LC_ALL=C $(CC) -print-search-dirs | sed -ne "s/install: \(.*\)/\1include/gp") makedefine CPPFLAGS := -I$(TOP)/src/include -I$(TOP)/src/arch/$(ARCH)/include -I$(GCC_INC_DIR) $(CPUFLAGS) makedefine CFLAGS := $(CPU_OPT) $(CPPFLAGS) -Os -nostdinc -nostdlib -fno-builtin -Wall From joe at smittys.pointclark.net Tue Jan 8 11:56:01 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Tue, 08 Jan 2008 05:56:01 -0500 Subject: [LinuxBIOS] [PATCH] remove duplicated microcode updates for some Intel processors In-Reply-To: <47833BC1.3090708@gmail.com> References: <47770D5D.7060108@gmx.net> <47771C26.9050001@gmail.com> <20071230000012.kli0uxn3ksosskc8@www.smittys.pointclark.net> <13426df10712292150n6f48ed54ya803992f2171c563@mail.gmail.com> <47833BC1.3090708@gmail.com> Message-ID: <20080108055601.87ncyk2w8osc48cc@www.smittys.pointclark.net> > Microcode updates coming in the morning, if the abuild passes. > > -Corey > SWEET :-) Thanks - Joe From info at coresystems.de Tue Jan 8 12:14:50 2008 From: info at coresystems.de (LinuxBIOS information) Date: Tue, 08 Jan 2008 12:14:50 +0100 Subject: [LinuxBIOS] r3037 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "oxygene" checked in revision 3037 to the LinuxBIOS source repository and caused the following changes: Change Log: Ubuntu's gcc doesn't write "install:" in german locales. Normalize used locale to "C" before parsing output. Signed-off-by: Patrick Georgi Acked-by: Stefan Reinauer Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3037&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in oxygene's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From c-d.hailfinger.devel.2006 at gmx.net Tue Jan 8 17:32:58 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue, 08 Jan 2008 17:32:58 +0100 Subject: [LinuxBIOS] [PATCH] rewrite generic x86 CAR code In-Reply-To: <4782D6C2.5080602@gmx.net> References: <4776D885.7060800@gmx.net> <478257A1.8000809@gmx.net> <4782C672.6040805@amd.com> <4782D6C2.5080602@gmx.net> Message-ID: <4783A5BA.3060209@gmx.net> Next try, with feedback incorporated. The "part" parameter has been changed to an offset into CAR size expressed in bytes. This patch is an attempt at introducing 4k CAR size granularity for the generic x86 code. For the old supported CAR sizes, the newly generated code is equivalent, so it should be a no-brainer. Add a copyright header to the code, the header is derived from the one found in the same piece of code in v3. Signed-off-by: Carl-Daniel Hailfinger Index: LinuxBIOSv2-CARx86/src/cpu/x86/car/cache_as_ram.inc =================================================================== --- LinuxBIOSv2-CARx86/src/cpu/x86/car/cache_as_ram.inc (Revision 3036) +++ LinuxBIOSv2-CARx86/src/cpu/x86/car/cache_as_ram.inc (Arbeitskopie) @@ -1,3 +1,28 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2000,2007 Ronald G. Minnich + * Copyright (C) 2005 Eswar Nallusamy, LANL + * Copyright (C) 2005 Tyan + * (Written by Yinghai Lu for Tyan) + * Copyright (C) 2007 coresystems GmbH + * (Written by Stefan Reinauer for coresystems GmbH) + * Copyright (C) 2007 Carl-Daniel Hailfinger + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + /* We will use 4K bytes only */ /* disable HyperThreading is done by eswar*/ /* other's is the same as AMD except remove amd specific msr */ @@ -106,39 +131,59 @@ jmp clear_fixed_var_mtrr clear_fixed_var_mtrr_out: -#if CacheSize == 0x10000 - /* enable caching for 64K using fixed mtrr */ +/* 0x06 is the WB IO type for a given 4k segment. + * segs is the number of 4k segments in the area of the particular + * register we want to use for CAR. + * reg is the register where the IO type should be stored. + */ +.macro extractmask segs, reg +.if \segs <= 0 + /* The xorl here is superfluous because at the point of first execution + * of this macro, %eax and %edx are cleared. Later invocations of this + * macro will have a monotonically increasing segs parameter. + */ + xorl \reg, \reg +.elseif \segs == 1 + movl $0x06000000, \reg +.elseif \segs == 2 + movl $0x06060000, \reg +.elseif \segs == 3 + movl $0x06060600, \reg +.elseif \segs >= 4 + movl $0x06060606, \reg +.endif +.endm + +/* size is the cache size in bytes we want to use for CAR. + * windowoffset is the 32k-aligned window into CAR size + */ +.macro simplemask carsize, windowoffset + simplemask_helper (((\carsize - \windowoffset) / 0x1000) - 4), %eax + simplemask_helper (((\carsize - \windowoffset) / 0x1000)), %edx +.endm + +#if CacheSize > 0x10000 +#error Invalid CAR size, must be at most 64k. +#endif +#if CacheSize < 0x1000 +#error Invalid CAR size, must be at least 4k. This is a processor limitation. +#endif +#if (CacheSize & (0x1000 - 1)) +#error Invalid CAR size, is not a multiple of 4k. This is a processor limitation. +#endif + +#if CacheSize > 0x8000 + /* enable caching for 32K-64K using fixed mtrr */ movl $0x268, %ecx /* fix4k_c0000*/ - movl $0x06060606, %eax /* WB IO type */ - movl %eax, %edx + simplemask CacheSize, 0x8000 wrmsr - movl $0x269, %ecx - wrmsr #endif -#if CacheSize == 0x8000 - /* enable caching for 32K using fixed mtrr */ + /* enable caching for 0-32K using fixed mtrr */ movl $0x269, %ecx /* fix4k_c8000*/ - movl $0x06060606, %eax /* WB IO type */ - movl %eax, %edx + simplemask CacheSize, 0 wrmsr -#endif - /* enable caching for 16K/8K/4K using fixed mtrr */ - movl $0x269, %ecx /* fix4k_cc000*/ -#if CacheSize == 0x4000 - movl $0x06060606, %edx /* WB IO type */ -#endif -#if CacheSize == 0x2000 - movl $0x06060000, %edx /* WB IO type */ -#endif -#if CacheSize == 0x1000 - movl $0x06000000, %edx /* WB IO type */ -#endif - xorl %eax, %eax - wrmsr - - #else /* disable cache */ movl %cr0, %eax From marc.jones at amd.com Tue Jan 8 17:56:06 2008 From: marc.jones at amd.com (Marc Jones) Date: Tue, 08 Jan 2008 09:56:06 -0700 Subject: [LinuxBIOS] [PATCH] rewrite generic x86 CAR code In-Reply-To: <4783A5BA.3060209@gmx.net> References: <4776D885.7060800@gmx.net> <478257A1.8000809@gmx.net> <4782C672.6040805@amd.com> <4782D6C2.5080602@gmx.net> <4783A5BA.3060209@gmx.net> Message-ID: <4783AB26.40502@amd.com> Carl-Daniel Hailfinger wrote: > Next try, with feedback incorporated. The "part" parameter has been > changed to an offset into CAR size expressed in bytes. > > This patch is an attempt at introducing 4k CAR size granularity for the > generic x86 code. For the old supported CAR sizes, the newly generated > code is equivalent, so it should be a no-brainer. > > Add a copyright header to the code, the header is derived from the one > found in the same piece of code in v3. > > Signed-off-by: Carl-Daniel Hailfinger > > This looks good. Thanks for the iterations. Acked-by: Marc Jones -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From svn at openbios.org Tue Jan 8 18:06:38 2008 From: svn at openbios.org (svn at openbios.org) Date: Tue, 8 Jan 2008 18:06:38 +0100 Subject: [LinuxBIOS] r3038 - trunk/LinuxBIOSv2/src/cpu/x86/car Message-ID: Author: hailfinger Date: 2008-01-08 18:06:38 +0100 (Tue, 08 Jan 2008) New Revision: 3038 Modified: trunk/LinuxBIOSv2/src/cpu/x86/car/cache_as_ram.inc Log: This patch is an attempt at introducing 4k CAR size granularity for the generic x86 CAR code. For the old supported CAR sizes, the newly generated code is equivalent, so it should be a no-brainer. Add a copyright header to the code, the header is derived from the one found in the same piece of code in v3. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Marc Jones Modified: trunk/LinuxBIOSv2/src/cpu/x86/car/cache_as_ram.inc =================================================================== --- trunk/LinuxBIOSv2/src/cpu/x86/car/cache_as_ram.inc 2008-01-08 10:28:06 UTC (rev 3037) +++ trunk/LinuxBIOSv2/src/cpu/x86/car/cache_as_ram.inc 2008-01-08 17:06:38 UTC (rev 3038) @@ -1,3 +1,28 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2000,2007 Ronald G. Minnich + * Copyright (C) 2005 Eswar Nallusamy, LANL + * Copyright (C) 2005 Tyan + * (Written by Yinghai Lu for Tyan) + * Copyright (C) 2007 coresystems GmbH + * (Written by Stefan Reinauer for coresystems GmbH) + * Copyright (C) 2007 Carl-Daniel Hailfinger + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + /* We will use 4K bytes only */ /* disable HyperThreading is done by eswar*/ /* other's is the same as AMD except remove amd specific msr */ @@ -106,39 +131,59 @@ jmp clear_fixed_var_mtrr clear_fixed_var_mtrr_out: -#if CacheSize == 0x10000 - /* enable caching for 64K using fixed mtrr */ +/* 0x06 is the WB IO type for a given 4k segment. + * segs is the number of 4k segments in the area of the particular + * register we want to use for CAR. + * reg is the register where the IO type should be stored. + */ +.macro extractmask segs, reg +.if \segs <= 0 + /* The xorl here is superfluous because at the point of first execution + * of this macro, %eax and %edx are cleared. Later invocations of this + * macro will have a monotonically increasing segs parameter. + */ + xorl \reg, \reg +.elseif \segs == 1 + movl $0x06000000, \reg +.elseif \segs == 2 + movl $0x06060000, \reg +.elseif \segs == 3 + movl $0x06060600, \reg +.elseif \segs >= 4 + movl $0x06060606, \reg +.endif +.endm + +/* size is the cache size in bytes we want to use for CAR. + * windowoffset is the 32k-aligned window into CAR size + */ +.macro simplemask carsize, windowoffset + simplemask_helper (((\carsize - \windowoffset) / 0x1000) - 4), %eax + simplemask_helper (((\carsize - \windowoffset) / 0x1000)), %edx +.endm + +#if CacheSize > 0x10000 +#error Invalid CAR size, must be at most 64k. +#endif +#if CacheSize < 0x1000 +#error Invalid CAR size, must be at least 4k. This is a processor limitation. +#endif +#if (CacheSize & (0x1000 - 1)) +#error Invalid CAR size, is not a multiple of 4k. This is a processor limitation. +#endif + +#if CacheSize > 0x8000 + /* enable caching for 32K-64K using fixed mtrr */ movl $0x268, %ecx /* fix4k_c0000*/ - movl $0x06060606, %eax /* WB IO type */ - movl %eax, %edx + simplemask CacheSize, 0x8000 wrmsr - movl $0x269, %ecx - wrmsr #endif -#if CacheSize == 0x8000 - /* enable caching for 32K using fixed mtrr */ + /* enable caching for 0-32K using fixed mtrr */ movl $0x269, %ecx /* fix4k_c8000*/ - movl $0x06060606, %eax /* WB IO type */ - movl %eax, %edx + simplemask CacheSize, 0 wrmsr -#endif - /* enable caching for 16K/8K/4K using fixed mtrr */ - movl $0x269, %ecx /* fix4k_cc000*/ -#if CacheSize == 0x4000 - movl $0x06060606, %edx /* WB IO type */ -#endif -#if CacheSize == 0x2000 - movl $0x06060000, %edx /* WB IO type */ -#endif -#if CacheSize == 0x1000 - movl $0x06000000, %edx /* WB IO type */ -#endif - xorl %eax, %eax - wrmsr - - #else /* disable cache */ movl %cr0, %eax From c-d.hailfinger.devel.2006 at gmx.net Tue Jan 8 18:15:58 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue, 08 Jan 2008 18:15:58 +0100 Subject: [LinuxBIOS] [PATCH] rewrite generic x86 CAR code In-Reply-To: <4783AB26.40502@amd.com> References: <4776D885.7060800@gmx.net> <478257A1.8000809@gmx.net> <4782C672.6040805@amd.com> <4782D6C2.5080602@gmx.net> <4783A5BA.3060209@gmx.net> <4783AB26.40502@amd.com> Message-ID: <4783AFCE.2070409@gmx.net> On 08.01.2008 17:56, Marc Jones wrote: > Carl-Daniel Hailfinger wrote: > >> Next try, with feedback incorporated. The "part" parameter has been >> changed to an offset into CAR size expressed in bytes. >> >> This patch is an attempt at introducing 4k CAR size granularity for the >> generic x86 code. For the old supported CAR sizes, the newly generated >> code is equivalent, so it should be a no-brainer. >> >> Add a copyright header to the code, the header is derived from the one >> found in the same piece of code in v3. >> >> Signed-off-by: Carl-Daniel Hailfinger >> >> >> > > This looks good. Thanks for the iterations. > Acked-by: Marc Jones > Thanks, r3038. Will prepare similar patches for v2 AMD CAR and v3 x86 CAR. Regards, Carl-Daniel From svn at openbios.org Tue Jan 8 18:28:35 2008 From: svn at openbios.org (svn at openbios.org) Date: Tue, 8 Jan 2008 18:28:35 +0100 Subject: [LinuxBIOS] r3039 - trunk/LinuxBIOSv2/src/cpu/amd/car Message-ID: Author: hailfinger Date: 2008-01-08 18:28:35 +0100 (Tue, 08 Jan 2008) New Revision: 3039 Modified: trunk/LinuxBIOSv2/src/cpu/amd/car/cache_as_ram.inc Log: Remove some DOS line endings accidentially introduced in r3014. No code lines affected, so svn blame will not be messed up. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Carl-Daniel Hailfinger Modified: trunk/LinuxBIOSv2/src/cpu/amd/car/cache_as_ram.inc =================================================================== --- trunk/LinuxBIOSv2/src/cpu/amd/car/cache_as_ram.inc 2008-01-08 17:06:38 UTC (rev 3038) +++ trunk/LinuxBIOSv2/src/cpu/amd/car/cache_as_ram.inc 2008-01-08 17:28:35 UTC (rev 3039) @@ -1,6 +1,6 @@ /* * This file is part of the LinuxBIOS project. - * + * * Copyright (C) 2005-2007 Advanced Micro Devices, Inc. * * This program is free software; you can redistribute it and/or modify @@ -15,11 +15,11 @@ * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA - */ - + */ + #define CacheSize DCACHE_RAM_SIZE #define CacheBase (0xd0000 - CacheSize) - + /* leave some space for global variable to pass to RAM stage */ #define GlobalVarSize DCACHE_RAM_GLOBAL_VAR_SIZE @@ -36,7 +36,7 @@ /*for normal part %ebx already contain cpu_init_detected from fallback call */ cache_as_ram_setup: - + movb $0xA0, %al outb %al, $0x80 @@ -107,7 +107,7 @@ /* Clear all MTRRs */ xorl %edx, %edx movl $fixed_mtrr_msr, %esi - + clear_fixed_var_mtrr: lodsl (%esi), %eax testl %eax, %eax @@ -245,7 +245,7 @@ movb $0xA1, %al outb %al, $0x80 - + /* enable cache */ movl %cr0, %eax andl $0x9fffffff, %eax @@ -259,7 +259,7 @@ bt $8, %eax /*BSC */ jnc CAR_FAM10_ap #endif - + movb $0xA2, %al outb %al, $0x80 @@ -280,7 +280,7 @@ /* set up the stack pointer */ movl $(CacheBase + CacheSize - GlobalVarSize), %eax movl %eax, %esp - + movb $0xA3, %al outb %al, $0x80 @@ -316,7 +316,7 @@ jc roll_cfg rolb %cl, %bl roll_cfg: - + /* calculate stack pointer */ movl $CacheSizeAPStack, %eax mull %ebx @@ -337,7 +337,7 @@ /* Restore the BIST result */ movl %ebp, %eax - + /* We need to set ebp ? No need */ movl %esp, %ebp pushl %ebx /* init detected */ From info at coresystems.de Tue Jan 8 18:52:39 2008 From: info at coresystems.de (LinuxBIOS information) Date: Tue, 08 Jan 2008 18:52:39 +0100 Subject: [LinuxBIOS] r3038 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "hailfinger" checked in revision 3038 to the LinuxBIOS source repository and caused the following changes: Change Log: This patch is an attempt at introducing 4k CAR size granularity for the generic x86 CAR code. For the old supported CAR sizes, the newly generated code is equivalent, so it should be a no-brainer. Add a copyright header to the code, the header is derived from the one found in the same piece of code in v3. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Marc Jones Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3038&device=serengeti_cheetah_fam10&vendor=amd Compilation of tyan:s2735 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3038&device=s2735&vendor=tyan If something broke during this checkin please be a pain in hailfinger's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From c-d.hailfinger.devel.2006 at gmx.net Tue Jan 8 18:57:50 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue, 08 Jan 2008 18:57:50 +0100 Subject: [LinuxBIOS] [PATCH] v2: rewrite AMD K* CAR code Message-ID: <4783B99E.1030208@gmx.net> This patch is an attempt at introducing 4k CAR size granularity for the AMD x86 CAR code. For the old supported CAR sizes, the newly generated code is equivalent, so it should be a no-brainer. Benefits: * a nice code size reduction * less #ifdef clutter for Family 10h * paranoid checks for CAR size * clear abstractions Not tested, as I lack hardware working with v2. Signed-off-by: Carl-Daniel Hailfinger Index: LinuxBIOSv2-CARx86/src/cpu/amd/car/cache_as_ram.inc =================================================================== --- LinuxBIOSv2-CARx86/src/cpu/amd/car/cache_as_ram.inc (Revision 3039) +++ LinuxBIOSv2-CARx86/src/cpu/amd/car/cache_as_ram.inc (Arbeitskopie) @@ -2,6 +2,7 @@ * This file is part of the LinuxBIOS project. * * Copyright (C) 2005-2007 Advanced Micro Devices, Inc. + * Copyright (C) 2008 Carl-Daniel Hailfinger * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -120,82 +121,70 @@ jmp clear_fixed_var_mtrr clear_fixed_var_mtrr_out: -#if CacheSize == 0x10000 - /* enable caching for 64K using fixed mtrr */ - movl $0x268, %ecx /* fix4k_c0000*/ - #if CAR_FAM10 == 1 - movl $0x1e1e1e1e, %edx /* WB MEM type */ - #else - movl $0x06060606, %edx /* WB IO type */ - #endif - - movl %edx, %eax - wrmsr - movl $0x269, %ecx - wrmsr +/* 0x06 is the WB IO type for a given 4k segment. + * 0x1e is the MEM IO type for a given 4k segment (K10 and above). + * segs is the number of 4k segments in the area of the particular + * register we want to use for CAR. + * reg is the register where the IO type should be stored. + */ +.macro extractmask segs, reg +.if \segs <= 0 + /* The xorl here is superfluous because at the point of first execution + * of this macro, %eax and %edx are cleared. Later invocations of this + * macro will have a monotonically increasing segs parameter. + */ + xorl \reg, \reg +#if CAR_FAM10 == 1 +.elseif \segs == 1 + movl $0x1e000000, \reg /* WB MEM type */ +.elseif \segs == 2 + movl $0x1e1e0000, \reg /* WB MEM type */ +.elseif \segs == 3 + movl $0x1e1e1e00, \reg /* WB MEM type */ +.elseif \segs >= 4 + movl $0x1e1e1e1e, \reg /* WB MEM type */ +#else +.elseif \segs == 1 + movl $0x06000000, \reg /* WB IO type */ +.elseif \segs == 2 + movl $0x06060000, \reg /* WB IO type */ +.elseif \segs == 3 + movl $0x06060600, \reg /* WB IO type */ +.elseif \segs >= 4 + movl $0x06060606, \reg /* WB IO type */ #endif +.endif +.endm -#if CacheSize == 0xc000 - /* enable caching for 16K using fixed mtrr */ - movl $0x268, %ecx /* fix4k_c4000*/ - #if CAR_FAM10 == 1 - movl $0x1e1e1e1e, %edx /* WB MEM type */ - #else - movl $0x06060606, %edx /* WB IO type */ - #endif - xorl %eax, %eax - wrmsr - /* enable caching for 32K using fixed mtrr */ - movl $0x269, %ecx /* fix4k_c8000*/ - #if CAR_FAM10 == 1 - movl $0x1e1e1e1e, %edx /* WB MEM type */ - #else - movl $0x06060606, %edx /* WB IO type */ - #endif - movl %edx, %eax - wrmsr +/* size is the cache size in bytes we want to use for CAR. + * windowoffset is the 32k-aligned window into CAR size + */ +.macro simplemask carsize, windowoffset + simplemask_helper (((\carsize - \windowoffset) / 0x1000) - 4), %eax + simplemask_helper (((\carsize - \windowoffset) / 0x1000)), %edx +.endm + +#if CacheSize > 0x10000 +#error Invalid CAR size, must be at most 64k. #endif +#if CacheSize < 0x1000 +#error Invalid CAR size, must be at least 4k. This is a processor limitation. +#endif +#if (CacheSize & (0x1000 - 1)) +#error Invalid CAR size, is not a multiple of 4k. This is a processor limitation. +#endif - -#if CacheSize == 0x8000 - /* enable caching for 32K using fixed mtrr */ - movl $0x269, %ecx /* fix4k_c8000*/ - #if CAR_FAM10 == 1 - movl $0x1e1e1e1e, %edx /* WB MEM type */ - #else - movl $0x06060606, %edx /* WB IO type */ - #endif - movl %edx, %eax - wrmsr +#if CacheSize > 0x8000 + /* enable caching for 32K-64K using fixed mtrr */ + movl $0x268, %ecx /* fix4k_c0000*/ + simplemask CacheSize, 0x8000 + wrmsr #endif -#if CacheSize < 0x8000 - /* enable caching for 16K/8K/4K using fixed mtrr */ - movl $0x269, %ecx /* fix4k_cc000*/ - #if CacheSize == 0x4000 - #if CAR_FAM10 == 1 - movl $0x1e1e1e1e, %edx /* WB MEM type */ - #else - movl $0x06060606, %edx /* WB IO type */ - #endif - #endif - #if CacheSize == 0x2000 - #if CAR_FAM10 == 1 - movl $0x1e1e0000, %edx /* WB MEM type */ - #else - movl $0x06060000, %edx /* WB IO type */ - #endif - #endif - #if CacheSize == 0x1000 - #if CAR_FAM10 == 1 - movl $0x1e000000, %edx /* WB MEM type */ - #else - movl $0x06000000, %edx /* WB IO type */ - #endif - #endif - xorl %eax, %eax + /* enable caching for 0-32K using fixed mtrr */ + movl $0x269, %ecx /* fix4k_c8000*/ + simplemask CacheSize, 0 wrmsr -#endif /* enable memory access for first MBs using top_mem */ movl $TOP_MEM, %ecx From marc.jones at amd.com Tue Jan 8 19:13:12 2008 From: marc.jones at amd.com (Marc Jones) Date: Tue, 08 Jan 2008 11:13:12 -0700 Subject: [LinuxBIOS] [PATCH] v2: rewrite AMD K* CAR code In-Reply-To: <4783B99E.1030208@gmx.net> References: <4783B99E.1030208@gmx.net> Message-ID: <4783BD38.3050309@amd.com> Carl-Daniel Hailfinger wrote: > This patch is an attempt at introducing 4k CAR size granularity for the > AMD x86 CAR code. For the old supported CAR sizes, the newly > generated code is equivalent, so it should be a no-brainer. > > Benefits: > * a nice code size reduction > * less #ifdef clutter for Family 10h > * paranoid checks for CAR size > * clear abstractions > > Not tested, as I lack hardware working with v2. > > Signed-off-by: Carl-Daniel Hailfinger > Much better than it was. Thanks! Acked-by: Marc Jones -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From corey.osgood at gmail.com Tue Jan 8 19:22:14 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Tue, 08 Jan 2008 13:22:14 -0500 Subject: [LinuxBIOS] [PATCH] remove duplicated microcode updates for some Intel processors In-Reply-To: <20080108055601.87ncyk2w8osc48cc@www.smittys.pointclark.net> References: <47770D5D.7060108@gmx.net> <47771C26.9050001@gmail.com> <20071230000012.kli0uxn3ksosskc8@www.smittys.pointclark.net> <13426df10712292150n6f48ed54ya803992f2171c563@mail.gmail.com> <47833BC1.3090708@gmail.com> <20080108055601.87ncyk2w8osc48cc@www.smittys.pointclark.net> Message-ID: <4783BF56.8010304@gmail.com> joe at smittys.pointclark.net wrote: >> Microcode updates coming in the morning, if the abuild passes. >> >> -Corey >> >> > SWEET :-) > > > Thanks - Joe Well, it failed, but it was only one socket (603/604), and the problem's size. From rminnich at gmail.com Tue Jan 8 19:30:38 2008 From: rminnich at gmail.com (ron minnich) Date: Tue, 8 Jan 2008 10:30:38 -0800 Subject: [LinuxBIOS] [PATCH] v2: rewrite AMD K* CAR code In-Reply-To: <4783BD38.3050309@amd.com> References: <4783B99E.1030208@gmx.net> <4783BD38.3050309@amd.com> Message-ID: <13426df10801081030v241bd8e0rc50788b1bd2555a9@mail.gmail.com> On Jan 8, 2008 10:13 AM, Marc Jones wrote: > Much better than it was. Thanks! > Acked-by: Marc Jones > this is pretty critical stuff. I suggest we hold off on a commit until we get a test case. I can't test it either ... ron From info at coresystems.de Tue Jan 8 19:44:30 2008 From: info at coresystems.de (LinuxBIOS information) Date: Tue, 08 Jan 2008 19:44:30 +0100 Subject: [LinuxBIOS] r3039 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "hailfinger" checked in revision 3039 to the LinuxBIOS source repository and caused the following changes: Change Log: Remove some DOS line endings accidentially introduced in r3014. No code lines affected, so svn blame will not be messed up. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Carl-Daniel Hailfinger Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3039&device=serengeti_cheetah_fam10&vendor=amd Compilation of tyan:s2735 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3039&device=s2735&vendor=tyan If something broke during this checkin please be a pain in hailfinger's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From svn at openbios.org Tue Jan 8 20:14:16 2008 From: svn at openbios.org (svn at openbios.org) Date: Tue, 8 Jan 2008 20:14:16 +0100 Subject: [LinuxBIOS] r3040 - trunk/LinuxBIOSv2/src/cpu/x86/car Message-ID: Author: hailfinger Date: 2008-01-08 20:14:16 +0100 (Tue, 08 Jan 2008) New Revision: 3040 Modified: trunk/LinuxBIOSv2/src/cpu/x86/car/cache_as_ram.inc Log: Fix compilation of Tyan S2735 which was broken by accident in r3038. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Carl-Daniel Hailfinger Modified: trunk/LinuxBIOSv2/src/cpu/x86/car/cache_as_ram.inc =================================================================== --- trunk/LinuxBIOSv2/src/cpu/x86/car/cache_as_ram.inc 2008-01-08 17:28:35 UTC (rev 3039) +++ trunk/LinuxBIOSv2/src/cpu/x86/car/cache_as_ram.inc 2008-01-08 19:14:16 UTC (rev 3040) @@ -158,8 +158,8 @@ * windowoffset is the 32k-aligned window into CAR size */ .macro simplemask carsize, windowoffset - simplemask_helper (((\carsize - \windowoffset) / 0x1000) - 4), %eax - simplemask_helper (((\carsize - \windowoffset) / 0x1000)), %edx + extractmask (((\carsize - \windowoffset) / 0x1000) - 4), %eax + extractmask (((\carsize - \windowoffset) / 0x1000)), %edx .endm #if CacheSize > 0x10000 From Marc.Karasek at Sun.COM Tue Jan 8 20:09:59 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Tue, 08 Jan 2008 14:09:59 -0500 Subject: [LinuxBIOS] AMD SimNOW question Message-ID: <4783CA87.4070600@sun.com> I am trying to get LinuxBIOS and AMD SimNOW working. I tried to follow the how-to and have run into a brick wall. It gets to the point of compiling linuxbios. Originally it could not find the file linuxbios-svn-2950.tar.gz file under sources and was failing. I then got this revision via svn and created this file. I put it in the sources directory, now the patch file for linuxbios is failing. It took me a lot work to get to this point as I have been having proxy server problems. The machine I am building/testing with is in a lab and is behind the proxy. I am pretty close to getting this compiled. I already have a system setup with SimNOW (NDA version). Any help would be appreciated... -- /********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 *********************/ From c-d.hailfinger.devel.2006 at gmx.net Tue Jan 8 20:33:48 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue, 08 Jan 2008 20:33:48 +0100 Subject: [LinuxBIOS] [PATCH] v2: rewrite AMD K* CAR code In-Reply-To: <13426df10801081030v241bd8e0rc50788b1bd2555a9@mail.gmail.com> References: <4783B99E.1030208@gmx.net> <4783BD38.3050309@amd.com> <13426df10801081030v241bd8e0rc50788b1bd2555a9@mail.gmail.com> Message-ID: <4783D01C.4010404@gmx.net> Updated patch. This one actually compiles. The previous patch unfortunately was generated from the wrong tree. Diff between the previous patch and this one is: > Index: src/cpu/amd/car/cache_as_ram.inc > =================================================================== > --- src/cpu/amd/car/cache_as_ram.inc (Revision 3039) > +++ src/cpu/amd/car/cache_as_ram.inc (Revision 3040) > @@ -158,8 +158,8 @@ > * windowoffset is the 32k-aligned window into CAR size > */ > .macro simplemask carsize, windowoffset > - simplemask_helper (((\carsize - \windowoffset) / 0x1000) - 4), %eax > - simplemask_helper (((\carsize - \windowoffset) / 0x1000)), %edx > + extractmask (((\carsize - \windowoffset) / 0x1000) - 4), %eax > + extractmask (((\carsize - \windowoffset) / 0x1000)), %edx > .endm > > #if CacheSize > 0x10000 Full patch with Changelog included below: This patch is an attempt at introducing 4k CAR size granularity for the AMD x86 CAR code. For the old supported CAR sizes, the newly generated code is equivalent, so it should be a no-brainer. Benefits: * a nice code size reduction * less #ifdef clutter for Family 10h * paranoid checks for CAR size * clear abstractions Not tested, as I lack hardware working with v2. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Marc Jones Index: LinuxBIOSv2-CARx86/src/cpu/amd/car/cache_as_ram.inc =================================================================== --- LinuxBIOSv2-CARx86/src/cpu/amd/car/cache_as_ram.inc (Revision 3040) +++ LinuxBIOSv2-CARx86/src/cpu/amd/car/cache_as_ram.inc (Arbeitskopie) @@ -2,6 +2,7 @@ * This file is part of the LinuxBIOS project. * * Copyright (C) 2005-2007 Advanced Micro Devices, Inc. + * Copyright (C) 2008 Carl-Daniel Hailfinger * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -120,82 +121,70 @@ jmp clear_fixed_var_mtrr clear_fixed_var_mtrr_out: -#if CacheSize == 0x10000 - /* enable caching for 64K using fixed mtrr */ - movl $0x268, %ecx /* fix4k_c0000*/ - #if CAR_FAM10 == 1 - movl $0x1e1e1e1e, %edx /* WB MEM type */ - #else - movl $0x06060606, %edx /* WB IO type */ - #endif - - movl %edx, %eax - wrmsr - movl $0x269, %ecx - wrmsr +/* 0x06 is the WB IO type for a given 4k segment. + * 0x1e is the MEM IO type for a given 4k segment (K10 and above). + * segs is the number of 4k segments in the area of the particular + * register we want to use for CAR. + * reg is the register where the IO type should be stored. + */ +.macro extractmask segs, reg +.if \segs <= 0 + /* The xorl here is superfluous because at the point of first execution + * of this macro, %eax and %edx are cleared. Later invocations of this + * macro will have a monotonically increasing segs parameter. + */ + xorl \reg, \reg +#if CAR_FAM10 == 1 +.elseif \segs == 1 + movl $0x1e000000, \reg /* WB MEM type */ +.elseif \segs == 2 + movl $0x1e1e0000, \reg /* WB MEM type */ +.elseif \segs == 3 + movl $0x1e1e1e00, \reg /* WB MEM type */ +.elseif \segs >= 4 + movl $0x1e1e1e1e, \reg /* WB MEM type */ +#else +.elseif \segs == 1 + movl $0x06000000, \reg /* WB IO type */ +.elseif \segs == 2 + movl $0x06060000, \reg /* WB IO type */ +.elseif \segs == 3 + movl $0x06060600, \reg /* WB IO type */ +.elseif \segs >= 4 + movl $0x06060606, \reg /* WB IO type */ #endif +.endif +.endm -#if CacheSize == 0xc000 - /* enable caching for 16K using fixed mtrr */ - movl $0x268, %ecx /* fix4k_c4000*/ - #if CAR_FAM10 == 1 - movl $0x1e1e1e1e, %edx /* WB MEM type */ - #else - movl $0x06060606, %edx /* WB IO type */ - #endif - xorl %eax, %eax - wrmsr - /* enable caching for 32K using fixed mtrr */ - movl $0x269, %ecx /* fix4k_c8000*/ - #if CAR_FAM10 == 1 - movl $0x1e1e1e1e, %edx /* WB MEM type */ - #else - movl $0x06060606, %edx /* WB IO type */ - #endif - movl %edx, %eax - wrmsr +/* size is the cache size in bytes we want to use for CAR. + * windowoffset is the 32k-aligned window into CAR size + */ +.macro simplemask carsize, windowoffset + extractmask (((\carsize - \windowoffset) / 0x1000) - 4), %eax + extractmask (((\carsize - \windowoffset) / 0x1000)), %edx +.endm + +#if CacheSize > 0x10000 +#error Invalid CAR size, must be at most 64k. #endif +#if CacheSize < 0x1000 +#error Invalid CAR size, must be at least 4k. This is a processor limitation. +#endif +#if (CacheSize & (0x1000 - 1)) +#error Invalid CAR size, is not a multiple of 4k. This is a processor limitation. +#endif - -#if CacheSize == 0x8000 - /* enable caching for 32K using fixed mtrr */ - movl $0x269, %ecx /* fix4k_c8000*/ - #if CAR_FAM10 == 1 - movl $0x1e1e1e1e, %edx /* WB MEM type */ - #else - movl $0x06060606, %edx /* WB IO type */ - #endif - movl %edx, %eax - wrmsr +#if CacheSize > 0x8000 + /* enable caching for 32K-64K using fixed mtrr */ + movl $0x268, %ecx /* fix4k_c0000*/ + simplemask CacheSize, 0x8000 + wrmsr #endif -#if CacheSize < 0x8000 - /* enable caching for 16K/8K/4K using fixed mtrr */ - movl $0x269, %ecx /* fix4k_cc000*/ - #if CacheSize == 0x4000 - #if CAR_FAM10 == 1 - movl $0x1e1e1e1e, %edx /* WB MEM type */ - #else - movl $0x06060606, %edx /* WB IO type */ - #endif - #endif - #if CacheSize == 0x2000 - #if CAR_FAM10 == 1 - movl $0x1e1e0000, %edx /* WB MEM type */ - #else - movl $0x06060000, %edx /* WB IO type */ - #endif - #endif - #if CacheSize == 0x1000 - #if CAR_FAM10 == 1 - movl $0x1e000000, %edx /* WB MEM type */ - #else - movl $0x06000000, %edx /* WB IO type */ - #endif - #endif - xorl %eax, %eax + /* enable caching for 0-32K using fixed mtrr */ + movl $0x269, %ecx /* fix4k_c8000*/ + simplemask CacheSize, 0 wrmsr -#endif /* enable memory access for first MBs using top_mem */ movl $TOP_MEM, %ecx From info at coresystems.de Tue Jan 8 20:59:43 2008 From: info at coresystems.de (LinuxBIOS information) Date: Tue, 08 Jan 2008 20:59:43 +0100 Subject: [LinuxBIOS] r3040 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "hailfinger" checked in revision 3040 to the LinuxBIOS source repository and caused the following changes: Change Log: Fix compilation of Tyan S2735 which was broken by accident in r3038. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Carl-Daniel Hailfinger Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3040&device=serengeti_cheetah_fam10&vendor=amd Compilation of tyan:s2735 has been fixed If something broke during this checkin please be a pain in hailfinger's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From myles at pel.cs.byu.edu Tue Jan 8 21:23:39 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Tue, 8 Jan 2008 13:23:39 -0700 Subject: [LinuxBIOS] AMD SimNOW question In-Reply-To: <4783CA87.4070600@sun.com> References: <4783CA87.4070600@sun.com> Message-ID: <2831fecf0801081223u25f7a96cheae2779637cf4189@mail.gmail.com> On Jan 8, 2008 12:09 PM, Marc Karasek wrote: > I am trying to get LinuxBIOS and AMD SimNOW working. > > I tried to follow the how-to and have run into a brick wall. > > It gets to the point of compiling linuxbios. Originally it could not > find the file linuxbios-svn-2950.tar.gz file under sources and was > failing. I then got this revision via svn and created this file. I put > it in the sources directory, now the patch file for linuxbios is failing. Here's my guess: When you got the revision and made the tarball, your directory structure ended up wrong so the patch won't apply. When you check it out from svn you get a LinuxBIOSv2/* and you need a svn/* If that doesn't help, I don't have enough information to help you. Are you building for fam10 or the original Serengeti_cheetah? Which payload are you using? What patch is failing? What's the error message? I just built LAB payloads for both versions of Serengeti Cheetah, and they worked for me. Myles > It took me a lot work to get to this point as I have been having proxy > server problems. The machine I am building/testing with is in a lab and > is behind the proxy. > > I am pretty close to getting this compiled. I already have a system > setup with SimNOW (NDA version). Any help would be appreciated... > > > -- > /********************* > Marc Karasek > MTS > Sun Microsystems > mailto:marc.karasek at sun.com > ph:770.360.6415 > *********************/ > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > From jordan.crouse at amd.com Tue Jan 8 21:42:10 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Tue, 8 Jan 2008 13:42:10 -0700 Subject: [LinuxBIOS] AMD SimNOW question In-Reply-To: <2831fecf0801081223u25f7a96cheae2779637cf4189@mail.gmail.com> References: <4783CA87.4070600@sun.com> <2831fecf0801081223u25f7a96cheae2779637cf4189@mail.gmail.com> Message-ID: <20080108204210.GB28312@cosmic.amd.com> On 08/01/08 13:23 -0700, Myles Watson wrote: > On Jan 8, 2008 12:09 PM, Marc Karasek wrote: > > I am trying to get LinuxBIOS and AMD SimNOW working. > > > > I tried to follow the how-to and have run into a brick wall. > > > > It gets to the point of compiling linuxbios. Originally it could not > > find the file linuxbios-svn-2950.tar.gz file under sources and was > > failing. I then got this revision via svn and created this file. I put > > it in the sources directory, now the patch file for linuxbios is failing. > > Here's my guess: When you got the revision and made the tarball, your > directory structure ended up wrong so the patch won't apply. When you > check it out from svn you get a LinuxBIOSv2/* and you need a svn/* Thats probably right - it would be interesting to figure out why SVN isn't working for you - this is the first time we've had a general SVN failure like this. Maybe we need to start using qa.linuxbios.org to as a backup for SVN failures. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From myles at pel.cs.byu.edu Tue Jan 8 22:20:49 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Tue, 8 Jan 2008 14:20:49 -0700 Subject: [LinuxBIOS] Expand linuxbiosv3 support In-Reply-To: <20080108203752.GA28312@cosmic.amd.com> References: <20071206223914.GB4092@cosmic.amd.com> <00f901c83860$3bfad7d0$4b23040a@chimp> <20071206234649.GA6114@cosmic.amd.com> <010c01c838df$226f2170$4b23040a@chimp> <20071207155811.GE6784@cosmic.amd.com> <2831fecf0801081214q6ee1f337raccc91bf32815ca8@mail.gmail.com> <20080108203752.GA28312@cosmic.amd.com> Message-ID: <2831fecf0801081320k32b4d9e2p83fecff3ad59ef6@mail.gmail.com> This patch is Jordan's buildrom patch with a few additions, so I'm including his original message: [BUILDROM] Expand linuxbiosv3 support Add more generic support for LinuxBIOSv3 - add specialized package for v3, and add support for using LAR to put it all together. Also add expanded (and better) option ROM support, though we're not actually using it right away. Myles again: It also changes LINUXBIOS variables to LBV2 unless they are used for both. I added dependencies between vendors that don't have any v3 platforms and LINUXBIOS_V2. One of the changes Jordan made was to always build v3 with no payload and then add it later with any binary blobs that might be needed. This way you can change them without rebuilding v3. Signed-off-by: Myles Watson -------------- next part -------------- A non-text attachment was scrubbed... Name: v3.patch Type: text/x-patch Size: 56888 bytes Desc: not available URL: From rminnich at gmail.com Tue Jan 8 23:00:11 2008 From: rminnich at gmail.com (ron minnich) Date: Tue, 8 Jan 2008 14:00:11 -0800 Subject: [LinuxBIOS] [PATCH] v2: rewrite AMD K* CAR code In-Reply-To: <4783D01C.4010404@gmx.net> References: <4783B99E.1030208@gmx.net> <4783BD38.3050309@amd.com> <13426df10801081030v241bd8e0rc50788b1bd2555a9@mail.gmail.com> <4783D01C.4010404@gmx.net> Message-ID: <13426df10801081400m1905129bxaee8fbef30d7d5a3@mail.gmail.com> Actually, if you all want to commit this, I can try it on the sis board this week. thanks ron From Marc.Karasek at Sun.COM Tue Jan 8 22:58:12 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Tue, 08 Jan 2008 16:58:12 -0500 Subject: [LinuxBIOS] AMD SimNOW question In-Reply-To: <20080108204210.GB28312@cosmic.amd.com> References: <4783CA87.4070600@sun.com> <2831fecf0801081223u25f7a96cheae2779637cf4189@mail.gmail.com> <20080108204210.GB28312@cosmic.amd.com> Message-ID: <4783F1F4.1070806@sun.com> I t has to do with the proxy server here at Sun. I have setup to use it by editing the ~/.subversion/servers file, but it still will not properly do the proxy when I have to do a svn co svn://xxx/yyy. It seems to work ok for http and https checkouts. I really hate proxy servers... /********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 *********************/ Jordan Crouse wrote: > On 08/01/08 13:23 -0700, Myles Watson wrote: > >> On Jan 8, 2008 12:09 PM, Marc Karasek wrote: >> >>> I am trying to get LinuxBIOS and AMD SimNOW working. >>> >>> I tried to follow the how-to and have run into a brick wall. >>> >>> It gets to the point of compiling linuxbios. Originally it could not >>> find the file linuxbios-svn-2950.tar.gz file under sources and was >>> failing. I then got this revision via svn and created this file. I put >>> it in the sources directory, now the patch file for linuxbios is failing. >>> >> Here's my guess: When you got the revision and made the tarball, your >> directory structure ended up wrong so the patch won't apply. When you >> check it out from svn you get a LinuxBIOSv2/* and you need a svn/* >> > > Thats probably right - it would be interesting to figure out why SVN isn't > working for you - this is the first time we've had a general SVN failure > like this. > > Maybe we need to start using qa.linuxbios.org to as a backup for SVN > failures. > > Jordan > From Marc.Karasek at Sun.COM Tue Jan 8 23:01:31 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Tue, 08 Jan 2008 17:01:31 -0500 Subject: [LinuxBIOS] AMD SimNOW question In-Reply-To: <2831fecf0801081223u25f7a96cheae2779637cf4189@mail.gmail.com> References: <4783CA87.4070600@sun.com> <2831fecf0801081223u25f7a96cheae2779637cf4189@mail.gmail.com> Message-ID: <4783F2BB.8000902@sun.com> You are right. I saw that it needed the files under svn/. So I moved the files into this directory under sources. This was from the svn co I did for version 2950. Could I use the tip of the tree for this or is it better to use version 2950? Now it needs the patch for the compile problems, ld, etc.. for Fedora 8. Progress no matter how slow is progress, I guess...................... :-) /********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 *********************/ Myles Watson wrote: > On Jan 8, 2008 12:09 PM, Marc Karasek wrote: > >> I am trying to get LinuxBIOS and AMD SimNOW working. >> >> I tried to follow the how-to and have run into a brick wall. >> >> It gets to the point of compiling linuxbios. Originally it could not >> find the file linuxbios-svn-2950.tar.gz file under sources and was >> failing. I then got this revision via svn and created this file. I put >> it in the sources directory, now the patch file for linuxbios is failing. >> > > Here's my guess: When you got the revision and made the tarball, your > directory structure ended up wrong so the patch won't apply. When you > check it out from svn you get a LinuxBIOSv2/* and you need a svn/* > > If that doesn't help, I don't have enough information to help you. > Are you building for fam10 or the original Serengeti_cheetah? Which > payload are you using? What patch is failing? What's the error > message? > > I just built LAB payloads for both versions of Serengeti Cheetah, and > they worked for me. > > Myles > > >> It took me a lot work to get to this point as I have been having proxy >> server problems. The machine I am building/testing with is in a lab and >> is behind the proxy. >> >> I am pretty close to getting this compiled. I already have a system >> setup with SimNOW (NDA version). Any help would be appreciated... >> >> >> -- >> /********************* >> Marc Karasek >> MTS >> Sun Microsystems >> mailto:marc.karasek at sun.com >> ph:770.360.6415 >> *********************/ >> >> >> -- >> linuxbios mailing list >> linuxbios at linuxbios.org >> http://www.linuxbios.org/mailman/listinfo/linuxbios >> >> From ward at gnu.org Tue Jan 8 23:09:03 2008 From: ward at gnu.org (Ward Vandewege) Date: Tue, 8 Jan 2008 17:09:03 -0500 Subject: [LinuxBIOS] [PATCH] v2: rewrite AMD K* CAR code In-Reply-To: <13426df10801081400m1905129bxaee8fbef30d7d5a3@mail.gmail.com> References: <4783B99E.1030208@gmx.net> <4783BD38.3050309@amd.com> <13426df10801081030v241bd8e0rc50788b1bd2555a9@mail.gmail.com> <4783D01C.4010404@gmx.net> <13426df10801081400m1905129bxaee8fbef30d7d5a3@mail.gmail.com> Message-ID: <20080108220903.GA25607@localdomain> On Tue, Jan 08, 2008 at 02:00:11PM -0800, ron minnich wrote: > Actually, if you all want to commit this, I can try it on the sis > board this week. Speaking of the SIS board; is it for sale yet? I can't find it anywhere... Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From myles at pel.cs.byu.edu Tue Jan 8 23:10:45 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Tue, 8 Jan 2008 15:10:45 -0700 Subject: [LinuxBIOS] AMD SimNOW question In-Reply-To: <4783F2BB.8000902@sun.com> References: <4783CA87.4070600@sun.com> <2831fecf0801081223u25f7a96cheae2779637cf4189@mail.gmail.com> <4783F2BB.8000902@sun.com> Message-ID: <01e801c85243$52ac9e30$a023040a@chimp> > -----Original Message----- > From: Marc.Karasek at Sun.COM [mailto:Marc.Karasek at Sun.COM] > Sent: Tuesday, January 08, 2008 3:02 PM > To: Myles Watson > Cc: LinuxBIOS > Subject: Re: [LinuxBIOS] AMD SimNOW question > > You are right. I saw that it needed the files under svn/. So I moved > the files into this directory under sources. This was from the svn co I > did for version 2950. Could I use the tip of the tree for this or is > it better to use version 2950? > > Now it needs the patch for the compile problems, ld, etc.. for Fedora 8. > > Progress no matter how slow is progress, I guess...................... :- > ) > You can use the head of the tree. Buildrom is supposed to be a stable version, so a working version is always specified for v2. Good luck, Myles > /********************* > Marc Karasek > MTS > Sun Microsystems > mailto:marc.karasek at sun.com > ph:770.360.6415 > *********************/ > > > > Myles Watson wrote: > > On Jan 8, 2008 12:09 PM, Marc Karasek wrote: > > > >> I am trying to get LinuxBIOS and AMD SimNOW working. > >> > >> I tried to follow the how-to and have run into a brick wall. > >> > >> It gets to the point of compiling linuxbios. Originally it could not > >> find the file linuxbios-svn-2950.tar.gz file under sources and was > >> failing. I then got this revision via svn and created this file. I > put > >> it in the sources directory, now the patch file for linuxbios is > failing. > >> > > > > Here's my guess: When you got the revision and made the tarball, your > > directory structure ended up wrong so the patch won't apply. When you > > check it out from svn you get a LinuxBIOSv2/* and you need a svn/* > > > > If that doesn't help, I don't have enough information to help you. > > Are you building for fam10 or the original Serengeti_cheetah? Which > > payload are you using? What patch is failing? What's the error > > message? > > > > I just built LAB payloads for both versions of Serengeti Cheetah, and > > they worked for me. > > > > Myles > > > > > >> It took me a lot work to get to this point as I have been having proxy > >> server problems. The machine I am building/testing with is in a lab > and > >> is behind the proxy. > >> > >> I am pretty close to getting this compiled. I already have a system > >> setup with SimNOW (NDA version). Any help would be appreciated... > >> > >> > >> -- > >> /********************* > >> Marc Karasek > >> MTS > >> Sun Microsystems > >> mailto:marc.karasek at sun.com > >> ph:770.360.6415 > >> *********************/ > >> > >> > >> -- > >> linuxbios mailing list > >> linuxbios at linuxbios.org > >> http://www.linuxbios.org/mailman/listinfo/linuxbios > >> > >> From jordan.crouse at amd.com Tue Jan 8 23:21:25 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Tue, 8 Jan 2008 15:21:25 -0700 Subject: [LinuxBIOS] AMD SimNOW question In-Reply-To: <01e801c85243$52ac9e30$a023040a@chimp> References: <4783CA87.4070600@sun.com> <2831fecf0801081223u25f7a96cheae2779637cf4189@mail.gmail.com> <4783F2BB.8000902@sun.com> <01e801c85243$52ac9e30$a023040a@chimp> Message-ID: <20080108222125.GC28312@cosmic.amd.com> On 08/01/08 15:10 -0700, Myles Watson wrote: > > > > -----Original Message----- > > From: Marc.Karasek at Sun.COM [mailto:Marc.Karasek at Sun.COM] > > Sent: Tuesday, January 08, 2008 3:02 PM > > To: Myles Watson > > Cc: LinuxBIOS > > Subject: Re: [LinuxBIOS] AMD SimNOW question > > > > You are right. I saw that it needed the files under svn/. So I moved > > the files into this directory under sources. This was from the svn co I > > did for version 2950. Could I use the tip of the tree for this or is > > it better to use version 2950? > > > > Now it needs the patch for the compile problems, ld, etc.. for Fedora 8. > > > > Progress no matter how slow is progress, I guess...................... :- > > ) > > > > You can use the head of the tree. Buildrom is supposed to be a stable > version, so a working version is always specified for v2. Yes - you can move up. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From peter at stuge.se Tue Jan 8 23:36:38 2008 From: peter at stuge.se (Peter Stuge) Date: Tue, 8 Jan 2008 23:36:38 +0100 Subject: [LinuxBIOS] [PATCH] v2: rewrite AMD K* CAR code In-Reply-To: <13426df10801081400m1905129bxaee8fbef30d7d5a3@mail.gmail.com> References: <4783B99E.1030208@gmx.net> <4783BD38.3050309@amd.com> <13426df10801081030v241bd8e0rc50788b1bd2555a9@mail.gmail.com> <4783D01C.4010404@gmx.net> <13426df10801081400m1905129bxaee8fbef30d7d5a3@mail.gmail.com> Message-ID: <20080108223638.25144.qmail@stuge.se> On Tue, Jan 08, 2008 at 02:00:11PM -0800, ron minnich wrote: > Actually, if you all want to commit this, I can try it on the sis > board this week. I think it looks good, please try it on hardware. My alix and LPC dongle was stolen in Berlin otherwise I'd help test. (Yes, laptop too.) //Peter From Marc.Karasek at Sun.COM Tue Jan 8 23:38:55 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Tue, 08 Jan 2008 17:38:55 -0500 Subject: [LinuxBIOS] AMD SimNOW question In-Reply-To: <20080108222125.GC28312@cosmic.amd.com> References: <4783CA87.4070600@sun.com> <2831fecf0801081223u25f7a96cheae2779637cf4189@mail.gmail.com> <4783F2BB.8000902@sun.com> <01e801c85243$52ac9e30$a023040a@chimp> <20080108222125.GC28312@cosmic.amd.com> Message-ID: <4783FB7F.4000205@sun.com> I have found the main problem with svn. It looks like if you use svn co http:// it will use the proxy settings under servers. If you do a svn co svn:// it tries to do a dns lookup, which fails behind a proxy server :-(. I have not been able to find any info on setting svn up to use a proxy when doing svn:// type checkouts. /********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 *********************/ Jordan Crouse wrote: > On 08/01/08 15:10 -0700, Myles Watson wrote: > >> >>> -----Original Message----- >>> From: Marc.Karasek at Sun.COM [mailto:Marc.Karasek at Sun.COM] >>> Sent: Tuesday, January 08, 2008 3:02 PM >>> To: Myles Watson >>> Cc: LinuxBIOS >>> Subject: Re: [LinuxBIOS] AMD SimNOW question >>> >>> You are right. I saw that it needed the files under svn/. So I moved >>> the files into this directory under sources. This was from the svn co I >>> did for version 2950. Could I use the tip of the tree for this or is >>> it better to use version 2950? >>> >>> Now it needs the patch for the compile problems, ld, etc.. for Fedora 8. >>> >>> Progress no matter how slow is progress, I guess...................... :- >>> ) >>> >>> >> You can use the head of the tree. Buildrom is supposed to be a stable >> version, so a working version is always specified for v2. >> > > Yes - you can move up. > > Jordan > > From Marc.Karasek at Sun.COM Tue Jan 8 23:41:35 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Tue, 08 Jan 2008 17:41:35 -0500 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: <2831fecf0801070837n4c22d036t38254f5ee02d14d1@mail.gmail.com> References: <477CF25C.7070901@sun.com> <477D2A90.3070001@sun.com> <13426df10801031043o3ea5df06r62f51e7c63fabaaa@mail.gmail.com> <477D507E.4030106@sun.com> <477E8A50.2080408@sun.com> <477EB7A1.80406@sun.com> <47824212.3030307@sun.com> <2831fecf0801070837n4c22d036t38254f5ee02d14d1@mail.gmail.com> Message-ID: <4783FC1F.7070309@sun.com> So what is the general consensus ==1 or >0? Also, I think I know how to commit back to the tree, but do I need a user account for this? /********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 *********************/ Myles Watson wrote: > On Jan 7, 2008 8:15 AM, Marc Karasek wrote: > >> After looking at the script Myles sent, I immediately saw the problem. >> I forgot that if [ $build_id ] will always be true because it checks to >> see if it is defined not the value of build_id. My bad, sorry. >> >> I have made the changes and added an == 1 to the if statement. Attached >> is the new and I hope final patch file for this. >> >> > It works for me (it doesn't add the load option.) > > Sorry to be picky, but it seems like this breaks if they mention > build-id more than once in the help in the future. I think >0 would > be better than ==1. > > With that fixed, or if no one thinks that will ever happen: > Acked-by: Myles Watson > >> /********************* >> Marc Karasek >> MTS >> Sun Microsystems >> mailto:marc.karasek at sun.com >> ph:770.360.6415 >> *********************/ >> >> >> >> Ed Swierk wrote: >> >> >>> On 1/4/08, Marc Karasek wrote: >>> >>> >>>> I made a test script and ran it and it sets build_id = 1 properly. I >>>> have also included this script. >>>> >>>> >>> The problem is that on Planet Bourne, zero means true and nonzero means false. >>> >>> --Ed >>> >>> From rminnich at gmail.com Tue Jan 8 23:48:44 2008 From: rminnich at gmail.com (ron minnich) Date: Tue, 8 Jan 2008 14:48:44 -0800 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: <4783FC1F.7070309@sun.com> References: <477CF25C.7070901@sun.com> <477D507E.4030106@sun.com> <477E8A50.2080408@sun.com> <477EB7A1.80406@sun.com> <47824212.3030307@sun.com> <2831fecf0801070837n4c22d036t38254f5ee02d14d1@mail.gmail.com> <4783FC1F.7070309@sun.com> Message-ID: <13426df10801081448s299b24b7uc36fe424a5859bc2@mail.gmail.com> On Jan 8, 2008 2:41 PM, Marc Karasek wrote: > So what is the general consensus ==1 or >0? I prefer > 0 > > Also, I think I know how to commit back to the tree, but do I need a > user account for this? yes, but get us the patch and we'll deal with the commit issue seperately. ron From peter at stuge.se Tue Jan 8 23:53:59 2008 From: peter at stuge.se (Peter Stuge) Date: Tue, 8 Jan 2008 23:53:59 +0100 Subject: [LinuxBIOS] AMD SimNOW question In-Reply-To: <4783FB7F.4000205@sun.com> References: <4783CA87.4070600@sun.com> <2831fecf0801081223u25f7a96cheae2779637cf4189@mail.gmail.com> <4783F2BB.8000902@sun.com> <01e801c85243$52ac9e30$a023040a@chimp> <20080108222125.GC28312@cosmic.amd.com> <4783FB7F.4000205@sun.com> Message-ID: <20080108225359.29612.qmail@stuge.se> On Tue, Jan 08, 2008 at 05:38:55PM -0500, Marc Karasek wrote: > If you do a svn co svn:// it tries to do a dns lookup, which fails > behind a proxy server :-(. I have not been able to find any info > on setting svn up to use a proxy when doing svn:// type checkouts. svn:// is a plain TCP connection. Is it a SOCKS proxy? An HTTP proxy of course may not be able to help. //Peter From myles at pel.cs.byu.edu Tue Jan 8 23:54:15 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Tue, 8 Jan 2008 15:54:15 -0700 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: <4783FC1F.7070309@sun.com> References: <477CF25C.7070901@sun.com> <477D507E.4030106@sun.com> <477E8A50.2080408@sun.com> <477EB7A1.80406@sun.com> <47824212.3030307@sun.com> <2831fecf0801070837n4c22d036t38254f5ee02d14d1@mail.gmail.com> <4783FC1F.7070309@sun.com> Message-ID: <2831fecf0801081454m71bb3ff3x3b2da3eb60d4aa37@mail.gmail.com> On Jan 8, 2008 3:41 PM, Marc Karasek wrote: > So what is the general consensus ==1 or >0? I like the idea of using grep. It seems much cleaner, and avoids that issue. The other sticking point for the patch the changes in src/arch/i386/lib/id.lds (See Ed's last message.) Myles > Also, I think I know how to commit back to the tree, but do I need a > user account for this? > > /********************* > Marc Karasek > MTS > Sun Microsystems > mailto:marc.karasek at sun.com > ph:770.360.6415 > *********************/ > > > > > Myles Watson wrote: > > On Jan 7, 2008 8:15 AM, Marc Karasek wrote: > > > >> After looking at the script Myles sent, I immediately saw the problem. > >> I forgot that if [ $build_id ] will always be true because it checks to > >> see if it is defined not the value of build_id. My bad, sorry. > >> > >> I have made the changes and added an == 1 to the if statement. Attached > >> is the new and I hope final patch file for this. > >> > >> > > It works for me (it doesn't add the load option.) > > > > Sorry to be picky, but it seems like this breaks if they mention > > build-id more than once in the help in the future. I think >0 would > > be better than ==1. > > > > With that fixed, or if no one thinks that will ever happen: > > Acked-by: Myles Watson > > > >> /********************* > >> Marc Karasek > >> MTS > >> Sun Microsystems > >> mailto:marc.karasek at sun.com > >> ph:770.360.6415 > >> *********************/ > >> > >> > >> > >> Ed Swierk wrote: > >> > >> > >>> On 1/4/08, Marc Karasek wrote: > >>> > >>> > >>>> I made a test script and ran it and it sets build_id = 1 properly. I > >>>> have also included this script. > >>>> > >>>> > >>> The problem is that on Planet Bourne, zero means true and nonzero means false. > >>> > >>> --Ed > >>> > >>> > From dhbarr at gozelle.com Wed Jan 9 00:16:25 2008 From: dhbarr at gozelle.com (David H. Barr) Date: Tue, 8 Jan 2008 17:16:25 -0600 Subject: [LinuxBIOS] AMD SimNOW question In-Reply-To: <20080108225359.29612.qmail@stuge.se> References: <4783CA87.4070600@sun.com> <2831fecf0801081223u25f7a96cheae2779637cf4189@mail.gmail.com> <4783F2BB.8000902@sun.com> <01e801c85243$52ac9e30$a023040a@chimp> <20080108222125.GC28312@cosmic.amd.com> <4783FB7F.4000205@sun.com> <20080108225359.29612.qmail@stuge.se> Message-ID: On Jan 8, 2008 4:53 PM, Peter Stuge wrote: > On Tue, Jan 08, 2008 at 05:38:55PM -0500, Marc Karasek wrote: > > If you do a svn co svn:// it tries to do a dns lookup, which fails > > behind a proxy server :-(. I have not been able to find any info > > on setting svn up to use a proxy when doing svn:// type checkouts. > > svn:// is a plain TCP connection. Is it a SOCKS proxy? An HTTP proxy > of course may not be able to help. svn co svn://80.190.231.112/... ? It's an ugly hack, but will it work? -dhbarr. From myles at pel.cs.byu.edu Wed Jan 9 00:30:52 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Tue, 8 Jan 2008 16:30:52 -0700 Subject: [LinuxBIOS] LinuxBIOSv3 Config files Message-ID: <2831fecf0801081530m3a3c0a99n3222c8b164f2e110@mail.gmail.com> In buildrom, I want to be able to set the variables I care about, then use make oldconfig to choose the (hopefully) sane defaults for the rest of the options. Here is a sample .config file that I'd like to use: ----------------------Begin .config -------------------------------- # # General setup # CONFIG_LOCALVERSION="-buildrom" # # Mainboard # CONFIG_VENDOR_EMULATION=y CONFIG_MAINBOARD_NAME="emulation/qemu-x86" CONFIG_BOARD_EMULATION_QEMU_X86=y CONFIG_LINUXBIOS_ROMSIZE_KB_1024=y CONFIG_ARCH_X86=y CONFIG_ARCH="x86" # # Devices # CONFIG_PCI_OPTION_ROM_RUN=y # # Payload # CONFIG_PAYLOAD_NONE=y ----------------------End .config -------------------------------- Unfortunately, I get this warning and it requires me to hit enter on every line (suboptimal for an automated build script.) The defaults are what I want, though. Kconfig:102:warning: defaults for choice values not supported Is there a reason why we don't let people use the defaults? Myles From jordan.crouse at amd.com Wed Jan 9 00:38:49 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Tue, 8 Jan 2008 16:38:49 -0700 Subject: [LinuxBIOS] LinuxBIOSv3 Config files In-Reply-To: <2831fecf0801081530m3a3c0a99n3222c8b164f2e110@mail.gmail.com> References: <2831fecf0801081530m3a3c0a99n3222c8b164f2e110@mail.gmail.com> Message-ID: <20080108233849.GD28312@cosmic.amd.com> On 08/01/08 16:30 -0700, Myles Watson wrote: > In buildrom, I want to be able to set the variables I care about, then > use make oldconfig to choose the (hopefully) sane defaults for the > rest of the options. That would make sense, but I'm not sure if there is a way to make kconfig do that. At least, in my experience, we've always needed to the user to build the entire .config, to avoid oldconfig asking questions. But there might be a conf option that can avoid that. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From joe at smittys.pointclark.net Wed Jan 9 00:58:32 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Tue, 08 Jan 2008 18:58:32 -0500 Subject: [LinuxBIOS] [PATCH] remove duplicated microcode updates for some Intel processors In-Reply-To: <4783BF56.8010304@gmail.com> References: <47770D5D.7060108@gmx.net> <47771C26.9050001@gmail.com> <20071230000012.kli0uxn3ksosskc8@www.smittys.pointclark.net> <13426df10712292150n6f48ed54ya803992f2171c563@mail.gmail.com> <47833BC1.3090708@gmail.com> <20080108055601.87ncyk2w8osc48cc@www.smittys.pointclark.net> <4783BF56.8010304@gmail.com> Message-ID: <20080108185832.6trpbtd5k4wsk0ok@www.smittys.pointclark.net> Quoting Corey Osgood : > joe at smittys.pointclark.net wrote: >>> Microcode updates coming in the morning, if the abuild passes. >>> >>> -Corey >>> >>> >> SWEET :-) >> >> >> Thanks - Joe > > Well, it failed, but it was only one socket (603/604), and the problem's > size. > Hmmmmm, not so sweet, how big is the microcode? Thanks - Joe From marc.jones at amd.com Wed Jan 9 00:54:29 2008 From: marc.jones at amd.com (Marc Jones) Date: Tue, 08 Jan 2008 16:54:29 -0700 Subject: [LinuxBIOS] PATCH: lx car that returns from disable_car In-Reply-To: <13426df10801071610s568a8d22yb3247551bdc4a1af@mail.gmail.com> References: <13426df10801041405h1d3e0f1eocdfba04c34144eb9@mail.gmail.com> <4782A542.6030109@amd.com> <13426df10801071546j3eaba5c8m6f7bcf3facb9f7f2@mail.gmail.com> <4782BC5B.4000504@amd.com> <13426df10801071610s568a8d22yb3247551bdc4a1af@mail.gmail.com> Message-ID: <47840D35.9060701@amd.com> ron minnich wrote: > On Jan 7, 2008 3:57 PM, Marc Jones wrote: > >> The hlt is really the right thing to do and I would rather it be in >> there. Correctly behaving jtag should be able to handle it. I understand >> clearing the fifo so do it before the hlt. > > OK. How about we do a bunch of outs and a hlt(). > > I'll ack any patch you want to make. > > ron > How about this? Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: die_hlt.patch URL: From peter at stuge.se Wed Jan 9 01:12:52 2008 From: peter at stuge.se (Peter Stuge) Date: Wed, 9 Jan 2008 01:12:52 +0100 Subject: [LinuxBIOS] PATCH: lx car that returns from disable_car In-Reply-To: <47840D35.9060701@amd.com> References: <13426df10801041405h1d3e0f1eocdfba04c34144eb9@mail.gmail.com> <4782A542.6030109@amd.com> <13426df10801071546j3eaba5c8m6f7bcf3facb9f7f2@mail.gmail.com> <4782BC5B.4000504@amd.com> <13426df10801071610s568a8d22yb3247551bdc4a1af@mail.gmail.com> <47840D35.9060701@amd.com> Message-ID: <20080109001252.15782.qmail@stuge.se> On Tue, Jan 08, 2008 at 04:54:29PM -0700, Marc Jones wrote: > How about this? > Marc > > -- > Marc Jones > Senior Firmware Engineer > (970) 226-9684 Office > mailto:Marc.Jones at amd.com > http://www.amd.com/embeddedprocessors > Add hlt() back into the die() function and update the comments. > > Signed-off-by: Marc Jones Acked-by: Peter Stuge > > > Index: LinuxBIOSv3/lib/console.c > =================================================================== > --- LinuxBIOSv3.orig/lib/console.c 2008-01-08 16:32:28.000000000 -0700 > +++ LinuxBIOSv3/lib/console.c 2008-01-08 16:48:52.000000000 -0700 > @@ -83,30 +83,37 @@ > } > > /** > - * Halt and loop due to a fatal error. > - * There have been several iterations of this function. > + * Halt and loop due to a fatal error. > + * There have been several iterations of this function. > * The first simply did a hlt(). Doing a hlt() can make jtag debugging > - * very difficult as one can not break into a hlt instruction on some CPUs. > - * Second was to do a console_tx_byte of a NULL character. > - * A number of concerns were raised about doing this idea. > - * Third idea was to do an inb from port 0x80, the POST port. That design > - * makes us very CPU-specific. > + * very difficult as one can not break into a hlt instruction on some CPUs. > + * Second was to do a console_tx_byte of a NULL character. > + * A number of concerns were raised about doing this idea. > + * Third idea was to do an inb from port 0x80, the POST port. That design > + * makes us very CPU-specific. > * The fourth idea was just POSTING the same > - * code over and over. That would erase the most recent POST code, > - * hindering diagnosis. > + * code over and over. That would erase the most recent POST code, > + * hindering diagnosis. > * > - * For now, for lack of a good alternative, > - * we will continue to call console_tx_byte. We call with a NULL since > - * it will clear any FIFOs in the path and won't clutter up the output, > - * since NULL doesn't print a visible character on most terminal > - * emulators. > + * For now, for lack of a better alternative, > + * we will call console_tx_byte ten times and then halt. > + * Some CPU JTAG debbuggers might have problems but it is the right thing > + * to do. We call with a NULL since it will clear any FIFOs in the path and > + * won't clutter up the output, since NULL doesn't print a visible character > + * on most terminal emulators. > * > * @param str A string to print for the error > * > */ > void die(const char *str) > { > + int i; > + > printk(BIOS_EMERG, str); > - while (1) > - console_tx_byte(0, (void *)0); > + > + while (1) { > + for (i = 0; i < 10; i++) > + console_tx_byte(0, (void *)0); > + hlt(); > + } > } From c-d.hailfinger.devel.2006 at gmx.net Wed Jan 9 01:33:16 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 09 Jan 2008 01:33:16 +0100 Subject: [LinuxBIOS] [PATCH] v3: rewrite generic x86 CAR code Message-ID: <4784164C.7040508@gmx.net> This patch is an attempt at introducing 4k CAR size granularity for the generic x86 code. For the old supported CAR sizes, the newly generated code is equivalent, so it should be a no-brainer. The patch is identical (except one build fix) to what was committed in r3038 to v2. Since the patch is identical, I'm tempted to steal Marc's ack from r3038. Acked-by: Marc Jones Signed-off-by: Carl-Daniel Hailfinger Index: LinuxBIOSv3-CAR/arch/x86/stage0_i586.S =================================================================== --- LinuxBIOSv3-CAR/arch/x86/stage0_i586.S (Revision 549) +++ LinuxBIOSv3-CAR/arch/x86/stage0_i586.S (Arbeitskopie) @@ -301,38 +301,59 @@ jmp clear_fixed_var_mtrr clear_fixed_var_mtrr_out: -#if CacheSize == 0x10000 - /* enable caching for 64K using fixed mtrr */ +/* 0x06 is the WB IO type for a given 4k segment. + * segs is the number of 4k segments in the area of the particular + * register we want to use for CAR. + * reg is the register where the IO type should be stored. + */ +.macro extractmask segs, reg +.if \segs <= 0 + /* The xorl here is superfluous because at the point of first execution + * of this macro, %eax and %edx are cleared. Later invocations of this + * macro will have a monotonically increasing segs parameter. + */ + xorl \reg, \reg +.elseif \segs == 1 + movl $0x06000000, \reg +.elseif \segs == 2 + movl $0x06060000, \reg +.elseif \segs == 3 + movl $0x06060600, \reg +.elseif \segs >= 4 + movl $0x06060606, \reg +.endif +.endm + +/* size is the cache size in bytes we want to use for CAR. + * windowoffset is the 32k-aligned window into CAR size + */ +.macro simplemask carsize, windowoffset + extractmask (((\carsize - \windowoffset) / 0x1000) - 4), %eax + extractmask (((\carsize - \windowoffset) / 0x1000)), %edx +.endm + +#if CacheSize > 0x10000 +#error Invalid CAR size, must be at most 64k. +#endif +#if CacheSize < 0x1000 +#error Invalid CAR size, must be at least 4k. This is a processor limitation. +#endif +#if (CacheSize & (0x1000 - 1)) +#error Invalid CAR size, is not a multiple of 4k. This is a processor limitation. +#endif + +#if CacheSize > 0x8000 + /* enable caching for 32K-64K using fixed mtrr */ movl $0x268, %ecx /* fix4k_c0000*/ - movl $0x06060606, %eax /* WB IO type */ - movl %eax, %edx + simplemask CacheSize, 0x8000 wrmsr - movl $0x269, %ecx - wrmsr #endif -#if CacheSize == 0x8000 - /* enable caching for 32K using fixed mtrr */ + /* enable caching for 0-32K using fixed mtrr */ movl $0x269, %ecx /* fix4k_c8000*/ - movl $0x06060606, %eax /* WB IO type */ - movl %eax, %edx + simplemask CacheSize, 0 wrmsr -#endif - /* enable caching for 16K/8K/4K using fixed mtrr */ - movl $0x269, %ecx /* fix4k_cc000*/ -#if CacheSize == 0x4000 - movl $0x06060606, %edx /* WB IO type */ -#endif -#if CacheSize == 0x2000 - movl $0x06060000, %edx /* WB IO type */ -#endif -#if CacheSize == 0x1000 - movl $0x06000000, %edx /* WB IO type */ -#endif - xorl %eax, %eax - wrmsr - #if defined(CONFIG_XIP_ROM_SIZE) && defined(CONFIG_XIP_ROM_BASE) /* enable write base caching so we can do execute in place * on the flash rom. From Libo.Feng at amd.com Wed Jan 9 03:32:01 2008 From: Libo.Feng at amd.com (Feng, Libo) Date: Wed, 9 Jan 2008 10:32:01 +0800 Subject: [LinuxBIOS] IRQ and interrupts Message-ID: Hi, all, I am confused again by IRQ and Interrupts. In my system, there is a plug-in Broadcom network board(5715). With lspci -v, I get the message as below: 08:04.0 Ethernet controller: Broadcom Corporation: Unknown device 1678 (rev a3) Subsystem: Broadcom Corporation: Unknown device 1678 Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 201 Memory at ff5d0000 (64-bit, non-prefetchable) [size=64K] Memory at ff5c0000 (64-bit, non-prefetchable) [size=64K] Capabilities: [40] PCI-X non-bridge device. Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable- 08:04.1 Ethernet controller: Broadcom Corporation: Unknown device 1678 (rev a3) Subsystem: Broadcom Corporation: Unknown device 1678 Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 201 Memory at ff5f0000 (64-bit, non-prefetchable) [size=64K] Memory at ff5e0000 (64-bit, non-prefetchable) [size=64K] Capabilities: [40] PCI-X non-bridge device. Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable- With lspci -xxx, I get the message as below: 08:04.0 Ethernet controller: Broadcom Corporation: Unknown device 1678 (rev a3) 00: e4 14 78 16 16 01 b0 02 a3 00 00 02 10 40 80 00 10: 04 00 5d ff 00 00 00 00 04 00 5c ff 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 e4 14 78 16 30: 00 00 00 00 40 00 00 00 00 00 00 00 09 01 40 00 40: 07 48 02 00 20 08 43 04 01 50 02 c0 00 20 00 64 50: 03 58 0c 00 00 10 40 04 05 00 86 00 a8 00 41 b8 60: 10 0c b1 4e 32 c0 00 00 00 00 03 90 00 00 00 00 70: 0a 12 00 00 c7 00 00 00 50 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 c0 00 00 00 fe d0 08 00 90: 01 4f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08:04.1 Ethernet controller: Broadcom Corporation: Unknown device 1678 (rev a3) 00: e4 14 78 16 16 01 b0 02 a3 00 00 02 10 40 80 00 10: 04 00 5f ff 00 00 00 00 04 00 5e ff 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 e4 14 78 16 30: 00 00 00 00 40 00 00 00 00 00 00 00 09 02 40 00 40: 07 48 02 00 21 08 43 04 01 50 02 c0 00 20 00 64 50: 03 58 90 00 08 00 91 22 05 00 86 00 18 5a 82 31 60: 84 10 8e 10 8a 2f 00 00 00 00 03 90 00 00 00 00 70: 0a 12 00 00 c7 00 00 00 50 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 c0 00 00 00 fe d0 08 00 90: 01 4f 00 08 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Lspci -v tells me the IRQ is 201, however, lspci -xxx tells me the IRQ is 09(offset 0x3c). My understanding is wrong or something else. Help me out. Best Regards ??? Feng Libo @ AMD Ext: 20906 Mobile Phone: 13683249071 Office Phone: 0086-010-62801406 -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey.osgood at gmail.com Wed Jan 9 03:36:20 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Tue, 08 Jan 2008 21:36:20 -0500 Subject: [LinuxBIOS] Intel refactoring and microcode updates Message-ID: <47843324.2050907@gmail.com> I've separated this into two patches, one code and one microcode, to improve readability, but they would both have to be committed at once (else things break). These patches eliminate a lot of repeated code, make porting and adding new CPUs easier, add all the latest released microcode updates, and add somewhat experimental support for the latest lga775 cpus, along with various other currently unsupported CPUs. Unfortunately, not everything works quite right yet. Here's the broken stuff: * socket_603: includes all Xeon model f0x, f1x, and f2x cpus. This may be incorrect, but I can't see any easy way to find out. * socket_604: includes all Xeon model f2x, f3x, f4x, and f6x. Same as above, with the added bonus of being too large to fit with any current board. It should also include the socket_603 IDs, since socket 603 CPUs work on socket 604 boards. * socket_775: too large to build with most current ports, but it could probably be broken down into socket_775_pentium and socket_775_core. All fxx IDs are pentium 4/D, and 6xx IDs are Core/Core 2 For now, I've left the current model_fxx and socket_*60*, so nothing breaks, but IMO the socket_603/604 I've added should be made to work. Both patches Signed-off-by: Corey Osgood -------------- next part -------------- A non-text attachment was scrubbed... Name: intel_microcode.patch Type: text/x-patch Size: 560938 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: intel_update.patch Type: text/x-patch Size: 62588 bytes Desc: not available URL: From my_tsai at sis.com Wed Jan 9 04:49:08 2008 From: my_tsai at sis.com (=?big5?B?vbKp+sSjIChteV90c2FpKQ==?=) Date: Wed, 9 Jan 2008 11:49:08 +0800 Subject: [LinuxBIOS] [PATCH] Gigabyte GA-2761GXDK readability improvements In-Reply-To: <478268D6.2030906@gmx.net> References: <478268D6.2030906@gmx.net> Message-ID: <8B129BF6F7AD7E4885A011ED7297EC9C0B55EE@SISMBEV02.sis.com.tw> Dear Carl-Daniel, Yes, I agreed. Thanks for your efforts. Morgan ### lspci -nnvv ### 00:00.0 Host bridge [0600]: Silicon Integrated Systems [SiS] 761/M761 Host [1039:0761] (rev 02) Subsystem: Silicon Integrated Systems [SiS] 761/M761 Host [1039:0761] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Capabilities: [d0] HyperTransport: Slave or Primary Interface Command: BaseUnitID=0 UnitCnt=17 MastHost- DefDir- DUL- Link Control 0: CFlE- CST- CFE- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [a4] HyperTransport: UnitID Clumping 00:02.0 ISA bridge [0601]: Silicon Integrated Systems [SiS] SiS966 [MuTIOL Media IO] [1039:0966] (rev 59) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [b0] Subsystem: Silicon Integrated Systems [SiS] Unknown device [1039:0000] Capabilities: [c0] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Address: fee0300c Data: 41a9 Capabilities: [d0] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag+ Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 0 Link: Latency L0s <1us, L1 <2us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x0 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise- Slot: Number 0, PowerLimit 0.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Off, PwrInd Off, Power- Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [f4] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:07.0 PCI bridge [0604]: Silicon Integrated Systems [SiS] PCI-to-PCI bridge [1039:000a] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [b0] Subsystem: Silicon Integrated Systems [SiS] Unknown device [1039:0000] Capabilities: [c0] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Address: fee0300c Data: 41b1 Capabilities: [d0] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag+ Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 0 Link: Latency L0s <1us, L1 <2us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x1 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise- Slot: Number 0, PowerLimit 0.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Off, PwrInd Off, Power- Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [f4] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [d0] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag+ Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s L1, Port 0 Link: Latency L0s <1us, L1 <2us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x1 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise- Slot: Number 0, PowerLimit 75.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Off, PwrInd Off, Power- Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [bc] HyperTransport: MSI Mapping Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Address: fee0300c Data: 41b9 Capabilities: [f4] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 01:00.0 VGA compatible controller [0300]: Silicon Integrated Systems [SiS] 661/741/760 PCI/AGP or 662/761Gx PCIE VGA Display Adapter [1039:6330] (rev 03) (prog-if 00 [VGA]) Subsystem: Silicon Integrated Systems [SiS] [M]661xX/[M]741[GX]/[M]760 PCI/AGP VGA Adapter [1039:6330] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 01) Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR+ TAbort- SERR- TAbort- SERR- It now finds the part, and gets ready to program it, but exits instantly without doing anything. I think this is the culprit: void generic_spi_page_program(int block, uint8_t *buf, uint8_t *bios) { if (it8716f_flashport) it8716f_spi_page_program(block, buf, bios); } i.e. the flashport is not set. So, before I dig too far into this, is there some simple thing I should look at to get flashrom working on this board? Also, seems to me it's a pretty serious error if this can not be determined, ... anyone mind if I add an error message? right now it exits with no error, having done no work :-) thanks ron -------------- next part -------------- A non-text attachment was scrubbed... Name: flashout Type: application/octet-stream Size: 1771 bytes Desc: not available URL: From c-d.hailfinger.devel.2006 at gmx.net Wed Jan 9 12:28:18 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 09 Jan 2008 12:28:18 +0100 Subject: [LinuxBIOS] flashrom on ga 2761gxdk In-Reply-To: <13426df10801082236o6974bc7agf705b168fa322941@mail.gmail.com> References: <13426df10801082236o6974bc7agf705b168fa322941@mail.gmail.com> Message-ID: <4784AFD2.5090401@gmx.net> On 09.01.2008 07:36, ron minnich wrote: > It now finds the part, and gets ready to program it, but exits > instantly without doing anything. I think this is the culprit: > void generic_spi_page_program(int block, uint8_t *buf, uint8_t *bios) > { > if (it8716f_flashport) > it8716f_spi_page_program(block, buf, bios); > } > > i.e. the flashport is not set. So, before I dig too far into this, is > there some simple thing I should look at to get flashrom working on > this board? > Yes, set the flash port to a reasonable value during BIOS init. Since all versions of the board will have that flash translation chip, you probably can do that unconditionally in Config.lb instead of the boardrevision-dependent way I did it for the GA-M57SLI. Code follows: tmp = pnp_read_config(SERIAL_DEV, IT8716F_CONFIG_REG_SWSUSP); /* Enable writing to serial flash. */ pnp_write_config(SERIAL_DEV, IT8716F_CONFIG_REG_SWSUSP, tmp | 0x10); pnp_set_logical_device(GPIO_DEV); /* Set Serial Flash interface to 0x0820 */ pnp_write_config(GPIO_DEV, 0x64, 0x08); pnp_write_config(GPIO_DEV, 0x65, 0x20); Or the Config.lb way: chip superio/ite/it8716f device pnp 2e.7 on # GPIO, SPI flash # Software Suspend and Flash Interface, see IT8716F datasheet, section 8.3.7 # FIXME: make sure this enables the right pin and the right segments irq 0x24 = 0x1a # Serial Flash I/O (SPI only, the thing flashrom calls it8716f_flashport) io 0x64 = 0x820 end > Also, seems to me it's a pretty serious error if this can not be > determined, ... anyone mind if I add an error message? right now it > exits with no error, having done no work :-) > Later, we will have more of these if style statements. Suggestion (rough cut-n-paste, whitespace damaged, may need a change of return types): { if (it8716f_flashport) return it8716f_spi_page_program(block, buf, bios); printf("generic_spi_page_program called, but no machine specific program routine available!\n"); return; } Regards, Carl-Daniel From svn at openbios.org Wed Jan 9 12:37:58 2008 From: svn at openbios.org (svn at openbios.org) Date: Wed, 9 Jan 2008 12:37:58 +0100 Subject: [LinuxBIOS] r3041 - trunk/LinuxBIOSv2/src/mainboard/gigabyte/ga_2761gxdk Message-ID: Author: hailfinger Date: 2008-01-09 12:37:58 +0100 (Wed, 09 Jan 2008) New Revision: 3041 Modified: trunk/LinuxBIOSv2/src/mainboard/gigabyte/ga_2761gxdk/mptable.c Log: Use macros to improve readability of the device-to-pin IRQ assignments in GA-2761GXDK mptables.c. Thanks to Torsten Duwe for initial code. Signed-off-by: Carl-Daniel Hailfinger Acked-by: ?\232?\148?\161?\230?\152?\142?\232?\128?\128 (Morgan Tsai) Modified: trunk/LinuxBIOSv2/src/mainboard/gigabyte/ga_2761gxdk/mptable.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/gigabyte/ga_2761gxdk/mptable.c 2008-01-08 19:14:16 UTC (rev 3040) +++ trunk/LinuxBIOSv2/src/mainboard/gigabyte/ga_2761gxdk/mptable.c 2008-01-09 11:37:58 UTC (rev 3041) @@ -100,44 +100,52 @@ } } -/*I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# -*/ smp_write_intsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x0, apicid_sis966, 0x0); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x1, apicid_sis966, 0x1); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x0, apicid_sis966, 0x2); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x3, apicid_sis966, 0x3); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x4, apicid_sis966, 0x4); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x6, apicid_sis966, 0x6); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x7, apicid_sis966, 0x7); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x8, apicid_sis966, 0x8); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0xc, apicid_sis966, 0xc); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0xd, apicid_sis966, 0xd); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0xe, apicid_sis966, 0xe); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0xf, apicid_sis966, 0xf); + /* I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# */ + smp_write_intsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, 0x0, apicid_sis966, 0x0); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_sis966[0], ((sbdn+1)<<2)|1, apicid_sis966, 0xa); +/* ISA ints are edge-triggered, and usually originate from the ISA bus, + * or its remainings. + */ +#define ISA_INT(intr, pin)\ + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, bus_isa, (intr), apicid_sis966,(pin)) - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_sis966[0], ((sbdn+2)<<2)|0, apicid_sis966, 0x16); // 22 + ISA_INT(0x1, 0x1); + ISA_INT(0x0, 0x2); + ISA_INT(0x3, 0x3); + ISA_INT(0x4, 0x4); + ISA_INT(0x6, 0x6); + ISA_INT(0x7, 0x7); + ISA_INT(0x8, 0x8); + ISA_INT(0xc, 0xc); + ISA_INT(0xd, 0xd); + ISA_INT(0xe, 0xe); + ISA_INT(0xf, 0xf); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_sis966[0], ((sbdn+2)<<2)|1, apicid_sis966, 0x17); // 23 +/* PCI interrupts are level triggered, and are + * associated with a specific bus/device/function tuple. + */ +#define PCI_INT(bus, dev, fn, pin) \ + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_sis966[bus], (((dev)<<2)|(fn)), apicid_sis966, (pin)) - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_sis966[0], ((sbdn+6)<<2)|1, apicid_sis966, 0x17); // 23 + PCI_INT(0, sbdn+1, 1, 0xa); + PCI_INT(0, sbdn+2, 0, 0x16); // 22 + PCI_INT(0, sbdn+2, 1, 0x17); // 23 + PCI_INT(0, sbdn+6, 1, 0x17); // 23 + PCI_INT(0, sbdn+5, 0, 0x14); // 20 + PCI_INT(0, sbdn+5, 1, 0x17); // 23 + PCI_INT(0, sbdn+5, 2, 0x15); // 21 + PCI_INT(0, sbdn+8, 0, 0x16); // 22 - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_sis966[0], ((sbdn+5)<<2)|0, apicid_sis966, 0x14); // 20 - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_sis966[0], ((sbdn+5)<<2)|1, apicid_sis966, 0x17); // 23 - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_sis966[0], ((sbdn+5)<<2)|2, apicid_sis966, 0x15); // 21 - - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_sis966[0], ((sbdn+8)<<2)|0, apicid_sis966, 0x16); // 22 - for(j=7; j>=2; j--) { if(!bus_sis966[j]) continue; for(i=0;i<4;i++) { - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_sis966[j], (0x00<<2)|i, apicid_sis966, 0x10 + (2+j+i+4-sbdn%4)%4); + PCI_INT(j, 0x00, i, 0x10 + (2+j+i+4-sbdn%4)%4); } } for(j=0; j<2; j++) for(i=0;i<4;i++) { - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, bus_sis966[1], ((0x06+j)<<2)|i, apicid_sis966, 0x10 + (2+i+j)%4); + PCI_INT(1, 0x06+j, i, 0x10 + (2+i+j)%4); } /*Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN#*/ From c-d.hailfinger.devel.2006 at gmx.net Wed Jan 9 12:41:31 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 09 Jan 2008 12:41:31 +0100 Subject: [LinuxBIOS] [PATCH] Gigabyte GA-2761GXDK readability improvements In-Reply-To: <8B129BF6F7AD7E4885A011ED7297EC9C0B55EE@SISMBEV02.sis.com.tw> References: <478268D6.2030906@gmx.net> <8B129BF6F7AD7E4885A011ED7297EC9C0B55EE@SISMBEV02.sis.com.tw> Message-ID: <4784B2EB.6020906@gmx.net> Dear Morgan, On 09.01.2008 04:49, ??? (my_tsai) wrote: > Yes, I agreed. > Thanks, committed in revision 3041. > Thanks for your efforts. > You are welcome. Do you know when the board will be available for purchase? Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Wed Jan 9 12:48:29 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 09 Jan 2008 12:48:29 +0100 Subject: [LinuxBIOS] r3041 - trunk/LinuxBIOSv2/src/mainboard/gigabyte/ga_2761gxdk In-Reply-To: <20080109113809.31907gmx1@mx100.gmx.net> References: <20080109113809.31907gmx1@mx100.gmx.net> Message-ID: <4784B48D.7050106@gmx.net> On 09.01.2008 12:37, svn at openbios.org wrote: > Author: hailfinger > Date: 2008-01-09 12:37:58 +0100 (Wed, 09 Jan 2008) > New Revision: 3041 > > Acked-by: ?\232?\148?\161?\230?\152?\142?\232?\128?\128 (Morgan Tsai) > It seems our subversion changelog mailing setup has problems handling UTF-8 contents in commit messages. svn log gives me the correct message: [...] Acked-by: ??? (Morgan Tsai) [...] Regards, Carl-Daniel From info at coresystems.de Wed Jan 9 13:24:07 2008 From: info at coresystems.de (LinuxBIOS information) Date: Wed, 09 Jan 2008 13:24:07 +0100 Subject: [LinuxBIOS] r3041 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "hailfinger" checked in revision 3041 to the LinuxBIOS source repository and caused the following changes: Change Log: Use macros to improve readability of the device-to-pin IRQ assignments in GA-2761GXDK mptables.c. Thanks to Torsten Duwe for initial code. Signed-off-by: Carl-Daniel Hailfinger Acked-by: ????????? (Morgan Tsai) Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3041&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in hailfinger's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From Marc.Karasek at Sun.COM Wed Jan 9 16:13:38 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Wed, 09 Jan 2008 10:13:38 -0500 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: <2831fecf0801081454m71bb3ff3x3b2da3eb60d4aa37@mail.gmail.com> References: <477CF25C.7070901@sun.com> <477D507E.4030106@sun.com> <477E8A50.2080408@sun.com> <477EB7A1.80406@sun.com> <47824212.3030307@sun.com> <2831fecf0801070837n4c22d036t38254f5ee02d14d1@mail.gmail.com> <4783FC1F.7070309@sun.com> <2831fecf0801081454m71bb3ff3x3b2da3eb60d4aa37@mail.gmail.com> Message-ID: <4784E4A2.8030209@sun.com> Attached is the latest. It uses -ge instead of == or >. This will take care of any time that there are more than 1 build-id in the ld -help output. To address Myles concerns about the id.lds changes. This was due to a bug I could not track down. I left the original code in and comments were added as to the why for this change. I could not find a better work around, or find the root cause for this problem. I will try to debug this further and provide some output to the group. /********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 *********************/ Myles Watson wrote: > On Jan 8, 2008 3:41 PM, Marc Karasek wrote: > >> So what is the general consensus ==1 or >0? >> > > I like the idea of using grep. It seems much cleaner, and avoids that issue. > > The other sticking point for the patch the changes in > src/arch/i386/lib/id.lds (See Ed's last message.) > > Myles > > >> Also, I think I know how to commit back to the tree, but do I need a >> user account for this? >> >> /********************* >> Marc Karasek >> MTS >> Sun Microsystems >> mailto:marc.karasek at sun.com >> ph:770.360.6415 >> *********************/ >> >> >> >> >> Myles Watson wrote: >> >>> On Jan 7, 2008 8:15 AM, Marc Karasek wrote: >>> >>> >>>> After looking at the script Myles sent, I immediately saw the problem. >>>> I forgot that if [ $build_id ] will always be true because it checks to >>>> see if it is defined not the value of build_id. My bad, sorry. >>>> >>>> I have made the changes and added an == 1 to the if statement. Attached >>>> is the new and I hope final patch file for this. >>>> >>>> >>>> >>> It works for me (it doesn't add the load option.) >>> >>> Sorry to be picky, but it seems like this breaks if they mention >>> build-id more than once in the help in the future. I think >0 would >>> be better than ==1. >>> >>> With that fixed, or if no one thinks that will ever happen: >>> Acked-by: Myles Watson >>> >>> >>>> /********************* >>>> Marc Karasek >>>> MTS >>>> Sun Microsystems >>>> mailto:marc.karasek at sun.com >>>> ph:770.360.6415 >>>> *********************/ >>>> >>>> >>>> >>>> Ed Swierk wrote: >>>> >>>> >>>> >>>>> On 1/4/08, Marc Karasek wrote: >>>>> >>>>> >>>>> >>>>>> I made a test script and ran it and it sets build_id = 1 properly. I >>>>>> have also included this script. >>>>>> >>>>>> >>>>>> >>>>> The problem is that on Planet Bourne, zero means true and nonzero means false. >>>>> >>>>> --Ed >>>>> >>>>> >>>>> -------------- next part -------------- A non-text attachment was scrubbed... Name: flags_ld.patch Type: text/x-patch Size: 4168 bytes Desc: not available URL: From rminnich at gmail.com Wed Jan 9 17:03:54 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 9 Jan 2008 08:03:54 -0800 Subject: [LinuxBIOS] flashrom on ga 2761gxdk In-Reply-To: <4784AFD2.5090401@gmx.net> References: <13426df10801082236o6974bc7agf705b168fa322941@mail.gmail.com> <4784AFD2.5090401@gmx.net> Message-ID: <13426df10801090803k1f6cac62sd757633c12a651bd@mail.gmail.com> On Jan 9, 2008 3:28 AM, Carl-Daniel Hailfinger wrote: > Yes, set the flash port to a reasonable value during BIOS init. This is under the factory BIOS. I will dig a little deeper. I could not at first see why it would not be set. I hope to have more time tonight. > { > > if (it8716f_flashport) > return it8716f_spi_page_program(block, buf, bios); > printf("generic_spi_page_program called, but no machine specific program routine available!\n"); > return; > } you'll get this message many times. I think it needs to be done in an outer function. I will dig a bit and try to see what to do. thanks ron From svn at openbios.org Wed Jan 9 19:27:49 2008 From: svn at openbios.org (svn at openbios.org) Date: Wed, 9 Jan 2008 19:27:49 +0100 Subject: [LinuxBIOS] r550 - LinuxBIOSv3/lib Message-ID: Author: mjones Date: 2008-01-09 19:27:49 +0100 (Wed, 09 Jan 2008) New Revision: 550 Modified: LinuxBIOSv3/lib/console.c Log: Add hlt() back into the die() function and update the comments. Signed-off-by: Marc Jones Acked-by: Peter Stuge Modified: LinuxBIOSv3/lib/console.c =================================================================== --- LinuxBIOSv3/lib/console.c 2008-01-07 16:34:34 UTC (rev 549) +++ LinuxBIOSv3/lib/console.c 2008-01-09 18:27:49 UTC (rev 550) @@ -83,30 +83,37 @@ } /** - * Halt and loop due to a fatal error. - * There have been several iterations of this function. + * Halt and loop due to a fatal error. + * There have been several iterations of this function. * The first simply did a hlt(). Doing a hlt() can make jtag debugging - * very difficult as one can not break into a hlt instruction on some CPUs. - * Second was to do a console_tx_byte of a NULL character. - * A number of concerns were raised about doing this idea. - * Third idea was to do an inb from port 0x80, the POST port. That design - * makes us very CPU-specific. + * very difficult as one can not break into a hlt instruction on some CPUs. + * Second was to do a console_tx_byte of a NULL character. + * A number of concerns were raised about doing this idea. + * Third idea was to do an inb from port 0x80, the POST port. That design + * makes us very CPU-specific. * The fourth idea was just POSTING the same - * code over and over. That would erase the most recent POST code, - * hindering diagnosis. + * code over and over. That would erase the most recent POST code, + * hindering diagnosis. * - * For now, for lack of a good alternative, - * we will continue to call console_tx_byte. We call with a NULL since - * it will clear any FIFOs in the path and won't clutter up the output, - * since NULL doesn't print a visible character on most terminal - * emulators. + * For now, for lack of a better alternative, + * we will call console_tx_byte ten times and then halt. + * Some CPU JTAG debbuggers might have problems but it is the right thing + * to do. We call with a NULL since it will clear any FIFOs in the path and + * won't clutter up the output, since NULL doesn't print a visible character + * on most terminal emulators. * * @param str A string to print for the error * */ void die(const char *str) { + int i; + printk(BIOS_EMERG, str); - while (1) - console_tx_byte(0, (void *)0); + + while (1) { + for (i = 0; i < 10; i++) + console_tx_byte(0, (void *)0); + hlt(); + } } From marc.jones at amd.com Wed Jan 9 19:28:11 2008 From: marc.jones at amd.com (Marc Jones) Date: Wed, 09 Jan 2008 11:28:11 -0700 Subject: [LinuxBIOS] PATCH: lx car that returns from disable_car In-Reply-To: <20080109001252.15782.qmail@stuge.se> References: <13426df10801041405h1d3e0f1eocdfba04c34144eb9@mail.gmail.com> <4782A542.6030109@amd.com> <13426df10801071546j3eaba5c8m6f7bcf3facb9f7f2@mail.gmail.com> <4782BC5B.4000504@amd.com> <13426df10801071610s568a8d22yb3247551bdc4a1af@mail.gmail.com> <47840D35.9060701@amd.com> <20080109001252.15782.qmail@stuge.se> Message-ID: <4785123B.2000100@amd.com> Peter Stuge wrote: > On Tue, Jan 08, 2008 at 04:54:29PM -0700, Marc Jones wrote: >> How about this? >> Marc >> >> -- >> Marc Jones >> Senior Firmware Engineer >> (970) 226-9684 Office >> mailto:Marc.Jones at amd.com >> http://www.amd.com/embeddedprocessors > >> Add hlt() back into the die() function and update the comments. >> >> Signed-off-by: Marc Jones > > Acked-by: Peter Stuge > r550 -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From marc.jones at amd.com Wed Jan 9 19:40:51 2008 From: marc.jones at amd.com (Marc Jones) Date: Wed, 09 Jan 2008 11:40:51 -0700 Subject: [LinuxBIOS] [PATCH] v3: rewrite generic x86 CAR code In-Reply-To: <4784164C.7040508@gmx.net> References: <4784164C.7040508@gmx.net> Message-ID: <47851533.3090501@amd.com> Carl-Daniel Hailfinger wrote: > This patch is an attempt at introducing 4k CAR size granularity for the > generic x86 code. For the old supported CAR sizes, the newly generated > code is equivalent, so it should be a no-brainer. > > The patch is identical (except one build fix) to what was committed in > r3038 to v2. Since the patch is identical, I'm tempted to steal Marc's > ack from r3038. > Acked-by: Marc Jones > > Signed-off-by: Carl-Daniel Hailfinger > Acked-by: Marc Jones -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From myles at pel.cs.byu.edu Wed Jan 9 22:56:44 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Wed, 9 Jan 2008 14:56:44 -0700 Subject: [LinuxBIOS] LinuxBIOSv3 Config files In-Reply-To: <20080108233849.GD28312@cosmic.amd.com> References: <2831fecf0801081530m3a3c0a99n3222c8b164f2e110@mail.gmail.com> <20080108233849.GD28312@cosmic.amd.com> Message-ID: <2831fecf0801091356h407194b0od60664726cb4da7c@mail.gmail.com> On Jan 8, 2008 4:38 PM, Jordan Crouse wrote: > On 08/01/08 16:30 -0700, Myles Watson wrote: > > In buildrom, I want to be able to set the variables I care about, then > > use make oldconfig to choose the (hopefully) sane defaults for the > > rest of the options. > > That would make sense, but I'm not sure if there is a way to make kconfig > do that. At least, in my experience, we've always needed to the user > to build the entire .config, to avoid oldconfig asking questions. > > But there might be a conf option that can avoid that. The only way I can find isn't as clean as I would like. make oldconfig < newlines.txt newlines.txt makes it choose the defaults by "hitting enter" It may be worth it because it would allow us to generate .config files instead of having to have one for every architecture. Myles From svn at openbios.org Thu Jan 10 00:09:23 2008 From: svn at openbios.org (svn at openbios.org) Date: Thu, 10 Jan 2008 00:09:23 +0100 Subject: [LinuxBIOS] r551 - LinuxBIOSv3/arch/x86 Message-ID: Author: hailfinger Date: 2008-01-10 00:09:23 +0100 (Thu, 10 Jan 2008) New Revision: 551 Modified: LinuxBIOSv3/arch/x86/stage0_i586.S Log: This patch is an attempt at introducing 4k CAR size granularity for the generic x86 code. For the old supported CAR sizes, the newly generated code is equivalent, so it should be a no-brainer. The patch is identical (except one build fix) to what was committed in r3038 to v2. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Marc Jones Modified: LinuxBIOSv3/arch/x86/stage0_i586.S =================================================================== --- LinuxBIOSv3/arch/x86/stage0_i586.S 2008-01-09 18:27:49 UTC (rev 550) +++ LinuxBIOSv3/arch/x86/stage0_i586.S 2008-01-09 23:09:23 UTC (rev 551) @@ -301,38 +301,59 @@ jmp clear_fixed_var_mtrr clear_fixed_var_mtrr_out: -#if CacheSize == 0x10000 - /* enable caching for 64K using fixed mtrr */ +/* 0x06 is the WB IO type for a given 4k segment. + * segs is the number of 4k segments in the area of the particular + * register we want to use for CAR. + * reg is the register where the IO type should be stored. + */ +.macro extractmask segs, reg +.if \segs <= 0 + /* The xorl here is superfluous because at the point of first execution + * of this macro, %eax and %edx are cleared. Later invocations of this + * macro will have a monotonically increasing segs parameter. + */ + xorl \reg, \reg +.elseif \segs == 1 + movl $0x06000000, \reg +.elseif \segs == 2 + movl $0x06060000, \reg +.elseif \segs == 3 + movl $0x06060600, \reg +.elseif \segs >= 4 + movl $0x06060606, \reg +.endif +.endm + +/* size is the cache size in bytes we want to use for CAR. + * windowoffset is the 32k-aligned window into CAR size + */ +.macro simplemask carsize, windowoffset + extractmask (((\carsize - \windowoffset) / 0x1000) - 4), %eax + extractmask (((\carsize - \windowoffset) / 0x1000)), %edx +.endm + +#if CacheSize > 0x10000 +#error Invalid CAR size, must be at most 64k. +#endif +#if CacheSize < 0x1000 +#error Invalid CAR size, must be at least 4k. This is a processor limitation. +#endif +#if (CacheSize & (0x1000 - 1)) +#error Invalid CAR size, is not a multiple of 4k. This is a processor limitation. +#endif + +#if CacheSize > 0x8000 + /* enable caching for 32K-64K using fixed mtrr */ movl $0x268, %ecx /* fix4k_c0000*/ - movl $0x06060606, %eax /* WB IO type */ - movl %eax, %edx + simplemask CacheSize, 0x8000 wrmsr - movl $0x269, %ecx - wrmsr #endif -#if CacheSize == 0x8000 - /* enable caching for 32K using fixed mtrr */ + /* enable caching for 0-32K using fixed mtrr */ movl $0x269, %ecx /* fix4k_c8000*/ - movl $0x06060606, %eax /* WB IO type */ - movl %eax, %edx + simplemask CacheSize, 0 wrmsr -#endif - /* enable caching for 16K/8K/4K using fixed mtrr */ - movl $0x269, %ecx /* fix4k_cc000*/ -#if CacheSize == 0x4000 - movl $0x06060606, %edx /* WB IO type */ -#endif -#if CacheSize == 0x2000 - movl $0x06060000, %edx /* WB IO type */ -#endif -#if CacheSize == 0x1000 - movl $0x06000000, %edx /* WB IO type */ -#endif - xorl %eax, %eax - wrmsr - #if defined(CONFIG_XIP_ROM_SIZE) && defined(CONFIG_XIP_ROM_BASE) /* enable write base caching so we can do execute in place * on the flash rom. From c-d.hailfinger.devel.2006 at gmx.net Thu Jan 10 00:11:00 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 10 Jan 2008 00:11:00 +0100 Subject: [LinuxBIOS] [PATCH] v3: rewrite generic x86 CAR code In-Reply-To: <47851533.3090501@amd.com> References: <4784164C.7040508@gmx.net> <47851533.3090501@amd.com> Message-ID: <47855484.6000606@gmx.net> On 09.01.2008 19:40, Marc Jones wrote: > Carl-Daniel Hailfinger wrote: > >> This patch is an attempt at introducing 4k CAR size granularity for the >> generic x86 code. For the old supported CAR sizes, the newly generated >> code is equivalent, so it should be a no-brainer. >> >> The patch is identical (except one build fix) to what was committed in >> r3038 to v2. Since the patch is identical, I'm tempted to steal Marc's >> ack from r3038. >> Acked-by: Marc Jones >> >> Signed-off-by: Carl-Daniel Hailfinger >> >> > > > Acked-by: Marc Jones > Thanks, r551. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Thu Jan 10 00:22:20 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 10 Jan 2008 00:22:20 +0100 Subject: [LinuxBIOS] flashrom on ga 2761gxdk In-Reply-To: <13426df10801090803k1f6cac62sd757633c12a651bd@mail.gmail.com> References: <13426df10801082236o6974bc7agf705b168fa322941@mail.gmail.com> <4784AFD2.5090401@gmx.net> <13426df10801090803k1f6cac62sd757633c12a651bd@mail.gmail.com> Message-ID: <4785572C.2070708@gmx.net> On 09.01.2008 17:03, ron minnich wrote: > On Jan 9, 2008 3:28 AM, Carl-Daniel Hailfinger > wrote: > > >> Yes, set the flash port to a reasonable value during BIOS init. >> > > This is under the factory BIOS. I will dig a little deeper. I could > not at first see why it would not be set. I hope to have more time > tonight. > That's easy. You don't need that port set unless you want to write to flash. Try the patch below and please post full verbose log. Index: flashrom-ron/spi.c =================================================================== --- flashrom-ron/spi.c (Revision 3036) +++ flashrom-ron/spi.c (Arbeitskopie) @@ -139,6 +139,8 @@ printf("serial flash pin %i\n", (tmp & 1 << 5) ? 87 : 29); /* LDN 0x7, reg 0x64/0x65 */ regwrite(port, 0x07, 0x7); + regwrite(port, 0x64, 0x08); + regwrite(port, 0x65, 0x20); flashport = regval(port, 0x64) << 8; flashport |= regval(port, 0x65); } Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Thu Jan 10 00:23:35 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 10 Jan 2008 00:23:35 +0100 Subject: [LinuxBIOS] [PATCH] v2: rewrite AMD K* CAR code In-Reply-To: <13426df10801081400m1905129bxaee8fbef30d7d5a3@mail.gmail.com> References: <4783B99E.1030208@gmx.net> <4783BD38.3050309@amd.com> <13426df10801081030v241bd8e0rc50788b1bd2555a9@mail.gmail.com> <4783D01C.4010404@gmx.net> <13426df10801081400m1905129bxaee8fbef30d7d5a3@mail.gmail.com> Message-ID: <47855777.1040801@gmx.net> On 08.01.2008 23:00, ron minnich wrote: > Actually, if you all want to commit this, I can try it on the sis > board this week. > Well, i'd like to commit, but I'll wait until you (or someone else) have tested it. Regards, Carl-Daniel From myles at pel.cs.byu.edu Thu Jan 10 00:26:42 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Wed, 9 Jan 2008 16:26:42 -0700 Subject: [LinuxBIOS] Expand linuxbiosv3 support In-Reply-To: <2831fecf0801081320k32b4d9e2p83fecff3ad59ef6@mail.gmail.com> References: <20071206223914.GB4092@cosmic.amd.com> <00f901c83860$3bfad7d0$4b23040a@chimp> <20071206234649.GA6114@cosmic.amd.com> <010c01c838df$226f2170$4b23040a@chimp> <20071207155811.GE6784@cosmic.amd.com> <2831fecf0801081214q6ee1f337raccc91bf32815ca8@mail.gmail.com> <20080108203752.GA28312@cosmic.amd.com> <2831fecf0801081320k32b4d9e2p83fecff3ad59ef6@mail.gmail.com> Message-ID: <001b01c85317$17b37810$2023040a@chimp> > -----Original Message----- > From: mylesgw at gmail.com [mailto:mylesgw at gmail.com] On Behalf Of Myles > Watson > Sent: Tuesday, January 08, 2008 2:21 PM > To: Jordan Crouse; Linuxbios > Subject: Re: Expand linuxbiosv3 support > > This patch is Jordan's buildrom patch with a few additions, so I'm > including > his original message: > > [BUILDROM] Expand linuxbiosv3 support > > Add more generic support for LinuxBIOSv3 - add specialized package > for v3, and add support for using LAR to put it all together. Also > add expanded (and better) option ROM support, though we're not actually > using it right away. > > Myles again: > > It also changes LINUXBIOS variables to LBV2 unless they are used for both. > I > added dependencies between vendors that don't have any v3 platforms and > LINUXBIOS_V2. > I accidentally changed one instance of LINUXBIOS_ROM_NAME to LBV2_ROM_NAME, which broke the v2 build. It's in linuxbios.inc. I've fixed it in my tree but decided to spare you another large patch for one tiny change. Myles > One of the changes Jordan made was to always build v3 with no payload > and then add it later with any binary blobs that might be needed. > This way you can change them without rebuilding v3. > > Signed-off-by: Myles Watson From harald.gutmann at gmx.net Thu Jan 10 00:31:31 2008 From: harald.gutmann at gmx.net (Harald Gutmann) Date: Thu, 10 Jan 2008 00:31:31 +0100 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <20071202044824.3246.qmail@stuge.se> References: <20070902141108.GA9106@localdomain> <47520056.7060508@gmail.com> <20071202044824.3246.qmail@stuge.se> Message-ID: <200801100031.31098.harald.gutmann@gmx.net> Am Sonntag, 2. Dezember 2007 05:48:23 schrieb Peter Stuge: > On Sat, Dec 01, 2007 at 07:46:14PM -0500, Richard Smith wrote: > > CS# from the IT8716F is routed up to R509 which is a zero ohm > > resistor. > > If this resistor is in place then CS is hardwired to CS# on U5 > > which is the SPI chip that's loaded. If you pull R509 then the CS# > > to both chips are free to be selected by (unloaded) Q2,Q43,Q4, and > > Q5 + resistors but I don't have the configuration mapped out. > > They would be part of Gigabyte's patented hardware BIOS failover > technology I suppose. > > Q4-3 and Q5-3 are both connected to the superio side of R509, so the > emitter if using PNP transistors. > > Traces from Q4-1 and Q5-1 both run toward the flash chips so they > would be the collector. > > Q4-2 and Q5-2 the base, with R91 before Q4 and R90 before Q5. The > other side of R91 goes to R389 which then goes to Q43-2. The other > side of R90 goes to R86 which then goes to Q2-2. > There are some vias on the traces between R{90,91} and Q{4,5} so they > are connected to something else as well. (But what?) There are also > vias on traces between R{86,389} and Q{2,43}. > > Q43 and Q4 are driven at the same time, through R389 and R91 > respectively. I wonder what the purpose of Q43 and Q2 is. > > The pinout does indeed match e.g. a BC847 PNP transistor in SOT23 > package. > > R89 is between Q4-1 (U5-CS#?) and a power net, so would be the > pull-up for when Q4 is not driven to select U5. > > There is certainly a corresponding resistor for Q5-1 but there's only > a via from the Q5-1 trace so it would have to be tested. My guess is > R130 (directly south of R129) since it's other end goes to U9-CS#. > > > It does not look like there is any easy way to re-enable switching > > between the SPI chips since you have to load several missing parts. > > The switch mod can be simplified to use existing pads and no pins > have to be lifted from the flash chips anymore. > > 1. Remove R509. > 2. Populate R89 and R130 with 10k or 100k pull-up 0402 resistors. > 3. Solder the switch common to Q4-3 and switch between Q4-1 and Q5-1. Confirmed. But not with SMD Resistors. First I removed the R509. As there are connections from R89 Left to U5 VCC; from R89 Right to U9 CS#; from R130 Left to U5 CS# and from R130 Right to U9 VCC I soldered normal 100k resistors between U5 VCC and U9 CS# and between U5 CS# and U9 VCC. Here are two photos of my new mod: http://img141.imageshack.us/img141/8866/dscf1791ob2.jpg http://img104.imageshack.us/img104/2579/dscf1792nn2.jpg I know, that these cables to the sockel are not really fine, but i had no other solution for mounting the sockel on the mainboard and it works fine! I added a sockel for the SPI-chips to be able to change the bios chip in an easy way. If someone is interested which sockels these are, they are manufactured by WELLS-CTI and have the part number 652C0082211-W003. I payed about 8? per part, and that sould be about 10$, without shipping costs. The distributer for these sockels was http://www.bfioptilas.com/. (PS: thanks to Mr. A. v. Heydwolff for organising these sockels.) > Of course this assumes that soldering 0402 resistors is considered > simple, which isn't likely true unless you're good at SMT soldering. A friend of mine helped me with the soldering, but he said that it is nearly impossible to solder these resistors without industry-equipment. > > > I'll probably just end up soldering on a 2nd chip and then wiring > > the CS# pins up to a switch like the other mods did. > > Of course there could be some timer thingy to do failover, but I > think manual control is best. I think the spring-loaded switch is > as useful as any mechanism in this case. > > > //Peter From harald.gutmann at gmx.net Thu Jan 10 01:00:30 2008 From: harald.gutmann at gmx.net (Harald Gutmann) Date: Thu, 10 Jan 2008 01:00:30 +0100 Subject: [LinuxBIOS] Please add support for MX25L8005 and MX25L3205D Message-ID: <200801100100.30695.harald.gutmann@gmx.net> Hello! As I've soldered a Sockel for SPI-Chips on my Mainboard (Gigabyte M57SLI4), I'd like to test the Chip's which have more space on it, and i've here. I have those chips, and the sockel but not really skills in programming C, i tried to look at the source code from flashrom, but grepping for "MX25L4005" (which already works) gives just two results. One result is in the flashchips.c file, and the second in flash.h, where in flash.h there is an entry for the MX25L8005 chip. I added in flashchips.c a line for the MX25L8005 chip, and flashrom detects it, but i don't know what the values in those lines are exactly for, but just correcting the first one to 1024 gives the right size output after the chip detction, but verifying after writing to the chip doesn't work. (I think there is some more work to do on the flashrom code, or i just have the wrong values insert in the flashchips.h file.) It would be really fine, if someone of you could implement that correctly, i can and will test if it works. Kind regards, Harald Gutmann From c-d.hailfinger.devel.2006 at gmx.net Thu Jan 10 01:25:44 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 10 Jan 2008 01:25:44 +0100 Subject: [LinuxBIOS] Please add support for MX25L8005 and MX25L3205D In-Reply-To: <200801100100.30695.harald.gutmann@gmx.net> References: <200801100100.30695.harald.gutmann@gmx.net> Message-ID: <47856608.2010106@gmx.net> On 10.01.2008 01:00, Harald Gutmann wrote: > As I've soldered a Sockel for SPI-Chips on my Mainboard (Gigabyte M57SLI4), > I'd like to test the Chip's which have more space on it, and i've here. > > I have those chips, and the sockel but not really skills in programming C, i > tried to look at the source code from flashrom, but grepping for "MX25L4005" > (which already works) gives just two results. One result is in the > flashchips.c file, and the second in flash.h, where in flash.h there is an > entry for the MX25L8005 chip. > > I added in flashchips.c a line for the MX25L8005 chip, and flashrom detects > it, but i don't know what the values in those lines are exactly for, but just > correcting the first one to 1024 gives the right size output after the chip > detction, but verifying after writing to the chip doesn't work. (I think > there is some more work to do on the flashrom code, or i just have the wrong > values insert in the flashchips.h file.) > Just adding the right values to flashchips.c is not enough. I need "flashrom -V" output both with your patch and without your patch. > It would be really fine, if someone of you could implement that correctly, i > can and will test if it works. > I can implement support if I have the output mentioned above. Your problem seems to be caused by the flash translation chip and not the flash chip. Regards, Carl-Daniel From marc.jones at amd.com Thu Jan 10 01:45:28 2008 From: marc.jones at amd.com (Marc Jones) Date: Wed, 09 Jan 2008 17:45:28 -0700 Subject: [LinuxBIOS] [PATCH] v2: rewrite AMD K* CAR code In-Reply-To: <47855777.1040801@gmx.net> References: <4783B99E.1030208@gmx.net> <4783BD38.3050309@amd.com> <13426df10801081030v241bd8e0rc50788b1bd2555a9@mail.gmail.com> <4783D01C.4010404@gmx.net> <13426df10801081400m1905129bxaee8fbef30d7d5a3@mail.gmail.com> <47855777.1040801@gmx.net> Message-ID: <47856AA8.1030003@amd.com> Carl-Daniel Hailfinger wrote: > On 08.01.2008 23:00, ron minnich wrote: >> Actually, if you all want to commit this, I can try it on the sis >> board this week. >> > > Well, i'd like to commit, but I'll wait until you (or someone else) have > tested it. > > Regards, > Carl-Daniel > We checked this on K8 with DCACHE_RAM_SIZE=0x08000 and it works as expected. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From c-d.hailfinger.devel.2006 at gmx.net Thu Jan 10 03:00:13 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 10 Jan 2008 03:00:13 +0100 Subject: [LinuxBIOS] [PATCH] v2: rewrite AMD K* CAR code In-Reply-To: <47856AA8.1030003@amd.com> References: <4783B99E.1030208@gmx.net> <4783BD38.3050309@amd.com> <13426df10801081030v241bd8e0rc50788b1bd2555a9@mail.gmail.com> <4783D01C.4010404@gmx.net> <13426df10801081400m1905129bxaee8fbef30d7d5a3@mail.gmail.com> <47855777.1040801@gmx.net> <47856AA8.1030003@amd.com> Message-ID: <47857C2D.90306@gmx.net> On 10.01.2008 01:45, Marc Jones wrote: > Carl-Daniel Hailfinger wrote: >> On 08.01.2008 23:00, ron minnich wrote: >>> Actually, if you all want to commit this, I can try it on the sis >>> board this week. >> >> Well, i'd like to commit, but I'll wait until you (or someone else) have >> tested it. > > We checked this on K8 with DCACHE_RAM_SIZE=0x08000 and it works as > expected. Thanks, great! There's one issue with specific binutils versions, though. The following sequence trips up a specific gas version with an error message: "Error: too many positional arguments" I'd like to blacklist the specific binutils version causing this and report the bug to the linux distributor. Jordan, could you give us more details (exact binutils version, name of distribution, are all updates applied)? .macro extractmask segs, reg .if \segs <= 0 xorl \reg, \reg .elseif \segs == 1 movl $0x06000000, \reg .elseif \segs == 2 movl $0x06060000, \reg .elseif \segs == 3 movl $0x06060600, \reg .elseif \segs >= 4 movl $0x06060606, \reg .endif .endm .macro simplemask carsize, windowoffset extractmask (((\carsize - \windowoffset) / 0x1000) - 4), %eax extractmask (((\carsize - \windowoffset) / 0x1000)), %edx .endm simplemask 0x8000, 0 Regards, Carl-Daniel From kbaski at yahoo.com Thu Jan 10 03:05:52 2008 From: kbaski at yahoo.com (Baski) Date: Wed, 9 Jan 2008 18:05:52 -0800 (PST) Subject: [LinuxBIOS] PCI device memory resource In-Reply-To: Message-ID: <654527.65238.qm@web51603.mail.re2.yahoo.com> For a PCI device to request memory resource of ,say 1MB, should it have onboard memory of 1MB ? TIA -- People wielding power and authority always desire to destroy the sources which gave them that power. Or, is it the other way round? --------------------------------- Never miss a thing. Make Yahoo your homepage. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at smittys.pointclark.net Thu Jan 10 03:24:12 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Wed, 09 Jan 2008 21:24:12 -0500 Subject: [LinuxBIOS] Intel refactoring and microcode updates In-Reply-To: <47843324.2050907@gmail.com> References: <47843324.2050907@gmail.com> Message-ID: <20080109212412.cgsck1t6xxcww4s8@www.smittys.pointclark.net> Quoting Corey Osgood : > I've separated this into two patches, one code and one microcode, to > improve readability, but they would both have to be committed at once > (else things break). These patches eliminate a lot of repeated code, > make porting and adding new CPUs easier, add all the latest released > microcode updates, and add somewhat experimental support for the latest > lga775 cpus, along with various other currently unsupported CPUs. > Unfortunately, not everything works quite right yet. Here's the broken > stuff: > > * socket_603: includes all Xeon model f0x, f1x, and f2x cpus. This may > be incorrect, but I can't see any easy way to find out. > * socket_604: includes all Xeon model f2x, f3x, f4x, and f6x. Same as > above, with the added bonus of being too large to fit with any current > board. It should also include the socket_603 IDs, since socket 603 CPUs > work on socket 604 boards. > * socket_775: too large to build with most current ports, but it could > probably be broken down into socket_775_pentium and socket_775_core. All > fxx IDs are pentium 4/D, and 6xx IDs are Core/Core 2 > > For now, I've left the current model_fxx and socket_*60*, so nothing > breaks, but IMO the socket_603/604 I've added should be made to work. > > Both patches Signed-off-by: Corey Osgood > Hmm looks good. Should we add a quick note to each file to what processor it belongs too? I think that would save developers time from having to look it up when writing code for a new board? What do you think? Thanks - Joe From c-d.hailfinger.devel.2006 at gmx.net Thu Jan 10 03:26:35 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 10 Jan 2008 03:26:35 +0100 Subject: [LinuxBIOS] [PATCH] v2: rewrite AMD K* CAR code In-Reply-To: <47857C2D.90306@gmx.net> References: <4783B99E.1030208@gmx.net> <4783BD38.3050309@amd.com> <13426df10801081030v241bd8e0rc50788b1bd2555a9@mail.gmail.com> <4783D01C.4010404@gmx.net> <13426df10801081400m1905129bxaee8fbef30d7d5a3@mail.gmail.com> <47855777.1040801@gmx.net> <47856AA8.1030003@amd.com> <47857C2D.90306@gmx.net> Message-ID: <4785825B.80000@gmx.net> On 10.01.2008 03:00, Carl-Daniel Hailfinger wrote: > On 10.01.2008 01:45, Marc Jones wrote: > >> Carl-Daniel Hailfinger wrote: >> >>> On 08.01.2008 23:00, ron minnich wrote: >>> >>>> Actually, if you all want to commit this, I can try it on the sis >>>> board this week. >>>> >>> Well, i'd like to commit, but I'll wait until you (or someone else) have >>> tested it. >>> >> We checked this on K8 with DCACHE_RAM_SIZE=0x08000 and it works as >> expected. >> > > Thanks, great! > > There's one issue with specific binutils versions, though. The following > sequence trips up a specific gas version with an error message: "Error: > too many positional arguments" > > I'd like to blacklist the specific binutils version causing this and > report the bug to the linux distributor. > Jordan, could you give us more details (exact binutils version, name of > distribution, are all updates applied)? > Or try this patch on top of my current patch: --- src/cpu/amd/car/cache_as_ram.inc~ 2008-01-08 20:16:30.000000000 +0100 +++ src/cpu/amd/car/cache_as_ram.inc 2008-01-10 03:24:09.000000000 +0100 @@ -160,8 +160,15 @@ * windowoffset is the 32k-aligned window into CAR size */ .macro simplemask carsize, windowoffset + .set gas_bug_workaround,(((\carsize - \windowoffset) / 0x1000) - 4) + extractmask gas_bug_workaround, %eax + .set gas_bug_workaround,(((\carsize - \windowoffset) / 0x1000)) + extractmask gas_bug_workaround, %edx +/* Without the gas bug workaround, the entire macro would consist only of the + * two lines below. extractmask (((\carsize - \windowoffset) / 0x1000) - 4), %eax extractmask (((\carsize - \windowoffset) / 0x1000)), %edx + */ .endm #if CacheSize > 0x10000 It is a workaound for http://sourceware.org/bugzilla/show_bug.cgi?id=669 . As an alternative, we may simply blacklist the affected binutils versions. Regards, Carl-Daniel From joe at smittys.pointclark.net Thu Jan 10 03:59:03 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Wed, 09 Jan 2008 21:59:03 -0500 Subject: [LinuxBIOS] svn question Message-ID: <20080109215903.kz0x1vj1c0swkgwk@www.smittys.pointclark.net> Dumb question, but I can't seem to find any real good docs on svn. How to I commit a patch to my local LinuxBIOSV2 copy?? Thanks - Joe From c-d.hailfinger.devel.2006 at gmx.net Thu Jan 10 04:15:47 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 10 Jan 2008 04:15:47 +0100 Subject: [LinuxBIOS] svn question In-Reply-To: <20080109215903.kz0x1vj1c0swkgwk@www.smittys.pointclark.net> References: <20080109215903.kz0x1vj1c0swkgwk@www.smittys.pointclark.net> Message-ID: <47858DE3.9050503@gmx.net> On 10.01.2008 03:59, joe at smittys.pointclark.net wrote: > Dumb question, but I can't seem to find any real good docs on svn. > http://svnbook.red-bean.com/ > How to I commit a patch to my local LinuxBIOSV2 copy?? > AFAIK you can't do local commits. You can apply patches locally, but a commit will only happen on the server. Regards, Carl-Daniel From bishop.robinson at gmail.com Thu Jan 10 04:16:55 2008 From: bishop.robinson at gmail.com (Robinson Tryon) Date: Wed, 9 Jan 2008 22:16:55 -0500 Subject: [LinuxBIOS] svn question In-Reply-To: <20080109215903.kz0x1vj1c0swkgwk@www.smittys.pointclark.net> References: <20080109215903.kz0x1vj1c0swkgwk@www.smittys.pointclark.net> Message-ID: On Jan 9, 2008 9:59 PM, wrote: > Dumb question, but I can't seem to find any real good docs on svn. How > to I commit a patch to my local LinuxBIOSV2 copy?? Do you want to commit something to a repository, or do you just want to patch your local checkout? To merge a patch into your local svn checkout you can use the 'patch' tool. Check out the man page for specifics -- but you'll basically run something like: patch /path/to/file /patch/to/patchfile.patch Here's a couple of examples: http://wiki.creativecommons.org/HOWTO_Patch From my_tsai at sis.com Thu Jan 10 05:00:28 2008 From: my_tsai at sis.com (=?big5?B?vbKp+sSjIChteV90c2FpKQ==?=) Date: Thu, 10 Jan 2008 12:00:28 +0800 Subject: [LinuxBIOS] [PATCH] Gigabyte GA-2761GXDK readability improvements In-Reply-To: <4784B2EB.6020906@gmx.net> References: <478268D6.2030906@gmx.net> <8B129BF6F7AD7E4885A011ED7297EC9C0B55EE@SISMBEV02.sis.com.tw> <4784B2EB.6020906@gmx.net> Message-ID: <8B129BF6F7AD7E4885A011ED7297EC9C0B5687@SISMBEV02.sis.com.tw> Dear Carl-Daniel, As I know, the board is designed for home server. I'm not sure it would be available for retail. Btw, due to the sis mail server policy, sender's field will be set as chinese name and account. So the mail would contain UTF-8 charset, and I cannot change it. Sorry for inconvenience. Best Regards, Morgan Tsai -----Original Message----- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006 at gmx.net] Sent: Wednesday, January 09, 2008 7:42 PM To: ??? (my_tsai) Cc: LinuxBIOS Subject: Re: [LinuxBIOS] [PATCH] Gigabyte GA-2761GXDK readability improvements Dear Morgan, On 09.01.2008 04:49, ??? (my_tsai) wrote: > Yes, I agreed. > Thanks, committed in revision 3041. > Thanks for your efforts. > You are welcome. Do you know when the board will be available for purchase? Regards, Carl-Daniel From rminnich at gmail.com Thu Jan 10 05:16:52 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 9 Jan 2008 20:16:52 -0800 Subject: [LinuxBIOS] flashrom on ga 2761gxdk In-Reply-To: <4785572C.2070708@gmx.net> References: <13426df10801082236o6974bc7agf705b168fa322941@mail.gmail.com> <4784AFD2.5090401@gmx.net> <13426df10801090803k1f6cac62sd757633c12a651bd@mail.gmail.com> <4785572C.2070708@gmx.net> Message-ID: <13426df10801092016o3b47fd9bl76887c70549c75b3@mail.gmail.com> verbose output attached. With the patch, it no longer finds the flash part. I will look at this too, but I thought you might find it useful ron -------------- next part -------------- A non-text attachment was scrubbed... Name: out Type: application/octet-stream Size: 6175 bytes Desc: not available URL: From bari at onelabs.com Thu Jan 10 06:06:07 2008 From: bari at onelabs.com (bari) Date: Wed, 09 Jan 2008 23:06:07 -0600 Subject: [LinuxBIOS] [PATCH] Gigabyte GA-2761GXDK readability improvements In-Reply-To: <8B129BF6F7AD7E4885A011ED7297EC9C0B5687@SISMBEV02.sis.com.tw> References: <478268D6.2030906@gmx.net> <8B129BF6F7AD7E4885A011ED7297EC9C0B55EE@SISMBEV02.sis.com.tw> <4784B2EB.6020906@gmx.net> <8B129BF6F7AD7E4885A011ED7297EC9C0B5687@SISMBEV02.sis.com.tw> Message-ID: <4785A7BF.4010308@onelabs.com> Gigabyte also calls the GA-2761GXDK the Churchill Home Server. IEI Technology Corp. has a simliar board here: http://www.ieiworld.com/en/Product_IPC.asp?model=KINO-761AM2 Foxconn has a 761GXM2MA-KRS2H: http://www.foxconnchannel.com/product/Motherboards/detail_spec.aspx?ID=en-us0000248 and a 761GXM2MA-RS2 http://www.foxconnchannel.com/product/Motherboards/detail_spec.aspx?ID=en-us0000324 they also have a 761MX with the SIS? 761GX + 968 http://www.foxconnchannel.com/product/Motherboards/detail_spec.aspx?ID=en-us0000336 -Bari ??? (my_tsai) wrote: > Dear Carl-Daniel, > > As I know, the board is designed for home server. I'm not sure it would be available for retail. > > Btw, due to the sis mail server policy, sender's field will be set as chinese name and account. > So the mail would contain UTF-8 charset, and I cannot change it. > > Sorry for inconvenience. > > > > > > > Best Regards, > > Morgan Tsai > > > > -----Original Message----- > From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006 at gmx.net] > Sent: Wednesday, January 09, 2008 7:42 PM > To: ??? (my_tsai) > Cc: LinuxBIOS > Subject: Re: [LinuxBIOS] [PATCH] Gigabyte GA-2761GXDK readability improvements > > Dear Morgan, > > On 09.01.2008 04:49, ??? (my_tsai) wrote: > >> Yes, I agreed. >> >> > > Thanks, committed in revision 3041. > > >> Thanks for your efforts. >> >> > > You are welcome. > > Do you know when the board will be available for purchase? > > > Regards, > Carl-Daniel > > From rminnich at gmail.com Thu Jan 10 06:08:14 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 9 Jan 2008 21:08:14 -0800 Subject: [LinuxBIOS] flashrom on ga 2761gxdk In-Reply-To: <4784AFD2.5090401@gmx.net> References: <13426df10801082236o6974bc7agf705b168fa322941@mail.gmail.com> <4784AFD2.5090401@gmx.net> Message-ID: <13426df10801092108q78c92393p7f91f5fbd08cb715@mail.gmail.com> Turns out, with a few debug prints added, I am more confused than I realized. The port is set to a reasonable value and it is indeed trying to flash (port is 0a30). It gets right into the page programming. The flash is mmap'ed. It's doing all the right things, but programming time appears to be zero. I put some prints in and this part: while (generic_spi_read_status_register() & JEDEC_RDSR_BIT_WIP) usleep(1000); completes instantly. So, not sure what to go after. Morgan, is the ITE8761F the part that should let me program SPI? Is there any mainboard-specific trick to making programming of SPI work? thanks ron From myles at pel.cs.byu.edu Thu Jan 10 06:20:07 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Wed, 9 Jan 2008 22:20:07 -0700 Subject: [LinuxBIOS] PCI device memory resource In-Reply-To: <654527.65238.qm@web51603.mail.re2.yahoo.com> References: <654527.65238.qm@web51603.mail.re2.yahoo.com> Message-ID: <003101c85348$77f980d0$2023040a@chimp> I'm guessing that you're asking if it has to have as much memory as the resource. If that's the case, the answer is no. You just have to respond to any request in that region. In other words, you could request a 1 GB region and only respond with useful data in the first 1 MB (respond to any other read with zeros), or map the 1 MB 1024 times into the 1 GB, or anything else you decide. Sorry if I totally missed the intent of your question, Myles _____ From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Baski Sent: Wednesday, January 09, 2008 7:06 PM To: linuxbios at linuxbios.org Subject: [LinuxBIOS] PCI device memory resource For a PCI device to request memory resource of ,say 1MB, should it have onboard memory of 1MB ? TIA -- People wielding power and authority always desire to destroy the sources which gave them that power. Or, is it the other way round? _____ Never miss a thing. Make Yahoo your homepage. -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey.osgood at gmail.com Thu Jan 10 06:24:55 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Thu, 10 Jan 2008 00:24:55 -0500 Subject: [LinuxBIOS] Intel refactoring and microcode updates In-Reply-To: <20080109212412.cgsck1t6xxcww4s8@www.smittys.pointclark.net> References: <47843324.2050907@gmail.com> <20080109212412.cgsck1t6xxcww4s8@www.smittys.pointclark.net> Message-ID: <4785AC27.40102@gmail.com> joe at smittys.pointclark.net wrote: > Quoting Corey Osgood : > > >> I've separated this into two patches, one code and one microcode, to >> improve readability, but they would both have to be committed at once >> (else things break). These patches eliminate a lot of repeated code, >> make porting and adding new CPUs easier, add all the latest released >> microcode updates, and add somewhat experimental support for the latest >> lga775 cpus, along with various other currently unsupported CPUs. >> Unfortunately, not everything works quite right yet. Here's the broken >> stuff: >> >> * socket_603: includes all Xeon model f0x, f1x, and f2x cpus. This may >> be incorrect, but I can't see any easy way to find out. >> * socket_604: includes all Xeon model f2x, f3x, f4x, and f6x. Same as >> above, with the added bonus of being too large to fit with any current >> board. It should also include the socket_603 IDs, since socket 603 CPUs >> work on socket 604 boards. >> * socket_775: too large to build with most current ports, but it could >> probably be broken down into socket_775_pentium and socket_775_core. All >> fxx IDs are pentium 4/D, and 6xx IDs are Core/Core 2 >> >> For now, I've left the current model_fxx and socket_*60*, so nothing >> breaks, but IMO the socket_603/604 I've added should be made to work. >> >> Both patches Signed-off-by: Corey Osgood >> >> > Hmm looks good. Should we add a quick note to each file to what > processor it belongs too? I think that would save developers time from > having to look it up when writing code for a new board? What do you > think? > > > Thanks - Joe > > Do you mean the microcode files? If so, the microcode update looks like this: Header Update Revision Date Processor Signature (CPU ID) ... So, the 4th entry in the update is always the CPU ID, and conveniently it's always the last one on the first line. It also makes grepping for them very easy, once you have the update broken down into smaller files. This is documented *somewhere* in LB, but I can't find it at the moment. It's also in the Intel architecture manual, volume 3a, table 9-6. In the past we labeled some CPU IDs as to what CPUs they belonged to. In truth, Intel uses the same CPU IDs for a variety of CPUs, for instance in some cases Celeron, Pentium X, and Xeons all share a common ID, since the core is still the same. So we can't really do that any more ;) -Corey From atschauschev at yahoo.com Thu Jan 10 11:51:41 2008 From: atschauschev at yahoo.com (Andon Tschauschev) Date: Thu, 10 Jan 2008 02:51:41 -0800 (PST) Subject: [LinuxBIOS] Question about disassembler for byte stream Message-ID: <372516.60688.qm@web33213.mail.mud.yahoo.com> Hi, Is there such thing like disassembler for byte streams? For example: I extract some memory through /dev/mem: 'dd if=/dev/mem of=./dump_1.dat bs=1 count=708K' Then I can look at the extracted memory using hexdump: 'hexdump -vC dump_1.dat | less' But reading machine code is not very comfortable... With the mentioned disassembler I would be able to do: 'streamdisass -i dump_1.dat -o dump_1.asm' and then enjoy the asm-representation of the dump? Thanks Andon ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From duwe at lst.de Thu Jan 10 12:09:06 2008 From: duwe at lst.de (Torsten Duwe) Date: Thu, 10 Jan 2008 12:09:06 +0100 Subject: [LinuxBIOS] Question about disassembler for byte stream In-Reply-To: <372516.60688.qm@web33213.mail.mud.yahoo.com> References: <372516.60688.qm@web33213.mail.mud.yahoo.com> Message-ID: <200801101209.06425.duwe@lst.de> On Thursday 10 January 2008, Andon Tschauschev wrote: > I extract some memory through /dev/mem: > 'dd if=/dev/mem of=./dump_1.dat bs=1 count=708K' > > Then I can look at the extracted memory using hexdump: > 'hexdump -vC dump_1.dat | less' > > But reading machine code is not very comfortable... > > With the mentioned disassembler I would be able to do: > 'streamdisass -i dump_1.dat -o dump_1.asm' > and then enjoy the asm-representation of the dump? What's wrong with objdump -D -b binary -m i386:x86-64 ? (Assuming you have an AMD64 machine) Torsten From echelon at free.fr Thu Jan 10 12:14:46 2008 From: echelon at free.fr (Florentin Demetrescu) Date: Thu, 10 Jan 2008 12:14:46 +0100 Subject: [LinuxBIOS] m57sli : debugging the flashrom problem when booting with LB In-Reply-To: <4766DD09.1070400@gmx.net> References: <47668D76.6060602@gmx.net> <4766DD09.1070400@gmx.net> Message-ID: <1199963686.4785fe264a52d@imp.free.fr> Hi all, I started working on this problem this week and there are some strange things I have found so far. First, the behaviour I noticed when starting flashrom after booting whith LB : 1) flashrom needs to be given the board type in command line parameter (-m gigabyte:m57sli) otherwise it is unable to recognize this board. On the other hand it seems to correctly recognize the SB type (mcp55) and the SIO too (it8716). It seems that it succeeds in reading and writting the configuration registers of the SIO (those accesible through the 0x2e - 0x2f pair of IO ports) at least.. 2) the real problem is that it hangs when trying to access the SPI interface of the SIO, more precisely when pooling the "busy flag" of the configuration register of the SPI interface before sending a SPI command, normally mapped at the 0x820 IO address. Indeed when dumping the value which is read @ this address, one get a value 0xff! It doesn't seem to me that this register should have normally this value, there seem to be a problem with the decoding of this IO address range into the mcp55 SB very probably.. 3) the most strange thing is that when probing with an oscilloscope the SPI signals, there _IS_ indeed a burst of activity on the CLK line when executing flashrom. Some code into flashrom seems to generate this activity, but I haven't found so far where it is triggerd. But from the flashrom point of view there is no reponse from the spi interface so it hangs.. Rudolf Marek suggested after an irc discussion that there could be problems with the GPIO configuration, but I don't think so, because if that would be the case then we couldn't access the SIO at all and the platform wouldn't boot at all with LB. But who knows? Rudolf, can you be more specific about this GPIO hypothesis?.. For my part I continue to think that there is a problem with the IO address decoding into the PCI->LPC bridge in mcp55.. Yinghai, can you help please? Regards, Florentin From c-d.hailfinger.devel.2006 at gmx.net Thu Jan 10 13:12:49 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 10 Jan 2008 13:12:49 +0100 Subject: [LinuxBIOS] flashrom on ga 2761gxdk In-Reply-To: <13426df10801092016o3b47fd9bl76887c70549c75b3@mail.gmail.com> References: <13426df10801082236o6974bc7agf705b168fa322941@mail.gmail.com> <4784AFD2.5090401@gmx.net> <13426df10801090803k1f6cac62sd757633c12a651bd@mail.gmail.com> <4785572C.2070708@gmx.net> <13426df10801092016o3b47fd9bl76887c70549c75b3@mail.gmail.com> Message-ID: <47860BC1.8050002@gmx.net> On 10.01.2008 05:16, ron minnich wrote: > verbose output attached. With the patch, it no longer finds the flash part. > Ah ok, I misunderstood. I thought the routine was unable to find the port. Looking at the log, we see: > LPC write to serial flash disabled > Which naturally means all writes will never reach the chip. Try the patch below: Enable LPC write cycle to SPI write cycle translation for IT8716F. Signed-off-by: Carl-Daniel Hailfinger Index: flashrom-ron/spi.c =================================================================== --- flashrom-ron/spi.c (Revision 3036) +++ flashrom-ron/spi.c (Arbeitskopie) @@ -136,6 +136,11 @@ 0xFFF80000, 0xFFFEFFFF, (tmp & 1 << 3) ? "en" : "dis"); printf("LPC write to serial flash %sabled\n", (tmp & 1 << 4) ? "en" : "dis"); + if (!(tmp & 1 << 4)) { + printf("Force enabling LPC write to serial flash\n"); + tmp |= 1 << 4; + regwrite(port, 0x24, tmp); + } printf("serial flash pin %i\n", (tmp & 1 << 5) ? 87 : 29); /* LDN 0x7, reg 0x64/0x65 */ regwrite(port, 0x07, 0x7); > Serial flash segment 0xfffe0000-0xffffffff enabled > Serial flash segment 0x000e0000-0x000fffff enabled > Serial flash segment 0xffee0000-0xffefffff disabled > Serial flash segment 0xfff80000-0xfffeffff enabled > That's the next problem. Do you see the gaps and overlaps between ranges? It seems it is entirely impossible to map flash to the 0xfff00000-0xfff7ffff range. Then again, this might be a data sheet bug. I'm reasonably sure a dump of the 1 MByte chip (if that chip has different contents in the upper and lower 512 kByte) will clear up any misunderstandings. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Thu Jan 10 13:32:34 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 10 Jan 2008 13:32:34 +0100 Subject: [LinuxBIOS] flashrom on ga 2761gxdk In-Reply-To: <47860BC1.8050002@gmx.net> References: <13426df10801082236o6974bc7agf705b168fa322941@mail.gmail.com> <4784AFD2.5090401@gmx.net> <13426df10801090803k1f6cac62sd757633c12a651bd@mail.gmail.com> <4785572C.2070708@gmx.net> <13426df10801092016o3b47fd9bl76887c70549c75b3@mail.gmail.com> <47860BC1.8050002@gmx.net> Message-ID: <47861062.3020909@gmx.net> Btw, the block lock bits are all set, so even if you manage to convince the SPI translation to map more than 512 KByte and even if you use enable LPC-to-SPI writes, you will still flash nothing. Try this for better lock bit printing: Enable LPC write cycle to SPI write cycle translation for IT8716F. Print detailed status register information for SST25VF series flash. Signed-off-by: Carl-Daniel Hailfinger Index: flashrom-ron/spi.c =================================================================== --- flashrom-ron/spi.c (Revision 3036) +++ flashrom-ron/spi.c (Arbeitskopie) @@ -136,6 +136,11 @@ 0xFFF80000, 0xFFFEFFFF, (tmp & 1 << 3) ? "en" : "dis"); printf("LPC write to serial flash %sabled\n", (tmp & 1 << 4) ? "en" : "dis"); + if (!(tmp & 1 << 4)) { + printf("Force enabling LPC write to serial flash\n"); + tmp |= 1 << 4; + regwrite(port, 0x24, tmp); + } printf("serial flash pin %i\n", (tmp & 1 << 5) ? 87 : 29); /* LDN 0x7, reg 0x64/0x65 */ regwrite(port, 0x07, 0x7); @@ -323,7 +328,8 @@ switch (flash->manufacture_id) { case ST_ID: case MX_ID: - if ((flash->model_id & 0xff00) == 0x2000) + if (((flash->model_id & 0xff00) == 0x2000) || + ((flash->model_id & 0xff00) == 0x2500)) generic_spi_prettyprint_status_register_st_m25p(status); break; } From harald.gutmann at gmx.net Thu Jan 10 13:39:35 2008 From: harald.gutmann at gmx.net (Harald Gutmann) Date: Thu, 10 Jan 2008 13:39:35 +0100 Subject: [LinuxBIOS] Please add support for MX25L8005 and MX25L3205D In-Reply-To: <47856608.2010106@gmx.net> References: <200801100100.30695.harald.gutmann@gmx.net> <47856608.2010106@gmx.net> Message-ID: <200801101339.35711.harald.gutmann@gmx.net> Am Donnerstag, 10. Januar 2008 01:25:44 schrieb Carl-Daniel Hailfinger: > Just adding the right values to flashchips.c is not enough. I need > "flashrom -V" output both with your patch and without your patch. first here is a diff between my "patched" and the actual plain svn version of flashrom: diff -ubr flashrom.plain/flashchips.c flashrom.patched/flashchips.c --- flashrom.plain/flashchips.c 2008-01-10 13:29:32.000000000 +0100 +++ flashrom.patched/flashchips.c 2008-01-10 13:32:53.000000000 +0100 @@ -52,6 +52,8 @@ probe_29f002, erase_29f002, write_29f002}, {"MX25L4005", MX_ID, MX_25L4005, 512, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, + {"MX25L8005", MX_ID, MX_25L8005, 1024, 256, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, {"SST25VF040B", SST_ID, SST_25VF040B, 512, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, {"SST25VF016B", SST_ID, SST_25VF016B, 2048, 256, > > It would be really fine, if someone of you could implement that > > correctly, i can and will test if it works. > > I can implement support if I have the output mentioned above. Your > problem seems to be caused by the flash translation chip and not the > flash chip. The output of both flashrom versions is attached. > Regards, > Carl-Daniel Thanks for investigating this issue. Regards, Harald -------------- next part -------------- Calibrating delay loop... 296M loops per second. OK. No LinuxBIOS table found. Found chipset "NVIDIA MCP55", enabling flash write... OK. Found board "GIGABYTE GA-M57SLI-S4": enabling flash write... Serial flash segment 0xfffe0000-0xffffffff enabled Serial flash segment 0x000e0000-0x000fffff enabled Serial flash segment 0xffee0000-0xffefffff disabled Serial flash segment 0xfff80000-0xfffeffff enabled LPC write to serial flash enabled serial flash pin 29 OK. Probing for Am29F040B, 512 KB probe_29f040b: id1 0x49, id2 0x4d Probing for Am29LV040B, 512 KB probe_29f040b: id1 0x49, id2 0x4d Probing for Am29F016D, 2048 KB probe_29f040b: id1 0xff, id2 0xff Probing for AE49F2008, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for At29C040A, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for At29C020, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for At49F002(N), 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for At49F002(N)T, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for EN29F002(A)(N)T, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for EN29F002(A)(N)B, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for MBM29F400TC, 512 KB probe_m29f400bt: id1 0x49, id2 0x44 Probing for MX29F002, 256 KB probe_29f002: id1 0x92, id2 0xe4 Probing for MX25L4005, 512 KB RDID returned c2 20 14. probe_spi: id1 0xc2, id2 0x2014 Probing for MX25L8005, 1024 KB RDID returned c2 20 14. probe_spi: id1 0xc2, id2 0x2014 Chip status register is 00 Chip status register: Status Register Write Disable (SRWD) is not set Chip status register: Bit 6 is not set Chip status register: Bit 5 is not set Chip status register: Block Protect 2 (BP2) is not set Chip status register: Block Protect 1 (BP1) is not set Chip status register: Block Protect 0 (BP0) is not set Chip status register: Write Enable Latch (WEL) is not set Chip status register: Write In Progress (WIP) is not set MX25L8005 found at physical address 0xfff00000. Flash part is MX25L8005 (1024 KB). No operations were specified. -------------- next part -------------- Calibrating delay loop... 371M loops per second. OK. No LinuxBIOS table found. Found chipset "NVIDIA MCP55", enabling flash write... OK. Found board "GIGABYTE GA-M57SLI-S4": enabling flash write... Serial flash segment 0xfffe0000-0xffffffff enabled Serial flash segment 0x000e0000-0x000fffff enabled Serial flash segment 0xffee0000-0xffefffff disabled Serial flash segment 0xfff80000-0xfffeffff enabled LPC write to serial flash enabled serial flash pin 29 OK. Probing for Am29F040B, 512 KB probe_29f040b: id1 0x49, id2 0x4d Probing for Am29LV040B, 512 KB probe_29f040b: id1 0x49, id2 0x4d Probing for Am29F016D, 2048 KB probe_29f040b: id1 0xff, id2 0xff Probing for AE49F2008, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for At29C040A, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for At29C020, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for At49F002(N), 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for At49F002(N)T, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for EN29F002(A)(N)T, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for EN29F002(A)(N)B, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for MBM29F400TC, 512 KB probe_m29f400bt: id1 0x49, id2 0x44 Probing for MX29F002, 256 KB probe_29f002: id1 0x92, id2 0xe4 Probing for MX25L4005, 512 KB RDID returned c2 20 14. probe_spi: id1 0xc2, id2 0x2014 Probing for SST25VF040B, 512 KB RDID returned c2 20 14. probe_spi: id1 0xc2, id2 0x2014 Probing for SST25VF016B, 2048 KB RDID returned c2 20 14. probe_spi: id1 0xc2, id2 0x2014 Probing for SST29EE020A, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for SST28SF040A, 512 KB probe_28sf040: id1 0x49, id2 0x4d Probing for SST39SF010A, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for SST39SF020A, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for SST39SF040, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for SST39VF020, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for SST49LF040B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for SST49LF040, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for SST49LF020A, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for SST49LF080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF002A/B, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for SST49LF003A/B, 384 KB probe_jedec: id1 0x12, id2 0x17 Probing for SST49LF004A/B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for SST49LF008A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF004C, 512 KB probe_49lfxxxc: id1 0x49, id2 0x4d Probing for SST49LF008C, 1024 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST49LF016C, 2048 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST49LF160C, 2048 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for Pm49FL002, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for Pm49FL004, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W29C011, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for W29C040P, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W29C020C, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for W29EE011, 128 KB probe_w29ee011: id1 0xff, id2 0xff Probing for W49F002U, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for W49V002A, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for W49V002FA, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for W39V040FA, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W39V040A, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W39V040B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W39V080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M29F002B, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for M50FW040, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for M29W040B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for M29F002T/NT, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for M29F400BT, 512 KB probe_m29f400bt: id1 0x49, id2 0x44 Probing for M50FLW040A, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for M50FLW040B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for M50FLW080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FLW080B, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FW080, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FW016, 2048 KB probe_jedec: id1 0xff, id2 0xff Probing for M50LPW116, 2048 KB probe_jedec: id1 0xff, id2 0xff Probing for M29W010B, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for M29F040B, 512 KB probe_29f040b: id1 0x49, id2 0x4d Probing for M25P05-A, 64 KB RDID returned c2 20 14. probe_spi: id1 0xc2, id2 0x2014 Probing for M25P10-A, 128 KB RDID returned c2 20 14. probe_spi: id1 0xc2, id2 0x2014 Probing for M25P20, 256 KB RDID returned c2 20 14. probe_spi: id1 0xc2, id2 0x2014 Probing for M25P40, 512 KB RDID returned c2 20 14. probe_spi: id1 0xc2, id2 0x2014 Probing for M25P80, 1024 KB RDID returned c2 20 14. probe_spi: id1 0xc2, id2 0x2014 Probing for M25P16, 2048 KB RDID returned c2 20 14. probe_spi: id1 0xc2, id2 0x2014 Probing for M25P32, 4096 KB RDID returned c2 20 14. probe_spi: id1 0xc2, id2 0x2014 Probing for M25P64, 8192 KB RDID returned c2 20 14. probe_spi: id1 0xc2, id2 0x2014 Probing for M25P128, 16384 KB RDID returned c2 20 14. probe_spi: id1 0xc2, id2 0x2014 Probing for 82802ab, 512 KB probe_82802ab: id1 0x49, id2 0x4d Probing for 82802ac, 1024 KB probe_82802ab: id1 0xff, id2 0xff Probing for F49B002UA, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for LHF00L04, 1024 KB probe_lhf00l04: id1 0xff, id2 0xff Probing for S29C51001T, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for S29C51002T, 256 KB probe_jedec: id1 0x92, id2 0xe4 Probing for S29C51004T, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for S29C31004T, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for EON unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned c2 20 14. probe_spi: id1 0xc2, id2 0x2014 Probing for MX unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned c2 20 14. probe_spi: id1 0xc2, id2 0x2014 MX unknown SPI chip found at physical address 0x100000000. Flash part is MX unknown SPI chip (0 KB). No operations were specified. From c-d.hailfinger.devel.2006 at gmx.net Thu Jan 10 13:42:41 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 10 Jan 2008 13:42:41 +0100 Subject: [LinuxBIOS] m57sli : debugging the flashrom problem when booting with LB In-Reply-To: <1199963686.4785fe264a52d@imp.free.fr> References: <47668D76.6060602@gmx.net> <4766DD09.1070400@gmx.net> <1199963686.4785fe264a52d@imp.free.fr> Message-ID: <478612C1.7090504@gmx.net> On 10.01.2008 12:14, Florentin Demetrescu wrote: > Hi all, > > I started working on this problem this week and there are some strange things I > have found so far. > Thanks for trying to figure this out! > First, the behaviour I noticed when starting flashrom after booting whith LB : > 1) flashrom needs to be given the board type in command line parameter (-m > gigabyte:m57sli) otherwise it is unable to recognize this board. On the other > hand it seems to correctly recognize the SB type (mcp55) and the SIO too > (it8716). It seems that it succeeds in reading and writting the configuration > registers of the SIO (those accesible through the 0x2e - 0x2f pair of IO ports) > at least.. > It seems the board identifiers used inside LB and inside flashrom differ. > 2) the real problem is that it hangs when trying to access the SPI interface of > the SIO, more precisely when pooling the "busy flag" of the configuration > register of the SPI interface before sending a SPI command, normally mapped at > the 0x820 IO address. Indeed when dumping the value which is read @ this > address, one get a value 0xff! It doesn't seem to me that this register should > have normally this value, there seem to be a problem with the decoding of this > IO address range into the mcp55 SB very probably.. > Yes indeed. > 3) the most strange thing is that when probing with an oscilloscope the SPI > signals, there _IS_ indeed a burst of activity on the CLK line when executing > flashrom. Some code into flashrom seems to generate this activity, but I haven't > That's the classic parallel flash probing which reads from and writes to the memory area of the chip. > found so far where it is triggerd. But from the flashrom point of view there is > no reponse from the spi interface so it hangs.. > Yes, that's the SPI probing which waits on the status register as you said. > Rudolf Marek suggested after an irc discussion that there could be problems with > the GPIO configuration, but I don't think so, because if that would be the case > then we couldn't access the SIO at all and the platform wouldn't boot at all > with LB. But who knows? Rudolf, can you be more specific about this GPIO > hypothesis?.. > For my part I continue to think that there is a problem with the IO address > decoding into the PCI->LPC bridge in mcp55.. Yinghai, can you help please? > Yinghai? Is there some mcp55 conf we need to change? Regards, Carl-Daniel From joe at smittys.pointclark.net Thu Jan 10 13:48:42 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Thu, 10 Jan 2008 07:48:42 -0500 Subject: [LinuxBIOS] Intel refactoring and microcode updates In-Reply-To: <4785AC27.40102@gmail.com> References: <47843324.2050907@gmail.com> <20080109212412.cgsck1t6xxcww4s8@www.smittys.pointclark.net> <4785AC27.40102@gmail.com> Message-ID: <20080110074842.3p5v4fkoowkg408w@www.smittys.pointclark.net> Quoting Corey Osgood : > joe at smittys.pointclark.net wrote: >> Quoting Corey Osgood : >> >> >>> I've separated this into two patches, one code and one microcode, to >>> improve readability, but they would both have to be committed at once >>> (else things break). These patches eliminate a lot of repeated code, >>> make porting and adding new CPUs easier, add all the latest released >>> microcode updates, and add somewhat experimental support for the latest >>> lga775 cpus, along with various other currently unsupported CPUs. >>> Unfortunately, not everything works quite right yet. Here's the broken >>> stuff: >>> >>> * socket_603: includes all Xeon model f0x, f1x, and f2x cpus. This may >>> be incorrect, but I can't see any easy way to find out. >>> * socket_604: includes all Xeon model f2x, f3x, f4x, and f6x. Same as >>> above, with the added bonus of being too large to fit with any current >>> board. It should also include the socket_603 IDs, since socket 603 CPUs >>> work on socket 604 boards. >>> * socket_775: too large to build with most current ports, but it could >>> probably be broken down into socket_775_pentium and socket_775_core. All >>> fxx IDs are pentium 4/D, and 6xx IDs are Core/Core 2 >>> >>> For now, I've left the current model_fxx and socket_*60*, so nothing >>> breaks, but IMO the socket_603/604 I've added should be made to work. >>> >>> Both patches Signed-off-by: Corey Osgood >>> >>> >> Hmm looks good. Should we add a quick note to each file to what >> processor it belongs too? I think that would save developers time from >> having to look it up when writing code for a new board? What do you >> think? >> >> >> Thanks - Joe >> >> > Do you mean the microcode files? If so, the microcode update looks like > this: > > Header > Update Revision > Date > Processor Signature (CPU ID) > ... > > So, the 4th entry in the update is always the CPU ID, and conveniently > it's always the last one on the first line. It also makes grepping for > them very easy, once you have the update broken down into smaller files. > This is documented *somewhere* in LB, but I can't find it at the moment. > It's also in the Intel architecture manual, volume 3a, table 9-6. > > In the past we labeled some CPU IDs as to what CPUs they belonged to. In > truth, Intel uses the same CPU IDs for a variety of CPUs, for instance > in some cases Celeron, Pentium X, and Xeons all share a common ID, since > the core is still the same. So we can't really do that any more ;) > > -Corey > Oh ok, that makes sense. Acked-by: Joseph Smith Thanks - Joe From joe at smittys.pointclark.net Thu Jan 10 13:52:41 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Thu, 10 Jan 2008 07:52:41 -0500 Subject: [LinuxBIOS] svn question In-Reply-To: References: <20080109215903.kz0x1vj1c0swkgwk@www.smittys.pointclark.net> Message-ID: <20080110075241.kwsi87b2g40sk004@www.smittys.pointclark.net> Quoting Robinson Tryon : > On Jan 9, 2008 9:59 PM, wrote: >> Dumb question, but I can't seem to find any real good docs on svn. How >> to I commit a patch to my local LinuxBIOSV2 copy?? > > Do you want to commit something to a repository, or do you just want > to patch your local checkout? > > To merge a patch into your local svn checkout you can use the 'patch' > tool. Check out the man page for specifics -- but you'll basically > run something like: > > patch /path/to/file /patch/to/patchfile.patch > > Here's a couple of examples: http://wiki.creativecommons.org/HOWTO_Patch > Thanks for the help. To be specific I want to test the fedora core 8 patch. So I would just do a: patch ../LinuxBIOSv2 /patch/to/patchfile.patch because the patch was supposed to be created at the top of the LB tree? Thanks - Joe From c-d.hailfinger.devel.2006 at gmx.net Thu Jan 10 13:56:05 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 10 Jan 2008 13:56:05 +0100 Subject: [LinuxBIOS] Please add support for MX25L8005 and MX25L3205D In-Reply-To: <200801101339.35711.harald.gutmann@gmx.net> References: <200801100100.30695.harald.gutmann@gmx.net> <47856608.2010106@gmx.net> <200801101339.35711.harald.gutmann@gmx.net> Message-ID: <478615E5.7020207@gmx.net> On 10.01.2008 13:39, Harald Gutmann wrote: > Am Donnerstag, 10. Januar 2008 01:25:44 schrieb Carl-Daniel Hailfinger: > >> Just adding the right values to flashchips.c is not enough. I need >> "flashrom -V" output both with your patch and without your patch. >> > first here is a diff between my "patched" and the actual plain svn version of > flashrom: > > diff -ubr flashrom.plain/flashchips.c flashrom.patched/flashchips.c > --- flashrom.plain/flashchips.c 2008-01-10 13:29:32.000000000 +0100 > +++ flashrom.patched/flashchips.c 2008-01-10 13:32:53.000000000 +0100 > @@ -52,6 +52,8 @@ > probe_29f002, erase_29f002, write_29f002}, > {"MX25L4005", MX_ID, MX_25L4005, 512, 256, > probe_spi, generic_spi_chip_erase_c7, > generic_spi_chip_write}, > + {"MX25L8005", MX_ID, MX_25L8005, 1024, 256, > + probe_spi, generic_spi_chip_erase_c7, > generic_spi_chip_write}, > {"SST25VF040B", SST_ID, SST_25VF040B, 512, 256, > probe_spi, generic_spi_chip_erase_c7, > generic_spi_chip_write}, > {"SST25VF016B", SST_ID, SST_25VF016B, 2048, 256, > > > That part of the patch is correct. Can you give me a Signed-off-by: line? I will ack and commit. See http://linuxbios.org/Development_Guidelines#Sign-off_Procedure for details. >>> It would be really fine, if someone of you could implement that >>> correctly, i can and will test if it works. >>> >> I can implement support if I have the output mentioned above. Your >> problem seems to be caused by the flash translation chip and not the >> flash chip. >> > The output of both flashrom versions is attached. > Thanks, I now see that it is indeed a problem with the SPI translation. Can you try to flash some random data to the rom? Verify will fail. Then try to read back the rom and upload both original random data and readback result somewhere (rapidshare etc.) and I'll try to find out what the flash translation chip really supports. And please tell me how much RAM the machine has (if it is more than 2 GB, I need the amount of Video RAM as well). Regards, Carl-Daniel From harald.gutmann at gmx.net Thu Jan 10 14:12:26 2008 From: harald.gutmann at gmx.net (Harald Gutmann) Date: Thu, 10 Jan 2008 14:12:26 +0100 Subject: [LinuxBIOS] Please add support for MX25L8005 and MX25L3205D In-Reply-To: <478615E5.7020207@gmx.net> References: <200801100100.30695.harald.gutmann@gmx.net> <200801101339.35711.harald.gutmann@gmx.net> <478615E5.7020207@gmx.net> Message-ID: <200801101412.27106.harald.gutmann@gmx.net> Am Donnerstag, 10. Januar 2008 13:56:05 schrieb Carl-Daniel Hailfinger: > On 10.01.2008 13:39, Harald Gutmann wrote: > > Am Donnerstag, 10. Januar 2008 01:25:44 schrieb Carl-Daniel Hailfinger: > >> Just adding the right values to flashchips.c is not enough. I need > >> "flashrom -V" output both with your patch and without your patch. > > > > first here is a diff between my "patched" and the actual plain svn > > version of flashrom: > > > > diff -ubr flashrom.plain/flashchips.c flashrom.patched/flashchips.c > > --- flashrom.plain/flashchips.c 2008-01-10 13:29:32.000000000 +0100 > > +++ flashrom.patched/flashchips.c 2008-01-10 13:32:53.000000000 > > +0100 @@ -52,6 +52,8 @@ > > probe_29f002, erase_29f002, write_29f002}, > > {"MX25L4005", MX_ID, MX_25L4005, 512, 256, > > probe_spi, generic_spi_chip_erase_c7, > > generic_spi_chip_write}, > > + {"MX25L8005", MX_ID, MX_25L8005, 1024, 256, > > + probe_spi, generic_spi_chip_erase_c7, > > generic_spi_chip_write}, > > {"SST25VF040B", SST_ID, SST_25VF040B, 512, 256, > > probe_spi, generic_spi_chip_erase_c7, > > generic_spi_chip_write}, > > {"SST25VF016B", SST_ID, SST_25VF016B, 2048, 256, > > That part of the patch is correct. Can you give me a Signed-off-by: > line? I will ack and commit. See > http://linuxbios.org/Development_Guidelines#Sign-off_Procedure for details. Signed-off-by: Harald Gutmann > >>> It would be really fine, if someone of you could implement that > >>> correctly, i can and will test if it works. > >> > >> I can implement support if I have the output mentioned above. Your > >> problem seems to be caused by the flash translation chip and not the > >> flash chip. > > > > The output of both flashrom versions is attached. > > Thanks, I now see that it is indeed a problem with the SPI translation. > Can you try to flash some random data to the rom? Verify will fail. Then > try to read back the rom and upload both original random data and > readback result somewhere (rapidshare etc.) and I'll try to find out > what the flash translation chip really supports. http://rapidshare.com/files/82696074/flashrom_files.tar.gz.html the file random_original.rom is the file i writed to the chip, where this file was created using dd and /dev/urandom. the file random_read.rom is the file which i've read with flashrom after writing the random_original.rom to the chip. > And please tell me how much RAM the machine has (if it is more than 2 > GB, I need the amount of Video RAM as well). My machine has 4Gb (4x1Gb) of RAM and Viedo RAM is 256Mb on an Nvidia Grapic Card. > Regards, > Carl-Daniel Regards, Harald From c-d.hailfinger.devel.2006 at gmx.net Thu Jan 10 14:22:20 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 10 Jan 2008 14:22:20 +0100 Subject: [LinuxBIOS] [PATCH] Gigabyte GA-2761GXDK readability improvements In-Reply-To: <8B129BF6F7AD7E4885A011ED7297EC9C0B5687@SISMBEV02.sis.com.tw> References: <478268D6.2030906@gmx.net> <8B129BF6F7AD7E4885A011ED7297EC9C0B55EE@SISMBEV02.sis.com.tw> <4784B2EB.6020906@gmx.net> <8B129BF6F7AD7E4885A011ED7297EC9C0B5687@SISMBEV02.sis.com.tw> Message-ID: <47861C0C.2040105@gmx.net> Dear Morgan, On 10.01.2008 05:00, ??? (my_tsai) wrote: > As I know, the board is designed for home server. I'm not sure it would be available for retail. > Thanks for the information. > Btw, due to the sis mail server policy, sender's field will be set as chinese name and account. > So the mail would contain UTF-8 charset, and I cannot change it. > It seems your mail server uses the Big5 charset, but that is no problem because I work with UTF-8 and it seems to display your name just fine. We can use UTF-8 for code commits to display your name correctly in the changelog. Best Regards, Carl-Daniel From svn at openbios.org Thu Jan 10 14:27:22 2008 From: svn at openbios.org (svn at openbios.org) Date: Thu, 10 Jan 2008 14:27:22 +0100 Subject: [LinuxBIOS] r3042 - trunk/util/flashrom Message-ID: Author: hailfinger Date: 2008-01-10 14:27:22 +0100 (Thu, 10 Jan 2008) New Revision: 3042 Modified: trunk/util/flashrom/flashchips.c Log: Enable MX25L8005 support in flashrom. The #defines were already there. Signed-off-by: Harald Gutmann Acked-by: Carl-Daniel Hailfinger Modified: trunk/util/flashrom/flashchips.c =================================================================== --- trunk/util/flashrom/flashchips.c 2008-01-09 11:37:58 UTC (rev 3041) +++ trunk/util/flashrom/flashchips.c 2008-01-10 13:27:22 UTC (rev 3042) @@ -52,6 +52,8 @@ probe_29f002, erase_29f002, write_29f002}, {"MX25L4005", MX_ID, MX_25L4005, 512, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, + {"MX25L8005", MX_ID, MX_25L8005, 1024, 256, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, {"SST25VF040B", SST_ID, SST_25VF040B, 512, 256, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, {"SST25VF016B", SST_ID, SST_25VF016B, 2048, 256, From stepan at coresystems.de Thu Jan 10 14:36:12 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 10 Jan 2008 14:36:12 +0100 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <47822AFE.3060405@gmx.net> References: <477ED8F5.1030807@gmx.net> <47800115.1060301@coresystems.de> <13426df10801051423h5c9426f8p549d2874359dfb09@mail.gmail.com> <20080106112946.GA31641@coresystems.de> <13426df10801061129k202bf432gca91b051a3399813@mail.gmail.com> <4781F372.7080204@gmx.net> <20080107130111.GA12633@coresystems.de> <47822AFE.3060405@gmx.net> Message-ID: <20080110133612.GA20807@coresystems.de> * Carl-Daniel Hailfinger [080107 14:37]: > >> 2. Explicit free space covering lar member is fine, but to add any new > >> file to the archive, you have to erase the part covered by the exlusive > >> space. > >> > > > > I don't think this is such a bit problem. Lar could remove this entry > > automatically, and recreate it. This is not more special code in lar > > than 1. But I start thinking that those two are pretty much the same in > > the end. > > > > Yes, 1 and 2 are very similar. Your proposal is almost exactly what I > had in mind. This "dummy" member would be removed once a file was added > to the lar and the new entry would "overwrite" the dummy header. If we > have an explicit size in the dummy header, we can point to the next > header easily without having to stop. However, once we use an explicit > size (setting some bits to 0), we have to erase the flash block to add a > new entry in place of the dummy. One plea though: What you describe usually only happens in a (currently) very rare case. That is the case where the "free" entry falls exactly on a flash block border. Sure. We could have gaps to match up flash chip borders again. But this would re-introduce the problem of having to slowly walk a lot of space all the time. Also, a potential update might as well exchange modules instead of just adding modules that were not there before. This will potentially shift all files in the lar, making it necessary to reflash the complete flash chip. > If we don't specify the size and keep > all header entries (except magic) at value 0xff (all bits set), we still > can write the new archive member without erasing because setting bits to > 0 is always possible. I am not convinced that safing flash erase cycles on bios updates is worth any design considerations. With one BIOS update a day, even deleting all flash blocks makes an average SST chip live at least 273 years. Do we need to extend that? > My proposed code change is not very flexible and really only serves as > "end of interesting lar members" marker, but it is flash-friendly. > Besides that, the code can be overridden so if you really want to look > at the boot block, you can do so easily. So that would be another runtime parameter? > > What about a linked list in the header? Each file could explicitly point > > to the next file. If the pointer is 0 or -1, we stop. > > > > Nice idea, but it may not work in all cases. Requirements for this to > work cleanly are: > - The next pointer needs to have all bits set to 1 in the "stop pointer" > case, or it is impossible to add a member after the member with a stop > pointer without erasing the sector containing the header with the stop > pointer. Oh my idea was to have the bootblock have a "next" member of -1. So there would always be a next member with 0 and 1 bits except for the last one (that will not allow you to put one behind it anyways, due to the reset vector on the x86 architecture) Keep in mind that currently flashrom ALWAYS erases the complete flash chip except for some esoteric uses of the PMC PM49FL004. No, I am not saying that we should keep a good concept out of LinuxBIOS just because one of the tools can not cope with this yet. But I fail to see the whole picture in the solution yet. Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From c-d.hailfinger.devel.2006 at gmx.net Thu Jan 10 14:38:18 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 10 Jan 2008 14:38:18 +0100 Subject: [LinuxBIOS] Please add support for MX25L8005 and MX25L3205D In-Reply-To: <200801101412.27106.harald.gutmann@gmx.net> References: <200801100100.30695.harald.gutmann@gmx.net> <200801101339.35711.harald.gutmann@gmx.net> <478615E5.7020207@gmx.net> <200801101412.27106.harald.gutmann@gmx.net> Message-ID: <47861FCA.7070706@gmx.net> On 10.01.2008 14:12, Harald Gutmann wrote: > Am Donnerstag, 10. Januar 2008 13:56:05 schrieb Carl-Daniel Hailfinger: > >> On 10.01.2008 13:39, Harald Gutmann wrote: >> >>> Am Donnerstag, 10. Januar 2008 01:25:44 schrieb Carl-Daniel Hailfinger: >>> >>>> Just adding the right values to flashchips.c is not enough. I need >>>> "flashrom -V" output both with your patch and without your patch. >>>> >>> first here is a diff between my "patched" and the actual plain svn >>> version of flashrom: >>> >>> diff -ubr flashrom.plain/flashchips.c flashrom.patched/flashchips.c >>> --- flashrom.plain/flashchips.c 2008-01-10 13:29:32.000000000 +0100 >>> +++ flashrom.patched/flashchips.c 2008-01-10 13:32:53.000000000 >>> +0100 @@ -52,6 +52,8 @@ >>> probe_29f002, erase_29f002, write_29f002}, >>> {"MX25L4005", MX_ID, MX_25L4005, 512, 256, >>> probe_spi, generic_spi_chip_erase_c7, >>> generic_spi_chip_write}, >>> + {"MX25L8005", MX_ID, MX_25L8005, 1024, 256, >>> + probe_spi, generic_spi_chip_erase_c7, >>> generic_spi_chip_write}, >>> {"SST25VF040B", SST_ID, SST_25VF040B, 512, 256, >>> probe_spi, generic_spi_chip_erase_c7, >>> generic_spi_chip_write}, >>> {"SST25VF016B", SST_ID, SST_25VF016B, 2048, 256, >>> >> That part of the patch is correct. Can you give me a Signed-off-by: >> line? I will ack and commit. See >> http://linuxbios.org/Development_Guidelines#Sign-off_Procedure for details. >> > > Signed-off-by: Harald Gutmann > Thanks, r3042. >> Thanks, I now see that it is indeed a problem with the SPI translation. >> Can you try to flash some random data to the rom? Verify will fail. Then >> try to read back the rom and upload both original random data and >> readback result somewhere (rapidshare etc.) and I'll try to find out >> what the flash translation chip really supports. >> > http://rapidshare.com/files/82696074/flashrom_files.tar.gz.html > > the file random_original.rom is the file i writed to the chip, where this file > was created using dd and /dev/urandom. > the file random_read.rom is the file which i've read with flashrom after > writing the random_original.rom to the chip. > OK, I now know the exact problem. The IT8716F flash translation function does not work with chips bigger than 512 KByte unless you use a special software enable routine. >> And please tell me how much RAM the machine has (if it is more than 2 >> GB, I need the amount of Video RAM as well). >> > My machine has 4Gb (4x1Gb) of RAM and Viedo RAM is 256Mb on an Nvidia Grapic > Card. > Thanks, that is enough information. Please update to current svn (it has your patch) and apply the patch below. If random flashing with the patch works, can you give me an Ack? If it doesn't work, can you upload the new random_read.com? Forcibly enable LPC-to-SPI translation on IT8716F for the 0xFFEE0000 - 0xFFEFFFFF range. Signed-off-by: Carl-Daniel Hailfinger Index: flashrom-harald/spi.c =================================================================== --- flashrom-harald/spi.c (Revision 3042) +++ flashrom-harald/spi.c (Arbeitskopie) @@ -137,6 +137,8 @@ printf("LPC write to serial flash %sabled\n", (tmp & 1 << 4) ? "en" : "dis"); printf("serial flash pin %i\n", (tmp & 1 << 5) ? 87 : 29); + tmp |= 1 << 2; + regwrite(port, 0x24, tmp); /* LDN 0x7, reg 0x64/0x65 */ regwrite(port, 0x07, 0x7); flashport = regval(port, 0x64) << 8; From bishop.robinson at gmail.com Thu Jan 10 14:37:49 2008 From: bishop.robinson at gmail.com (Robinson Tryon) Date: Thu, 10 Jan 2008 08:37:49 -0500 Subject: [LinuxBIOS] svn question In-Reply-To: <20080110075241.kwsi87b2g40sk004@www.smittys.pointclark.net> References: <20080109215903.kz0x1vj1c0swkgwk@www.smittys.pointclark.net> <20080110075241.kwsi87b2g40sk004@www.smittys.pointclark.net> Message-ID: On Jan 10, 2008 7:52 AM, wrote: > > Quoting Robinson Tryon : > > > On Jan 9, 2008 9:59 PM, wrote: > >> Dumb question, but I can't seem to find any real good docs on svn. How > >> to I commit a patch to my local LinuxBIOSV2 copy?? > > > > Do you want to commit something to a repository, or do you just want > > to patch your local checkout? > > > > To merge a patch into your local svn checkout you can use the 'patch' > > tool. Check out the man page for specifics -- but you'll basically > > run something like: > > > > patch /path/to/file /patch/to/patchfile.patch > > > > Here's a couple of examples: http://wiki.creativecommons.org/HOWTO_Patch > > > Thanks for the help. To be specific I want to test the fedora core 8 > patch. So I would just do a: > > patch ../LinuxBIOSv2 /patch/to/patchfile.patch > > because the patch was supposed to be created at the top of the LB tree? If someone created a patchfile (my-patch.patch) at the top of the LB tree (/LinuxBIOSv2) then what you'll want to do is cd into that top-level directory: tux at iceberg:~$ cd LinuxBIOSv2 tux at iceberg:~/LinuxBIOSv2$ Then run the patch command: tux at iceberg:~/LinuxBIOSv2$ patch -p0 < my-patch.patch patching file Foo/Bar/bar.c patching file Foo/Bar/bar.h The "-p" switch indicates how many leading slashes should be stripped from the filenames in the diff before 'patch' tries to match them with existing files. If you have a patch made at the top level and you apply the patch at the top level, then just use -p0. Cheers, -- Robinson From stepan at coresystems.de Thu Jan 10 14:47:45 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 10 Jan 2008 14:47:45 +0100 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <13426df10801070840u786eaf23n6b41bc0462970996@mail.gmail.com> References: <477ED8F5.1030807@gmx.net> <47800115.1060301@coresystems.de> <13426df10801051423h5c9426f8p549d2874359dfb09@mail.gmail.com> <20080106112946.GA31641@coresystems.de> <13426df10801061129k202bf432gca91b051a3399813@mail.gmail.com> <4781F372.7080204@gmx.net> <13426df10801070840u786eaf23n6b41bc0462970996@mail.gmail.com> Message-ID: <20080110134745.GB20807@coresystems.de> * ron minnich [080107 17:40]: > I still find the explicit termination marker very interesting, esp. > since it is flash rewrite friendly. With a 100k average possible erase cycles per flash block, I never managed to exceed the life time for a flash chip, before they would die physically (ie. bend pins etc) The one reason why we don't want to erase the flash is because we don't want to have to rewrite the bootblock, risking to render the system unusable without special equipment. But to achieve safety here we don't even need to touch the "previous" element if we want to add a new element to the lar. Because the previous would point to the "empty" file or marker, and that's exactly the position where a new file would be put. > Pointers, let's not do them, instead, if we want such a thing, let's > do indices. If we start doing pointers, LAR is no longer > location-independent. Obviously we would not add the base address of the lar in memory when having a linked list but only keep the offset from the start of the lar. It's still a linked list. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From harald.gutmann at gmx.net Thu Jan 10 14:53:56 2008 From: harald.gutmann at gmx.net (Harald Gutmann) Date: Thu, 10 Jan 2008 14:53:56 +0100 Subject: [LinuxBIOS] Please add support for MX25L8005 and MX25L3205D In-Reply-To: <47861FCA.7070706@gmx.net> References: <200801100100.30695.harald.gutmann@gmx.net> <200801101412.27106.harald.gutmann@gmx.net> <47861FCA.7070706@gmx.net> Message-ID: <200801101453.56400.harald.gutmann@gmx.net> Am Donnerstag, 10. Januar 2008 14:38:18 schrieb Carl-Daniel Hailfinger: > OK, I now know the exact problem. The IT8716F flash translation function > does not work with chips bigger than 512 KByte unless you use a special > software enable routine. > > >> And please tell me how much RAM the machine has (if it is more than 2 > >> GB, I need the amount of Video RAM as well). > > > > My machine has 4Gb (4x1Gb) of RAM and Viedo RAM is 256Mb on an Nvidia > > Grapic Card. > > Thanks, that is enough information. > > Please update to current svn (it has your patch) and apply the patch > below. If random flashing with the patch works, can you give me an Ack? > If it doesn't work, can you upload the new random_read.com? It doesn't work with that patch. Here are the files: http://rapidshare.com/files/82704058/flashrom_files_patched.tar.gz.html A diff file to the original flashrom is also included. Regards, Harald From info at coresystems.de Thu Jan 10 15:14:56 2008 From: info at coresystems.de (LinuxBIOS information) Date: Thu, 10 Jan 2008 15:14:56 +0100 Subject: [LinuxBIOS] r3042 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "hailfinger" checked in revision 3042 to the LinuxBIOS source repository and caused the following changes: Change Log: Enable MX25L8005 support in flashrom. The #defines were already there. Signed-off-by: Harald Gutmann Acked-by: Carl-Daniel Hailfinger Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3042&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in hailfinger's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From c-d.hailfinger.devel.2006 at gmx.net Thu Jan 10 15:16:16 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 10 Jan 2008 15:16:16 +0100 Subject: [LinuxBIOS] Please add support for MX25L8005 and MX25L3205D In-Reply-To: <200801101453.56400.harald.gutmann@gmx.net> References: <200801100100.30695.harald.gutmann@gmx.net> <200801101412.27106.harald.gutmann@gmx.net> <47861FCA.7070706@gmx.net> <200801101453.56400.harald.gutmann@gmx.net> Message-ID: <478628B0.2070501@gmx.net> On 10.01.2008 14:53, Harald Gutmann wrote: > Am Donnerstag, 10. Januar 2008 14:38:18 schrieb Carl-Daniel Hailfinger: > >> OK, I now know the exact problem. The IT8716F flash translation function >> does not work with chips bigger than 512 KByte unless you use a special >> software enable routine. >> Please update to current svn (it has your patch) and apply the patch >> below. If random flashing with the patch works, can you give me an Ack? >> If it doesn't work, can you upload the new random_read.com? >> > It doesn't work with that patch. > Here are the files: > http://rapidshare.com/files/82704058/flashrom_files_patched.tar.gz.html > Thanks! It seems we can't support any flash chip bigger than 512 kByte on a board using IT8716F SPI translation without a LOT of effort. If you don't care about speed, it is probably possible to read and write a flash chip with any size, but you can't use anthing outside the bottom 512 kByte area before RAM shadows ROM. I have sent a mail to ITE to find out if we can use the IT8716F for bigger flash chips. If I get an answer, I will tell you. Regards, Carl-Daniel From ward at gnu.org Thu Jan 10 16:04:43 2008 From: ward at gnu.org (Ward Vandewege) Date: Thu, 10 Jan 2008 10:04:43 -0500 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <200801100031.31098.harald.gutmann@gmx.net> References: <20070902141108.GA9106@localdomain> <47520056.7060508@gmail.com> <20071202044824.3246.qmail@stuge.se> <200801100031.31098.harald.gutmann@gmx.net> Message-ID: <20080110150443.GA15940@localdomain> On Thu, Jan 10, 2008 at 12:31:31AM +0100, Harald Gutmann wrote: > > Of course this assumes that soldering 0402 resistors is considered > > simple, which isn't likely true unless you're good at SMT soldering. > A friend of mine helped me with the soldering, but he said that it is nearly > impossible to solder these resistors without industry-equipment. Actually, if you're interested in SMT soldering, check out this '101' video: http://www.curiousinventor.com/guides/Surface_Mount_Soldering/101 There is some very helpful information in there! Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From kbaski at yahoo.com Thu Jan 10 16:14:20 2008 From: kbaski at yahoo.com (Baski) Date: Thu, 10 Jan 2008 07:14:20 -0800 (PST) Subject: [LinuxBIOS] PCI device memory resource In-Reply-To: <003101c85348$77f980d0$2023040a@chimp> Message-ID: <467709.19100.qm@web51611.mail.re2.yahoo.com> Pardon my bad phrasing of the original question. I have a mem-mapped PCI controller which has no on-board memory, but is asking for 32MB memory resource. Is this legal? While BIOS gives it 32MB address space, who is going to malloc and give it the required memory to work with? Thanks - Baski Myles Watson wrote: v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} I?m guessing that you?re asking if it has to have as much memory as the resource. If that?s the case, the answer is no. You just have to respond to any request in that region. In other words, you could request a 1 GB region and only respond with useful data in the first 1 MB (respond to any other read with zeros), or map the 1 MB 1024 times into the 1 GB, or anything else you decide. Sorry if I totally missed the intent of your question, Myles --------------------------------- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Baski Sent: Wednesday, January 09, 2008 7:06 PM To: linuxbios at linuxbios.org Subject: [LinuxBIOS] PCI device memory resource For a PCI device to request memory resource of ,say 1MB, should it have onboard memory of 1MB ? TIA -- People wielding power and authority always desire to destroy the sources which gave them that power. Or, is it the other way round? --------------------------------- Never miss a thing. Make Yahoo your homepage. -- People wielding power and authority always desire to destroy the sources which gave them that power. Or, is it the other way round? --------------------------------- Never miss a thing. Make Yahoo your homepage. -------------- next part -------------- An HTML attachment was scrubbed... URL: From myles at pel.cs.byu.edu Thu Jan 10 17:06:34 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Thu, 10 Jan 2008 09:06:34 -0700 Subject: [LinuxBIOS] PCI device memory resource In-Reply-To: <467709.19100.qm@web51611.mail.re2.yahoo.com> References: <003101c85348$77f980d0$2023040a@chimp> <467709.19100.qm@web51611.mail.re2.yahoo.com> Message-ID: <005d01c853a2$c602aa90$2023040a@chimp> I think the confusion comes because of the difference between memory and memory address space. The PCI controller is asking for 32 MB of the physical address space, not memory. When the BIOS allocates this region in the address space, it is trusting that the PCI controller will respond to any reads/writes to that address space. There is no need to have actual RAM backing up every bit of address space, but the device needs to respond to accesses to its address space. Myles _____ From: Baski [mailto:kbaski at yahoo.com] Sent: Thursday, January 10, 2008 8:14 AM To: myles at mouselemur.cs.byu.edu; linuxbios at linuxbios.org Subject: RE: [LinuxBIOS] PCI device memory resource Pardon my bad phrasing of the original question. I have a mem-mapped PCI controller which has no on-board memory, but is asking for 32MB memory resource. Is this legal? While BIOS gives it 32MB address space, who is going to malloc and give it the required memory to work with? Thanks - Baski Myles Watson wrote: I'm guessing that you're asking if it has to have as much memory as the resource. If that's the case, the answer is no. You just have to respond to any request in that region. In other words, you could request a 1 GB region and only respond with useful data in the first 1 MB (respond to any other read with zeros), or map the 1 MB 1024 times into the 1 GB, or anything else you decide. Sorry if I totally missed the intent of your question, Myles _____ From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Baski Sent: Wednesday, January 09, 2008 7:06 PM To: linuxbios at linuxbios.org Subject: [LinuxBIOS] PCI device memory resource For a PCI device to request memory resource of ,say 1MB, should it have onboard memory of 1MB ? TIA -- People wielding power and authority always desire to destroy the sources which gave them that power. Or, is it the other way round? _____ Never miss a thing. Make Yahoo your homepage. -- People wielding power and authority always desire to destroy the sources which gave them that power. Or, is it the other way round? _____ Never miss a thing. Make Yahoo your homepage. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marc.Karasek at Sun.COM Thu Jan 10 17:06:08 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Thu, 10 Jan 2008 11:06:08 -0500 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: <2831fecf0801081454m71bb3ff3x3b2da3eb60d4aa37@mail.gmail.com> References: <477CF25C.7070901@sun.com> <477D507E.4030106@sun.com> <477E8A50.2080408@sun.com> <477EB7A1.80406@sun.com> <47824212.3030307@sun.com> <2831fecf0801070837n4c22d036t38254f5ee02d14d1@mail.gmail.com> <4783FC1F.7070309@sun.com> <2831fecf0801081454m71bb3ff3x3b2da3eb60d4aa37@mail.gmail.com> Message-ID: <47864270.8060305@sun.com> So with the -gt change is this patch ok to go? I will have some more time (maybe) next week to track down further the id.lds problem. /********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 *********************/ Myles Watson wrote: > On Jan 8, 2008 3:41 PM, Marc Karasek wrote: > >> So what is the general consensus ==1 or >0? >> > > I like the idea of using grep. It seems much cleaner, and avoids that issue. > > The other sticking point for the patch the changes in > src/arch/i386/lib/id.lds (See Ed's last message.) > > Myles > > >> Also, I think I know how to commit back to the tree, but do I need a >> user account for this? >> >> /********************* >> Marc Karasek >> MTS >> Sun Microsystems >> mailto:marc.karasek at sun.com >> ph:770.360.6415 >> *********************/ >> >> >> >> >> Myles Watson wrote: >> >>> On Jan 7, 2008 8:15 AM, Marc Karasek wrote: >>> >>> >>>> After looking at the script Myles sent, I immediately saw the problem. >>>> I forgot that if [ $build_id ] will always be true because it checks to >>>> see if it is defined not the value of build_id. My bad, sorry. >>>> >>>> I have made the changes and added an == 1 to the if statement. Attached >>>> is the new and I hope final patch file for this. >>>> >>>> >>>> >>> It works for me (it doesn't add the load option.) >>> >>> Sorry to be picky, but it seems like this breaks if they mention >>> build-id more than once in the help in the future. I think >0 would >>> be better than ==1. >>> >>> With that fixed, or if no one thinks that will ever happen: >>> Acked-by: Myles Watson >>> >>> >>>> /********************* >>>> Marc Karasek >>>> MTS >>>> Sun Microsystems >>>> mailto:marc.karasek at sun.com >>>> ph:770.360.6415 >>>> *********************/ >>>> >>>> >>>> >>>> Ed Swierk wrote: >>>> >>>> >>>> >>>>> On 1/4/08, Marc Karasek wrote: >>>>> >>>>> >>>>> >>>>>> I made a test script and ran it and it sets build_id = 1 properly. I >>>>>> have also included this script. >>>>>> >>>>>> >>>>>> >>>>> The problem is that on Planet Bourne, zero means true and nonzero means false. >>>>> >>>>> --Ed >>>>> >>>>> >>>>> From eswierk at arastra.com Thu Jan 10 17:15:10 2008 From: eswierk at arastra.com (Ed Swierk) Date: Thu, 10 Jan 2008 08:15:10 -0800 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: <47864270.8060305@sun.com> References: <477CF25C.7070901@sun.com> <477E8A50.2080408@sun.com> <477EB7A1.80406@sun.com> <47824212.3030307@sun.com> <2831fecf0801070837n4c22d036t38254f5ee02d14d1@mail.gmail.com> <4783FC1F.7070309@sun.com> <2831fecf0801081454m71bb3ff3x3b2da3eb60d4aa37@mail.gmail.com> <47864270.8060305@sun.com> Message-ID: On 1/10/08, Marc Karasek wrote: > So with the -gt change is this patch ok to go? > > I will have some more time (maybe) next week to track down further the > id.lds problem. I would prefer to see id.lds left as is, with the workaround code perhaps included in a comment or #if 0, until a better-understood solution is found. --Ed From mylesgw at gmail.com Thu Jan 10 17:28:17 2008 From: mylesgw at gmail.com (Myles Watson) Date: Thu, 10 Jan 2008 09:28:17 -0700 Subject: [LinuxBIOS] Fwd: Possible stack protect solutions (RESEND) In-Reply-To: <13426df10801030930u4a8b1ef7m5db8ecd8d89b3297@mail.gmail.com> References: <13426df10801030825q634ce66fsb3ed6389158fbb71@mail.gmail.com> <20080103171258.GA22798@coresystems.de> <13426df10801030930u4a8b1ef7m5db8ecd8d89b3297@mail.gmail.com> Message-ID: <2831fecf0801100828k4428e483ped534baae93d8e19@mail.gmail.com> On Jan 3, 2008 10:30 AM, ron minnich wrote: > On Jan 3, 2008 9:12 AM, Stefan Reinauer wrote: > > * ron minnich [080103 17:25]: > > > This patch will enable setting distro variables such as > > > -fno_stack_protector as needed. It is a simple patch to buildtarget > > > and can be extended for other uses. > > > > > > If this patch is acceptable then we can fix the various makefiles to > > > include the variable. > > > > > > The only remaining question is the name -- is CPU_OPT really appropriate? > > > > Why not make it CFLAGS? The C compiler is called CC in our environment, > > too. > > > like this? > > Tested on FC8 and works fine. This patch adds -fno-stack-protector to my FLAGS too, even though I don't need them. It still builds, with or without the patch. Myles > ron > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > From myles at pel.cs.byu.edu Thu Jan 10 17:31:45 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Thu, 10 Jan 2008 09:31:45 -0700 Subject: [LinuxBIOS] Fwd: Possible stack protect solutions (RESEND) In-Reply-To: <2831fecf0801100828k4428e483ped534baae93d8e19@mail.gmail.com> References: <13426df10801030825q634ce66fsb3ed6389158fbb71@mail.gmail.com> <20080103171258.GA22798@coresystems.de> <13426df10801030930u4a8b1ef7m5db8ecd8d89b3297@mail.gmail.com> <2831fecf0801100828k4428e483ped534baae93d8e19@mail.gmail.com> Message-ID: <2831fecf0801100831wac7ed88n2fd6b8bbc8ce8059@mail.gmail.com> On Jan 3, 2008 10:30 AM, ron minnich wrote: > On Jan 3, 2008 9:12 AM, Stefan Reinauer wrote: > > * ron minnich [080103 17:25]: > > > This patch will enable setting distro variables such as > > > -fno_stack_protector as needed. It is a simple patch to buildtarget > > > and can be extended for other uses. > > > > > > If this patch is acceptable then we can fix the various makefiles to > > > include the variable. > > > > > > The only remaining question is the name -- is CPU_OPT really appropriate? > > > > Why not make it CFLAGS? The C compiler is called CC in our environment, > > too. > > > like this? > > Tested on FC8 and works fine. This patch adds -fno-stack-protector to my FLAGS too, even though I don't need them. It still builds, with or without the patch. Myles > ron > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > From jordan.crouse at amd.com Thu Jan 10 17:31:11 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Thu, 10 Jan 2008 09:31:11 -0700 Subject: [LinuxBIOS] v2: rewrite AMD K* CAR code In-Reply-To: <4785825B.80000@gmx.net> References: <4783B99E.1030208@gmx.net> <4783BD38.3050309@amd.com> <13426df10801081030v241bd8e0rc50788b1bd2555a9@mail.gmail.com> <4783D01C.4010404@gmx.net> <13426df10801081400m1905129bxaee8fbef30d7d5a3@mail.gmail.com> <47855777.1040801@gmx.net> <47856AA8.1030003@amd.com> <47857C2D.90306@gmx.net> <4785825B.80000@gmx.net> Message-ID: <20080110163111.GH19170@cosmic.amd.com> On 10/01/08 03:26 +0100, Carl-Daniel Hailfinger wrote: > On 10.01.2008 03:00, Carl-Daniel Hailfinger wrote: > > On 10.01.2008 01:45, Marc Jones wrote: > > > >> Carl-Daniel Hailfinger wrote: > >> > >>> On 08.01.2008 23:00, ron minnich wrote: > >>> > >>>> Actually, if you all want to commit this, I can try it on the sis > >>>> board this week. > >>>> > >>> Well, i'd like to commit, but I'll wait until you (or someone else) have > >>> tested it. > >>> > >> We checked this on K8 with DCACHE_RAM_SIZE=0x08000 and it works as > >> expected. > >> > > > > Thanks, great! > > > > There's one issue with specific binutils versions, though. The following > > sequence trips up a specific gas version with an error message: "Error: > > too many positional arguments" > > > > I'd like to blacklist the specific binutils version causing this and > > report the bug to the linux distributor. > > Jordan, could you give us more details (exact binutils version, name of > > distribution, are all updates applied)? > > > > Or try this patch on top of my current patch: That did the trick. Thank you. I do want to explain myself a little bit more. I have a dedicated SimNow box that we built out some time ago - it works well because it has lots of processors and lots of memory, and nobody else uses it, so its perfect as a SimNow solution (SimNow uses a lot of resources, as you might imagine). This box is running a ancient version of Gentoo (sometime in 2005, if I am not mistaken). It lives in the server room, and I haven't had the need nor wherewithall to ask permission to go in there and install something more modern on it. It just works, and thats good enough for me. So it was to my surprise and delight when I discovered last year that both buildrom and the k8 LinuxBIOS code would compile on the box with no problems - thats one less 'scp' I need to try out images. Thats why I raised the alarm on this patch - its not so much that it *has* to work on an ancient binutils version, its more that it worked _before_ the patch, so unless Carl-Daniel intended to break support for ancient binutils, it should work _after_. I would have been fine with giving the old server the boot, but I thought if we could figure out a reasonable workaround, it wouldn't hurt the project. So my appreciation goes to Carl-Daniel for humoring me. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From rminnich at gmail.com Thu Jan 10 17:33:43 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 10 Jan 2008 08:33:43 -0800 Subject: [LinuxBIOS] v3 status In-Reply-To: <4782AB8E.1000706@amd.com> References: <13426df10801041736rdae8c21ubd3e1cc947a068d3@mail.gmail.com> <4782AB8E.1000706@amd.com> Message-ID: <13426df10801100833w6188faa8j36469563d38fedcf@mail.gmail.com> On Jan 7, 2008 2:45 PM, Marc Jones wrote: > As for 1MB and above, it sounds like GLIUInit() isn't running correctly. > Can you dump RCONF and GLIU MSRs? Something like v2 print_conf() in the > norwich\mainboard.c. I'm bringing that code forward but some MSRs got renamed, so give me a bit. I will get you a dump tonight. Off to my day job :-) ron From svn at openbios.org Thu Jan 10 18:48:26 2008 From: svn at openbios.org (svn at openbios.org) Date: Thu, 10 Jan 2008 18:48:26 +0100 Subject: [LinuxBIOS] r3043 - trunk/LinuxBIOSv2/src/cpu/amd/car Message-ID: Author: hailfinger Date: 2008-01-10 18:48:25 +0100 (Thu, 10 Jan 2008) New Revision: 3043 Modified: trunk/LinuxBIOSv2/src/cpu/amd/car/cache_as_ram.inc Log: This patch introduces 4k CAR size granularity for the AMD x86 CAR code. For the old supported CAR sizes, the newly generated code is equivalent, so it should be a no-brainer. Benefits: * a nice code size reduction * less #ifdef clutter for Family 10h * paranoid checks for CAR size * clear abstractions This has been tested by Marc Jones and Jordan Crouse. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Marc Jones Modified: trunk/LinuxBIOSv2/src/cpu/amd/car/cache_as_ram.inc =================================================================== --- trunk/LinuxBIOSv2/src/cpu/amd/car/cache_as_ram.inc 2008-01-10 13:27:22 UTC (rev 3042) +++ trunk/LinuxBIOSv2/src/cpu/amd/car/cache_as_ram.inc 2008-01-10 17:48:25 UTC (rev 3043) @@ -2,6 +2,7 @@ * This file is part of the LinuxBIOS project. * * Copyright (C) 2005-2007 Advanced Micro Devices, Inc. + * Copyright (C) 2008 Carl-Daniel Hailfinger * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -120,82 +121,70 @@ jmp clear_fixed_var_mtrr clear_fixed_var_mtrr_out: -#if CacheSize == 0x10000 - /* enable caching for 64K using fixed mtrr */ - movl $0x268, %ecx /* fix4k_c0000*/ - #if CAR_FAM10 == 1 - movl $0x1e1e1e1e, %edx /* WB MEM type */ - #else - movl $0x06060606, %edx /* WB IO type */ - #endif - - movl %edx, %eax - wrmsr - movl $0x269, %ecx - wrmsr +/* 0x06 is the WB IO type for a given 4k segment. + * 0x1e is the MEM IO type for a given 4k segment (K10 and above). + * segs is the number of 4k segments in the area of the particular + * register we want to use for CAR. + * reg is the register where the IO type should be stored. + */ +.macro extractmask segs, reg +.if \segs <= 0 + /* The xorl here is superfluous because at the point of first execution + * of this macro, %eax and %edx are cleared. Later invocations of this + * macro will have a monotonically increasing segs parameter. + */ + xorl \reg, \reg +#if CAR_FAM10 == 1 +.elseif \segs == 1 + movl $0x1e000000, \reg /* WB MEM type */ +.elseif \segs == 2 + movl $0x1e1e0000, \reg /* WB MEM type */ +.elseif \segs == 3 + movl $0x1e1e1e00, \reg /* WB MEM type */ +.elseif \segs >= 4 + movl $0x1e1e1e1e, \reg /* WB MEM type */ +#else +.elseif \segs == 1 + movl $0x06000000, \reg /* WB IO type */ +.elseif \segs == 2 + movl $0x06060000, \reg /* WB IO type */ +.elseif \segs == 3 + movl $0x06060600, \reg /* WB IO type */ +.elseif \segs >= 4 + movl $0x06060606, \reg /* WB IO type */ #endif +.endif +.endm -#if CacheSize == 0xc000 - /* enable caching for 16K using fixed mtrr */ - movl $0x268, %ecx /* fix4k_c4000*/ - #if CAR_FAM10 == 1 - movl $0x1e1e1e1e, %edx /* WB MEM type */ - #else - movl $0x06060606, %edx /* WB IO type */ - #endif - xorl %eax, %eax - wrmsr - /* enable caching for 32K using fixed mtrr */ - movl $0x269, %ecx /* fix4k_c8000*/ - #if CAR_FAM10 == 1 - movl $0x1e1e1e1e, %edx /* WB MEM type */ - #else - movl $0x06060606, %edx /* WB IO type */ - #endif - movl %edx, %eax - wrmsr +/* size is the cache size in bytes we want to use for CAR. + * windowoffset is the 32k-aligned window into CAR size + */ +.macro simplemask carsize, windowoffset + extractmask (((\carsize - \windowoffset) / 0x1000) - 4), %eax + extractmask (((\carsize - \windowoffset) / 0x1000)), %edx +.endm + +#if CacheSize > 0x10000 +#error Invalid CAR size, must be at most 64k. #endif +#if CacheSize < 0x1000 +#error Invalid CAR size, must be at least 4k. This is a processor limitation. +#endif +#if (CacheSize & (0x1000 - 1)) +#error Invalid CAR size, is not a multiple of 4k. This is a processor limitation. +#endif - -#if CacheSize == 0x8000 - /* enable caching for 32K using fixed mtrr */ - movl $0x269, %ecx /* fix4k_c8000*/ - #if CAR_FAM10 == 1 - movl $0x1e1e1e1e, %edx /* WB MEM type */ - #else - movl $0x06060606, %edx /* WB IO type */ - #endif - movl %edx, %eax - wrmsr +#if CacheSize > 0x8000 + /* enable caching for 32K-64K using fixed mtrr */ + movl $0x268, %ecx /* fix4k_c0000*/ + simplemask CacheSize, 0x8000 + wrmsr #endif -#if CacheSize < 0x8000 - /* enable caching for 16K/8K/4K using fixed mtrr */ - movl $0x269, %ecx /* fix4k_cc000*/ - #if CacheSize == 0x4000 - #if CAR_FAM10 == 1 - movl $0x1e1e1e1e, %edx /* WB MEM type */ - #else - movl $0x06060606, %edx /* WB IO type */ - #endif - #endif - #if CacheSize == 0x2000 - #if CAR_FAM10 == 1 - movl $0x1e1e0000, %edx /* WB MEM type */ - #else - movl $0x06060000, %edx /* WB IO type */ - #endif - #endif - #if CacheSize == 0x1000 - #if CAR_FAM10 == 1 - movl $0x1e000000, %edx /* WB MEM type */ - #else - movl $0x06000000, %edx /* WB IO type */ - #endif - #endif - xorl %eax, %eax + /* enable caching for 0-32K using fixed mtrr */ + movl $0x269, %ecx /* fix4k_c8000*/ + simplemask CacheSize, 0 wrmsr -#endif /* enable memory access for first MBs using top_mem */ movl $TOP_MEM, %ecx From c-d.hailfinger.devel.2006 at gmx.net Thu Jan 10 18:54:51 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 10 Jan 2008 18:54:51 +0100 Subject: [LinuxBIOS] [PATCH] v2: rewrite AMD K* CAR code In-Reply-To: <4783D01C.4010404@gmx.net> References: <4783B99E.1030208@gmx.net> <4783BD38.3050309@amd.com> <13426df10801081030v241bd8e0rc50788b1bd2555a9@mail.gmail.com> <4783D01C.4010404@gmx.net> Message-ID: <47865BEB.4010406@gmx.net> On 08.01.2008 20:33, Carl-Daniel Hailfinger wrote: > This patch is an attempt at introducing 4k CAR size granularity for the > AMD x86 CAR code. For the old supported CAR sizes, the newly > generated code is equivalent, so it should be a no-brainer. > > Benefits: > * a nice code size reduction > * less #ifdef clutter for Family 10h > * paranoid checks for CAR size > * clear abstractions > > Not tested, as I lack hardware working with v2. > > Signed-off-by: Carl-Daniel Hailfinger > Acked-by: Marc Jones > Thanks to Marc and Jordan for testing. r3043. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Thu Jan 10 18:57:56 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 10 Jan 2008 18:57:56 +0100 Subject: [LinuxBIOS] [PATCH] v2: rewrite AMD K* CAR code In-Reply-To: <4785825B.80000@gmx.net> References: <4783B99E.1030208@gmx.net> <4783BD38.3050309@amd.com> <13426df10801081030v241bd8e0rc50788b1bd2555a9@mail.gmail.com> <4783D01C.4010404@gmx.net> <13426df10801081400m1905129bxaee8fbef30d7d5a3@mail.gmail.com> <47855777.1040801@gmx.net> <47856AA8.1030003@amd.com> <47857C2D.90306@gmx.net> <4785825B.80000@gmx.net> Message-ID: <47865CA4.8040605@gmx.net> On 10.01.2008 03:26, Carl-Daniel Hailfinger wrote: > --- src/cpu/amd/car/cache_as_ram.inc~ 2008-01-08 20:16:30.000000000 +0100 > +++ src/cpu/amd/car/cache_as_ram.inc 2008-01-10 03:24:09.000000000 +0100 > @@ -160,8 +160,15 @@ > * windowoffset is the 32k-aligned window into CAR size > */ > .macro simplemask carsize, windowoffset > + .set gas_bug_workaround,(((\carsize - \windowoffset) / 0x1000) - 4) > + extractmask gas_bug_workaround, %eax > + .set gas_bug_workaround,(((\carsize - \windowoffset) / 0x1000)) > + extractmask gas_bug_workaround, %edx > +/* Without the gas bug workaround, the entire macro would consist only of the > + * two lines below. > extractmask (((\carsize - \windowoffset) / 0x1000) - 4), %eax > extractmask (((\carsize - \windowoffset) / 0x1000)), %edx > + */ > .endm > > #if CacheSize > 0x10000 > > > Add a workaround for a bug in some binutils version which strictly interpret whitespace as macro argument delimiter. Since the code is preprocessed by gcc and the tokenizer may insert whitespace, that can fail. http://sourceware.org/bugzilla/show_bug.cgi?id=669 Signed-off-by: Carl-Daniel Hailfinger Regards, Carl-Daniel From jordan.crouse at amd.com Thu Jan 10 19:00:12 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Thu, 10 Jan 2008 11:00:12 -0700 Subject: [LinuxBIOS] v2: rewrite AMD K* CAR code In-Reply-To: <47865CA4.8040605@gmx.net> References: <4783B99E.1030208@gmx.net> <4783BD38.3050309@amd.com> <13426df10801081030v241bd8e0rc50788b1bd2555a9@mail.gmail.com> <4783D01C.4010404@gmx.net> <13426df10801081400m1905129bxaee8fbef30d7d5a3@mail.gmail.com> <47855777.1040801@gmx.net> <47856AA8.1030003@amd.com> <47857C2D.90306@gmx.net> <4785825B.80000@gmx.net> <47865CA4.8040605@gmx.net> Message-ID: <20080110180012.GA25867@cosmic.amd.com> On 10/01/08 18:57 +0100, Carl-Daniel Hailfinger wrote: > On 10.01.2008 03:26, Carl-Daniel Hailfinger wrote: > > --- src/cpu/amd/car/cache_as_ram.inc~ 2008-01-08 20:16:30.000000000 +0100 > > +++ src/cpu/amd/car/cache_as_ram.inc 2008-01-10 03:24:09.000000000 +0100 > > @@ -160,8 +160,15 @@ > > * windowoffset is the 32k-aligned window into CAR size > > */ > > .macro simplemask carsize, windowoffset > > + .set gas_bug_workaround,(((\carsize - \windowoffset) / 0x1000) - 4) > > + extractmask gas_bug_workaround, %eax > > + .set gas_bug_workaround,(((\carsize - \windowoffset) / 0x1000)) > > + extractmask gas_bug_workaround, %edx > > +/* Without the gas bug workaround, the entire macro would consist only of the > > + * two lines below. > > extractmask (((\carsize - \windowoffset) / 0x1000) - 4), %eax > > extractmask (((\carsize - \windowoffset) / 0x1000)), %edx > > + */ > > .endm > > > > #if CacheSize > 0x10000 > > > > > > > > Add a workaround for a bug in some binutils version which strictly > interpret whitespace as macro argument delimiter. Since the code is > preprocessed by gcc and the tokenizer may insert whitespace, that can > fail. http://sourceware.org/bugzilla/show_bug.cgi?id=669 > > Signed-off-by: Carl-Daniel Hailfinger Acked-by: Jordan Crouse > > Regards, > Carl-Daniel > > -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From svn at openbios.org Thu Jan 10 18:59:25 2008 From: svn at openbios.org (svn at openbios.org) Date: Thu, 10 Jan 2008 18:59:25 +0100 Subject: [LinuxBIOS] r3044 - trunk/LinuxBIOSv2/src/cpu/amd/car Message-ID: Author: hailfinger Date: 2008-01-10 18:59:25 +0100 (Thu, 10 Jan 2008) New Revision: 3044 Modified: trunk/LinuxBIOSv2/src/cpu/amd/car/cache_as_ram.inc Log: Add a workaround for a bug in some binutils version which strictly interpret whitespace as macro argument delimiter. Since the code is preprocessed by gcc and the tokenizer may insert whitespace, that can fail. http://sourceware.org/bugzilla/show_bug.cgi?id=669 Signed-off-by: Carl-Daniel Hailfinger Acked-by: Jordan Crouse Modified: trunk/LinuxBIOSv2/src/cpu/amd/car/cache_as_ram.inc =================================================================== --- trunk/LinuxBIOSv2/src/cpu/amd/car/cache_as_ram.inc 2008-01-10 17:48:25 UTC (rev 3043) +++ trunk/LinuxBIOSv2/src/cpu/amd/car/cache_as_ram.inc 2008-01-10 17:59:25 UTC (rev 3044) @@ -160,8 +160,15 @@ * windowoffset is the 32k-aligned window into CAR size */ .macro simplemask carsize, windowoffset + .set gas_bug_workaround,(((\carsize - \windowoffset) / 0x1000) - 4) + extractmask gas_bug_workaround, %eax + .set gas_bug_workaround,(((\carsize - \windowoffset) / 0x1000)) + extractmask gas_bug_workaround, %edx +/* Without the gas bug workaround, the entire macro would consist only of the + * two lines below. extractmask (((\carsize - \windowoffset) / 0x1000) - 4), %eax extractmask (((\carsize - \windowoffset) / 0x1000)), %edx + */ .endm #if CacheSize > 0x10000 From c-d.hailfinger.devel.2006 at gmx.net Thu Jan 10 19:01:19 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 10 Jan 2008 19:01:19 +0100 Subject: [LinuxBIOS] v2: rewrite AMD K* CAR code In-Reply-To: <20080110180012.GA25867@cosmic.amd.com> References: <4783B99E.1030208@gmx.net> <4783BD38.3050309@amd.com> <13426df10801081030v241bd8e0rc50788b1bd2555a9@mail.gmail.com> <4783D01C.4010404@gmx.net> <13426df10801081400m1905129bxaee8fbef30d7d5a3@mail.gmail.com> <47855777.1040801@gmx.net> <47856AA8.1030003@amd.com> <47857C2D.90306@gmx.net> <4785825B.80000@gmx.net> <47865CA4.8040605@gmx.net> <20080110180012.GA25867@cosmic.amd.com> Message-ID: <47865D6F.2050501@gmx.net> On 10.01.2008 19:00, Jordan Crouse wrote: > On 10/01/08 18:57 +0100, Carl-Daniel Hailfinger wrote: > >> On 10.01.2008 03:26, Carl-Daniel Hailfinger wrote: >> >>> --- src/cpu/amd/car/cache_as_ram.inc~ 2008-01-08 20:16:30.000000000 +0100 >>> +++ src/cpu/amd/car/cache_as_ram.inc 2008-01-10 03:24:09.000000000 +0100 >>> @@ -160,8 +160,15 @@ >>> * windowoffset is the 32k-aligned window into CAR size >>> */ >>> .macro simplemask carsize, windowoffset >>> + .set gas_bug_workaround,(((\carsize - \windowoffset) / 0x1000) - 4) >>> + extractmask gas_bug_workaround, %eax >>> + .set gas_bug_workaround,(((\carsize - \windowoffset) / 0x1000)) >>> + extractmask gas_bug_workaround, %edx >>> +/* Without the gas bug workaround, the entire macro would consist only of the >>> + * two lines below. >>> extractmask (((\carsize - \windowoffset) / 0x1000) - 4), %eax >>> extractmask (((\carsize - \windowoffset) / 0x1000)), %edx >>> + */ >>> .endm >>> >>> #if CacheSize > 0x10000 >>> >>> >>> >>> >> Add a workaround for a bug in some binutils version which strictly >> interpret whitespace as macro argument delimiter. Since the code is >> preprocessed by gcc and the tokenizer may insert whitespace, that can >> fail. http://sourceware.org/bugzilla/show_bug.cgi?id=669 >> >> Signed-off-by: Carl-Daniel Hailfinger >> > > Acked-by: Jordan Crouse > Thanks, r3044. Regards, Carl-Daniel From rminnich at gmail.com Thu Jan 10 19:19:41 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 10 Jan 2008 10:19:41 -0800 Subject: [LinuxBIOS] LinuxBIOSv3 Config files In-Reply-To: <2831fecf0801091356h407194b0od60664726cb4da7c@mail.gmail.com> References: <2831fecf0801081530m3a3c0a99n3222c8b164f2e110@mail.gmail.com> <20080108233849.GD28312@cosmic.amd.com> <2831fecf0801091356h407194b0od60664726cb4da7c@mail.gmail.com> Message-ID: <13426df10801101019v3b98ab22iff447a6abddddca0@mail.gmail.com> On Jan 9, 2008 1:56 PM, Myles Watson wrote: > make oldconfig < newlines.txt yes y | make oldconfig ron From jordan.crouse at amd.com Thu Jan 10 19:29:05 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Thu, 10 Jan 2008 11:29:05 -0700 Subject: [LinuxBIOS] LinuxBIOSv3 Config files In-Reply-To: <13426df10801101019v3b98ab22iff447a6abddddca0@mail.gmail.com> References: <2831fecf0801081530m3a3c0a99n3222c8b164f2e110@mail.gmail.com> <20080108233849.GD28312@cosmic.amd.com> <2831fecf0801091356h407194b0od60664726cb4da7c@mail.gmail.com> <13426df10801101019v3b98ab22iff447a6abddddca0@mail.gmail.com> Message-ID: <20080110182905.GB25867@cosmic.amd.com> On 10/01/08 10:19 -0800, ron minnich wrote: > On Jan 9, 2008 1:56 PM, Myles Watson wrote: > > > make oldconfig < newlines.txt > > yes y | make oldconfig Dangerous - not all defaults are 'y'. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From info at coresystems.de Thu Jan 10 19:35:22 2008 From: info at coresystems.de (LinuxBIOS information) Date: Thu, 10 Jan 2008 19:35:22 +0100 Subject: [LinuxBIOS] r3043 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "hailfinger" checked in revision 3043 to the LinuxBIOS source repository and caused the following changes: Change Log: This patch introduces 4k CAR size granularity for the AMD x86 CAR code. For the old supported CAR sizes, the newly generated code is equivalent, so it should be a no-brainer. Benefits: * a nice code size reduction * less #ifdef clutter for Family 10h * paranoid checks for CAR size * clear abstractions This has been tested by Marc Jones and Jordan Crouse. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Marc Jones Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3043&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in hailfinger's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From rminnich at gmail.com Thu Jan 10 20:03:39 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 10 Jan 2008 11:03:39 -0800 Subject: [LinuxBIOS] LinuxBIOSv3 Config files In-Reply-To: <20080110182905.GB25867@cosmic.amd.com> References: <2831fecf0801081530m3a3c0a99n3222c8b164f2e110@mail.gmail.com> <20080108233849.GD28312@cosmic.amd.com> <2831fecf0801091356h407194b0od60664726cb4da7c@mail.gmail.com> <13426df10801101019v3b98ab22iff447a6abddddca0@mail.gmail.com> <20080110182905.GB25867@cosmic.amd.com> Message-ID: <13426df10801101103y388720a6w2b818eb0ff29f794@mail.gmail.com> On Jan 10, 2008 10:29 AM, Jordan Crouse wrote: > > On 10/01/08 10:19 -0800, ron minnich wrote: > > On Jan 9, 2008 1:56 PM, Myles Watson wrote: > > > > > make oldconfig < newlines.txt > > > > yes y | make oldconfig > > Dangerous - not all defaults are 'y'. > sure, but it's at least as safe as newlines.txt ron From myles at pel.cs.byu.edu Thu Jan 10 20:17:51 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Thu, 10 Jan 2008 12:17:51 -0700 Subject: [LinuxBIOS] LinuxBIOSv3 Config files In-Reply-To: <13426df10801101103y388720a6w2b818eb0ff29f794@mail.gmail.com> References: <2831fecf0801081530m3a3c0a99n3222c8b164f2e110@mail.gmail.com> <20080108233849.GD28312@cosmic.amd.com> <2831fecf0801091356h407194b0od60664726cb4da7c@mail.gmail.com> <13426df10801101019v3b98ab22iff447a6abddddca0@mail.gmail.com> <20080110182905.GB25867@cosmic.amd.com> <13426df10801101103y388720a6w2b818eb0ff29f794@mail.gmail.com> Message-ID: <007101c853bd$7ec28220$2023040a@chimp> > -----Original Message----- > From: ron minnich [mailto:rminnich at gmail.com] > Sent: Thursday, January 10, 2008 12:04 PM > To: Jordan Crouse > Cc: Myles Watson; Linuxbios > Subject: Re: LinuxBIOSv3 Config files > > On Jan 10, 2008 10:29 AM, Jordan Crouse wrote: > > > > On 10/01/08 10:19 -0800, ron minnich wrote: > > > On Jan 9, 2008 1:56 PM, Myles Watson wrote: > > > > > > > make oldconfig < newlines.txt > > > > > > yes y | make oldconfig > > > > Dangerous - not all defaults are 'y'. > > > > sure, but it's at least as safe as newlines.txt > > ron The reason I used new lines was that it selected the defaults. For example, for numerical choices 'y' is not a good choice and sends it into an infinite loop. I'll grant that new lines are only as safe as the default values. Myles From jordan.crouse at amd.com Thu Jan 10 20:18:14 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Thu, 10 Jan 2008 12:18:14 -0700 Subject: [LinuxBIOS] LinuxBIOSv3 Config files In-Reply-To: <13426df10801101103y388720a6w2b818eb0ff29f794@mail.gmail.com> References: <2831fecf0801081530m3a3c0a99n3222c8b164f2e110@mail.gmail.com> <20080108233849.GD28312@cosmic.amd.com> <2831fecf0801091356h407194b0od60664726cb4da7c@mail.gmail.com> <13426df10801101019v3b98ab22iff447a6abddddca0@mail.gmail.com> <20080110182905.GB25867@cosmic.amd.com> <13426df10801101103y388720a6w2b818eb0ff29f794@mail.gmail.com> Message-ID: <20080110191814.GE25867@cosmic.amd.com> On 10/01/08 11:03 -0800, ron minnich wrote: > On Jan 10, 2008 10:29 AM, Jordan Crouse wrote: > > > > On 10/01/08 10:19 -0800, ron minnich wrote: > > > On Jan 9, 2008 1:56 PM, Myles Watson wrote: > > > > > > > make oldconfig < newlines.txt > > > > > > yes y | make oldconfig > > > > Dangerous - not all defaults are 'y'. > > > > sure, but it's at least as safe as newlines.txt His goal was to get the defaults - newlines.txt will do that. Your option may turn very undesirable options - saying 'y' to "experimental" is not always the best way. I am on record as forcing the buildrom developer to generate and maintain a complete configuration file - I think it supports more reproducible builds and eliminates doubt and confusion. That I said, I understand what Myles is trying to do, and it really should be a feature that kconfig offers. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From info at coresystems.de Thu Jan 10 20:25:51 2008 From: info at coresystems.de (LinuxBIOS information) Date: Thu, 10 Jan 2008 20:25:51 +0100 Subject: [LinuxBIOS] r3044 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "hailfinger" checked in revision 3044 to the LinuxBIOS source repository and caused the following changes: Change Log: Add a workaround for a bug in some binutils version which strictly interpret whitespace as macro argument delimiter. Since the code is preprocessed by gcc and the tokenizer may insert whitespace, that can fail. http://sourceware.org/bugzilla/show_bug.cgi?id=669 Signed-off-by: Carl-Daniel Hailfinger Acked-by: Jordan Crouse Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3044&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in hailfinger's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From myles at pel.cs.byu.edu Thu Jan 10 20:28:51 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Thu, 10 Jan 2008 12:28:51 -0700 Subject: [LinuxBIOS] LinuxBIOSv3 Config files In-Reply-To: <20080110191814.GE25867@cosmic.amd.com> References: <2831fecf0801081530m3a3c0a99n3222c8b164f2e110@mail.gmail.com> <20080108233849.GD28312@cosmic.amd.com> <2831fecf0801091356h407194b0od60664726cb4da7c@mail.gmail.com> <13426df10801101019v3b98ab22iff447a6abddddca0@mail.gmail.com> <20080110182905.GB25867@cosmic.amd.com> <13426df10801101103y388720a6w2b818eb0ff29f794@mail.gmail.com> <20080110191814.GE25867@cosmic.amd.com> Message-ID: <007201c853bf$07bffa20$2023040a@chimp> > -----Original Message----- > From: Jordan Crouse [mailto:jordan.crouse at amd.com] > Sent: Thursday, January 10, 2008 12:18 PM > To: ron minnich > Cc: Myles Watson; Linuxbios > Subject: Re: LinuxBIOSv3 Config files > > On 10/01/08 11:03 -0800, ron minnich wrote: > > On Jan 10, 2008 10:29 AM, Jordan Crouse wrote: > > > > > > On 10/01/08 10:19 -0800, ron minnich wrote: > > > > On Jan 9, 2008 1:56 PM, Myles Watson wrote: > > > > > > > > > make oldconfig < newlines.txt > > > > > > > > yes y | make oldconfig > > > > > > Dangerous - not all defaults are 'y'. > > > > > > > sure, but it's at least as safe as newlines.txt > > His goal was to get the defaults - newlines.txt will do that. Your option > may turn very undesirable options - saying 'y' to "experimental" is not > always the best way. > > I am on record as forcing the buildrom developer to generate and maintain > a complete configuration file - I think it supports more reproducible > builds > and eliminates doubt and confusion. That I said, I understand what Myles > is trying to do, and it really should be a feature that kconfig offers. > This brings us back to the reason we started this conversation. I think it's too bad to force the ROM_size argument from a config file. Having a different config file for each architecture * rom_size * console_option * boot_Device means that no one will implement/maintain them. I think it would be nice to allow people (maybe only with "Advanced Options" selected) to configure v3 (at least specify the ROM size and the architecture) from buildrom. I think the easier we make it to try out different things, the more people will try things and help us improve. We can also do checks to see if payloads will fit from buildrom if we have some idea about the ROM size. Myles > Jordan > > -- > Jordan Crouse > Systems Software Development Engineer > Advanced Micro Devices, Inc. From rminnich at gmail.com Thu Jan 10 20:49:24 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 10 Jan 2008 11:49:24 -0800 Subject: [LinuxBIOS] LinuxBIOSv3 Config files In-Reply-To: <20080110191814.GE25867@cosmic.amd.com> References: <2831fecf0801081530m3a3c0a99n3222c8b164f2e110@mail.gmail.com> <20080108233849.GD28312@cosmic.amd.com> <2831fecf0801091356h407194b0od60664726cb4da7c@mail.gmail.com> <13426df10801101019v3b98ab22iff447a6abddddca0@mail.gmail.com> <20080110182905.GB25867@cosmic.amd.com> <13426df10801101103y388720a6w2b818eb0ff29f794@mail.gmail.com> <20080110191814.GE25867@cosmic.amd.com> Message-ID: <13426df10801101149s4e607786i46a86c0b5717f04a@mail.gmail.com> On Jan 10, 2008 11:18 AM, Jordan Crouse wrote: > His goal was to get the defaults - newlines.txt will do that. Your option > may turn very undesirable options - saying 'y' to "experimental" is not > always the best way. gotcha. I was doing this tongue in cheek anyway :-) ron From rminnich at gmail.com Thu Jan 10 20:50:42 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 10 Jan 2008 11:50:42 -0800 Subject: [LinuxBIOS] LinuxBIOSv3 Config files In-Reply-To: <007201c853bf$07bffa20$2023040a@chimp> References: <2831fecf0801081530m3a3c0a99n3222c8b164f2e110@mail.gmail.com> <20080108233849.GD28312@cosmic.amd.com> <2831fecf0801091356h407194b0od60664726cb4da7c@mail.gmail.com> <13426df10801101019v3b98ab22iff447a6abddddca0@mail.gmail.com> <20080110182905.GB25867@cosmic.amd.com> <13426df10801101103y388720a6w2b818eb0ff29f794@mail.gmail.com> <20080110191814.GE25867@cosmic.amd.com> <007201c853bf$07bffa20$2023040a@chimp> Message-ID: <13426df10801101150tb7e6463j1f8de836ce8c7ac5@mail.gmail.com> On Jan 10, 2008 11:28 AM, Myles Watson wrote: > This brings us back to the reason we started this conversation. I think > it's too bad to force the ROM_size argument from a config file. Having a > different config file for each architecture * rom_size * console_option * > boot_Device means that no one will implement/maintain them. > Some variables ought to be environment variables as far as I'm concerned ... ron From rmh at aybabtu.com Thu Jan 10 21:58:03 2008 From: rmh at aybabtu.com (Robert Millan) Date: Thu, 10 Jan 2008 21:58:03 +0100 Subject: [LinuxBIOS] [PATCH] fix build race in LBv3 Message-ID: <20080110205803.GA9396@thorin> This fixes a build race (make -j2): make: *** No rule to make target `/home/rmh/hacking/linuxbios/LinuxBIOSv3/build/stage0-prefixed.o', \ needed by `/home/rmh/hacking/linuxbios/LinuxBIOSv3/build/linuxbios.initram'. Stop. -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) -------------- next part -------------- A non-text attachment was scrubbed... Name: race.diff Type: text/x-diff Size: 645 bytes Desc: not available URL: From svn at openbios.org Thu Jan 10 22:13:19 2008 From: svn at openbios.org (svn at openbios.org) Date: Thu, 10 Jan 2008 22:13:19 +0100 Subject: [LinuxBIOS] r552 - LinuxBIOSv3/arch/x86 Message-ID: Author: hailfinger Date: 2008-01-10 22:13:19 +0100 (Thu, 10 Jan 2008) New Revision: 552 Modified: LinuxBIOSv3/arch/x86/Makefile Log: This fixes a build race (make -j2): make: *** No rule to make target `LinuxBIOSv3/build/stage0-prefixed.o', needed by `LinuxBIOSv3/build/linuxbios.initram'. Stop. Signed-off-by: Robert Millan Acked-by: Carl-Daniel Hailfinger Modified: LinuxBIOSv3/arch/x86/Makefile =================================================================== --- LinuxBIOSv3/arch/x86/Makefile 2008-01-09 23:09:23 UTC (rev 551) +++ LinuxBIOSv3/arch/x86/Makefile 2008-01-10 21:13:19 UTC (rev 552) @@ -135,7 +135,7 @@ $(patsubst %,$(obj)/arch/x86/%,$(STAGE0_CAR_OBJ)) \ $(STAGE0_MAINBOARD_OBJ) $(STAGE0_CHIPSET_OBJ) -$(obj)/stage0.o $(obj)/stage0.init: $(STAGE0_OBJ) +$(obj)/stage0.o $(obj)/stage0.init $(obj)/stage0-prefixed.o: $(STAGE0_OBJ) $(Q)# We need to be careful. If stage0.o gets bigger than $(Q)# 0x4000 - 0x100, we will end up with a 4 gig file. $(Q)# I wonder if that behavior is on purpose. From c-d.hailfinger.devel.2006 at gmx.net Thu Jan 10 22:15:00 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 10 Jan 2008 22:15:00 +0100 Subject: [LinuxBIOS] [PATCH] fix build race in LBv3 In-Reply-To: <20080110205803.GA9396@thorin> References: <20080110205803.GA9396@thorin> Message-ID: <47868AD4.2040407@gmx.net> On 10.01.2008 21:58, Robert Millan wrote: > This fixes a build race (make -j2): > > make: *** No rule to make target `/home/rmh/hacking/linuxbios/LinuxBIOSv3/build/stage0-prefixed.o', \ > needed by `/home/rmh/hacking/linuxbios/LinuxBIOSv3/build/linuxbios.initram'. Stop. > > Thanks! > Signed-off-by: Robert Millan > Acked-by: Carl-Daniel Hailfinger Committed in r552. Regards, Carl-Daniel From martin at marcher.name Thu Jan 10 21:59:14 2008 From: martin at marcher.name (Martin Marcher) Date: Thu, 10 Jan 2008 21:59:14 +0100 Subject: [LinuxBIOS] 2 Terabyte Limit of BIOS/MBR Message-ID: Hello, hope to be in the right place to ask this, if not just point me to where you think it's apropriate my Hardware is: Tyan Transport GT20 (B2865) http://www.tyan.com/support_download_manuals.aspx?model=B.GT20B2865 an Areca 1210 raid controller is attached to it and I just was hit by the 2TB limit which a BIOS can handle. Is that right that the problem is the BIOS? how I understand the different articles at wikipedia, ms and different netsources the BIOS just can't handle disks that are larger than 2TB, in turn this renders a MBR unusable. Fine so I convert the disk to a GPT and off I should go. But I found that the bios of this board still refuses to accept the disk (reported as an scsi device from the controller) and just says "No BIOS disk found". OK, now the actual question(s): 1) Is this problem (if I understood it right) still there with linuxbios? 2) If so what plans are there to still be able to use a >2TB disk? (Note: Just plugging a smaller disk to boot from isn't exactly what I consider a solution, however you are the experts :) 3) Last, not least I couldn't the Tyan GT20 in the supported hardware list, is that true or just missing. If it's missing I'll bug Tyan about this once a month or so, in case you don't have the specs available to send it to you (if you want me to do that). thanks martin apologies if that is totally OT but I think I'm right here :) -- http://noneisyours.marcher.name http://feeds.feedburner.com/NoneIsYours You are not free to read this message, by doing so, you have violated my licence and are required to urinate publicly. Thank you. From c-d.hailfinger.devel.2006 at gmx.net Thu Jan 10 22:55:07 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 10 Jan 2008 22:55:07 +0100 Subject: [LinuxBIOS] 2 Terabyte Limit of BIOS/MBR In-Reply-To: References: Message-ID: <4786943B.7050600@gmx.net> On 10.01.2008 21:59, Martin Marcher wrote: > Hello, > > hope to be in the right place to ask this, if not just point me to where you > think it's apropriate > > my Hardware is: > > Tyan Transport GT20 (B2865) > http://www.tyan.com/support_download_manuals.aspx?model=B.GT20B2865 > > an Areca 1210 raid controller is attached to it and I just was hit by the > 2TB limit which a BIOS can handle. > Is the RAID array exactly 2 TB? Then the BIOS will see its size as 0. > Is that right that the problem is the BIOS? > Yes. > how I understand the different articles at wikipedia, ms and different > netsources the BIOS just can't handle disks that are larger than 2TB, in > turn this renders a MBR unusable. Fine so I convert the disk to a GPT and > off I should go. But I found that the bios of this board still refuses to > accept the disk (reported as an scsi device from the controller) and just > says "No BIOS disk found". > Haha. Nice bug. > OK, now the actual question(s): > > 1) Is this problem (if I understood it right) still there with linuxbios? > Why should we replicate such a bug? If you use Linux as bootloader inside LinuxBIOS and if the Linux kernel has support for devices >2 TB enabled (all recent kernels do), you can boot from disks up to 65535 TB (maybe even 131071 TB) if the adapter creates a virtual SATA device (the limits are what you would expect from LBA48 addressing). Depending on the device driver (you said the RAID adapter claims to be SCSI), the limit may be even higher. > 2) If so what plans are there to still be able to use a >2TB disk? > (Note: Just plugging a smaller disk to boot from isn't exactly what I > consider a solution, however you are the experts :) > Three "solutions": 1. Use LinuxBIOS and Linux as Bootloader (LAB) 2. Use the vendor BIOS and boot from a smaller disk 3. Use the vendor BIOS, but make sure the RAID is either smaller than 2 TB or a few GB bigger than 2 TB (in that case the detected size would probably be real size minus 2 TB). To be honest, this tip may or may not work, depending on how broken the BIOS is. > 3) Last, not least I couldn't the Tyan GT20 in the supported hardware list, > is that true or just missing. > True. It should be supportable, though, if we have one board to experiment with. The Tyan Tomcat K8E S2865 is the board inside according to the manual. > If it's missing I'll bug Tyan about this once a month or so, in case you > don't have the specs available to send it to you (if you want me to do > that). How much time are you willing to invest to port LinuxBIOS to the board? Regards, Carl-Daniel From bernhard.walle at gmx.de Thu Jan 10 23:18:57 2008 From: bernhard.walle at gmx.de (Bernhard Walle) Date: Thu, 10 Jan 2008 23:18:57 +0100 Subject: [LinuxBIOS] [PATCH] Flashrom: "Fix" help output Message-ID: <20080110221857.GA27622@mail1.bwalle.de> This patch removes '\n' from the help output since this looks a bit strange: ----------------------------------------------------------------------------- ... -i | --image : only flash image name from flash layout If no file is specified, then all that happens is that flash info is dumped. ----------------------------------------------------------------------------- After the patch: ----------------------------------------------------------------------------- ... -i | --image : only flash image name from flash layout If no file is specified, then all that happens is that flash info is dumped. ----------------------------------------------------------------------------- The line length is still below 80 characters. Signed-off-by: Bernhard Walle --- flashrom.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/flashrom.c +++ b/flashrom.c @@ -206,7 +206,7 @@ void usage(const char *name) " -f | --force: force write without checking image\n" " -l | --layout : read rom layout from file\n" " -i | --image : only flash image name from flash layout\n" - "\n" " If no file is specified, then all that happens\n" + "\n" " If no file is specified, then all that happens" " is that flash info is dumped.\n\n"); exit(1); } From ward at gnu.org Fri Jan 11 00:18:49 2008 From: ward at gnu.org (Ward Vandewege) Date: Thu, 10 Jan 2008 18:18:49 -0500 Subject: [LinuxBIOS] [PATCH] buildrom: add extract and busybox-config, uclibc-config targets Message-ID: <20080110231849.GA22723@localdomain> -- Ward Vandewege Free Software Foundation - Senior System Administrator -------------- next part -------------- This patch adds extract targets, as well as the first of a a bunch of config targets: busybox-config and uclibc-config. The extract targets will just extract the component(s) under work. The config targets will run a configure command for the component, and then copy the resulting config file to packages/component/conf/customconfig. That config file will then be used to build the image. Signed-off-by: Ward Vandewege Index: Makefile =================================================================== --- Makefile (revision 89) +++ Makefile (working copy) @@ -20,7 +20,7 @@ config-targets := 1 endif -ifneq ($(filter config %config,$(MAKECMDGOALS)),) +ifneq ($(filter textconfig oldconfig defconfig menuconfig,$(MAKECMDGOALS)),) config-targets := 1 dot-config := 0 endif @@ -47,11 +47,14 @@ PKG_clean=$(patsubst %, %-clean, $(PKGLIST)) PKG_distclean=$(patsubst %, %-distclean, $(PKGLIST)) +PKG_extract=$(patsubst %, %-extract, $(PKGLIST)) all: $(HOSTTOOLS-y) payload linuxbios payload: $(PAYLOAD_TARGET) +extract: $(PKG_extract) + clean: $(PKG_clean) @ rm -rf $(INITRD_DIR) $(OUTPUT_DIR) Index: packages/kernel/kernel.inc =================================================================== --- packages/kernel/kernel.inc (revision 89) +++ packages/kernel/kernel.inc (working copy) @@ -28,6 +28,7 @@ $(KERNEL_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(KERNEL_SOURCE) @ mkdir -p $(KERNEL_DIR) @ echo "Unpacking kernel..." + @ mkdir -p $(KERNEL_STAMP_DIR) @ tar -C $(KERNEL_DIR) -jxf $(SOURCE_DIR)/$(KERNEL_SOURCE) @ touch $@ @@ -83,3 +84,6 @@ generic-kernel-distclean: @ rm -rf $(KERNEL_DIR) + +kernel-extract: $(KERNEL_STAMP_DIR)/.patched + Index: packages/unifdef/unifdef.mk =================================================================== --- packages/unifdef/unifdef.mk (revision 89) +++ packages/unifdef/unifdef.mk (working copy) @@ -18,6 +18,7 @@ @ wget -P $(SOURCE_DIR) $(UNIFDEF_URL)/$(UNIFDEF_SOURCE) $(UNIFDEF_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(UNIFDEF_SOURCE) + @ mkdir -p $(UNIFDEF_STAMP_DIR) @ tar -C $(UNIFDEF_DIR) -zxf $(SOURCE_DIR)/$(UNIFDEF_SOURCE) @ rm -f $(UNIFDEF_SRC_DIR)/unifdef @ rm -f $(UNIFDEF_SRC_DIR)/unifdef.o @@ -48,4 +49,8 @@ echo "Source: $(UNIFDEF_URL)/$(UNIFDEF_SOURCE)" echo "" +unifdef-extract: $(UNIFDEF_STAMP_DIR)/.unpacked + .PHONY: unifdef + + Index: packages/busybox/busybox.mk =================================================================== --- packages/busybox/busybox.mk (revision 89) +++ packages/busybox/busybox.mk (working copy) @@ -17,11 +17,20 @@ BUSYBOX_CONFIG ?= defconfig +ifeq ($(BUSYBOX_CONFIG),defconfig) +ifeq ($(shell if [ -f $(PACKAGE_DIR)/busybox/conf/customconfig ]; then echo 1; fi),1) + BUSYBOX_CONFIG = customconfig +endif +endif + $(SOURCE_DIR)/$(BUSYBOX_SOURCE): + @ echo "Downloading busybox..." @ mkdir -p $(SOURCE_DIR) @ wget -P $(SOURCE_DIR) $(BUSYBOX_URL)/$(BUSYBOX_SOURCE) $(BUSYBOX_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(BUSYBOX_SOURCE) + @ mkdir -p $(BUSYBOX_DIR) + @ mkdir -p $(BUSYBOX_STAMP_DIR) @ echo "Unpacking busybox..." @ tar -C $(BUSYBOX_DIR) -jxf $(SOURCE_DIR)/$(BUSYBOX_SOURCE) @ touch $@ @@ -32,7 +41,7 @@ @ touch $@ $(BUSYBOX_SRC_DIR)/.config: $(BUSYBOX_STAMP_DIR)/.patched - @ cp $(PACKAGE_DIR)/busybox/conf/$(BUSYBOX_CONFIG) $@ + @ cp -f $(PACKAGE_DIR)/busybox/conf/$(BUSYBOX_CONFIG) $@ $(BUSYBOX_SRC_DIR)/busybox: $(BUSYBOX_SRC_DIR)/.config @ echo "Building busybox..." @@ -57,8 +66,17 @@ busybox-distclean: @ rm -rf $(BUSYBOX_DIR)/* + @ rm -f $(PACKAGE_DIR)/busybox/conf/customconfig busybox-bom: @ echo "Package: busybox" @ echo "Source: $(BUSYBOX_URL)/$(BUSYBOX_SOURCE)" @ echo "" + +busybox-extract: $(BUSYBOX_STAMP_DIR)/.patched + +busybox-config: $(BUSYBOX_STAMP_DIR)/.patched + @ echo "Configure busybox..." + @ $(MAKE) -C $(BUSYBOX_SRC_DIR) menuconfig + @ cp -f $(BUSYBOX_SRC_DIR)/.config $(PACKAGE_DIR)/busybox/conf/customconfig + Index: packages/mkelfimage/mkelfimage.mk =================================================================== --- packages/mkelfimage/mkelfimage.mk (revision 89) +++ packages/mkelfimage/mkelfimage.mk (working copy) @@ -21,6 +21,7 @@ $(MKELFIMAGE_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(MKELFIMAGE_SOURCE) @ echo "Unpacking mkelfimage..." + @ mkdir -p $(MKELFIMAGE_STAMP_DIR) @ tar -C $(MKELFIMAGE_DIR) -zxf $(SOURCE_DIR)/$(MKELFIMAGE_SOURCE) @ touch $@ @@ -60,3 +61,6 @@ echo "Package: mkelfimage" echo "Source: $(MKELFIMAGE_URL)/$(MKELFIMAGE_SOURCE)" echo "" + +mkelfimage-extract: $(MKELFIMAGE_STAMP_DIR)/.patched + Index: packages/uclibc/uclibc.mk =================================================================== --- packages/uclibc/uclibc.mk (revision 89) +++ packages/uclibc/uclibc.mk (working copy) @@ -7,8 +7,15 @@ UCLIBC_VER ?= 0.9.28 UCLIBC_ARCH ?= i386 UCLIBC_CONFIG ?= defconfig + +ifeq ($(UCLIBC_CONFIG),defconfig) +ifeq ($(shell if [ -f $(PACKAGE_DIR)/ucblic/conf/customconfig ]; then echo 1; fi),1) + UCLIBC_CONFIG = customconfig endif +endif +endif + UCLIBC_URL=http://www.uclibc.org/downloads UCLIBC_SOURCE=uClibc-$(UCLIBC_VER).tar.bz2 UCLIBC_DIR=$(BUILD_DIR)/uclibc @@ -25,10 +32,13 @@ endif $(SOURCE_DIR)/$(UCLIBC_SOURCE): + @ echo "Downloading uclibc..." @ mkdir -p $(SOURCE_DIR) @ wget -P $(SOURCE_DIR) $(UCLIBC_URL)/$(UCLIBC_SOURCE) $(UCLIBC_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(UCLIBC_SOURCE) + @ mkdir -p $(UCLIBC_DIR) + @ mkdir -p $(UCLIBC_STAMP_DIR) @ echo "Unpacking uclibc..." @ tar -C $(UCLIBC_DIR) -jxf $(SOURCE_DIR)/$(UCLIBC_SOURCE) @ touch $@ @@ -77,3 +87,11 @@ @ echo "Package: uclibc" @ echo "Source: $(UCLIBC_URL)/$(UCLIBC_SOURCE)" @ echo "" + +uclibc-extract: $(UCLIBC_STAMP_DIR)/.unpacked + +uclibc-config: $(UCLIBC_STAMP_DIR)/.unpacked + @ echo "Configure uclibc..." + @ $(MAKE) -C $(UCLIBC_SRC_DIR) menuconfig + @ cp -f $(UCLIBC_SRC_DIR)/.config $(PACKAGE_DIR)/uclibc/conf/customconfig + Index: packages/lzma/lzma.mk =================================================================== --- packages/lzma/lzma.mk (revision 89) +++ packages/lzma/lzma.mk (working copy) @@ -19,6 +19,7 @@ $(LZMA_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(LZMA_SOURCE) @ mkdir -p $(LZMA_SRC_DIR) + @ mkdir -p $(LZMA_STAMP_DIR) @ tar -C $(LZMA_SRC_DIR) -jxf $(SOURCE_DIR)/$(LZMA_SOURCE) @ touch $@ @@ -44,3 +45,6 @@ lzma-distclean: @ rm -rf $(LZMA_DIR)/* + +lzma-extract: $(LZMA_STAMP_DIR)/.unpacked + Index: packages/linuxbios/tyan-s2891-linuxbios.mk =================================================================== --- packages/linuxbios/tyan-s2891-linuxbios.mk (revision 89) +++ packages/linuxbios/tyan-s2891-linuxbios.mk (working copy) @@ -32,6 +32,7 @@ $(SOURCE_DIR)/$(LINUXBIOS_TARBALL): @ echo "Fetching the LinuxBIOS code..." @ mkdir -p $(SOURCE_DIR)/linuxbios + @ mkdir -p $(LINUXBIOS_LOG_DIR) @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \ $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ > $(LINUXBIOS_FETCH_LOG) 2>&1 Index: packages/linuxbios/tyan-s2882-linuxbios.mk =================================================================== --- packages/linuxbios/tyan-s2882-linuxbios.mk (revision 89) +++ packages/linuxbios/tyan-s2882-linuxbios.mk (working copy) @@ -32,6 +32,7 @@ $(SOURCE_DIR)/$(LINUXBIOS_TARBALL): @ echo "Fetching the LinuxBIOS code..." @ mkdir -p $(SOURCE_DIR)/linuxbios + @ mkdir -p $(LINUXBIOS_LOG_DIR) @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \ $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ > $(LINUXBIOS_FETCH_LOG) 2>&1 Index: packages/linuxbios/msm800sev-linuxbios.mk =================================================================== --- packages/linuxbios/msm800sev-linuxbios.mk (revision 89) +++ packages/linuxbios/msm800sev-linuxbios.mk (working copy) @@ -23,6 +23,7 @@ $(SOURCE_DIR)/$(LINUXBIOS_TARBALL): @ echo "Fetching the LinuxBIOS code..." @ mkdir -p $(SOURCE_DIR)/linuxbios + @ mkdir -p $(LINUXBIOS_LOG_DIR) @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \ $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ > $(LINUXBIOS_FETCH_LOG) 2>&1 Index: packages/linuxbios/ga-2761gxdk-linuxbios.mk =================================================================== --- packages/linuxbios/ga-2761gxdk-linuxbios.mk (revision 89) +++ packages/linuxbios/ga-2761gxdk-linuxbios.mk (working copy) @@ -25,6 +25,7 @@ $(SOURCE_DIR)/$(LINUXBIOS_TARBALL): @ echo "Fetching the LinuxBIOS code..." @ mkdir -p $(SOURCE_DIR)/linuxbios + @ mkdir -p $(LINUXBIOS_LOG_DIR) @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \ $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ > $(LINUXBIOS_FETCH_LOG) 2>&1 Index: packages/linuxbios/linuxbios.inc =================================================================== --- packages/linuxbios/linuxbios.inc (revision 89) +++ packages/linuxbios/linuxbios.inc (working copy) @@ -70,6 +70,7 @@ $(LINUXBIOS_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) @ echo "Unpacking LinuxBIOS..." + @ mkdir -p $(LINUXBIOS_STAMP_DIR) @ tar -C $(LINUXBIOS_DIR) -zxf $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) @ touch $@ @@ -115,3 +116,5 @@ fi @ rm -rf $(LINUXBIOS_DIR)/* + +linuxbios-extract: $(LINUXBIOS_STAMP_DIR)/.patched Index: packages/linuxbios/supermicro-h8dmr-linuxbios.mk =================================================================== --- packages/linuxbios/supermicro-h8dmr-linuxbios.mk (revision 89) +++ packages/linuxbios/supermicro-h8dmr-linuxbios.mk (working copy) @@ -36,6 +36,7 @@ $(SOURCE_DIR)/$(LINUXBIOS_TARBALL): @ echo "Fetching the LinuxBIOS code..." @ mkdir -p $(SOURCE_DIR)/linuxbios + @ mkdir -p $(LINUXBIOS_LOG_DIR) @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \ $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ > $(LINUXBIOS_FETCH_LOG) 2>&1 Index: packages/linuxbios/norwich-linuxbios.mk =================================================================== --- packages/linuxbios/norwich-linuxbios.mk (revision 89) +++ packages/linuxbios/norwich-linuxbios.mk (working copy) @@ -23,6 +23,7 @@ $(SOURCE_DIR)/$(LINUXBIOS_TARBALL): @ echo "Fetching the LinuxBIOS code..." @ mkdir -p $(SOURCE_DIR)/linuxbios + @ mkdir -p $(LINUXBIOS_LOG_DIR) @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \ $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ > $(LINUXBIOS_FETCH_LOG) 2>&1 Index: packages/linuxbios/generic-linuxbios.mk =================================================================== --- packages/linuxbios/generic-linuxbios.mk (revision 89) +++ packages/linuxbios/generic-linuxbios.mk (working copy) @@ -29,6 +29,7 @@ $(SOURCE_DIR)/$(LINUXBIOS_TARBALL): @ echo "Fetching the LinuxBIOS code..." @ mkdir -p $(SOURCE_DIR)/linuxbios + @ mkdir -p $(LINUXBIOS_LOG_DIR) @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \ $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ > $(LINUXBIOS_FETCH_LOG) 2>&1 Index: packages/linuxbios/m57sli-linuxbios.mk =================================================================== --- packages/linuxbios/m57sli-linuxbios.mk (revision 89) +++ packages/linuxbios/m57sli-linuxbios.mk (working copy) @@ -36,6 +36,7 @@ $(SOURCE_DIR)/$(LINUXBIOS_TARBALL): @ echo "Fetching the LinuxBIOS code..." @ mkdir -p $(SOURCE_DIR)/linuxbios + @ mkdir -p $(LINUXBIOS_LOG_DIR) @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \ $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ > $(LINUXBIOS_FETCH_LOG) 2>&1 Index: packages/linuxbios/alix1c-linuxbios.mk =================================================================== --- packages/linuxbios/alix1c-linuxbios.mk (revision 89) +++ packages/linuxbios/alix1c-linuxbios.mk (working copy) @@ -23,6 +23,7 @@ $(SOURCE_DIR)/$(LINUXBIOS_TARBALL): @ echo "Fetching the LinuxBIOS code..." @ mkdir -p $(SOURCE_DIR)/linuxbios + @ mkdir -p $(LINUXBIOS_LOG_DIR) @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \ $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ > $(LINUXBIOS_FETCH_LOG) 2>&1 Index: packages/linuxbios/serengeti_cheetah.mk =================================================================== --- packages/linuxbios/serengeti_cheetah.mk (revision 89) +++ packages/linuxbios/serengeti_cheetah.mk (working copy) @@ -45,6 +45,7 @@ $(SOURCE_DIR)/$(LINUXBIOS_TARBALL): @ echo "Fetching the LinuxBIOS code..." @ mkdir -p $(SOURCE_DIR)/linuxbios + @ mkdir -p $(LINUXBIOS_LOG_DIR) @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \ $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ > $(LINUXBIOS_FETCH_LOG) 2>&1 Index: packages/linuxbios/qemu.mk =================================================================== --- packages/linuxbios/qemu.mk (revision 89) +++ packages/linuxbios/qemu.mk (working copy) @@ -34,6 +34,7 @@ $(SOURCE_DIR)/$(LINUXBIOS_TARBALL): @ echo "Fetching the LinuxBIOS code..." @ mkdir -p $(SOURCE_DIR)/linuxbios + @ mkdir -p $(LINUXBIOS_LOG_DIR) @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(LINUXBIOS_SVN_DIR) \ $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ > $(LINUXBIOS_FETCH_LOG) 2>&1 From myles at pel.cs.byu.edu Fri Jan 11 00:39:57 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Thu, 10 Jan 2008 16:39:57 -0700 Subject: [LinuxBIOS] [PATCH] buildrom: add extract and busybox-config, uclibc-config targets In-Reply-To: <20080110231849.GA22723@localdomain> References: <20080110231849.GA22723@localdomain> Message-ID: <008d01c853e2$1c332f90$2023040a@chimp> > -----Original Message----- > From: linuxbios-bounces at linuxbios.org [mailto:linuxbios- > bounces at linuxbios.org] On Behalf Of Ward Vandewege > Sent: Thursday, January 10, 2008 4:19 PM > To: linuxbios at linuxbios.org > Subject: [LinuxBIOS] [PATCH] buildrom: add extract and busybox- > config,uclibc-config targets > > Sorry to be so dense, but it looks like you added mkdir -p in a lot of places for directories, even though there are already makefile rules for them. The config stuff looks fine, though. Myles > > -- > Ward Vandewege > Free Software Foundation - Senior System Administrator From yinghailu at gmail.com Fri Jan 11 00:42:40 2008 From: yinghailu at gmail.com (yhlu) Date: Thu, 10 Jan 2008 15:42:40 -0800 Subject: [LinuxBIOS] m57sli : debugging the flashrom problem when booting with LB In-Reply-To: <478612C1.7090504@gmx.net> References: <47668D76.6060602@gmx.net> <4766DD09.1070400@gmx.net> <1199963686.4785fe264a52d@imp.free.fr> <478612C1.7090504@gmx.net> Message-ID: <2ea3fae10801101542pe17862fsb82bdffa9a41853@mail.gmail.com> On Jan 10, 2008 4:42 AM, Carl-Daniel Hailfinger wrote: > On 10.01.2008 12:14, Florentin Demetrescu wrote: > > Hi all, > > For my part I continue to think that there is a problem with the IO address > > decoding into the PCI->LPC bridge in mcp55.. Yinghai, can you help please? > > > > Yinghai? Is there some mcp55 conf we need to change? that range is already decoded to LPC bridge ( enable_rom, or cache_as_rom_auto, or mcp55_lpc.c) YH From rminnich at gmail.com Fri Jan 11 00:52:49 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 10 Jan 2008 15:52:49 -0800 Subject: [LinuxBIOS] AMD SimNOW question In-Reply-To: <4783FB7F.4000205@sun.com> References: <4783CA87.4070600@sun.com> <2831fecf0801081223u25f7a96cheae2779637cf4189@mail.gmail.com> <4783F2BB.8000902@sun.com> <01e801c85243$52ac9e30$a023040a@chimp> <20080108222125.GC28312@cosmic.amd.com> <4783FB7F.4000205@sun.com> Message-ID: <13426df10801101552k105385eaifa1d0771839da3b5@mail.gmail.com> On Jan 8, 2008 2:38 PM, Marc Karasek wrote: > I have found the main problem with svn. It looks like if you use svn co > http:// it will use the proxy settings under servers. If you do a svn > co svn:// it tries to do a dns lookup, which fails behind a proxy server > :-(. I have not been able to find any info on setting svn up to use a > proxy when doing svn:// type checkouts. There is a way to do it, maybe: http://subversion.tigris.org/faq.html#proxy ron From duwe at lst.de Fri Jan 11 01:21:35 2008 From: duwe at lst.de (Torsten Duwe) Date: Fri, 11 Jan 2008 01:21:35 +0100 Subject: [LinuxBIOS] 2 Terabyte Limit of BIOS/MBR In-Reply-To: References: Message-ID: <200801110121.35592.duwe@lst.de> On Thursday 10 January 2008, Martin Marcher wrote: > the BIOS just can't handle disks that are larger than 2TB, in In theory a legacy BIOS should be able to at least access the first 2TB. The limit stems from 512 bytes block size and counting blocks in 32-bit integers, which is done in a classic DOS disk label, in the MBR. > Fine so I convert the disk to a GPT and > off I should go. Does your legacy BIOS support GPT? unlikely. > OK, now the actual question(s): > > 1) Is this problem (if I understood it right) still there with linuxbios? LinuxBIOS itself isn't directly considered with disks besides initialising the controller. Look at the section "Payloads" in the wiki. Most of them are open source, BTW 8-) > 2) If so what plans are there to still be able to use a >2TB disk? Make a DOS (legacy BIOS) _partition_ of small size to boot from, at the start of the disk. Make sure it's consistent with the GPT label. If that does not help, you _need_ LinuxBIOS and a capable payload, or a guru boot setup. > 3) Last, not least I couldn't the Tyan GT20 in the supported hardware list, > is that true or just missing. Tyan is LinuxBIOS-friendly, behind the scenes, if the 2865(?) board is not supported maybe there's a way (the S2912 is supported). > If it's missing I'll bug Tyan about this once a month or so, in case you > don't have the specs available to send it to you (if you want me to do > that). Anyone here ready to do the port? > apologies if that is totally OT but I think I'm right here :) Not with questions about legacy BIOSes, but with datasheets you are ;-) Torsten From svn at openbios.org Fri Jan 11 01:32:07 2008 From: svn at openbios.org (svn at openbios.org) Date: Fri, 11 Jan 2008 01:32:07 +0100 Subject: [LinuxBIOS] r3045 - trunk/util/flashrom Message-ID: Author: duwe Date: 2008-01-11 01:32:07 +0100 (Fri, 11 Jan 2008) New Revision: 3045 Modified: trunk/util/flashrom/flashrom.c Log: This patch removes '\n' from the help output since this looks a bit strange. After the patch [...] The line length is still below 80 characters. Signed-off-by: Bernhard Walle Acked-by: Torsten Duwe Modified: trunk/util/flashrom/flashrom.c =================================================================== --- trunk/util/flashrom/flashrom.c 2008-01-10 17:59:25 UTC (rev 3044) +++ trunk/util/flashrom/flashrom.c 2008-01-11 00:32:07 UTC (rev 3045) @@ -206,7 +206,7 @@ " -f | --force: force write without checking image\n" " -l | --layout : read rom layout from file\n" " -i | --image : only flash image name from flash layout\n" - "\n" " If no file is specified, then all that happens\n" + "\n" " If no file is specified, then all that happens" " is that flash info is dumped.\n\n"); exit(1); } From duwe at lst.de Fri Jan 11 01:33:59 2008 From: duwe at lst.de (Torsten Duwe) Date: Fri, 11 Jan 2008 01:33:59 +0100 Subject: [LinuxBIOS] [PATCH] Flashrom: "Fix" help output In-Reply-To: <20080110221857.GA27622@mail1.bwalle.de> References: <20080110221857.GA27622@mail1.bwalle.de> Message-ID: <200801110133.59524.duwe@lst.de> On Thursday 10 January 2008, Bernhard Walle wrote: > This patch removes '\n' from the help output since this looks a bit > strange: [...] > After the patch: [...] > The line length is still below 80 characters. Indeed. > Signed-off-by: Bernhard Walle Acked-by: Torsten Duwe That's what we call a "trivial" patch around here ;-) revision 3045. Torsten From info at coresystems.de Fri Jan 11 02:18:04 2008 From: info at coresystems.de (LinuxBIOS information) Date: Fri, 11 Jan 2008 02:18:04 +0100 Subject: [LinuxBIOS] r3045 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "duwe" checked in revision 3045 to the LinuxBIOS source repository and caused the following changes: Change Log: This patch removes '\n' from the help output since this looks a bit strange. After the patch [...] The line length is still below 80 characters. Signed-off-by: Bernhard Walle Acked-by: Torsten Duwe Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3045&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in duwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From corey.osgood at gmail.com Fri Jan 11 02:33:19 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Thu, 10 Jan 2008 20:33:19 -0500 Subject: [LinuxBIOS] Intel refactoring and microcode updates In-Reply-To: <20080110074842.3p5v4fkoowkg408w@www.smittys.pointclark.net> References: <47843324.2050907@gmail.com> <20080109212412.cgsck1t6xxcww4s8@www.smittys.pointclark.net> <4785AC27.40102@gmail.com> <20080110074842.3p5v4fkoowkg408w@www.smittys.pointclark.net> Message-ID: <4786C75F.9080806@gmail.com> joe at smittys.pointclark.net wrote: > Quoting Corey Osgood : > >> joe at smittys.pointclark.net wrote: >>> Quoting Corey Osgood : >>> >>> >>>> I've separated this into two patches, one code and one microcode, to >>>> improve readability, but they would both have to be committed at once >>>> (else things break). These patches eliminate a lot of repeated code, >>>> make porting and adding new CPUs easier, add all the latest released >>>> microcode updates, and add somewhat experimental support for the >>>> latest >>>> lga775 cpus, along with various other currently unsupported CPUs. >>>> Unfortunately, not everything works quite right yet. Here's the >>>> broken >>>> stuff: >>>> >>>> * socket_603: includes all Xeon model f0x, f1x, and f2x cpus. This >>>> may >>>> be incorrect, but I can't see any easy way to find out. >>>> * socket_604: includes all Xeon model f2x, f3x, f4x, and f6x. Same as >>>> above, with the added bonus of being too large to fit with any current >>>> board. It should also include the socket_603 IDs, since socket 603 >>>> CPUs >>>> work on socket 604 boards. >>>> * socket_775: too large to build with most current ports, but it >>>> could >>>> probably be broken down into socket_775_pentium and >>>> socket_775_core. All >>>> fxx IDs are pentium 4/D, and 6xx IDs are Core/Core 2 >>>> >>>> For now, I've left the current model_fxx and socket_*60*, so nothing >>>> breaks, but IMO the socket_603/604 I've added should be made to work. >>>> >>>> Both patches Signed-off-by: Corey Osgood >>>> >>>> >>> Hmm looks good. Should we add a quick note to each file to what >>> processor it belongs too? I think that would save developers time from >>> having to look it up when writing code for a new board? What do you >>> think? >>> >>> >>> Thanks - Joe >>> >>> >> Do you mean the microcode files? If so, the microcode update looks like >> this: >> >> Header >> Update Revision >> Date >> Processor Signature (CPU ID) >> ... >> >> So, the 4th entry in the update is always the CPU ID, and conveniently >> it's always the last one on the first line. It also makes grepping for >> them very easy, once you have the update broken down into smaller files. >> This is documented *somewhere* in LB, but I can't find it at the moment. >> It's also in the Intel architecture manual, volume 3a, table 9-6. >> >> In the past we labeled some CPU IDs as to what CPUs they belonged to. In >> truth, Intel uses the same CPU IDs for a variety of CPUs, for instance >> in some cases Celeron, Pentium X, and Xeons all share a common ID, since >> the core is still the same. So we can't really do that any more ;) >> >> -Corey >> > Oh ok, that makes sense. > > Acked-by: Joseph Smith > > Thanks - Joe Thanks, Joe. Anyone else have anything to say? Honestly expected more feedback, but if there are no objections I'll commit it tomorrow. The other thing I forgot to mention was that all the data on CPU IDs came from the existing code and this site: http://processorfinder.intel.com. Some of them are a bit unclear on what sockets they use, but if anything comes up wrong, we can easily correct it. -Corey From peter at stuge.se Fri Jan 11 02:38:03 2008 From: peter at stuge.se (Peter Stuge) Date: Fri, 11 Jan 2008 02:38:03 +0100 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <20080110134745.GB20807@coresystems.de> <13426df10801070840u786eaf23n6b41bc0462970996@mail.gmail.com> <4781F372.7080204@gmx.net> <4780FF1B.2010308@gmx.net> <13426df10801052052q416a8532g72e8478190763bfa@mail.gmail.com> References: <4780FF1B.2010308@gmx.net> <477ED8F5.1030807@gmx.net> <47800115.1060301@coresystems.de> <13426df10801051415q69c0b3er4e6efabcdbe5c3e3@mail.gmail.com> <47800451.3080805@coresystems.de> <13426df10801051429o44b18cd4j8f21d6dd976d7f90@mail.gmail.com> <47800753.6020900@coresystems.de> <13426df10801051444y5ca97762xd67c07783a9af478@mail.gmail.com> <20080106011152.21774.qmail@stuge.se> <13426df10801052052q416a8532g72e8478190763bfa@mail.gmail.com> Message-ID: <20080111013803.3369.qmail@stuge.se> On Sat, Jan 05, 2008 at 08:52:49PM -0800, ron minnich wrote: > On Jan 5, 2008 5:11 PM, Peter Stuge wrote: > > On Sat, Jan 05, 2008 at 02:44:55PM -0800, ron minnich wrote: > > > NOT finding a file should be efficient. > > > > Yes. > > > > Where do the delay come from? Can anyone measure the LPC? > > I will try to measure for you but remember it is running uncached. > Each and every access is a full LPC cycle, which is not really fast. True. It is definately LPC access time causing this. On Sun, Jan 06, 2008 at 05:17:31PM +0100, Carl-Daniel Hailfinger wrote: > IIRC the PCEngines alix.1c has parallel flash Nope. Both the soldered-on flash and obviously the LPC port are LPC. > for all boards with LPC-to-SPI translation through a IT8716F Super > I/O chip, the following applies: > My calculations suggest that for optimal reads (4 bytes at a 4 byte > boundary) with the IT8716F SPI translation function, we need (1 byte > opcode + 3 bytes addr + 4 bytes data)* 8 = 64 clock cycles on the SPI > bus alone. With a maximum of 33 MHz for the SPI clock on that particular > chip (MUST verify that the chip is set to 33 MHz and not 16 MHz!), this > optimal read takes 2 usec. Smaller reads take at least 1.25 usec. On top > of the pure SPI bus time we have to add the time to transmit and receive > that data over LPC. Say 5 us per byte. That's rather slow for us, yes. On Mon, Jan 07, 2008 at 10:40:02AM +0100, Carl-Daniel Hailfinger wrote: > Well, we can't use CPU cache, but we can abuse CAR memory as cache I like this. > 1. Explicit "stop searching here" marker. Maybe. But I do not think this is very clean.. On Mon, Jan 07, 2008 at 08:40:31AM -0800, ron minnich wrote: > I would rather not walk all of empty space ever at any time. I think the cost of one walk is ok for the flexibility gained. > I like the end marker best. I think the runtime-created index is much more fun. It also keeps the lar format very clean. In practice, the marker is the most efficient method, but it is a bit of an abomination IMO. :p How do we handle the integrity issue when a single flash block that contains the start of a lar file is erased at runtime? (Thus breaking a link in the list.) That re-introduces the walking cost if we want to be able to find any files beyond the erased block. Maybe both run-time indexing and marker is good? But then there's no point in the marker. So only build the index when a hole is encountered. //Peter From peter at stuge.se Fri Jan 11 02:42:18 2008 From: peter at stuge.se (Peter Stuge) Date: Fri, 11 Jan 2008 02:42:18 +0100 Subject: [LinuxBIOS] Please add support for MX25L8005 and MX25L3205D In-Reply-To: <478628B0.2070501@gmx.net> References: <200801100100.30695.harald.gutmann@gmx.net> <200801101412.27106.harald.gutmann@gmx.net> <47861FCA.7070706@gmx.net> <200801101453.56400.harald.gutmann@gmx.net> <478628B0.2070501@gmx.net> Message-ID: <20080111014219.4215.qmail@stuge.se> On Thu, Jan 10, 2008 at 03:16:16PM +0100, Carl-Daniel Hailfinger wrote: > It seems we can't support any flash chip bigger than 512 kByte on a > board using IT8716F SPI translation without a LOT of effort. Please explain further? //Peter From rminnich at gmail.com Fri Jan 11 02:45:51 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 10 Jan 2008 17:45:51 -0800 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <20080111013803.3369.qmail@stuge.se> References: <477ED8F5.1030807@gmx.net> <47800753.6020900@coresystems.de> <13426df10801051444y5ca97762xd67c07783a9af478@mail.gmail.com> <20080106011152.21774.qmail@stuge.se> <20080110134745.GB20807@coresystems.de> <13426df10801070840u786eaf23n6b41bc0462970996@mail.gmail.com> <4781F372.7080204@gmx.net> <4780FF1B.2010308@gmx.net> <13426df10801052052q416a8532g72e8478190763bfa@mail.gmail.com> <20080111013803.3369.qmail@stuge.se> Message-ID: <13426df10801101745o684b0981g1fd02ff01a075007@mail.gmail.com> On Jan 10, 2008 5:38 PM, Peter Stuge wrote: > I think the runtime-created index is much more fun. > It also keeps the lar format very clean. Since I suffered the pain on a certain project for wasting milliseconds, I would rather not waste milliseconds. In this case, though, we're wasting hundreds and hundreds of milliseconds. They're lost forever and never coming back. > > In practice, the marker is the most efficient method, but it is a bit > of an abomination IMO. :p Performance hacks often are :-) ron From c-d.hailfinger.devel.2006 at gmx.net Fri Jan 11 02:48:13 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 11 Jan 2008 02:48:13 +0100 Subject: [LinuxBIOS] Intel refactoring and microcode updates In-Reply-To: <4786C75F.9080806@gmail.com> References: <47843324.2050907@gmail.com> <20080109212412.cgsck1t6xxcww4s8@www.smittys.pointclark.net> <4785AC27.40102@gmail.com> <20080110074842.3p5v4fkoowkg408w@www.smittys.pointclark.net> <4786C75F.9080806@gmail.com> Message-ID: <4786CADD.7030305@gmx.net> On 11.01.2008 02:33, Corey Osgood wrote: > joe at smittys.pointclark.net wrote: > >> Quoting Corey Osgood : >> >>> Do you mean the microcode files? If so, the microcode update looks like >>> this: >>> >>> Header >>> Update Revision >>> Date >>> Processor Signature (CPU ID) >>> ... >>> >>> So, the 4th entry in the update is always the CPU ID, and conveniently >>> it's always the last one on the first line. It also makes grepping for >>> them very easy, once you have the update broken down into smaller files. >>> This is documented *somewhere* in LB, but I can't find it at the moment. >>> It's also in the Intel architecture manual, volume 3a, table 9-6. >>> >>> In the past we labeled some CPU IDs as to what CPUs they belonged to. In >>> truth, Intel uses the same CPU IDs for a variety of CPUs, for instance >>> in some cases Celeron, Pentium X, and Xeons all share a common ID, since >>> the core is still the same. So we can't really do that any more ;) >>> >>> >> Oh ok, that makes sense. >> >> Acked-by: Joseph Smith >> > Thanks, Joe. Anyone else have anything to say? Honestly expected more > feedback, but if there are no objections I'll commit it tomorrow. > > The other thing I forgot to mention was that all the data on CPU IDs > came from the existing code and this site: > http://processorfinder.intel.com. Some of them are a bit unclear on what > sockets they use, but if anything comes up wrong, we can easily correct it. > Do you see any way to solve the "size problem" for sockets with too many different cores? It would also be interesting to find out if your work on stripping duplicate contents gives us new opportunities to reduce size even further. Regards, Carl-Daniel From joe at smittys.pointclark.net Fri Jan 11 02:53:01 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Thu, 10 Jan 2008 20:53:01 -0500 Subject: [LinuxBIOS] Intel refactoring and microcode updates In-Reply-To: <4786CADD.7030305@gmx.net> References: <47843324.2050907@gmail.com> <20080109212412.cgsck1t6xxcww4s8@www.smittys.pointclark.net> <4785AC27.40102@gmail.com> <20080110074842.3p5v4fkoowkg408w@www.smittys.pointclark.net> <4786C75F.9080806@gmail.com> <4786CADD.7030305@gmx.net> Message-ID: <20080110205301.1uursf7nc4ococg8@www.smittys.pointclark.net> Quoting Carl-Daniel Hailfinger : > > Do you see any way to solve the "size problem" for sockets with too many > different cores? > > Regards, > Carl-Daniel > Not sure what you mean? How many different cores could you put in even the most popular socket, three? Thanks - Joe From c-d.hailfinger.devel.2006 at gmx.net Fri Jan 11 03:07:11 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 11 Jan 2008 03:07:11 +0100 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <20080111013803.3369.qmail@stuge.se> References: <4780FF1B.2010308@gmx.net> <477ED8F5.1030807@gmx.net> <47800115.1060301@coresystems.de> <13426df10801051415q69c0b3er4e6efabcdbe5c3e3@mail.gmail.com> <47800451.3080805@coresystems.de> <13426df10801051429o44b18cd4j8f21d6dd976d7f90@mail.gmail.com> <47800753.6020900@coresystems.de> <13426df10801051444y5ca97762xd67c07783a9af478@mail.gmail.com> <20080106011152.21774.qmail@stuge.se> <13426df10801052052q416a8532g72e8478190763bfa@mail.gmail.com> <20080111013803.3369.qmail@stuge.se> Message-ID: <4786CF4F.8010605@gmx.net> On 11.01.2008 02:38, Peter Stuge wrote: > On Sat, Jan 05, 2008 at 08:52:49PM -0800, ron minnich wrote: > >> On Jan 5, 2008 5:11 PM, Peter Stuge wrote: >> >>> On Sat, Jan 05, 2008 at 02:44:55PM -0800, ron minnich wrote: >>> >>>> NOT finding a file should be efficient. >>>> >>> Yes. >>> >>> Where do the delay come from? Can anyone measure the LPC? >>> >> I will try to measure for you but remember it is running uncached. >> Each and every access is a full LPC cycle, which is not really fast. >> > > True. It is definately LPC access time causing this. > Yes. > On Sun, Jan 06, 2008 at 05:17:31PM +0100, Carl-Daniel Hailfinger wrote: > >> IIRC the PCEngines alix.1c has parallel flash >> > > Nope. Both the soldered-on flash and obviously the LPC port are LPC. > Even LPC alone is faster than LPC-to-slow-SPI-to-LPC. >> for all boards with LPC-to-SPI translation through a IT8716F Super >> I/O chip, the following applies: >> My calculations suggest that for optimal reads (4 bytes at a 4 byte >> boundary) with the IT8716F SPI translation function, we need (1 byte >> opcode + 3 bytes addr + 4 bytes data)* 8 = 64 clock cycles on the SPI >> bus alone. With a maximum of 33 MHz for the SPI clock on that particular >> chip (MUST verify that the chip is set to 33 MHz and not 16 MHz!), this >> optimal read takes 2 usec. Smaller reads take at least 1.25 usec. On top >> of the pure SPI bus time we have to add the time to transmit and receive >> that data over LPC. >> > > Say 5 us per byte. That's rather slow for us, yes. > Hopefully that's the worst case. Still horrible if we use 1 MByte ROMs - 5 seconds for reading the whole ROM is unacceptable. > On Mon, Jan 07, 2008 at 10:40:02AM +0100, Carl-Daniel Hailfinger wrote: > >> Well, we can't use CPU cache, but we can abuse CAR memory as cache >> > > I like this. > I'll try to code up some generic LAR caching extension over the weekend unless someone beats me to it. (Hint, hint!) >> 1. Explicit "stop searching here" marker. >> > > Maybe. But I do not think this is very clean.. > Not very clean, but extremely flash-friendly. And in contrast to a "skip n bytes" marker you can add a new LAR member in its place without erasing the marker (at least that's how my implementation performs). > On Mon, Jan 07, 2008 at 08:40:31AM -0800, ron minnich wrote: > >> I would rather not walk all of empty space ever at any time. >> > > I think the cost of one walk is ok for the flexibility gained. > We have to make sure it is never more than one full walk. Everything else is embarrassing. >> I like the end marker best. >> > > I think the runtime-created index is much more fun. > It also keeps the lar format very clean. > We can do both. It seems that at least for the runtime-created index/cache we all agree. > In practice, the marker is the most efficient method, but it is a bit > of an abomination IMO. :p > Big question: Is v3 a matter of pride or speed or userfriendliness? I haven't decided yet. ;-) > How do we handle the integrity issue when a single flash block that > contains the start of a lar file is erased at runtime? (Thus breaking > a link in the list.) > If we really do erases at LB runtime, the person waiting for the erase surely has the time to rebuild the index/cache (which will probably need a fraction of the time needed for erase). > That re-introduces the walking cost if we want to be able to find > any files beyond the erased block. > > Maybe both run-time indexing and marker is good? But then there's no > point in the marker. So only build the index when a hole is > encountered. > Avoiding LPC cycles is always a reason to build an index/cache. L2 cache is orders of magnitude faster than LPC. For n LAR members, a failed lookup will either cost you ~n*20 LPC transactions with 32 bit each or n*2 L2 cache accesses. I'd claim a factor of 1000 speed improvement. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Fri Jan 11 03:09:51 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 11 Jan 2008 03:09:51 +0100 Subject: [LinuxBIOS] Intel refactoring and microcode updates In-Reply-To: <20080110205301.1uursf7nc4ococg8@www.smittys.pointclark.net> References: <47843324.2050907@gmail.com> <20080109212412.cgsck1t6xxcww4s8@www.smittys.pointclark.net> <4785AC27.40102@gmail.com> <20080110074842.3p5v4fkoowkg408w@www.smittys.pointclark.net> <4786C75F.9080806@gmail.com> <4786CADD.7030305@gmx.net> <20080110205301.1uursf7nc4ococg8@www.smittys.pointclark.net> Message-ID: <4786CFEF.9030801@gmx.net> On 11.01.2008 02:53, joe at smittys.pointclark.net wrote: > Quoting Carl-Daniel Hailfinger : > >> >> Do you see any way to solve the "size problem" for sockets with too many >> different cores? >> > Not sure what you mean? How many different cores could you put in even > the most popular socket, three? No, I was talking about the problems to keep all microcodes available for all processor types that could be plugged into a given socket. To express it another way: "no BIOS changes needed as long as the processor fits electrically and mechanically into the socket". Depending on the socket, that might be a lot of different microcode updates you have to keep in ROM. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Fri Jan 11 03:18:04 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 11 Jan 2008 03:18:04 +0100 Subject: [LinuxBIOS] Please add support for MX25L8005 and MX25L3205D In-Reply-To: <20080111014219.4215.qmail@stuge.se> References: <200801100100.30695.harald.gutmann@gmx.net> <200801101412.27106.harald.gutmann@gmx.net> <47861FCA.7070706@gmx.net> <200801101453.56400.harald.gutmann@gmx.net> <478628B0.2070501@gmx.net> <20080111014219.4215.qmail@stuge.se> Message-ID: <4786D1DC.9050800@gmx.net> On 11.01.2008 02:42, Peter Stuge wrote: > On Thu, Jan 10, 2008 at 03:16:16PM +0100, Carl-Daniel Hailfinger wrote: > >> It seems we can't support any flash chip bigger than 512 kByte on a >> board using IT8716F SPI translation without a LOT of effort. >> > > Please explain further? > The IT8716F datasheet suggests that LPC-to-SPI translation is limited to one 512 kByte area and one disjoint 128 kByte area. It is not specified to which addresses of the flash chip the 128 kByte area is decoded. All accesses outside this area will have to be read in 2-byte chunks by issuing a read command to the SPI controller. Memory mapping such accesses seems to be impossible according to the datasheet. Writing is even worse: You can only program chips which support the byte-program instruction because sending more than 5 bytes to the SPI chip (1 opcode, 3 address, 1 data) is not possible outside the natively decoded area. Every routine accessing ROM has to be rewritten to use "retrieve these bytes" helper routines. String comparisons etc. will not work unless you hand-code them. LAR walking will be real fun. The only way to not get a headache would be to access only the given 512 kByte area before RAM is enabled, then directly after enabling RAM copy ROM contents with the read-2-bytes method to RAM and work from RAM. Suicidal complexity. I still hope ITE engineers will tell me about a way to avoid all this horrible stuff. The datasheet surely does not leave much hope. Regards, Carl-Daniel From corey.osgood at gmail.com Fri Jan 11 03:34:28 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Thu, 10 Jan 2008 21:34:28 -0500 Subject: [LinuxBIOS] Intel refactoring and microcode updates In-Reply-To: <4786CADD.7030305@gmx.net> References: <47843324.2050907@gmail.com> <20080109212412.cgsck1t6xxcww4s8@www.smittys.pointclark.net> <4785AC27.40102@gmail.com> <20080110074842.3p5v4fkoowkg408w@www.smittys.pointclark.net> <4786C75F.9080806@gmail.com> <4786CADD.7030305@gmx.net> Message-ID: <4786D5B4.1040108@gmail.com> Carl-Daniel Hailfinger wrote: > On 11.01.2008 02:33, Corey Osgood wrote: > >> joe at smittys.pointclark.net wrote: >> >> >>> Quoting Corey Osgood : >>> >>> >>>> Do you mean the microcode files? If so, the microcode update looks like >>>> this: >>>> >>>> Header >>>> Update Revision >>>> Date >>>> Processor Signature (CPU ID) >>>> ... >>>> >>>> So, the 4th entry in the update is always the CPU ID, and conveniently >>>> it's always the last one on the first line. It also makes grepping for >>>> them very easy, once you have the update broken down into smaller files. >>>> This is documented *somewhere* in LB, but I can't find it at the moment. >>>> It's also in the Intel architecture manual, volume 3a, table 9-6. >>>> >>>> In the past we labeled some CPU IDs as to what CPUs they belonged to. In >>>> truth, Intel uses the same CPU IDs for a variety of CPUs, for instance >>>> in some cases Celeron, Pentium X, and Xeons all share a common ID, since >>>> the core is still the same. So we can't really do that any more ;) >>>> >>>> >>>> >>> Oh ok, that makes sense. >>> >>> Acked-by: Joseph Smith >>> >>> >> Thanks, Joe. Anyone else have anything to say? Honestly expected more >> feedback, but if there are no objections I'll commit it tomorrow. >> >> The other thing I forgot to mention was that all the data on CPU IDs >> came from the existing code and this site: >> http://processorfinder.intel.com. Some of them are a bit unclear on what >> sockets they use, but if anything comes up wrong, we can easily correct it. >> >> > > Do you see any way to solve the "size problem" for sockets with too many > different cores? It would also be interesting to find out if your work > on stripping duplicate contents gives us new opportunities to reduce > size even further. > > Regards, > Carl-Daniel I'm thinking lzma compression, it knocks the files down to about 1/3 their current size or smaller. But I hate to introduce lzma as a requirement, especially just for this one task, and some distros don't have lzma prepackaged. I have already removed all the duplicate updates, so the only option is possibly eliminating more cores, for socket 604, and for lga775 it's either breaking things down into smaller subsets (pentium vs. core, as i mentioned before), or larger flash chips. joe at smittys.pointclark.net wrote: > Not sure what you mean? How many different cores could you put in even > the most popular socket, three? > > Thanks - Joe LGA775 currently has 19 (and may have more I don't know about). Using some rough math, I get a rounded-down size of 186KB (really is quite a bit more) for its updates, and that would go into both normal and fallback images. -Corey From peter at stuge.se Fri Jan 11 03:46:31 2008 From: peter at stuge.se (Peter Stuge) Date: Fri, 11 Jan 2008 03:46:31 +0100 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <20080110150443.GA15940@localdomain> References: <20070902141108.GA9106@localdomain> <47520056.7060508@gmail.com> <20071202044824.3246.qmail@stuge.se> <200801100031.31098.harald.gutmann@gmx.net> <20080110150443.GA15940@localdomain> Message-ID: <20080111024631.21673.qmail@stuge.se> On Thu, Jan 10, 2008 at 10:04:43AM -0500, Ward Vandewege wrote: > Actually, if you're interested in SMT soldering, check out this > '101' video: > > http://www.curiousinventor.com/guides/Surface_Mount_Soldering/101 > > There is some very helpful information in there! Indeed! I definately recommend this even if you actually don't own a soldering iron yet, but have thought about buying one, and certainly if you already own one. :) //Peter From jakllsch at kollasch.net Fri Jan 11 03:47:23 2008 From: jakllsch at kollasch.net (jakllsch at kollasch.net) Date: Thu, 10 Jan 2008 20:47:23 -0600 Subject: [LinuxBIOS] 2 Terabyte Limit of BIOS/MBR In-Reply-To: References: Message-ID: <20080111024723.GB25714@kirkkit.kollasch.net> On Thu, Jan 10, 2008 at 09:59:14PM +0100, Martin Marcher wrote: > Hello, > > hope to be in the right place to ask this, if not just point me to where you > think it's apropriate > > my Hardware is: > > Tyan Transport GT20 (B2865) > http://www.tyan.com/support_download_manuals.aspx?model=B.GT20B2865 > > an Areca 1210 raid controller is attached to it and I just was hit by the > 2TB limit which a BIOS can handle. > > Is that right that the problem is the BIOS? Or at least a problem with the Areca BIOS extension. Could also be the main Tyan BIOS too I suppose. INT13h Extensions support 64-bit LBAs, so that's not an inherent problem unless there are limitations of the BIOSes's implementations. > how I understand the different articles at wikipedia, ms and different > netsources the BIOS just can't handle disks that are larger than 2TB, in > turn this renders a MBR unusable. Fine so I convert the disk to a GPT and > off I should go. But I found that the bios of this board still refuses to > accept the disk (reported as an scsi device from the controller) and just > says "No BIOS disk found". Well, you're distorting some things there. The BIOS itself just provides functions for disk access, and by itself, is incapable of understanding partition tables. Also, the limitations of 32-bit Windows? are totally irrelevant. :) Now to get remotely on-topic: If you're not interested in the task of porting LB to your board, I'd start bugging both Tyan and Areca. Jonathan Kollasch -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From peter at stuge.se Fri Jan 11 03:49:44 2008 From: peter at stuge.se (Peter Stuge) Date: Fri, 11 Jan 2008 03:49:44 +0100 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <200801100031.31098.harald.gutmann@gmx.net> References: <20070902141108.GA9106@localdomain> <47520056.7060508@gmail.com> <20071202044824.3246.qmail@stuge.se> <200801100031.31098.harald.gutmann@gmx.net> Message-ID: <20080111024944.22378.qmail@stuge.se> On Thu, Jan 10, 2008 at 12:31:31AM +0100, Harald Gutmann wrote: > > The switch mod can be simplified to use existing pads and no pins > > have to be lifted from the flash chips anymore. > > > > 1. Remove R509. > > 2. Populate R89 and R130 with 10k or 100k pull-up 0402 resistors. > > 3. Solder the switch common to Q4-3 and switch between Q4-1 and Q5-1. > > Confirmed. But not with SMD Resistors. Great, thanks for the confirmation! > First I removed the R509. > As there are connections from R89 Left to U5 VCC; from R89 Right to > U9 CS#; from R130 Left to U5 CS# and from R130 Right to U9 VCC I > soldered normal 100k resistors between U5 VCC and U9 CS# and > between U5 CS# and U9 VCC. > > Here are two photos of my new mod: > http://img141.imageshack.us/img141/8866/dscf1791ob2.jpg > http://img104.imageshack.us/img104/2579/dscf1792nn2.jpg Looks good! > I know, that these cables to the sockel are not really fine, but i > had no other solution for mounting the sockel on the mainboard and > it works fine! As long as it works, it is good enough. :) //Peter From peter at stuge.se Fri Jan 11 04:02:29 2008 From: peter at stuge.se (Peter Stuge) Date: Fri, 11 Jan 2008 04:02:29 +0100 Subject: [LinuxBIOS] LinuxBIOSv3 Config files In-Reply-To: <20080110191814.GE25867@cosmic.amd.com> References: <2831fecf0801081530m3a3c0a99n3222c8b164f2e110@mail.gmail.com> <20080108233849.GD28312@cosmic.amd.com> <2831fecf0801091356h407194b0od60664726cb4da7c@mail.gmail.com> <13426df10801101019v3b98ab22iff447a6abddddca0@mail.gmail.com> <20080110182905.GB25867@cosmic.amd.com> <13426df10801101103y388720a6w2b818eb0ff29f794@mail.gmail.com> <20080110191814.GE25867@cosmic.amd.com> Message-ID: <20080111030229.25891.qmail@stuge.se> On Thu, Jan 10, 2008 at 12:18:14PM -0700, Jordan Crouse wrote: > it really should be a feature that kconfig offers. It's make defconfig in Linux. //Peter From peter at stuge.se Fri Jan 11 04:34:39 2008 From: peter at stuge.se (Peter Stuge) Date: Fri, 11 Jan 2008 04:34:39 +0100 Subject: [LinuxBIOS] Intel refactoring and microcode updates In-Reply-To: <4786D5B4.1040108@gmail.com> References: <47843324.2050907@gmail.com> <20080109212412.cgsck1t6xxcww4s8@www.smittys.pointclark.net> <4785AC27.40102@gmail.com> <20080110074842.3p5v4fkoowkg408w@www.smittys.pointclark.net> <4786C75F.9080806@gmail.com> <4786CADD.7030305@gmx.net> <4786D5B4.1040108@gmail.com> Message-ID: <20080111033439.1814.qmail@stuge.se> On Thu, Jan 10, 2008 at 09:34:28PM -0500, Corey Osgood wrote: > > How many different cores could you put in even the most popular > > socket, three? > > LGA775 currently has 19 (and may have more I don't know about). > Using some rough math, I get a rounded-down size of 186KB (really > is quite a bit more) for its updates, and that would go into both > normal and fallback images. I think we need to make it configurable. //Peter From myles at pel.cs.byu.edu Fri Jan 11 05:00:45 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Thu, 10 Jan 2008 21:00:45 -0700 Subject: [LinuxBIOS] LinuxBIOSv3 Config files In-Reply-To: <20080111030229.25891.qmail@stuge.se> References: <2831fecf0801081530m3a3c0a99n3222c8b164f2e110@mail.gmail.com><20080108233849.GD28312@cosmic.amd.com><2831fecf0801091356h407194b0od60664726cb4da7c@mail.gmail.com><13426df10801101019v3b98ab22iff447a6abddddca0@mail.gmail.com><20080110182905.GB25867@cosmic.amd.com><13426df10801101103y388720a6w2b818eb0ff29f794@mail.gmail.com><20080110191814.GE25867@cosmic.amd.com> <20080111030229.25891.qmail@stuge.se> Message-ID: <009701c85406$8b8deb90$2023040a@chimp> > On Thu, Jan 10, 2008 at 12:18:14PM -0700, Jordan Crouse wrote: > > it really should be a feature that kconfig offers. > > It's make defconfig in Linux. > Make defconfig ignores your .config file. What I wanted was something similar to make allyesconfig, which chooses yes for anything you didn't specify. Maybe make alldefconfig? Myles > //Peter From rminnich at gmail.com Fri Jan 11 05:08:57 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 10 Jan 2008 20:08:57 -0800 Subject: [LinuxBIOS] PATCH: lx car that returns from disable_car In-Reply-To: <4782A542.6030109@amd.com> References: <13426df10801041405h1d3e0f1eocdfba04c34144eb9@mail.gmail.com> <4782A542.6030109@amd.com> Message-ID: <13426df10801102008ld9b6d6rab616a6beee6d443@mail.gmail.com> Marc, here are the register dumps. As a reminder, we seem to have no memory above 1M. For the other discussion, iterate over the flash to find all the headers is taking 2-3 seconds. Sorry, that's just too long. We need the terminator in LAR; iterate over all of FLASH even once is just not going to work. Even if you turn caching on, the initial load is going to kill you. Thanks ron -------------- next part -------------- A non-text attachment was scrubbed... Name: marc2 Type: application/octet-stream Size: 3679 bytes Desc: not available URL: From peter at stuge.se Fri Jan 11 05:37:27 2008 From: peter at stuge.se (Peter Stuge) Date: Fri, 11 Jan 2008 05:37:27 +0100 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <13426df10801102008ld9b6d6rab616a6beee6d443@mail.gmail.com> <4786CF4F.8010605@gmx.net> References: <47800115.1060301@coresystems.de> <13426df10801051415q69c0b3er4e6efabcdbe5c3e3@mail.gmail.com> <47800451.3080805@coresystems.de> <13426df10801051429o44b18cd4j8f21d6dd976d7f90@mail.gmail.com> <47800753.6020900@coresystems.de> <13426df10801051444y5ca97762xd67c07783a9af478@mail.gmail.com> <20080106011152.21774.qmail@stuge.se> <13426df10801052052q416a8532g72e8478190763bfa@mail.gmail.com> <20080111013803.3369.qmail@stuge.se> <4786CF4F.8010605@gmx.net> Message-ID: <20080111043727.16212.qmail@stuge.se> On Fri, Jan 11, 2008 at 03:07:11AM +0100, Carl-Daniel Hailfinger wrote: > > In practice, the marker is the most efficient method, but it is a > > bit of an abomination IMO. :p > > Big question: Is v3 a matter of pride or speed or userfriendliness? > I haven't decided yet. ;-) All of the above, to me at least. > > How do we handle the integrity issue when a single flash block > > that contains the start of a lar file is erased at runtime? (Thus > > breaking a link in the list.) > > If we really do erases at LB runtime, the person waiting for the > erase surely has the time to rebuild the index/cache (which will > probably need a fraction of the time needed for erase). No matter who is erasing, the reality is that the marker is not foolproof; for that to happen, power will have to fail exactly after 8 bytes of magic have been written to a sector I think that the run-time index should always be created once we hit the marker. But we should try to avoid ever hitting the marker in the first place. Perhaps by introducing certain requirements for the "open-ended" special filenames that we currently have, ie. segment0 and any others. On Thu, Jan 10, 2008 at 08:08:57PM -0800, ron minnich wrote: > For the other discussion, iterate over the flash to find all the > headers is taking 2-3 seconds. Sorry, that's just too long. Fully agreed. > We need the terminator in LAR; iterate over all of FLASH even once > is just not going to work. We should try to redesign so that it never happens in the common case. For the corrupted flash case I think the best we can accomplish is the runtime index, which will have to cost a bit of time, but at least it will only be once per boot rather than once per file lookup. Maybe it's not possible to redesign so that we can avoid the scan in the common case. Then I would start looking at aligning members and increasing 16 byte steps to maybe 4k or so. //Peter From uwe at hermann-uwe.de Fri Jan 11 09:07:07 2008 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 11 Jan 2008 09:07:07 +0100 Subject: [LinuxBIOS] Intel refactoring and microcode updates In-Reply-To: <20080111033439.1814.qmail@stuge.se> References: <47843324.2050907@gmail.com> <20080109212412.cgsck1t6xxcww4s8@www.smittys.pointclark.net> <4785AC27.40102@gmail.com> <20080110074842.3p5v4fkoowkg408w@www.smittys.pointclark.net> <4786C75F.9080806@gmail.com> <4786CADD.7030305@gmx.net> <4786D5B4.1040108@gmail.com> <20080111033439.1814.qmail@stuge.se> Message-ID: <20080111080707.GA25382@greenwood> On Fri, Jan 11, 2008 at 04:34:39AM +0100, Peter Stuge wrote: > On Thu, Jan 10, 2008 at 09:34:28PM -0500, Corey Osgood wrote: > > > How many different cores could you put in even the most popular > > > socket, three? > > > > LGA775 currently has 19 (and may have more I don't know about). > > Using some rough math, I get a rounded-down size of 186KB (really > > is quite a bit more) for its updates, and that would go into both > > normal and fallback images. > > I think we need to make it configurable. Yep, agreed. You should be able to specify exactly which CPU you want to use and the build process should only include the updates for just that CPU (or list of CPUs if you specify more than one). Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From uwe at hermann-uwe.de Fri Jan 11 09:27:18 2008 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 11 Jan 2008 09:27:18 +0100 Subject: [LinuxBIOS] Intel refactoring and microcode updates In-Reply-To: <47843324.2050907@gmail.com> References: <47843324.2050907@gmail.com> Message-ID: <20080111082718.GB25382@greenwood> On Tue, Jan 08, 2008 at 09:36:20PM -0500, Corey Osgood wrote: > Both patches Signed-off-by: Corey Osgood I checked that this doesn't break abuild, so far so good. On which hardware has this been tested so far? I'm reluctant to commit this without some broader testing on actual hardware. I'd say at least some of the 440BX boards, i810, and others. I can test some of the above soonish I hope, but someone with server-grade boards should probably also do some tests (E7520 boards and similar). > Index: src/cpu/intel/microcode/2107-m406fbB4.inc > =================================================================== > --- src/cpu/intel/microcode/2107-m406fbB4.inc (revision 0) > +++ src/cpu/intel/microcode/2107-m406fbB4.inc (revision 0) > @@ -0,0 +1,266 @@ > +/** > + * Copyright Intel Corporation, 1995, 96, 97, 98, 99, 2000, 01, 02, > + * 03, 04, 05, 06, 07. > + * > + * These microcode updates are distributed for the sole purpose of > + * installation in the BIOS or Operating System of computer systems > + * which include a Genuine Intel microprocessor sold or distributed > + * to or by you. You are not authorized to use this material for > + * any other purpose. > +**/ Where exactly do these files come from (URL on intel.com?) We should document this in either the files and/or the wiki. I know about http://www.urbanmyth.org/microcode/ http://people.debian.org/~cate/files/microcode/ is that the source? There's also some stuff at http://downloadcenter.intel.com/detail_desc.aspx?strstate=live&productid=528&dwnldid=14303&agr=n&lang=eng&prdmap=528 for example, which has a different license header, though: /+++ / Copyright (c) <1995-2008>, Intel Corporation. / All rights reserved. / / Redistribution. Redistribution and use in binary form, without modification, are / permitted provided that the following conditions are met: / .Redistributions must reproduce the above copyright notice and the following / disclaimer in the documentation and/or other materials provided with the / distribution. / .Neither the name of Intel Corporation nor the names of its suppliers may be used / to endorse or promote products derived from this software without specific prior / written permission. / .No reverse engineering, decompilation, or disassembly of this software is / permitted. / ."Binary form" includes any format commonly used for electronic conveyance / which is a reversible, bit-exact translation of binary representation to ASCII or / ISO text, for example, "uuencode." / / DISCLAIMER. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT / HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED / WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED / WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR / PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER / OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, / SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT / NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; / LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER / CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, / STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) / ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF / ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. / / These microcode updates are distributed for the sole purpose of / installation in the BIOS or Operating System of computer systems / which include a Genuine Intel microprocessor sold or distributed / to or by you. You are not authorized to use this material for / any other purpose. /--- > +/* Note: It is impossible to tell what Xeons are Socket 603 vs 604 from the info > + * on Intel's website. Also, socket 603 CPUs work in 604 systems. Hence, > + * combined for good reasons. */ > +struct cpu_device_id cpu_table[] = { > + { X86_VENDOR_INTEL, 0x0f0a }, > + { X86_VENDOR_INTEL, 0x0f11 }, > + { X86_VENDOR_INTEL, 0x0f12 }, > + { X86_VENDOR_INTEL, 0x0f22 }, > + { X86_VENDOR_INTEL, 0x0f24 }, > + { X86_VENDOR_INTEL, 0x0f25 }, > + { X86_VENDOR_INTEL, 0x0f26 }, > + { X86_VENDOR_INTEL, 0x0f27 }, > + { X86_VENDOR_INTEL, 0x0f29 }, > + { 0, 0 }, > +}; > + > +struct chip_operations cpu_intel_socket_603_ops = { > + CHIP_NAME("Socket 603 CPU") Shouldn't this be CHIP_NAME("Socket 603/604 CPU") then? > +/* Note: It is impossible to tell what Xeons are Socket 603 vs 604 from the info > + * on Intel's website. Also, socket 603 CPUs work in 604 systems. Hence, > + * combined for good reasons. */ > +struct cpu_device_id cpu_table[] = { > + { X86_VENDOR_INTEL, 0x0f22 }, > + { X86_VENDOR_INTEL, 0x0f24 }, > + { X86_VENDOR_INTEL, 0x0f25 }, > + { X86_VENDOR_INTEL, 0x0f26 }, > + { X86_VENDOR_INTEL, 0x0f27 }, > + { X86_VENDOR_INTEL, 0x0f29 }, > + { X86_VENDOR_INTEL, 0x0f34 }, > + { X86_VENDOR_INTEL, 0x0f41 }, > + { X86_VENDOR_INTEL, 0x0f43 }, > + { X86_VENDOR_INTEL, 0x0f48 }, > + { X86_VENDOR_INTEL, 0x0f49 }, > + { X86_VENDOR_INTEL, 0x0f4a }, > + { 0, 0 }, > +}; > + > +struct chip_operations cpu_intel_socket_604_ops = { > + CHIP_NAME("Socket 604 CPU") Same here? > +/* Note: Intel does not explicitly state which CPUs are Socket M vs Socket P on their website, but there was a large overlap of the ones I could identify. Hence, this includes all Socket M and P CPUs, along with onboard Core, Core 2, and (Core/Core2 based) Celeron M CPUs, for convenience's sake */ Line is too long. > +struct cpu_device_id cpu_table[] = { > + { X86_VENDOR_INTEL, 0x06e8 }, > + { X86_VENDOR_INTEL, 0x06ec }, > + { X86_VENDOR_INTEL, 0x06f2 }, > + { X86_VENDOR_INTEL, 0x06f6 }, > + { X86_VENDOR_INTEL, 0x06fa }, > + { X86_VENDOR_INTEL, 0x06fb }, > + { X86_VENDOR_INTEL, 0x06fd }, > + /* I don't know if we'll be able to see all 5 digits, so both are included */ > + { X86_VENDOR_INTEL, 0x10676 }, > + { X86_VENDOR_INTEL, 0x0676 }, Add a TODO here maybe, we should find out and fix it. > +/* Slot 1 CPU IDs. Note that the same ID is sometimes used for Celeron, > + * Pentium, and Xeon families, in various packages. This also includes > + * Mobile Pentium II and Celeron families */ > +struct cpu_device_id cpu_table[] = { Maybe const struct cpu_device_id cpu_table[] = { (same for most other files) > +u32 microcode_updates[] = { These arrays can be const too, I guess. > Index: src/cpu/intel/intel_shared/intel_init.c > =================================================================== > --- src/cpu/intel/intel_shared/intel_init.c (revision 0) > +++ src/cpu/intel/intel_shared/intel_init.c (revision 0) > @@ -0,0 +1,53 @@ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#ifdef CONFIG_SMP > +#if CONFIG_SMP Why both? > Index: src/cpu/intel/intel_generic/intel_generic.c > =================================================================== > --- src/cpu/intel/intel_generic/intel_generic.c (revision 0) > +++ src/cpu/intel/intel_generic/intel_generic.c (revision 0) > @@ -0,0 +1,85 @@ > +#define NO_MICROCODE_UPDATES > +#include "../intel_shared/intel_init.c" > +#include "chip.h" > + > +/* CPU IDs for all >=PPro x86 and x86_64 Intel CPUs, as of 12/30/2007, without > + * the microcode updates. Microcode updates should be done later, with recent > + * kernels this is done automatically, just put the latest microcode update file > + * in /etc/firmware */ > +struct cpu_device_id cpu_table[] = { > +/* TODO!!! */ What exactly? > Index: src/mainboard/a-trend/atc-6220/Config.lb > =================================================================== > --- src/mainboard/a-trend/atc-6220/Config.lb (revision 3036) > +++ src/mainboard/a-trend/atc-6220/Config.lb (working copy) > @@ -82,7 +82,7 @@ > > chip northbridge/intel/i440bx # Northbridge > device apic_cluster 0 on # APIC cluster > - chip cpu/intel/slot_2 # CPU (FIXME: It's slot 1, actually) > + chip cpu/intel/slot_1 # CPU > device apic 0 on end # APIC > end > end Nice, thanks. This was on my TODO list, too. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From echelon at free.fr Fri Jan 11 12:04:41 2008 From: echelon at free.fr (Florentin Demetrescu) Date: Fri, 11 Jan 2008 12:04:41 +0100 Subject: [LinuxBIOS] m57sli : debugging the flashrom problem when booting with LB In-Reply-To: <2ea3fae10801101542pe17862fsb82bdffa9a41853@mail.gmail.com> References: <47668D76.6060602@gmx.net> <4766DD09.1070400@gmx.net> <1199963686.4785fe264a52d@imp.free.fr> <478612C1.7090504@gmx.net> <2ea3fae10801101542pe17862fsb82bdffa9a41853@mail.gmail.com> Message-ID: <1200049481.47874d495d0bc@imp.free.fr> Okay I will check this with my oscilloscope.. The most difficult would be to identify the LPC signals on the IT8716 chip, given that the package really installed onto the board doesn't match the publically available datasheet.. But with some effort this can be done.. I hope to be able to give some result after this WE.. Florentin Quoting yhlu : > On Jan 10, 2008 4:42 AM, Carl-Daniel Hailfinger > wrote: > > On 10.01.2008 12:14, Florentin Demetrescu wrote: > > > Hi all, > > > For my part I continue to think that there is a problem with the IO > address > > > decoding into the PCI->LPC bridge in mcp55.. Yinghai, can you help > please? > > > > > > > Yinghai? Is there some mcp55 conf we need to change? > > that range is already decoded to LPC bridge ( enable_rom, or > cache_as_rom_auto, or mcp55_lpc.c) > > YH > From joe at smittys.pointclark.net Fri Jan 11 13:37:39 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Fri, 11 Jan 2008 07:37:39 -0500 Subject: [LinuxBIOS] Intel refactoring and microcode updates In-Reply-To: <4786D5B4.1040108@gmail.com> References: <47843324.2050907@gmail.com> <20080109212412.cgsck1t6xxcww4s8@www.smittys.pointclark.net> <4785AC27.40102@gmail.com> <20080110074842.3p5v4fkoowkg408w@www.smittys.pointclark.net> <4786C75F.9080806@gmail.com> <4786CADD.7030305@gmx.net> <4786D5B4.1040108@gmail.com> Message-ID: <20080111073739.3qspsc1dwk8wc8s0@www.smittys.pointclark.net> Quoting Corey Osgood : > Carl-Daniel Hailfinger wrote: >> On 11.01.2008 02:33, Corey Osgood wrote: >> >>> joe at smittys.pointclark.net wrote: >>> >>> >>>> Quoting Corey Osgood : >>>> >>>> >>>>> Do you mean the microcode files? If so, the microcode update looks like >>>>> this: >>>>> >>>>> Header >>>>> Update Revision >>>>> Date >>>>> Processor Signature (CPU ID) >>>>> ... >>>>> >>>>> So, the 4th entry in the update is always the CPU ID, and conveniently >>>>> it's always the last one on the first line. It also makes grepping for >>>>> them very easy, once you have the update broken down into smaller files. >>>>> This is documented *somewhere* in LB, but I can't find it at the moment. >>>>> It's also in the Intel architecture manual, volume 3a, table 9-6. >>>>> >>>>> In the past we labeled some CPU IDs as to what CPUs they belonged to. In >>>>> truth, Intel uses the same CPU IDs for a variety of CPUs, for instance >>>>> in some cases Celeron, Pentium X, and Xeons all share a common ID, since >>>>> the core is still the same. So we can't really do that any more ;) >>>>> >>>>> >>>>> >>>> Oh ok, that makes sense. >>>> >>>> Acked-by: Joseph Smith >>>> >>>> >>> Thanks, Joe. Anyone else have anything to say? Honestly expected more >>> feedback, but if there are no objections I'll commit it tomorrow. >>> >>> The other thing I forgot to mention was that all the data on CPU IDs >>> came from the existing code and this site: >>> http://processorfinder.intel.com. Some of them are a bit unclear on what >>> sockets they use, but if anything comes up wrong, we can easily correct it. >>> >>> >> >> Do you see any way to solve the "size problem" for sockets with too many >> different cores? It would also be interesting to find out if your work >> on stripping duplicate contents gives us new opportunities to reduce >> size even further. >> >> Regards, >> Carl-Daniel > > I'm thinking lzma compression, it knocks the files down to about 1/3 > their current size or smaller. But I hate to introduce lzma as a > requirement, especially just for this one task, and some distros don't > have lzma prepackaged. I have already removed all the duplicate updates, > so the only option is possibly eliminating more cores, for socket 604, > and for lga775 it's either breaking things down into smaller subsets > (pentium vs. core, as i mentioned before), or larger flash chips. > > joe at smittys.pointclark.net wrote: >> Not sure what you mean? How many different cores could you put in even >> the most popular socket, three? >> >> Thanks - Joe > > LGA775 currently has 19 (and may have more I don't know about). Using > some rough math, I get a rounded-down size of 186KB (really is quite a > bit more) for its updates, and that would go into both normal and > fallback images. > > -Corey > Wow I guess I didn't realize LGA775 had so many..... Thanks - Joe From stepan at coresystems.de Fri Jan 11 13:48:02 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 11 Jan 2008 13:48:02 +0100 Subject: [LinuxBIOS] 2 Terabyte Limit of BIOS/MBR In-Reply-To: <20080111024723.GB25714@kirkkit.kollasch.net> References: <20080111024723.GB25714@kirkkit.kollasch.net> Message-ID: <20080111124802.GA18192@coresystems.de> * jakllsch at kollasch.net [080111 03:47]: > > how I understand the different articles at wikipedia, ms and different > > netsources the BIOS just can't handle disks that are larger than 2TB, in > > turn this renders a MBR unusable. Fine so I convert the disk to a GPT and > > off I should go. But I found that the bios of this board still refuses to > > accept the disk (reported as an scsi device from the controller) and just > > says "No BIOS disk found". > > Well, you're distorting some things there. The BIOS itself > just provides functions for disk access, and by itself, is > incapable of understanding partition tables. While I thought this initially, I now believe this is not exactly true. Many systems are nowadays installed in a way that the MBR does not contain the bootblock code, but instead points to an active primary partition that contains the partition bootblock. This implies that the BIOS knows how to parse the MBR and run the partition bootblock. Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From stepan at coresystems.de Fri Jan 11 13:48:36 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 11 Jan 2008 13:48:36 +0100 Subject: [LinuxBIOS] LinuxBIOSv3 Config files In-Reply-To: <009701c85406$8b8deb90$2023040a@chimp> References: <20080111030229.25891.qmail@stuge.se> <009701c85406$8b8deb90$2023040a@chimp> Message-ID: <20080111124836.GB18192@coresystems.de> * Myles Watson [080111 05:00]: > > On Thu, Jan 10, 2008 at 12:18:14PM -0700, Jordan Crouse wrote: > > > it really should be a feature that kconfig offers. > > > > It's make defconfig in Linux. > > > > Make defconfig ignores your .config file. What I wanted was something > similar to make allyesconfig, which chooses yes for anything you didn't > specify. Maybe make alldefconfig? make oldconfig? -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From stepan at coresystems.de Fri Jan 11 13:52:06 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 11 Jan 2008 13:52:06 +0100 Subject: [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <4786CF4F.8010605@gmx.net> References: <47800115.1060301@coresystems.de> <13426df10801051415q69c0b3er4e6efabcdbe5c3e3@mail.gmail.com> <47800451.3080805@coresystems.de> <13426df10801051429o44b18cd4j8f21d6dd976d7f90@mail.gmail.com> <47800753.6020900@coresystems.de> <13426df10801051444y5ca97762xd67c07783a9af478@mail.gmail.com> <20080106011152.21774.qmail@stuge.se> <13426df10801052052q416a8532g72e8478190763bfa@mail.gmail.com> <20080111013803.3369.qmail@stuge.se> <4786CF4F.8010605@gmx.net> Message-ID: <20080111125206.GA2236@coresystems.de> * Carl-Daniel Hailfinger [080111 03:07]: > Hopefully that's the worst case. Still horrible if we use 1 MByte ROMs - > 5 seconds for reading the whole ROM is unacceptable. We will have to bear with that if we plan to check the rom checksum at some point. This feature should definitely be an option though, given the slow speed of the flashes. Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From corey.osgood at gmail.com Fri Jan 11 15:42:00 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Fri, 11 Jan 2008 09:42:00 -0500 Subject: [LinuxBIOS] Intel refactoring and microcode updates In-Reply-To: <20080111033439.1814.qmail@stuge.se> References: <47843324.2050907@gmail.com> <20080109212412.cgsck1t6xxcww4s8@www.smittys.pointclark.net> <4785AC27.40102@gmail.com> <20080110074842.3p5v4fkoowkg408w@www.smittys.pointclark.net> <4786C75F.9080806@gmail.com> <4786CADD.7030305@gmx.net> <4786D5B4.1040108@gmail.com> <20080111033439.1814.qmail@stuge.se> Message-ID: <47878038.3070102@gmail.com> Peter Stuge wrote: > On Thu, Jan 10, 2008 at 09:34:28PM -0500, Corey Osgood wrote: > >>> How many different cores could you put in even the most popular >>> socket, three? >>> >> LGA775 currently has 19 (and may have more I don't know about). >> Using some rough math, I get a rounded-down size of 186KB (really >> is quite a bit more) for its updates, and that would go into both >> normal and fallback images. >> > > I think we need to make it configurable. > > > //Peter > I don't like that. With a factory bios, you expect the correct microcode update for your CPU to be present, no matter what CPU you put in a socket. We should be able to do the same. -Corey From peter at stuge.se Fri Jan 11 15:54:18 2008 From: peter at stuge.se (Peter Stuge) Date: Fri, 11 Jan 2008 15:54:18 +0100 Subject: [LinuxBIOS] Intel refactoring and microcode updates In-Reply-To: <47878038.3070102@gmail.com> References: <47843324.2050907@gmail.com> <20080109212412.cgsck1t6xxcww4s8@www.smittys.pointclark.net> <4785AC27.40102@gmail.com> <20080110074842.3p5v4fkoowkg408w@www.smittys.pointclark.net> <4786C75F.9080806@gmail.com> <4786CADD.7030305@gmx.net> <4786D5B4.1040108@gmail.com> <20080111033439.1814.qmail@stuge.se> <47878038.3070102@gmail.com> Message-ID: <20080111145418.17092.qmail@stuge.se> On Fri, Jan 11, 2008 at 09:42:00AM -0500, Corey Osgood wrote: > Peter Stuge wrote: > > I think we need to make it configurable. > > I don't like that. With a factory bios, you expect the correct > microcode update for your CPU to be present, no matter what CPU you > put in a socket. (Actually no, not always.) > We should be able to do the same. I agree, but we should also try to be even more flexible. I think we should allow inclusion of 0<=n<=all microcode updates. Definately an advanced option, but still. //Peter From uwe at hermann-uwe.de Fri Jan 11 16:31:50 2008 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 11 Jan 2008 16:31:50 +0100 Subject: [LinuxBIOS] LinuxBIOSv3 Config files In-Reply-To: <20080111124836.GB18192@coresystems.de> References: <20080111030229.25891.qmail@stuge.se> <009701c85406$8b8deb90$2023040a@chimp> <20080111124836.GB18192@coresystems.de> Message-ID: <20080111153150.GA16602@greenwood> On Fri, Jan 11, 2008 at 01:48:36PM +0100, Stefan Reinauer wrote: > * Myles Watson [080111 05:00]: > > > On Thu, Jan 10, 2008 at 12:18:14PM -0700, Jordan Crouse wrote: > > > > it really should be a feature that kconfig offers. > > > > > > It's make defconfig in Linux. > > > > > > > Make defconfig ignores your .config file. What I wanted was something > > similar to make allyesconfig, which chooses yes for anything you didn't > > specify. Maybe make alldefconfig? > > make oldconfig? That's interactive per default, I think. But it's the correct option if you want the defaults for unspecified options, IIRC. If you want "yes" for all unspecified options: make oldconfig < /usr/bin/yes Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From uwe at hermann-uwe.de Fri Jan 11 16:33:21 2008 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 11 Jan 2008 16:33:21 +0100 Subject: [LinuxBIOS] Intel refactoring and microcode updates In-Reply-To: <20080111145418.17092.qmail@stuge.se> References: <47843324.2050907@gmail.com> <20080109212412.cgsck1t6xxcww4s8@www.smittys.pointclark.net> <4785AC27.40102@gmail.com> <20080110074842.3p5v4fkoowkg408w@www.smittys.pointclark.net> <4786C75F.9080806@gmail.com> <4786CADD.7030305@gmx.net> <4786D5B4.1040108@gmail.com> <20080111033439.1814.qmail@stuge.se> <47878038.3070102@gmail.com> <20080111145418.17092.qmail@stuge.se> Message-ID: <20080111153321.GB16602@greenwood> On Fri, Jan 11, 2008 at 03:54:18PM +0100, Peter Stuge wrote: > On Fri, Jan 11, 2008 at 09:42:00AM -0500, Corey Osgood wrote: > > Peter Stuge wrote: > > > I think we need to make it configurable. > > > > I don't like that. With a factory bios, you expect the correct > > microcode update for your CPU to be present, no matter what CPU you > > put in a socket. > > (Actually no, not always.) > > > > We should be able to do the same. > > I agree, but we should also try to be even more flexible. I think we > should allow inclusion of 0<=n<=all microcode updates. Definately an > advanced option, but still. Yep, that's what I meant. It's fine if the default is "all microcode updates", but there should be an option for advanced users to only use the one(s) you really want or need in order to save time and space. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From rminnich at gmail.com Fri Jan 11 16:59:17 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 11 Jan 2008 07:59:17 -0800 Subject: [LinuxBIOS] LinuxBIOSv3 Config files In-Reply-To: <20080111153150.GA16602@greenwood> References: <20080111030229.25891.qmail@stuge.se> <009701c85406$8b8deb90$2023040a@chimp> <20080111124836.GB18192@coresystems.de> <20080111153150.GA16602@greenwood> Message-ID: <13426df10801110759g47f5c066p915c9bd95598fbc@mail.gmail.com> On Jan 11, 2008 7:31 AM, Uwe Hermann wrote: > If you want "yes" for all unspecified options: > > make oldconfig < /usr/bin/yes Now, Uwe, we just came full circle. I said something like that a few messages ago and Jordan yelled at me :-) ron From peter at stuge.se Fri Jan 11 17:03:48 2008 From: peter at stuge.se (Peter Stuge) Date: Fri, 11 Jan 2008 17:03:48 +0100 Subject: [LinuxBIOS] LinuxBIOSv3 Config files In-Reply-To: <13426df10801110759g47f5c066p915c9bd95598fbc@mail.gmail.com> References: <20080111030229.25891.qmail@stuge.se> <009701c85406$8b8deb90$2023040a@chimp> <20080111124836.GB18192@coresystems.de> <20080111153150.GA16602@greenwood> <13426df10801110759g47f5c066p915c9bd95598fbc@mail.gmail.com> Message-ID: <20080111160348.2709.qmail@stuge.se> On Fri, Jan 11, 2008 at 07:59:17AM -0800, ron minnich wrote: > > If you want "yes" for all unspecified options: > > > > make oldconfig < /usr/bin/yes > > Now, Uwe, we just came full circle. I said something like that a > few messages ago and Jordan yelled at me :-) So will oldconfig read from stdin also for options specified in .config ? If so, this is still no the winner. Linux make help does not seem to have a target that combines oldconfig and defconfig in the desired way. :\ //Peter From uwe at hermann-uwe.de Fri Jan 11 17:27:30 2008 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 11 Jan 2008 17:27:30 +0100 Subject: [LinuxBIOS] LinuxBIOSv3 Config files In-Reply-To: <13426df10801110759g47f5c066p915c9bd95598fbc@mail.gmail.com> References: <20080111030229.25891.qmail@stuge.se> <009701c85406$8b8deb90$2023040a@chimp> <20080111124836.GB18192@coresystems.de> <20080111153150.GA16602@greenwood> <13426df10801110759g47f5c066p915c9bd95598fbc@mail.gmail.com> Message-ID: <20080111162730.GB20696@greenwood> On Fri, Jan 11, 2008 at 07:59:17AM -0800, ron minnich wrote: > On Jan 11, 2008 7:31 AM, Uwe Hermann wrote: > > > If you want "yes" for all unspecified options: > > > > make oldconfig < /usr/bin/yes > > Now, Uwe, we just came full circle. I said something like that a few > messages ago and Jordan yelled at me :-) Yeah, sorry, I should have read the whole thread first ;-) Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From eswierk at arastra.com Fri Jan 11 17:40:01 2008 From: eswierk at arastra.com (Ed Swierk) Date: Fri, 11 Jan 2008 08:40:01 -0800 Subject: [LinuxBIOS] LinuxBIOSv3 Config files In-Reply-To: <20080111160348.2709.qmail@stuge.se> References: <20080111030229.25891.qmail@stuge.se> <009701c85406$8b8deb90$2023040a@chimp> <20080111124836.GB18192@coresystems.de> <20080111153150.GA16602@greenwood> <13426df10801110759g47f5c066p915c9bd95598fbc@mail.gmail.com> <20080111160348.2709.qmail@stuge.se> Message-ID: On 1/11/08, Peter Stuge wrote: > Linux make help does not seem to have a target that combines > oldconfig and defconfig in the desired way. :\ FWIW, Red Hat patches the kernel to achieve this: # This patch adds a "make nonint_oldconfig" which is non-interactive and # also gives a list of missing options at the end. Useful for automated # builds (as used in the buildsystem). http://cvs.fedoraproject.org/viewcvs/rpms/kernel/F-8/linux-2.6-build-nonintconfig.patch?rev=1.11&view=markup --Ed From jordan.crouse at amd.com Fri Jan 11 17:49:30 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Fri, 11 Jan 2008 09:49:30 -0700 Subject: [LinuxBIOS] LinuxBIOSv3 Config files In-Reply-To: References: <20080111030229.25891.qmail@stuge.se> <009701c85406$8b8deb90$2023040a@chimp> <20080111124836.GB18192@coresystems.de> <20080111153150.GA16602@greenwood> <13426df10801110759g47f5c066p915c9bd95598fbc@mail.gmail.com> <20080111160348.2709.qmail@stuge.se> Message-ID: <20080111164930.GA1518@cosmic.amd.com> On 11/01/08 08:40 -0800, Ed Swierk wrote: > On 1/11/08, Peter Stuge wrote: > > Linux make help does not seem to have a target that combines > > oldconfig and defconfig in the desired way. :\ > > FWIW, Red Hat patches the kernel to achieve this: > > # This patch adds a "make nonint_oldconfig" which is non-interactive and > # also gives a list of missing options at the end. Useful for automated > # builds (as used in the buildsystem). > > http://cvs.fedoraproject.org/viewcvs/rpms/kernel/F-8/linux-2.6-build-nonintconfig.patch?rev=1.11&view=markup Wow - that looks like its exactly what we want! Thanks. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From stepan at coresystems.de Fri Jan 11 18:13:31 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 11 Jan 2008 18:13:31 +0100 Subject: [LinuxBIOS] LinuxBIOSv3 Config files In-Reply-To: <20080111160348.2709.qmail@stuge.se> References: <20080111030229.25891.qmail@stuge.se> <009701c85406$8b8deb90$2023040a@chimp> <20080111124836.GB18192@coresystems.de> <20080111153150.GA16602@greenwood> <13426df10801110759g47f5c066p915c9bd95598fbc@mail.gmail.com> <20080111160348.2709.qmail@stuge.se> Message-ID: <4787A3BB.5080504@coresystems.de> Peter Stuge wrote: > On Fri, Jan 11, 2008 at 07:59:17AM -0800, ron minnich wrote: > >>> If you want "yes" for all unspecified options: >>> >>> make oldconfig < /usr/bin/yes >>> >> Now, Uwe, we just came full circle. I said something like that a >> few messages ago and Jordan yelled at me :-) >> > > So will oldconfig read from stdin also for options specified in > .config ? If so, this is still no the winner. > > nope. oldconfig only asks options not available in .config -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From svn at openbios.org Fri Jan 11 18:38:24 2008 From: svn at openbios.org (svn at openbios.org) Date: Fri, 11 Jan 2008 18:38:24 +0100 Subject: [LinuxBIOS] r90 - in buildrom-devel: . config/platforms packages/linuxbios packages/linuxbios/conf.v3 Message-ID: Author: jcrouse Date: 2008-01-11 18:38:23 +0100 (Fri, 11 Jan 2008) New Revision: 90 Modified: buildrom-devel/Config.in buildrom-devel/Makefile buildrom-devel/config/platforms/Config.in buildrom-devel/config/platforms/alix1c.conf buildrom-devel/config/platforms/db800.conf buildrom-devel/config/platforms/dbe61.conf buildrom-devel/config/platforms/ga-2761gxdk.conf buildrom-devel/config/platforms/m57sli.conf buildrom-devel/config/platforms/msm800sev.conf buildrom-devel/config/platforms/norwich.conf buildrom-devel/config/platforms/platforms.conf buildrom-devel/config/platforms/qemu.conf buildrom-devel/config/platforms/serengeti_cheetah.conf buildrom-devel/config/platforms/supermicro-h8dmr.conf buildrom-devel/config/platforms/tyan-s2882.conf buildrom-devel/config/platforms/tyan-s2891.conf buildrom-devel/packages/linuxbios/alix1c-linuxbios.mk buildrom-devel/packages/linuxbios/conf.v3/qemu.conf buildrom-devel/packages/linuxbios/ga-2761gxdk-linuxbios.mk buildrom-devel/packages/linuxbios/generic-linuxbios.mk buildrom-devel/packages/linuxbios/linuxbios.inc buildrom-devel/packages/linuxbios/m57sli-linuxbios.mk buildrom-devel/packages/linuxbios/msm800sev-linuxbios.mk buildrom-devel/packages/linuxbios/norwich-linuxbios.mk buildrom-devel/packages/linuxbios/qemu.mk buildrom-devel/packages/linuxbios/serengeti_cheetah.mk buildrom-devel/packages/linuxbios/supermicro-h8dmr-linuxbios.mk buildrom-devel/packages/linuxbios/tyan-s2882-linuxbios.mk buildrom-devel/packages/linuxbios/tyan-s2891-linuxbios.mk Log: [BUILDROM] Expand linuxbiosv3 support Add more generic support for LinuxBIOSv3 - add specialized package for v3, and add support for using LAR to put it all together. Also add expanded (and better) option ROM support, though we're not actually using it right away. Myles again: It also changes LINUXBIOS variables to LBV2 unless they are used for both. I added dependencies between vendors that don't have any v3 platforms and LINUXBIOS_V2. One of the changes Jordan made was to always build v3 with no payload and then add it later with any binary blobs that might be needed. This way you can change them without rebuilding v3. Signed-off-by: Myles Watson Acked-by: Jordan Crouse Modified: buildrom-devel/Config.in =================================================================== --- buildrom-devel/Config.in 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/Config.in 2008-01-11 17:38:23 UTC (rev 90) @@ -47,12 +47,24 @@ menu "LinuxBIOS configuration" +choice + prompt "LinuxBIOS Version" + default LINUXBIOS_V2 + +config LINUXBIOS_V2 + bool "LinuxBIOS v2" + help + Select this option to build a .rom based on the LinuxBIOS + v2 code. The v2 code is far more stable, and supports many + different platforms. + config LINUXBIOS_V3 - bool "Use LinuxBIOSv3" - depends ADVANCED - default n + bool "LinuxBIOS v3" + depends EXPERIMENTAL help - Use the v3 tree. LinuxBIOSv3 doesn't support all platforms yet. + Select this option to build a LinuxBIOS v3 based ROM. This + is experimental, and only supports a few platforms. +endchoice config USE_LZMA bool "Enable LZMA compression" @@ -61,10 +73,9 @@ depends !PAYLOAD_ETHERBOOT default y help - Allow LZMA compression for the payload. This doesn't work - for FILO or OFW. + Precompress the payload with LZMA. This doesn't work + for FILO, OFW, or ETHERBOOT. - config LB_USE_BUILD bool "Specify a LinuxBIOS build dir" depends ADVANCED Modified: buildrom-devel/Makefile =================================================================== --- buildrom-devel/Makefile 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/Makefile 2008-01-11 17:38:23 UTC (rev 90) @@ -12,6 +12,7 @@ OUTPUT_DIR=$(BASE_DIR)/deploy PACKAGE_DIR=$(BASE_DIR)/packages BIN_DIR=$(BASE_DIR)/bin +ROM_DIR=$(OUTPUT_DIR)/roms ifeq (.config, $(wildcard .config)) dot-config := 1 @@ -39,17 +40,44 @@ # Include the global settings and other checks include $(SCRIPT_DIR)/Build.settings +# TARGET_ROM is what we are ultimately building - this should be +# specified by the platform files + +TARGET_ROM ?= linuxbios.rom +TARGET_ROM_FILE=$(OUTPUT_DIR)/$(TARGET_ROM) + +# Choose the version of LinuxBIOS to build - this might be better +# elsewhere, but what the heck - its easy. + +LINUXBIOS-$(CONFIG_LINUXBIOS_V2) = linuxbios +LINUXBIOS-$(CONFIG_LINUXBIOS_V3) = linuxbiosv3 roms + # Construct the list of packages we will be building -PKGLIST = linuxbios $(PAYLOAD-y) $(HOSTTOOLS-y) +PKGLIST = $(LINUXBIOS-y) $(PAYLOAD-y) $(HOSTTOOLS-y) # Construct the various targets PKG_clean=$(patsubst %, %-clean, $(PKGLIST)) PKG_distclean=$(patsubst %, %-distclean, $(PKGLIST)) -all: $(HOSTTOOLS-y) payload linuxbios +# This is the top level target - for v2, the final deliverable is built +# by LinuxBIOS, for v3 it is built by us, so we have ifdef magic here +ifeq ($(CONFIG_LINUXBIOS_V2),y) +rom: $(HOSTTOOLS-y) payload $(LINUXBIOS-y) +else + +# Add the payload, and then add everything in the deploy/roms directory + +rom: $(HOSTTOOLS-y) payload $(LINUXBIOS-y) + cp $(LBV3_OUTPUT) $(TARGET_ROM_FILE) + $(STAGING_DIR)/bin/lar -a $(TARGET_ROM_FILE) $(PAYLOAD_TARGET):normal/payload + for file in `ls $(ROM_DIR)`; do \ + $(STAGING_DIR)/bin/lar -a $(TARGET_ROM_FILE) $(ROM_DIR)/$$file:$$file; \ + done +endif + payload: $(PAYLOAD_TARGET) clean: $(PKG_clean) @@ -70,12 +98,18 @@ MKTARGETS:= $(shell ls $(PACKAGE_DIR)/*/*.mk) -include $(filter-out $(PACKAGE_DIR)/kernel/% $(PACKAGE_DIR)/linuxbios/%,$(MKTARGETS)) +include $(filter-out $(PACKAGE_DIR)/kernel/% $(PACKAGE_DIR)/linuxbios/% $(PACKAGE_DIR)/linuxbiosv3/%,$(MKTARGETS)) -include $(KERNEL_MK) $(LINUXBIOS_MK) +include $(KERNEL_MK) +ifeq ($(CONFIG_LINUXBIOS_V2),y) +include $(LBV2_MK) +else +include $(PACKAGE_DIR)/linuxbiosv3/linuxbiosv3.mk endif +endif + super-distclean: @ make -C $(KCONFIG_DIR) clean @ rm -rf $(BUILD_DIR) Modified: buildrom-devel/config/platforms/Config.in =================================================================== --- buildrom-devel/config/platforms/Config.in 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/config/platforms/Config.in 2008-01-11 17:38:23 UTC (rev 90) @@ -17,6 +17,7 @@ config VENDOR_GIGABYTE bool "GIGABYTE" + depends LINUXBIOS_V2 config VENDOR_PC_ENGINES bool "PC Engines" @@ -26,9 +27,11 @@ config VENDOR_SUPERMICRO bool "Supermicro" + depends LINUXBIOS_V2 config VENDOR_TYAN bool "Tyan" + depends LINUXBIOS_V2 endchoice @@ -61,29 +64,34 @@ config PLATFORM_DB800 bool "AMD DB800" depends VENDOR_AMD + depends LINUXBIOS_V2 select PLATFORM config PLATFORM_GA_M57SLI_S4 bool "GIGABYTE GA-M57SLI-S4" depends VENDOR_GIGABYTE + depends LINUXBIOS_V2 select PLATFORM select PLATFORM_SUPPORT_64BIT config PLATFORM_GA_2761GXDK bool "GIGABYTE GA-2761GXDK" depends VENDOR_GIGABYTE + depends LINUXBIOS_V2 select PLATFORM select PLATFORM_SUPPORT_64BIT config PLATFORM_TYAN_S2882 bool "Tyan S2882" depends VENDOR_TYAN + depends LINUXBIOS_V2 select PLATFORM select PLATFORM_SUPPORT_64BIT config PLATFORM_TYAN_S2891 bool "Tyan S2891" depends VENDOR_TYAN + depends LINUXBIOS_V2 select PLATFORM select PLATFORM_SUPPORT_64BIT @@ -95,18 +103,21 @@ config PLATFORM_SERENGETI_CHEETAH bool "AMD Serengeti-Cheetah" depends VENDOR_AMD + depends LINUXBIOS_V2 select PLATFORM select PLATFORM_SUPPORT_64BIT config PLATFORM_SUPERMICRO_H8DMR bool "Supermicro H8DMR" depends VENDOR_SUPERMICRO + depends LINUXBIOS_V2 select PLATFORM select PLATFORM_SUPPORT_64BIT config PLATFORM_CHEETAH_FAM10 bool "AMD Serengeti-Cheetah with fam10 processor" depends VENDOR_AMD + depends LINUXBIOS_V2 select PLATFORM select PLATFORM_SUPPORT_64BIT endchoice Modified: buildrom-devel/config/platforms/alix1c.conf =================================================================== --- buildrom-devel/config/platforms/alix1c.conf 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/config/platforms/alix1c.conf 2008-01-11 17:38:23 UTC (rev 90) @@ -12,7 +12,7 @@ # Targets KERNEL_MK=$(PACKAGE_DIR)/kernel/alix1c-kernel.mk -LINUXBIOS_MK=$(PACKAGE_DIR)/linuxbios/alix1c-linuxbios.mk +LBV2_MK=$(PACKAGE_DIR)/linuxbios/alix1c-linuxbios.mk # kernel configuration (for LAB) @@ -27,9 +27,9 @@ LINUXBIOS_VENDOR=pcengines LINUXBIOS_BOARD=alix1c -LINUXBIOS_CONFIG=Config.lb -LINUXBIOS_TDIR=alix1c -LINUXBIOS_TAG=2807 +LBV2_CONFIG=Config.lb +LBV2_TDIR=alix1c +LBV2_TAG=2807 LINUXBIOS_ROM_NAME=linuxbios.rom # FILO configuration Modified: buildrom-devel/config/platforms/db800.conf =================================================================== --- buildrom-devel/config/platforms/db800.conf 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/config/platforms/db800.conf 2008-01-11 17:38:23 UTC (rev 90) @@ -14,7 +14,7 @@ # Use the same settings as the Norwich platform KERNEL_MK=$(PACKAGE_DIR)/kernel/norwich-kernel.mk -LINUXBIOS_MK=$(PACKAGE_DIR)/linuxbios/norwich-linuxbios.mk +LBV2_MK=$(PACKAGE_DIR)/linuxbios/norwich-linuxbios.mk # kernel configuration (for LAB) # Use the same settings as the Norwich platform @@ -30,9 +30,9 @@ LINUXBIOS_VENDOR=amd LINUXBIOS_BOARD=db800 -LINUXBIOS_CONFIG=Config.lb -LINUXBIOS_TDIR=db800 -LINUXBIOS_TAG=2810 +LBV2_CONFIG=Config.lb +LBV2_TDIR=db800 +LBV2_TAG=2810 LINUXBIOS_ROM_NAME=db800.rom # FILO configuration Modified: buildrom-devel/config/platforms/dbe61.conf =================================================================== --- buildrom-devel/config/platforms/dbe61.conf 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/config/platforms/dbe61.conf 2008-01-11 17:38:23 UTC (rev 90) @@ -14,7 +14,7 @@ # Targets KERNEL_MK=$(PACKAGE_DIR)/kernel/norwich-kernel.mk -LINUXBIOS_MK=$(PACKAGE_DIR)/linuxbios/norwich-linuxbios.mk +LBV2_MK=$(PACKAGE_DIR)/linuxbios/norwich-linuxbios.mk # kernel configuration (for LAB) @@ -29,9 +29,9 @@ LINUXBIOS_VENDOR=artecgroup LINUXBIOS_BOARD=dbe61 -LINUXBIOS_CONFIG=Config.lb -LINUXBIOS_TDIR=dbe61 -LINUXBIOS_TAG=2728 +LBV2_CONFIG=Config.lb +LBV2_TDIR=dbe61 +LBV2_TAG=2728 LINUXBIOS_ROM_NAME=dbe61.rom # FILO configuration Modified: buildrom-devel/config/platforms/ga-2761gxdk.conf =================================================================== --- buildrom-devel/config/platforms/ga-2761gxdk.conf 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/config/platforms/ga-2761gxdk.conf 2008-01-11 17:38:23 UTC (rev 90) @@ -18,7 +18,7 @@ # Disable for now - I don't know the right kernel for this platform #KERNEL_MK=$(PACKAGE_DIR)/kernel/ -LINUXBIOS_MK=$(PACKAGE_DIR)/linuxbios/ga-2761gxdk-linuxbios.mk +LBV2_MK=$(PACKAGE_DIR)/linuxbios/ga-2761gxdk-linuxbios.mk # kernel configuration (for LAB) @@ -34,9 +34,9 @@ LINUXBIOS_VENDOR=gigabyte LINUXBIOS_BOARD=ga_2761gxdk -LINUXBIOS_CONFIG=Config.lb -LINUXBIOS_TDIR=ga_2761gxdk -LINUXBIOS_TAG=2908 +LBV2_CONFIG=Config.lb +LBV2_TDIR=ga_2761gxdk +LBV2_TAG=2908 LINUXBIOS_ROM_NAME=linuxbios.rom # FILO configuration Modified: buildrom-devel/config/platforms/m57sli.conf =================================================================== --- buildrom-devel/config/platforms/m57sli.conf 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/config/platforms/m57sli.conf 2008-01-11 17:38:23 UTC (rev 90) @@ -17,7 +17,7 @@ # Targets KERNEL_MK=$(PACKAGE_DIR)/kernel/m57sli-kernel.mk -LINUXBIOS_MK=$(PACKAGE_DIR)/linuxbios/m57sli-linuxbios.mk +LBV2_MK=$(PACKAGE_DIR)/linuxbios/m57sli-linuxbios.mk # kernel configuration (for LAB) @@ -38,9 +38,9 @@ LINUXBIOS_VENDOR=gigabyte LINUXBIOS_BOARD=m57sli -LINUXBIOS_CONFIG=Config.lb -LINUXBIOS_TDIR=m57sli -LINUXBIOS_TAG=2958 +LBV2_CONFIG=Config.lb +LBV2_TDIR=m57sli +LBV2_TAG=2958 LINUXBIOS_ROM_NAME=linuxbios.rom # FILO configuration Modified: buildrom-devel/config/platforms/msm800sev.conf =================================================================== --- buildrom-devel/config/platforms/msm800sev.conf 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/config/platforms/msm800sev.conf 2008-01-11 17:38:23 UTC (rev 90) @@ -13,7 +13,7 @@ # Targets KERNEL_MK=$(PACKAGE_DIR)/kernel/msm800sev-kernel.mk -LINUXBIOS_MK=$(PACKAGE_DIR)/linuxbios/msm800sev-linuxbios.mk +LBV2_MK=$(PACKAGE_DIR)/linuxbios/msm800sev-linuxbios.mk # kernel configuration (for LAB) @@ -28,9 +28,9 @@ LINUXBIOS_VENDOR=digitallogic LINUXBIOS_BOARD=msm800sev -LINUXBIOS_CONFIG=Config.lb -LINUXBIOS_TDIR=msm800sev -LINUXBIOS_TAG=2810 +LBV2_CONFIG=Config.lb +LBV2_TDIR=msm800sev +LBV2_TAG=2810 LINUXBIOS_ROM_NAME=linuxbios.rom # FILO configuration Modified: buildrom-devel/config/platforms/norwich.conf =================================================================== --- buildrom-devel/config/platforms/norwich.conf 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/config/platforms/norwich.conf 2008-01-11 17:38:23 UTC (rev 90) @@ -13,7 +13,7 @@ # Targets KERNEL_MK=$(PACKAGE_DIR)/kernel/norwich-kernel.mk -LINUXBIOS_MK=$(PACKAGE_DIR)/linuxbios/norwich-linuxbios.mk +LBV2_MK=$(PACKAGE_DIR)/linuxbios/norwich-linuxbios.mk # kernel configuration (for LAB) @@ -28,9 +28,9 @@ LINUXBIOS_VENDOR=amd LINUXBIOS_BOARD=norwich -LINUXBIOS_CONFIG=Config.lb -LINUXBIOS_TDIR=norwich -LINUXBIOS_TAG=2810 +LBV2_CONFIG=Config.lb +LBV2_TDIR=norwich +LBV2_TAG=2810 LINUXBIOS_ROM_NAME=norwich.rom # FILO configuration Modified: buildrom-devel/config/platforms/platforms.conf =================================================================== --- buildrom-devel/config/platforms/platforms.conf 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/config/platforms/platforms.conf 2008-01-11 17:38:23 UTC (rev 90) @@ -1,7 +1,7 @@ # This will include the correct configuration for the # selected platform -LINUXBIOS_MK=$(PACKAGE_DIR)/linuxbios/generic-linuxbios.mk +LBV2_MK=$(PACKAGE_DIR)/linuxbios/generic-linuxbios.mk ##Include the correct platform configuration Modified: buildrom-devel/config/platforms/qemu.conf =================================================================== --- buildrom-devel/config/platforms/qemu.conf 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/config/platforms/qemu.conf 2008-01-11 17:38:23 UTC (rev 90) @@ -12,7 +12,7 @@ # Targets KERNEL_MK=$(PACKAGE_DIR)/kernel/qemu-kernel.mk -LINUXBIOS_MK=$(PACKAGE_DIR)/linuxbios/qemu.mk +LBV2_MK=$(PACKAGE_DIR)/linuxbios/qemu.mk # kernel configuration (for LAB) @@ -23,21 +23,19 @@ # Etherboot configuration ETHERBOOT_ARCH=i386 -# LinuxBIOS configuration - -ifeq ($(CONFIG_LINUXBIOS_V3),y) -LINUXBIOS_TAG=HEAD -LINUXBIOS_V3_CONFIG=$(PACKAGE_DIR)/linuxbios/conf.v3/qemu.conf -LINUXBIOS_ROM_NAME=build/linuxbios.rom -else -LINUXBIOS_TAG=2950 -LINUXBIOS_CONFIG=Config.lb +# LinuxBIOSv2 configuration +LBV2_TAG=2950 +LBV2_CONFIG=Config.lb LINUXBIOS_ROM_NAME=qemu.rom -endif +# LinuxBIOS v3 configuration +LBV3_CONFIG=qemu-i386-defconfig +LBV3_TAG=HEAD +LBV3_ROM_NAME=linuxbios.rom + LINUXBIOS_VENDOR=emulation LINUXBIOS_BOARD=qemu-i386 -LINUXBIOS_TDIR=qemu-i386 +LBV2_TDIR=qemu-i386 # FILO configuration Modified: buildrom-devel/config/platforms/serengeti_cheetah.conf =================================================================== --- buildrom-devel/config/platforms/serengeti_cheetah.conf 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/config/platforms/serengeti_cheetah.conf 2008-01-11 17:38:23 UTC (rev 90) @@ -18,7 +18,7 @@ # Targets KERNEL_MK=$(PACKAGE_DIR)/kernel/serengeti_cheetah-kernel.mk -LINUXBIOS_MK=$(PACKAGE_DIR)/linuxbios/serengeti_cheetah.mk +LBV2_MK=$(PACKAGE_DIR)/linuxbios/serengeti_cheetah.mk # kernel configuration (for LAB) @@ -42,19 +42,19 @@ # LinuxBIOS configuration +LINUXBIOS_VENDOR=amd +LBV2_CONFIG=Config.lb + ifeq ($(CONFIG_PLATFORM_CHEETAH_FAM10),y) -LINUXBIOS_VENDOR=amd LINUXBIOS_BOARD=serengeti_cheetah_fam10 -LINUXBIOS_CONFIG=Config.lb -LINUXBIOS_TDIR=serengeti_cheetah_fam10 -LINUXBIOS_TAG=3018 +LBV2_TDIR=serengeti_cheetah_fam10 +LBV2_TAG=3018 LINUXBIOS_ROM_NAME=amd-cheetah-fam10.rom else -LINUXBIOS_VENDOR=amd LINUXBIOS_BOARD=serengeti_cheetah -LINUXBIOS_CONFIG=Config.lb -LINUXBIOS_TDIR=serengeti_cheetah -LINUXBIOS_TAG=2950 +LBV2_CONFIG=Config.lb +LBV2_TDIR=serengeti_cheetah +LBV2_TAG=2950 LINUXBIOS_ROM_NAME=serengeti_cheetah.rom endif Modified: buildrom-devel/config/platforms/supermicro-h8dmr.conf =================================================================== --- buildrom-devel/config/platforms/supermicro-h8dmr.conf 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/config/platforms/supermicro-h8dmr.conf 2008-01-11 17:38:23 UTC (rev 90) @@ -17,7 +17,7 @@ # Targets KERNEL_MK=$(PACKAGE_DIR)/kernel/supermicro-h8dmr-kernel.mk -LINUXBIOS_MK=$(PACKAGE_DIR)/linuxbios/supermicro-h8dmr-linuxbios.mk +LBV2_MK=$(PACKAGE_DIR)/linuxbios/supermicro-h8dmr-linuxbios.mk # kernel configuration (for LAB) @@ -38,9 +38,9 @@ LINUXBIOS_VENDOR=supermicro LINUXBIOS_BOARD=h8dmr -LINUXBIOS_CONFIG=Config.lb -LINUXBIOS_TDIR=h8dmr -LINUXBIOS_TAG=2996 +LBV2_CONFIG=Config.lb +LBV2_TDIR=h8dmr +LBV2_TAG=2996 LINUXBIOS_ROM_NAME=linuxbios.rom # FILO configuration Modified: buildrom-devel/config/platforms/tyan-s2882.conf =================================================================== --- buildrom-devel/config/platforms/tyan-s2882.conf 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/config/platforms/tyan-s2882.conf 2008-01-11 17:38:23 UTC (rev 90) @@ -17,7 +17,7 @@ # Targets KERNEL_MK=$(PACKAGE_DIR)/kernel/tyan-s2882-kernel.mk -LINUXBIOS_MK=$(PACKAGE_DIR)/linuxbios/tyan-s2882-linuxbios.mk +LBV2_MK=$(PACKAGE_DIR)/linuxbios/tyan-s2882-linuxbios.mk # kernel configuration (for LAB) @@ -38,9 +38,9 @@ LINUXBIOS_VENDOR=tyan LINUXBIOS_BOARD=s2882 -LINUXBIOS_CONFIG=Config.lb -LINUXBIOS_TDIR=s2882 -LINUXBIOS_TAG=2887 +LBV2_CONFIG=Config.lb +LBV2_TDIR=s2882 +LBV2_TAG=2887 LINUXBIOS_ROM_NAME=linuxbios.rom # FILO configuration Modified: buildrom-devel/config/platforms/tyan-s2891.conf =================================================================== --- buildrom-devel/config/platforms/tyan-s2891.conf 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/config/platforms/tyan-s2891.conf 2008-01-11 17:38:23 UTC (rev 90) @@ -17,7 +17,7 @@ # Targets KERNEL_MK=$(PACKAGE_DIR)/kernel/tyan-s2891-kernel.mk -LINUXBIOS_MK=$(PACKAGE_DIR)/linuxbios/tyan-s2891-linuxbios.mk +LBV2_MK=$(PACKAGE_DIR)/linuxbios/tyan-s2891-linuxbios.mk # kernel configuration (for LAB) @@ -38,9 +38,9 @@ LINUXBIOS_VENDOR=tyan LINUXBIOS_BOARD=s2891 -LINUXBIOS_CONFIG=Config.lb -LINUXBIOS_TDIR=s2891 -LINUXBIOS_TAG=2792 +LBV2_CONFIG=Config.lb +LBV2_TDIR=s2891 +LBV2_TAG=2792 LINUXBIOS_ROM_NAME=linuxbios.rom # FILO configuration Modified: buildrom-devel/packages/linuxbios/alix1c-linuxbios.mk =================================================================== --- buildrom-devel/packages/linuxbios/alix1c-linuxbios.mk 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/packages/linuxbios/alix1c-linuxbios.mk 2008-01-11 17:38:23 UTC (rev 90) @@ -1,37 +1,37 @@ # This is the Generic LinuxBIOS target ifeq ($(CONFIG_PLATFORM),y) -ifeq ($(LINUXBIOS_TAG),) +ifeq ($(LBV2_TAG),) $(error You need to specify a version to pull in your platform config) endif endif -LINUXBIOS_BASE_DIR=svn -LINUXBIOS_URL=svn://openbios.org/repos/trunk/LinuxBIOSv2 -LINUXBIOS_TARBALL=linuxbios-svn-$(LINUXBIOS_TAG).tar.gz -LINUXBIOS_PAYLOAD_TARGET=$(LINUXBIOS_BUILD_DIR)/payload.elf +LBV2_BASE_DIR=svn +LBV2_URL=svn://openbios.org/repos/trunk/LinuxBIOSv2 +LBV2_TARBALL=linuxbios-svn-$(LBV2_TAG).tar.gz +LBV2_PAYLOAD_TARGET=$(LBV2_BUILD_DIR)/payload.elf VSA_URL=http://www.amd.com/files/connectivitysolutions/geode/geode_lx/ -LINUXBIOS_VSA=lx_vsa.36k.bin +LBV2_VSA=lx_vsa.36k.bin TARGET_ROM = $(LINUXBIOS_VENDOR)-$(LINUXBIOS_BOARD).rom include $(PACKAGE_DIR)/linuxbios/linuxbios.inc -$(SOURCE_DIR)/$(LINUXBIOS_VSA): +$(SOURCE_DIR)/$(LBV2_VSA): @ echo "Fetching the VSA code..." - wget -P $(SOURCE_DIR) $(VSA_URL)/$(LINUXBIOS_VSA).gz -O $@ + wget -P $(SOURCE_DIR) $(VSA_URL)/$(LBV2_VSA).gz -O $@ -$(SOURCE_DIR)/$(LINUXBIOS_TARBALL): +$(SOURCE_DIR)/$(LBV2_TARBALL): @ echo "Fetching the LinuxBIOS code..." @ mkdir -p $(SOURCE_DIR)/linuxbios - @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \ - $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ - > $(LINUXBIOS_FETCH_LOG) 2>&1 + @ $(BIN_DIR)/fetchsvn.sh $(LBV2_URL) $(SOURCE_DIR)/linuxbios \ + $(LBV2_TAG) $(SOURCE_DIR)/$(LBV2_TARBALL) \ + > $(LBV2_FETCH_LOG) 2>&1 # Special rule - append the VSA -$(OUTPUT_DIR)/$(TARGET_ROM): $(LINUXBIOS_OUTPUT) $(SOURCE_DIR)/$(LINUXBIOS_VSA) +$(OUTPUT_DIR)/$(TARGET_ROM): $(LBV2_OUTPUT) $(SOURCE_DIR)/$(LBV2_VSA) @ mkdir -p $(OUTPUT_DIR) - @ cat $(SOURCE_DIR)/$(LINUXBIOS_VSA) $(LINUXBIOS_OUTPUT) > $@ + @ cat $(SOURCE_DIR)/$(LBV2_VSA) $(LBV2_OUTPUT) > $@ linuxbios: $(OUTPUT_DIR)/$(TARGET_ROM) linuxbios-clean: generic-linuxbios-clean Modified: buildrom-devel/packages/linuxbios/conf.v3/qemu.conf =================================================================== --- buildrom-devel/packages/linuxbios/conf.v3/qemu.conf 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/packages/linuxbios/conf.v3/qemu.conf 2008-01-11 17:38:23 UTC (rev 90) @@ -1,89 +0,0 @@ -# -# Automatically generated make config: don't edit -# LinuxBIOS version: 3.0.0 -# Wed Dec 5 11:10:31 2007 -# - -# -# General setup -# -# CONFIG_EXPERIMENTAL is not set -# CONFIG_EXPERT is not set -CONFIG_LOCALVERSION="" - -# -# Mainboard -# -# CONFIG_VENDOR_ADL is not set -# CONFIG_VENDOR_AMD is not set -# CONFIG_VENDOR_ARTECGROUP is not set -CONFIG_VENDOR_EMULATION=y -# CONFIG_VENDOR_PCENGINES is not set -CONFIG_MAINBOARD_NAME="emulation/qemu-x86" -CONFIG_MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID=0x15ad -CONFIG_MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID=0x1976 -CONFIG_BOARD_EMULATION_QEMU_X86=y -# CONFIG_LINUXBIOS_ROMSIZE_KB_128 is not set -# CONFIG_LINUXBIOS_ROMSIZE_KB_256 is not set -# CONFIG_LINUXBIOS_ROMSIZE_KB_512 is not set -# CONFIG_LINUXBIOS_ROMSIZE_KB_1024 is not set -CONFIG_LINUXBIOS_ROMSIZE_KB_2048=y -CONFIG_LINUXBIOS_ROMSIZE_KB=2048 -CONFIG_ARCH_X86=y -CONFIG_ARCH="x86" -CONFIG_CPU_I586=y -CONFIG_OPTION_TABLE=y - -# -# Compression -# -# CONFIG_COMPRESSION_LZMA is not set -# CONFIG_COMPRESSION_NRV2B is not set -# CONFIG_DEFAULT_COMPRESSION_LZMA is not set -# CONFIG_DEFAULT_COMPRESSION_NRV2B is not set -CONFIG_DEFAULT_COMPRESSION_NONE=y - -# -# Console -# -CONFIG_CONSOLE=y -CONFIG_CONSOLE_LOGLEVEL_8=y -# CONFIG_CONSOLE_LOGLEVEL_7 is not set -# CONFIG_CONSOLE_LOGLEVEL_6 is not set -# CONFIG_CONSOLE_LOGLEVEL_5 is not set -# CONFIG_CONSOLE_LOGLEVEL_4 is not set -# CONFIG_CONSOLE_LOGLEVEL_3 is not set -# CONFIG_CONSOLE_LOGLEVEL_2 is not set -# CONFIG_CONSOLE_LOGLEVEL_1 is not set -# CONFIG_CONSOLE_LOGLEVEL_0 is not set -CONFIG_DEFAULT_CONSOLE_LOGLEVEL=8 -CONFIG_CONSOLE_SERIAL=y -CONFIG_CONSOLE_SERIAL_COM1=y -# CONFIG_CONSOLE_SERIAL_COM2 is not set -CONFIG_CONSOLE_SERIAL_115200=y -# CONFIG_CONSOLE_SERIAL_57600 is not set -# CONFIG_CONSOLE_SERIAL_38400 is not set -# CONFIG_CONSOLE_SERIAL_19200 is not set -# CONFIG_CONSOLE_SERIAL_9600 is not set - -# -# Devices -# -CONFIG_PCI_OPTION_ROM_RUN=y -# CONFIG_PCI_OPTION_ROM_RUN_X86EMU is not set -CONFIG_PCI_OPTION_ROM_RUN_VM86=y -# CONFIG_PCI_OPTION_ROM_RUN_NONE is not set -# CONFIG_MULTIPLE_VGA_INIT is not set -# CONFIG_INITIALIZE_ONBOARD_VGA_FIRST is not set -CONFIG_NORTHBRIDGE_INTEL_I440BXEMULATION=y -CONFIG_SOUTHBRIDGE_INTEL_I82371EB=y -CONFIG_SUPERIO_WINBOND_W83627HF=y -CONFIG_NORTHBRIDGE_INTEL_I440BXEMULATION_RAMSIZE=32 - -# -# Payload -# -# CONFIG_PAYLOAD_PREPARSE_ELF is not set -CONFIG_PAYLOAD_ELF=y -# CONFIG_PAYLOAD_NONE is not set -CONFIG_PAYLOAD_FILE="payload.elf" Modified: buildrom-devel/packages/linuxbios/ga-2761gxdk-linuxbios.mk =================================================================== --- buildrom-devel/packages/linuxbios/ga-2761gxdk-linuxbios.mk 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/packages/linuxbios/ga-2761gxdk-linuxbios.mk 2008-01-11 17:38:23 UTC (rev 90) @@ -1,17 +1,17 @@ # This is the Generic LinuxBIOS target ifeq ($(CONFIG_PLATFORM),y) -ifeq ($(LINUXBIOS_TAG),) +ifeq ($(LBV2_TAG),) $(error You need to specify a version to pull in your platform config) endif endif -LINUXBIOS_PATCHES=$(PACKAGE_DIR)/linuxbios/patches/2761gxdk-fix-target.patch +LBV2_PATCHES=$(PACKAGE_DIR)/linuxbios/patches/2761gxdk-fix-target.patch -LINUXBIOS_BASE_DIR=svn -LINUXBIOS_URL=svn://linuxbios.org/repos/trunk/LinuxBIOSv2 -LINUXBIOS_TARBALL=linuxbios-svn-$(LINUXBIOS_TAG).tar.gz -LINUXBIOS_PAYLOAD_TARGET=$(LINUXBIOS_BUILD_DIR)/payload.elf +LBV2_BASE_DIR=svn +LBV2_URL=svn://linuxbios.org/repos/trunk/LinuxBIOSv2 +LBV2_TARBALL=linuxbios-svn-$(LBV2_TAG).tar.gz +LBV2_PAYLOAD_TARGET=$(LBV2_BUILD_DIR)/payload.elf TARGET_ROM = $(LINUXBIOS_VENDOR)-$(LINUXBIOS_BOARD).rom include $(PACKAGE_DIR)/linuxbios/linuxbios.inc @@ -22,16 +22,16 @@ OPTIONROM_ID = pci1039,6330 include $(PACKAGE_DIR)/linuxbios/optionroms.inc -$(SOURCE_DIR)/$(LINUXBIOS_TARBALL): +$(SOURCE_DIR)/$(LBV2_TARBALL): @ echo "Fetching the LinuxBIOS code..." @ mkdir -p $(SOURCE_DIR)/linuxbios - @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \ - $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ - > $(LINUXBIOS_FETCH_LOG) 2>&1 + @ $(BIN_DIR)/fetchsvn.sh $(LBV2_URL) $(SOURCE_DIR)/linuxbios \ + $(LBV2_TAG) $(SOURCE_DIR)/$(LBV2_TARBALL) \ + > $(LBV2_FETCH_LOG) 2>&1 -$(OUTPUT_DIR)/$(TARGET_ROM): $(LINUXBIOS_OUTPUT) $(SOURCE_DIR)/$(OPTIONROM_ID).rom +$(OUTPUT_DIR)/$(TARGET_ROM): $(LBV2_OUTPUT) $(SOURCE_DIR)/$(OPTIONROM_ID).rom @ mkdir -p $(OUTPUT_DIR) - @ cat $(SOURCE_DIR)/$(OPTIONROM_ID).rom $(LINUXBIOS_OUTPUT) > $@ + @ cat $(SOURCE_DIR)/$(OPTIONROM_ID).rom $(LBV2_OUTPUT) > $@ linuxbios: $(OUTPUT_DIR)/$(TARGET_ROM) linuxbios-clean: generic-linuxbios-clean Modified: buildrom-devel/packages/linuxbios/generic-linuxbios.mk =================================================================== --- buildrom-devel/packages/linuxbios/generic-linuxbios.mk 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/packages/linuxbios/generic-linuxbios.mk 2008-01-11 17:38:23 UTC (rev 90) @@ -1,19 +1,19 @@ # This is the Generic LinuxBIOS target ifeq ($(CONFIG_PLATFORM),y) -ifeq ($(LINUXBIOS_TAG),) +ifeq ($(LBV2_TAG),) $(error You need to specify a version to pull in your platform config) endif endif -LINUXBIOS_BASE_DIR=svn -LINUXBIOS_URL=svn://linuxbios.org/repos/trunk/LinuxBIOSv2 -LINUXBIOS_TARBALL=linuxbios-svn-$(LINUXBIOS_TAG).tar.gz -LINUXBIOS_PAYLOAD_TARGET=$(LINUXBIOS_BUILD_DIR)/payload.elf +LBV2_BASE_DIR=svn +LBV2_URL=svn://linuxbios.org/repos/trunk/LinuxBIOSv2 +LBV2_TARBALL=linuxbios-svn-$(LBV2_TAG).tar.gz +LBV2_PAYLOAD_TARGET=$(LBV2_BUILD_DIR)/payload.elf TARGET_ROM = $(LINUXBIOS_VENDOR)-$(LINUXBIOS_BOARD).rom # This is the list of components that comprise the ROM (excluding the payload) -LINUXBIOS_COMPONENTS = $(LINUXBIOS_OUTPUT) +LBV2_COMPONENTS = $(LBV2_OUTPUT) include $(PACKAGE_DIR)/linuxbios/linuxbios.inc @@ -23,19 +23,19 @@ include $(PACKAGE_DIR)/linuxbios/optionroms.inc # Add it to the front of the list so it is prepended to the LinuxBIOS output -LINUXBIOS_COMPONENTS = $(SOURCE_DIR)/$(OPTIONROM_ID).rom $(LINUXBIOS_COMPONENTS) +LBV2_COMPONENTS = $(SOURCE_DIR)/$(OPTIONROM_ID).rom $(LBV2_COMPONENTS) endif -$(SOURCE_DIR)/$(LINUXBIOS_TARBALL): +$(SOURCE_DIR)/$(LBV2_TARBALL): @ echo "Fetching the LinuxBIOS code..." @ mkdir -p $(SOURCE_DIR)/linuxbios - @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \ - $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ - > $(LINUXBIOS_FETCH_LOG) 2>&1 + @ $(BIN_DIR)/fetchsvn.sh $(LBV2_URL) $(SOURCE_DIR)/linuxbios \ + $(LBV2_TAG) $(SOURCE_DIR)/$(LBV2_TARBALL) \ + > $(LBV2_FETCH_LOG) 2>&1 -$(OUTPUT_DIR)/$(TARGET_ROM): $(LINUXBIOS_COMPONENTS) +$(OUTPUT_DIR)/$(TARGET_ROM): $(LBV2_COMPONENTS) @ mkdir -p $(OUTPUT_DIR) - @ cat $(LINUXBIOS_COMPONENTS) > $@ + @ cat $(LBV2_COMPONENTS) > $@ linuxbios: $(OUTPUT_DIR)/$(TARGET_ROM) linuxbios-clean: generic-linuxbios-clean Modified: buildrom-devel/packages/linuxbios/linuxbios.inc =================================================================== --- buildrom-devel/packages/linuxbios/linuxbios.inc 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/packages/linuxbios/linuxbios.inc 2008-01-11 17:38:23 UTC (rev 90) @@ -7,111 +7,94 @@ ifeq ($(LINUXBIOS_BOARD),) $(error No LinuxBIOS board specified) endif -ifeq ($(CONFIG_LINUXBIOS_V3),y) - ifeq ($(LINUXBIOS_V3_CONFIG),) - $(error No LinuxBIOSv3 config specified) - endif -else - ifeq ($(LINUXBIOS_CONFIG),) - $(error No LinuxBIOS config specified) - endif +ifeq ($(LBV2_CONFIG),) +$(error No LinuxBIOS config specified) endif -ifeq ($(LINUXBIOS_TDIR),) +ifeq ($(LBV2_TDIR),) $(error No LinuxBIOS TDIR specified) endif endif -LINUXBIOS_OUTPUT=$(LINUXBIOS_BUILD_DIR)/$(LINUXBIOS_ROM_NAME) -LINUXBIOS_DIR=$(BUILD_DIR)/linuxbios +LBV2_OUTPUT=$(LBV2_BUILD_DIR)/$(LBV2_ROM_NAME) +LBV2_DIR=$(BUILD_DIR)/linuxbios # If the user wanted to override the build directory - obey that now ifeq ($(CONFIG_LB_USE_BUILD),y) -LINUXBIOS_SRC_DIR=$(subst ",,$(CONFIG_LB_BUILDDIR)) +LBV2_SRC_DIR=$(subst ",,$(CONFIG_LB_BUILDDIR)) else -LINUXBIOS_SRC_DIR=$(LINUXBIOS_DIR)/$(LINUXBIOS_BASE_DIR) +LBV2_SRC_DIR=$(LBV2_DIR)/$(LBV2_BASE_DIR) endif -LINUXBIOS_TARGET_DIR=$(LINUXBIOS_SRC_DIR)/targets/ -LINUXBIOS_TARGET_NAME=$(LINUXBIOS_VENDOR)/$(LINUXBIOS_BOARD) -LINUXBIOS_CONFIG_NAME=$(LINUXBIOS_TARGET_NAME)/$(LINUXBIOS_CONFIG) +LBV2_TARGET_DIR=$(LBV2_SRC_DIR)/targets/ +LBV2_TARGET_NAME=$(LINUXBIOS_VENDOR)/$(LINUXBIOS_BOARD) +LBV2_CONFIG_NAME=$(LBV2_TARGET_NAME)/$(LBV2_CONFIG) -ifeq ($(CONFIG_LINUXBIOS_V3),y) -LINUXBIOS_BUILD_DIR=$(LINUXBIOS_SRC_DIR) -else -LINUXBIOS_BUILD_DIR=$(LINUXBIOS_TARGET_DIR)/$(LINUXBIOS_TARGET_NAME)/$(LINUXBIOS_TDIR) -endif +LBV2_BUILD_DIR=$(LBV2_TARGET_DIR)/$(LBV2_TARGET_NAME)/$(LBV2_TDIR) -LINUXBIOS_STAMP_DIR=$(LINUXBIOS_DIR)/stamps -LINUXBIOS_LOG_DIR=$(LINUXBIOS_DIR)/logs +LBV2_STAMP_DIR=$(LBV2_DIR)/stamps +LBV2_LOG_DIR=$(LBV2_DIR)/logs ifeq ($(CONFIG_VERBOSE),y) -LINUXBIOS_FETCH_LOG=/dev/stdout -LINUXBIOS_CONFIG_LOG=/dev/stdout -LINUXBIOS_BUILD_LOG=/dev/stdout -LINUXBIOS_INSTALL_LOG=/dev/stdout +LBV2_FETCH_LOG=/dev/stdout +LBV2_CONFIG_LOG=/dev/stdout +LBV2_BUILD_LOG=/dev/stdout +LBV2_INSTALL_LOG=/dev/stdout else -LINUXBIOS_FETCH_LOG=$(LINUXBIOS_LOG_DIR)/fetch.log -LINUXBIOS_BUILD_LOG=$(LINUXBIOS_LOG_DIR)/build.log -LINUXBIOS_CONFIG_LOG=$(LINUXBIOS_LOG_DIR)/config.log -LINUXBIOS_INSTALL_LOG=$(LINUXBIOS_LOG_DIR)/install.log +LBV2_FETCH_LOG=$(LBV2_LOG_DIR)/fetch.log +LBV2_BUILD_LOG=$(LBV2_LOG_DIR)/build.log +LBV2_CONFIG_LOG=$(LBV2_LOG_DIR)/config.log +LBV2_INSTALL_LOG=$(LBV2_LOG_DIR)/install.log endif # This allows us to skip the unpack/patch/configure stage ifeq ($(CONFIG_LB_USE_BUILD),y) -LINUXBIOS_DIR_TARGET= +LBV2_DIR_TARGET= else -LINUXBIOS_DIR_TARGET=$(LINUXBIOS_STAMP_DIR)/.configured +LBV2_DIR_TARGET=$(LBV2_STAMP_DIR)/.configured endif -$(LINUXBIOS_PAYLOAD_TARGET): $(PAYLOAD_TARGET) +$(LBV2_PAYLOAD_TARGET): $(PAYLOAD_TARGET) @ cp $< $@ -$(LINUXBIOS_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) +$(LBV2_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(LBV2_TARBALL) @ echo "Unpacking LinuxBIOS..." - @ tar -C $(LINUXBIOS_DIR) -zxf $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) + @ tar -C $(LBV2_DIR) -zxf $(SOURCE_DIR)/$(LBV2_TARBALL) @ touch $@ -$(LINUXBIOS_STAMP_DIR)/.patched: $(LINUXBIOS_STAMP_DIR)/.unpacked +$(LBV2_STAMP_DIR)/.patched: $(LBV2_STAMP_DIR)/.unpacked @ echo "Patching LinuxBIOS..." - @ $(BIN_DIR)/doquilt.sh $(LINUXBIOS_SRC_DIR) $(LINUXBIOS_PATCHES) + @ $(BIN_DIR)/doquilt.sh $(LBV2_SRC_DIR) $(LBV2_PATCHES) @ touch $@ -$(LINUXBIOS_STAMP_DIR)/.configured: $(LINUXBIOS_STAMP_DIR)/.patched -ifeq ($(CONFIG_LINUXBIOS_V3),y) - @ echo "Configuring v3..." - @ cp $(LINUXBIOS_V3_CONFIG) $(LINUXBIOS_SRC_DIR)/.config - @ make -C $(LINUXBIOS_SRC_DIR) oldconfig > $(LINUXBIOS_CONFIG_LOG) 2>&1 - @ touch $@ -else +$(LBV2_STAMP_DIR)/.configured: $(LBV2_STAMP_DIR)/.patched @ echo "Building target..." - @( cd $(LINUXBIOS_TARGET_DIR); \ - ./buildtarget $(LINUXBIOS_CONFIG_NAME) > $(LINUXBIOS_CONFIG_LOG) 2>&1) + @( cd $(LBV2_TARGET_DIR); \ + ./buildtarget $(LBV2_CONFIG_NAME) > $(LBV2_CONFIG_LOG) 2>&1) @ touch $@ -endif -$(LINUXBIOS_STAMP_DIR) $(LINUXBIOS_LOG_DIR): +$(LBV2_STAMP_DIR) $(LBV2_LOG_DIR): @ mkdir -p $@ -$(LINUXBIOS_OUTPUT): $(LINUXBIOS_STAMP_DIR) $(LINUXBIOS_LOG_DIR) $(LINUXBIOS_DIR_TARGET) $(LINUXBIOS_PAYLOAD_TARGET) +$(LBV2_OUTPUT): $(LBV2_STAMP_DIR) $(LBV2_LOG_DIR) $(LBV2_DIR_TARGET) $(LBV2_PAYLOAD_TARGET) @ echo "Building linuxbios..." @ (export CPU_OPT="$(STACKPROTECT)"; \ - make -C $(LINUXBIOS_BUILD_DIR) > $(LINUXBIOS_BUILD_LOG) 2>&1) + make -C $(LBV2_BUILD_DIR) > $(LBV2_BUILD_LOG) 2>&1) generic-linuxbios-clean: @ echo "Cleaning linuxbios..." - @ rm -f $(LINUXBIOS_PAYLOAD_TARGET) - @ if [ -d $(LINUXBIOS_BUILD_DIR) ];then \ - $(MAKE) -C $(LINUXBIOS_BUILD_DIR) clean > /dev/null 2>&1; \ + @ rm -f $(LBV2_PAYLOAD_TARGET) + @ if [ -d $(LBV2_BUILD_DIR) ];then \ + $(MAKE) -C $(LBV2_BUILD_DIR) clean > /dev/null 2>&1; \ fi - @ rm -f $(LINUXBIOS_OUTPUT) + @ rm -f $(LBV2_OUTPUT) generic-linuxbios-distclean: @ if [ "$(CONFIG_LB_USE_BUILD)" = "y" ]; then \ echo "Cleaning linuxbios build..."; \ - $(MAKE) -C $(LINUXBIOS_BUILD_DIR) clean > /dev/null 2>&1; \ - rm -f $(LINUXBIOS_OUTPUT); \ + $(MAKE) -C $(LBV2_BUILD_DIR) clean > /dev/null 2>&1; \ + rm -f $(LBV2_OUTPUT); \ fi - @ rm -rf $(LINUXBIOS_DIR)/* + @ rm -rf $(LBV2_DIR)/* Modified: buildrom-devel/packages/linuxbios/m57sli-linuxbios.mk =================================================================== --- buildrom-devel/packages/linuxbios/m57sli-linuxbios.mk 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/packages/linuxbios/m57sli-linuxbios.mk 2008-01-11 17:38:23 UTC (rev 90) @@ -1,48 +1,48 @@ # This is the Generic LinuxBIOS target ifeq ($(CONFIG_PLATFORM),y) -ifeq ($(LINUXBIOS_TAG),) +ifeq ($(LBV2_TAG),) $(error You need to specify a version to pull in your platform config) endif endif -LINUXBIOS_PATCHES= +LBV2_PATCHES= ifeq ($(CONFIG_PAYLOAD_FILO),y) - LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/m57sli-filo-and-etherboot-Config.lb.patch + LBV2_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/m57sli-filo-and-etherboot-Config.lb.patch endif ifeq ($(CONFIG_PAYLOAD_ETHERBOOT),y) - LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/m57sli-filo-and-etherboot-Config.lb.patch + LBV2_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/m57sli-filo-and-etherboot-Config.lb.patch endif ifeq ($(CONFIG_PAYLOAD_KERNEL),y) - LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/m57sli-kernel-and-lab-Config.lb.patch + LBV2_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/m57sli-kernel-and-lab-Config.lb.patch endif ifeq ($(CONFIG_PAYLOAD_LAB),y) - LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/m57sli-kernel-and-lab-Config.lb.patch + LBV2_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/m57sli-kernel-and-lab-Config.lb.patch endif -LINUXBIOS_BASE_DIR=svn -LINUXBIOS_URL=svn://linuxbios.org/repos/trunk/LinuxBIOSv2 -LINUXBIOS_TARBALL=linuxbios-svn-$(LINUXBIOS_TAG).tar.gz -LINUXBIOS_PAYLOAD_TARGET=$(LINUXBIOS_BUILD_DIR)/payload.elf +LBV2_BASE_DIR=svn +LBV2_URL=svn://linuxbios.org/repos/trunk/LinuxBIOSv2 +LBV2_TARBALL=linuxbios-svn-$(LBV2_TAG).tar.gz +LBV2_PAYLOAD_TARGET=$(LBV2_BUILD_DIR)/payload.elf TARGET_ROM = $(LINUXBIOS_VENDOR)-$(LINUXBIOS_BOARD).rom include $(PACKAGE_DIR)/linuxbios/linuxbios.inc -$(SOURCE_DIR)/$(LINUXBIOS_TARBALL): +$(SOURCE_DIR)/$(LBV2_TARBALL): @ echo "Fetching the LinuxBIOS code..." @ mkdir -p $(SOURCE_DIR)/linuxbios - @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \ - $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ - > $(LINUXBIOS_FETCH_LOG) 2>&1 + @ $(BIN_DIR)/fetchsvn.sh $(LBV2_URL) $(SOURCE_DIR)/linuxbios \ + $(LBV2_TAG) $(SOURCE_DIR)/$(LBV2_TARBALL) \ + > $(LBV2_FETCH_LOG) 2>&1 -$(OUTPUT_DIR)/$(TARGET_ROM): $(LINUXBIOS_OUTPUT) +$(OUTPUT_DIR)/$(TARGET_ROM): $(LBV2_OUTPUT) @ mkdir -p $(OUTPUT_DIR) - @ cat $(LINUXBIOS_OUTPUT) > $@ + @ cat $(LBV2_OUTPUT) > $@ linuxbios: $(OUTPUT_DIR)/$(TARGET_ROM) linuxbios-clean: generic-linuxbios-clean Modified: buildrom-devel/packages/linuxbios/msm800sev-linuxbios.mk =================================================================== --- buildrom-devel/packages/linuxbios/msm800sev-linuxbios.mk 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/packages/linuxbios/msm800sev-linuxbios.mk 2008-01-11 17:38:23 UTC (rev 90) @@ -1,37 +1,37 @@ # This is the Generic LinuxBIOS target ifeq ($(CONFIG_PLATFORM),y) -ifeq ($(LINUXBIOS_TAG),) +ifeq ($(LBV2_TAG),) $(error You need to specify a version to pull in your platform config) endif endif -LINUXBIOS_BASE_DIR=svn -LINUXBIOS_URL=svn://openbios.org/repos/trunk/LinuxBIOSv2 -LINUXBIOS_TARBALL=linuxbios-svn-$(LINUXBIOS_TAG).tar.gz -LINUXBIOS_PAYLOAD_TARGET=$(LINUXBIOS_BUILD_DIR)/payload.elf +LBV2_BASE_DIR=svn +LBV2_URL=svn://openbios.org/repos/trunk/LinuxBIOSv2 +LBV2_TARBALL=linuxbios-svn-$(LBV2_TAG).tar.gz +LBV2_PAYLOAD_TARGET=$(LBV2_BUILD_DIR)/payload.elf VSA_URL=http://www.amd.com/files/connectivitysolutions/geode/geode_lx/ -LINUXBIOS_VSA=lx_vsa.36k.bin +LBV2_VSA=lx_vsa.36k.bin TARGET_ROM = $(LINUXBIOS_VENDOR)-$(LINUXBIOS_BOARD).rom include $(PACKAGE_DIR)/linuxbios/linuxbios.inc -$(SOURCE_DIR)/$(LINUXBIOS_VSA): +$(SOURCE_DIR)/$(LBV2_VSA): @ echo "Fetching the VSA code..." - wget -P $(SOURCE_DIR) $(VSA_URL)/$(LINUXBIOS_VSA).gz -O $@ + wget -P $(SOURCE_DIR) $(VSA_URL)/$(LBV2_VSA).gz -O $@ -$(SOURCE_DIR)/$(LINUXBIOS_TARBALL): +$(SOURCE_DIR)/$(LBV2_TARBALL): @ echo "Fetching the LinuxBIOS code..." @ mkdir -p $(SOURCE_DIR)/linuxbios - @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \ - $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ - > $(LINUXBIOS_FETCH_LOG) 2>&1 + @ $(BIN_DIR)/fetchsvn.sh $(LBV2_URL) $(SOURCE_DIR)/linuxbios \ + $(LBV2_TAG) $(SOURCE_DIR)/$(LBV2_TARBALL) \ + > $(LBV2_FETCH_LOG) 2>&1 # Special rule - append the VSA -$(OUTPUT_DIR)/$(TARGET_ROM): $(LINUXBIOS_OUTPUT) $(SOURCE_DIR)/$(LINUXBIOS_VSA) +$(OUTPUT_DIR)/$(TARGET_ROM): $(LBV2_OUTPUT) $(SOURCE_DIR)/$(LBV2_VSA) @ mkdir -p $(OUTPUT_DIR) - @ cat $(SOURCE_DIR)/$(LINUXBIOS_VSA) $(LINUXBIOS_OUTPUT) > $@ + @ cat $(SOURCE_DIR)/$(LBV2_VSA) $(LBV2_OUTPUT) > $@ linuxbios: $(OUTPUT_DIR)/$(TARGET_ROM) linuxbios-clean: generic-linuxbios-clean Modified: buildrom-devel/packages/linuxbios/norwich-linuxbios.mk =================================================================== --- buildrom-devel/packages/linuxbios/norwich-linuxbios.mk 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/packages/linuxbios/norwich-linuxbios.mk 2008-01-11 17:38:23 UTC (rev 90) @@ -1,37 +1,40 @@ # This is the Generic LinuxBIOS target +echo $(LBV2_TAG) ifeq ($(CONFIG_PLATFORM),y) -ifeq ($(LINUXBIOS_TAG),) +ifeq ($(LBV2_TAG),) $(error You need to specify a version to pull in your platform config) +else +$(warning You specified $(LBV2_TAG) a version to pull in your platform config) endif endif -LINUXBIOS_BASE_DIR=svn -LINUXBIOS_URL=svn://openbios.org/repos/trunk/LinuxBIOSv2 -LINUXBIOS_TARBALL=linuxbios-svn-$(LINUXBIOS_TAG).tar.gz -LINUXBIOS_PAYLOAD_TARGET=$(LINUXBIOS_BUILD_DIR)/payload.elf +LBV2_BASE_DIR=svn +LBV2_URL=svn://openbios.org/repos/trunk/LinuxBIOSv2 +LBV2_TARBALL=linuxbios-svn-$(LBV2_TAG).tar.gz +LBV2_PAYLOAD_TARGET=$(LBV2_BUILD_DIR)/payload.elf VSA_URL=http://www.amd.com/files/connectivitysolutions/geode/geode_lx/ -LINUXBIOS_VSA=lx_vsa.36k.bin +LBV2_VSA=lx_vsa.36k.bin TARGET_ROM = $(LINUXBIOS_VENDOR)-$(LINUXBIOS_BOARD).rom include $(PACKAGE_DIR)/linuxbios/linuxbios.inc -$(SOURCE_DIR)/$(LINUXBIOS_VSA): +$(SOURCE_DIR)/$(LBV2_VSA): @ echo "Fetching the VSA code..." - wget -P $(SOURCE_DIR) $(VSA_URL)/$(LINUXBIOS_VSA).gz -O $@ + wget -P $(SOURCE_DIR) $(VSA_URL)/$(LBV2_VSA).gz -O $@ -$(SOURCE_DIR)/$(LINUXBIOS_TARBALL): - @ echo "Fetching the LinuxBIOS code..." +$(SOURCE_DIR)/$(LBV2_TARBALL): + @ echo "Fetching the LinuxBIOS rev $(LBV2_TAG) code..." @ mkdir -p $(SOURCE_DIR)/linuxbios - @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \ - $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ - > $(LINUXBIOS_FETCH_LOG) 2>&1 + @ $(BIN_DIR)/fetchsvn.sh $(LBV2_URL) $(SOURCE_DIR)/linuxbios \ + $(LBV2_TAG) $(SOURCE_DIR)/$(LBV2_TARBALL) \ + > $(LBV2_FETCH_LOG) 2>&1 # Special rule - append the VSA -$(OUTPUT_DIR)/$(TARGET_ROM): $(LINUXBIOS_OUTPUT) $(SOURCE_DIR)/$(LINUXBIOS_VSA) +$(OUTPUT_DIR)/$(TARGET_ROM): $(LBV2_OUTPUT) $(SOURCE_DIR)/$(LBV2_VSA) @ mkdir -p $(OUTPUT_DIR) - @ cat $(SOURCE_DIR)/$(LINUXBIOS_VSA) $(LINUXBIOS_OUTPUT) > $@ + @ cat $(SOURCE_DIR)/$(LBV2_VSA) $(LBV2_OUTPUT) > $@ linuxbios: $(OUTPUT_DIR)/$(TARGET_ROM) linuxbios-clean: generic-linuxbios-clean Modified: buildrom-devel/packages/linuxbios/qemu.mk =================================================================== --- buildrom-devel/packages/linuxbios/qemu.mk 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/packages/linuxbios/qemu.mk 2008-01-11 17:38:23 UTC (rev 90) @@ -1,44 +1,37 @@ # This is the QEMU LinuxBIOS target ifeq ($(CONFIG_PLATFORM),y) -ifeq ($(LINUXBIOS_TAG),) +ifeq ($(LBV2_TAG),) $(error You need to specify a version to pull in your platform config) endif endif -LINUXBIOS_PATCHES = +LBV2_PATCHES = - - -LINUXBIOS_BASE_DIR=svn +LBV2_BASE_DIR=svn TARGET_ROM = $(LINUXBIOS_VENDOR)-$(LINUXBIOS_BOARD).rom -LINUXBIOS_PAYLOAD_TARGET=$(LINUXBIOS_BUILD_DIR)/payload.elf +LBV2_PAYLOAD_TARGET=$(LBV2_BUILD_DIR)/payload.elf -ifeq ($(CONFIG_LINUXBIOS_V3),y) - LINUXBIOS_URL=svn://linuxbios.org/repository/LinuxBIOSv3 - LINUXBIOS_TARBALL=linuxbiosv3-svn-$(LINUXBIOS_TAG).tar.gz - LINUXBIOS_SVN_DIR=$(SOURCE_DIR)/linuxbiosv3 +ifeq ($(CONFIG_PAYLOAD_LAB),y) +LBV2_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/qemu-lab.patch else - ifeq ($(CONFIG_PAYLOAD_LAB),y) - LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/qemu-lab.patch - else - LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/qemu-payload.patch - endif - LINUXBIOS_URL=svn://linuxbios.org/repos/trunk/LinuxBIOSv2 - LINUXBIOS_TARBALL=linuxbios-svn-$(LINUXBIOS_TAG).tar.gz - LINUXBIOS_SVN_DIR=$(SOURCE_DIR)/linuxbios +LBV2_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/qemu-payload.patch endif +LBV2_URL=svn://linuxbios.org/repos/trunk/LinuxBIOSv2 +LBV2_TARBALL=linuxbios-svn-$(LBV2_TAG).tar.gz +LBV2_SVN_DIR=$(SOURCE_DIR)/linuxbios + include $(PACKAGE_DIR)/linuxbios/linuxbios.inc -$(SOURCE_DIR)/$(LINUXBIOS_TARBALL): +$(SOURCE_DIR)/$(LBV2_TARBALL): @ echo "Fetching the LinuxBIOS code..." @ mkdir -p $(SOURCE_DIR)/linuxbios - @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(LINUXBIOS_SVN_DIR) \ - $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ - > $(LINUXBIOS_FETCH_LOG) 2>&1 + @ $(BIN_DIR)/fetchsvn.sh $(LBV2_URL) $(LBV2_SVN_DIR) \ + $(LBV2_TAG) $(SOURCE_DIR)/$(LBV2_TARBALL) \ + > $(LBV2_FETCH_LOG) 2>&1 -$(OUTPUT_DIR)/$(TARGET_ROM): $(LINUXBIOS_OUTPUT) +$(OUTPUT_DIR)/$(TARGET_ROM): $(LBV2_OUTPUT) @ mkdir -p $(OUTPUT_DIR) @ cp $< $@ Modified: buildrom-devel/packages/linuxbios/serengeti_cheetah.mk =================================================================== --- buildrom-devel/packages/linuxbios/serengeti_cheetah.mk 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/packages/linuxbios/serengeti_cheetah.mk 2008-01-11 17:38:23 UTC (rev 90) @@ -1,12 +1,12 @@ # This is the Generic LinuxBIOS target ifeq ($(CONFIG_PLATFORM),y) -ifeq ($(LINUXBIOS_TAG),) +ifeq ($(LBV2_TAG),) $(error You need to specify a version to pull in your platform config) endif endif -LINUXBIOS_PATCHES = +LBV2_PATCHES = # Make sure we have the tools we need to accomplish this HAVE_IASL:=$(call find-tool,iasl) @@ -18,38 +18,38 @@ ifeq ($(CONFIG_PLATFORM_CHEETAH_FAM10),y) ifeq ($(CONFIG_PAYLOAD_LAB),y) - LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/serengeti_cheetah_fam10-lab.patch + LBV2_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/serengeti_cheetah_fam10-lab.patch endif endif ifeq ($(CONFIG_PLATFORM_SERENGETI_CHEETAH),y) ifeq ($(CONFIG_PAYLOAD_LAB),y) - LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/serengeti_cheetah-lab.patch + LBV2_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/serengeti_cheetah-lab.patch else - LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/serengeti_cheetah-payload.patch + LBV2_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/serengeti_cheetah-payload.patch endif ifeq ($(CONFIG_SIMNOW),y) -LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/simnow.patch +LBV2_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/simnow.patch endif endif -LINUXBIOS_BASE_DIR=svn -LINUXBIOS_URL=svn://linuxbios.org/repos/trunk/LinuxBIOSv2 -LINUXBIOS_TARBALL=linuxbios-svn-$(LINUXBIOS_TAG).tar.gz -LINUXBIOS_PAYLOAD_TARGET=$(LINUXBIOS_BUILD_DIR)/payload.elf +LBV2_BASE_DIR=svn +LBV2_URL=svn://linuxbios.org/repos/trunk/LinuxBIOSv2 +LBV2_TARBALL=linuxbios-svn-$(LBV2_TAG).tar.gz +LBV2_PAYLOAD_TARGET=$(LBV2_BUILD_DIR)/payload.elf TARGET_ROM = $(LINUXBIOS_VENDOR)-$(LINUXBIOS_BOARD).rom include $(PACKAGE_DIR)/linuxbios/linuxbios.inc -$(SOURCE_DIR)/$(LINUXBIOS_TARBALL): +$(SOURCE_DIR)/$(LBV2_TARBALL): @ echo "Fetching the LinuxBIOS code..." @ mkdir -p $(SOURCE_DIR)/linuxbios - @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \ - $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ - > $(LINUXBIOS_FETCH_LOG) 2>&1 + @ $(BIN_DIR)/fetchsvn.sh $(LBV2_URL) $(SOURCE_DIR)/linuxbios \ + $(LBV2_TAG) $(SOURCE_DIR)/$(LBV2_TARBALL) \ + > $(LBV2_FETCH_LOG) 2>&1 -$(OUTPUT_DIR)/$(TARGET_ROM): $(LINUXBIOS_OUTPUT) +$(OUTPUT_DIR)/$(TARGET_ROM): $(LBV2_OUTPUT) @ mkdir -p $(OUTPUT_DIR) @ cp $< $@ Modified: buildrom-devel/packages/linuxbios/supermicro-h8dmr-linuxbios.mk =================================================================== --- buildrom-devel/packages/linuxbios/supermicro-h8dmr-linuxbios.mk 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/packages/linuxbios/supermicro-h8dmr-linuxbios.mk 2008-01-11 17:38:23 UTC (rev 90) @@ -1,48 +1,48 @@ # This is the Generic LinuxBIOS target ifeq ($(CONFIG_PLATFORM),y) -ifeq ($(LINUXBIOS_TAG),) +ifeq ($(LBV2_TAG),) $(error You need to specify a version to pull in your platform config) endif endif -LINUXBIOS_PATCHES = +LBV2_PATCHES = ifeq ($(CONFIG_PAYLOAD_FILO),y) - LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/supermicro-h8dmr-filo-and-etherboot-Config.lb.patch + LBV2_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/supermicro-h8dmr-filo-and-etherboot-Config.lb.patch endif ifeq ($(CONFIG_PAYLOAD_ETHERBOOT),y) - LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/supermicro-h8dmr-filo-and-etherboot-Config.lb.patch + LBV2_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/supermicro-h8dmr-filo-and-etherboot-Config.lb.patch endif ifeq ($(CONFIG_PAYLOAD_KERNEL),y) - LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/supermicro-h8dmr-kernel-and-lab-Config.lb.patch + LBV2_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/supermicro-h8dmr-kernel-and-lab-Config.lb.patch endif ifeq ($(CONFIG_PAYLOAD_LAB),y) - LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/supermicro-h8dmr-kernel-and-lab-Config.lb.patch + LBV2_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/supermicro-h8dmr-kernel-and-lab-Config.lb.patch endif -LINUXBIOS_BASE_DIR=svn -LINUXBIOS_URL=svn://linuxbios.org/repos/trunk/LinuxBIOSv2 -LINUXBIOS_TARBALL=linuxbios-svn-$(LINUXBIOS_TAG).tar.gz -LINUXBIOS_PAYLOAD_TARGET=$(LINUXBIOS_BUILD_DIR)/payload.elf +LBV2_BASE_DIR=svn +LBV2_URL=svn://linuxbios.org/repos/trunk/LinuxBIOSv2 +LBV2_TARBALL=linuxbios-svn-$(LBV2_TAG).tar.gz +LBV2_PAYLOAD_TARGET=$(LBV2_BUILD_DIR)/payload.elf TARGET_ROM = $(LINUXBIOS_VENDOR)-$(LINUXBIOS_BOARD).rom include $(PACKAGE_DIR)/linuxbios/linuxbios.inc -$(SOURCE_DIR)/$(LINUXBIOS_TARBALL): +$(SOURCE_DIR)/$(LBV2_TARBALL): @ echo "Fetching the LinuxBIOS code..." @ mkdir -p $(SOURCE_DIR)/linuxbios - @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \ - $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ - > $(LINUXBIOS_FETCH_LOG) 2>&1 + @ $(BIN_DIR)/fetchsvn.sh $(LBV2_URL) $(SOURCE_DIR)/linuxbios \ + $(LBV2_TAG) $(SOURCE_DIR)/$(LBV2_TARBALL) \ + > $(LBV2_FETCH_LOG) 2>&1 -$(OUTPUT_DIR)/$(TARGET_ROM): $(LINUXBIOS_OUTPUT) +$(OUTPUT_DIR)/$(TARGET_ROM): $(LBV2_OUTPUT) @ mkdir -p $(OUTPUT_DIR) - @ cat $(LINUXBIOS_OUTPUT) > $@ + @ cat $(LBV2_OUTPUT) > $@ linuxbios: $(OUTPUT_DIR)/$(TARGET_ROM) linuxbios-clean: generic-linuxbios-clean Modified: buildrom-devel/packages/linuxbios/tyan-s2882-linuxbios.mk =================================================================== --- buildrom-devel/packages/linuxbios/tyan-s2882-linuxbios.mk 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/packages/linuxbios/tyan-s2882-linuxbios.mk 2008-01-11 17:38:23 UTC (rev 90) @@ -1,44 +1,44 @@ # This is the Generic LinuxBIOS target ifeq ($(CONFIG_PLATFORM),y) -ifeq ($(LINUXBIOS_TAG),) +ifeq ($(LBV2_TAG),) $(error You need to specify a version to pull in your platform config) endif endif -LINUXBIOS_PATCHES = +LBV2_PATCHES = ifeq ($(CONFIG_PAYLOAD_FILO),y) - LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/tyan-s2882-filo-Config.lb.patch + LBV2_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/tyan-s2882-filo-Config.lb.patch endif ifeq ($(CONFIG_PAYLOAD_KERNEL),y) - LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/tyan-s2882-kernel-and-lab-Config.lb.patch + LBV2_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/tyan-s2882-kernel-and-lab-Config.lb.patch endif ifeq ($(CONFIG_PAYLOAD_LAB),y) - LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/tyan-s2882-kernel-and-lab-Config.lb.patch + LBV2_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/tyan-s2882-kernel-and-lab-Config.lb.patch endif -LINUXBIOS_BASE_DIR=svn -LINUXBIOS_URL=svn://linuxbios.org/repos/trunk/LinuxBIOSv2 -LINUXBIOS_TARBALL=linuxbios-svn-$(LINUXBIOS_TAG).tar.gz -LINUXBIOS_PAYLOAD_TARGET=$(LINUXBIOS_BUILD_DIR)/payload.elf +LBV2_BASE_DIR=svn +LBV2_URL=svn://linuxbios.org/repos/trunk/LinuxBIOSv2 +LBV2_TARBALL=linuxbios-svn-$(LBV2_TAG).tar.gz +LBV2_PAYLOAD_TARGET=$(LBV2_BUILD_DIR)/payload.elf TARGET_ROM = $(LINUXBIOS_VENDOR)-$(LINUXBIOS_BOARD).rom include $(PACKAGE_DIR)/linuxbios/linuxbios.inc -$(SOURCE_DIR)/$(LINUXBIOS_TARBALL): +$(SOURCE_DIR)/$(LBV2_TARBALL): @ echo "Fetching the LinuxBIOS code..." @ mkdir -p $(SOURCE_DIR)/linuxbios - @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \ - $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ - > $(LINUXBIOS_FETCH_LOG) 2>&1 + @ $(BIN_DIR)/fetchsvn.sh $(LBV2_URL) $(SOURCE_DIR)/linuxbios \ + $(LBV2_TAG) $(SOURCE_DIR)/$(LBV2_TARBALL) \ + > $(LBV2_FETCH_LOG) 2>&1 -$(OUTPUT_DIR)/$(TARGET_ROM): $(LINUXBIOS_OUTPUT) +$(OUTPUT_DIR)/$(TARGET_ROM): $(LBV2_OUTPUT) @ mkdir -p $(OUTPUT_DIR) - @ cat $(LINUXBIOS_OUTPUT) > $@ + @ cat $(LBV2_OUTPUT) > $@ linuxbios: $(OUTPUT_DIR)/$(TARGET_ROM) linuxbios-clean: generic-linuxbios-clean Modified: buildrom-devel/packages/linuxbios/tyan-s2891-linuxbios.mk =================================================================== --- buildrom-devel/packages/linuxbios/tyan-s2891-linuxbios.mk 2007-12-22 03:21:44 UTC (rev 89) +++ buildrom-devel/packages/linuxbios/tyan-s2891-linuxbios.mk 2008-01-11 17:38:23 UTC (rev 90) @@ -1,44 +1,44 @@ # This is the Generic LinuxBIOS target ifeq ($(CONFIG_PLATFORM),y) -ifeq ($(LINUXBIOS_TAG),) +ifeq ($(LBV2_TAG),) $(error You need to specify a version to pull in your platform config) endif endif -LINUXBIOS_PATCHES = +LBV2_PATCHES = ifeq ($(CONFIG_PAYLOAD_FILO),y) - LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/tyan-s2891-filo-Config.lb.patch + LBV2_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/tyan-s2891-filo-Config.lb.patch endif ifeq ($(CONFIG_PAYLOAD_KERNEL),y) - LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/tyan-s2891-kernel-and-lab-Config.lb.patch + LBV2_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/tyan-s2891-kernel-and-lab-Config.lb.patch endif ifeq ($(CONFIG_PAYLOAD_LAB),y) - LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/tyan-s2891-kernel-and-lab-Config.lb.patch + LBV2_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/tyan-s2891-kernel-and-lab-Config.lb.patch endif -LINUXBIOS_BASE_DIR=svn -LINUXBIOS_URL=svn://linuxbios.org/repos/trunk/LinuxBIOSv2 -LINUXBIOS_TARBALL=linuxbios-svn-$(LINUXBIOS_TAG).tar.gz -LINUXBIOS_PAYLOAD_TARGET=$(LINUXBIOS_BUILD_DIR)/payload.elf +LBV2_BASE_DIR=svn +LBV2_URL=svn://linuxbios.org/repos/trunk/LinuxBIOSv2 +LBV2_TARBALL=linuxbios-svn-$(LBV2_TAG).tar.gz +LBV2_PAYLOAD_TARGET=$(LBV2_BUILD_DIR)/payload.elf TARGET_ROM = $(LINUXBIOS_VENDOR)-$(LINUXBIOS_BOARD).rom include $(PACKAGE_DIR)/linuxbios/linuxbios.inc -$(SOURCE_DIR)/$(LINUXBIOS_TARBALL): +$(SOURCE_DIR)/$(LBV2_TARBALL): @ echo "Fetching the LinuxBIOS code..." @ mkdir -p $(SOURCE_DIR)/linuxbios - @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \ - $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ - > $(LINUXBIOS_FETCH_LOG) 2>&1 + @ $(BIN_DIR)/fetchsvn.sh $(LBV2_URL) $(SOURCE_DIR)/linuxbios \ + $(LBV2_TAG) $(SOURCE_DIR)/$(LBV2_TARBALL) \ + > $(LBV2_FETCH_LOG) 2>&1 -$(OUTPUT_DIR)/$(TARGET_ROM): $(LINUXBIOS_OUTPUT) +$(OUTPUT_DIR)/$(TARGET_ROM): $(LBV2_OUTPUT) @ mkdir -p $(OUTPUT_DIR) - @ cat $(LINUXBIOS_OUTPUT) > $@ + @ cat $(LBV2_OUTPUT) > $@ linuxbios: $(OUTPUT_DIR)/$(TARGET_ROM) linuxbios-clean: generic-linuxbios-clean From peter at stuge.se Fri Jan 11 18:54:16 2008 From: peter at stuge.se (Peter Stuge) Date: Fri, 11 Jan 2008 18:54:16 +0100 Subject: [LinuxBIOS] LinuxBIOSv3 Config files In-Reply-To: <4787A3BB.5080504@coresystems.de> References: <20080111030229.25891.qmail@stuge.se> <009701c85406$8b8deb90$2023040a@chimp> <20080111124836.GB18192@coresystems.de> <20080111153150.GA16602@greenwood> <13426df10801110759g47f5c066p915c9bd95598fbc@mail.gmail.com> <20080111160348.2709.qmail@stuge.se> <4787A3BB.5080504@coresystems.de> Message-ID: <20080111175416.18469.qmail@stuge.se> On Fri, Jan 11, 2008 at 06:13:31PM +0100, Stefan Reinauer wrote: > >So will oldconfig read from stdin also for options specified in > >.config ? If so, this is still no the winner. > > nope. oldconfig only asks options not available in .config Then this should work: while :;do echo;done|make oldconfig //Peter From svn at openbios.org Fri Jan 11 19:22:54 2008 From: svn at openbios.org (svn at openbios.org) Date: Fri, 11 Jan 2008 19:22:54 +0100 Subject: [LinuxBIOS] r91 - in buildrom-devel: . packages packages/linuxbios packages/linuxbiosv3 packages/linuxbiosv3/conf packages/roms Message-ID: Author: myles Date: 2008-01-11 19:22:53 +0100 (Fri, 11 Jan 2008) New Revision: 91 Added: buildrom-devel/packages/linuxbiosv3/ buildrom-devel/packages/linuxbiosv3/conf/ buildrom-devel/packages/linuxbiosv3/conf/qemu-i386-defconfig buildrom-devel/packages/linuxbiosv3/linuxbiosv3.mk buildrom-devel/packages/linuxbiosv3/patches/ buildrom-devel/packages/roms/ buildrom-devel/packages/roms/rom-geode.inc buildrom-devel/packages/roms/roms.mk Removed: buildrom-devel/packages/linuxbios/conf.v3/ Modified: buildrom-devel/Makefile buildrom-devel/packages/linuxbios/linuxbios.inc Log: This is the rest of the last patch. - Myles This patch is Jordan's buildrom patch with a few additions, so I'm including his original message: [BUILDROM] Expand linuxbiosv3 support - the rest of the files Add more generic support for LinuxBIOSv3 - add specialized package for v3, and add support for using LAR to put it all together. Also add expanded (and better) option ROM support, though we're not actually using it right away. Myles again: It also changes LINUXBIOS variables to LBV2 unless they are used for both. I added dependencies between vendors that don't have any v3 platforms and LINUXBIOS_V2. This also makes the Makefile silent during ROM processing. Modified: buildrom-devel/Makefile =================================================================== --- buildrom-devel/Makefile 2008-01-11 17:38:23 UTC (rev 90) +++ buildrom-devel/Makefile 2008-01-11 18:22:53 UTC (rev 91) @@ -68,12 +68,10 @@ rom: $(HOSTTOOLS-y) payload $(LINUXBIOS-y) else -# Add the payload, and then add everything in the deploy/roms directory - rom: $(HOSTTOOLS-y) payload $(LINUXBIOS-y) - cp $(LBV3_OUTPUT) $(TARGET_ROM_FILE) - $(STAGING_DIR)/bin/lar -a $(TARGET_ROM_FILE) $(PAYLOAD_TARGET):normal/payload - for file in `ls $(ROM_DIR)`; do \ + @ cp $(LBV3_OUTPUT) $(TARGET_ROM_FILE) + @ $(STAGING_DIR)/bin/lar -a $(TARGET_ROM_FILE) $(PAYLOAD_TARGET):normal/payload + @ for file in `ls $(ROM_DIR)`; do \ $(STAGING_DIR)/bin/lar -a $(TARGET_ROM_FILE) $(ROM_DIR)/$$file:$$file; \ done endif Modified: buildrom-devel/packages/linuxbios/linuxbios.inc =================================================================== --- buildrom-devel/packages/linuxbios/linuxbios.inc 2008-01-11 17:38:23 UTC (rev 90) +++ buildrom-devel/packages/linuxbios/linuxbios.inc 2008-01-11 18:22:53 UTC (rev 91) @@ -15,7 +15,7 @@ endif endif -LBV2_OUTPUT=$(LBV2_BUILD_DIR)/$(LBV2_ROM_NAME) +LBV2_OUTPUT=$(LBV2_BUILD_DIR)/$(LINUXBIOS_ROM_NAME) LBV2_DIR=$(BUILD_DIR)/linuxbios # If the user wanted to override the build directory - obey that now Added: buildrom-devel/packages/linuxbiosv3/conf/qemu-i386-defconfig =================================================================== --- buildrom-devel/packages/linuxbiosv3/conf/qemu-i386-defconfig (rev 0) +++ buildrom-devel/packages/linuxbiosv3/conf/qemu-i386-defconfig 2008-01-11 18:22:53 UTC (rev 91) @@ -0,0 +1,88 @@ +# +# Automatically generated make config: don't edit +# LinuxBIOS version: 3.0.0 +# Tue Jan 8 12:28:41 2008 +# + +# +# General setup +# +# CONFIG_EXPERIMENTAL is not set +# CONFIG_EXPERT is not set +CONFIG_LOCALVERSION="" + +# +# Mainboard +# +# CONFIG_VENDOR_ADL is not set +# CONFIG_VENDOR_AMD is not set +# CONFIG_VENDOR_ARTECGROUP is not set +CONFIG_VENDOR_EMULATION=y +# CONFIG_VENDOR_PCENGINES is not set +CONFIG_MAINBOARD_NAME="emulation/qemu-x86" +CONFIG_MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID=0x15ad +CONFIG_MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID=0x1976 +CONFIG_BOARD_EMULATION_QEMU_X86=y +# CONFIG_LINUXBIOS_ROMSIZE_KB_128 is not set +# CONFIG_LINUXBIOS_ROMSIZE_KB_256 is not set +# CONFIG_LINUXBIOS_ROMSIZE_KB_512 is not set +CONFIG_LINUXBIOS_ROMSIZE_KB_1024=y +# CONFIG_LINUXBIOS_ROMSIZE_KB_2048 is not set +CONFIG_LINUXBIOS_ROMSIZE_KB=1024 +CONFIG_ARCH_X86=y +CONFIG_ARCH="x86" +CONFIG_CPU_I586=y +CONFIG_OPTION_TABLE=y + +# +# Compression +# +CONFIG_COMPRESSION_LZMA=y +# CONFIG_COMPRESSION_NRV2B is not set +CONFIG_DEFAULT_COMPRESSION_LZMA=y +# CONFIG_DEFAULT_COMPRESSION_NRV2B is not set +# CONFIG_DEFAULT_COMPRESSION_NONE is not set + +# +# Console +# +CONFIG_CONSOLE=y +CONFIG_CONSOLE_LOGLEVEL_8=y +# CONFIG_CONSOLE_LOGLEVEL_7 is not set +# CONFIG_CONSOLE_LOGLEVEL_6 is not set +# CONFIG_CONSOLE_LOGLEVEL_5 is not set +# CONFIG_CONSOLE_LOGLEVEL_4 is not set +# CONFIG_CONSOLE_LOGLEVEL_3 is not set +# CONFIG_CONSOLE_LOGLEVEL_2 is not set +# CONFIG_CONSOLE_LOGLEVEL_1 is not set +# CONFIG_CONSOLE_LOGLEVEL_0 is not set +CONFIG_DEFAULT_CONSOLE_LOGLEVEL=8 +CONFIG_CONSOLE_SERIAL=y +CONFIG_CONSOLE_SERIAL_COM1=y +# CONFIG_CONSOLE_SERIAL_COM2 is not set +CONFIG_CONSOLE_SERIAL_115200=y +# CONFIG_CONSOLE_SERIAL_57600 is not set +# CONFIG_CONSOLE_SERIAL_38400 is not set +# CONFIG_CONSOLE_SERIAL_19200 is not set +# CONFIG_CONSOLE_SERIAL_9600 is not set + +# +# Devices +# +CONFIG_PCI_OPTION_ROM_RUN=y +# CONFIG_PCI_OPTION_ROM_RUN_X86EMU is not set +CONFIG_PCI_OPTION_ROM_RUN_VM86=y +# CONFIG_PCI_OPTION_ROM_RUN_NONE is not set +# CONFIG_MULTIPLE_VGA_INIT is not set +# CONFIG_INITIALIZE_ONBOARD_VGA_FIRST is not set +CONFIG_NORTHBRIDGE_INTEL_I440BXEMULATION=y +CONFIG_SOUTHBRIDGE_INTEL_I82371EB=y +CONFIG_SUPERIO_WINBOND_W83627HF=y +CONFIG_NORTHBRIDGE_INTEL_I440BXEMULATION_RAMSIZE=32 + +# +# Payload +# +# CONFIG_PAYLOAD_PREPARSE_ELF is not set +# CONFIG_PAYLOAD_ELF is not set +CONFIG_PAYLOAD_NONE=y Added: buildrom-devel/packages/linuxbiosv3/linuxbiosv3.mk =================================================================== --- buildrom-devel/packages/linuxbiosv3/linuxbiosv3.mk (rev 0) +++ buildrom-devel/packages/linuxbiosv3/linuxbiosv3.mk 2008-01-11 18:22:53 UTC (rev 91) @@ -0,0 +1,76 @@ +ifeq ($(LBV3_TAG),) +$(error You need to specify a version to pull in your platform config) +endif + +LBV3_URL=svn://openbios.org/repository/LinuxBIOSv3 +LBV3_TARBALL=linuxbios-svn-$(LBV3_TAG).tar.gz +LBV3_DIR=$(BUILD_DIR)/linuxbiosv3 +LBV3_SRC_DIR=$(LBV3_DIR)/svn + +LBV3_STAMP_DIR=$(LBV3_DIR)/stamps +LBV3_LOG_DIR=$(LBV3_DIR)/logs + +ifeq ($(CONFIG_VERBOSE),y) +LBV3_FETCH_LOG=/dev/stdout +LBV3_CONFIG_LOG=/dev/stdout +LBV3_BUILD_LOG=/dev/stdout +else +LBV3_FETCH_LOG=$(LBV3_LOG_DIR)/fetch.log +LBV3_CONFIG_LOG=$(LBV3_LOG_DIR)/config.log +LBV3_BUILD_LOG=$(LBV3_LOG_DIR)/build.log +endif + +TARGET_ROM = $(LINUXBIOS_VENDOR)-$(LINUXBIOS_BOARD).rom + +LBV3_OUTPUT=$(LBV3_SRC_DIR)/build/linuxbios.rom + +LBV3_PATCHES ?= + +$(SOURCE_DIR)/$(LBV3_TARBALL): + @ mkdir -p $(SOURCE_DIR)/linuxbiosv3 + @ $(BIN_DIR)/fetchsvn.sh $(LBV3_URL) \ + $(SOURCE_DIR)/linuxbiosv3 $(LBV3_TAG) \ + $@ > $(LBV3_FETCH_LOG) 2>&1 + +$(LBV3_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(LBV3_TARBALL) + @echo "Unpacking LinuxBIOSv3..." + @ mkdir -p $(LBV3_DIR) + @ tar -C $(LBV3_DIR) -zxf $(SOURCE_DIR)/$(LBV3_TARBALL) + @ touch $@ + +$(LBV3_STAMP_DIR)/.patched: $(LBV3_STAMP_DIR)/.unpacked + @ echo "Patching LinuxBIOSv3..." + @ $(BIN_DIR)/doquilt.sh $(LBV3_SRC_DIR) $(LBV3_PATCHES) + @ touch $@ + +$(LBV3_STAMP_DIR)/.configured: $(LBV3_STAMP_DIR)/.patched + @ echo "Configuring LinuxBIOSv3..." + @ cp $(PACKAGE_DIR)/linuxbiosv3/conf/$(LBV3_CONFIG) $(LBV3_SRC_DIR)/.config + @ make -C $(LBV3_SRC_DIR) oldconfig > $(LBV3_CONFIG_LOG) 2>&1 + @ touch $@ + +$(LBV3_OUTPUT): $(LBV3_STAMP_DIR)/.configured + @ echo "Building LinuxBIOSv3..." + @ $(MAKE) -C $(LBV3_SRC_DIR) > $(LBV3_BUILD_LOG) 2>&1 + +$(LBV3_SRC_DIR)/build/util/lar/lar: $(LBV3_STAMP_DIR)/.configured + @ $(MAKE) -C $(LBV3_SRC_DIR)/util lar > $(LBV3_BUILD_LOG) 2>&1 + +$(STAGING_DIR)/bin/lar: $(LBV3_SRC_DIR)/build/util/lar/lar + @ mkdir -p $(STAGING_DIR)/bin + @ cp $< $@ + + +$(LBV3_STAMP_DIR) $(LBV3_LOG_DIR): + @ mkdir -p $@ + +linuxbiosv3: $(LBV3_LOG_DIR) $(LBV3_STAMP_DIR) $(LBV3_OUTPUT) $(STAGING_DIR)/bin/lar + +linuxbiosv3-clean: + @ echo "Cleaning linuxbiosv3..." + @ $(MAKE) -C $(LBV3_SRC_DIR) clean > /dev/null 2>&1 + +linuxbiosv3-distclean: + @ rm -rf $(LBV3_DIR)/* + @ rm -rf $(STAGING_DIR)/bin/lar + Added: buildrom-devel/packages/roms/rom-geode.inc =================================================================== --- buildrom-devel/packages/roms/rom-geode.inc (rev 0) +++ buildrom-devel/packages/roms/rom-geode.inc 2008-01-11 18:22:53 UTC (rev 91) @@ -0,0 +1,17 @@ +# This is the geode specific optionrom target +# download VSA + +VSA_URL=http://www.amd.com/files/connectivitysolutions/geode/geode_lx/ +GEODE_VSA=lx_vsa.36k.bin + +$(SOURCE_DIR)/$(GEODE_VSA): + @ echo "Fetching the VSA code..." + @ wget -P $(SOURCE_DIR) $(VSA_URL)/$(GEODE_VSA).gz -O $@ + +# Copy the file to the ROM_DIR - it should have the same name that it +# will have in the LAR + +$(ROM_DIR)/vsa: $(SOURCE_DIR)/$(GEODE_VSA): + @ cp $< $@ + +OPTIONROM_TARGETS += $(ROM_DIR)/vsa Added: buildrom-devel/packages/roms/roms.mk =================================================================== --- buildrom-devel/packages/roms/roms.mk (rev 0) +++ buildrom-devel/packages/roms/roms.mk 2008-01-11 18:22:53 UTC (rev 91) @@ -0,0 +1,22 @@ +# Each platform that needs an option ROM or other binary blob is specified +# here + + +OPTIONROM_TARGETS= + +OPTIONROM-y = +OPTIONROM-$(CONFIG_PLATFORM_NORWICH) += rom-geode.inc + +ifneq ($(OPTIONROMS-y),) +include $(OPTIONROM-y) +endif + +$(ROM_DIR): + mkdir -p $(ROM_DIR) + +roms: $(ROM_DIR) $(OPTIONROM_TARGETS) + +roms-clean: + @ rm -rf $(OPTIONROM_TARGETS) + +roms-distclean: roms-clean From svn at openbios.org Fri Jan 11 19:23:47 2008 From: svn at openbios.org (svn at openbios.org) Date: Fri, 11 Jan 2008 19:23:47 +0100 Subject: [LinuxBIOS] r3046 - trunk/LinuxBIOSv2/targets Message-ID: Author: jcrouse Date: 2008-01-11 19:23:47 +0100 (Fri, 11 Jan 2008) New Revision: 3046 Modified: trunk/LinuxBIOSv2/targets/buildtarget Log: Add the ability to extend CFLAGS as needed for several new distros Signed-off-by: Ronald G. Minnich Acked-by: Peter Stuge Acked-by: Stefan Reinauer Acked-by: Jordan Crouse Modified: trunk/LinuxBIOSv2/targets/buildtarget =================================================================== --- trunk/LinuxBIOSv2/targets/buildtarget 2008-01-11 00:32:07 UTC (rev 3045) +++ trunk/LinuxBIOSv2/targets/buildtarget 2008-01-11 18:23:47 UTC (rev 3046) @@ -53,4 +53,25 @@ export PYTHONPATH=$config_dir $PYTHON $config_py $config_lb $lbpath +# now start checking for distro-specific breakage. +## This check is for the no stack protector mess. +EXTRA_CFLAGS= + +if [ -z "$CC" ]; then + CC=gcc +fi + +$CC -fno-stack-protector -S -xc /dev/null -o .$$.tmp + +if [ $? -eq 0 ]; then + EXTRA_CFLAGS=-fno-stack-protector +fi + +rm -rf .$$.tmp + +for i in $build_dir/Makefile.settings $build_dir/*/Makefile.settings +do + echo CFLAGS+=$EXTRA_CFLAGS >>$i +done + exit $? From mylesgw at gmail.com Fri Jan 11 19:24:44 2008 From: mylesgw at gmail.com (Myles Watson) Date: Fri, 11 Jan 2008 11:24:44 -0700 Subject: [LinuxBIOS] r90 - in buildrom-devel: . config/platformspackages/linuxbios packages/linuxbios/conf.v3 In-Reply-To: <200801111738.m0BHcemw031709@mouselemur.cs.byu.edu> References: <200801111738.m0BHcemw031709@mouselemur.cs.byu.edu> Message-ID: <00c301c8547f$3e2f82e0$2023040a@chimp> > > Signed-off-by: Myles Watson > Acked-by: Jordan Crouse > The rest is in r91. Thanks, Myles From myles at pel.cs.byu.edu Fri Jan 11 19:26:47 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Fri, 11 Jan 2008 11:26:47 -0700 Subject: [LinuxBIOS] r3046 - trunk/LinuxBIOSv2/targets In-Reply-To: <200801111824.m0BIO9ub031879@mouselemur.cs.byu.edu> References: <200801111824.m0BIO9ub031879@mouselemur.cs.byu.edu> Message-ID: <00c401c8547f$86bef360$2023040a@chimp> > Author: jcrouse > Date: 2008-01-11 19:23:47 +0100 (Fri, 11 Jan 2008) > New Revision: 3046 > > Modified: > trunk/LinuxBIOSv2/targets/buildtarget > Log: > Add the ability to extend CFLAGS as needed for several new distros > Signed-off-by: Ronald G. Minnich > Acked-by: Peter Stuge > Acked-by: Stefan Reinauer > Acked-by: Jordan Crouse > > > > Modified: trunk/LinuxBIOSv2/targets/buildtarget > =================================================================== > --- trunk/LinuxBIOSv2/targets/buildtarget 2008-01-11 00:32:07 UTC (rev > 3045) > +++ trunk/LinuxBIOSv2/targets/buildtarget 2008-01-11 18:23:47 UTC (rev > 3046) > @@ -53,4 +53,25 @@ > export PYTHONPATH=$config_dir > $PYTHON $config_py $config_lb $lbpath > > +# now start checking for distro-specific breakage. > +## This check is for the no stack protector mess. > +EXTRA_CFLAGS= > + > +if [ -z "$CC" ]; then > + CC=gcc > +fi > + > +$CC -fno-stack-protector -S -xc /dev/null -o .$$.tmp > + > +if [ $? -eq 0 ]; then > + EXTRA_CFLAGS=-fno-stack-protector > +fi This adds the flag for me, even though I didn't need it. Was that intended? Myles > + > +rm -rf .$$.tmp > + > +for i in $build_dir/Makefile.settings $build_dir/*/Makefile.settings > +do > + echo CFLAGS+=$EXTRA_CFLAGS >>$i > +done > + > exit $? > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios From marc.jones at amd.com Fri Jan 11 18:38:39 2008 From: marc.jones at amd.com (Marc Jones) Date: Fri, 11 Jan 2008 10:38:39 -0700 Subject: [LinuxBIOS] PATCH: lx car that returns from disable_car In-Reply-To: <13426df10801102008ld9b6d6rab616a6beee6d443@mail.gmail.com> References: <13426df10801041405h1d3e0f1eocdfba04c34144eb9@mail.gmail.com> <4782A542.6030109@amd.com> <13426df10801102008ld9b6d6rab616a6beee6d443@mail.gmail.com> Message-ID: <4787A99F.2070409@amd.com> ron minnich wrote: > Marc, here are the register dumps. > > As a reminder, we seem to have no memory above 1M. > It looks like stage2 has problems. The MSRs are not setup beyond what stage1 did to allow stage2 to run. Specificly, geodelx_pci_domain_phase2() is not running. Can you send your entire output? Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From jordan.crouse at AMD.COM Fri Jan 11 19:29:32 2008 From: jordan.crouse at AMD.COM (Jordan Crouse) Date: Fri, 11 Jan 2008 11:29:32 -0700 Subject: [LinuxBIOS] r90 - in buildrom-devel: . config/platformspackages/linuxbios packages/linuxbios/conf.v3 In-Reply-To: <00c301c8547f$3e2f82e0$2023040a@chimp> References: <200801111738.m0BHcemw031709@mouselemur.cs.byu.edu> <00c301c8547f$3e2f82e0$2023040a@chimp> Message-ID: <20080111182932.GD2917@cosmic.amd.com> On 11/01/08 11:24 -0700, Myles Watson wrote: > > > > > Signed-off-by: Myles Watson > > Acked-by: Jordan Crouse > > > > The rest is in r91. AHHH!! That completely slipped my mind. I'm so sorry. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From jordan.crouse at amd.com Fri Jan 11 17:14:51 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Fri, 11 Jan 2008 09:14:51 -0700 Subject: [LinuxBIOS] Expand linuxbiosv3 support In-Reply-To: <2831fecf0801081320k32b4d9e2p83fecff3ad59ef6@mail.gmail.com> References: <20071206223914.GB4092@cosmic.amd.com> <00f901c83860$3bfad7d0$4b23040a@chimp> <20071206234649.GA6114@cosmic.amd.com> <010c01c838df$226f2170$4b23040a@chimp> <20071207155811.GE6784@cosmic.amd.com> <2831fecf0801081214q6ee1f337raccc91bf32815ca8@mail.gmail.com> <20080108203752.GA28312@cosmic.amd.com> <2831fecf0801081320k32b4d9e2p83fecff3ad59ef6@mail.gmail.com> Message-ID: <20080111161451.GB29166@cosmic.amd.com> On 08/01/08 14:20 -0700, Myles Watson wrote: > This patch is Jordan's buildrom patch with a few additions, so I'm including > his original message: > > [BUILDROM] Expand linuxbiosv3 support > > Add more generic support for LinuxBIOSv3 - add specialized package > for v3, and add support for using LAR to put it all together. Also > add expanded (and better) option ROM support, though we're not actually > using it right away. > > Myles again: > > It also changes LINUXBIOS variables to LBV2 unless they are used for both. I > added dependencies between vendors that don't have any v3 platforms and > LINUXBIOS_V2. > > One of the changes Jordan made was to always build v3 with no payload > and then add it later with any binary blobs that might be needed. > This way you can change them without rebuilding v3. > > Signed-off-by: Myles Watson Acked-by: Jordan Crouse Thanks. From myles at pel.cs.byu.edu Fri Jan 11 19:36:46 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Fri, 11 Jan 2008 11:36:46 -0700 Subject: [LinuxBIOS] r90 - in buildrom-devel: . config/platformspackages/linuxbios packages/linuxbios/conf.v3 In-Reply-To: <20080111182932.GD2917@cosmic.amd.com> References: <200801111738.m0BHcemw031709@mouselemur.cs.byu.edu> <00c301c8547f$3e2f82e0$2023040a@chimp> <20080111182932.GD2917@cosmic.amd.com> Message-ID: <00c501c85480$eb60dd00$2023040a@chimp> > > AHHH!! That completely slipped my mind. I'm so sorry. > No problem. It happens. Myles From Marc.Karasek at Sun.COM Fri Jan 11 19:49:10 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Fri, 11 Jan 2008 13:49:10 -0500 Subject: [LinuxBIOS] AMD SimNOW question In-Reply-To: <13426df10801101552k105385eaifa1d0771839da3b5@mail.gmail.com> References: <4783CA87.4070600@sun.com> <2831fecf0801081223u25f7a96cheae2779637cf4189@mail.gmail.com> <4783F2BB.8000902@sun.com> <01e801c85243$52ac9e30$a023040a@chimp> <20080108222125.GC28312@cosmic.amd.com> <4783FB7F.4000205@sun.com> <13426df10801101552k105385eaifa1d0771839da3b5@mail.gmail.com> Message-ID: <4787BA26.8060700@sun.com> I have managed to cobble together a build structure that tries to build. It gets to the point of building the linuxbios image and it chokes because the image is to large for the romsize. Can someone shed some light on what Config.lb should be set to to get this to compile. The payload buildrom is generating is 790,000+ bytes big. /********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 *********************/ ron minnich wrote: > On Jan 8, 2008 2:38 PM, Marc Karasek wrote: > >> I have found the main problem with svn. It looks like if you use svn co >> http:// it will use the proxy settings under servers. If you do a svn >> co svn:// it tries to do a dns lookup, which fails behind a proxy server >> :-(. I have not been able to find any info on setting svn up to use a >> proxy when doing svn:// type checkouts. >> > > There is a way to do it, maybe: http://subversion.tigris.org/faq.html#proxy > > ron > From Marc.Karasek at Sun.COM Fri Jan 11 19:50:14 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Fri, 11 Jan 2008 13:50:14 -0500 Subject: [LinuxBIOS] Patch file for ld/fedora 8 issue as promised... In-Reply-To: <2831fecf0801081454m71bb3ff3x3b2da3eb60d4aa37@mail.gmail.com> References: <477CF25C.7070901@sun.com> <477D507E.4030106@sun.com> <477E8A50.2080408@sun.com> <477EB7A1.80406@sun.com> <47824212.3030307@sun.com> <2831fecf0801070837n4c22d036t38254f5ee02d14d1@mail.gmail.com> <4783FC1F.7070309@sun.com> <2831fecf0801081454m71bb3ff3x3b2da3eb60d4aa37@mail.gmail.com> Message-ID: <4787BA66.1000506@sun.com> Is this patch good to go as is? Or should I pull out the id.lds section for now? /********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 *********************/ Myles Watson wrote: > On Jan 8, 2008 3:41 PM, Marc Karasek wrote: > >> So what is the general consensus ==1 or >0? >> > > I like the idea of using grep. It seems much cleaner, and avoids that issue. > > The other sticking point for the patch the changes in > src/arch/i386/lib/id.lds (See Ed's last message.) > > Myles > > >> Also, I think I know how to commit back to the tree, but do I need a >> user account for this? >> >> /********************* >> Marc Karasek >> MTS >> Sun Microsystems >> mailto:marc.karasek at sun.com >> ph:770.360.6415 >> *********************/ >> >> >> >> >> Myles Watson wrote: >> >>> On Jan 7, 2008 8:15 AM, Marc Karasek wrote: >>> >>> >>>> After looking at the script Myles sent, I immediately saw the problem. >>>> I forgot that if [ $build_id ] will always be true because it checks to >>>> see if it is defined not the value of build_id. My bad, sorry. >>>> >>>> I have made the changes and added an == 1 to the if statement. Attached >>>> is the new and I hope final patch file for this. >>>> >>>> >>>> >>> It works for me (it doesn't add the load option.) >>> >>> Sorry to be picky, but it seems like this breaks if they mention >>> build-id more than once in the help in the future. I think >0 would >>> be better than ==1. >>> >>> With that fixed, or if no one thinks that will ever happen: >>> Acked-by: Myles Watson >>> >>> >>>> /********************* >>>> Marc Karasek >>>> MTS >>>> Sun Microsystems >>>> mailto:marc.karasek at sun.com >>>> ph:770.360.6415 >>>> *********************/ >>>> >>>> >>>> >>>> Ed Swierk wrote: >>>> >>>> >>>> >>>>> On 1/4/08, Marc Karasek wrote: >>>>> >>>>> >>>>> >>>>>> I made a test script and ran it and it sets build_id = 1 properly. I >>>>>> have also included this script. >>>>>> >>>>>> >>>>>> >>>>> The problem is that on Planet Bourne, zero means true and nonzero means false. >>>>> >>>>> --Ed >>>>> >>>>> >>>>> From jordan.crouse at amd.com Fri Jan 11 18:41:38 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Fri, 11 Jan 2008 10:41:38 -0700 Subject: [LinuxBIOS] Expand linuxbiosv3 support In-Reply-To: <2831fecf0801081320k32b4d9e2p83fecff3ad59ef6@mail.gmail.com> References: <20071206223914.GB4092@cosmic.amd.com> <00f901c83860$3bfad7d0$4b23040a@chimp> <20071206234649.GA6114@cosmic.amd.com> <010c01c838df$226f2170$4b23040a@chimp> <20071207155811.GE6784@cosmic.amd.com> <2831fecf0801081214q6ee1f337raccc91bf32815ca8@mail.gmail.com> <20080108203752.GA28312@cosmic.amd.com> <2831fecf0801081320k32b4d9e2p83fecff3ad59ef6@mail.gmail.com> Message-ID: <20080111174138.GA2410@cosmic.amd.com> On 08/01/08 14:20 -0700, Myles Watson wrote: > > Signed-off-by: Myles Watson I went ahead and comitted this (v90), so that Ward could refactor his patch against it. Jordan From info at coresystems.de Fri Jan 11 20:10:59 2008 From: info at coresystems.de (LinuxBIOS information) Date: Fri, 11 Jan 2008 20:10:59 +0100 Subject: [LinuxBIOS] r3046 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "jcrouse" checked in revision 3046 to the LinuxBIOS source repository and caused the following changes: Change Log: Add the ability to extend CFLAGS as needed for several new distros Signed-off-by: Ronald G. Minnich Acked-by: Peter Stuge Acked-by: Stefan Reinauer Acked-by: Jordan Crouse Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3046&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in jcrouse's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From svn at openbios.org Fri Jan 11 20:17:38 2008 From: svn at openbios.org (svn at openbios.org) Date: Fri, 11 Jan 2008 20:17:38 +0100 Subject: [LinuxBIOS] r92 - buildrom-devel/packages/linuxbios Message-ID: Author: jcrouse Date: 2008-01-11 20:17:38 +0100 (Fri, 11 Jan 2008) New Revision: 92 Removed: buildrom-devel/packages/linuxbios/CL2.5.patch Log: Remove a OLPC refugee that I must have missed. Trivial. Signed-off-by: Jordan Crouse Deleted: buildrom-devel/packages/linuxbios/CL2.5.patch =================================================================== --- buildrom-devel/packages/linuxbios/CL2.5.patch 2008-01-11 18:22:53 UTC (rev 91) +++ buildrom-devel/packages/linuxbios/CL2.5.patch 2008-01-11 19:17:38 UTC (rev 92) @@ -1,17 +0,0 @@ -Index: src/mainboard/olpc/rev_a/auto.c -=================================================================== ---- a/src/mainboard/olpc/rev_a/auto.c (revision 2392) -+++ b/src/mainboard/olpc/rev_a/auto.c (working copy) -@@ -122,10 +122,11 @@ - /* the msr value reported by quanta is very, very different. - * we will go with that value for now. - */ -- msr.lo = 0x286332a3; -+ msr.lo = 0x686332a3; - - wrmsr(0x20000019, msr); - -+ print_err("CL2.5 Set\n"); - } - - #include "northbridge/amd/gx2/raminit.c" From rminnich at gmail.com Fri Jan 11 20:17:52 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 11 Jan 2008 11:17:52 -0800 Subject: [LinuxBIOS] AMD SimNOW question In-Reply-To: <4787BA26.8060700@sun.com> References: <4783CA87.4070600@sun.com> <2831fecf0801081223u25f7a96cheae2779637cf4189@mail.gmail.com> <4783F2BB.8000902@sun.com> <01e801c85243$52ac9e30$a023040a@chimp> <20080108222125.GC28312@cosmic.amd.com> <4783FB7F.4000205@sun.com> <13426df10801101552k105385eaifa1d0771839da3b5@mail.gmail.com> <4787BA26.8060700@sun.com> Message-ID: <13426df10801111117v63572e44w3e86215c79a73e54@mail.gmail.com> In the TARGET file, you can put something like this: option ROM_SIZE=1024*1024 that gets you 1M ron From myles at pel.cs.byu.edu Fri Jan 11 20:25:50 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Fri, 11 Jan 2008 12:25:50 -0700 Subject: [LinuxBIOS] AMD SimNOW question In-Reply-To: <13426df10801111117v63572e44w3e86215c79a73e54@mail.gmail.com> References: <4783CA87.4070600@sun.com> <2831fecf0801081223u25f7a96cheae2779637cf4189@mail.gmail.com> <4783F2BB.8000902@sun.com> <01e801c85243$52ac9e30$a023040a@chimp> <20080108222125.GC28312@cosmic.amd.com> <4783FB7F.4000205@sun.com> <13426df10801101552k105385eaifa1d0771839da3b5@mail.gmail.com> <4787BA26.8060700@sun.com> <13426df10801111117v63572e44w3e86215c79a73e54@mail.gmail.com> Message-ID: <2831fecf0801111125heb23fcbke4c4cecade5081d2@mail.gmail.com> Here are my Config.lb files for Serengeti Cheetah and fam 10. Good luck, Myles On Jan 11, 2008 12:17 PM, ron minnich wrote: > In the TARGET file, you can put something like this: > > option ROM_SIZE=1024*1024 > > that gets you 1M > > ron > -------------- next part -------------- A non-text attachment was scrubbed... Name: Config.lb Type: application/octet-stream Size: 1790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Config.lb Type: application/octet-stream Size: 3370 bytes Desc: not available URL: From corey.osgood at gmail.com Fri Jan 11 20:26:47 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Fri, 11 Jan 2008 14:26:47 -0500 Subject: [LinuxBIOS] r3046 - trunk/LinuxBIOSv2/targets In-Reply-To: <00c401c8547f$86bef360$2023040a@chimp> References: <200801111824.m0BIO9ub031879@mouselemur.cs.byu.edu> <00c401c8547f$86bef360$2023040a@chimp> Message-ID: <4787C2F7.1090705@gmail.com> Myles Watson wrote: >> Author: jcrouse >> Date: 2008-01-11 19:23:47 +0100 (Fri, 11 Jan 2008) >> New Revision: 3046 >> >> Modified: >> trunk/LinuxBIOSv2/targets/buildtarget >> Log: >> Add the ability to extend CFLAGS as needed for several new distros >> Signed-off-by: Ronald G. Minnich >> Acked-by: Peter Stuge >> Acked-by: Stefan Reinauer >> Acked-by: Jordan Crouse >> >> >> >> Modified: trunk/LinuxBIOSv2/targets/buildtarget >> =================================================================== >> --- trunk/LinuxBIOSv2/targets/buildtarget 2008-01-11 00:32:07 UTC (rev >> 3045) >> +++ trunk/LinuxBIOSv2/targets/buildtarget 2008-01-11 18:23:47 UTC (rev >> 3046) >> @@ -53,4 +53,25 @@ >> export PYTHONPATH=$config_dir >> $PYTHON $config_py $config_lb $lbpath >> >> +# now start checking for distro-specific breakage. >> +## This check is for the no stack protector mess. >> +EXTRA_CFLAGS= >> + >> +if [ -z "$CC" ]; then >> + CC=gcc >> +fi >> + >> +$CC -fno-stack-protector -S -xc /dev/null -o .$$.tmp >> + >> +if [ $? -eq 0 ]; then >> + EXTRA_CFLAGS=-fno-stack-protector >> +fi >> > > This adds the flag for me, even though I didn't need it. Was that intended? > > Myles I don't think it matters, if your gcc wasn't compiled to do stack checking it'll just ignore it. But I think it breaks gcc 3.x, do we care? IMHO, no. -Corey From myles at pel.cs.byu.edu Fri Jan 11 20:41:37 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Fri, 11 Jan 2008 12:41:37 -0700 Subject: [LinuxBIOS] r3046 - trunk/LinuxBIOSv2/targets In-Reply-To: <4787C2F7.1090705@gmail.com> References: <200801111824.m0BIO9ub031879@mouselemur.cs.byu.edu> <00c401c8547f$86bef360$2023040a@chimp> <4787C2F7.1090705@gmail.com> Message-ID: <00d301c85489$face83b0$2023040a@chimp> > -----Original Message----- > From: Corey Osgood [mailto:corey.osgood at gmail.com] > Sent: Friday, January 11, 2008 12:27 PM > To: myles at mouselemur.cs.byu.edu > Cc: 'Jordan Crouse'; linuxbios at linuxbios.org > Subject: Re: [LinuxBIOS] r3046 - trunk/LinuxBIOSv2/targets > > Myles Watson wrote: > >> Author: jcrouse > >> Date: 2008-01-11 19:23:47 +0100 (Fri, 11 Jan 2008) > >> New Revision: 3046 > >> > >> Modified: > >> trunk/LinuxBIOSv2/targets/buildtarget > >> Log: > >> Add the ability to extend CFLAGS as needed for several new distros > >> Signed-off-by: Ronald G. Minnich > >> Acked-by: Peter Stuge > >> Acked-by: Stefan Reinauer > >> Acked-by: Jordan Crouse > >> > >> > >> > >> Modified: trunk/LinuxBIOSv2/targets/buildtarget > >> =================================================================== > >> --- trunk/LinuxBIOSv2/targets/buildtarget 2008-01-11 00:32:07 UTC > (rev > >> 3045) > >> +++ trunk/LinuxBIOSv2/targets/buildtarget 2008-01-11 18:23:47 UTC > (rev > >> 3046) > >> @@ -53,4 +53,25 @@ > >> export PYTHONPATH=$config_dir > >> $PYTHON $config_py $config_lb $lbpath > >> > >> +# now start checking for distro-specific breakage. > >> +## This check is for the no stack protector mess. > >> +EXTRA_CFLAGS= > >> + > >> +if [ -z "$CC" ]; then > >> + CC=gcc > >> +fi > >> + > >> +$CC -fno-stack-protector -S -xc /dev/null -o .$$.tmp > >> + > >> +if [ $? -eq 0 ]; then > >> + EXTRA_CFLAGS=-fno-stack-protector > >> +fi > >> > > > > This adds the flag for me, even though I didn't need it. Was that > intended? > > > > Myles > I don't think it matters, if your gcc wasn't compiled to do stack > checking it'll just ignore it. But I think it breaks gcc 3.x, do we > care? IMHO, no. In that case we shouldn't do a check, we should just add it to the flags. Myles > -Corey From yasteve at gmail.com Fri Jan 11 20:44:21 2008 From: yasteve at gmail.com (Steve Isaacs) Date: Fri, 11 Jan 2008 11:44:21 -0800 Subject: [LinuxBIOS] INIT detected. Message-ID: <1200080661.2777.30.camel@biosbreath> Is this message normal or does it indicate a problem that needs to be corrected? INIT detected from ---- {APICID = 00 NODEID = 00 COREID = 00} --- Issuing SOFT_RESET... Looking at the code this is emitted in model_fxx/init_cpus.c when cpu_init_detectedx is non-zero. Thanks, Steve From c-d.hailfinger.devel.2006 at gmx.net Fri Jan 11 20:50:19 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 11 Jan 2008 20:50:19 +0100 Subject: [LinuxBIOS] r3046 - trunk/LinuxBIOSv2/targets In-Reply-To: <00d301c85489$face83b0$2023040a@chimp> References: <200801111824.m0BIO9ub031879@mouselemur.cs.byu.edu> <00c401c8547f$86bef360$2023040a@chimp> <4787C2F7.1090705@gmail.com> <00d301c85489$face83b0$2023040a@chimp> Message-ID: <4787C87B.9040003@gmx.net> On 11.01.2008 20:41, Myles Watson wrote: > >> -----Original Message----- >> From: Corey Osgood [mailto:corey.osgood at gmail.com] >> Sent: Friday, January 11, 2008 12:27 PM >> To: myles at mouselemur.cs.byu.edu >> Cc: 'Jordan Crouse'; linuxbios at linuxbios.org >> Subject: Re: [LinuxBIOS] r3046 - trunk/LinuxBIOSv2/targets >> >> Myles Watson wrote: >> >>>> Author: jcrouse >>>> Date: 2008-01-11 19:23:47 +0100 (Fri, 11 Jan 2008) >>>> New Revision: 3046 >>>> >>>> Modified: >>>> trunk/LinuxBIOSv2/targets/buildtarget >>>> Log: >>>> Add the ability to extend CFLAGS as needed for several new distros >>>> Signed-off-by: Ronald G. Minnich >>>> Acked-by: Peter Stuge >>>> Acked-by: Stefan Reinauer >>>> Acked-by: Jordan Crouse >>>> >>>> >>>> >>>> Modified: trunk/LinuxBIOSv2/targets/buildtarget >>>> =================================================================== >>>> --- trunk/LinuxBIOSv2/targets/buildtarget 2008-01-11 00:32:07 UTC >>>> >> (rev >> >>>> 3045) >>>> +++ trunk/LinuxBIOSv2/targets/buildtarget 2008-01-11 18:23:47 UTC >>>> >> (rev >> >>>> 3046) >>>> @@ -53,4 +53,25 @@ >>>> export PYTHONPATH=$config_dir >>>> $PYTHON $config_py $config_lb $lbpath >>>> >>>> +# now start checking for distro-specific breakage. >>>> +## This check is for the no stack protector mess. >>>> +EXTRA_CFLAGS= >>>> + >>>> +if [ -z "$CC" ]; then >>>> + CC=gcc >>>> +fi >>>> + >>>> +$CC -fno-stack-protector -S -xc /dev/null -o .$$.tmp >>>> + >>>> +if [ $? -eq 0 ]; then >>>> + EXTRA_CFLAGS=-fno-stack-protector >>>> +fi >>>> >>>> >>> This adds the flag for me, even though I didn't need it. Was that >>> >> intended? >> >>> Myles >>> >> I don't think it matters, if your gcc wasn't compiled to do stack >> checking it'll just ignore it. But I think it breaks gcc 3.x, do we >> care? IMHO, no. >> > > In that case we shouldn't do a check, we should just add it to the flags. > I'd say we try to stay compatible with 3.x. Regards, Carl-Daniel From svn at openbios.org Fri Jan 11 21:02:53 2008 From: svn at openbios.org (svn at openbios.org) Date: Fri, 11 Jan 2008 21:02:53 +0100 Subject: [LinuxBIOS] r93 - buildrom-devel/packages/busybox/conf Message-ID: Author: myles Date: 2008-01-11 21:02:53 +0100 (Fri, 11 Jan 2008) New Revision: 93 Added: buildrom-devel/packages/busybox/conf/defconfig-serengeti_cheetah-x86_64 Log: Sorry I missed this file in an earlier commit. Signed-off-by: Myles Watson Acked-by: Myles Watson Added: buildrom-devel/packages/busybox/conf/defconfig-serengeti_cheetah-x86_64 =================================================================== --- buildrom-devel/packages/busybox/conf/defconfig-serengeti_cheetah-x86_64 (rev 0) +++ buildrom-devel/packages/busybox/conf/defconfig-serengeti_cheetah-x86_64 2008-01-11 20:02:53 UTC (rev 93) @@ -0,0 +1,598 @@ +# +# Automatically generated make config: don't edit +# +HAVE_DOT_CONFIG=y + +# +# Busybox Settings +# + +# +# General Configuration +# +CONFIG_FEATURE_BUFFERS_USE_MALLOC=y +# CONFIG_FEATURE_BUFFERS_GO_ON_STACK is not set +# CONFIG_FEATURE_BUFFERS_GO_IN_BSS is not set +# CONFIG_FEATURE_VERBOSE_USAGE is not set +# CONFIG_FEATURE_INSTALLER is not set +# CONFIG_LOCALE_SUPPORT is not set +# CONFIG_FEATURE_DEVFS is not set +CONFIG_FEATURE_DEVPTS=y +# CONFIG_FEATURE_CLEAN_UP is not set +CONFIG_FEATURE_SUID=y +# CONFIG_FEATURE_SUID_CONFIG is not set +# CONFIG_FEATURE_SUID_CONFIG_QUIET is not set +# CONFIG_SELINUX is not set + +# +# Build Options +# +# CONFIG_STATIC is not set +# CONFIG_DISABLE_SHARED is not set +# CONFIG_BUILD_LIBBUSYBOX is not set +# CONFIG_FEATURE_FULL_LIBBUSYBOX is not set +# CONFIG_FEATURE_SHARED_BUSYBOX is not set +CONFIG_LFS=y +# USING_CROSS_COMPILER is not set +CROSS_COMPILER_PREFIX="" +EXTRA_CFLAGS_OPTIONS="" +# CONFIG_BUILD_AT_ONCE is not set + +# +# Debugging Options +# +# CONFIG_DEBUG is not set +# CONFIG_NO_DEBUG_LIB is not set +# CONFIG_DMALLOC is not set +# CONFIG_EFENCE is not set +CONFIG_DEBUG_YANK_SUSv2=y + +# +# Installation Options +# +# CONFIG_INSTALL_NO_USR is not set +CONFIG_INSTALL_APPLET_SYMLINKS=y +# CONFIG_INSTALL_APPLET_HARDLINKS is not set +# CONFIG_INSTALL_APPLET_DONT is not set +PREFIX="./_install" + +# +# Busybox Library Tuning +# +CONFIG_MD5_SIZE_VS_SPEED=2 + +# +# Applets +# + +# +# Archival Utilities +# +# CONFIG_AR is not set +# CONFIG_FEATURE_AR_LONG_FILENAMES is not set +# CONFIG_BUNZIP2 is not set +# CONFIG_CPIO is not set +# CONFIG_DPKG is not set +# CONFIG_DPKG_DEB is not set +# CONFIG_FEATURE_DPKG_DEB_EXTRACT_ONLY is not set +# CONFIG_GUNZIP is not set +# CONFIG_FEATURE_GUNZIP_UNCOMPRESS is not set +# CONFIG_GZIP is not set +# CONFIG_RPM2CPIO is not set +# CONFIG_RPM is not set +# CONFIG_TAR is not set +# CONFIG_FEATURE_TAR_CREATE is not set +# CONFIG_FEATURE_TAR_BZIP2 is not set +# CONFIG_FEATURE_TAR_LZMA is not set +# CONFIG_FEATURE_TAR_FROM is not set +# CONFIG_FEATURE_TAR_GZIP is not set +# CONFIG_FEATURE_TAR_COMPRESS is not set +# CONFIG_FEATURE_TAR_OLDGNU_COMPATABILITY is not set +# CONFIG_FEATURE_TAR_GNU_EXTENSIONS is not set +# CONFIG_FEATURE_TAR_LONG_OPTIONS is not set +# CONFIG_UNCOMPRESS is not set +# CONFIG_UNLZMA is not set +# CONFIG_FEATURE_LZMA_FAST is not set +# CONFIG_UNZIP is not set +# CONFIG_FEATURE_UNARCHIVE_TAPE is not set +# CONFIG_FEATURE_DEB_TAR_GZ is not set +# CONFIG_FEATURE_DEB_TAR_BZ2 is not set +# CONFIG_FEATURE_DEB_TAR_LZMA is not set + +# +# Coreutils +# +CONFIG_BASENAME=y +# CONFIG_CAL is not set +CONFIG_CAT=y +# CONFIG_CHGRP is not set +# CONFIG_CHMOD is not set +# CONFIG_CHOWN is not set +# CONFIG_CHROOT is not set +# CONFIG_CMP is not set +# CONFIG_COMM is not set +CONFIG_CP=y +# CONFIG_CUT is not set +# CONFIG_DATE is not set +# CONFIG_FEATURE_DATE_ISOFMT is not set +CONFIG_DD=y +# CONFIG_DF is not set +# CONFIG_DIRNAME is not set +# CONFIG_DOS2UNIX is not set +# CONFIG_UNIX2DOS is not set +# CONFIG_DU is not set +# CONFIG_FEATURE_DU_DEFALT_BLOCKSIZE_1K is not set +CONFIG_ECHO=y +CONFIG_FEATURE_FANCY_ECHO=y +# CONFIG_ENV is not set +# CONFIG_EXPR is not set +# CONFIG_EXPR_MATH_SUPPORT_64 is not set +CONFIG_FALSE=y +# CONFIG_FOLD is not set +# CONFIG_HEAD is not set +# CONFIG_FEATURE_FANCY_HEAD is not set +# CONFIG_HOSTID is not set +# CONFIG_ID is not set +# CONFIG_INSTALL is not set +# CONFIG_LENGTH is not set +CONFIG_LN=y +# CONFIG_LOGNAME is not set +CONFIG_LS=y +# CONFIG_FEATURE_LS_FILETYPES is not set +# CONFIG_FEATURE_LS_FOLLOWLINKS is not set +# CONFIG_FEATURE_LS_RECURSIVE is not set +CONFIG_FEATURE_LS_SORTFILES=y +CONFIG_FEATURE_LS_TIMESTAMPS=y +CONFIG_FEATURE_LS_USERNAME=y +# CONFIG_FEATURE_LS_COLOR is not set +# CONFIG_FEATURE_LS_COLOR_IS_DEFAULT is not set +# CONFIG_MD5SUM is not set +CONFIG_MKDIR=y +# CONFIG_MKFIFO is not set +CONFIG_MKNOD=y +CONFIG_MV=y +# CONFIG_NICE is not set +# CONFIG_NOHUP is not set +# CONFIG_OD is not set +# CONFIG_PRINTENV is not set +# CONFIG_PRINTF is not set +CONFIG_PWD=y +# CONFIG_REALPATH is not set +CONFIG_RM=y +# CONFIG_RMDIR is not set +# CONFIG_SEQ is not set +# CONFIG_SHA1SUM is not set +# CONFIG_SLEEP is not set +# CONFIG_FEATURE_FANCY_SLEEP is not set +# CONFIG_SORT is not set +# CONFIG_FEATURE_SORT_BIG is not set +# CONFIG_STAT is not set +# CONFIG_FEATURE_STAT_FORMAT is not set +# CONFIG_STTY is not set +# CONFIG_SUM is not set +# CONFIG_SYNC is not set +# CONFIG_TAIL is not set +# CONFIG_FEATURE_FANCY_TAIL is not set +# CONFIG_TEE is not set +# CONFIG_FEATURE_TEE_USE_BLOCK_IO is not set +CONFIG_TEST=y +# CONFIG_FEATURE_TEST_64 is not set +CONFIG_TOUCH=y +# CONFIG_TR is not set +# CONFIG_FEATURE_TR_CLASSES is not set +# CONFIG_FEATURE_TR_EQUIV is not set +CONFIG_TRUE=y +# CONFIG_TTY is not set +# CONFIG_UNAME is not set +# CONFIG_UNIQ is not set +CONFIG_USLEEP=y +# CONFIG_UUDECODE is not set +# CONFIG_UUENCODE is not set +# CONFIG_WATCH is not set +# CONFIG_WC is not set +# CONFIG_WHO is not set +# CONFIG_WHOAMI is not set +# CONFIG_YES is not set + +# +# Common options for cp and mv +# +CONFIG_FEATURE_PRESERVE_HARDLINKS=y + +# +# Common options for ls, more and telnet +# +CONFIG_FEATURE_AUTOWIDTH=y + +# +# Common options for df, du, ls +# +# CONFIG_FEATURE_HUMAN_READABLE is not set +# CONFIG_FEATURE_MD5_SHA1_SUM_CHECK is not set + +# +# Console Utilities +# +# CONFIG_CHVT is not set +CONFIG_CLEAR=y +# CONFIG_DEALLOCVT is not set +# CONFIG_DUMPKMAP is not set +# CONFIG_LOADFONT is not set +# CONFIG_LOADKMAP is not set +CONFIG_OPENVT=y +# CONFIG_RESET is not set +# CONFIG_SETCONSOLE is not set +# CONFIG_SETKEYCODES is not set + +# +# Debian Utilities +# +# CONFIG_MKTEMP is not set +# CONFIG_PIPE_PROGRESS is not set +CONFIG_READLINK=y +CONFIG_FEATURE_READLINK_FOLLOW=y +CONFIG_RUN_PARTS=y +# CONFIG_START_STOP_DAEMON is not set +# CONFIG_WHICH is not set + +# +# Editors +# +# CONFIG_AWK is not set +# CONFIG_FEATURE_AWK_MATH is not set +# CONFIG_PATCH is not set +# CONFIG_SED is not set +# CONFIG_VI is not set +# CONFIG_FEATURE_VI_COLON is not set +# CONFIG_FEATURE_VI_YANKMARK is not set +# CONFIG_FEATURE_VI_SEARCH is not set +# CONFIG_FEATURE_VI_USE_SIGNALS is not set +# CONFIG_FEATURE_VI_DOT_CMD is not set +# CONFIG_FEATURE_VI_READONLY is not set +# CONFIG_FEATURE_VI_SETOPTS is not set +# CONFIG_FEATURE_VI_SET is not set +# CONFIG_FEATURE_VI_WIN_RESIZE is not set +# CONFIG_FEATURE_VI_OPTIMIZE_CURSOR is not set + +# +# Finding Utilities +# +# CONFIG_FIND is not set +# CONFIG_FEATURE_FIND_MTIME is not set +# CONFIG_FEATURE_FIND_MMIN is not set +# CONFIG_FEATURE_FIND_PERM is not set +# CONFIG_FEATURE_FIND_TYPE is not set +# CONFIG_FEATURE_FIND_XDEV is not set +# CONFIG_FEATURE_FIND_NEWER is not set +# CONFIG_FEATURE_FIND_INUM is not set +# CONFIG_FEATURE_FIND_EXEC is not set +# CONFIG_GREP is not set +# CONFIG_FEATURE_GREP_EGREP_ALIAS is not set +# CONFIG_FEATURE_GREP_FGREP_ALIAS is not set +# CONFIG_FEATURE_GREP_CONTEXT is not set +# CONFIG_XARGS is not set +# CONFIG_FEATURE_XARGS_SUPPORT_CONFIRMATION is not set +# CONFIG_FEATURE_XARGS_SUPPORT_QUOTES is not set +# CONFIG_FEATURE_XARGS_SUPPORT_TERMOPT is not set +# CONFIG_FEATURE_XARGS_SUPPORT_ZERO_TERM is not set + +# +# Init Utilities +# +# CONFIG_INIT is not set +# CONFIG_FEATURE_USE_INITTAB is not set +# CONFIG_FEATURE_INIT_SCTTY is not set +# CONFIG_FEATURE_EXTRA_QUIET is not set +# CONFIG_FEATURE_INIT_COREDUMPS is not set +# CONFIG_FEATURE_INITRD is not set +CONFIG_HALT=y +# CONFIG_MESG is not set + +# +# Login/Password Management Utilities +# +# CONFIG_FEATURE_SHADOWPASSWDS is not set +# CONFIG_USE_BB_SHADOW is not set +# CONFIG_USE_BB_PWD_GRP is not set +# CONFIG_ADDGROUP is not set +# CONFIG_DELGROUP is not set +# CONFIG_ADDUSER is not set +# CONFIG_DELUSER is not set +# CONFIG_GETTY is not set +# CONFIG_FEATURE_UTMP is not set +# CONFIG_FEATURE_WTMP is not set +# CONFIG_LOGIN is not set +# CONFIG_FEATURE_SECURETTY is not set +# CONFIG_PASSWD is not set +# CONFIG_SU is not set +# CONFIG_SULOGIN is not set +# CONFIG_VLOCK is not set + +# +# Linux Ext2 FS Progs +# +# CONFIG_CHATTR is not set +# CONFIG_E2FSCK is not set +# CONFIG_FSCK is not set +# CONFIG_LSATTR is not set +# CONFIG_MKE2FS is not set +# CONFIG_TUNE2FS is not set +# CONFIG_E2LABEL is not set +# CONFIG_FINDFS is not set + +# +# Linux Module Utilities +# +# CONFIG_INSMOD is not set +# CONFIG_FEATURE_INSMOD_VERSION_CHECKING is not set +# CONFIG_FEATURE_INSMOD_KSYMOOPS_SYMBOLS is not set +# CONFIG_FEATURE_INSMOD_LOADINKMEM is not set +# CONFIG_FEATURE_INSMOD_LOAD_MAP is not set +# CONFIG_FEATURE_INSMOD_LOAD_MAP_FULL is not set +# CONFIG_RMMOD is not set +# CONFIG_LSMOD is not set +# CONFIG_FEATURE_LSMOD_PRETTY_2_6_OUTPUT is not set +# CONFIG_MODPROBE is not set +# CONFIG_FEATURE_MODPROBE_MULTIPLE_OPTIONS is not set +# CONFIG_FEATURE_CHECK_TAINTED_MODULE is not set +# CONFIG_FEATURE_2_4_MODULES is not set +# CONFIG_FEATURE_2_6_MODULES is not set +# CONFIG_FEATURE_QUERY_MODULE_INTERFACE is not set + +# +# Linux System Utilities +# +CONFIG_DMESG=y +CONFIG_FBSET=y +CONFIG_FEATURE_FBSET_FANCY=y +# CONFIG_FEATURE_FBSET_READMODE is not set +# CONFIG_FDFLUSH is not set +# CONFIG_FDFORMAT is not set +# CONFIG_FDISK is not set +FDISK_SUPPORT_LARGE_DISKS=y +# CONFIG_FEATURE_FDISK_WRITABLE is not set +# CONFIG_FEATURE_AIX_LABEL is not set +# CONFIG_FEATURE_SGI_LABEL is not set +# CONFIG_FEATURE_SUN_LABEL is not set +# CONFIG_FEATURE_OSF_LABEL is not set +# CONFIG_FEATURE_FDISK_ADVANCED is not set +# CONFIG_FREERAMDISK is not set +# CONFIG_FSCK_MINIX is not set +# CONFIG_MKFS_MINIX is not set +# CONFIG_FEATURE_MINIX2 is not set +# CONFIG_GETOPT is not set +# CONFIG_HEXDUMP is not set +# CONFIG_HWCLOCK is not set +# CONFIG_FEATURE_HWCLOCK_LONGOPTIONS is not set +# CONFIG_FEATURE_HWCLOCK_ADJTIME_FHS is not set +# CONFIG_IPCRM is not set +# CONFIG_IPCS is not set +# CONFIG_LOSETUP is not set +# CONFIG_MDEV is not set +# CONFIG_FEATURE_MDEV_CONF is not set +# CONFIG_MKSWAP is not set +# CONFIG_MORE is not set +# CONFIG_FEATURE_USE_TERMIOS is not set +CONFIG_MOUNT=y +# CONFIG_FEATURE_MOUNT_NFS is not set +# CONFIG_PIVOT_ROOT is not set +# CONFIG_RDATE is not set +# CONFIG_READPROFILE is not set +# CONFIG_SETARCH is not set +# CONFIG_SWAPONOFF is not set +# CONFIG_SWITCH_ROOT is not set +CONFIG_UMOUNT=y +# CONFIG_FEATURE_UMOUNT_ALL is not set + +# +# Common options for mount/umount +# +# CONFIG_FEATURE_MOUNT_LOOP is not set +# CONFIG_FEATURE_MTAB_SUPPORT is not set + +# +# Miscellaneous Utilities +# +# CONFIG_ADJTIMEX is not set +# CONFIG_BBCONFIG is not set +# CONFIG_CROND is not set +# CONFIG_FEATURE_CROND_CALL_SENDMAIL is not set +# CONFIG_CRONTAB is not set +# CONFIG_DC is not set +# CONFIG_DEVFSD is not set +# CONFIG_DEVFSD_MODLOAD is not set +# CONFIG_DEVFSD_FG_NP is not set +# CONFIG_DEVFSD_VERBOSE is not set +# CONFIG_EJECT is not set +# CONFIG_LAST is not set +# CONFIG_LESS is not set +# CONFIG_FEATURE_LESS_BRACKETS is not set +# CONFIG_FEATURE_LESS_FLAGS is not set +# CONFIG_FEATURE_LESS_FLAGCS is not set +# CONFIG_FEATURE_LESS_MARKS is not set +# CONFIG_FEATURE_LESS_REGEXP is not set +# CONFIG_HDPARM is not set +# CONFIG_FEATURE_HDPARM_GET_IDENTITY is not set +# CONFIG_FEATURE_HDPARM_HDIO_SCAN_HWIF is not set +# CONFIG_FEATURE_HDPARM_HDIO_UNREGISTER_HWIF is not set +# CONFIG_FEATURE_HDPARM_HDIO_DRIVE_RESET is not set +# CONFIG_FEATURE_HDPARM_HDIO_TRISTATE_HWIF is not set +# CONFIG_FEATURE_HDPARM_HDIO_GETSET_DMA is not set +CONFIG_MAKEDEVS=y +# CONFIG_FEATURE_MAKEDEVS_LEAF is not set +CONFIG_FEATURE_MAKEDEVS_TABLE=y +# CONFIG_MOUNTPOINT is not set +# CONFIG_MT is not set +# CONFIG_RUNLEVEL is not set +# CONFIG_RX is not set +# CONFIG_STRINGS is not set +# CONFIG_SETSID is not set +# CONFIG_TIME is not set +# CONFIG_WATCHDOG is not set + +# +# Networking Utilities +# +CONFIG_FEATURE_IPV6=y +# CONFIG_ARPING is not set +# CONFIG_DNSD is not set +# CONFIG_ETHER_WAKE is not set +# CONFIG_FAKEIDENTD is not set +# CONFIG_FTPGET is not set +# CONFIG_FTPPUT is not set +CONFIG_HOSTNAME=y +# CONFIG_HTTPD is not set +# CONFIG_FEATURE_HTTPD_USAGE_FROM_INETD_ONLY is not set +# CONFIG_FEATURE_HTTPD_BASIC_AUTH is not set +# CONFIG_FEATURE_HTTPD_AUTH_MD5 is not set +# CONFIG_FEATURE_HTTPD_RELOAD_CONFIG_SIGHUP is not set +# CONFIG_FEATURE_HTTPD_SETUID is not set +# CONFIG_FEATURE_HTTPD_CONFIG_WITH_MIME_TYPES is not set +# CONFIG_FEATURE_HTTPD_CGI is not set +# CONFIG_FEATURE_HTTPD_CONFIG_WITH_SCRIPT_INTERPR is not set +# CONFIG_FEATURE_HTTPD_SET_REMOTE_PORT_TO_ENV is not set +# CONFIG_FEATURE_HTTPD_ENCODE_URL_STR is not set +CONFIG_IFCONFIG=y +# CONFIG_FEATURE_IFCONFIG_STATUS is not set +# CONFIG_FEATURE_IFCONFIG_SLIP is not set +# CONFIG_FEATURE_IFCONFIG_MEMSTART_IOADDR_IRQ is not set +# CONFIG_FEATURE_IFCONFIG_HW is not set +CONFIG_FEATURE_IFCONFIG_BROADCAST_PLUS=y +CONFIG_IFUPDOWN=y +CONFIG_FEATURE_IFUPDOWN_IP=y +CONFIG_FEATURE_IFUPDOWN_IP_BUILTIN=y +CONFIG_FEATURE_IFUPDOWN_IPV4=y +CONFIG_FEATURE_IFUPDOWN_IPV6=y +# CONFIG_FEATURE_IFUPDOWN_IPX is not set +CONFIG_FEATURE_IFUPDOWN_MAPPING=y +# CONFIG_INETD is not set +# CONFIG_FEATURE_INETD_SUPPORT_BILTIN_ECHO is not set +# CONFIG_FEATURE_INETD_SUPPORT_BILTIN_DISCARD is not set +# CONFIG_FEATURE_INETD_SUPPORT_BILTIN_TIME is not set +# CONFIG_FEATURE_INETD_SUPPORT_BILTIN_DAYTIME is not set +# CONFIG_FEATURE_INETD_SUPPORT_BILTIN_CHARGEN is not set +# CONFIG_FEATURE_INETD_RPC is not set +CONFIG_IP=y +CONFIG_FEATURE_IP_ADDRESS=y +CONFIG_FEATURE_IP_LINK=y +CONFIG_FEATURE_IP_ROUTE=y +# CONFIG_FEATURE_IP_TUNNEL is not set +# CONFIG_IPCALC is not set +# CONFIG_FEATURE_IPCALC_FANCY is not set +# CONFIG_IPADDR is not set +# CONFIG_IPLINK is not set +# CONFIG_IPROUTE is not set +# CONFIG_IPTUNNEL is not set +# CONFIG_NAMEIF is not set +# CONFIG_NC is not set +# CONFIG_NC_GAPING_SECURITY_HOLE is not set +# CONFIG_NETSTAT is not set +# CONFIG_NSLOOKUP is not set +# CONFIG_PING is not set +# CONFIG_FEATURE_FANCY_PING is not set +# CONFIG_PING6 is not set +# CONFIG_FEATURE_FANCY_PING6 is not set +# CONFIG_ROUTE is not set +# CONFIG_TELNET is not set +# CONFIG_FEATURE_TELNET_TTYPE is not set +# CONFIG_FEATURE_TELNET_AUTOLOGIN is not set +# CONFIG_TELNETD is not set +# CONFIG_FEATURE_TELNETD_INETD is not set +CONFIG_TFTP=y +CONFIG_FEATURE_TFTP_GET=y +# CONFIG_FEATURE_TFTP_PUT is not set +CONFIG_FEATURE_TFTP_BLOCKSIZE=y +# CONFIG_FEATURE_TFTP_DEBUG is not set +# CONFIG_TRACEROUTE is not set +# CONFIG_FEATURE_TRACEROUTE_VERBOSE is not set +# CONFIG_FEATURE_TRACEROUTE_SOURCE_ROUTE is not set +# CONFIG_FEATURE_TRACEROUTE_USE_ICMP is not set +# CONFIG_VCONFIG is not set +CONFIG_WGET=y +# CONFIG_FEATURE_WGET_STATUSBAR is not set +# CONFIG_FEATURE_WGET_AUTHENTICATION is not set +CONFIG_FEATURE_WGET_IP6_LITERAL=y + +# +# udhcp Server/Client +# +# CONFIG_UDHCPD is not set +CONFIG_UDHCPC=y +# CONFIG_DUMPLEASES is not set +CONFIG_FEATURE_UDHCP_SYSLOG=y +# CONFIG_FEATURE_UDHCP_DEBUG is not set +# CONFIG_ZCIP is not set + +# +# Process Utilities +# +# CONFIG_FREE is not set +# CONFIG_FUSER is not set +# CONFIG_KILL is not set +# CONFIG_KILLALL is not set +# CONFIG_PIDOF is not set +# CONFIG_FEATURE_PIDOF_SINGLE is not set +# CONFIG_FEATURE_PIDOF_OMIT is not set +# CONFIG_PS is not set +# CONFIG_FEATURE_PS_WIDE is not set +# CONFIG_RENICE is not set +# CONFIG_BB_SYSCTL is not set +# CONFIG_TOP is not set +# CONFIG_FEATURE_TOP_CPU_USAGE_PERCENTAGE is not set +# CONFIG_UPTIME is not set + +# +# Shells +# +CONFIG_FEATURE_SH_IS_ASH=y +# CONFIG_FEATURE_SH_IS_HUSH is not set +# CONFIG_FEATURE_SH_IS_LASH is not set +# CONFIG_FEATURE_SH_IS_MSH is not set +# CONFIG_FEATURE_SH_IS_NONE is not set +CONFIG_ASH=y + +# +# Ash Shell Options +# +# CONFIG_ASH_JOB_CONTROL is not set +# CONFIG_ASH_READ_NCHARS is not set +# CONFIG_ASH_READ_TIMEOUT is not set +CONFIG_ASH_ALIAS=y +CONFIG_ASH_MATH_SUPPORT=y +# CONFIG_ASH_MATH_SUPPORT_64 is not set +CONFIG_ASH_GETOPTS=y +CONFIG_ASH_CMDCMD=y +# CONFIG_ASH_BUILTIN_ECHO is not set +# CONFIG_ASH_MAIL is not set +CONFIG_ASH_OPTIMIZE_FOR_SIZE=y +# CONFIG_ASH_RANDOM_SUPPORT is not set +# CONFIG_ASH_EXPAND_PRMT is not set +# CONFIG_HUSH is not set +# CONFIG_LASH is not set +# CONFIG_MSH is not set + +# +# Bourne Shell Options +# +CONFIG_FEATURE_SH_EXTRA_QUIET=y +CONFIG_FEATURE_SH_STANDALONE_SHELL=y +CONFIG_FEATURE_COMMAND_EDITING=y +# CONFIG_FEATURE_COMMAND_EDITING_VI is not set +CONFIG_FEATURE_COMMAND_HISTORY=15 +# CONFIG_FEATURE_COMMAND_SAVEHISTORY is not set +CONFIG_FEATURE_COMMAND_TAB_COMPLETION=y +# CONFIG_FEATURE_COMMAND_USERNAME_COMPLETION is not set +# CONFIG_FEATURE_SH_FANCY_PROMPT is not set + +# +# System Logging Utilities +# +# CONFIG_SYSLOGD is not set +# CONFIG_FEATURE_ROTATE_LOGFILE is not set +# CONFIG_FEATURE_REMOTE_LOG is not set +# CONFIG_FEATURE_IPC_SYSLOG is not set +CONFIG_FEATURE_IPC_SYSLOG_BUFFER_SIZE=0 +# CONFIG_LOGREAD is not set +# CONFIG_FEATURE_LOGREAD_REDUCED_LOCKING is not set +# CONFIG_KLOGD is not set +# CONFIG_LOGGER is not set From myles at pel.cs.byu.edu Fri Jan 11 21:29:11 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Fri, 11 Jan 2008 13:29:11 -0700 Subject: [LinuxBIOS] r3021 build service In-Reply-To: <476AC059.3060604@AMD.com> References: <476A17EF.1040308@gmail.com> <476AC059.3060604@AMD.com> Message-ID: <2831fecf0801111229h17a146bm584b1e0ddcaf5222@mail.gmail.com> Here's my attempt at fixing abuild for serengeti_cheetah_fam10. It's pretty trivial, since I'm just using the ROM_IMAGE_SIZE in Config.lb and putting it in Config-abuild.lb. When I reduce this size (past what it is in Config-abuild.lb), it gives me the same overlap error in my system that abuild is seeing. I also added XIP_ROM_SIZE, although I admit freely that I don't know anything about this variable. I just wanted to make it match Marc's Config.lb. Maybe the right thing to do would be to remove both XIP_ROM_SIZE references in Config-abuild.lb Either way, I think the ROM_IMAGE_SIZE change will help. Myles Signed-off-by: Myles Watson On Dec 20, 2007 12:19 PM, Marc Jones wrote: > > Corey Osgood wrote: > > Corey Osgood wrote: > > > >> On Dec 19, 2007 4:26 PM, LinuxBIOS information >> > wrote: > >> > >> Dear LinuxBIOS readers! > >> > >> This is the automated build check service of LinuxBIOS. > >> > >> The developer "cozzie" checked in revision 3021 to > >> the LinuxBIOS source repository and caused the following > >> changes: > >> > >> Change Log: > >> More abuild fixes, this should be the last (trivial) > >> > >> Signed-off-by: Corey Osgood < corey.osgood at gmail.com > >> > > >> Acked-by: Corey Osgood >> > > >> > >> > >> > >> Build Log: > >> Compilation of amd:serengeti_cheetah_fam10 is still broken > >> See the error log at > >> http://qa.linuxbios.org/log_buildbrd.php?revision=3021&device=serengeti_cheetah_fam10&vendor=amd > >> > >> > >> > >> Oh for cripe's sake, ld now? Will fix when I make it home tonight. > >> > >> -Corey > >> > > > > Scratch that, someone else can wrap it up. I don't know if it just needs > > a ROM_SIZE increase or something deeper is wrong, I've been completely > > unable to reproduce the error. Someone with access to the build server > > or a similar setup is probably the best candidate to fix this (I've done > > my share ;-) ) > > > > -Corey > > > > > > Corey, > > I looked at the output and I don't see anything obvious. It doesn't fail > for me either. I'll work with Stefan when he is able to look at it. > > Marc > > -- > Marc Jones > Senior Firmware Engineer > (970) 226-9684 Office > mailto:Marc.Jones at amd.com > http://www.amd.com/embeddedprocessors > > > > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > -------------- next part -------------- A non-text attachment was scrubbed... Name: fam10_abuild_fix.diff Type: text/x-patch Size: 727 bytes Desc: not available URL: From svn at openbios.org Fri Jan 11 21:46:46 2008 From: svn at openbios.org (svn at openbios.org) Date: Fri, 11 Jan 2008 21:46:46 +0100 Subject: [LinuxBIOS] r94 - buildrom-devel/packages/linuxbios Message-ID: Author: ward Date: 2008-01-11 21:46:46 +0100 (Fri, 11 Jan 2008) New Revision: 94 Modified: buildrom-devel/packages/linuxbios/norwich-linuxbios.mk Log: This spurious echo sneaked in in r90 but breaks the build for the norwich board. This is a trivial patch. Signed-off-by: Ward Vandewege Acked-by: Ward Vandewege Modified: buildrom-devel/packages/linuxbios/norwich-linuxbios.mk =================================================================== --- buildrom-devel/packages/linuxbios/norwich-linuxbios.mk 2008-01-11 20:02:53 UTC (rev 93) +++ buildrom-devel/packages/linuxbios/norwich-linuxbios.mk 2008-01-11 20:46:46 UTC (rev 94) @@ -1,6 +1,5 @@ # This is the Generic LinuxBIOS target -echo $(LBV2_TAG) ifeq ($(CONFIG_PLATFORM),y) ifeq ($(LBV2_TAG),) $(error You need to specify a version to pull in your platform config) From marc.jones at amd.com Fri Jan 11 21:57:46 2008 From: marc.jones at amd.com (Marc Jones) Date: Fri, 11 Jan 2008 13:57:46 -0700 Subject: [LinuxBIOS] INIT detected. In-Reply-To: <1200080661.2777.30.camel@biosbreath> References: <1200080661.2777.30.camel@biosbreath> Message-ID: <4787D84A.9080700@amd.com> Steve Isaacs wrote: > Is this message normal or does it indicate a problem that needs to be > corrected? > > INIT detected from ---- {APICID = 00 NODEID = 00 COREID = 00} --- > > > Issuing SOFT_RESET... > > > Looking at the code this is emitted in model_fxx/init_cpus.c when > cpu_init_detectedx is non-zero. > > Thanks, > > Steve > > Steve, This could indicate a real problem. It means that the core was unexpectedly reset at some point. This is checked in cache_as_ram.inc. Look for /* check if cpu_init_detected */. If the reset is intentional, the reset code should set/clear the bit in the msr by calling set_bios_reset(); I have seen unintentional resets caused by AP init and/or CAR and memory init issues. You can get into some funny race conditions with AP and BSP using the same CAR location but that is just a guess. I hope that gives you some ideas about what might be going wrong and where to start looking. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From marc.jones at amd.com Fri Jan 11 22:20:17 2008 From: marc.jones at amd.com (Marc Jones) Date: Fri, 11 Jan 2008 14:20:17 -0700 Subject: [LinuxBIOS] r3021 build service In-Reply-To: <2831fecf0801111229h17a146bm584b1e0ddcaf5222@mail.gmail.com> References: <476A17EF.1040308@gmail.com> <476AC059.3060604@AMD.com> <2831fecf0801111229h17a146bm584b1e0ddcaf5222@mail.gmail.com> Message-ID: <4787DD91.60808@amd.com> Myles Watson wrote: > Here's my attempt at fixing abuild for serengeti_cheetah_fam10. > > It's pretty trivial, since I'm just using the ROM_IMAGE_SIZE in > Config.lb and putting it in Config-abuild.lb. When I reduce this size > (past what it is in Config-abuild.lb), it gives me the same overlap > error in my system that abuild is seeing. > > I also added XIP_ROM_SIZE, although I admit freely that I don't know > anything about this variable. I just wanted to make it match Marc's > Config.lb. > > Maybe the right thing to do would be to remove both XIP_ROM_SIZE > references in Config-abuild.lb > > Either way, I think the ROM_IMAGE_SIZE change will help. Myles, Thanks, the bigger problem is that the rom generated by the auto abuild is larger than expected. We are investigating the tool chain. Once we understand what is going on I will feel more comfortable with increasing the ROM_IMAGE_SIZE. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From Marc.Karasek at Sun.COM Fri Jan 11 22:32:33 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Fri, 11 Jan 2008 16:32:33 -0500 Subject: [LinuxBIOS] AMD SimNOW question In-Reply-To: <2831fecf0801111147l6356254ay3dc392a174446dfd@mail.gmail.com> References: <4783CA87.4070600@sun.com> <2831fecf0801081223u25f7a96cheae2779637cf4189@mail.gmail.com> <4783F2BB.8000902@sun.com> <01e801c85243$52ac9e30$a023040a@chimp> <20080108222125.GC28312@cosmic.amd.com> <4783FB7F.4000205@sun.com> <13426df10801101552k105385eaifa1d0771839da3b5@mail.gmail.com> <4787BA26.8060700@sun.com> <2831fecf0801111147l6356254ay3dc392a174446dfd@mail.gmail.com> Message-ID: <4787E071.1050306@sun.com> Is there anyway under SimNow to send the console output to a log file. I have linuxbios up and running :-) but the Linux kernel I have as a boot loader is crashing.. I have tried to stop it at the point when it starts dmping the same message to the screen but it is nearly impossible to time it right. /********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 *********************/ Myles Watson wrote: > Marc, > > I sent the wrong one for serengeti-cheetah last time. Sorry. > > Myles > > On Jan 11, 2008 11:49 AM, Marc Karasek wrote: > >> I have managed to cobble together a build structure that tries to build. >> >> It gets to the point of building the linuxbios image and it chokes >> because the image is to large for the romsize. >> >> Can someone shed some light on what Config.lb should be set to to get >> this to compile. >> >> The payload buildrom is generating is 790,000+ bytes big. >> >> /********************* >> Marc Karasek >> MTS >> Sun Microsystems >> mailto:marc.karasek at sun.com >> ph:770.360.6415 >> *********************/ >> >> >> >> >> ron minnich wrote: >> >>> On Jan 8, 2008 2:38 PM, Marc Karasek wrote: >>> >>> >>>> I have found the main problem with svn. It looks like if you use svn co >>>> http:// it will use the proxy settings under servers. If you do a svn >>>> co svn:// it tries to do a dns lookup, which fails behind a proxy server >>>> :-(. I have not been able to find any info on setting svn up to use a >>>> proxy when doing svn:// type checkouts. >>>> >>>> >>> There is a way to do it, maybe: http://subversion.tigris.org/faq.html#proxy >>> >>> ron >>> >>> From myles at pel.cs.byu.edu Fri Jan 11 22:44:56 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Fri, 11 Jan 2008 14:44:56 -0700 Subject: [LinuxBIOS] AMD SimNOW question In-Reply-To: <4787E071.1050306@sun.com> References: <4783CA87.4070600@sun.com> <2831fecf0801081223u25f7a96cheae2779637cf4189@mail.gmail.com> <4783F2BB.8000902@sun.com> <01e801c85243$52ac9e30$a023040a@chimp> <20080108222125.GC28312@cosmic.amd.com> <4783FB7F.4000205@sun.com> <13426df10801101552k105385eaifa1d0771839da3b5@mail.gmail.com> <4787BA26.8060700@sun.com> <2831fecf0801111147l6356254ay3dc392a174446dfd@mail.gmail.com> <4787E071.1050306@sun.com> Message-ID: <00e301c8549b$357abf40$2023040a@chimp> There are a couple of ways, which you can find here: http://linuxbios.org/AMD_SimNow if you want it to go to a file, instead of cat /home/myles/.simnow/com1/simnow_out try cat /home/myles/.simnow/com1/simnow_out > myfile.log otherwise, if you're using snserial there is some option to do that as well. Myles > -----Original Message----- > From: Marc.Karasek at Sun.COM [mailto:Marc.Karasek at Sun.COM] > Sent: Friday, January 11, 2008 2:33 PM > To: Myles Watson; LinuxBIOS > Subject: Re: [LinuxBIOS] AMD SimNOW question > > Is there anyway under SimNow to send the console output to a log file. > > I have linuxbios up and running :-) but the Linux kernel I have as a > boot loader is crashing.. I have tried to stop it at the point when it > starts dmping the same message to the screen but it is nearly impossible > to time it right. > > /********************* > Marc Karasek > MTS > Sun Microsystems > mailto:marc.karasek at sun.com > ph:770.360.6415 > *********************/ > > > > Myles Watson wrote: > > Marc, > > > > I sent the wrong one for serengeti-cheetah last time. Sorry. > > > > Myles > > > > On Jan 11, 2008 11:49 AM, Marc Karasek wrote: > > > >> I have managed to cobble together a build structure that tries to > build. > >> > >> It gets to the point of building the linuxbios image and it chokes > >> because the image is to large for the romsize. > >> > >> Can someone shed some light on what Config.lb should be set to to get > >> this to compile. > >> > >> The payload buildrom is generating is 790,000+ bytes big. > >> > >> /********************* > >> Marc Karasek > >> MTS > >> Sun Microsystems > >> mailto:marc.karasek at sun.com > >> ph:770.360.6415 > >> *********************/ > >> > >> > >> > >> > >> ron minnich wrote: > >> > >>> On Jan 8, 2008 2:38 PM, Marc Karasek wrote: > >>> > >>> > >>>> I have found the main problem with svn. It looks like if you use svn > co > >>>> http:// it will use the proxy settings under servers. If you do a > svn > >>>> co svn:// it tries to do a dns lookup, which fails behind a proxy > server > >>>> :-(. I have not been able to find any info on setting svn up to use > a > >>>> proxy when doing svn:// type checkouts. > >>>> > >>>> > >>> There is a way to do it, maybe: > http://subversion.tigris.org/faq.html#proxy > >>> > >>> ron > >>> > >>> From jordan.crouse at amd.com Fri Jan 11 22:56:06 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Fri, 11 Jan 2008 14:56:06 -0700 Subject: [LinuxBIOS] [BUILDROM] Consolidate all the geode Linuxbios targets Message-ID: <20080111215606.GA17668@cosmic.amd.com> I'm about to introduce some new code, but first, this is some cleanup of the linuxbios/ directory - all the geode targets were the same, so I consolidated them. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. -------------- next part -------------- [BUILDROM] Consolidate all the geode Linuxbios targets All the Geode LinuxBIOS v2 targets do the same thing, so consolidate them. Signed-off-by: Jordan Crouse Index: buildrom-devel/packages/linuxbios/alix1c-linuxbios.mk =================================================================== --- buildrom-devel.orig/packages/linuxbios/alix1c-linuxbios.mk 2008-01-11 12:16:03.000000000 -0700 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -1,38 +0,0 @@ -# This is the Generic LinuxBIOS target - -ifeq ($(CONFIG_PLATFORM),y) -ifeq ($(LBV2_TAG),) -$(error You need to specify a version to pull in your platform config) -endif -endif - -LBV2_BASE_DIR=svn -LBV2_URL=svn://openbios.org/repos/trunk/LinuxBIOSv2 -LBV2_TARBALL=linuxbios-svn-$(LBV2_TAG).tar.gz -LBV2_PAYLOAD_TARGET=$(LBV2_BUILD_DIR)/payload.elf -VSA_URL=http://www.amd.com/files/connectivitysolutions/geode/geode_lx/ -LBV2_VSA=lx_vsa.36k.bin -TARGET_ROM = $(LINUXBIOS_VENDOR)-$(LINUXBIOS_BOARD).rom - -include $(PACKAGE_DIR)/linuxbios/linuxbios.inc - -$(SOURCE_DIR)/$(LBV2_VSA): - @ echo "Fetching the VSA code..." - wget -P $(SOURCE_DIR) $(VSA_URL)/$(LBV2_VSA).gz -O $@ - -$(SOURCE_DIR)/$(LBV2_TARBALL): - @ echo "Fetching the LinuxBIOS code..." - @ mkdir -p $(SOURCE_DIR)/linuxbios - @ $(BIN_DIR)/fetchsvn.sh $(LBV2_URL) $(SOURCE_DIR)/linuxbios \ - $(LBV2_TAG) $(SOURCE_DIR)/$(LBV2_TARBALL) \ - > $(LBV2_FETCH_LOG) 2>&1 - -# Special rule - append the VSA - -$(OUTPUT_DIR)/$(TARGET_ROM): $(LBV2_OUTPUT) $(SOURCE_DIR)/$(LBV2_VSA) - @ mkdir -p $(OUTPUT_DIR) - @ cat $(SOURCE_DIR)/$(LBV2_VSA) $(LBV2_OUTPUT) > $@ - -linuxbios: $(OUTPUT_DIR)/$(TARGET_ROM) -linuxbios-clean: generic-linuxbios-clean -linuxbios-distclean: generic-linuxbios-distclean Index: buildrom-devel/packages/linuxbios/geodelx-linuxbios.mk =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ buildrom-devel/packages/linuxbios/geodelx-linuxbios.mk 2008-01-11 14:17:05.000000000 -0700 @@ -0,0 +1,39 @@ +# This target supports all Geode LX platforms - it handles downloading +# the VSA as an additional step + +ifeq ($(CONFIG_PLATFORM),y) +ifeq ($(LBV2_TAG),) +$(error You need to specify a version to pull in your platform config) +endif +endif + +LBV2_BASE_DIR=svn +LBV2_URL=svn://openbios.org/repos/trunk/LinuxBIOSv2 +LBV2_TARBALL=linuxbios-svn-$(LBV2_TAG).tar.gz +LBV2_PAYLOAD_TARGET=$(LBV2_BUILD_DIR)/payload.elf +VSA_URL=http://www.amd.com/files/connectivitysolutions/geode/geode_lx/ +LBV2_VSA=lx_vsa.36k.bin +TARGET_ROM = $(LINUXBIOS_VENDOR)-$(LINUXBIOS_BOARD).rom + +include $(PACKAGE_DIR)/linuxbios/linuxbios.inc + +$(SOURCE_DIR)/$(LBV2_VSA): + @ echo "Fetching the VSA code..." + wget -P $(SOURCE_DIR) $(VSA_URL)/$(LBV2_VSA).gz -O $@ + +$(SOURCE_DIR)/$(LBV2_TARBALL): + @ echo "Fetching the LinuxBIOS code..." + @ mkdir -p $(SOURCE_DIR)/linuxbios + @ $(BIN_DIR)/fetchsvn.sh $(LBV2_URL) $(SOURCE_DIR)/linuxbios \ + $(LBV2_TAG) $(SOURCE_DIR)/$(LBV2_TARBALL) \ + > $(LBV2_FETCH_LOG) 2>&1 + +# Special rule - append the VSA + +$(OUTPUT_DIR)/$(TARGET_ROM): $(LBV2_OUTPUT) $(SOURCE_DIR)/$(LBV2_VSA) + @ mkdir -p $(OUTPUT_DIR) + @ cat $(SOURCE_DIR)/$(LBV2_VSA) $(LBV2_OUTPUT) > $@ + +linuxbios: $(OUTPUT_DIR)/$(TARGET_ROM) +linuxbios-clean: generic-linuxbios-clean +linuxbios-distclean: generic-linuxbios-distclean Index: buildrom-devel/packages/linuxbios/msm800sev-linuxbios.mk =================================================================== --- buildrom-devel.orig/packages/linuxbios/msm800sev-linuxbios.mk 2008-01-11 12:16:08.000000000 -0700 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -1,38 +0,0 @@ -# This is the Generic LinuxBIOS target - -ifeq ($(CONFIG_PLATFORM),y) -ifeq ($(LBV2_TAG),) -$(error You need to specify a version to pull in your platform config) -endif -endif - -LBV2_BASE_DIR=svn -LBV2_URL=svn://openbios.org/repos/trunk/LinuxBIOSv2 -LBV2_TARBALL=linuxbios-svn-$(LBV2_TAG).tar.gz -LBV2_PAYLOAD_TARGET=$(LBV2_BUILD_DIR)/payload.elf -VSA_URL=http://www.amd.com/files/connectivitysolutions/geode/geode_lx/ -LBV2_VSA=lx_vsa.36k.bin -TARGET_ROM = $(LINUXBIOS_VENDOR)-$(LINUXBIOS_BOARD).rom - -include $(PACKAGE_DIR)/linuxbios/linuxbios.inc - -$(SOURCE_DIR)/$(LBV2_VSA): - @ echo "Fetching the VSA code..." - wget -P $(SOURCE_DIR) $(VSA_URL)/$(LBV2_VSA).gz -O $@ - -$(SOURCE_DIR)/$(LBV2_TARBALL): - @ echo "Fetching the LinuxBIOS code..." - @ mkdir -p $(SOURCE_DIR)/linuxbios - @ $(BIN_DIR)/fetchsvn.sh $(LBV2_URL) $(SOURCE_DIR)/linuxbios \ - $(LBV2_TAG) $(SOURCE_DIR)/$(LBV2_TARBALL) \ - > $(LBV2_FETCH_LOG) 2>&1 - -# Special rule - append the VSA - -$(OUTPUT_DIR)/$(TARGET_ROM): $(LBV2_OUTPUT) $(SOURCE_DIR)/$(LBV2_VSA) - @ mkdir -p $(OUTPUT_DIR) - @ cat $(SOURCE_DIR)/$(LBV2_VSA) $(LBV2_OUTPUT) > $@ - -linuxbios: $(OUTPUT_DIR)/$(TARGET_ROM) -linuxbios-clean: generic-linuxbios-clean -linuxbios-distclean: generic-linuxbios-distclean Index: buildrom-devel/packages/linuxbios/norwich-linuxbios.mk =================================================================== --- buildrom-devel.orig/packages/linuxbios/norwich-linuxbios.mk 2008-01-11 12:16:11.000000000 -0700 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -1,41 +0,0 @@ -# This is the Generic LinuxBIOS target - -echo $(LBV2_TAG) -ifeq ($(CONFIG_PLATFORM),y) -ifeq ($(LBV2_TAG),) -$(error You need to specify a version to pull in your platform config) -else -$(warning You specified $(LBV2_TAG) a version to pull in your platform config) -endif -endif - -LBV2_BASE_DIR=svn -LBV2_URL=svn://openbios.org/repos/trunk/LinuxBIOSv2 -LBV2_TARBALL=linuxbios-svn-$(LBV2_TAG).tar.gz -LBV2_PAYLOAD_TARGET=$(LBV2_BUILD_DIR)/payload.elf -VSA_URL=http://www.amd.com/files/connectivitysolutions/geode/geode_lx/ -LBV2_VSA=lx_vsa.36k.bin -TARGET_ROM = $(LINUXBIOS_VENDOR)-$(LINUXBIOS_BOARD).rom - -include $(PACKAGE_DIR)/linuxbios/linuxbios.inc - -$(SOURCE_DIR)/$(LBV2_VSA): - @ echo "Fetching the VSA code..." - wget -P $(SOURCE_DIR) $(VSA_URL)/$(LBV2_VSA).gz -O $@ - -$(SOURCE_DIR)/$(LBV2_TARBALL): - @ echo "Fetching the LinuxBIOS rev $(LBV2_TAG) code..." - @ mkdir -p $(SOURCE_DIR)/linuxbios - @ $(BIN_DIR)/fetchsvn.sh $(LBV2_URL) $(SOURCE_DIR)/linuxbios \ - $(LBV2_TAG) $(SOURCE_DIR)/$(LBV2_TARBALL) \ - > $(LBV2_FETCH_LOG) 2>&1 - -# Special rule - append the VSA - -$(OUTPUT_DIR)/$(TARGET_ROM): $(LBV2_OUTPUT) $(SOURCE_DIR)/$(LBV2_VSA) - @ mkdir -p $(OUTPUT_DIR) - @ cat $(SOURCE_DIR)/$(LBV2_VSA) $(LBV2_OUTPUT) > $@ - -linuxbios: $(OUTPUT_DIR)/$(TARGET_ROM) -linuxbios-clean: generic-linuxbios-clean -linuxbios-distclean: generic-linuxbios-distclean Index: buildrom-devel/config/platforms/alix1c.conf =================================================================== --- buildrom-devel.orig/config/platforms/alix1c.conf 2008-01-11 13:39:10.000000000 -0700 +++ buildrom-devel/config/platforms/alix1c.conf 2008-01-11 13:39:30.000000000 -0700 @@ -12,7 +12,7 @@ # Targets KERNEL_MK=$(PACKAGE_DIR)/kernel/alix1c-kernel.mk -LBV2_MK=$(PACKAGE_DIR)/linuxbios/alix1c-linuxbios.mk +LBV2_MK=$(PACKAGE_DIR)/linuxbios/geodelx-linuxbios.mk # kernel configuration (for LAB) Index: buildrom-devel/config/platforms/db800.conf =================================================================== --- buildrom-devel.orig/config/platforms/db800.conf 2008-01-11 13:39:10.000000000 -0700 +++ buildrom-devel/config/platforms/db800.conf 2008-01-11 13:39:39.000000000 -0700 @@ -14,7 +14,7 @@ # Use the same settings as the Norwich platform KERNEL_MK=$(PACKAGE_DIR)/kernel/norwich-kernel.mk -LBV2_MK=$(PACKAGE_DIR)/linuxbios/norwich-linuxbios.mk +LBV2_MK=$(PACKAGE_DIR)/linuxbios/geodelx-linuxbios.mk # kernel configuration (for LAB) # Use the same settings as the Norwich platform Index: buildrom-devel/config/platforms/dbe61.conf =================================================================== --- buildrom-devel.orig/config/platforms/dbe61.conf 2008-01-11 13:39:10.000000000 -0700 +++ buildrom-devel/config/platforms/dbe61.conf 2008-01-11 13:39:49.000000000 -0700 @@ -14,7 +14,7 @@ # Targets KERNEL_MK=$(PACKAGE_DIR)/kernel/norwich-kernel.mk -LBV2_MK=$(PACKAGE_DIR)/linuxbios/norwich-linuxbios.mk +LBV2_MK=$(PACKAGE_DIR)/linuxbios/geodelx-linuxbios.mk # kernel configuration (for LAB) Index: buildrom-devel/config/platforms/msm800sev.conf =================================================================== --- buildrom-devel.orig/config/platforms/msm800sev.conf 2008-01-11 13:39:11.000000000 -0700 +++ buildrom-devel/config/platforms/msm800sev.conf 2008-01-11 13:39:57.000000000 -0700 @@ -13,7 +13,7 @@ # Targets KERNEL_MK=$(PACKAGE_DIR)/kernel/msm800sev-kernel.mk -LBV2_MK=$(PACKAGE_DIR)/linuxbios/msm800sev-linuxbios.mk +LBV2_MK=$(PACKAGE_DIR)/linuxbios/geodelx-linuxbios.mk # kernel configuration (for LAB) Index: buildrom-devel/config/platforms/norwich.conf =================================================================== --- buildrom-devel.orig/config/platforms/norwich.conf 2008-01-11 13:39:11.000000000 -0700 +++ buildrom-devel/config/platforms/norwich.conf 2008-01-11 13:40:07.000000000 -0700 @@ -13,7 +13,7 @@ # Targets KERNEL_MK=$(PACKAGE_DIR)/kernel/norwich-kernel.mk -LBV2_MK=$(PACKAGE_DIR)/linuxbios/norwich-linuxbios.mk +LBV2_MK=$(PACKAGE_DIR)/linuxbios/geodelx-linuxbios.mk # kernel configuration (for LAB) From Marc.Karasek at Sun.COM Fri Jan 11 22:51:34 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Fri, 11 Jan 2008 16:51:34 -0500 Subject: [LinuxBIOS] AMD SimNOW question In-Reply-To: <00e301c8549b$357abf40$2023040a@chimp> References: <4783CA87.4070600@sun.com> <2831fecf0801081223u25f7a96cheae2779637cf4189@mail.gmail.com> <4783F2BB.8000902@sun.com> <01e801c85243$52ac9e30$a023040a@chimp> <20080108222125.GC28312@cosmic.amd.com> <4783FB7F.4000205@sun.com> <13426df10801101552k105385eaifa1d0771839da3b5@mail.gmail.com> <4787BA26.8060700@sun.com> <2831fecf0801111147l6356254ay3dc392a174446dfd@mail.gmail.com> <4787E071.1050306@sun.com> <00e301c8549b$357abf40$2023040a@chimp> Message-ID: <4787E4E6.4050802@sun.com> No the serial port output looks ok. It is the "vga" ouput I need to capture. The kernel as loader is crashing... /********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 *********************/ Myles Watson wrote: > There are a couple of ways, which you can find here: > > http://linuxbios.org/AMD_SimNow > > if you want it to go to a file, instead of > > cat /home/myles/.simnow/com1/simnow_out > > try > > cat /home/myles/.simnow/com1/simnow_out > myfile.log > > otherwise, if you're using snserial there is some option to do that as well. > > Myles > > >> -----Original Message----- >> From: Marc.Karasek at Sun.COM [mailto:Marc.Karasek at Sun.COM] >> Sent: Friday, January 11, 2008 2:33 PM >> To: Myles Watson; LinuxBIOS >> Subject: Re: [LinuxBIOS] AMD SimNOW question >> >> Is there anyway under SimNow to send the console output to a log file. >> >> I have linuxbios up and running :-) but the Linux kernel I have as a >> boot loader is crashing.. I have tried to stop it at the point when it >> starts dmping the same message to the screen but it is nearly impossible >> to time it right. >> >> /********************* >> Marc Karasek >> MTS >> Sun Microsystems >> mailto:marc.karasek at sun.com >> ph:770.360.6415 >> *********************/ >> >> >> >> Myles Watson wrote: >> >>> Marc, >>> >>> I sent the wrong one for serengeti-cheetah last time. Sorry. >>> >>> Myles >>> >>> On Jan 11, 2008 11:49 AM, Marc Karasek wrote: >>> >>> >>>> I have managed to cobble together a build structure that tries to >>>> >> build. >> >>>> It gets to the point of building the linuxbios image and it chokes >>>> because the image is to large for the romsize. >>>> >>>> Can someone shed some light on what Config.lb should be set to to get >>>> this to compile. >>>> >>>> The payload buildrom is generating is 790,000+ bytes big. >>>> >>>> /********************* >>>> Marc Karasek >>>> MTS >>>> Sun Microsystems >>>> mailto:marc.karasek at sun.com >>>> ph:770.360.6415 >>>> *********************/ >>>> >>>> >>>> >>>> >>>> ron minnich wrote: >>>> >>>> >>>>> On Jan 8, 2008 2:38 PM, Marc Karasek wrote: >>>>> >>>>> >>>>> >>>>>> I have found the main problem with svn. It looks like if you use svn >>>>>> >> co >> >>>>>> http:// it will use the proxy settings under servers. If you do a >>>>>> >> svn >> >>>>>> co svn:// it tries to do a dns lookup, which fails behind a proxy >>>>>> >> server >> >>>>>> :-(. I have not been able to find any info on setting svn up to use >>>>>> >> a >> >>>>>> proxy when doing svn:// type checkouts. >>>>>> >>>>>> >>>>>> >>>>> There is a way to do it, maybe: >>>>> >> http://subversion.tigris.org/faq.html#proxy >> >>>>> ron >>>>> >>>>> >>>>> > > > From jordan.crouse at amd.com Fri Jan 11 22:51:46 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Fri, 11 Jan 2008 14:51:46 -0700 Subject: [LinuxBIOS] AMD SimNOW question In-Reply-To: <00e301c8549b$357abf40$2023040a@chimp> References: <2831fecf0801081223u25f7a96cheae2779637cf4189@mail.gmail.com> <4783F2BB.8000902@sun.com> <01e801c85243$52ac9e30$a023040a@chimp> <20080108222125.GC28312@cosmic.amd.com> <4783FB7F.4000205@sun.com> <13426df10801101552k105385eaifa1d0771839da3b5@mail.gmail.com> <4787BA26.8060700@sun.com> <2831fecf0801111147l6356254ay3dc392a174446dfd@mail.gmail.com> <4787E071.1050306@sun.com> <00e301c8549b$357abf40$2023040a@chimp> Message-ID: <20080111215146.GG2917@cosmic.amd.com> On 11/01/08 14:44 -0700, Myles Watson wrote: > There are a couple of ways, which you can find here: > > http://linuxbios.org/AMD_SimNow > > if you want it to go to a file, instead of > > cat /home/myles/.simnow/com1/simnow_out > > try > > cat /home/myles/.simnow/com1/simnow_out > myfile.log > > otherwise, if you're using snserial there is some option to do that as well. You can set up snserial to output to a pty, and then do a cat 'ptyX > myfile.log". But it would be a good idea to make snserial output to a logfile. I'll add that to my todo list. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From jordan.crouse at amd.com Fri Jan 11 22:57:52 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Fri, 11 Jan 2008 14:57:52 -0700 Subject: [LinuxBIOS] Consolidate all the geode Linuxbios targets In-Reply-To: <20080111215606.GA17668@cosmic.amd.com> References: <20080111215606.GA17668@cosmic.amd.com> Message-ID: <20080111215752.GB17668@cosmic.amd.com> On 11/01/08 14:56 -0700, Jordan Crouse wrote: > I'm about to introduce some new code, but first, this is some cleanup > of the linuxbios/ directory - all the geode targets were the same, so > I consolidated them. As an aside, I tried all the Geode targets to make sure they work, and it looks like mem800sev and the alix1c targets do not work - they point to /tmp/filo.elf as the default payload in the Config.lb, and we expect that the payload is in ../payload.elf like the db800 and norwich targets do. Either that needs to be fixed in LinuxBIOS v2, or we need to patch the files in buildrom, which has the ironic side effect of making my previous patch invalid. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From atschauschev at yahoo.com Fri Jan 11 23:01:22 2008 From: atschauschev at yahoo.com (Andon Tschauschev) Date: Fri, 11 Jan 2008 14:01:22 -0800 (PST) Subject: [LinuxBIOS] AMD SimNOW (program) fails to run Message-ID: <370062.40109.qm@web33213.mail.mud.yahoo.com> Hello, I want to use SimNow 4.4.2, but it fails to run. OS is openSUSE 10.3 x86_64, 1GB RAM, Kernel version: andon at freezer:~> uname -a Linux freezer 2.6.22.13-0.3-default #1 SMP 2007/11/19 15:02:58 UTC x86_64 x86_64 x86_64 GNU/Linux andon at freezer:~> CPU Info: andon at freezer:~> cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 79 model name : AMD Athlon(tm) 64 Processor 3800+ stepping : 2 cpu MHz : 1000.000 cache size : 512 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow up pni cx16 lahf_lm svm extapic cr8_legacy bogomips : 2010.89 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc andon at freezer:~> Running SimNow produces following error: andon at freezer:~/SimNow/simnow-linux64-4.4.2pub> ./simnow -f bsds/cheetah_1p.bsd Using image path: "/tool/perf/simnow-data/images" Device Library: Winbond W83627HF SIO Device Library: SMB Hub Device Device Library: AMD 8th Generation Integrated Northbridge Device Library: PCI Bus Device Library: PCA9548 Device Device Library: Memory Device Device Library: Emerald Graphics Device Library: Dimm Bank Device Library: AweSim Processor Device Library: AT24C Device Device Library: Debugger Device Library: AMD-8132 PCI-X Controller Device Library: AMD-8111 I/O Hub Device Library: USB JumpDrive Device Library: Intel(R) Pro/1000 MT/PT Desktop Network Adapter Using library path: "./libs" Opening "bsds/cheetah_1p.bsd" Instructions per Microsecond: 800 CPU Model Name: Opteron System Bus Frequency: 200 CPU Clock Mul: 0 Turbo_Port61: 0 Turbo_Vsync: 0 Guard Memory Required: TRUE CPU Manages Cycles: TRUE Disk Block Cache Size: 64K Disk Block Cache Depth: 5 Disk Block Cache Bits: 12 info: creating device #0 "AMD 8th Generation Integrated Northbridge" info: creating device #1 "Dimm Bank" info: creating device #2 "AMD-8111 I/O Hub" info: creating device #3 "Memory Device" info: creating device #4 "Winbond W83627HF SIO" info: creating device #5 "SMB Hub Device" info: creating device #6 "PCI Bus" info: creating device #7 "Debugger" info: creating device #8 "AweSim Processor" FixIt: Error: Unable to allocate processor model memory. Aborted andon at freezer:~/SimNow/simnow-linux64-4.4.2pub> Strace output: andon at freezer:~/SimNow/simnow-linux64-4.4.2pub> strace ./simnow -f bsds/cheetah_1p.bsd ... ... ... ... write(1, "info: creating device #8 \"AweSim"..., 44info: creating device #8 "AweSim Processor" ) = 44 mmap(NULL, 1646592, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaab2c7000 write(6, "\0", 1) = 1 futex(0x5d29e4, FUTEX_WAKE_OP, 1, 1, 0x5d29e0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_EQ, 0}) = 1 futex(0x5d29b8, FUTEX_WAKE, 1) = 1 futex(0x5d2af0, FUTEX_WAKE, 1) = 1 futex(0x5d2b18, FUTEX_WAKE, 1) = 1 futex(0x5d2b1c, FUTEX_WAIT, 1, NULL) = -1 EAGAIN (Resource temporarily unavailable) futex(0x5d2af0, FUTEX_WAKE, 1) = 0 write(6, "\0", 1) = 1 futex(0x65d7ac, FUTEX_WAIT, 1, NULL) = 0 futex(0x65d780, FUTEX_WAKE, 1) = 0 mmap(0x5400000000, 2147483648, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot allocate memory) mmap(NULL, 2147483648, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot allocate memory) write(1, "FixIt: Error: Unable to allocate"..., 57FixIt: Error: Unable to allocate processor model memory. ) = 57 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 tgkill(5923, 5923, SIGABRT) = 0 --- SIGABRT (Aborted) @ 0 (0) --- +++ killed by SIGABRT +++ andon at freezer:~/SimNow/simnow-linux64-4.4.2pub> Thank you for any help you can give me. Regards Andon ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From jordan.crouse at amd.com Fri Jan 11 23:03:16 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Fri, 11 Jan 2008 15:03:16 -0700 Subject: [LinuxBIOS] AMD SimNOW question In-Reply-To: <4787E4E6.4050802@sun.com> References: <4783F2BB.8000902@sun.com> <01e801c85243$52ac9e30$a023040a@chimp> <20080108222125.GC28312@cosmic.amd.com> <4783FB7F.4000205@sun.com> <13426df10801101552k105385eaifa1d0771839da3b5@mail.gmail.com> <4787BA26.8060700@sun.com> <2831fecf0801111147l6356254ay3dc392a174446dfd@mail.gmail.com> <4787E071.1050306@sun.com> <00e301c8549b$357abf40$2023040a@chimp> <4787E4E6.4050802@sun.com> Message-ID: <20080111220316.GA18141@cosmic.amd.com> On 11/01/08 16:51 -0500, Marc Karasek wrote: > No the serial port output looks ok. It is the "vga" ouput I need to > capture. The kernel as loader is crashing... Oh, wow... I don't think there's any way to do that. You can log the I/O and memory space accesses, but you can't log the screen. Maybe the I/O and memory space accesses would be enough - assuming you can parse through the noise to find the strings you want. Jordan From marc.jones at amd.com Fri Jan 11 23:07:39 2008 From: marc.jones at amd.com (Marc Jones) Date: Fri, 11 Jan 2008 15:07:39 -0700 Subject: [LinuxBIOS] r3021 build service In-Reply-To: <4787DD91.60808@amd.com> References: <476A17EF.1040308@gmail.com> <476AC059.3060604@AMD.com> <2831fecf0801111229h17a146bm584b1e0ddcaf5222@mail.gmail.com> <4787DD91.60808@amd.com> Message-ID: <4787E8AB.8010207@amd.com> Marc Jones wrote: > > Myles Watson wrote: >> Here's my attempt at fixing abuild for serengeti_cheetah_fam10. >> >> It's pretty trivial, since I'm just using the ROM_IMAGE_SIZE in >> Config.lb and putting it in Config-abuild.lb. When I reduce this size >> (past what it is in Config-abuild.lb), it gives me the same overlap >> error in my system that abuild is seeing. >> >> I also added XIP_ROM_SIZE, although I admit freely that I don't know >> anything about this variable. I just wanted to make it match Marc's >> Config.lb. >> >> Maybe the right thing to do would be to remove both XIP_ROM_SIZE >> references in Config-abuild.lb >> >> Either way, I think the ROM_IMAGE_SIZE change will help. > > Myles, > > Thanks, the bigger problem is that the rom generated by the auto abuild > is larger than expected. We are investigating the tool chain. Once we > understand what is going on I will feel more comfortable with increasing > the ROM_IMAGE_SIZE. > > Marc > > I made a very sexy picture of what a failover coreboot v2 image looks like and what ROM_IMAGE_SIZE and other variables are. http://www.coreboot.org/Anatomy_of_a_Failover_LinuxBIOSv2_Image Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From yasteve at gmail.com Fri Jan 11 23:12:05 2008 From: yasteve at gmail.com (Steve Isaacs) Date: Fri, 11 Jan 2008 14:12:05 -0800 Subject: [LinuxBIOS] INIT detected. In-Reply-To: <4787D84A.9080700@amd.com> References: <1200080661.2777.30.camel@biosbreath> <4787D84A.9080700@amd.com> Message-ID: <1200089525.2777.40.camel@biosbreath> On Fri, 2008-01-11 at 13:57 -0700, Marc Jones wrote: > > This could indicate a real problem. It means that the core was > unexpectedly reset at some point. This is checked in cache_as_ram.inc. > Look for /* check if cpu_init_detected */. > Yes, as it turns out this is a real problem. The southbridge for some reason unknown to me is sending the INIT message when upstream messages are enabled. I'm currently working with the chip supplier on that one. > I have seen unintentional resets caused by AP init and/or CAR and memory > init issues. You can get into some funny race conditions with AP and BSP > using the same CAR location but that is just a guess. > This is what I was initially suspecting when I realized the INIT may be a real problem. The INIT was causing other delays that eventually caused a timeout on the AP in the fidvid code (previous post). I now realize (just a short while ago) that with fidvid I've been chasing a symptom, not another problem. Thanks, Steve From myles at pel.cs.byu.edu Fri Jan 11 23:11:19 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Fri, 11 Jan 2008 15:11:19 -0700 Subject: [LinuxBIOS] AMD SimNOW question In-Reply-To: <4787E4E6.4050802@sun.com> References: <4783CA87.4070600@sun.com> <2831fecf0801081223u25f7a96cheae2779637cf4189@mail.gmail.com> <4783F2BB.8000902@sun.com> <01e801c85243$52ac9e30$a023040a@chimp> <20080108222125.GC28312@cosmic.amd.com> <4783FB7F.4000205@sun.com> <13426df10801101552k105385eaifa1d0771839da3b5@mail.gmail.com> <4787BA26.8060700@sun.com> <2831fecf0801111147l6356254ay3dc392a174446dfd@mail.gmail.com> <4787E071.1050306@sun.com> <00e301c8549b$357abf40$2023040a@chimp> <4787E4E6.4050802@sun.com> Message-ID: <00ed01c8549e$e44d5b60$2023040a@chimp> Sorry I misunderstood. I still recommend the same thing, only tell the Linux kernel to use the serial port as the console, console=ttyS0,115200 You don't want to try to capture the actual VGA probably. Good luck, Myles > -----Original Message----- > From: Marc.Karasek at Sun.COM [mailto:Marc.Karasek at Sun.COM] > Sent: Friday, January 11, 2008 2:52 PM > To: myles at mouselemur.cs.byu.edu > Cc: 'LinuxBIOS' > Subject: Re: [LinuxBIOS] AMD SimNOW question > > No the serial port output looks ok. It is the "vga" ouput I need to > capture. The kernel as loader is crashing... > > /********************* > Marc Karasek > MTS > Sun Microsystems > mailto:marc.karasek at sun.com > ph:770.360.6415 > *********************/ > > > > Myles Watson wrote: > > There are a couple of ways, which you can find here: > > > > http://linuxbios.org/AMD_SimNow > > > > if you want it to go to a file, instead of > > > > cat /home/myles/.simnow/com1/simnow_out > > > > try > > > > cat /home/myles/.simnow/com1/simnow_out > myfile.log > > > > otherwise, if you're using snserial there is some option to do that as > well. > > > > Myles > > > > > >> -----Original Message----- > >> From: Marc.Karasek at Sun.COM [mailto:Marc.Karasek at Sun.COM] > >> Sent: Friday, January 11, 2008 2:33 PM > >> To: Myles Watson; LinuxBIOS > >> Subject: Re: [LinuxBIOS] AMD SimNOW question > >> > >> Is there anyway under SimNow to send the console output to a log file. > >> > >> I have linuxbios up and running :-) but the Linux kernel I have as a > >> boot loader is crashing.. I have tried to stop it at the point when it > >> starts dmping the same message to the screen but it is nearly > impossible > >> to time it right. > >> > >> /********************* > >> Marc Karasek > >> MTS > >> Sun Microsystems > >> mailto:marc.karasek at sun.com > >> ph:770.360.6415 > >> *********************/ > >> > >> > >> > >> Myles Watson wrote: > >> > >>> Marc, > >>> > >>> I sent the wrong one for serengeti-cheetah last time. Sorry. > >>> > >>> Myles > >>> > >>> On Jan 11, 2008 11:49 AM, Marc Karasek wrote: > >>> > >>> > >>>> I have managed to cobble together a build structure that tries to > >>>> > >> build. > >> > >>>> It gets to the point of building the linuxbios image and it chokes > >>>> because the image is to large for the romsize. > >>>> > >>>> Can someone shed some light on what Config.lb should be set to to get > >>>> this to compile. > >>>> > >>>> The payload buildrom is generating is 790,000+ bytes big. > >>>> > >>>> /********************* > >>>> Marc Karasek > >>>> MTS > >>>> Sun Microsystems > >>>> mailto:marc.karasek at sun.com > >>>> ph:770.360.6415 > >>>> *********************/ > >>>> > >>>> > >>>> > >>>> > >>>> ron minnich wrote: > >>>> > >>>> > >>>>> On Jan 8, 2008 2:38 PM, Marc Karasek wrote: > >>>>> > >>>>> > >>>>> > >>>>>> I have found the main problem with svn. It looks like if you use > svn > >>>>>> > >> co > >> > >>>>>> http:// it will use the proxy settings under servers. If you do a > >>>>>> > >> svn > >> > >>>>>> co svn:// it tries to do a dns lookup, which fails behind a proxy > >>>>>> > >> server > >> > >>>>>> :-(. I have not been able to find any info on setting svn up to > use > >>>>>> > >> a > >> > >>>>>> proxy when doing svn:// type checkouts. > >>>>>> > >>>>>> > >>>>>> > >>>>> There is a way to do it, maybe: > >>>>> > >> http://subversion.tigris.org/faq.html#proxy > >> > >>>>> ron > >>>>> > >>>>> > >>>>> > > > > > > From c-d.hailfinger.devel.2006 at gmx.net Fri Jan 11 23:19:15 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 11 Jan 2008 23:19:15 +0100 Subject: [LinuxBIOS] r3021 build service In-Reply-To: <4787E8AB.8010207@amd.com> References: <476A17EF.1040308@gmail.com> <476AC059.3060604@AMD.com> <2831fecf0801111229h17a146bm584b1e0ddcaf5222@mail.gmail.com> <4787DD91.60808@amd.com> <4787E8AB.8010207@amd.com> Message-ID: <4787EB63.60200@gmx.net> On 11.01.2008 23:07, Marc Jones wrote: > I made a very sexy picture of what a failover coreboot v2 image looks > like and what ROM_IMAGE_SIZE and other variables are. > > http://www.coreboot.org/Anatomy_of_a_Failover_LinuxBIOSv2_Image > Great, thanks! One of the things I'd always wanted to have an image of. Regards, Carl-Daniel From rminnich at gmail.com Fri Jan 11 23:28:55 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 11 Jan 2008 14:28:55 -0800 Subject: [LinuxBIOS] r3021 build service In-Reply-To: <4787E8AB.8010207@amd.com> References: <476A17EF.1040308@gmail.com> <476AC059.3060604@AMD.com> <2831fecf0801111229h17a146bm584b1e0ddcaf5222@mail.gmail.com> <4787DD91.60808@amd.com> <4787E8AB.8010207@amd.com> Message-ID: <13426df10801111428i1ed50ac9ydf083ab899bf28bf@mail.gmail.com> On Jan 11, 2008 2:07 PM, Marc Jones wrote: > I made a very sexy picture of what a failover coreboot v2 image looks > like and what ROM_IMAGE_SIZE and other variables are. > > http://www.coreboot.org/Anatomy_of_a_Failover_LinuxBIOSv2_Image > I think we should make you Chairman of the Graphics Department :-) This is great! ron From rminnich at gmail.com Fri Jan 11 23:34:35 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 11 Jan 2008 14:34:35 -0800 Subject: [LinuxBIOS] [BUILDROM] Consolidate all the geode Linuxbios targets In-Reply-To: <20080111215606.GA17668@cosmic.amd.com> References: <20080111215606.GA17668@cosmic.amd.com> Message-ID: <13426df10801111434t140f874bre1ca57a1e75fe64a@mail.gmail.com> Fix the payloads on alix1c and msm800sev. ron -------------- next part -------------- A non-text attachment was scrubbed... Name: alixmsm800payload.diff Type: text/x-patch Size: 1014 bytes Desc: not available URL: From jordan.crouse at amd.com Fri Jan 11 23:38:41 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Fri, 11 Jan 2008 15:38:41 -0700 Subject: [LinuxBIOS] Consolidate all the geode Linuxbios targets In-Reply-To: <13426df10801111434t140f874bre1ca57a1e75fe64a@mail.gmail.com> References: <20080111215606.GA17668@cosmic.amd.com> <13426df10801111434t140f874bre1ca57a1e75fe64a@mail.gmail.com> Message-ID: <20080111223841.GA18269@cosmic.amd.com> On 11/01/08 14:34 -0800, ron minnich wrote: > Fix the payloads on alix1c and msm800sev. > > ron > Fix these to use a more standard relative path for payload. > Signed-off-by: Ronald G. Minnich Acked-by: Jordan Crouse And thank you for your speed! > Index: targets/digitallogic/msm800sev/Config.lb > =================================================================== > --- targets/digitallogic/msm800sev/Config.lb (revision 3046) > +++ targets/digitallogic/msm800sev/Config.lb (working copy) > @@ -22,7 +22,7 @@ > romimage "fallback" > option USE_FALLBACK_IMAGE=1 > option LINUXBIOS_EXTRA_VERSION=".0Fallback" > - payload /tmp/filo.elf > + payload ../payload.elf > end > > buildrom ./linuxbios.rom ROM_SIZE "fallback" > Index: targets/pcengines/alix1c/Config.lb > =================================================================== > --- targets/pcengines/alix1c/Config.lb (revision 3046) > +++ targets/pcengines/alix1c/Config.lb (working copy) > @@ -19,7 +19,7 @@ > romimage "fallback" > option USE_FALLBACK_IMAGE = 1 > option LINUXBIOS_EXTRA_VERSION = ".0Fallback" > - payload /tmp/filo.elf > + payload ../payload.elf > end > > buildrom ./linuxbios.rom ROM_SIZE "fallback" > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From svn at openbios.org Fri Jan 11 23:37:28 2008 From: svn at openbios.org (svn at openbios.org) Date: Fri, 11 Jan 2008 23:37:28 +0100 Subject: [LinuxBIOS] r3047 - in trunk/LinuxBIOSv2/targets: digitallogic/msm800sev pcengines/alix1c Message-ID: Author: rminnich Date: 2008-01-11 23:37:27 +0100 (Fri, 11 Jan 2008) New Revision: 3047 Modified: trunk/LinuxBIOSv2/targets/digitallogic/msm800sev/Config.lb trunk/LinuxBIOSv2/targets/pcengines/alix1c/Config.lb Log: Fix these to use a more standard relative path for payload. Signed-off-by: Ronald G. Minnich Acked-by: Jordan Crouse Modified: trunk/LinuxBIOSv2/targets/digitallogic/msm800sev/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/digitallogic/msm800sev/Config.lb 2008-01-11 18:23:47 UTC (rev 3046) +++ trunk/LinuxBIOSv2/targets/digitallogic/msm800sev/Config.lb 2008-01-11 22:37:27 UTC (rev 3047) @@ -22,7 +22,7 @@ romimage "fallback" option USE_FALLBACK_IMAGE=1 option LINUXBIOS_EXTRA_VERSION=".0Fallback" - payload /tmp/filo.elf + payload ../payload.elf end buildrom ./linuxbios.rom ROM_SIZE "fallback" Modified: trunk/LinuxBIOSv2/targets/pcengines/alix1c/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/pcengines/alix1c/Config.lb 2008-01-11 18:23:47 UTC (rev 3046) +++ trunk/LinuxBIOSv2/targets/pcengines/alix1c/Config.lb 2008-01-11 22:37:27 UTC (rev 3047) @@ -19,7 +19,7 @@ romimage "fallback" option USE_FALLBACK_IMAGE = 1 option LINUXBIOS_EXTRA_VERSION = ".0Fallback" - payload /tmp/filo.elf + payload ../payload.elf end buildrom ./linuxbios.rom ROM_SIZE "fallback" From rminnich at gmail.com Fri Jan 11 23:37:52 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 11 Jan 2008 14:37:52 -0800 Subject: [LinuxBIOS] Consolidate all the geode Linuxbios targets In-Reply-To: <20080111223841.GA18269@cosmic.amd.com> References: <20080111215606.GA17668@cosmic.amd.com> <13426df10801111434t140f874bre1ca57a1e75fe64a@mail.gmail.com> <20080111223841.GA18269@cosmic.amd.com> Message-ID: <13426df10801111437s34dfd507q3a4739f3bdd9bb75@mail.gmail.com> On Jan 11, 2008 2:38 PM, Jordan Crouse wrote: > > Fix these to use a more standard relative path for payload. > > Signed-off-by: Ronald G. Minnich > > Acked-by: Jordan Crouse Committed revision 3047. From jordan.crouse at amd.com Fri Jan 11 23:45:28 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Fri, 11 Jan 2008 15:45:28 -0700 Subject: [LinuxBIOS] Consolidate all the geode Linuxbios targets In-Reply-To: <13426df10801111437s34dfd507q3a4739f3bdd9bb75@mail.gmail.com> References: <20080111215606.GA17668@cosmic.amd.com> <13426df10801111434t140f874bre1ca57a1e75fe64a@mail.gmail.com> <20080111223841.GA18269@cosmic.amd.com> <13426df10801111437s34dfd507q3a4739f3bdd9bb75@mail.gmail.com> Message-ID: <20080111224528.GA18860@cosmic.amd.com> On 11/01/08 14:37 -0800, ron minnich wrote: > On Jan 11, 2008 2:38 PM, Jordan Crouse wrote: > > > > Fix these to use a more standard relative path for payload. > > > Signed-off-by: Ronald G. Minnich > > > > Acked-by: Jordan Crouse > > Committed revision 3047. And the associated patch to bump the revision in buildrom. -------------- next part -------------- [BUILDROM] Bump the mem800sev and alix1c revisions Bump the linuxbios revision of the mem800sev and alix1c to take advantage of the payload patch added to LBv2. Signed-off-by: Jordan Crouse Index: buildrom-devel/config/platforms/alix1c.conf =================================================================== --- buildrom-devel.orig/config/platforms/alix1c.conf 2008-01-11 15:43:21.000000000 -0700 +++ buildrom-devel/config/platforms/alix1c.conf 2008-01-11 15:43:37.000000000 -0700 @@ -29,7 +29,7 @@ LINUXBIOS_BOARD=alix1c LBV2_CONFIG=Config.lb LBV2_TDIR=alix1c -LBV2_TAG=2807 +LBV2_TAG=3047 LINUXBIOS_ROM_NAME=linuxbios.rom # FILO configuration Index: buildrom-devel/config/platforms/msm800sev.conf =================================================================== --- buildrom-devel.orig/config/platforms/msm800sev.conf 2008-01-11 15:43:43.000000000 -0700 +++ buildrom-devel/config/platforms/msm800sev.conf 2008-01-11 15:43:51.000000000 -0700 @@ -30,7 +30,7 @@ LINUXBIOS_BOARD=msm800sev LBV2_CONFIG=Config.lb LBV2_TDIR=msm800sev -LBV2_TAG=2810 +LBV2_TAG=3047 LINUXBIOS_ROM_NAME=linuxbios.rom # FILO configuration From ward at gnu.org Fri Jan 11 23:48:49 2008 From: ward at gnu.org (Ward Vandewege) Date: Fri, 11 Jan 2008 17:48:49 -0500 Subject: [LinuxBIOS] [PATCH] buildrom: add extract and busybox-config, uclibc-config targets In-Reply-To: <008d01c853e2$1c332f90$2023040a@chimp> References: <20080110231849.GA22723@localdomain> <008d01c853e2$1c332f90$2023040a@chimp> Message-ID: <20080111224849.GA4101@localdomain> On Thu, Jan 10, 2008 at 04:39:57PM -0700, Myles Watson wrote: > Sorry to be so dense, but it looks like you added mkdir -p in a lot of > places for directories, even though there are already makefile rules for > them. Right, that was stupid, I had not noticed those. This patch fixes that, and it's updated to r94. Thanks for catching that :) Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator -------------- next part -------------- This patch adds extract targets, as well as the first of a a bunch of config targets: busybox-config and uclibc-config. The extract targets will just extract the component(s) under work. The config targets will run a configure command for the component, and then copy the resulting config file to packages/component/conf/customconfig. That config file will then be used to build the image when 'make' is issued. Signed-off-by: Ward Vandewege Index: Makefile =================================================================== --- Makefile (revision 94) +++ Makefile (working copy) @@ -21,7 +21,7 @@ config-targets := 1 endif -ifneq ($(filter config %config,$(MAKECMDGOALS)),) +ifneq ($(filter textconfig oldconfig defconfig menuconfig,$(MAKECMDGOALS)),) config-targets := 1 dot-config := 0 endif @@ -60,6 +60,7 @@ PKG_clean=$(patsubst %, %-clean, $(PKGLIST)) PKG_distclean=$(patsubst %, %-distclean, $(PKGLIST)) +PKG_extract=$(patsubst %, %-extract, $(PKGLIST)) # This is the top level target - for v2, the final deliverable is built # by LinuxBIOS, for v3 it is built by us, so we have ifdef magic here @@ -78,6 +79,8 @@ payload: $(PAYLOAD_TARGET) +extract: $(PKG_extract) + clean: $(PKG_clean) @ rm -rf $(INITRD_DIR) $(OUTPUT_DIR) Index: packages/kernel/kernel.inc =================================================================== --- packages/kernel/kernel.inc (revision 94) +++ packages/kernel/kernel.inc (working copy) @@ -25,7 +25,7 @@ KERNEL_INSTALL_LOG=$(KERNEL_LOG_DIR)/install.log endif -$(KERNEL_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(KERNEL_SOURCE) +$(KERNEL_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(KERNEL_SOURCE) $(KERNEL_STAMP_DIR) @ mkdir -p $(KERNEL_DIR) @ echo "Unpacking kernel..." @ tar -C $(KERNEL_DIR) -jxf $(SOURCE_DIR)/$(KERNEL_SOURCE) @@ -83,3 +83,6 @@ generic-kernel-distclean: @ rm -rf $(KERNEL_DIR) + +kernel-extract: $(KERNEL_STAMP_DIR)/.patched + Index: packages/unifdef/unifdef.mk =================================================================== --- packages/unifdef/unifdef.mk (revision 94) +++ packages/unifdef/unifdef.mk (working copy) @@ -17,7 +17,7 @@ @ mkdir -p $(SOURCE_DIR) @ wget -P $(SOURCE_DIR) $(UNIFDEF_URL)/$(UNIFDEF_SOURCE) -$(UNIFDEF_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(UNIFDEF_SOURCE) +$(UNIFDEF_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(UNIFDEF_SOURCE) $(UNIFDEF_STAMP_DIR) @ tar -C $(UNIFDEF_DIR) -zxf $(SOURCE_DIR)/$(UNIFDEF_SOURCE) @ rm -f $(UNIFDEF_SRC_DIR)/unifdef @ rm -f $(UNIFDEF_SRC_DIR)/unifdef.o @@ -48,4 +48,8 @@ echo "Source: $(UNIFDEF_URL)/$(UNIFDEF_SOURCE)" echo "" +unifdef-extract: $(UNIFDEF_STAMP_DIR)/.unpacked + .PHONY: unifdef + + Index: packages/busybox/busybox.mk =================================================================== --- packages/busybox/busybox.mk (revision 94) +++ packages/busybox/busybox.mk (working copy) @@ -17,11 +17,18 @@ BUSYBOX_CONFIG ?= defconfig +ifeq ($(BUSYBOX_CONFIG),defconfig) +ifeq ($(shell if [ -f $(PACKAGE_DIR)/busybox/conf/customconfig ]; then echo 1; fi),1) + BUSYBOX_CONFIG = customconfig +endif +endif + $(SOURCE_DIR)/$(BUSYBOX_SOURCE): + @ echo "Downloading busybox..." @ mkdir -p $(SOURCE_DIR) @ wget -P $(SOURCE_DIR) $(BUSYBOX_URL)/$(BUSYBOX_SOURCE) -$(BUSYBOX_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(BUSYBOX_SOURCE) +$(BUSYBOX_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(BUSYBOX_SOURCE) $(BUSYBOX_STAMP_DIR) $(BUSYBOX_DIR) @ echo "Unpacking busybox..." @ tar -C $(BUSYBOX_DIR) -jxf $(SOURCE_DIR)/$(BUSYBOX_SOURCE) @ touch $@ @@ -32,7 +39,7 @@ @ touch $@ $(BUSYBOX_SRC_DIR)/.config: $(BUSYBOX_STAMP_DIR)/.patched - @ cp $(PACKAGE_DIR)/busybox/conf/$(BUSYBOX_CONFIG) $@ + @ cp -f $(PACKAGE_DIR)/busybox/conf/$(BUSYBOX_CONFIG) $@ $(BUSYBOX_SRC_DIR)/busybox: $(BUSYBOX_SRC_DIR)/.config @ echo "Building busybox..." @@ -46,7 +53,7 @@ @ $(MAKE) -C $(BUSYBOX_SRC_DIR) \ PREFIX=$(INITRD_DIR) install > $(BUSYBOX_INSTALL_LOG) 2>&1 -$(BUSYBOX_STAMP_DIR) $(BUSYBOX_LOG_DIR): +$(BUSYBOX_STAMP_DIR) $(BUSYBOX_LOG_DIR) $(BUSYBOX_DIR): @ mkdir -p $@ busybox: $(BUSYBOX_STAMP_DIR) $(BUSYBOX_LOG_DIR) $(INITRD_DIR)/bin/busybox @@ -57,8 +64,17 @@ busybox-distclean: @ rm -rf $(BUSYBOX_DIR)/* + @ rm -f $(PACKAGE_DIR)/busybox/conf/customconfig busybox-bom: @ echo "Package: busybox" @ echo "Source: $(BUSYBOX_URL)/$(BUSYBOX_SOURCE)" @ echo "" + +busybox-extract: $(BUSYBOX_STAMP_DIR)/.patched + +busybox-config: $(BUSYBOX_STAMP_DIR)/.patched + @ echo "Configure busybox..." + @ $(MAKE) -C $(BUSYBOX_SRC_DIR) menuconfig + @ cp -f $(BUSYBOX_SRC_DIR)/.config $(PACKAGE_DIR)/busybox/conf/customconfig + Index: packages/mkelfimage/mkelfimage.mk =================================================================== --- packages/mkelfimage/mkelfimage.mk (revision 94) +++ packages/mkelfimage/mkelfimage.mk (working copy) @@ -19,7 +19,7 @@ @ mkdir -p $(SOURCE_DIR) @ wget -P $(SOURCE_DIR) $(MKELFIMAGE_URL)/$(MKELFIMAGE_SOURCE) -$(MKELFIMAGE_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(MKELFIMAGE_SOURCE) +$(MKELFIMAGE_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(MKELFIMAGE_SOURCE) $(MKELFIMAGE_STAMP_DIR) @ echo "Unpacking mkelfimage..." @ tar -C $(MKELFIMAGE_DIR) -zxf $(SOURCE_DIR)/$(MKELFIMAGE_SOURCE) @ touch $@ @@ -60,3 +60,6 @@ echo "Package: mkelfimage" echo "Source: $(MKELFIMAGE_URL)/$(MKELFIMAGE_SOURCE)" echo "" + +mkelfimage-extract: $(MKELFIMAGE_STAMP_DIR)/.patched + Index: packages/uclibc/uclibc.mk =================================================================== --- packages/uclibc/uclibc.mk (revision 94) +++ packages/uclibc/uclibc.mk (working copy) @@ -7,8 +7,15 @@ UCLIBC_VER ?= 0.9.28 UCLIBC_ARCH ?= i386 UCLIBC_CONFIG ?= defconfig + +ifeq ($(UCLIBC_CONFIG),defconfig) +ifeq ($(shell if [ -f $(PACKAGE_DIR)/ucblic/conf/customconfig ]; then echo 1; fi),1) + UCLIBC_CONFIG = customconfig endif +endif +endif + UCLIBC_URL=http://www.uclibc.org/downloads UCLIBC_SOURCE=uClibc-$(UCLIBC_VER).tar.bz2 UCLIBC_DIR=$(BUILD_DIR)/uclibc @@ -25,10 +32,11 @@ endif $(SOURCE_DIR)/$(UCLIBC_SOURCE): + @ echo "Downloading uclibc..." @ mkdir -p $(SOURCE_DIR) @ wget -P $(SOURCE_DIR) $(UCLIBC_URL)/$(UCLIBC_SOURCE) -$(UCLIBC_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(UCLIBC_SOURCE) +$(UCLIBC_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(UCLIBC_SOURCE) $(UCLIBC_STAMP_DIR) $(UCLIBC_DIR) @ echo "Unpacking uclibc..." @ tar -C $(UCLIBC_DIR) -jxf $(SOURCE_DIR)/$(UCLIBC_SOURCE) @ touch $@ @@ -61,7 +69,7 @@ @ install -m 755 -d $(STAGING_DIR)/bin @ install -m 755 $< $@ -$(UCLIBC_STAMP_DIR) $(UCLIBC_LOG_DIR): +$(UCLIBC_STAMP_DIR) $(UCLIBC_LOG_DIR) $(UCLIBC_DIR): @ mkdir -p $@ uclibc: $(UCLIBC_STAMP_DIR) $(UCLIBC_LOG_DIR) $(STAGING_DIR)/lib/libc.a @@ -77,3 +85,11 @@ @ echo "Package: uclibc" @ echo "Source: $(UCLIBC_URL)/$(UCLIBC_SOURCE)" @ echo "" + +uclibc-extract: $(UCLIBC_STAMP_DIR)/.unpacked + +uclibc-config: $(UCLIBC_STAMP_DIR)/.unpacked + @ echo "Configure uclibc..." + @ $(MAKE) -C $(UCLIBC_SRC_DIR) menuconfig + @ cp -f $(UCLIBC_SRC_DIR)/.config $(PACKAGE_DIR)/uclibc/conf/customconfig + Index: packages/lzma/lzma.mk =================================================================== --- packages/lzma/lzma.mk (revision 94) +++ packages/lzma/lzma.mk (working copy) @@ -17,7 +17,7 @@ @ mkdir -p $(SOURCE_DIR) @ wget -P $(SOURCE_DIR) $(LZMA_URL)/$(LZMA_SOURCE) -$(LZMA_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(LZMA_SOURCE) +$(LZMA_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(LZMA_SOURCE) $(LZMA_STAMP_DIR) @ mkdir -p $(LZMA_SRC_DIR) @ tar -C $(LZMA_SRC_DIR) -jxf $(SOURCE_DIR)/$(LZMA_SOURCE) @ touch $@ @@ -44,3 +44,6 @@ lzma-distclean: @ rm -rf $(LZMA_DIR)/* + +lzma-extract: $(LZMA_STAMP_DIR)/.unpacked + Index: packages/linuxbios/linuxbios.inc =================================================================== --- packages/linuxbios/linuxbios.inc (revision 94) +++ packages/linuxbios/linuxbios.inc (working copy) @@ -58,7 +58,7 @@ $(LBV2_PAYLOAD_TARGET): $(PAYLOAD_TARGET) @ cp $< $@ -$(LBV2_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(LBV2_TARBALL) +$(LBV2_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(LBV2_TARBALL) $(LBV2_STAMP_DIR) $(LBV2_LOG_DIR) @ echo "Unpacking LinuxBIOS..." @ tar -C $(LBV2_DIR) -zxf $(SOURCE_DIR)/$(LBV2_TARBALL) @ touch $@ @@ -98,3 +98,5 @@ fi @ rm -rf $(LBV2_DIR)/* + +linuxbios-extract: $(LBV2_STAMP_DIR)/.patched From ward at gnu.org Fri Jan 11 23:50:12 2008 From: ward at gnu.org (Ward Vandewege) Date: Fri, 11 Jan 2008 17:50:12 -0500 Subject: [LinuxBIOS] Consolidate all the geode Linuxbios targets In-Reply-To: <20080111224528.GA18860@cosmic.amd.com> References: <20080111215606.GA17668@cosmic.amd.com> <13426df10801111434t140f874bre1ca57a1e75fe64a@mail.gmail.com> <20080111223841.GA18269@cosmic.amd.com> <13426df10801111437s34dfd507q3a4739f3bdd9bb75@mail.gmail.com> <20080111224528.GA18860@cosmic.amd.com> Message-ID: <20080111225012.GB4101@localdomain> On Fri, Jan 11, 2008 at 03:45:28PM -0700, Jordan Crouse wrote: > And the associated patch to bump the revision in buildrom. > > > !DSPAM:4787f1d7211931030414324! > [BUILDROM] Bump the mem800sev and alix1c revisions > > Bump the linuxbios revision of the mem800sev and alix1c to take advantage > of the payload patch added to LBv2. > > Signed-off-by: Jordan Crouse Acked-by: Ward Vandewege (I think this qualifies as a trivial patch, you could have self-acked) Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From svn at openbios.org Fri Jan 11 23:53:36 2008 From: svn at openbios.org (svn at openbios.org) Date: Fri, 11 Jan 2008 23:53:36 +0100 Subject: [LinuxBIOS] r95 - buildrom-devel/config/platforms Message-ID: Author: jcrouse Date: 2008-01-11 23:53:36 +0100 (Fri, 11 Jan 2008) New Revision: 95 Modified: buildrom-devel/config/platforms/alix1c.conf buildrom-devel/config/platforms/msm800sev.conf Log: [BUILDROM] Bump the mem800sev and alix1c revisions Bump the linuxbios revision of the mem800sev and alix1c to take advantage of the payload patch added to LBv2. Signed-off-by: Jordan Crouse Acked-by: Ward Vandewege Modified: buildrom-devel/config/platforms/alix1c.conf =================================================================== --- buildrom-devel/config/platforms/alix1c.conf 2008-01-11 20:46:46 UTC (rev 94) +++ buildrom-devel/config/platforms/alix1c.conf 2008-01-11 22:53:36 UTC (rev 95) @@ -29,7 +29,7 @@ LINUXBIOS_BOARD=alix1c LBV2_CONFIG=Config.lb LBV2_TDIR=alix1c -LBV2_TAG=2807 +LBV2_TAG=3047 LINUXBIOS_ROM_NAME=linuxbios.rom # FILO configuration Modified: buildrom-devel/config/platforms/msm800sev.conf =================================================================== --- buildrom-devel/config/platforms/msm800sev.conf 2008-01-11 20:46:46 UTC (rev 94) +++ buildrom-devel/config/platforms/msm800sev.conf 2008-01-11 22:53:36 UTC (rev 95) @@ -30,7 +30,7 @@ LINUXBIOS_BOARD=msm800sev LBV2_CONFIG=Config.lb LBV2_TDIR=msm800sev -LBV2_TAG=2810 +LBV2_TAG=3047 LINUXBIOS_ROM_NAME=linuxbios.rom # FILO configuration From jordan.crouse at amd.com Fri Jan 11 23:56:33 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Fri, 11 Jan 2008 15:56:33 -0700 Subject: [LinuxBIOS] Consolidate all the geode Linuxbios targets In-Reply-To: <20080111225012.GB4101@localdomain> References: <20080111215606.GA17668@cosmic.amd.com> <13426df10801111434t140f874bre1ca57a1e75fe64a@mail.gmail.com> <20080111223841.GA18269@cosmic.amd.com> <13426df10801111437s34dfd507q3a4739f3bdd9bb75@mail.gmail.com> <20080111224528.GA18860@cosmic.amd.com> <20080111225012.GB4101@localdomain> Message-ID: <20080111225633.GD18860@cosmic.amd.com> On 11/01/08 17:50 -0500, Ward Vandewege wrote: > On Fri, Jan 11, 2008 at 03:45:28PM -0700, Jordan Crouse wrote: > > And the associated patch to bump the revision in buildrom. > > > > > > !DSPAM:4787f1d7211931030414324! > > > [BUILDROM] Bump the mem800sev and alix1c revisions > > > > Bump the linuxbios revision of the mem800sev and alix1c to take advantage > > of the payload patch added to LBv2. > > > > Signed-off-by: Jordan Crouse > > Acked-by: Ward Vandewege > > (I think this qualifies as a trivial patch, you could have self-acked) r95. Thanks. -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From jordan.crouse at amd.com Fri Jan 11 23:54:59 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Fri, 11 Jan 2008 15:54:59 -0700 Subject: [LinuxBIOS] Consolidate all the geode Linuxbios targets In-Reply-To: <20080111225012.GB4101@localdomain> References: <20080111215606.GA17668@cosmic.amd.com> <13426df10801111434t140f874bre1ca57a1e75fe64a@mail.gmail.com> <20080111223841.GA18269@cosmic.amd.com> <13426df10801111437s34dfd507q3a4739f3bdd9bb75@mail.gmail.com> <20080111224528.GA18860@cosmic.amd.com> <20080111225012.GB4101@localdomain> Message-ID: <20080111225459.GC18860@cosmic.amd.com> On 11/01/08 17:50 -0500, Ward Vandewege wrote: > On Fri, Jan 11, 2008 at 03:45:28PM -0700, Jordan Crouse wrote: > > And the associated patch to bump the revision in buildrom. > > > > > > !DSPAM:4787f1d7211931030414324! > > > [BUILDROM] Bump the mem800sev and alix1c revisions > > > > Bump the linuxbios revision of the mem800sev and alix1c to take advantage > > of the payload patch added to LBv2. > > > > Signed-off-by: Jordan Crouse > > Acked-by: Ward Vandewege > > (I think this qualifies as a trivial patch, you could have self-acked) Yeah - but bumping a revision like that could be dangerous - its good to have an archive record of it. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From myles at pel.cs.byu.edu Sat Jan 12 00:07:37 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Fri, 11 Jan 2008 16:07:37 -0700 Subject: [LinuxBIOS] [PATCH] buildrom: add extract and busybox-config, uclibc-config targets In-Reply-To: <20080111224849.GA4101@localdomain> References: <20080110231849.GA22723@localdomain> <008d01c853e2$1c332f90$2023040a@chimp> <20080111224849.GA4101@localdomain> Message-ID: <00fd01c854a6$c22e7cf0$2023040a@chimp> > On Thu, Jan 10, 2008 at 04:39:57PM -0700, Myles Watson wrote: > > Sorry to be so dense, but it looks like you added mkdir -p in a lot of > > places for directories, even though there are already makefile rules for > > them. > > Right, that was stupid, I had not noticed those. This patch fixes that, > and > it's updated to r94. Thanks for catching that :) Thanks for catching my "echo" (Debug statement I forgot to remove) too. This patch breaks the dependencies somehow. Before your patch, I could remove the work/uclibc directory and only uclibc would get rebuilt. Now it rebuilds mkelfimage, the kernel, etc. I looked for the problem, but didn't see it right away. Myles From info at coresystems.de Sat Jan 12 00:23:51 2008 From: info at coresystems.de (LinuxBIOS information) Date: Sat, 12 Jan 2008 00:23:51 +0100 Subject: [LinuxBIOS] r3047 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "rminnich" checked in revision 3047 to the LinuxBIOS source repository and caused the following changes: Change Log: Fix these to use a more standard relative path for payload. Signed-off-by: Ronald G. Minnich Acked-by: Jordan Crouse Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3047&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in rminnich's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From marc.jones at amd.com Sat Jan 12 01:01:21 2008 From: marc.jones at amd.com (Marc Jones) Date: Fri, 11 Jan 2008 17:01:21 -0700 Subject: [LinuxBIOS] PATCH: lx car that returns from disable_car In-Reply-To: <4787A99F.2070409@amd.com> References: <13426df10801041405h1d3e0f1eocdfba04c34144eb9@mail.gmail.com> <4782A542.6030109@amd.com> <13426df10801102008ld9b6d6rab616a6beee6d443@mail.gmail.com> <4787A99F.2070409@amd.com> Message-ID: <47880351.3060704@amd.com> Marc Jones wrote: > > ron minnich wrote: >> Marc, here are the register dumps. >> >> As a reminder, we seem to have no memory above 1M. >> > > It looks like stage2 has problems. The MSRs are not setup beyond what > stage1 did to allow stage2 to run. > Specificly, geodelx_pci_domain_phase2() is not running. > > Can you send your entire output? > Marc > > Ron, I think I am up to the same point you are. It looks like there is a problem in the device scanning. void dev_phase2(void) should call geodelx_pci_domain_phase2() for the southbridge device. Here is the output. Is this the correct order? It seems strange. Phase 2: Early setup... dev_phase2: dev root: dev_phase2: dev cpus: dev_phase2: dev device0_0: dev_phase2: dev southbridge: dev_phase2: dev domain0: Phase 2: Done. I attached my complete output. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: output.TXT URL: From c-d.hailfinger.devel.2006 at gmx.net Sat Jan 12 01:13:30 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 12 Jan 2008 01:13:30 +0100 Subject: [LinuxBIOS] Messing with CAR in a big way Message-ID: <4788062A.5060900@gmx.net> Hi, I'm currently considering to completely ignore what the BKDG says about CAR and change the AMD CAR code to 64k size at an *arbitrary* address. Right. Any address of your choice as long as it is below 1 MB. A few rules, though: If you want the CAR area to reside below 0x80000 (512k), you have to respect a 64k alignment. Between 0x80000 and 0xC0000 (768k) the alignment is 16k and between 0xC0000 and and 0x100000 (1M) the alignment is 4k. Ron, where would you like to have the CAR area to avoid copying the stack around in v2? Any places where stack location is hardcoded without using the usual #define? Regards, Carl-Daniel From r.marek at assembler.cz Sat Jan 12 01:18:42 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Sat, 12 Jan 2008 01:18:42 +0100 Subject: [LinuxBIOS] Messing with CAR in a big way In-Reply-To: <4788062A.5060900@gmx.net> References: <4788062A.5060900@gmx.net> Message-ID: <47880762.4000003@assembler.cz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Imho you must copy the data from CAR, because when it is OFF, no writeback is done to memory: (from BKDG) Temporary data stored in the cache during boot cannot be written back to DRAM after enabling the DRAM controller using a CLFLUSH or WBINVB instruction. The cache should be invalidated after the DRAM controller is initialized with an INVD instruction. The later is imho not done in LB I think. Maybe needs fix? Btw please design it to be suspend-to-ram friendly ;) Rudolf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHiAdi3J9wPJqZRNURArMLAKCrHtmvITd9ioSMiGc6Py6FFPas4ACeNufS gT1zEj/AXsPrAQGqJHrFJrI= =JfBy -----END PGP SIGNATURE----- From rminnich at gmail.com Sat Jan 12 01:25:04 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 11 Jan 2008 16:25:04 -0800 Subject: [LinuxBIOS] Messing with CAR in a big way In-Reply-To: <4788062A.5060900@gmx.net> References: <4788062A.5060900@gmx.net> Message-ID: <13426df10801111625w4f557de5ya93e16a9d83fbbf@mail.gmail.com> On Jan 11, 2008 4:13 PM, Carl-Daniel Hailfinger wrote: > Ron, where would you like to have the CAR area to avoid copying the > stack around in v2? Any places where stack location is hardcoded without > using the usual #define? > If you could put it at x800000 that would work very well with what I'm doing on LX. Be advised that car on older opterons is a bit tricky, due to limitations in the hardware. I can't test on older k8 any more, all I have is an AM2. thanks ron From c-d.hailfinger.devel.2006 at gmx.net Sat Jan 12 01:33:25 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 12 Jan 2008 01:33:25 +0100 Subject: [LinuxBIOS] Messing with CAR in a big way In-Reply-To: <47880762.4000003@assembler.cz> References: <4788062A.5060900@gmx.net> <47880762.4000003@assembler.cz> Message-ID: <47880AD5.70709@gmx.net> On 12.01.2008 01:18, Rudolf Marek wrote: > Imho you must copy the data from CAR, because when it is OFF, no > writeback is > done to memory: (from BKDG) > > Temporary data stored in the cache during boot cannot be written back > to DRAM > after enabling the > DRAM controller using a CLFLUSH or WBINVB instruction. The cache should be > invalidated after the DRAM controller is initialized with an INVD > instruction. OK, then we simply copy the whole CAR area to some backup memory location, disable CAR, then INVD and copy everything back to the original location. That way, moving the stack with all of its nasty side effects will not happen. > The later is imho not done in LB I think. Maybe needs fix? I have to reread the v2 code. Almost all BIOS code I write nowadays is either for code shared between v2 and v3 or for v3 only. > Btw please design it to be suspend-to-ram friendly ;) Will do. Is there any specific part of the source that lists your requirements for suspend-to-RAM? IIRC resume-from-RAM enables CAR, gets RAM out of self-refresh, then jumps back to the OS. Writing to arbitrary RAM locations has to be avoided with suspend-to-RAM. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Sat Jan 12 01:35:42 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 12 Jan 2008 01:35:42 +0100 Subject: [LinuxBIOS] Messing with CAR in a big way In-Reply-To: <13426df10801111625w4f557de5ya93e16a9d83fbbf@mail.gmail.com> References: <4788062A.5060900@gmx.net> <13426df10801111625w4f557de5ya93e16a9d83fbbf@mail.gmail.com> Message-ID: <47880B5E.7080901@gmx.net> On 12.01.2008 01:25, ron minnich wrote: > On Jan 11, 2008 4:13 PM, Carl-Daniel Hailfinger > wrote: > > >> Ron, where would you like to have the CAR area to avoid copying the >> stack around in v2? Any places where stack location is hardcoded without >> using the usual #define? >> >> > > If you could put it at x800000 that would work very well with what I'm > doing on LX. > One zero too many? Your location would be 8 MB. That is impossible according to the BKDG. > Be advised that car on older opterons is a bit tricky, due to > limitations in the hardware. I can't test on older k8 any more, all I > have is an AM2. > I think SimNow may be good enough for first tests of older hardware. Regards, Carl-Daniel From rminnich at gmail.com Sat Jan 12 01:40:23 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 11 Jan 2008 16:40:23 -0800 Subject: [LinuxBIOS] Messing with CAR in a big way In-Reply-To: <47880B5E.7080901@gmx.net> References: <4788062A.5060900@gmx.net> <13426df10801111625w4f557de5ya93e16a9d83fbbf@mail.gmail.com> <47880B5E.7080901@gmx.net> Message-ID: <13426df10801111640n78b84244of77c3dbd711a8ab2@mail.gmail.com> On Jan 11, 2008 4:35 PM, Carl-Daniel Hailfinger wrote: > One zero too many? Your location would be 8 MB. That is impossible > according to the BKDG. yes, my mistake. ron > > > Be advised that car on older opterons is a bit tricky, due to > > limitations in the hardware. I can't test on older k8 any more, all I > > have is an AM2. > > > > I think SimNow may be good enough for first tests of older hardware. > > > Regards, > Carl-Daniel > From rminnich at gmail.com Sat Jan 12 01:43:10 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 11 Jan 2008 16:43:10 -0800 Subject: [LinuxBIOS] Messing with CAR in a big way In-Reply-To: <47880AD5.70709@gmx.net> References: <4788062A.5060900@gmx.net> <47880762.4000003@assembler.cz> <47880AD5.70709@gmx.net> Message-ID: <13426df10801111643l5e054cf7y80409094515a7787@mail.gmail.com> On Jan 11, 2008 4:33 PM, Carl-Daniel Hailfinger wrote: > On 12.01.2008 01:18, Rudolf Marek wrote: > > Temporary data stored in the cache during boot cannot be written back > > to DRAM > > after enabling the > > DRAM controller using a CLFLUSH or WBINVB instruction. The cache should be > > invalidated after the DRAM controller is initialized with an INVD > > instruction. are you sure? I ask because what i am doing on LX (that worked) is to enable the cache, copy the stack back over itself, and then wbinvd. It worked well, I think it might work on k8. > OK, then we simply copy the whole CAR area to some backup memory > location, disable CAR, then INVD and copy everything back to the > original location. That way, moving the stack with all of its nasty side > effects will not happen. Just see the LX. Copy stack onto itself. Works fine. This was Marc Jone's idea. Just make sure the stack is in an area back by memory, like 0x80000 thanks ron From c-d.hailfinger.devel.2006 at gmx.net Sat Jan 12 01:46:41 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 12 Jan 2008 01:46:41 +0100 Subject: [LinuxBIOS] [PATCH] v3: Print a message before resetting the processor Message-ID: <47880DF1.901@gmx.net> After configuring the PLL registers on Geode LX, we have to reset the processor. However, nothing in the log tells the user why the processor is being reset. Example log follows: LinuxBIOS-3.0.0 Fri Jan 11 15:53:52 MST 2008 starting... Choosing fallback boot. [...] Fallback failed. Try normal boot LAR: Attempting to open 'normal/initram/segment0'. [...] LAR: CHECK normal/initram/segment0 @ 0xfffc49b0 start 0xfffc4a00 len 5564 reallen 5564 compression 0 entry 0x000010ca loadaddress 0x00000000 Entry point is 0xfffc5aca pll_reset: read msr 0x4c000014 _MSR GLCP_SYS_RSTPLL (4c000014) value is: 00000398:0000181e Configuring PLL LinuxBIOS-3.0.0 Fri Jan 11 15:53:52 MST 2008 starting... Choosing fallback boot. [...] Print an informative message before resetting the processor. Signed-off-by: Carl-Daniel Hailfinger Index: LinuxBIOSv3-betterpllreset/arch/x86/geodelx/geodelx.c =================================================================== --- LinuxBIOSv3-betterpllreset/arch/x86/geodelx/geodelx.c (Revision 551) +++ LinuxBIOSv3-betterpllreset/arch/x86/geodelx/geodelx.c (Arbeitskopie) @@ -187,6 +187,8 @@ /* Use SWFLAGS to remember: "we've already been here". */ msr_glcp_sys_pll.lo |= (1 << RSTPLL_LOWER_SWFLAGS_SHIFT); + printk(BIOS_INFO, "Resetting the processor after PLL " + "configuration for the changes to take effect\n"); /* "Reset the chip" value */ msr_glcp_sys_pll.lo |= RSTPPL_LOWER_CHIP_RESET_SET; wrmsr(GLCP_SYS_RSTPLL, msr_glcp_sys_pll); From rminnich at gmail.com Sat Jan 12 01:45:36 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 11 Jan 2008 16:45:36 -0800 Subject: [LinuxBIOS] Messing with CAR in a big way In-Reply-To: <47880B5E.7080901@gmx.net> References: <4788062A.5060900@gmx.net> <13426df10801111625w4f557de5ya93e16a9d83fbbf@mail.gmail.com> <47880B5E.7080901@gmx.net> Message-ID: <13426df10801111645s447414e1nd66d0bb574f3bb01@mail.gmail.com> For reference here is the geode lx disable car. CAR is at 80000. The steps are to re-enable cache (for loop), then dirty all the tags for the CAR area (cld; rep movsl; etc); then write it all back (wbinvd). Works really well. for (i = 0; i < ARRAY_SIZE(msr_table); i++) wrmsr(msr_table[i].msrnum, msr_table[i].msr); __asm__ __volatile__("cld; rep movsl" ::"D" (DCACHE_RAM_BASE), "S" (DCACHE_RAM_BASE), "c" (DCACHE_RAM_SIZE/4): "memory"); __asm__ __volatile__ ("wbinvd\n"); Would be great if this worked on k8. Thanks ron From rminnich at gmail.com Sat Jan 12 01:53:19 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 11 Jan 2008 16:53:19 -0800 Subject: [LinuxBIOS] [PATCH] v3: Print a message before resetting the processor In-Reply-To: <47880DF1.901@gmx.net> References: <47880DF1.901@gmx.net> Message-ID: <13426df10801111653j3bcbc251y6145519baa821224@mail.gmail.com> Acked-by: Ronald G. Minnich From duwe at lst.de Sat Jan 12 01:58:39 2008 From: duwe at lst.de (Torsten Duwe) Date: Sat, 12 Jan 2008 01:58:39 +0100 Subject: [LinuxBIOS] [PATCH] v3: Print a message before resetting the processor In-Reply-To: <47880DF1.901@gmx.net> References: <47880DF1.901@gmx.net> Message-ID: <200801120158.39897.duwe@lst.de> On Saturday 12 January 2008, Carl-Daniel Hailfinger wrote: > After configuring the PLL registers on Geode LX, we have to reset the > processor. However, nothing in the log tells the user why the processor > is being reset. > + printk(BIOS_INFO, "Resetting the processor after PLL " > + "configuration for the changes to take effect\n"); > /* "Reset the chip" value */ It shouldn't be BIOS_INFO. Resetting the machine is as fundamental as can be, so always tell this news if someone is listening (-> BIOS_EMERG). IMHO a few stars might be appropriate as well, but that's a matter of taste. Besides that Acked-by: Torsten Duwe Torsten From c-d.hailfinger.devel.2006 at gmx.net Sat Jan 12 02:10:23 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 12 Jan 2008 02:10:23 +0100 Subject: [LinuxBIOS] Messing with CAR in a big way In-Reply-To: <13426df10801111645s447414e1nd66d0bb574f3bb01@mail.gmail.com> References: <4788062A.5060900@gmx.net> <13426df10801111625w4f557de5ya93e16a9d83fbbf@mail.gmail.com> <47880B5E.7080901@gmx.net> <13426df10801111645s447414e1nd66d0bb574f3bb01@mail.gmail.com> Message-ID: <4788137F.6050506@gmx.net> On 12.01.2008 01:45, ron minnich wrote: > For reference here is the geode lx disable car. CAR is at 80000. The > steps are to re-enable cache (for loop), then dirty all the tags for > the CAR area (cld; rep movsl; etc); then write it all back (wbinvd). > > Works really well. > > for (i = 0; i < ARRAY_SIZE(msr_table); i++) > wrmsr(msr_table[i].msrnum, msr_table[i].msr); > > __asm__ __volatile__("cld; rep movsl" ::"D" (DCACHE_RAM_BASE), > "S" (DCACHE_RAM_BASE), "c" (DCACHE_RAM_SIZE/4): "memory"); > > __asm__ __volatile__ ("wbinvd\n"); > > Would be great if this worked on k8. > Do you want CAR to start at 0x80000 and end at 0x87FFF or do you want it to start at 0x78000 and end at 0x7FFFF? I'm assuming the former. Try this: (no guarantees at all) Signed-off-by: Carl-Daniel Hailfinger Index: LinuxBIOSv2-myCAR/src/cpu/amd/car/cache_as_ram.inc =================================================================== --- LinuxBIOSv2-myCAR/src/cpu/amd/car/cache_as_ram.inc (Revision 3044) +++ LinuxBIOSv2-myCAR/src/cpu/amd/car/cache_as_ram.inc (Arbeitskopie) @@ -19,7 +19,7 @@ */ #define CacheSize DCACHE_RAM_SIZE -#define CacheBase (0xd0000 - CacheSize) +#define CacheBase (0x88000 - CacheSize) /* leave some space for global variable to pass to RAM stage */ #define GlobalVarSize DCACHE_RAM_GLOBAL_VAR_SIZE @@ -181,6 +181,7 @@ #error Invalid CAR size, is not a multiple of 4k. This is a processor limitation. #endif +#if 0 #if CacheSize > 0x8000 /* enable caching for 32K-64K using fixed mtrr */ movl $0x268, %ecx /* fix4k_c0000*/ @@ -191,6 +192,14 @@ /* enable caching for 0-32K using fixed mtrr */ movl $0x269, %ecx /* fix4k_c8000*/ simplemask CacheSize, 0 +#endif +#if CacheSize != 0x8000 +#error The new code wants CacheSize to be exactly 32k for now. +#endif + /* Enable caching from 0x80000-0x87FFF */ + movl $0x00000606, %eax + xorl %edx, %edx + movl $0x258, %ecx wrmsr /* enable memory access for first MBs using top_mem */ From svn at openbios.org Sat Jan 12 02:09:47 2008 From: svn at openbios.org (svn at openbios.org) Date: Sat, 12 Jan 2008 02:09:47 +0100 Subject: [LinuxBIOS] r553 - LinuxBIOSv3/arch/x86/geodelx Message-ID: Author: hailfinger Date: 2008-01-12 02:09:47 +0100 (Sat, 12 Jan 2008) New Revision: 553 Modified: LinuxBIOSv3/arch/x86/geodelx/geodelx.c Log: After configuring the PLL registers on Geode LX, we have to reset the processor. However, nothing in the log tells the user why the processor is being reset. Example log follows: LinuxBIOS-3.0.0 Fri Jan 11 15:53:52 MST 2008 starting... Choosing fallback boot. [...] Fallback failed. Try normal boot LAR: Attempting to open 'normal/initram/segment0'. [...] LAR: CHECK normal/initram/segment0 @ 0xfffc49b0 start 0xfffc4a00 len 5564 reallen 5564 compression 0 entry 0x000010ca loadaddress 0x00000000 Entry point is 0xfffc5aca pll_reset: read msr 0x4c000014 _MSR GLCP_SYS_RSTPLL (4c000014) value is: 00000398:0000181e Configuring PLL LinuxBIOS-3.0.0 Fri Jan 11 15:53:52 MST 2008 starting... Choosing fallback boot. [...] Print an informative message before resetting the processor. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Ronald G. Minnich Modified: LinuxBIOSv3/arch/x86/geodelx/geodelx.c =================================================================== --- LinuxBIOSv3/arch/x86/geodelx/geodelx.c 2008-01-10 21:13:19 UTC (rev 552) +++ LinuxBIOSv3/arch/x86/geodelx/geodelx.c 2008-01-12 01:09:47 UTC (rev 553) @@ -187,6 +187,8 @@ /* Use SWFLAGS to remember: "we've already been here". */ msr_glcp_sys_pll.lo |= (1 << RSTPLL_LOWER_SWFLAGS_SHIFT); + printk(BIOS_INFO, "Resetting the processor after PLL " + "configuration for the changes to take effect\n"); /* "Reset the chip" value */ msr_glcp_sys_pll.lo |= RSTPPL_LOWER_CHIP_RESET_SET; wrmsr(GLCP_SYS_RSTPLL, msr_glcp_sys_pll); From c-d.hailfinger.devel.2006 at gmx.net Sat Jan 12 02:11:24 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 12 Jan 2008 02:11:24 +0100 Subject: [LinuxBIOS] [PATCH] v3: Print a message before resetting the processor In-Reply-To: <13426df10801111653j3bcbc251y6145519baa821224@mail.gmail.com> References: <47880DF1.901@gmx.net> <13426df10801111653j3bcbc251y6145519baa821224@mail.gmail.com> Message-ID: <478813BC.2080909@gmx.net> On 12.01.2008 01:53, ron minnich wrote: > Acked-by: Ronald G. Minnich > Thanks, r553. Regards, Carl-Daniel From duwe at lst.de Sat Jan 12 02:08:59 2008 From: duwe at lst.de (Torsten Duwe) Date: Sat, 12 Jan 2008 02:08:59 +0100 Subject: [LinuxBIOS] [PATCH] v3: Print a message before resetting the processor In-Reply-To: <13426df10801111653j3bcbc251y6145519baa821224@mail.gmail.com> References: <47880DF1.901@gmx.net> <13426df10801111653j3bcbc251y6145519baa821224@mail.gmail.com> Message-ID: <200801120208.59357.duwe@lst.de> On Saturday 12 January 2008, ron minnich wrote: > Acked-by: Ronald G. Minnich [BIOS_INFO vs. BIOS_EMERG] Think about it this way: whichever log level is set, the information that a repeating log is intentional should be there. Torsten From c-d.hailfinger.devel.2006 at gmx.net Sat Jan 12 02:14:53 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 12 Jan 2008 02:14:53 +0100 Subject: [LinuxBIOS] [PATCH] v3: Print a message before resetting the processor In-Reply-To: <200801120158.39897.duwe@lst.de> References: <47880DF1.901@gmx.net> <200801120158.39897.duwe@lst.de> Message-ID: <4788148D.8010606@gmx.net> On 12.01.2008 01:58, Torsten Duwe wrote: > On Saturday 12 January 2008, Carl-Daniel Hailfinger wrote: > >> After configuring the PLL registers on Geode LX, we have to reset the >> processor. However, nothing in the log tells the user why the processor >> is being reset. >> > > >> + printk(BIOS_INFO, "Resetting the processor after PLL " >> + "configuration for the changes to take effect\n"); >> /* "Reset the chip" value */ >> > > It shouldn't be BIOS_INFO. Resetting the machine is as fundamental as can be, > so always tell this news if someone is listening (-> BIOS_EMERG). IMHO a few > stars might be appropriate as well, but that's a matter of taste. Besides > that > Sorry, I saw your mail too late. I agree that it should have a high level, but since almost all messages in v3 are BIOS_DEBUG and even the first "LinuxBIOS v3.0.0 starting" is BIOS_INFO, I thought BIOS_INFO would be OK. BIOS_EMERG is a bit strong because every cold boot will trigger that code path by design. Someone needs to go through all those printk() and decide which level is appropriate for each message. > Acked-by: Torsten Duwe > Thanks! Regards, Carl-Daniel From joe at smittys.pointclark.net Sat Jan 12 02:16:58 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Fri, 11 Jan 2008 20:16:58 -0500 Subject: [LinuxBIOS] Intel refactoring and microcode updates In-Reply-To: <20080111153321.GB16602@greenwood> References: <47843324.2050907@gmail.com> <20080109212412.cgsck1t6xxcww4s8@www.smittys.pointclark.net> <4785AC27.40102@gmail.com> <20080110074842.3p5v4fkoowkg408w@www.smittys.pointclark.net> <4786C75F.9080806@gmail.com> <4786CADD.7030305@gmx.net> <4786D5B4.1040108@gmail.com> <20080111033439.1814.qmail@stuge.se> <47878038.3070102@gmail.com> <20080111145418.17092.qmail@stuge.se> <20080111153321.GB16602@greenwood> Message-ID: <20080111201658.1bl8gyy40oo04ggo@www.smittys.pointclark.net> Quoting Uwe Hermann : > On Fri, Jan 11, 2008 at 03:54:18PM +0100, Peter Stuge wrote: >> On Fri, Jan 11, 2008 at 09:42:00AM -0500, Corey Osgood wrote: >> > Peter Stuge wrote: >> > > I think we need to make it configurable. >> > >> > I don't like that. With a factory bios, you expect the correct >> > microcode update for your CPU to be present, no matter what CPU you >> > put in a socket. >> >> (Actually no, not always.) >> >> >> > We should be able to do the same. >> >> I agree, but we should also try to be even more flexible. I think we >> should allow inclusion of 0<=n<=all microcode updates. Definately an >> advanced option, but still. > > Yep, that's what I meant. It's fine if the default is "all microcode > updates", but there should be an option for advanced users to only use > the one(s) you really want or need in order to save time and space. > > > Uwe. > That makes perfect sense.....I like the advanced option idea:-) Thanks - Joe From duwe at lst.de Sat Jan 12 02:20:21 2008 From: duwe at lst.de (Torsten Duwe) Date: Sat, 12 Jan 2008 02:20:21 +0100 Subject: [LinuxBIOS] [PATCH] v3: Print a message before resetting the processor In-Reply-To: <4788148D.8010606@gmx.net> References: <47880DF1.901@gmx.net> <200801120158.39897.duwe@lst.de> <4788148D.8010606@gmx.net> Message-ID: <200801120220.21930.duwe@lst.de> On Saturday 12 January 2008, Carl-Daniel Hailfinger wrote: > BIOS_EMERG is a bit strong because every cold boot will > trigger that code path by design. OTOH after the new PLL values the machine _is_ unusable unless reset, right? As I replied to Ron, this message should be prioritised as high as the highest other message in that area, to always note that the reset is intentional. > Someone needs to go through all those printk() and decide which level is > appropriate for each message. If they're all BIOS_INFO then there's no problem :-) > > Acked-by: Torsten Duwe > > Thanks! Welcome. Torsten From rminnich at gmail.com Sat Jan 12 02:23:38 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 11 Jan 2008 17:23:38 -0800 Subject: [LinuxBIOS] Messing with CAR in a big way In-Reply-To: <4788137F.6050506@gmx.net> References: <4788062A.5060900@gmx.net> <13426df10801111625w4f557de5ya93e16a9d83fbbf@mail.gmail.com> <47880B5E.7080901@gmx.net> <13426df10801111645s447414e1nd66d0bb574f3bb01@mail.gmail.com> <4788137F.6050506@gmx.net> Message-ID: <13426df10801111723l548a0b8flf24224d8edc8b1c3@mail.gmail.com> On Jan 11, 2008 5:10 PM, Carl-Daniel Hailfinger wrote: > Do you want CAR to start at 0x80000 and end at 0x87FFF Oh shoot, I just realized, on LX it goes from 88000 to 88fff. But it doesn't matter that much. 80000 to 87fff is fine too. ron From rminnich at gmail.com Sat Jan 12 02:27:48 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 11 Jan 2008 17:27:48 -0800 Subject: [LinuxBIOS] Intel refactoring and microcode updates In-Reply-To: <20080111201658.1bl8gyy40oo04ggo@www.smittys.pointclark.net> References: <47843324.2050907@gmail.com> <20080110074842.3p5v4fkoowkg408w@www.smittys.pointclark.net> <4786C75F.9080806@gmail.com> <4786CADD.7030305@gmx.net> <4786D5B4.1040108@gmail.com> <20080111033439.1814.qmail@stuge.se> <47878038.3070102@gmail.com> <20080111145418.17092.qmail@stuge.se> <20080111153321.GB16602@greenwood> <20080111201658.1bl8gyy40oo04ggo@www.smittys.pointclark.net> Message-ID: <13426df10801111727r704ed8d3i15be74e5de47de63@mail.gmail.com> note that on V3, we have the neat ability to put microcode in LAR, and find it there on boot. So we might have another top level directory: /microcode And then you can figure out, long after the bios is built, which microcode updates you want to support. ron From c-d.hailfinger.devel.2006 at gmx.net Sat Jan 12 02:32:52 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 12 Jan 2008 02:32:52 +0100 Subject: [LinuxBIOS] Messing with CAR in a big way In-Reply-To: <13426df10801111723l548a0b8flf24224d8edc8b1c3@mail.gmail.com> References: <4788062A.5060900@gmx.net> <13426df10801111625w4f557de5ya93e16a9d83fbbf@mail.gmail.com> <47880B5E.7080901@gmx.net> <13426df10801111645s447414e1nd66d0bb574f3bb01@mail.gmail.com> <4788137F.6050506@gmx.net> <13426df10801111723l548a0b8flf24224d8edc8b1c3@mail.gmail.com> Message-ID: <478818C4.4040605@gmx.net> On 12.01.2008 02:23, ron minnich wrote: > On Jan 11, 2008 5:10 PM, Carl-Daniel Hailfinger > wrote: > > >> Do you want CAR to start at 0x80000 and end at 0x87FFF >> > > Oh shoot, I just realized, on LX it goes from 88000 to 88fff. But it > doesn't matter that much. 80000 to 87fff is fine too. > No problem, try this one: Index: LinuxBIOSv2-myCAR/src/cpu/amd/car/cache_as_ram.inc =================================================================== --- LinuxBIOSv2-myCAR/src/cpu/amd/car/cache_as_ram.inc (Revision 3044) +++ LinuxBIOSv2-myCAR/src/cpu/amd/car/cache_as_ram.inc (Arbeitskopie) @@ -19,7 +19,7 @@ */ #define CacheSize DCACHE_RAM_SIZE -#define CacheBase (0xd0000 - CacheSize) +#define CacheBase (0x90000 - CacheSize) /* leave some space for global variable to pass to RAM stage */ #define GlobalVarSize DCACHE_RAM_GLOBAL_VAR_SIZE @@ -181,6 +181,7 @@ #error Invalid CAR size, is not a multiple of 4k. This is a processor limitation. #endif +#if 0 #if CacheSize > 0x8000 /* enable caching for 32K-64K using fixed mtrr */ movl $0x268, %ecx /* fix4k_c0000*/ @@ -191,6 +192,14 @@ /* enable caching for 0-32K using fixed mtrr */ movl $0x269, %ecx /* fix4k_c8000*/ simplemask CacheSize, 0 +#endif +#if CacheSize != 0x8000 +#error The new code wants CacheSize to be exactly 32k for now. +#endif + /* Enable caching from 0x88000-0x8FFFF */ + movl $0x06060000, %eax + xorl %edx, %edx + movl $0x258, %ecx wrmsr /* enable memory access for first MBs using top_mem */ From rminnich at gmail.com Sat Jan 12 02:43:41 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 11 Jan 2008 17:43:41 -0800 Subject: [LinuxBIOS] Welcome to coreboot. Message-ID: <13426df10801111743x101d9e24v6ae046df01873597@mail.gmail.com> Welcome to coreboot! It's been 10 years (in octal anyway!) since the first successful LinuxBIOS boot. In those days, by design, LinuxBIOS looked like this: LinuxBIOS = (core boot code) + (Linux kernel) We did not consider LinuxBIOS to be separable in any way from Linux, and in fact the name LinuxBIOS really meant just that -- Linux as the BIOS. In the early config tool, there was no 'payload' keyword: there was a 'linux' keyword, since only linux payloads were supported. Several things happened in the following years. While this: LinuxBIOS = (core boot code) + (Linux 2.2 kernel) fit easily in 512 Kbytes, this: LinuxBIOS = (core boot code) + (Linux 2.4 kernel) required 1 Mbyte. At about the same time we moved to 2.4, vendors moved the flash sizes ... down. In 1999, 1 Mbyte flash sizes were common on the cluster nodes we intended to use LinuxBIOS on; by 2001, 256KB was the limit, and it was physically impossible to put anything larger than 512KB on the systems.The result was that LinuxBIOS could no longer use Linux on these systems! At that point, people started to change to this: LinuxBIOS = (core boot code) + (Etherboot) But, that was a little confusing. LinuxBIOS did not really mean "Etherboot". So we actually did this with the name: BIOS ROM = (LinuxBIOS) + (Etherboot) In other words, we shrunk the scope of LinuxBIOS to mean 'the core boot code'. So, what we really meant was "core boot code" but we called it "LinuxBIOS". Of course, people did not stop there. By now, we have seen: BIOS ROM = (LinuxBIOS) + (Open Firmware) BIOS ROM = (LinuxBIOS) + (Slim Line Open Firmware) BIOS ROM = (LinuxBIOS) + (FILO) BIOS ROM = (LinuxBIOS) + (GRUB 2) BIOS ROM = (LinuxBIOS) + (Plan 9 loader) BIOS ROM = (LinuxBIOS) + (Plan 9 kernel) BIOS ROM = (LinuxBIOS) + (WIN CE loader) BIOS ROM = (LinuxBIOS) + (Open BIOS) BIOS ROM = (LinuxBIOS) + (Linux kernel) BIOS ROM = (LinuxBIOS) + (ADLO) (which lets us boot Windows) BIOS ROM = (LinuxBIOS) + (Tiano Core) And many other uses we don't even know about! It may well be that a larger variety of BIOSes have been supported on the LinuxBIOS core boot code than any other software. As you can see, what LinuxBIOS has really meant for the past few years is "the core boot code". In almost every case, when a system has shipped with "LinuxBIOS", what it has really shipped with is the "core boot code" + "a boot loader such as FILO". There has been no Linux in the ROM on these systems. At the same time, the use of the name "Linux" in "LinuxBIOS" has led to lots of confusion. Many companies had trouble thinking about the name, as they assumed (not unreasonably) that we were requiring Linux in ROM. As a result, starting last year, we decided to look at a new name. We had lots of candidates, and discussed the name with many companies. In the end, the name that seemed to stick was "coreboot". It makes a lot of sense: the code we are working on is the "core boot code". So, starting this year, the 10th (base 8!) anniversary of the first LinuxBIOS boot, we are transitioning to the name coreboot. As you can see from the above, coreboot can support all kinds of software, still including Linux. What of the name LinuxBIOS? It still has meaning. When a company ships a system that looks like this: BIOS ROM = (coreboot) + (Linux 2.6 kernel) What do we call it? Well, that system is LinuxBIOS in the original sense of the term -- Linux as the BIOS. And, as it happens, more and more companies are shipping systems configured this way. This name change was a lot of work. A great deal of behind-the-scenes work has been done by Stefan Reinauer, so I hope you will join me in thanking Stefan for a job well done. We will make the changes slowly and with a lot of preparation. You have already seen the IRC channel change, and host names change over to coreboot.org. At some point in the next three months you will see a change in the svn repository name. We're going to be very careful to ensure nothing breaks. As always, thanks for all your help and support. I look forward to the next 10 (base 10!) years. Ron Minnich From peter at stuge.se Sat Jan 12 04:05:53 2008 From: peter at stuge.se (Peter Stuge) Date: Sat, 12 Jan 2008 04:05:53 +0100 Subject: [LinuxBIOS] AMD SimNOW (program) fails to run In-Reply-To: <370062.40109.qm@web33213.mail.mud.yahoo.com> References: <370062.40109.qm@web33213.mail.mud.yahoo.com> Message-ID: <20080112030553.9895.qmail@stuge.se> On Fri, Jan 11, 2008 at 02:01:22PM -0800, Andon Tschauschev wrote: > info: creating device #8 "AweSim Processor" > FixIt: Error: Unable to allocate processor model memory. > Aborted .. > mmap(0x5400000000, 2147483648, PROT_NONE,MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot allocate memory) > mmap(NULL, 2147483648, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot allocate memory) It seems you're out of RAM. Add another gig or two (swap worst case) to the system and try again. //Peter From corey.osgood at gmail.com Sat Jan 12 04:07:47 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Fri, 11 Jan 2008 22:07:47 -0500 Subject: [LinuxBIOS] r3021 build service In-Reply-To: <2831fecf0801111229h17a146bm584b1e0ddcaf5222@mail.gmail.com> References: <476A17EF.1040308@gmail.com> <476AC059.3060604@AMD.com> <2831fecf0801111229h17a146bm584b1e0ddcaf5222@mail.gmail.com> Message-ID: <47882F03.6040808@gmail.com> Myles Watson wrote: > Here's my attempt at fixing abuild for serengeti_cheetah_fam10. > > It's pretty trivial, since I'm just using the ROM_IMAGE_SIZE in > Config.lb and putting it in Config-abuild.lb. When I reduce this size > (past what it is in Config-abuild.lb), it gives me the same overlap > error in my system that abuild is seeing. > > I also added XIP_ROM_SIZE, although I admit freely that I don't know > anything about this variable. I just wanted to make it match Marc's > Config.lb. > This should be set in the src/*/Config.lb, not here. Can you try it without the change? > Maybe the right thing to do would be to remove both XIP_ROM_SIZE > references in Config-abuild.lb > > Either way, I think the ROM_IMAGE_SIZE change will help. > > Myles > > Signed-off-by: Myles Watson Please check the above, but either way Acked-by: Corey Osgood From peter at stuge.se Sat Jan 12 04:20:37 2008 From: peter at stuge.se (Peter Stuge) Date: Sat, 12 Jan 2008 04:20:37 +0100 Subject: [LinuxBIOS] Intel refactoring and microcode updates In-Reply-To: <13426df10801111727r704ed8d3i15be74e5de47de63@mail.gmail.com> References: <20080110074842.3p5v4fkoowkg408w@www.smittys.pointclark.net> <4786C75F.9080806@gmail.com> <4786CADD.7030305@gmx.net> <4786D5B4.1040108@gmail.com> <20080111033439.1814.qmail@stuge.se> <47878038.3070102@gmail.com> <20080111145418.17092.qmail@stuge.se> <20080111153321.GB16602@greenwood> <20080111201658.1bl8gyy40oo04ggo@www.smittys.pointclark.net> <13426df10801111727r704ed8d3i15be74e5de47de63@mail.gmail.com> Message-ID: <20080112032037.13841.qmail@stuge.se> On Fri, Jan 11, 2008 at 05:27:48PM -0800, ron minnich wrote: > note that on V3, we have the neat ability to put microcode in LAR, > and find it there on boot. > > So we might have another top level directory: /microcode > > And then you can figure out, long after the bios is built, which > microcode updates you want to support. A good deal indeed. //Peter From corey.osgood at gmail.com Sat Jan 12 04:24:40 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Fri, 11 Jan 2008 22:24:40 -0500 Subject: [LinuxBIOS] Intel refactoring and microcode updates In-Reply-To: <13426df10801111727r704ed8d3i15be74e5de47de63@mail.gmail.com> References: <47843324.2050907@gmail.com> <20080110074842.3p5v4fkoowkg408w@www.smittys.pointclark.net> <4786C75F.9080806@gmail.com> <4786CADD.7030305@gmx.net> <4786D5B4.1040108@gmail.com> <20080111033439.1814.qmail@stuge.se> <47878038.3070102@gmail.com> <20080111145418.17092.qmail@stuge.se> <20080111153321.GB16602@greenwood> <20080111201658.1bl8gyy40oo04ggo@www.smittys.pointclark.net> <13426df10801111727r704ed8d3i15be74e5de47de63@mail.gmail.com> Message-ID: <478832F8.4000904@gmail.com> ron minnich wrote: > note that on V3, we have the neat ability to put microcode in LAR, and > find it there on boot. > > So we might have another top level directory: /microcode > > And then you can figure out, long after the bios is built, which > microcode updates you want to support. > > ron > This is what I'm thinking, once v3 gets going. For now, I think LGA775 is about to get split, socket 603 works (I forgot that it really does build now, ignore my previous statement), and socket 604, well, I'll try to find out more on exactly what cores were used. Thanks, Corey From corey.osgood at gmail.com Sat Jan 12 04:32:36 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Fri, 11 Jan 2008 22:32:36 -0500 Subject: [LinuxBIOS] Intel refactoring and microcode updates In-Reply-To: <20080111201658.1bl8gyy40oo04ggo@www.smittys.pointclark.net> References: <47843324.2050907@gmail.com> <20080109212412.cgsck1t6xxcww4s8@www.smittys.pointclark.net> <4785AC27.40102@gmail.com> <20080110074842.3p5v4fkoowkg408w@www.smittys.pointclark.net> <4786C75F.9080806@gmail.com> <4786CADD.7030305@gmx.net> <4786D5B4.1040108@gmail.com> <20080111033439.1814.qmail@stuge.se> <47878038.3070102@gmail.com> <20080111145418.17092.qmail@stuge.se> <20080111153321.GB16602@greenwood> <20080111201658.1bl8gyy40oo04ggo@www.smittys.pointclark.net> Message-ID: <478834D4.9070208@gmail.com> joe at smittys.pointclark.net wrote: > Quoting Uwe Hermann : > > >> On Fri, Jan 11, 2008 at 03:54:18PM +0100, Peter Stuge wrote: >> >>> On Fri, Jan 11, 2008 at 09:42:00AM -0500, Corey Osgood wrote: >>> >>>> Peter Stuge wrote: >>>> >>>>> I think we need to make it configurable. >>>>> >>>> I don't like that. With a factory bios, you expect the correct >>>> microcode update for your CPU to be present, no matter what CPU you >>>> put in a socket. >>>> >>> (Actually no, not always.) >>> >>> >>> >>>> We should be able to do the same. >>>> >>> I agree, but we should also try to be even more flexible. I think we >>> should allow inclusion of 0<=n<=all microcode updates. Definately an >>> advanced option, but still. >>> >> Yep, that's what I meant. It's fine if the default is "all microcode >> updates", but there should be an option for advanced users to only use >> the one(s) you really want or need in order to save time and space. >> >> >> Uwe. >> >> > That makes perfect sense.....I like the advanced option idea:-) > > Thanks - Joe This seems like it would get very messy, very quickly. The only way I can come up with to do it is #if's for every single ID, perhaps in some intel_custom folder, so it doesn't make a mess of the existing stuff. Anyways, I'll get on top of testing this weekend, I have slot 1 (440zx), socket 370 (i810), and socket 479 (i830) boards I can test with, assuming they all still work. If those work, I'll bet the farm that the rest of them do. Everything passes abuild, btw. -Corey From corey.osgood at gmail.com Sat Jan 12 05:11:27 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Fri, 11 Jan 2008 23:11:27 -0500 Subject: [LinuxBIOS] [PATCH] Drop microcode references from Via CPUs Message-ID: <47883DEF.7080707@slightlyhackish.com> Via C3 datasheets don't make any mention of microcode updates, and the C7 bios programmer's guide explicitly states they're not necessary, and leaves it at that. Even if they are possible and exist, we don't have any info on it, nor any updates, so drop these unneeded references. Signed-off-by: Corey Osgood -------------- next part -------------- A non-text attachment was scrubbed... Name: drop_via_microcode.patch Type: text/x-patch Size: 794 bytes Desc: not available URL: From yinghailu at gmail.com Sat Jan 12 08:59:31 2008 From: yinghailu at gmail.com (yhlu) Date: Fri, 11 Jan 2008 23:59:31 -0800 Subject: [LinuxBIOS] AMD SimNOW (program) fails to run In-Reply-To: <20080112030553.9895.qmail@stuge.se> References: <370062.40109.qm@web33213.mail.mud.yahoo.com> <20080112030553.9895.qmail@stuge.se> Message-ID: <2ea3fae10801112359p1ee42639m14da84d8233b0a46@mail.gmail.com> On Jan 11, 2008 7:05 PM, Peter Stuge wrote: > On Fri, Jan 11, 2008 at 02:01:22PM -0800, Andon Tschauschev wrote: > > info: creating device #8 "AweSim Processor" > > FixIt: Error: Unable to allocate processor model memory. > > Aborted > > .. > > > mmap(0x5400000000, 2147483648, PROT_NONE,MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot allocate memory) > > mmap(NULL, 2147483648, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot allocate memory) > > It seems you're out of RAM. > > Add another gig or two (swap worst case) to the system and try again. > or use one simple model with one cpu and 64m. YH From r.marek at assembler.cz Sat Jan 12 11:45:47 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Sat, 12 Jan 2008 11:45:47 +0100 Subject: [LinuxBIOS] Messing with CAR in a big way In-Reply-To: <47880AD5.70709@gmx.net> References: <4788062A.5060900@gmx.net> <47880762.4000003@assembler.cz> <47880AD5.70709@gmx.net> Message-ID: <47889A5B.8040604@assembler.cz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Carl-Daniel Hailfinger wrote: > On 12.01.2008 01:18, Rudolf Marek wrote: >> Imho you must copy the data from CAR, because when it is OFF, no >> writeback is >> done to memory: (from BKDG) >> >> Temporary data stored in the cache during boot cannot be written back >> to DRAM >> after enabling the >> DRAM controller using a CLFLUSH or WBINVB instruction. The cache should be >> invalidated after the DRAM controller is initialized with an INVD >> instruction. > > OK, then we simply copy the whole CAR area to some backup memory > location, disable CAR, then INVD and copy everything back to the > original location. That way, moving the stack with all of its nasty side > effects will not happen. > >> The later is imho not done in LB I think. Maybe needs fix? > > I have to reread the v2 code. Almost all BIOS code I write nowadays is > either for code shared between v2 and v3 or for v3 only. Ok, I tried to research this yesterday but failed to find it. > >> Btw please design it to be suspend-to-ram friendly ;) > > Will do. Is there any specific part of the source that lists your > requirements for suspend-to-RAM? IIRC resume-from-RAM enables CAR, gets > RAM out of self-refresh, then jumps back to the OS. Writing to arbitrary > RAM locations has to be avoided with suspend-to-RAM. Yes or at least now please write to 1MB - TOPK region as it is done now in v2. So the CAR is written directly bellow to TOPK. I think for S3 I will need to define LOWK too. -maybe just _RAMBASE But lets assume now that 1MB-TOPK memory can be used. Please try to avoid writings anywhere in bellow 1MB as possible (to RAM, CAR location is "dont care" for me). I think to run S3 from unpatched kernel I still need to fix Secondary.S boot plus my reset realmode routine. I think I will put it directly to first 4KB of memory, which will be later overwritten by tables anyway. So far, I would prefer if LB uses mem like this: 0-4KB (lowmem data area) _RAMBASE - TOPK 0xf000 BIOS segment for DSDT etc This memory should be reserved in e820 _RAMBASE-TOPK plus we can use ACPI memory hotplug to reclaim this memory back once linux is restored ;) (yeah my know idea ) So haveing _RAMBASE sitting at 1MB as default would be cool too, eliminates the stack computations for 1MB for APs too. Thanks, Rudolf > > Regards, > Carl-Daniel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHiJpb3J9wPJqZRNURAuQtAKCavij93Vg0f8TekFRdyLMshVV0yACeLLGl JBXCF65n+hlisp2eFool7tQ= =BfuB -----END PGP SIGNATURE----- From bishop.robinson at gmail.com Sat Jan 12 12:09:21 2008 From: bishop.robinson at gmail.com (Robinson Tryon) Date: Sat, 12 Jan 2008 06:09:21 -0500 Subject: [LinuxBIOS] adding "--list-supported" feature to superiotool #91 Message-ID: Here's a first shot at bug #91 (http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/91), adding a --list-supported switch to superiotool. I wasn't very sure about what the "wiki links" part of this feature entailed. I included the primary url for superiotool, but perhaps there's something more that needs to be done? In terms of formatting, I just grouped the chips by vendor. For chips that have dump support I added "(dump)" after their name. Signed-off-by: Robinson P. Tryon Oh, and how should I go about getting an account on Trac? I'd be happy to take a stab at adding --list-supported to flashrom (#90) once this patch passes muster. --R -------------- next part -------------- A non-text attachment was scrubbed... Name: superiotool-list-supported.patch Type: text/x-patch Size: 8452 bytes Desc: not available URL: From atschauschev at yahoo.com Sat Jan 12 12:56:09 2008 From: atschauschev at yahoo.com (Andon Tschauschev) Date: Sat, 12 Jan 2008 03:56:09 -0800 (PST) Subject: [LinuxBIOS] AMD SimNOW (program) fails to run In-Reply-To: <20080112030553.9895.qmail@stuge.se> Message-ID: <718699.33070.qm@web33202.mail.mud.yahoo.com> >> It seems you're out of RAM. You are right -- I forgot to look how many ressources the OS needs -- and openSUSE with KDE takes lots of. I try to use another distro that doesnt need so much, if this doesnt help, I take more RAM. > or use one simple model with one cpu and 64m. yes, I'm using 'cheetah_1p.bsd' Thanks Andon ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From jtmettala at gmail.com Sat Jan 12 13:15:34 2008 From: jtmettala at gmail.com (=?UTF-8?Q?Jouni_Mett=C3=A4l=C3=A4?=) Date: Sat, 12 Jan 2008 14:15:34 +0200 Subject: [LinuxBIOS] abit be6 Message-ID: <63e824e50801120415n36ec1197w1342f2c5710bb46e@mail.gmail.com> LinuxBios booted to filo. Motherboard is abit be6. This is azza/pt-6ibd/ config using http://coreboot.org/AZZA_PT-6IBD_Build_Tutorial. filo config was also from it. Config was modified to use just fallback image with 128k chip. I don't have spare 256k chip now. Flashing needed uniflash. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: minicom.cap Type: application/octet-stream Size: 18673 bytes Desc: not available URL: From joe at smittys.pointclark.net Sat Jan 12 16:13:20 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Sat, 12 Jan 2008 10:13:20 -0500 Subject: [LinuxBIOS] Intel refactoring and microcode updates In-Reply-To: <478834D4.9070208@gmail.com> References: <47843324.2050907@gmail.com> <20080109212412.cgsck1t6xxcww4s8@www.smittys.pointclark.net> <4785AC27.40102@gmail.com> <20080110074842.3p5v4fkoowkg408w@www.smittys.pointclark.net> <4786C75F.9080806@gmail.com> <4786CADD.7030305@gmx.net> <4786D5B4.1040108@gmail.com> <20080111033439.1814.qmail@stuge.se> <47878038.3070102@gmail.com> <20080111145418.17092.qmail@stuge.se> <20080111153321.GB16602@greenwood> <20080111201658.1bl8gyy40oo04ggo@www.smittys.pointclark.net> <478834D4.9070208@gmail.com> Message-ID: <20080112101320.guxodivebggsoosg@www.smittys.pointclark.net> Quoting Corey Osgood : > joe at smittys.pointclark.net wrote: >> Quoting Uwe Hermann : >> >> >>> On Fri, Jan 11, 2008 at 03:54:18PM +0100, Peter Stuge wrote: >>> >>>> On Fri, Jan 11, 2008 at 09:42:00AM -0500, Corey Osgood wrote: >>>> >>>>> Peter Stuge wrote: >>>>> >>>>>> I think we need to make it configurable. >>>>>> >>>>> I don't like that. With a factory bios, you expect the correct >>>>> microcode update for your CPU to be present, no matter what CPU you >>>>> put in a socket. >>>>> >>>> (Actually no, not always.) >>>> >>>> >>>> >>>>> We should be able to do the same. >>>>> >>>> I agree, but we should also try to be even more flexible. I think we >>>> should allow inclusion of 0<=n<=all microcode updates. Definately an >>>> advanced option, but still. >>>> >>> Yep, that's what I meant. It's fine if the default is "all microcode >>> updates", but there should be an option for advanced users to only use >>> the one(s) you really want or need in order to save time and space. >>> >>> >>> Uwe. >>> >>> >> That makes perfect sense.....I like the advanced option idea:-) >> >> Thanks - Joe > > This seems like it would get very messy, very quickly. The only way I > can come up with to do it is #if's for every single ID, perhaps in some > intel_custom folder, so it doesn't make a mess of the existing stuff. > > Anyways, I'll get on top of testing this weekend, I have slot 1 (440zx), > socket 370 (i810), and socket 479 (i830) boards I can test with, > assuming they all still work. If those work, I'll bet the farm that the > rest of them do. Everything passes abuild, btw. > > -Corey > Yeh, even though it is a good idea it probibly would complicate things alot. For now it may be better to just commit a piece at a time for each processor tested. I'm really interested in how the socket 479 (Pentium M) testing goes. Let us know:-) Thanks - Joe From stepan at coresystems.de Sat Jan 12 18:07:43 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 12 Jan 2008 18:07:43 +0100 Subject: [coreboot] [LinuxBIOS] Welcome to coreboot. In-Reply-To: <13426df10801111743x101d9e24v6ae046df01873597@mail.gmail.com> References: <13426df10801111743x101d9e24v6ae046df01873597@mail.gmail.com> Message-ID: <20080112170743.GA29072@coresystems.de> * ron minnich [080112 02:43]: > We will make the changes slowly and with a lot of preparation. You > have already seen the IRC channel change, and host names change over > to coreboot.org. At some point in the next three months you will see a > change in the svn repository name. We're going to be very careful to > ensure nothing breaks. I switched the mailing list over to the new name. The list archive was moved too. Please send mails to coreboot at coreboot.org in future. The web frontend is now available at http://www.coreboot.org/mailman/listinfo/coreboot Mails to linuxbios at linuxbios.org are sent to the new mailing list, too so the transition should be relatively seamless. Please send me an email if any problems occur. Best regards, Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From peter at stuge.se Sat Jan 12 18:20:49 2008 From: peter at stuge.se (Peter Stuge) Date: Sat, 12 Jan 2008 18:20:49 +0100 Subject: [coreboot] [LinuxBIOS] adding "--list-supported" feature to superiotool #91 In-Reply-To: References: Message-ID: <20080112172049.9116.qmail@stuge.se> Thanks for the patch! Some comments. On Sat, Jan 12, 2008 at 06:09:21AM -0500, Robinson Tryon wrote: > I wasn't very sure about what the "wiki links" part of this feature > entailed. I included the primary url for superiotool, but perhaps > there's something more that needs to be done? I think there's a page for each supported sio chip with the output from previous superiotool runs. Or there should be. Would be handy to have that address available as well. > Oh, and how should I go about getting an account on Trac? Stefan should get you hooked up. :) > +void print_fintek_chips(void) { > + char name [] = "Fintek"; > + print_vendor_chips(name, reg_table); > +} Why the extra char[]? The function parameter is const so the name could just be a string constant in the call. And thinking further I saw that the vendor name is given as a string constant in more places in the files. Perhaps make it a #define near the top of the file? That's a separate patch though, and just a thought. > +void print_vendor_chips(const char *vendor, > + const struct superio_registers reg_table[]) { > + int i, any_supported_chips = 0; > + > + printf(" Chips from %s:\n", vendor); > + > + for (i = 0; /* Nothing */; i++) { > + if (reg_table[i].superio_id == EOT) > + break; So why not write the break condition in the for statement? > + any_supported_chips = 1; > + print_chip(reg_table[i]); > + } > + > + if (!any_supported_chips) > + printf(" None.\n"); any_supported_chips could just check if 0==i, right? Also - isn't the vendor inclued in the reg_table? Why is it needed at all in this function? Sorry if I'm being slow. //Peter From rmh at aybabtu.com Sat Jan 12 18:17:41 2008 From: rmh at aybabtu.com (Robert Millan) Date: Sat, 12 Jan 2008 18:17:41 +0100 Subject: [coreboot] [LinuxBIOS] Welcome to coreboot. In-Reply-To: <13426df10801111743x101d9e24v6ae046df01873597@mail.gmail.com> References: <13426df10801111743x101d9e24v6ae046df01873597@mail.gmail.com> Message-ID: <20080112171741.GA5396@thorin> On Fri, Jan 11, 2008 at 05:43:41PM -0800, ron minnich wrote: > Of course, people did not stop there. By now, we have seen: > BIOS ROM = (LinuxBIOS) + (Open Firmware) > [...] > BIOS ROM = (LinuxBIOS) + (GRUB 2) To make it even worse, you can now have Open Firmware and GRUB on top of it ;-) http://lists.gnu.org/archive/html/grub-devel/2008-01/msg00232.html -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) From peter at stuge.se Sat Jan 12 18:24:52 2008 From: peter at stuge.se (Peter Stuge) Date: Sat, 12 Jan 2008 18:24:52 +0100 Subject: [coreboot] [LinuxBIOS] abit be6 In-Reply-To: <63e824e50801120415n36ec1197w1342f2c5710bb46e@mail.gmail.com> References: <63e824e50801120415n36ec1197w1342f2c5710bb46e@mail.gmail.com> Message-ID: <20080112172452.9934.qmail@stuge.se> On Sat, Jan 12, 2008 at 02:15:34PM +0200, Jouni Mett?l? wrote: > LinuxBios booted to filo. Motherboard is abit be6. This is azza/pt-6ibd/ > config using http://coreboot.org/AZZA_PT-6IBD_Build_Tutorial. filo > config was also from it. Cool! FILO doesn't find a hard drive at hda. Do you have one there? Either way, it would be nice if you could use memtest as payload and let it run for a few hours to check that RAM is set up right. //Peter From tsylla at gmail.com Sat Jan 12 18:51:21 2008 From: tsylla at gmail.com (Tom Sylla) Date: Sat, 12 Jan 2008 12:51:21 -0500 Subject: [coreboot] [LinuxBIOS] [PATCH] v3: add a check for a termination member In-Reply-To: <4786CF4F.8010605@gmx.net> References: <4780FF1B.2010308@gmx.net> <477ED8F5.1030807@gmx.net> <47800115.1060301@coresystems.de> <13426df10801051415q69c0b3er4e6efabcdbe5c3e3@mail.gmail.com> <47800451.3080805@coresystems.de> <13426df10801051429o44b18cd4j8f21d6dd976d7f90@mail.gmail.com> <47800753.6020900@coresystems.de> <13426df10801051444y5ca97762xd67c07783a9af478@mail.gmail.com> <20080106011152.21774.qmail@stuge.se> <13426df10801052052q416a8532g72e8478190763bfa@mail.gmail.com> <20080111013803.3369.qmail@stuge.se> <4786CF4F.8010605@gmx.net> Message-ID: <4788FE19.6030301@gmail.com> Carl-Daniel Hailfinger wrote: > Hopefully that's the worst case. Still horrible if we use 1 MByte ROMs - > 5 seconds for reading the whole ROM is unacceptable. Sort of tangential, but some asked for some measurements of speed of reads on 5536. I did some tests reading 64KB sequentially from an SST49LF002A on a 500MHz Geode LX platform. The numbers are all scaled up to time to read 1MB: 905ms - normal config 897ms - with a 5536 PCI region config added for the ROM region 738ms - with the region config set to prefetchable also This was just a rep movsd from the ROM to another memory location. So that is about 1us/byte, getting better with better configuration. Turning on a 5536 region config has the effect of making the reads get decoded medium instead of subtractive on PCI. Prefetch will let the 5536 use its PCI buffers to prefetch data from the ROM, so it has a big effect on sequential reads. From rminnich at gmail.com Sat Jan 12 18:52:34 2008 From: rminnich at gmail.com (ron minnich) Date: Sat, 12 Jan 2008 09:52:34 -0800 Subject: [coreboot] [LinuxBIOS] Messing with CAR in a big way In-Reply-To: <47889A5B.8040604@assembler.cz> References: <4788062A.5060900@gmx.net> <47880762.4000003@assembler.cz> <47880AD5.70709@gmx.net> <47889A5B.8040604@assembler.cz> Message-ID: <13426df10801120952p4ce34396xd4f8fe57437d8543@mail.gmail.com> Rudolf, many payloads start at 1 MB. I don't think we want to use CAR at that low address. What is the reason that we can't put all coreboot variables below 1MB? Just trying to understand s3 :-) ron From martin at marcher.name Sat Jan 12 20:20:13 2008 From: martin at marcher.name (Martin Marcher) Date: Sat, 12 Jan 2008 20:20:13 +0100 Subject: [coreboot] 2 Terabyte Limit of BIOS/MBR References: <4786943B.7050600@gmx.net> Message-ID: On Thursday 10 January 2008 22:55 Carl-Daniel Hailfinger wrote: > On 10.01.2008 21:59, Martin Marcher wrote: >> Hello, >> >> hope to be in the right place to ask this, if not just point me to where >> you think it's apropriate >> >> my Hardware is: >> >> Tyan Transport GT20 (B2865) >> http://www.tyan.com/support_download_manuals.aspx?model=B.GT20B2865 >> >> an Areca 1210 raid controller is attached to it and I just was hit by the >> 2TB limit which a BIOS can handle. >> > > Is the RAID array exactly 2 TB? Then the BIOS will see its size as 0. nope it's 3TB total. Running debian/etch we have seperate /boot / partitions and most of the space is used by some xen domUs. / is inside an LVM (guess that doesn't matter a lot since debian itself is ready for the large block device support) > Why should we replicate such a bug? If you use Linux as bootloader > inside LinuxBIOS and if the Linux kernel has support for devices >2 TB > enabled (all recent kernels do), you can boot from disks up to 65535 TB > (maybe even 131071 TB) if the adapter creates a virtual SATA device (the > limits are what you would expect from LBA48 addressing). Depending on > the device driver (you said the RAID adapter claims to be SCSI), the > limit may be even higher. the problem is I don't get to boot linux. Tried to boot from a cd with only grub on it but after some reading I concluded that grub relies on the disks reported from the bios. All grub finds is (cd) and fd0-9 - not a single hd device. > Three "solutions": > 1. Use LinuxBIOS and Linux as Bootloader (LAB) > 2. Use the vendor BIOS and boot from a smaller disk I do that right now, but I consider it a not optimal solution > 3. Use the vendor BIOS, but make sure the RAID is either smaller than 2 > TB or a few GB bigger than 2 TB (in that case the detected size would > probably be real size minus 2 TB). To be honest, this tip may or may not > work, depending on how broken the BIOS is. well it's not working since the disk is "stuck" at >2TB (750GB are used the rest is free, but the raid controller doesn't have an option to shrink it back) > >> 3) Last, not least I couldn't the Tyan GT20 in the supported hardware >> list, is that true or just missing. >> > > True. It should be supportable, though, if we have one board to > experiment with. The Tyan Tomcat K8E S2865 is the board inside according > to the manual. > >> If it's missing I'll bug Tyan about this once a month or so, in case you >> don't have the specs available to send it to you (if you want me to do >> that). > > How much time are you willing to invest to port LinuxBIOS to the board? If it was only me: as much as needed We are a small company with 2 physical server but given I could find a setup where I can install and uninstall linuxbios securely (in case it won't work) I guess I could talk my boss into allowing me to regularly taking the server down and test the bios - reading up on this in the wiki now /martin -- http://noneisyours.marcher.name http://feeds.feedburner.com/NoneIsYours You are not free to read this message, by doing so, you have violated my licence and are required to urinate publicly. Thank you. From martin at marcher.name Sat Jan 12 20:24:51 2008 From: martin at marcher.name (Martin Marcher) Date: Sat, 12 Jan 2008 20:24:51 +0100 Subject: [coreboot] 2 Terabyte Limit of BIOS/MBR References: <20080111024723.GB25714@kirkkit.kollasch.net> Message-ID: On Friday 11 January 2008 03:47 jakllsch at kollasch.net wrote: >> Is that right that the problem is the BIOS? > > Or at least a problem with the Areca BIOS extension. > Could also be the main Tyan BIOS too I suppose. I guess it's not a problem of the Areca controller since it's bios sees the created drive just fine with the correct size. > INT13h Extensions support 64-bit LBAs, so that's not an inherent > problem unless there are limitations of the BIOSes's implementations. >> how I understand the different articles at wikipedia, ms and different >> netsources the BIOS just can't handle disks that are larger than 2TB, in >> turn this renders a MBR unusable. Fine so I convert the disk to a GPT and >> off I should go. But I found that the bios of this board still refuses to >> accept the disk (reported as an scsi device from the controller) and just >> says "No BIOS disk found". > > Well, you're distorting some things there. The BIOS itself > just provides functions for disk access, and by itself, is > incapable of understanding partition tables. That was badly stated, see my other posts. Booting from a grub disk still won't work (grub doesn't see any disk) as soon as i boot from an external usb drive all is fine and from the point where linux boots I have full access to the drive. Seeing all available, partitioned and unpartitioned disk space. > Also, the limitations of 32-bit Windows? are totally irrelevant. :) no windows here, debian/etch x86_64, being totally new to this i just found that a few pages at MS explained basics actually quite good. /martin -- http://noneisyours.marcher.name http://feeds.feedburner.com/NoneIsYours You are not free to read this message, by doing so, you have violated my licence and are required to urinate publicly. Thank you. From rminnich at gmail.com Sat Jan 12 22:38:23 2008 From: rminnich at gmail.com (ron minnich) Date: Sat, 12 Jan 2008 13:38:23 -0800 Subject: [coreboot] [LinuxBIOS] [PATCH] Drop microcode references from Via CPUs In-Reply-To: <47883DEF.7080707@slightlyhackish.com> References: <47883DEF.7080707@slightlyhackish.com> Message-ID: <13426df10801121338w4f3d30c8u1ab4fdca2de8302f@mail.gmail.com> On Jan 11, 2008 8:11 PM, Corey Osgood wrote: > Via C3 datasheets don't make any mention of microcode updates, and the > C7 bios programmer's guide explicitly states they're not necessary, and > leaves it at that. Even if they are possible and exist, we don't have > any info on it, nor any updates, so drop these unneeded references. > > Signed-off-by: Corey Osgood This cleanup is really wonderful. Acked-by: Ronald G. Minnich From r.marek at assembler.cz Sat Jan 12 22:39:13 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Sat, 12 Jan 2008 22:39:13 +0100 Subject: [coreboot] [LinuxBIOS] Messing with CAR in a big way / S3 considerations In-Reply-To: <13426df10801120952p4ce34396xd4f8fe57437d8543@mail.gmail.com> References: <4788062A.5060900@gmx.net> <47880762.4000003@assembler.cz> <47880AD5.70709@gmx.net> <47889A5B.8040604@assembler.cz> <13426df10801120952p4ce34396xd4f8fe57437d8543@mail.gmail.com> Message-ID: <47893381.7090509@assembler.cz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ron minnich wrote: > Rudolf, many payloads start at 1 MB. I don't think we want to use CAR > at that low address. Maybe if you want to have CAR address = RAM address (to copy it to itself) Just please choose TOPK - CAR_SIZE as it is now. > What is the reason that we can't put all coreboot > variables below 1MB? Yes we can, but some parts are very messy including but not limited to: 1) stack segment for AP cpus, very ugly define, hardwired to 1MB when using _RAMBASE lower then 1MB 2) Memory is cleared from zero to TOPK, which is bad. > Just trying to understand s3 :-) Before suspend phase: Coreboot boots payload, it boots OS. Suspend phase: Linux will put to a ACPI table a waking vector address, and uses the value from DSDT to write to SB value to activate the S3 sleep. Resume phase: Coreboot runs as from coldboot except of taking memory from self-refresh mode. No payload is to be loaded, only it is jumped back to OS. What it needs: It just needs not to mess with memory too much. We can reserve a region for Coreboot say at 1MB-2MB (plus usual reserved regions like 0-4K and 960K-1MB) I dont want to take all low memory because the entry point is in real mode and the OS must have some memory bellow 1MB free. We can put _RAMBASE at 8MB and reserve region from 8MB-9MB but no other memory that is reserved should not be touched because it contains OS data ;) (so no memory test for example ;) There are parts of Coreboot which are messing too much with memory, like I described in previous mails and this must be fixed. Easiest way how to avoid non-std solutions and get instantly more memory is to escape to up 1MB of memory or to any better place ;) I dont think it is wise to have for LB only 0 - 640KB of RAM with lot of exceptions, lets use one continuous block in "higher" RAM. ACPI says, reserved blocks can start at 8MB. Problematic parts: Secondary.S - (the trampoline for AP CPUs) lapic_cpu_init.c - (it copies the Secondary.S to undefined place in low memory, and AP cpu stack is handled badly when _RAMBASE is bellow 1MB) wakeup.c (yeah mine implentation which jumps back to real mode, this must be fixed, so no data at our reserved region of 0-4KB gets overwritten) clear_init_ram.c (in AMD CAR) it just clears a lot of memory from ZERO instead of _RAMBASE to TOPK Used CAR "memory/cache" should not be a problem, because it is not written back to memory in any way. So to sum it up. If we would isolate Coreboot writes to memory to those regions: 0-4K 960K-1M _RAMBASE - TOPK (RAMBASE > 1MB) It would be nice, and just _RAMBASE - TOPK region could be reserved in memory map, because it uses Coreboot when starting after resume. This memory region could be claimed back to OS via ACPI memory hotplug, which I'm now investigating. Reserving permanently 1MB of memory when using S3 would be also possible because Asus BIOS takes 1MB at the end of memory for SMM and suspend too. I hope it is now clear how it works ;) I just avoided in my experiments all those stuff because I told linux to use 2MB-1024MB :) (my TOPK is 2048) But now I really would like to get this solved too, because suspend to RAM now works which is great leap because with proprietary BIOS I was unable to get it working :))) Rudolf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHiTOA3J9wPJqZRNURAtDaAKC6rsRnILoF+00I25gP2PywsqbXewCfaWqF GewY+xYUH0Q2rWtVIOYP1/k= =DIfc -----END PGP SIGNATURE----- From svn at openbios.org Sat Jan 12 22:44:57 2008 From: svn at openbios.org (svn at openbios.org) Date: Sat, 12 Jan 2008 22:44:57 +0100 Subject: [coreboot] r3048 - trunk/LinuxBIOSv2/src/cpu/via/model_centaur Message-ID: Author: cozzie Date: 2008-01-12 22:44:57 +0100 (Sat, 12 Jan 2008) New Revision: 3048 Modified: trunk/LinuxBIOSv2/src/cpu/via/model_centaur/Config.lb trunk/LinuxBIOSv2/src/cpu/via/model_centaur/model_centaur_init.c Log: Via C3 datasheets don't make any mention of microcode updates, and the C7 bios programmer's guide explicitly states they're not necessary, and leaves it at that. Even if they are possible and exist, we don't have any info on it, nor any updates, so drop these unneeded references. Signed-off-by: Corey Osgood Acked-by: Ronald G. Minnich Modified: trunk/LinuxBIOSv2/src/cpu/via/model_centaur/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/cpu/via/model_centaur/Config.lb 2008-01-11 22:37:27 UTC (rev 3047) +++ trunk/LinuxBIOSv2/src/cpu/via/model_centaur/Config.lb 2008-01-12 21:44:57 UTC (rev 3048) @@ -5,5 +5,4 @@ dir /cpu/x86/sse dir /cpu/x86/lapic dir /cpu/x86/cache -dir /cpu/intel/microcode driver model_centaur_init.o Modified: trunk/LinuxBIOSv2/src/cpu/via/model_centaur/model_centaur_init.c =================================================================== --- trunk/LinuxBIOSv2/src/cpu/via/model_centaur/model_centaur_init.c 2008-01-11 22:37:27 UTC (rev 3047) +++ trunk/LinuxBIOSv2/src/cpu/via/model_centaur/model_centaur_init.c 2008-01-12 21:44:57 UTC (rev 3048) @@ -7,7 +7,6 @@ #include #include #include -#include #include #include From corey.osgood at gmail.com Sat Jan 12 22:54:08 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Sat, 12 Jan 2008 16:54:08 -0500 Subject: [coreboot] [LinuxBIOS] [PATCH] Drop microcode references from Via CPUs In-Reply-To: <13426df10801121338w4f3d30c8u1ab4fdca2de8302f@mail.gmail.com> References: <47883DEF.7080707@slightlyhackish.com> <13426df10801121338w4f3d30c8u1ab4fdca2de8302f@mail.gmail.com> Message-ID: <47893700.1080101@gmail.com> ron minnich wrote: > On Jan 11, 2008 8:11 PM, Corey Osgood wrote: > >> Via C3 datasheets don't make any mention of microcode updates, and the >> C7 bios programmer's guide explicitly states they're not necessary, and >> leaves it at that. Even if they are possible and exist, we don't have >> any info on it, nor any updates, so drop these unneeded references. >> >> Signed-off-by: Corey Osgood >> > > This cleanup is really wonderful. > > Acked-by: Ronald G. Minnich > r3048, thanks From c-d.hailfinger.devel.2006 at gmx.net Sat Jan 12 23:21:16 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 12 Jan 2008 23:21:16 +0100 Subject: [coreboot] [LinuxBIOS] Messing with CAR in a big way / S3 considerations In-Reply-To: <47893381.7090509@assembler.cz> References: <4788062A.5060900@gmx.net> <47880762.4000003@assembler.cz> <47880AD5.70709@gmx.net> <47889A5B.8040604@assembler.cz> <13426df10801120952p4ce34396xd4f8fe57437d8543@mail.gmail.com> <47893381.7090509@assembler.cz> Message-ID: <47893D5C.6030908@gmx.net> On 12.01.2008 22:39, Rudolf Marek wrote: > ron minnich wrote: > > Rudolf, many payloads start at 1 MB. I don't think we want to use CAR > > at that low address. > > Maybe if you want to have CAR address = RAM address (to copy it to itself) > Just please choose TOPK - CAR_SIZE as it is now. Well, CAR has to be below 1 MB (processor limitation). We can make sure it will not clobber more than 64 kB in that area. Because of conflicts with legacy ROM decoded areas, CAR has to stay below 896 kB. Conflicts with areas decoded by devices are pretty likely in the 640 kB - 1024 kB range. > > What is the reason that we can't put all coreboot > > variables below 1MB? > > Yes we can, but some parts are very messy including but not limited to: > > 1) stack segment for AP cpus, very ugly define, hardwired to 1MB when > using > _RAMBASE lower then 1MB > > 2) Memory is cleared from zero to TOPK, which is bad. But the two points above are pure code issues and can be fixed, right? > > Just trying to understand s3 :-) > > Before suspend phase: > Coreboot boots payload, it boots OS. > > Suspend phase: > Linux will put to a ACPI table a waking vector address, and uses the > value from > DSDT to write to SB value to activate the S3 sleep. > > Resume phase: Coreboot runs as from coldboot except of taking memory from > self-refresh mode. No payload is to be loaded, only it is jumped back > to OS. > > What it needs: > > It just needs not to mess with memory too much. We can reserve a > region for > Coreboot say at 1MB-2MB (plus usual reserved regions like 0-4K and > 960K-1MB) See my list of constraints above. > I dont want to take all low memory because the entry point is in real > mode and > the OS must have some memory bellow 1MB free. An area with 64 kB size somewhere below 1 MB should cover variable storage. We might have to mess with the 0-4 kB area as well. > There are parts of Coreboot which are messing too much with memory, like I > described in previous mails and this must be fixed. Easiest way how to > avoid > non-std solutions and get instantly more memory is to escape to up 1MB > of memory > or to any better place ;) I dont think it is wise to have for LB only > 0 - 640KB > of RAM with lot of exceptions, lets use one continuous block in > "higher" RAM. > ACPI says, reserved blocks can start at 8MB. > > Problematic parts: > > Secondary.S - (the trampoline for AP CPUs) > > lapic_cpu_init.c - (it copies the Secondary.S to undefined place in > low memory, > and AP cpu stack is handled badly when _RAMBASE is bellow 1MB) > > wakeup.c (yeah mine implentation which jumps back to real mode, this > must be > fixed, so no data at our reserved region of 0-4KB gets overwritten) > > clear_init_ram.c (in AMD CAR) > it just clears a lot of memory from ZERO instead of _RAMBASE to TOPK > > Used CAR "memory/cache" should not be a problem, because it is not > written back > to memory in any way. > > So to sum it up. If we would isolate Coreboot writes to memory to > those regions: > > 0-4K > > 960K-1M > > _RAMBASE - TOPK (RAMBASE > 1MB) > > It would be nice, and just _RAMBASE - TOPK region could be reserved in > memory > map, because it uses Coreboot when starting after resume. This memory > region > could be claimed back to OS via ACPI memory hotplug, which I'm now > investigating. Reserving permanently 1MB of memory when using S3 would > be also > possible because Asus BIOS takes 1MB at the end of memory for SMM and > suspend too. Well, during CAR our stack has to be below 1 MB. Moving the stack during execution is something we do now for K8, but I'd like to get rid of that completely so we never introduce such stuff to v3. Note: Geode LX in v3 does not move the stack. > I hope it is now clear how it works ;) I just avoided in my > experiments all > those stuff because I told linux to use 2MB-1024MB :) (my TOPK is 2048) Nice trick. > But now I really would like to get this solved too, because suspend to > RAM now > works which is great leap because with proprietary BIOS I was unable > to get it > working :))) Congratulations! Regards, Carl-Daniel From svn at openbios.org Sat Jan 12 23:29:17 2008 From: svn at openbios.org (svn at openbios.org) Date: Sat, 12 Jan 2008 23:29:17 +0100 Subject: [coreboot] r3049 - trunk/LinuxBIOSv2/src/mainboard/asus/a8v-e_se Message-ID: Author: ruik Date: 2008-01-12 23:29:17 +0100 (Sat, 12 Jan 2008) New Revision: 3049 Modified: trunk/LinuxBIOSv2/src/mainboard/asus/a8v-e_se/cache_as_ram_auto.c Log: Fix the documentation of GPIO setup, tell W83627EHF to use external suspend clock (undocumented in datasheet, documented in 'W83627HG-AW'). Introduce sio_init function for all this. Signed-off-by: Rudolf Marek Acked-by: Ronald G. Minnich Modified: trunk/LinuxBIOSv2/src/mainboard/asus/a8v-e_se/cache_as_ram_auto.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/asus/a8v-e_se/cache_as_ram_auto.c 2008-01-12 21:44:57 UTC (rev 3048) +++ trunk/LinuxBIOSv2/src/mainboard/asus/a8v-e_se/cache_as_ram_auto.c 2008-01-12 22:29:17 UTC (rev 3049) @@ -79,6 +79,7 @@ #define SERIAL_DEV PNP_DEV(0x2e, W83627EHG_SP1) #define GPIO_DEV PNP_DEV(0x2e, W83627EHG_GPIO_SUSLED) +#define ACPI_DEV PNP_DEV(0x2e, W83627EHG_ACPI) #define RTC_DEV PNP_DEV(0x2e, W83627EHG_RTC) static void memreset_setup(void) @@ -153,13 +154,8 @@ return (dev >> 15) & 0x1f; } -#if USE_FALLBACK_IMAGE == 1 -void failover_process(unsigned long bist, unsigned long cpu_init_detectedx) -{ -// unsigned last_boot_normal_x = last_boot_normal(); -//FIXME - unsigned last_boot_normal_x = 1; +void sio_init(void) { u8 reg; pnp_enter_ext_func_mode(SERIAL_DEV); @@ -174,18 +170,40 @@ pnp_exit_ext_func_mode(SERIAL_DEV); + pnp_enter_ext_func_mode(ACPI_DEV); + pnp_set_logical_device(ACPI_DEV); + reg = pnp_read_config(ACPI_DEV, 0xe6); + /* Set the delay rising time from PWROK_LP to PWROK_ST to 300 - 600ms, and 0 to vice versa */ + pnp_write_config(ACPI_DEV, 0xe6, (reg & 0xf0)); + /* 1 Use external suspend clock source 32.768KHz. Undocumented?? */ + reg = pnp_read_config(ACPI_DEV, 0xe4); + pnp_write_config(ACPI_DEV, 0xe4, (reg | 0x10)); + pnp_exit_ext_func_mode(ACPI_DEV); + pnp_enter_ext_func_mode(GPIO_DEV); pnp_set_logical_device(GPIO_DEV); - pnp_write_config(GPIO_DEV, 0xe0, 0xde); // 1101110 0=output 1=input - pnp_write_config(GPIO_DEV, 0xe1, 0x1); //set output val - pnp_write_config(GPIO_DEV, 0xe2, 0x0); //no inversion - pnp_write_config(GPIO_DEV, 0xe3, 0x3); //0000 0011 0=output 1=input - pnp_write_config(GPIO_DEV, 0xe4, 0xa4); //set output val - pnp_write_config(GPIO_DEV, 0xe5, 0x0); //no inversion - pnp_write_config(GPIO_DEV, 0x30, 0x9); //Enable GPIO 2 & GPIO 5 pnp_exit_ext_func_mode(GPIO_DEV); + /* set memory voltage to 2.75V, vcore offset + 100mV, 1.5V Chipset voltage */ + pnp_write_config(GPIO_DEV, 0xe0, 0xde); /* 1101110 0=output 1=input */ + pnp_write_config(GPIO_DEV, 0xe1, 0x1); /* set output val */ + pnp_write_config(GPIO_DEV, 0xe2, 0x0); /* no inversion */ + pnp_write_config(GPIO_DEV, 0xe3, 0x3); /* 0000 0011 0=output 1=input */ + pnp_write_config(GPIO_DEV, 0xe4, 0xa4); /* set output val 1010 0100 */ + pnp_write_config(GPIO_DEV, 0xe5, 0x0); /* no inversion */ + pnp_write_config(GPIO_DEV, 0x30, 0x9); /* Enable GPIO 2 & GPIO 5 */ + pnp_exit_ext_func_mode(GPIO_DEV); +} +#if USE_FALLBACK_IMAGE == 1 + +void failover_process(unsigned long bist, unsigned long cpu_init_detectedx) +{ +// unsigned last_boot_normal_x = last_boot_normal(); +//FIXME + unsigned last_boot_normal_x = 1; + + sio_init(); w83627ehg_enable_serial(SERIAL_DEV, TTYS0_BASE); uart_init(); console_init(); @@ -258,34 +276,8 @@ (DCACHE_RAM_BASE + DCACHE_RAM_SIZE - DCACHE_RAM_GLOBAL_VAR_SIZE); char *p; - u8 reg; - pnp_enter_ext_func_mode(SERIAL_DEV); - reg = pnp_read_config(SERIAL_DEV, 0x24); - pnp_write_config(SERIAL_DEV, 0x24, (reg & ~0x40)); /* we have 24MHz input */ - - reg = pnp_read_config(SERIAL_DEV, 0x2A); - pnp_write_config(SERIAL_DEV, 0x2A, (reg | 1)); /* we have GPIO for KB/MS PIN */ - - reg = pnp_read_config(SERIAL_DEV, 0x2C); - pnp_write_config(SERIAL_DEV, 0x2C, (reg | 0xf0)); /* we have all RESTOUT and even some reserved bits too */ - - pnp_exit_ext_func_mode(SERIAL_DEV); - - pnp_enter_ext_func_mode(GPIO_DEV); - pnp_set_logical_device(GPIO_DEV); - pnp_write_config(GPIO_DEV, 0xe0, 0xde); // 1101110 0=output 1=input - pnp_write_config(GPIO_DEV, 0xe1, 0x1); //set output val - pnp_write_config(GPIO_DEV, 0xe2, 0x0); //no inversion - pnp_write_config(GPIO_DEV, 0xe3, 0x3); //0000 0011 0=output 1=input - pnp_write_config(GPIO_DEV, 0xe4, 0xa4); //set output val - //0x10 seems to control something with SGD VIA - - pnp_write_config(GPIO_DEV, 0xe5, 0x0); //no inversion - pnp_write_config(GPIO_DEV, 0x30, 0x9); //Enable GPIO 2 & GPIO 5 - pnp_exit_ext_func_mode(GPIO_DEV); - - + sio_init(); w83627ehg_enable_serial(SERIAL_DEV, TTYS0_BASE); uart_init(); console_init(); From info at coresystems.de Sat Jan 12 23:31:25 2008 From: info at coresystems.de (LinuxBIOS information) Date: Sat, 12 Jan 2008 23:31:25 +0100 Subject: [coreboot] r3048 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "cozzie" checked in revision 3048 to the LinuxBIOS source repository and caused the following changes: Change Log: Via C3 datasheets don't make any mention of microcode updates, and the C7 bios programmer's guide explicitly states they're not necessary, and leaves it at that. Even if they are possible and exist, we don't have any info on it, nor any updates, so drop these unneeded references. Signed-off-by: Corey Osgood Acked-by: Ronald G. Minnich Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3048&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in cozzie's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From bishop.robinson at gmail.com Sat Jan 12 23:46:38 2008 From: bishop.robinson at gmail.com (Robinson Tryon) Date: Sat, 12 Jan 2008 17:46:38 -0500 Subject: [coreboot] [LinuxBIOS] adding "--list-supported" feature to superiotool #91 In-Reply-To: <20080112172049.9116.qmail@stuge.se> References: <20080112172049.9116.qmail@stuge.se> Message-ID: On Jan 12, 2008 12:20 PM, Peter Stuge wrote: > Thanks for the patch! Some comments. > > On Sat, Jan 12, 2008 at 06:09:21AM -0500, Robinson Tryon wrote: > > I wasn't very sure about what the "wiki links" part of this feature > > entailed. I included the primary url for superiotool, but perhaps > > there's something more that needs to be done? > > I think there's a page for each supported sio chip with the output > from previous superiotool runs. Or there should be. Would be handy > to have that address available as well. On the wiki page it looked like there were links to several mailing list posts -- those emails probably contained the dumps for each chip. Should that information be included in the data section of each vendor file? If so, should there be a new field in the superio_registers STRUCT to handle that? > > Oh, and how should I go about getting an account on Trac? > > Stefan should get you hooked up. :) Great! (hopefully he's reading this thread...) > > > > +void print_fintek_chips(void) { > > + char name [] = "Fintek"; > > + print_vendor_chips(name, reg_table); > > +} > > Why the extra char[]? The function parameter is const so the name > could just be a string constant in the call. Good point. (I haven't been programming in C for quite some time...) > > And thinking further I saw that the vendor name is given as a string > constant in more places in the files. Perhaps make it a #define near > the top of the file? That's a separate patch though, and just a > thought. Yes, I noticed that as well (as well as a couple of other things that could stand to be refactored). But as you pointed out, one thing at a time. > > > > +void print_vendor_chips(const char *vendor, > > + const struct superio_registers reg_table[]) { > > + int i, any_supported_chips = 0; > > + > > + printf(" Chips from %s:\n", vendor); > > + > > + for (i = 0; /* Nothing */; i++) { > > + if (reg_table[i].superio_id == EOT) > > + break; > > So why not write the break condition in the for statement? I was just borrowing code? :-) But yes, that's a good point. Actually, here's another question for you: Why is all of the data for superiotool stored in arrays terminated with EOT? Can't we just use ARRAY_SIZE (or some similar construct) to figure out the length of a given array before we iterate over it? > > > + any_supported_chips = 1; > > + print_chip(reg_table[i]); > > + } > > + > > + if (!any_supported_chips) > > + printf(" None.\n"); > > any_supported_chips could just check if 0==i, right? yep. > Also - isn't the vendor inclued in the reg_table? Why is it needed at > all in this function? Sorry if I'm being slow. I don't believe that the vendor name is included in the reg_table -- just the chip id, chip name, and registers, right? Here's the updated patch. Let me know how the dump URLs should be stored, and I'll add support for that as well. Signed-off-by: Robinson P. Tryon --R -------------- next part -------------- A non-text attachment was scrubbed... Name: superiotool-list-supported2.patch Type: text/x-patch Size: 8200 bytes Desc: not available URL: From r.marek at assembler.cz Sat Jan 12 23:57:29 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Sat, 12 Jan 2008 23:57:29 +0100 Subject: [coreboot] [LinuxBIOS] Messing with CAR in a big way / S3 considerations In-Reply-To: <47893D5C.6030908@gmx.net> References: <4788062A.5060900@gmx.net> <47880762.4000003@assembler.cz> <47880AD5.70709@gmx.net> <47889A5B.8040604@assembler.cz> <13426df10801120952p4ce34396xd4f8fe57437d8543@mail.gmail.com> <47893381.7090509@assembler.cz> <47893D5C.6030908@gmx.net> Message-ID: <478945D9.1030103@assembler.cz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, > Well, CAR has to be below 1 MB (processor limitation). We can make sure > it will not clobber more than 64 kB in that area. Because of conflicts > with legacy ROM decoded areas, CAR has to stay below 896 kB. Conflicts > with areas decoded by devices are pretty likely in the 640 kB - 1024 kB > range. Hum OK, so lets use 0-64KB? > >>> What is the reason that we can't put all coreboot >>> variables below 1MB? >> Yes we can, but some parts are very messy including but not limited to: >> >> 1) stack segment for AP cpus, very ugly define, hardwired to 1MB when >> using >> _RAMBASE lower then 1MB >> >> 2) Memory is cleared from zero to TOPK, which is bad. > > But the two points above are pure code issues and can be fixed, right? Yes it could of course. IMHO there is no much space left for everything bellow 1MB so I think there is a hack with the 1MB above usage for the stack. > > An area with 64 kB size somewhere below 1 MB should cover variable > storage. We might have to mess with the 0-4 kB area as well. I think this is fine, why not, because the LB table is there written once Coreboot is nearly done anyway. Lets put there secondary.S trampoline and back to real mode switcher too. > Well, during CAR our stack has to be below 1 MB. Moving the stack during > execution is something we do now for K8, but I'd like to get rid of that > completely so we never introduce such stuff to v3. Note: Geode LX in v3 > does not move the stack. Ok when it is possible to remap the stack to same location (as opposed to what the Opteron BKDG says) Up to 0xe AMD family it says that cache must be invalidated with INVD and writeback is not possible with CLFLUSH or WBINVB. Maybe Manual writeback is then. 0xf AMD family allows only 48KB, 256 tags must be reserved. It says nothing about "unable to copy it on itself". Only that cache invalidate must be done after DRAM works. And new guide revision also says: Temporarily disable cache fill probes on the BSP by programming DisFillP = 1 (Function 0, offset 68h). Then read 64K and enable the DisFillP = 0. It does not tell if data can be written back with WINVD, CLFLUSH just to avoid that before dram is ready. the 0x10 fam BKDG says even more, also just 48KB, read all with rep MOV, there are additional constrains like not to push more then a double word with first push. It also says that writeback to main memory is possible with CLFLUSH or WBINVD invd. It also recommends not to use exceptions, interrupts, no MMX, 3Dow etc Except of: MOVD, MOVQ, MOVDQA, MOVQ2DQ, MOVDQ2Q. Maybe manual writeback will work here too. > Congratulations! Thanks, yep, its cool ;) Rudolf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHiUXY3J9wPJqZRNURAok9AJ93Gi7OywIVfAv1A2f+WI5C6BukCwCfc9Le 9ktjrwY4ZUYkoJZxnUepbvE= =/CVa -----END PGP SIGNATURE----- From info at coresystems.de Sun Jan 13 00:26:19 2008 From: info at coresystems.de (LinuxBIOS information) Date: Sun, 13 Jan 2008 00:26:19 +0100 Subject: [coreboot] r3049 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "ruik" checked in revision 3049 to the LinuxBIOS source repository and caused the following changes: Change Log: Fix the documentation of GPIO setup, tell W83627EHF to use external suspend clock (undocumented in datasheet, documented in 'W83627HG-AW'). Introduce sio_init function for all this. Signed-off-by: Rudolf Marek Acked-by: Ronald G. Minnich Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=3049&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in ruik's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From c-d.hailfinger.devel.2006 at gmx.net Sun Jan 13 00:36:59 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 13 Jan 2008 00:36:59 +0100 Subject: [coreboot] [LinuxBIOS] Messing with CAR in a big way / S3 considerations In-Reply-To: <478945D9.1030103@assembler.cz> References: <4788062A.5060900@gmx.net> <47880762.4000003@assembler.cz> <47880AD5.70709@gmx.net> <47889A5B.8040604@assembler.cz> <13426df10801120952p4ce34396xd4f8fe57437d8543@mail.gmail.com> <47893381.7090509@assembler.cz> <47893D5C.6030908@gmx.net> <478945D9.1030103@assembler.cz> Message-ID: <47894F1B.8060201@gmx.net> On 12.01.2008 23:57, Rudolf Marek wrote: > > Well, CAR has to be below 1 MB (processor limitation). We can make sure > > it will not clobber more than 64 kB in that area. Because of conflicts > > with legacy ROM decoded areas, CAR has to stay below 896 kB. Conflicts > > with areas decoded by devices are pretty likely in the 640 kB - 1024 kB > > range. > > Hum OK, so lets use 0-64KB? That could work for processors which are guaranteed to have more than 64 kB of L2 cache. Basically, you can place the CAR area with 64 kB size granularity and alignment between 0 kB and 512 kB, with 16 kB granularity+alignment between 512 kB and 768 kB, and with 4 kB granularity+alignment between 768 kB and 1024 kB. That is a processor limitation. Now if a processor has 64 kB L2 cache or less, placing CAR between 0 kB and 512 kB is naturally impossible. /"You are in a maze of twisty little passages, all alike." /Of course, CAR is rather fragile and there is no guarantee my rewrites will ever allow us to use the full theoretical potential. > > Well, during CAR our stack has to be below 1 MB. Moving the stack during > > execution is something we do now for K8, but I'd like to get rid of that > > completely so we never introduce such stuff to v3. Note: Geode LX in v3 > > does not move the stack. > > Ok when it is possible to remap the stack to same location (as opposed > to what > the Opteron BKDG says) > > Up to 0xe AMD family it says that cache must be invalidated with INVD and > writeback is not possible with CLFLUSH or WBINVB. Maybe Manual > writeback is then. > > 0xf AMD family allows only 48KB, 256 tags must be reserved. > It says nothing about "unable to copy it on itself". Only that cache > invalidate must be done after DRAM works. Yes. > And new guide revision also says: Temporarily disable cache fill > probes on the > BSP by programming DisFillP = 1 (Function 0, offset 68h). Then read > 64K and > enable the DisFillP = 0. It does not tell if data can be written back with > WINVD, CLFLUSH just to avoid that before dram is ready. Interesting. I must have overlooked that part. > the 0x10 fam BKDG says even more, also just 48KB, read all with rep MOV, > there are additional constrains like not to push more then a double word > with first push. Yes, fragility abounds. > It also says that writeback to main memory is possible with CLFLUSH > or WBINVD > invd. It also recommends not to use exceptions, interrupts, no MMX, > 3Dow etc > Except of: MOVD, MOVQ, MOVDQA, MOVQ2DQ, MOVDQ2Q. > > Maybe manual writeback will work here too. Let's try it. Regards, Carl-Daniel From r.marek at assembler.cz Sun Jan 13 02:55:55 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Sun, 13 Jan 2008 02:55:55 +0100 Subject: [coreboot] [LinuxBIOS] Messing with CAR in a big way / S3 considerations In-Reply-To: <47894F1B.8060201@gmx.net> References: <4788062A.5060900@gmx.net> <47880762.4000003@assembler.cz> <47880AD5.70709@gmx.net> <47889A5B.8040604@assembler.cz> <13426df10801120952p4ce34396xd4f8fe57437d8543@mail.gmail.com> <47893381.7090509@assembler.cz> <47893D5C.6030908@gmx.net> <478945D9.1030103@assembler.cz> <47894F1B.8060201@gmx.net> Message-ID: <47896FAB.70401@assembler.cz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Interesting. I must have overlooked that part. Nope, get new revision http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/32559.pdf 32559 Rev. 3.08 July 2007 Rudolf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHiW+r3J9wPJqZRNURAimWAJ9SVMiKhvG7FB/us2mKWNfk+RZO+ACeKFNh 3ReSodBaBgQvDrK+qxVxlD0= =sNiS -----END PGP SIGNATURE----- From uwe at hermann-uwe.de Sun Jan 13 02:57:05 2008 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 13 Jan 2008 02:57:05 +0100 Subject: [coreboot] [LinuxBIOS] adding "--list-supported" feature to superiotool #91 In-Reply-To: References: <20080112172049.9116.qmail@stuge.se> Message-ID: <20080113015705.GA2210@greenwood> On Sat, Jan 12, 2008 at 05:46:38PM -0500, Robinson Tryon wrote: > On the wiki page it looked like there were links to several mailing > list posts -- those emails probably contained the dumps for each chip. Yes. > Should that information be included in the data section of each vendor > file? If so, should there be a new field in the superio_registers > STRUCT to handle that? Not sure I understand what you mean, but I think the answer is no. _One_ link to http://coreboot.org/Superiotool#Supported_devices is more than enough. I don't think it makes sense to have an extra wiki page for each chip or an extra link for each chip in the --list-supported output, if that's what you mean. > Actually, here's another question for you: > Why is all of the data for superiotool stored in arrays terminated > with EOT? Can't we just use ARRAY_SIZE (or some similar construct) to > figure out the length of a given array before we iterate over it? Not all entries have the same length. Using the EOT method is nice, IMO. > > Also - isn't the vendor inclued in the reg_table? Why is it needed at > > all in this function? Sorry if I'm being slow. > > I don't believe that the vendor name is included in the reg_table -- > just the chip id, chip name, and registers, right? Yep. > Here's the updated patch. Let me know how the dump URLs should be > stored, and I'll add support for that as well. Not needed. One link to http://coreboot.org/Superiotool#Supported_devices at the bottom of the output or so should be enough. > +/* Print information about a specific chip. */ > +void print_chip(const struct superio_registers reg) { > + printf(" %s", reg.name); I'd make this function take a "const char *vendor" as argument and print the vendor in each line, without indentation. I find that format looks more readable (and is probably easier to parse/grep/sed if we ever want that). Example output from a quick test I did: Fintek F71862FG Fintek F71872F/FG / F71806F/FG Fintek F71882FG/F71883FG Fintek F71805F/FG (dump) ITE IT8661F (dump) ITE IT8702F ITE IT8705F/AF / IT8700F (dump) ITE IT8706R ITE IT8708F (dump) ITE IT8710F ITE IT8712F (dump) ITE IT8716F (dump) ITE IT8718F (dump) ITE IT8726F NSC PC97307 (dump) NSC PC87317 (dump) NSC PC97317 (dump) NSC PC87309 (dump) NSC PC87360 (dump) NSC PC87351 (dump) NSC PC87364 NSC PC87365 NSC PC87363 NSC PC87366 (dump) NSC PC8739x NSC PC87591x NSC PC8741x (dump) NSC PC87372 NSC PC8374L (dump) NSC PC87427 NSC PC87373 SMSC FDC37C93xFR SMSC FDC37N971 SMSC FDC37N972 SMSC LPC47N252 [...] > + /* Unless the ldn is empty, assume this chip has a dump. */ > + if(reg.ldn[0].ldn != EOT) > + printf(" (dump)"); "dump available" is probably a bit clearer. > + printf("\n"); > +} > + > +/* Print a list of all supported chips from the given vendor. */ > +void print_vendor_chips(const char *vendor, > + const struct superio_registers reg_table[]) { > + int i; > + > + printf(" Chips from %s:\n", vendor); > + > + for (i = 0; reg_table[i].superio_id != EOT; i++) { > + print_chip(reg_table[i]); > + } > + > + if (i == 0) > + printf(" None.\n"); > +} > + > +/* Print a list of all chips supported by superiotool. */ > +void print_list_of_supported_chips(void) > +{ > + int i; > + > + printf("Supported Super I/O Chips:\n"); > + printf(" Notes:\n"); > + printf(" - See http://linuxbios.org/Superiotool for more information.\n"); > + printf(" - Chips with (dump) after them have support for dumping registers.\n"); > + printf("\n"); I'd drop these (4) lines here (maybe add them in the manpage). Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From peter at stuge.se Sun Jan 13 05:37:13 2008 From: peter at stuge.se (Peter Stuge) Date: Sun, 13 Jan 2008 05:37:13 +0100 Subject: [coreboot] 2 Terabyte Limit of BIOS/MBR In-Reply-To: References: <4786943B.7050600@gmx.net> Message-ID: <20080113043713.14603.qmail@stuge.se> On Sat, Jan 12, 2008 at 08:20:13PM +0100, Martin Marcher wrote: > We are a small company with 2 physical server but given I could > find a setup where I can install and uninstall linuxbios securely > (in case it won't work) I suggest a BIOS savior. Pretty cheap and a great way to switch between flash chips. Make sure you get the RD1-LPC8 which is 8Mbit, ie. 1Mbyte. That may be enough for a LAB (Linux as bootloader) coreboot with your needed drivers, but then it should probably kexec your normal system kernel. //Peter From bishop.robinson at gmail.com Sun Jan 13 12:46:09 2008 From: bishop.robinson at gmail.com (Robinson Tryon) Date: Sun, 13 Jan 2008 06:46:09 -0500 Subject: [coreboot] [LinuxBIOS] adding "--list-supported" feature to superiotool #91 In-Reply-To: <20080113015705.GA2210@greenwood> References: <20080112172049.9116.qmail@stuge.se> <20080113015705.GA2210@greenwood> Message-ID: On Jan 12, 2008 8:57 PM, Uwe Hermann wrote: > ... > > Actually, here's another question for you: > > Why is all of the data for superiotool stored in arrays terminated > > with EOT? Can't we just use ARRAY_SIZE (or some similar construct) to > > figure out the length of a given array before we iterate over it? > > Not all entries have the same length. Using the EOT method is nice, IMO. Okay, cool. Is it common for C programmers to terminate arrays like this? (I haven't written much C code, so I'm just wondering for my own edification... :-) > > Here's a new patch. I believe that I addressed everything that Uwe brought up, including adding an entry in the superiotool manpage. Let me know how it looks. (I noticed that there are a few references to "LinuxBIOS" in the manpage, etc... that need to be changed to "coreboot"; I'll do that in a separate patch) Signed-off-by: Robinson P. Tryon -------------- next part -------------- A non-text attachment was scrubbed... Name: superiotool-list-supported3.patch Type: text/x-patch Size: 9377 bytes Desc: not available URL: From frobozz.lb at gmail.com Sun Jan 13 12:59:51 2008 From: frobozz.lb at gmail.com (Lars Randers) Date: Sun, 13 Jan 2008 12:59:51 +0100 Subject: [coreboot] MTRR question Message-ID: <1464f1250801130359r3b0963d6icc4ac89de50762c4@mail.gmail.com> Why do we use a variable MTRR to map the bios code instead of the fixed ones? I've been trying to integrate a VGA bios alongside the normal and fallback images, but that 2 ^ XIP size requirement is making things very difficult. So far I have only managed to include the VGA bios code blob if I disable the normal image in the config.lb Is there anything preventing me from using the fixed size MTRR descriptors for the bios area instead of a variable one? @Luc - Are you working on getting a VGA textmode console running on the VIA Epia board? I stumbled on your name on the unicrome project, so if anyone could do it, it'd be you :) In any case I'd be very interested in anything along those lines... From mechno at gmail.com Sun Jan 13 12:50:42 2008 From: mechno at gmail.com (Maarten van Eeuwijk) Date: Sun, 13 Jan 2008 12:50:42 +0100 Subject: [coreboot] lspci -tvnn, superiotool -dV, flashrom -V, for the MSI 6119 mainboard. Message-ID: <53613eef0801130350i75bce8e0te278d3f324e27bd@mail.gmail.com> Hi all, A few day's ago I asked Uwe for a little help on my MS6119 board from MSI. He adviced me to post the results of lspci -tvnn, superiotool -dV and flashrom -V to the mailing list, for the sake of archiving. So, after some creative wiring I got a LiveCD going and ran the pieces of software mentioned above. The tests are done with minimal hardware, all the PCI slots were empty. The only slots filled were the CPU slot and the AGP slot. For the ones who think they recognize a Asus p2b here, you're almost dead on. The MS6119 has the same hardware and similair layout but the wiring is likely to be different. Here are the results: *lspci -tvnn:* -[0000:00]-+-00.0 8086:7190 +-01.0-[0000:01]----00.0 1002:4742 +-07.0 8086:7110 +-07.1 8086:7111 +-07.2 8086:7112 \-07.3 8086:7113 *superiotool -dV:* superiotool r3011 Probing for ALi Super I/O at 0x3f0... Failed. Returned data: id=0xffff, rev=0xff Probing for ALi Super I/O at 0x370... Failed. Returned data: id=0xffff, rev=0xff Probing for Fintek Super I/O at 0x2e... Failed. Returned data: vid=0xffff, id=0xffff Probing for Fintek Super I/O at 0x4e... Failed. Returned data: vid=0xffff, id=0xffff Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x2e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x2e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for NSC Super I/O at 0x2e... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x4e... Failed. Returned data: port=0xff, port+1=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x2e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x4e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x4e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x162e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x162e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x164e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x164e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x3f0... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x3f0... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x370... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x370... Failed. Returned data: id=0xff, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0... Found Winbond W83977TF (id=0x97, rev=0x73) at 0x3f0 Register dump: idx 20 21 22 23 24 25 26 28 2a 2b 2c 2d 2e 2f val 97 73 ff fe 84 00 00 00 00 00 00 00 00 ff def 97 73 ff fe MM 00 MM 00 00 00 00 RR RR RR LDN 0x00 (Floppy) idx 30 60 61 70 74 f0 f1 f2 f4 f5 val 01 03 f0 06 02 0e 00 ff 00 00 def 01 03 f0 06 02 0e 00 ff 00 00 LDN 0x01 (Parallel port) idx 30 60 61 70 74 f0 val 01 03 78 07 03 00 def 01 03 78 07 04 3f LDN 0x02 (COM1) idx 30 60 61 70 f0 val 01 03 f8 04 00 def 01 03 f8 04 00 LDN 0x03 (COM2) idx 30 60 61 70 f0 f1 val 01 02 f8 03 00 00 def 01 02 f8 03 00 00 LDN 0x05 (Keyboard / mouse) idx 30 60 61 62 63 70 72 f0 val 01 00 60 00 64 01 00 42 def 01 00 60 00 64 01 0c 83 LDN 0x07 (GPIO 1) idx 30 60 61 62 63 64 65 70 72 e0 e1 e2 e3 e4 e5 e6 e7 f1 val 00 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 01 00 def 00 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 01 00 LDN 0x08 (GPIO 2) idx 30 60 61 70 72 e8 e9 ea eb ec ed ee f0 f1 f2 f3 f4 val 01 00 00 00 00 10 01 01 01 01 08 01 00 ff 00 00 00 def 00 00 00 00 00 01 01 01 01 01 01 01 00 RR 00 00 00 LDN 0x09 (GPIO 3) idx 30 60 61 62 63 64 65 70 72 e0 e1 e2 e3 e4 e5 e6 e7 f1 val 00 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 01 00 def 00 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 01 00 LDN 0x0a (ACPI) idx 30 60 61 62 63 64 65 70 e0 e1 02 e3 e4 f0 f1 f2 f3 f4 f5 f6 f7 fe ff val 00 00 00 00 00 00 00 00 00 00 ff 07 00 00 00 0f 07 00 00 00 00 00 00 def 00 00 00 00 00 00 00 00 00 00 NA MM RR 00 00 00 00 00 00 00 00 RR RR Probing for Winbond Super I/O (init=0x88) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff *flashrom -V:* Calibrating delay loop... 100M loops per second. OK. No LinuxBIOS table found. Found chipset "PIIX4/PIIX4E/PIIX4M", enabling flash write... OK. Probing for Am29F040B, 512 KB probe_29f040b: id1 0x7f, id2 0x3f Probing for Am29LV040B, 512 KB probe_29f040b: id1 0x7f, id2 0x3f Probing for Am29F016D, 2048 KB probe_29f040b: id1 0xff, id2 0xff Probing for AE49F2008, 256 KB probe_jedec: id1 0xda, id2 0x45 Probing for At29C040A, 512 KB probe_jedec: id1 0xda, id2 0x45 Probing for At29C020, 256 KB probe_jedec: id1 0xda, id2 0x45 Probing for At49F002(N), 256 KB probe_jedec: id1 0xda, id2 0x45 Probing for At49F002(N)T, 256 KB probe_jedec: id1 0xda, id2 0x45 Probing for EN29F002(A)(N)T, 256 KB probe_jedec: id1 0xda, id2 0x45 Probing for EN29F002(A)(N)B, 256 KB probe_jedec: id1 0xda, id2 0x45 Probing for MBM29F400TC, 512 KB probe_m29f400bt: id1 0x7f, id2 0x3f Probing for MX29F002, 256 KB probe_29f002: id1 0xda, id2 0x45 Probing for MX25L4005, 512 KB generic_spi_command called, but no SPI chipset detected Probing for MX25L8005, 1024 KB generic_spi_command called, but no SPI chipset detected Probing for SST25VF040B, 512 KB generic_spi_command called, but no SPI chipset detected Probing for SST25VF016B, 2048 KB generic_spi_command called, but no SPI chipset detected Probing for SST29EE020A, 256 KB probe_jedec: id1 0xda, id2 0x45 Probing for SST28SF040A, 512 KB probe_28sf040: id1 0x7f, id2 0x3f Probing for SST39SF010A, 128 KB probe_jedec: id1 0xda, id2 0x45 Probing for SST39SF020A, 256 KB probe_jedec: id1 0xda, id2 0x45 Probing for SST39SF040, 512 KB probe_jedec: id1 0xda, id2 0x45 Probing for SST39VF020, 256 KB probe_jedec: id1 0xda, id2 0x45 Probing for SST49LF040B, 512 KB probe_jedec: id1 0xda, id2 0x45 Probing for SST49LF040, 512 KB probe_jedec: id1 0xda, id2 0x45 Probing for SST49LF020A, 256 KB probe_jedec: id1 0xda, id2 0x45 Probing for SST49LF080A, 1024 KB probe_jedec: id1 0xda, id2 0x45 Probing for SST49LF002A/B, 256 KB probe_jedec: id1 0xda, id2 0x45 Probing for SST49LF003A/B, 384 KB probe_jedec: id1 0xda, id2 0x45 Probing for SST49LF004A/B, 512 KB probe_jedec: id1 0xda, id2 0x45 Probing for SST49LF008A, 1024 KB probe_jedec: id1 0xda, id2 0x45 Probing for SST49LF004C, 512 KB probe_49lfxxxc: id1 0x7f, id2 0x3f Probing for SST49LF008C, 1024 KB probe_49lfxxxc: id1 0x7f, id2 0x3f Probing for SST49LF016C, 2048 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST49LF160C, 2048 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for Pm49FL002, 256 KB probe_jedec: id1 0xda, id2 0x45 Probing for Pm49FL004, 512 KB probe_jedec: id1 0xda, id2 0x45 Probing for W29C011, 128 KB probe_jedec: id1 0xda, id2 0x45 Probing for W29C040P, 512 KB probe_jedec: id1 0xda, id2 0x45 Probing for W29C020C, 256 KB probe_jedec: id1 0xda, id2 0x45 W29C020C found at physical address 0xfffc0000. Flash part is W29C020C (256 KB). No operations were specified. That's it. Uwe told me he could help me with hacking up a MS6119 target file with this info. Once the bios works, I 'll use it to make a router of that board utilizing coreboot, m0n0wall, a few ethernet NIC's and a Compact flash card. Once that works I will demonstrate it at school. Perhaps I 'll put it against a Cisco router in a VS showdown on troughput. Might be cool to beat a 800+ bucks Cisco machine with an old piece of hardware I found in a trashbox. tnx for your time, Maarten "merethan" -------------- next part -------------- An HTML attachment was scrubbed... URL: From hansolofalcon at worldnet.att.net Sun Jan 13 17:49:02 2008 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Sun, 13 Jan 2008 11:49:02 -0500 Subject: [coreboot] [LinuxBIOS] Welcome to coreboot. In-Reply-To: <20080112170743.GA29072@coresystems.de> Message-ID: <003801c85604$34f812b0$6401a8c0@who8> Hello! The download pages reflect the new name. But what about for those of us who have preexisting repositories checked out via SVN? I just ran an update and SVN found everything without any issues. Ideally we need to have a page up that reflects that. But anyway everything looks good. -- Gregg C Levine hansolofalcon at worldnet.att.net "The Force will be with you always." Obi-Wan Kenobi ? > -----Original Message----- > From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On > Behalf Of Stefan Reinauer > Sent: Saturday, January 12, 2008 12:08 PM > To: LinuxBIOS > Subject: Re: [coreboot] [LinuxBIOS] Welcome to coreboot. > > * ron minnich [080112 02:43]: > > We will make the changes slowly and with a lot of preparation. You > > have already seen the IRC channel change, and host names change over > > to coreboot.org. At some point in the next three months you will see a > > change in the svn repository name. We're going to be very careful to > > ensure nothing breaks. > > I switched the mailing list over to the new name. The list archive was > moved too. > > Please send mails to coreboot at coreboot.org in future. The web frontend > is now available at http://www.coreboot.org/mailman/listinfo/coreboot > > Mails to linuxbios at linuxbios.org are sent to the new mailing list, too > so the transition should be relatively seamless. > > Please send me an email if any problems occur. > > Best regards, > Stefan > > -- > coresystems GmbH b" Brahmsstr. 16 b" D-79104 Freiburg i. Br. > Tel.: +49 761 7668825 b" Fax: +49 761 7664613 > Email: info at coresystems.de b" http://www.coresystems.de/ > Registergericht: Amtsgericht Freiburg b" HRB 7656 > GeschC$ftsfC > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From jtmettala at gmail.com Sun Jan 13 20:08:17 2008 From: jtmettala at gmail.com (=?UTF-8?Q?Jouni_Mett=C3=A4l=C3=A4?=) Date: Sun, 13 Jan 2008 21:08:17 +0200 Subject: [coreboot] [LinuxBIOS] abit be6 In-Reply-To: <20080112172452.9934.qmail@stuge.se> References: <63e824e50801120415n36ec1197w1342f2c5710bb46e@mail.gmail.com> <20080112172452.9934.qmail@stuge.se> Message-ID: <63e824e50801131108t542e1df6gbb4b594b02733f45@mail.gmail.com> On Jan 12, 2008 7:24 PM, Peter Stuge wrote: > On Sat, Jan 12, 2008 at 02:15:34PM +0200, Jouni Mett?l? wrote: > > LinuxBios booted to filo. Motherboard is abit be6. This is azza/pt-6ibd/ > > config using http://coreboot.org/AZZA_PT-6IBD_Build_Tutorial. filo > > config was also from it. > > Cool! > > FILO doesn't find a hard drive at hda. Do you have one there? > > Either way, it would be nice if you could use memtest as payload and > let it run for a few hours to check that RAM is set up right. > > > //Peter > It now boots with filo. This time with different filo Config file. # means these lines were commented out. #USE_GRUB = 1 MENULST_TIMEOUT = 6 -> = 10 VGA_CONSOLE = 1 -> VGA_CONSOLE = 0 PC_KEYBOARD = 1 -> PC_KEYBOARD = 0 #SUPPORT_PCI = 1 #PCI_BRUTE_SCAN = 1 added DEBUG_ALL = 1 using single 64M chip memtest was ok after 20 minutes. If longer time is needed then I test new version of memtest. Reading supported motherboards azza/pt-6ibd/ works also with 64MB it is marked as WIP. Keyboard isn't working yet. Tested ps/2 keyboard. Using kernel as boot file it boots. I can't log in with keyboard or minicom. This could be something simple I don't now. Writing of boot line works with minicom. Maybe I could add some useful logs with using some startup scripts? Slightly edited minicom log is attached. It might still have something unneccessary lines. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: minicom6.cap Type: application/octet-stream Size: 35126 bytes Desc: not available URL: From saproj at gmail.com Sun Jan 13 23:08:15 2008 From: saproj at gmail.com (Sergei Antonov) Date: Mon, 14 Jan 2008 01:08:15 +0300 Subject: [coreboot] [LinuxBIOS] abit be6 In-Reply-To: <20080112172452.9934.qmail@stuge.se> References: <63e824e50801120415n36ec1197w1342f2c5710bb46e@mail.gmail.com> <20080112172452.9934.qmail@stuge.se> Message-ID: <1dfa6edc0801131408u64211danc17ba8037944c323@mail.gmail.com> On Jan 12, 2008 8:24 PM, Peter Stuge wrote: > On Sat, Jan 12, 2008 at 02:15:34PM +0200, Jouni Mett?l? wrote: > > LinuxBios booted to filo. Motherboard is abit be6. This is azza/pt-6ibd/ > > config using http://coreboot.org/AZZA_PT-6IBD_Build_Tutorial. filo > > config was also from it. > > Cool! > > FILO doesn't find a hard drive at hda. Do you have one there? Sounds familiar. It is fixed by a patch: http://www.coreboot.org/pipermail/coreboot/2007-December/028339.html nobody seemed to pay attention to it. From saproj at gmail.com Sun Jan 13 23:14:21 2008 From: saproj at gmail.com (Sergei Antonov) Date: Mon, 14 Jan 2008 01:14:21 +0300 Subject: [coreboot] [LinuxBIOS] abit be6 In-Reply-To: <63e824e50801131108t542e1df6gbb4b594b02733f45@mail.gmail.com> References: <63e824e50801120415n36ec1197w1342f2c5710bb46e@mail.gmail.com> <20080112172452.9934.qmail@stuge.se> <63e824e50801131108t542e1df6gbb4b594b02733f45@mail.gmail.com> Message-ID: <1dfa6edc0801131414m2054fecdo8993780bac793b75@mail.gmail.com> On Jan 13, 2008 10:08 PM, Jouni Mett?l? wrote: > > > > On Jan 12, 2008 7:24 PM, Peter Stuge wrote: > > > > On Sat, Jan 12, 2008 at 02:15:34PM +0200, Jouni Mett?l? wrote: > > > LinuxBios booted to filo. Motherboard is abit be6. This is azza/pt-6ibd/ > > > config using http://coreboot.org/AZZA_PT-6IBD_Build_Tutorial. filo > > > config was also from it. > > > > Cool! > > > > FILO doesn't find a hard drive at hda. Do you have one there? > > > > Either way, it would be nice if you could use memtest as payload and > > let it run for a few hours to check that RAM is set up right. > > > > > > //Peter > > > > It now boots with filo. This time with different filo Config file. # means > these lines were commented out. > > #USE_GRUB = 1 > MENULST_TIMEOUT = 6 -> = 10 > VGA_CONSOLE = 1 -> VGA_CONSOLE = 0 > PC_KEYBOARD = 1 -> PC_KEYBOARD = 0 > #SUPPORT_PCI = 1 > #PCI_BRUTE_SCAN = 1 > added > DEBUG_ALL = 1 > > using single 64M chip memtest was ok after 20 minutes. If longer time is > needed then I test new version of memtest. Reading supported motherboards > azza/pt-6ibd/ works also with 64MB it is marked as WIP. > > Keyboard isn't working yet. Tested ps/2 keyboard. Using kernel as boot file > it boots. I can't log in with keyboard or minicom. This could be something > simple I don't now. Writing of boot line works with minicom. I can confirm. It has been reported by me a while ago: http://www.coreboot.org/pipermail/coreboot/2007-December/028256.html People on IRC tried to help me, but the problem still remains. Did you use flashrom on this board? It didn't work for me, and I had to use uniflash in dos. From echelon at free.fr Sun Jan 13 23:32:37 2008 From: echelon at free.fr (Florentin Demetrescu) Date: Sun, 13 Jan 2008 23:32:37 +0100 Subject: [coreboot] [LinuxBIOS] m57sli : debugging the flashrom problem when booting with LB In-Reply-To: <2ea3fae10801101542pe17862fsb82bdffa9a41853@mail.gmail.com> References: <47668D76.6060602@gmx.net> <4766DD09.1070400@gmx.net> <1199963686.4785fe264a52d@imp.free.fr> <478612C1.7090504@gmx.net> <2ea3fae10801101542pe17862fsb82bdffa9a41853@mail.gmail.com> Message-ID: <1200263557.478a918520f8f@imp.free.fr> Hi, I think we are close to fix the pb. of the flashrom under LB on the m57sli mobo There was indeed a problem with the IO address decoding into the PCI->LPC bridge.. Facts: 1) after booting with LB : when reading @ the IO address 0x820 (where the SPI IF of the IT8715 SIO should be mapped), one gets 0xff (the value read is 0x0c after booting with the factory bios) 2) when probing the LPC bus with an oscilloscope, one can notice that a IO read @ 0x820 produces: - under factory bios : a corect IO read cycle as expected with the address 0x820 and the SIO answers with the correct value; - under LB : a WRITE IO cycle @ the address 0x0080! (yes is true!) This is what is seen on the bus (I tested many times..), even if the software operation really was a IO read; 3) the PCI register 0xa0 of the pci device 00:01.0 (the LPC bridge) holds the value: - 0xc1100001 under factory bios; - 0x30000001 under LB; 4) the IO range 0x0800->0x085f can be seen with the factory bios into the pci register 0xb4 of the same pci device; it don't appear with the actual version of LB 5) after booting with LB, and forcing the following registers of the lpc bridge with the following comands: setpci -s 00:01.0 a0.l=c1100001 setpci -s 00:01.0 a4.l=0 setpci -s 00:01.0 a8.l=0 setpci -s 00:01.0 ac.l=0 setpci -s 00:01.0 b0.l=02f40295 setpci -s 00:01.0 b4.l=085f0800 (force them at same values as in proprietary bios) the command "flashrom -m gigabyte:m57sli" do not hang anymore and correctly identifies the flash chip (I haven't tested yet a full flash programming) So a workaround is now possible as suggested in point (5). For a full coreboot patch, unfortunatelly I don't master the software architecture of coreboot enough to make a proposal.. Can someone help please? I would like to thank Yinghai for his advice (-> mcp55_lpc.c where I found the very interesting procedure "mcp55_lpc_enable_childrens_resources") which permited me to do this work.. Florentin Quoting yhlu : > On Jan 10, 2008 4:42 AM, Carl-Daniel Hailfinger > wrote: > > On 10.01.2008 12:14, Florentin Demetrescu wrote: > > > Hi all, > > > For my part I continue to think that there is a problem with the IO > address > > > decoding into the PCI->LPC bridge in mcp55.. Yinghai, can you help > please? > > > > > > > Yinghai? Is there some mcp55 conf we need to change? > > that range is already decoded to LPC bridge ( enable_rom, or > cache_as_rom_auto, or mcp55_lpc.c) > > YH > From echelon at free.fr Sun Jan 13 23:43:08 2008 From: echelon at free.fr (Florentin Demetrescu) Date: Sun, 13 Jan 2008 23:43:08 +0100 Subject: [coreboot] [LinuxBIOS] m57sli : debugging the flashrom problem when booting with LB In-Reply-To: <1200263557.478a918520f8f@imp.free.fr> References: <47668D76.6060602@gmx.net> <4766DD09.1070400@gmx.net> <1199963686.4785fe264a52d@imp.free.fr> <478612C1.7090504@gmx.net> <2ea3fae10801101542pe17862fsb82bdffa9a41853@mail.gmail.com> <1200263557.478a918520f8f@imp.free.fr> Message-ID: <1200264188.478a93fcd8877@imp.free.fr> By the way the LPC interface of the IT8716 version used by this mobo is not as described into the DS. The LPC pads are as follows: - LCLK (PCICLK?) : 78 - nLFRAME : 71 - nLRST : 68 - SERIRQ : 70 - LAD[0] : 72 - LAD[1] : 73 - LAD[2] : 74 - LAD[3] : 75 Lastly on can use the unpopulated TPM connector to solder a sniffer on the LPC bus (where we see that at least sometimes the Trusted Computing can be usefull at something.. ;-)) Quoting Florentin Demetrescu : > Hi, > > I think we are close to fix the pb. of the flashrom under LB on the m57sli > mobo > > There was indeed a problem with the IO address decoding into the PCI->LPC > bridge.. > > Facts: > 1) after booting with LB : when reading @ the IO address 0x820 (where the SPI > IF > of the IT8715 SIO should be mapped), one gets 0xff (the value read is 0x0c > after > booting with the factory bios) > 2) when probing the LPC bus with an oscilloscope, one can notice that a IO > read > @ 0x820 produces: > - under factory bios : a corect IO read cycle as expected with the address > 0x820 and the SIO answers with the correct value; > - under LB : a WRITE IO cycle @ the address 0x0080! (yes is true!) This is > what > is seen on the bus (I tested many times..), even if the software operation > really was a IO read; > 3) the PCI register 0xa0 of the pci device 00:01.0 (the LPC bridge) holds the > value: > - 0xc1100001 under factory bios; > - 0x30000001 under LB; > 4) the IO range 0x0800->0x085f can be seen with the factory bios into the pci > register 0xb4 of the same pci device; it don't appear with the actual version > of > LB > 5) after booting with LB, and forcing the following registers of the lpc > bridge > with the following comands: > setpci -s 00:01.0 a0.l=c1100001 > setpci -s 00:01.0 a4.l=0 > setpci -s 00:01.0 a8.l=0 > setpci -s 00:01.0 ac.l=0 > setpci -s 00:01.0 b0.l=02f40295 > setpci -s 00:01.0 b4.l=085f0800 > (force them at same values as in proprietary bios) > the command "flashrom -m gigabyte:m57sli" do not hang anymore and correctly > identifies the flash chip (I haven't tested yet a full flash programming) > > So a workaround is now possible as suggested in point (5). > > For a full coreboot patch, unfortunatelly I don't master the software > architecture of coreboot enough to make a proposal.. Can someone help please? > > I would like to thank Yinghai for his advice (-> mcp55_lpc.c where I found > the > very interesting procedure "mcp55_lpc_enable_childrens_resources") which > permited me to do this work.. > > Florentin > > Quoting yhlu : > > > On Jan 10, 2008 4:42 AM, Carl-Daniel Hailfinger > > wrote: > > > On 10.01.2008 12:14, Florentin Demetrescu wrote: > > > > Hi all, > > > > For my part I continue to think that there is a problem with the IO > > address > > > > decoding into the PCI->LPC bridge in mcp55.. Yinghai, can you help > > please? > > > > > > > > > > Yinghai? Is there some mcp55 conf we need to change? > > > > that range is already decoded to LPC bridge ( enable_rom, or > > cache_as_rom_auto, or mcp55_lpc.c) > > > > YH > > > > > > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > From c-d.hailfinger.devel.2006 at gmx.net Mon Jan 14 02:09:21 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 14 Jan 2008 02:09:21 +0100 Subject: [coreboot] [LinuxBIOS] m57sli : debugging the flashrom problem when booting with LB In-Reply-To: <1200263557.478a918520f8f@imp.free.fr> References: <47668D76.6060602@gmx.net> <4766DD09.1070400@gmx.net> <1199963686.4785fe264a52d@imp.free.fr> <478612C1.7090504@gmx.net> <2ea3fae10801101542pe17862fsb82bdffa9a41853@mail.gmail.com> <1200263557.478a918520f8f@imp.free.fr> Message-ID: <478AB641.3020306@gmx.net> Hi Florentin, you did a great job debugging this. Congratulations! On 13.01.2008 23:32, Florentin Demetrescu wrote: > I think we are close to fix the pb. of the flashrom under LB on the m57sli mobo > > There was indeed a problem with the IO address decoding into the PCI->LPC > bridge.. > > Facts: > 1) after booting with LB : when reading @ the IO address 0x820 (where the SPI IF > of the IT8715 SIO should be mapped), one gets 0xff (the value read is 0x0c after > booting with the factory bios) > 2) when probing the LPC bus with an oscilloscope, one can notice that a IO read > @ 0x820 produces: > - under factory bios : a corect IO read cycle as expected with the address > 0x820 and the SIO answers with the correct value; > - under LB : a WRITE IO cycle @ the address 0x0080! (yes is true!) This is what > is seen on the bus (I tested many times..), even if the software operation > really was a IO read; > 3) the PCI register 0xa0 of the pci device 00:01.0 (the LPC bridge) holds the > value: > - 0xc1100001 under factory bios; > - 0x30000001 under LB; > 4) the IO range 0x0800->0x085f can be seen with the factory bios into the pci > register 0xb4 of the same pci device; it don't appear with the actual version of > LB > 5) after booting with LB, and forcing the following registers of the lpc bridge > with the following comands: > setpci -s 00:01.0 a0.l=c1100001 > setpci -s 00:01.0 a4.l=0 > setpci -s 00:01.0 a8.l=0 > setpci -s 00:01.0 ac.l=0 > setpci -s 00:01.0 b0.l=02f40295 > setpci -s 00:01.0 b4.l=085f0800 > (force them at same values as in proprietary bios) > the command "flashrom -m gigabyte:m57sli" do not hang anymore and correctly > identifies the flash chip (I haven't tested yet a full flash programming) > > So a workaround is now possible as suggested in point (5). > > For a full coreboot patch, unfortunatelly I don't master the software > architecture of coreboot enough to make a proposal.. Can someone help please? > > I would like to thank Yinghai for his advice (-> mcp55_lpc.c where I found the > very interesting procedure "mcp55_lpc_enable_childrens_resources") which > permited me to do this work.. > Regards, Carl-Daniel From corey.osgood at gmail.com Mon Jan 14 11:46:29 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Mon, 14 Jan 2008 05:46:29 -0500 Subject: [coreboot] [LinuxBIOS] Intel refactoring and microcode updates In-Reply-To: <20080112101320.guxodivebggsoosg@www.smittys.pointclark.net> References: <47843324.2050907@gmail.com> <20080109212412.cgsck1t6xxcww4s8@www.smittys.pointclark.net> <4785AC27.40102@gmail.com> <20080110074842.3p5v4fkoowkg408w@www.smittys.pointclark.net> <4786C75F.9080806@gmail.com> <4786CADD.7030305@gmx.net> <4786D5B4.1040108@gmail.com> <20080111033439.1814.qmail@stuge.se> <47878038.3070102@gmail.com> <20080111145418.17092.qmail@stuge.se> <20080111153321.GB16602@greenwood> <20080111201658.1bl8gyy40oo04ggo@www.smittys.pointclark.net> <478834D4.9070208@gmail.com> <20080112101320.guxodivebggsoosg@www.smittys.pointclark.net> Message-ID: <478B3D85.6060207@gmail.com> joe at smittys.pointclark.net wrote: > Quoting Corey Osgood : > >> joe at smittys.pointclark.net wrote: >>> Quoting Uwe Hermann : >>> >>> >>>> On Fri, Jan 11, 2008 at 03:54:18PM +0100, Peter Stuge wrote: >>>> >>>>> On Fri, Jan 11, 2008 at 09:42:00AM -0500, Corey Osgood wrote: >>>>> >>>>>> Peter Stuge wrote: >>>>>> >>>>>>> I think we need to make it configurable. >>>>>>> >>>>>> I don't like that. With a factory bios, you expect the correct >>>>>> microcode update for your CPU to be present, no matter what CPU you >>>>>> put in a socket. >>>>>> >>>>> (Actually no, not always.) >>>>> >>>>> >>>>> >>>>>> We should be able to do the same. >>>>>> >>>>> I agree, but we should also try to be even more flexible. I think we >>>>> should allow inclusion of 0<=n<=all microcode updates. Definately an >>>>> advanced option, but still. >>>>> >>>> Yep, that's what I meant. It's fine if the default is "all microcode >>>> updates", but there should be an option for advanced users to only use >>>> the one(s) you really want or need in order to save time and space. >>>> >>>> >>>> Uwe. >>>> >>>> >>> That makes perfect sense.....I like the advanced option idea:-) >>> >>> Thanks - Joe >> >> This seems like it would get very messy, very quickly. The only way I >> can come up with to do it is #if's for every single ID, perhaps in some >> intel_custom folder, so it doesn't make a mess of the existing stuff. >> >> Anyways, I'll get on top of testing this weekend, I have slot 1 (440zx), >> socket 370 (i810), and socket 479 (i830) boards I can test with, >> assuming they all still work. If those work, I'll bet the farm that the >> rest of them do. Everything passes abuild, btw. >> >> -Corey >> > Yeh, even though it is a good idea it probibly would complicate things > alot. For now it may be better to just commit a piece at a time for > each processor tested. I'm really interested in how the socket 479 > (Pentium M) testing goes. Let us know:-) > > > Thanks - Joe I know ;) Uwe, do you have a 440bx board you can try this on? Mine has officially bit the dust. I can say that i810/socket 370 works as expected with 3 different cores. I'll get to the socket 479 if I have time tomorrow, I've been tinkering with the i810 most of the last couple days. Thanks, Corey From mechno at gmail.com Mon Jan 14 11:44:14 2008 From: mechno at gmail.com (Maarten van Eeuwijk) Date: Mon, 14 Jan 2008 11:44:14 +0100 Subject: [coreboot] *UPDATE*: lspci -tvnn, superiotool -dV, flashrom -V, for the MSI 6119 mainboard Message-ID: <53613eef0801140244g4249a782v3ab69ed86d93049b@mail.gmail.com> Hi all, Most of you already received the email displayed below. Later that day I spoke Uwe on IRC and he told me he had fogot to tell me I had to include the irq_tables.c as generated by getpir as well. So, here it is in the attachments. In case your mailing systems do not forward attachments, here are the contents of that file: /* This file was generated by getpir.c, do not modify! * (but if you do, please run checkpir on it to verify) * * Contains the IRQ Routing Table dumped directly from your * memory, which BIOS sets up. * * Documentation at: http://www.microsoft.com/whdc/archive/pciirq.mspx */ #ifdef GETPIR #include "pirq_routing.h" #else #include #endif const struct irq_routing_table intel_irq_routing_table = { PIRQ_SIGNATURE, /* u32 signature */ PIRQ_VERSION, /* u16 version */ 32+16*7, /* There can be total 7 devices on the bus */ 0x00, /* Where the interrupt router lies (bus) */ (0x07<<3)|0x0, /* Where the interrupt router lies (dev) */ 0x800, /* IRQs devoted exclusively to PCI usage */ 0x8086, /* Vendor */ 0x7000, /* Device */ 0, /* Crap (miniport) */ { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */ 0x9c, /* u8 checksum. This has to be set to some value that would give 0 after the sum of all bytes for this structure (including checksum) */ { /* bus, dev|fn, {link, bitmap}, {link, bitmap}, {link, bitmap}, {link, bitmap}, slot, rfu */ {0x00,(0x0e<<3)|0x0, {{0x60, 0xdeb8}, {0x61, 0xdeb8}, {0x62, 0xdeb8}, {0x63, 0x0deb8}}, 0x1, 0x0}, {0x00,(0x10<<3)|0x0, {{0x61, 0xdeb8}, {0x62, 0xdeb8}, {0x63, 0xdeb8}, {0x60, 0x0deb8}}, 0x2, 0x0}, {0x00,(0x12<<3)|0x0, {{0x62, 0xdeb8}, {0x63, 0xdeb8}, {0x60, 0xdeb8}, {0x61, 0x0deb8}}, 0x3, 0x0}, {0x00,(0x14<<3)|0x0, {{0x63, 0xdeb8}, {0x60, 0xdeb8}, {0x61, 0xdeb8}, {0x62, 0x0deb8}}, 0x4, 0x0}, {0x00,(0x07<<3)|0x1, {{0x00, 0xdeb8}, {0x00, 0xdeb8}, {0x00, 0xdeb8}, {0x00, 0x0deb8}}, 0x0, 0x0}, {0x00,(0x07<<3)|0x2, {{0x00, 0xdeb8}, {0x00, 0xdeb8}, {0x00, 0xdeb8}, {0x63, 0x0deb8}}, 0x0, 0x0}, {0x00,(0x01<<3)|0x0, {{0x60, 0xdeb8}, {0x61, 0xdeb8}, {0x62, 0xdeb8}, {0x63, 0x0deb8}}, 0x0, 0x0}, } }; greetz from Holland, Maarten "merethan" On Jan 13, 2008 12:50 PM, Maarten van Eeuwijk wrote: > Hi all, > > A few day's ago I asked Uwe for a little help on my MS6119 board from MSI. > He adviced me to post the results of lspci -tvnn, superiotool -dV > and flashrom -V to the mailing list, for the sake of archiving. > So, after some creative wiring I got a LiveCD going and ran the pieces of > software mentioned above. > > The tests are done with minimal hardware, all the PCI slots were empty. > The only slots filled were the CPU slot and the AGP slot. > > For the ones who think they recognize a Asus p2b here, you're almost dead > on. The MS6119 has the same hardware and similair layout but the wiring is > likely to be different. > > Here are the results: > > *lspci -tvnn:* > -[0000:00]-+-00.0 8086:7190 > +-01.0-[0000:01]----00.0 1002:4742 > +-07.0 8086:7110 > +-07.1 8086:7111 > +-07.2 8086:7112 > \-07.3 8086:7113 > > > *superiotool -dV:* > superiotool r3011 > Probing for ALi Super I/O at 0x3f0... > Failed. Returned data: id=0xffff, rev=0xff > Probing for ALi Super I/O at 0x370... > Failed. Returned data: id=0xffff, rev=0xff > Probing for Fintek Super I/O at 0x2e... > Failed. Returned data: vid=0xffff, id=0xffff > Probing for Fintek Super I/O at 0x4e... > Failed. Returned data: vid=0xffff, id=0xffff > Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x2e... > Failed. Returned data: id=0xffff, rev=0xf > Probing for ITE Super I/O (init=0x87,0x87) at 0x2e... > Failed. Returned data: id=0xffff, rev=0xf > Probing for ITE Super I/O (init=0x87,0x01,0x55,0x55/0xaa) at 0x4e... > Failed. Returned data: id=0xffff, rev=0xf > Probing for ITE Super I/O (init=0x87,0x87) at 0x4e... > Failed. Returned data: id=0xffff, rev=0xf > Probing for NSC Super I/O at 0x2e... > Failed. Returned data: port=0xff, port+1=0xff > Probing for NSC Super I/O at 0x4e... > Failed. Returned data: port=0xff, port+1=0xff > Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e... > Failed. Returned data: id=0xff, rev=0xff > Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x2e... > Failed. Returned data: id=0xff, rev=0xff > Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x4e... > Failed. Returned data: id=0xff, rev=0xff > Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x4e... > Failed. Returned data: id=0xff, rev=0xff > Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x162e... > Failed. Returned data: id=0xff, rev=0xff > Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x162e... > Failed. Returned data: id=0xff, rev=0xff > Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x164e... > Failed. Returned data: id=0xff, rev=0xff > Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x164e... > Failed. Returned data: id=0xff, rev=0xff > Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x3f0... > Failed. Returned data: id=0xff, rev=0xff > Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x3f0... > Failed. Returned data: id=0xff, rev=0xff > Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x370... > Failed. Returned data: id=0xff, rev=0xff > Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x370... > Failed. Returned data: id=0xff, rev=0xff > Probing for Winbond Super I/O (init=0x88) at 0x2e... > Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff > Probing for Winbond Super I/O (init=0x89) at 0x2e... > Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff > Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e... > Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff > Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e... > Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff > Probing for Winbond Super I/O (init=0x88) at 0x4e... > Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff > Probing for Winbond Super I/O (init=0x89) at 0x4e... > Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff > Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e... > Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff > Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e... > Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff > Probing for Winbond Super I/O (init=0x88) at 0x3f0... > Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff > Probing for Winbond Super I/O (init=0x89) at 0x3f0... > Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff > Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0... > Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff > Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0... > Found Winbond W83977TF (id=0x97, rev=0x73) at 0x3f0 > Register dump: > idx 20 21 22 23 24 25 26 28 2a 2b 2c 2d 2e 2f > val 97 73 ff fe 84 00 00 00 00 00 00 00 00 ff > def 97 73 ff fe MM 00 MM 00 00 00 00 RR RR RR > LDN 0x00 (Floppy) > idx 30 60 61 70 74 f0 f1 f2 f4 f5 > val 01 03 f0 06 02 0e 00 ff 00 00 > def 01 03 f0 06 02 0e 00 ff 00 00 > LDN 0x01 (Parallel port) > idx 30 60 61 70 74 f0 > val 01 03 78 07 03 00 > def 01 03 78 07 04 3f > LDN 0x02 (COM1) > idx 30 60 61 70 f0 > val 01 03 f8 04 00 > def 01 03 f8 04 00 > LDN 0x03 (COM2) > idx 30 60 61 70 f0 f1 > val 01 02 f8 03 00 00 > def 01 02 f8 03 00 00 > LDN 0x05 (Keyboard / mouse) > idx 30 60 61 62 63 70 72 f0 > val 01 00 60 00 64 01 00 42 > def 01 00 60 00 64 01 0c 83 > LDN 0x07 (GPIO 1) > idx 30 60 61 62 63 64 65 70 72 e0 e1 e2 e3 e4 e5 e6 e7 f1 > val 00 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 01 00 > def 00 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 01 00 > LDN 0x08 (GPIO 2) > idx 30 60 61 70 72 e8 e9 ea eb ec ed ee f0 f1 f2 f3 f4 > val 01 00 00 00 00 10 01 01 01 01 08 01 00 ff 00 00 00 > def 00 00 00 00 00 01 01 01 01 01 01 01 00 RR 00 00 00 > LDN 0x09 (GPIO 3) > idx 30 60 61 62 63 64 65 70 72 e0 e1 e2 e3 e4 e5 e6 e7 f1 > val 00 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 01 00 > def 00 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 01 00 > LDN 0x0a (ACPI) > idx 30 60 61 62 63 64 65 70 e0 e1 02 e3 e4 f0 f1 f2 f3 f4 f5 f6 f7 fe ff > > val 00 00 00 00 00 00 00 00 00 00 ff 07 00 00 00 0f 07 00 00 00 00 00 00 > def 00 00 00 00 00 00 00 00 00 00 NA MM RR 00 00 00 00 00 00 00 00 RR RR > Probing for Winbond Super I/O (init=0x88) at 0x370... > Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff > Probing for Winbond Super I/O (init=0x89) at 0x370... > Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff > Probing for Winbond Super I/O (init=0x86,0x86) at 0x370... > Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff > Probing for Winbond Super I/O (init=0x87,0x87) at 0x370... > Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff > Probing for Winbond Super I/O (init=0x88) at 0x250... > Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff > Probing for Winbond Super I/O (init=0x89) at 0x250... > Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff > Probing for Winbond Super I/O (init=0x86,0x86) at 0x250... > Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff > Probing for Winbond Super I/O (init=0x87,0x87) at 0x250... > Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff > > > *flashrom -V:* > Calibrating delay loop... 100M loops per second. OK. > No LinuxBIOS table found. > Found chipset "PIIX4/PIIX4E/PIIX4M", enabling flash write... OK. > Probing for Am29F040B, 512 KB > probe_29f040b: id1 0x7f, id2 0x3f > Probing for Am29LV040B, 512 KB > probe_29f040b: id1 0x7f, id2 0x3f > Probing for Am29F016D, 2048 KB > probe_29f040b: id1 0xff, id2 0xff > Probing for AE49F2008, 256 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for At29C040A, 512 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for At29C020, 256 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for At49F002(N), 256 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for At49F002(N)T, 256 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for EN29F002(A)(N)T, 256 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for EN29F002(A)(N)B, 256 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for MBM29F400TC, 512 KB > probe_m29f400bt: id1 0x7f, id2 0x3f > Probing for MX29F002, 256 KB > probe_29f002: id1 0xda, id2 0x45 > Probing for MX25L4005, 512 KB > generic_spi_command called, but no SPI chipset detected > Probing for MX25L8005, 1024 KB > generic_spi_command called, but no SPI chipset detected > Probing for SST25VF040B, 512 KB > generic_spi_command called, but no SPI chipset detected > Probing for SST25VF016B, 2048 KB > generic_spi_command called, but no SPI chipset detected > Probing for SST29EE020A, 256 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for SST28SF040A, 512 KB > probe_28sf040: id1 0x7f, id2 0x3f > Probing for SST39SF010A, 128 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for SST39SF020A, 256 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for SST39SF040, 512 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for SST39VF020, 256 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for SST49LF040B, 512 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for SST49LF040, 512 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for SST49LF020A, 256 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for SST49LF080A, 1024 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for SST49LF002A/B, 256 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for SST49LF003A/B, 384 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for SST49LF004A/B, 512 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for SST49LF008A, 1024 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for SST49LF004C, 512 KB > probe_49lfxxxc: id1 0x7f, id2 0x3f > Probing for SST49LF008C, 1024 KB > probe_49lfxxxc: id1 0x7f, id2 0x3f > Probing for SST49LF016C, 2048 KB > probe_49lfxxxc: id1 0xff, id2 0xff > Probing for SST49LF160C, 2048 KB > probe_49lfxxxc: id1 0xff, id2 0xff > Probing for Pm49FL002, 256 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for Pm49FL004, 512 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for W29C011, 128 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for W29C040P, 512 KB > probe_jedec: id1 0xda, id2 0x45 > Probing for W29C020C, 256 KB > probe_jedec: id1 0xda, id2 0x45 > W29C020C found at physical address 0xfffc0000. > Flash part is W29C020C (256 KB). > No operations were specified. > > That's it. > > Uwe told me he could help me with hacking up a MS6119 target file with > this info. > Once the bios works, I 'll use it to make a router of that board utilizing > coreboot, m0n0wall, a few ethernet NIC's and a Compact flash card. > Once that works I will demonstrate it at school. Perhaps I 'll put it > against a Cisco router in a VS showdown on troughput. > Might be cool to beat a 800+ bucks Cisco machine with an old piece of > hardware I found in a trashbox. > > > tnx for your time, > > Maarten "merethan" > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: irq_tables.c Type: text/x-csrc Size: 1839 bytes Desc: not available URL: From c-d.hailfinger.devel.2006 at gmx.net Mon Jan 14 13:00:13 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 14 Jan 2008 13:00:13 +0100 Subject: [coreboot] Web site configuration Message-ID: <478B4ECD.3000101@gmx.net> Hi, it seems that the recent move to coreboot.org has created a level of content duplication which will eventually worsen our search engine ranking. We duplicate almost all content at least five(!) times: http://linuxbios.org/AMD_SimNow http://www.linuxbios.org/AMD_SimNow http://wiki.linuxbios.org/AMD_SimNow http://coreboot.org/AMD_SimNow http://www.coreboot.org/AMD_SimNow Can we please decide which domain we will use for the wiki in the future and issue "HTTP 301 Moved Permanently" for all URLs containing one of the other domains? That way, Google will not pick its own random selection of *.linuxbios.org and *.coreboot.org when researching stuff about LinuxBIOS/coreboot. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Mon Jan 14 13:40:56 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 14 Jan 2008 13:40:56 +0100 Subject: [coreboot] [LinuxBIOS] Welcome to coreboot. In-Reply-To: <13426df10801111743x101d9e24v6ae046df01873597@mail.gmail.com> References: <13426df10801111743x101d9e24v6ae046df01873597@mail.gmail.com> Message-ID: <478B5858.7080203@gmx.net> On 12.01.2008 02:43, ron minnich wrote: > Welcome to coreboot! > > [...] > > As a result, starting last year, we decided to look at a new name. We > had lots of > candidates, and discussed the name with many companies. In the end, the name > that seemed to stick was "coreboot". It makes a lot of sense: the code we are > working on is the "core boot code". > There is one aspect of the new name that was not discussed yet if I remember correctly: Capitalization. It seems "coreboot" is all lowercase. While I agree that it looks nice, I remember the trouble "openSUSE" had when they insisted on their particular capitalization, especially in contiguous texts with "openSUSE" at the beginning of some sentences. Starting a sentence with a lowercase word makes most word processors complain loudly. Independent of that, some media outlets don't care about capitalization of project nam