coreboot May 2006

coreboot@coreboot.org

50 participants
101 discussions

[LinuxBIOS] Rapid booting of Linux -- Recommended distributions / Kernel options?
by Eric Poulsen 06 May '06

06 May '06

I've been using Ubuntu (because of ease of install / familiarity with Debian) as my test platform for rapid booting. Ubuntu is remarkably slow at booting -- It's made to work with just about any hardware. Can anyone recommend any distributions that are more geared towards the embedded rapid-boot? Essentially, I'd like to have a user-space program that's doing I/O via serial / usb to do data logging as quickly as possible, and everything else (display, mounting a mechanical hard drive) can wait. Essentially, steps 1-3 have to be as fast as possible. 1) LB + Filo -- Load Kernel from CF 2) Kernel init (I have this down to 0.9 seconds) 3) User space program that loads USB drivers and begins data logging 4) Everything else: network, display (X.org), hard drive mount etc I need a distro that lets you do most of the usual startup stuff later. --- Here's a list of kernel options that I'm using -- anybody have any other "tricks" to speed this up? root=/dev/hda1 console=ttyS0,115200 [I know this slows it down] console=tty0 [This might be a major time waster, also -- I suspect the kernel VGA init is slow] lpj=2136847 dhash_entries=16000 [I'm not sure if making the Dentry hash is slow, or if the VGA init routine just before it is the culprit] ide0=0x1f0,0x3f6,14 ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe hda=65535,16,63 hdb=none hdc=noprobe [This is the CF -- don't need it after boot] hdd=none no_hlt Also, If I do hda=noprobe, I guess the kernel won't mount it, so it fails. Seems like the kernel *must* probe the hd? I thought as long as it has the CHS, it didn't need to probe.

3 2

Re: [LinuxBIOS] some more tyan/s2881 questions
by Lu, Yinghai 05 May '06

05 May '06

1. need to add acpi support in s2881 LinuxBIOS support to get it. Anyway 8111 acpi support is already there in Serengeti_leopard, so it will be easy to get that. YH -----Original Message----- From: linuxbios-bounces(a)linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of Ward Vandewege Sent: Monday, April 10, 2006 3:43 PM To: linuxbios(a)linuxbios.org Subject: [LinuxBIOS] some more tyan/s2881 questions So the board is stable now. That's great. Some observations: 1. 'halt' no longer powers the machine off, which it does with the proprietary bios. 'halt -p' does the job though. LinuxBIOS oddity? 2. reboots seem to cause problems sometimes. I'm not sure yet what causes this, but I've had problems with the machine hanging after ACPI: Unable to locate RSDP It normally sits there for a few seconds, but I had the machine in such a state that it simply hung at that point. This may have had something to do with the IPMI card, which I'm experimenting with. I had to unplug the power before this problem went away, a cold restart didn't help. I will do more testing to see if I can pinpoint this. Thanks for all your help so far! Ward. -- Ward Vandewege <ward(a)fsf.org> Free Software Foundation - Senior System Administrator -- linuxbios mailing list linuxbios(a)linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios

3 8

[LinuxBIOS] s2881 build broken
by Ward Vandewege 05 May '06

05 May '06

Hi all, It seems that revision 2288 broke something in the tyan/s2881 build; 2289 and 2290 are also bad. 2287 is ok. Boot log attached; it just keeps rebooting after the 'Jumping to LinuxBIOS' line. This is gcc 3.4. Suggestions? Thanks, Ward. -- Ward Vandewege <ward(a)fsf.org> Free Software Foundation - Senior System Administrator

2 4

Re: [LinuxBIOS] MSI K8N Neo4-F (PCB 1.0)
by Lu, Yinghai 05 May '06

05 May '06

It could be supported. 1. Ck804 support is in the tree. 2. athlon64 support is in the tree. But need to check to make it support 1 above dimms 3. Athlon64 FX support need to use fidvid to set correct FID, otherwise it will only run at low freq. ---- we need to provide enable_fid_change_on_sb for Ck804. You can start from make a clone mb and target dir for it from tyan s2891... YH

1 0

[LinuxBIOS] MSI K8N Neo4-F (PCB 1.0)
by Chaos Eternal 05 May '06

05 May '06

I'v got a motherboard: MSI K8N Neo4-F (PCB 1.0) URL IS http://www.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID… Typically it's a CK804 board, so I want to make it run linux bios, can anybody give me some comments? lspci's result: 0000:00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7125 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Capabilities: [44] #08 [01e0] Capabilities: [e0] #08 [a801] 0000:00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7125 Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 0000:00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7125 Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Interrupt: pin A routed to IRQ 3 Region 0: I/O ports at fc00 [size=32] Region 4: I/O ports at 4c00 [size=64] Region 5: I/O ports at 4c40 [size=64] Capabilities: [44] 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- 0000:00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) (prog-if 10 [OHCI]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7125 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 (750ns min, 250ns max) Interrupt: pin A routed to IRQ 50 Region 0: Memory at fe02f000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] 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- 0000:00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) (prog-if 20 [EHCI]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7125 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 (750ns min, 250ns max) Interrupt: pin B routed to IRQ 217 Region 0: Memory at feb00000 (32-bit, non-prefetchable) [size=256] Capabilities: [44] #0a [2098] Capabilities: [80] 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- 0000:00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) (prog-if 8a [Master SecP PriP]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7125 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 (750ns min, 250ns max) Region 4: I/O ports at e000 [size=16] Capabilities: [44] 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- 0000:00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) (prog-if 85 [Master SecO PriO]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7125 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 (750ns min, 250ns max) Interrupt: pin A routed to IRQ 217 Region 0: I/O ports at 09f0 [size=8] Region 1: I/O ports at 0bf0 [size=4] Region 2: I/O ports at 0970 [size=8] Region 3: I/O ports at 0b70 [size=4] Region 4: I/O ports at cc00 [size=16] Region 5: Memory at fe02b000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] 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- 0000:00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) (prog-if 85 [Master SecO PriO]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7125 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 (750ns min, 250ns max) Interrupt: pin A routed to IRQ 225 Region 0: I/O ports at 09e0 [size=8] Region 1: I/O ports at 0be0 [size=4] Region 2: I/O ports at 0960 [size=8] Region 3: I/O ports at 0b60 [size=4] Region 4: I/O ports at b800 [size=16] Region 5: Memory at fe02a000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] 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- 0000:00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) (prog-if 01 [Subtractive decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 I/O behind bridge: 0000a000-0000afff Memory behind bridge: fde00000-fdefffff Prefetchable memory behind bridge: fdf00000-fdffffff BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- 0000:00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7125 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 (250ns min, 5000ns max) Interrupt: pin A routed to IRQ 233 Region 0: Memory at fe029000 (32-bit, non-prefetchable) [size=4K] Region 1: I/O ports at b400 [size=8] Capabilities: [44] 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- 0000:00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (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- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 0x08 (32 bytes) Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: 00009000-00009fff Memory behind bridge: fdd00000-fddfffff Prefetchable memory behind bridge: 00000000fdc00000-00000000fdc00000 BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- Capabilities: [40] 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- Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable+ Address: 00000000fee00000 Data: 40b9 Capabilities: [58] #08 [a800] Capabilities: [80] #10 [0141] 0000:00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (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- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 0x08 (32 bytes) Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: 00008000-00008fff Memory behind bridge: fdb00000-fdbfffff Prefetchable memory behind bridge: 00000000fda00000-00000000fda00000 BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- Capabilities: [40] 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- Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable+ Address: 00000000fee00000 Data: 40c1 Capabilities: [58] #08 [a800] Capabilities: [80] #10 [0141] 0000:00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (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- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 0x08 (32 bytes) Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 I/O behind bridge: 00007000-00007fff Memory behind bridge: fd900000-fd9fffff Prefetchable memory behind bridge: 00000000fd800000-00000000fd800000 BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- Capabilities: [40] 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- Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable+ Address: 00000000fee00000 Data: 40c9 Capabilities: [58] #08 [a800] Capabilities: [80] #10 [0141] 0000:00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (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- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 0x08 (32 bytes) Bus: primary=00, secondary=05, subordinate=05, sec-latency=0 I/O behind bridge: 00006000-00006fff Memory behind bridge: fd700000-fd7fffff Prefetchable memory behind bridge: 00000000fd600000-00000000fd600000 BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- Capabilities: [40] 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- Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable+ Address: 00000000fee00000 Data: 40d1 Capabilities: [58] #08 [a800] Capabilities: [80] #10 [0141] 0000:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Capabilities: [80] #08 [2101] 0000:00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- 0000:00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- 0000:00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

1 0

[LinuxBIOS] Another newbi question / TYAN TIGER MP S2460
by paul.collomb1＠libertysurf.fr 05 May '06

05 May '06

Thanks for your response. I do not prefer LinuxBIOS v2 than LinuxBIOS v1. I am not a specialist, my goal is just to work with a " LinuxBIOS moherboard compatible ", in the support of LinuxBIOS v1 I have only see the " S2466 " model ( for K7 ). It's almost the same model but is it compatible with " S2460 " ? Thanks -------------------------------------------------------------------------------------------------------------------------------------- From: "Lu, Yinghai" <yinghai.lu(a)amd.com> To: paul.collomb1(a)libertysurf.fr, "_linuxbios" <linuxbios(a)linuxbios.org> In the LinuxBIOS V1, there is support for Tyan K7 MB. If you want support in LinuxBIOS v2, Someone need to check northbridge/amd/amd76x and reformat the interface or translate to C.... -------------- ALICE HAUT DEBIT : TRIPLE PLAY A 29,95 EUR/MOIS -------------- Découvrez vite ALICEBOX : avec le modem WIFI, profitez de l'ADSL, de la TELEPHONIE et en exclusivité de la TELEVISION ! Bénéficiez aussi de la hotline gratuite 24h/24 ! Soumis à conditions. Pour en profiter cliquez ici http://abonnement.aliceadsl.fr

1 0

[LinuxBIOS] Epia M tree build issue
by Eric Poulsen 04 May '06

04 May '06

I know I'm beginning to sound like a broken record here, but I can't seem to get a definitive answer, and the build process for LB is ... complex. 1) Is the effect reproducible on other systems? Has anyone else tried to follow the same steps I have?* 2) If so, is this a "real" issue? Or do I just badly mis-understand the LB build process? * I realize that most people don't have Epia motherboards to try this on, but if the "right" way compiles the first time around, that'd be something. --- The issue: There are two distinct ways I've attempted to build an Epia-M target. The first way I tried it was "wrong" because I didn't do a 'make clean' after changing config options and re-running 'builtarget'. Oddly, this "wrong" way resulted in a working LB install. Later, when modifying LB itself to better support the Epia ML (NB: These changes have no affect on the effect seen, and everything mentioned here applies to a stock Epia M target), I was more careful about my build process, and found that building from fully cleaned ('make clean') target directory resulted in a LB binary that did not work. The "wrong" way that works: 'buildtarget via/epia-m' make [compiles OK, but we don't have VGA options] Edit Config.lb; add the vga options (CONFIG_CONSOLE_VGA=1, CONFIG_PCI_ROM_RUN=1) 'buildtarget via/epia-m' make [Compiles successfully -- We now have a working LB + VGA ] [If you do a "make clean" just before the _second_ make, you'll have the same linking errors you see below] The "right" way that doesn't work: Enter the targets/via/epia-m directory Edit Config.lb; add the vga options (CONFIG_CONSOLE_VGA=1, CONFIG_PCI_ROM_RUN=1) 'buildtarget via/epia-m' make [Linking errors -- I'd say this is where the issue first manifests itself] Edit Config.lb again, increase ROM_IMAGE_SIZE 'buildtarget via/epia-m' make [Compiles successfully, but with a bad LB image -- Exception 13 during attempts to init VGA]

6 11

Re: [LinuxBIOS] s2881 build broken
by Lu, Yinghai 04 May '06

04 May '06

If the compressed_stream is enabled, 1. when build the payload.nrv2b_x, if ratio <= 1, the head four byte will be "0x5a5a5a5a", and use ori payload. else the head four byte will be "0xaaaaaaaa", and used payload.nrv2b image instead. 2. when rom_steam_init is called, it will check the head signature to decide if uncompress it, or just use it. YH -----Original Message----- From: linuxbios-bounces(a)linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of yhlu Sent: Thursday, May 04, 2006 8:44 AM To: Stefan Reinauer Cc: Ward Vandewege; linuxbios(a)linuxbios.org Subject: Re: [LinuxBIOS] s2881 build broken that will need another 4 byte header before the stream. YH On 5/4/06, Stefan Reinauer <stepan(a)coresystems.de> wrote: > * yhlu <yinghailu(a)gmail.com> [060504 13:12]: > > You revert the ilen print out? > > we could add that into the unrv2b() function, but I think we should not > change the API for debugging only. > > > if you nrv2b one zelf image, you will get more bigger ilen instead... > > Can we detect whether we're decompressing a zelf image and print a > message instead? or cause that the uncompressed version is used? > > Stefan > > -- > coresystems GmbH * Brahmsstr. 16 * D-79104 Freiburg i. Br. > Tel.: +49 761 7668825 * Fax: +49 761 7664613 > Email: info(a)coresystems.de * http://www.coresystems.de/ > -- linuxbios mailing list linuxbios(a)linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios

1 0

[LinuxBIOS] WRITE FROM COLOMBIA
by MIJAIL 04 May '06

04 May '06

HI... SORRY BY MY ENGLISH I WROTE TO YOU FROM BOGOTA COLOMBIA.. WE WANT TO TRY TO DO A CLUSTER WITH A LINUXBIOS.... MY QUESTION ARE: 1. WHEN I UPDATE MY MOTHERBOARD BIOS WITH LINUXBIOS (MAKE IN A FLASH BIOS)I HAVE A RISK TO NEVER WORK AGAIN MY BOARD?? 2. WHEN I UPDATE MY MOTHERBOARD BIOS WITH LINUXBIOS I NEED ALSO INTAL THE BPROC PROGRAM?? 3. IF I HAVE INSTALED DEBIAN AND I WANT INSTAL LINUXBIOS THE INFORMATION AND SISTEM WILL BE LOST?? 4. IF I HAVE MANY OLD PC'S...(LIKE PENTIUM III) WHITH PROCESOR, RAM, WITHOUT HARD DRIVE, CAN I INSTAL LINUX BIOS?? 5. HOW I TO FORM THE IP ADRESS IN THE BIOS TO MAKE THE MACHINE ABLE TO USE IN MY LAN?? TANK VERY MUCH... LAST QUESTION....YOU SEND ME A ANSWER TO THIS MAIL OR I NEED TO FIND IT IN SOME WEB PAGE?? -- Mijail Valderrama Kireeva Ingeniero de Sistemas Tel. (571) 227 1236 Cel. 300-5705741 Bogotá - Colombia

2 1

Re: [LinuxBIOS] s2881 build broken
by Lu, Yinghai 04 May '06

04 May '06

I commit the fix up, please check it... Thanks Yinghai Lu -----Original Message----- From: linuxbios-bounces(a)linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of Ward Vandewege Sent: Wednesday, May 03, 2006 5:10 PM To: Stefan Reinauer Cc: linuxbios(a)linuxbios.org Subject: Re: [LinuxBIOS] s2881 build broken On Thu, May 04, 2006 at 01:12:08AM +0200, Stefan Reinauer wrote: > * Ward Vandewege <ward(a)gnu.org> [060504 00:39]: > > Hi all, > > > > It seems that revision 2288 broke something in the tyan/s2881 build; 2289 and > > 2290 are also bad. 2287 is ok. > > > > Boot log attached; it just keeps rebooting after the 'Jumping to LinuxBIOS' > > line. This is gcc 3.4. > > > > Suggestions? > > Yes, I suggest I owe you a beer next time we meet and you try 2291. :) all right, will do so on Friday; not in the office tomorrow. I'll put a note on the s2881 build page that 2288 through 2290 are known bad. > Yinghai Lu has sent a patch that is more complete but also more > intrusive, which will go in later I guess. Until then this should work > fine. > > This one is a good reason for automated testing on hardware.. 8) Yes. I was thinking about that today while trying different revisions to see which one was the culprit. Would there be an easier way to do automated testing than having lots of boxes with some sort of software switchable BIOSsavior (actually, that would be a nice thing to have in any case)? Emulation, perhaps? Ward. -- Ward Vandewege <ward(a)fsf.org> Free Software Foundation - Senior System Administrator -- linuxbios mailing list linuxbios(a)linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios

3 4

← Newer
1
...
5
6
7
8
9
10
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot May 2006