coreboot November 2007

coreboot@coreboot.org

75 participants
397 discussions

[LinuxBIOS] Mounting root FS from VIA EPIA M-II still not working
by Coquelicot 20 Nov '07

20 Nov '07

Dear all, I know that this subject is coming back and forth to the mailing list like boomerang but I need some help with it. Apparently it IS possible to make linux recognize CompactFlash as a root device but so far I have been unable to make it work. I have tried lots of paths, both from reading the mailing list archives (esp. one success story from Markus Tornqvist - which gave me some hope) and VIA EPIA M howto available on LB webpage. I still can't make Linux recognize 3rd IDE controller (ide2). LinuxBIOS part works fine - the kernel boots from CF card all right, than it stops. I have tries 'resetcf' LB utility in early stage of boot (I am trying to boot Debian so I was putting this utility in various directories in the initrd image - 'init-premount', 'init-top', also - 'local-top'. I tried to pass 'ide2=0x1e0,0x1ec,9 ide4=noprobe'. Nothing worked. I know that plan B for now is to try to find CF-to-IDE adapter that can do the booting but I thought that would be a waste of CF slot on board... I wanted to make the system as embedded as it can be. I will be very grateful for any advice. I am using kernel 2.6.23, my CF card is SanDisk Extreme III. -- Coquelicot

2 1

[LinuxBIOS] alix1c
by Peter Stuge 19 Nov '07

19 Nov '07

Limited success. LinuxBIOS-2.0.0.0Fallback Fri Nov 16 05:46:41 CET 2007 booting... I added a POST code and a while(1) near the end of hardwaremain.c after this message. The board shows the POST for about a second and then powers off. If I move the while(1) to after init_timer() it pauses on POST 11 for a second or so, then shows some other codes quickly, then 80 and then power off, even though init_timer() seems to be do {} while(0) on the alix1c. This is also the behavior I get with a fresh checkout. //Peter

5 7

[LinuxBIOS] Socket 370 thought....
by joe＠smittys.pointclark.net 18 Nov '07

18 Nov '07

Hello, Just had a thought. I wonder if socket 370 boards with LinuxBIOS (i810) would support Tualatin (FC-PGA2) processors as long as the FSB was compatable. You would probibly need a FC-PGA to FC-PGA2 converter because of the voltage differences, but this would allow much faster processors, up to 1.4Ghz :-) Thanks - Joe

4 8

[LinuxBIOS] Long LinuxBIOS boot
by Coquelicot 18 Nov '07

18 Nov '07

Hey all, I'm experiencing curiously long startup time - 20 seconds before LB starts booting - on my VIA EPIA M-II. To investigate, I have re-compiled LB with logging level 9 and it seems that the delay is very long even before LB starts to output any messages to TTYS1. I am worndering what can be the cause? I have compiled LB binary an pre-pended it with original VIA video bios (extracted from the motherboard). After boot, everything works very well, I can see the Linux boot messages but 20 second startup time - that defies the whole LB concept, so I am confused :). I have tested it with 2 different power supplies and the result was the same, only slightly different - with normal PC powersupply I managed to get LB booting in ~10 seconds (ie. before first LB messages were sent to the serial port). The original power supply that takes ~20 seconds to boot it M1-ATX carpc power supply. Big thanks for any help, I attach the LB boot log for reference -- Coquelicot

1 0

[LinuxBIOS] r2975 build service
by LinuxBIOS information 17 Nov '07

17 Nov '07

Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2975 to the LinuxBIOS source repository and caused the following changes: Change Log: Detection support for more Super I/Os. Small fixes (trivial). Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Build Log: Compilation of amd:serengeti_cheetah is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2975&device=serengeti_che… Compilation of asus:a8v-e_se is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2975&device=a8v-e_se&vend… Compilation of iwill:dk8_htx is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2975&device=dk8_htx&vendo… Compilation of msi:ms9185 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2975&device=ms9185&vendor… Compilation of msi:ms9282 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2975&device=ms9282&vendor… Compilation of supermicro:h8dmr is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2975&device=h8dmr&vendor=… If something broke during this checkin please be a pain in uwe'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

1 0

[LinuxBIOS] r2975 - trunk/util/superiotool
by svn＠openbios.org 17 Nov '07

17 Nov '07

Author: uwe Date: 2007-11-17 18:13:52 +0100 (Sat, 17 Nov 2007) New Revision: 2975 Modified: trunk/util/superiotool/README trunk/util/superiotool/ali.c trunk/util/superiotool/smsc.c trunk/util/superiotool/superiotool.8 trunk/util/superiotool/superiotool.h Log: Detection support for more Super I/Os. Small fixes (trivial). Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Modified: trunk/util/superiotool/README =================================================================== --- trunk/util/superiotool/README 2007-11-15 15:52:42 UTC (rev 2974) +++ trunk/util/superiotool/README 2007-11-17 17:13:52 UTC (rev 2975) @@ -30,9 +30,9 @@ Usage ----- - $ superiotool [-d] [-D] [-V] [-v] [-h] + $ superiotool [-d] [-V] [-v] [-h] - -d | --dump Dump Super I/O registers + -d | --dump Dump Super I/O register contents -V | --verbose Verbose mode -v | --version Show the superiotool version -h | --help Show a short help text Modified: trunk/util/superiotool/ali.c =================================================================== --- trunk/util/superiotool/ali.c 2007-11-15 15:52:42 UTC (rev 2974) +++ trunk/util/superiotool/ali.c 2007-11-17 17:13:52 UTC (rev 2975) @@ -53,6 +53,8 @@ {0x30,0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,EOT}, {0x00,0x35,0x14,0x11,0x71,RSVD,0x05,EOT}}, {EOT}}}, + {0x2351, "M512x", { + {EOT}}}, {EOT} }; @@ -78,6 +80,8 @@ id = regval(port, DEVICE_ID_BYTE1_REG) << 8; id |= regval(port, DEVICE_ID_BYTE2_REG); + + /* TODO: Not documented/available on M512x (?) */ rev = regval(port, DEVICE_REV_REG); if (superio_unknown(reg_table, id)) { Modified: trunk/util/superiotool/smsc.c =================================================================== --- trunk/util/superiotool/smsc.c 2007-11-15 15:52:42 UTC (rev 2974) +++ trunk/util/superiotool/smsc.c 2007-11-17 17:13:52 UTC (rev 2975) @@ -28,10 +28,19 @@ static const struct superio_registers reg_table[] = { /* The following Super I/Os use the 0x20/0x21 ID registers. */ + {0x03, "FDC37C93xFR", { + /* FIXME: There's another 0x03 but found on port 0x0d/0x0e! */ + {EOT}}}, + {0x0a, "FDC37N971", { + {EOT}}}, + {0x0b, "FDC37N972", { + {EOT}}}, {0x0e, "LPC47N252", { /* From sensors-detect */ {EOT}}}, {0x14, "LPC47M172", { {EOT}}}, + {0x30, "FDC37C93xAPM", { + {EOT}}}, {0x40, "FDC37C67x", { /* E.g. FDC37C672. Chiprev: 0x01 */ {EOT}}}, {0x42, "FDC37B80x/FDC37M707", { @@ -79,6 +88,8 @@ {0x30,0x60,0x61,0x70,0xf0,EOT}, {0x00,0x00,0x00,NANA,NANA,EOT}}, {EOT}}}, + {0x43, "FDC37B77x", { + {EOT}}}, {0x44, "FDC37B78x", { {NOLDN, NULL, {0x03,0x07,0x20,0x21,0x22,0x23,0x24,0x26,0x27,0x28, @@ -337,10 +348,14 @@ {0x03, "FDC37C669", { /* Init: 0x55, 0x55. Exit: 0xaa. Ports: 0x3f0/0x370. */ /* Chiprev: 0x02. */ + /* FIXME: There's another 0x03 but found on port 0x20/0x21! */ {EOT}}}, {0x04, "FDC37C669FR", { /* TODO: Not yet in sensors-detect. */ /* Init: 0x55, 0x55. Exit: 0xaa. Ports: 0x3f0/0x370. */ {EOT}}}, + {0x13, "LPC47N237", { + /* Init: 0x55. Exit: 0xaa. Ports: 0x2e/0x4e. */ + {EOT}}}, {0x28, "FDC37N769", { /* Init: 0x55. Exit: 0xaa. Ports: 0x3f0/0x370. */ {NOLDN, NULL, @@ -355,6 +370,9 @@ 0x80,0x00,0x3c,RSVD,RSVD,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,RSVD,0x00,0x00,0x03,0x00,0x00,EOT}}, {EOT}}}, + {0x29, "FDC37N3869/FDC37N869", { + /* Init: 0x55. Exit: 0xaa. Ports: 0x3f0/0x370. */ + {EOT}}}, {0x5a, "LPC47N227", { /* Init: 0x55. Exit: 0xaa. Ports: 0x2e/0x4e. */ {NOLDN, NULL, Modified: trunk/util/superiotool/superiotool.8 =================================================================== --- trunk/util/superiotool/superiotool.8 2007-11-15 15:52:42 UTC (rev 2974) +++ trunk/util/superiotool/superiotool.8 2007-11-17 17:13:52 UTC (rev 2975) @@ -74,7 +74,7 @@ .TP .B "\-V, \-\-verbose" Enable verbose mode. This option can be used together with the -.BR "\-d" " or " "\-D" " option (or both)." +.BR "\-d" " option." .sp The verbose output will not only list for which type of Super I/O the tool is scanning, but also at which configuration port it's probing, and which Modified: trunk/util/superiotool/superiotool.h =================================================================== --- trunk/util/superiotool/superiotool.h 2007-11-15 15:52:42 UTC (rev 2974) +++ trunk/util/superiotool/superiotool.h 2007-11-17 17:13:52 UTC (rev 2975) @@ -30,7 +30,7 @@ #include <sys/io.h> #define USAGE "Usage: superiotool [-d] [-V] [-v] [-h]\n\n\ - -d | --dump Dump Super I/O registers\n\ + -d | --dump Dump Super I/O register contents\n\ -V | --verbose Verbose mode\n\ -v | --version Show the superiotool version\n\ -h | --help Show a short help text\n\n\

1 0

[LinuxBIOS] [PATCH] v3: update design doc to new realities
by Carl-Daniel Hailfinger 17 Nov '07

17 Nov '07

Update the design doc to match a mixture of wishful thinking and reality. * We use LAR and not CPIO * printk() can be called from stage 1 without ill effects * stage 2 phase 1 is without purpose Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> --- Index: LinuxBIOSv3/doc/design/newboot.lyx =================================================================== --- LinuxBIOSv3/doc/design/newboot.lyx (Revision 509) +++ LinuxBIOSv3/doc/design/newboot.lyx (Arbeitskopie) @@ -85,7 +85,7 @@ \begin_layout Standard The new LinuxBIOS boot architecture depends on CAR, with payloads appearing - as files in a CPIO archive. + as files in a LAR archive. The device tree is defined by a device tree blob (DTB) and all the activities flow from that. For now, the DTC will produce a standard LinuxBIOS v2 device tree; this @@ -150,7 +150,7 @@ is the layout of the whole FLASH. Note that we can kill the buildrom tool, since the FLASH code is now a - CPIO archive. + LAR archive. Note that the linker script will now be very simple. The initram is roughly what is in auto.c, although the early hardware setup from auto.c is now in the pre-initram, so that we have serial output and @@ -162,7 +162,7 @@ etc. The DTB can be modified by the flashrom tool, and hence a platform can be customized from a binary FLASH image. - Each CPIO file has a checksum attached to the end, so that the system can + Each LAR file has a checksum attached to the end, so that the system can verify that the data is uncorrupted. We now build at least four targets for a platform: \end_layout @@ -290,9 +290,9 @@ \emph default , which define an address range that is picked up by default if no other resource claims it. - + \emph on - Subtractive address ranges +Subtractive address ranges \emph default are typically used for legacy PC address ranges. @@ -734,7 +734,7 @@ It is actually included in the stage0_*.S file; but we maintain a distinction in the stage nomenclature for now. This code sets up cache-as-ram, zeros a memory area, sets up a stack, and - then calls Stage 1. + then calls stage 1. \end_layout @@ -758,16 +758,56 @@ Stage 1: C, in arch/{architecture} \end_layout +\begin_layout Standard +Initial entry point for stage 1 is arch/{architecture}/stage1.c:stage1_main(). +\end_layout + +\begin_layout Standard +printk() may be used from anywhere in C code, but it will output characters + only after the welcome banner has been printed. +\end_layout + \begin_layout Enumerate -Preboot hardware, as from auto.c (C) +POST(0x02). + (C) \end_layout \begin_layout Enumerate -Decide whether we can proceed or must recover from serial port. +Stop secondary processors. (C) \end_layout \begin_layout Enumerate +Preboot hardware, as from auto.c (C). + hardware_stage1() +\end_layout + +\begin_layout Enumerate +Initialize serial port. + (C) +\end_layout + +\begin_layout Enumerate +Initialize USB debug port. + (C) +\end_layout + +\begin_layout Enumerate +Print welcome banner to celebrate working printk() output. + (C) +\end_layout + +\begin_layout Enumerate +Enable ROM. + (C) +\end_layout + +\begin_layout Enumerate +Decide whether we can proceed or must recover from serial port. + Criteria? (C) +\end_layout + +\begin_layout Enumerate Checksum the top flash \begin_inset Quotes eld \end_inset @@ -778,7 +818,7 @@ , if it is bad then ... recover from serial port (C, PIC). - We can definitely reflash CPIO archive, but NOTE: reflashing the boot block + We can definitely reflash LAR archive, but NOTE: reflashing the boot block is tricky ... (C) \end_layout @@ -791,16 +831,39 @@ \begin_inset Quotes eld \end_inset -fallback', etc.) (C) +fallback', etc.). + (C) \end_layout \begin_layout Enumerate -In that directory, need 'initram', 'payload.ext', and others. - make sure that in '/', there is a decompressor of the right type for each - extension needed. +In that directory, execute 'initram'. + If that fails, execute 'initram' in any other directory. + If that fails as well, recover from serial port. + (C, PIC) +\end_layout + +\begin_layout Enumerate +Make sure that in '/', there is a decompressor for each compression type + used. (C) \end_layout +\begin_layout Enumerate +In the directory named by the boot type, execute 'stage2'. + (C) +\end_layout + +\begin_layout Enumerate +In that directory, look for a file 'payload', and load all of 'payload/segment%d +'. + (C) +\end_layout + +\begin_layout Enumerate +Jump to the entry point of 'payload/segment0'. + (C) +\end_layout + \begin_layout Subsection Stage 2: Device tree \end_layout @@ -834,13 +897,11 @@ \end_layout \begin_layout Subparagraph* -Phase 1 -- making printk work +Phase 1 -- very early setup \end_layout \begin_layout Standard -These are any functions that are required to make printk operational. - No other code should be run in Phase 1. - +This phase existed to make printk work and has been obsoleted. \end_layout \begin_layout Standard @@ -867,8 +928,6 @@ \begin_layout Standard These are functions that are required before any PCI operations of any kind are run. - These functions may call printk. - \end_layout \begin_layout Standard @@ -1650,9 +1709,9 @@ \begin_layout Standard In our opinion, this is asking for trouble. We currently, in the superio code, can catch stupid errors in usage that - would be lost were we to go to this + would be lost were we to go to this \family sans - void * based approach. +void * based approach. In fact, we can argue that we ought to be adding stronger type checking to the tree, not taking it away. As of this version of the document, the handling of the superio is not @@ -2445,9 +2504,9 @@ This file is only used for the southbridge part, so, following LinuxBIOS include rules, cs5536.h does not go in include; rather, it goes in the \family typewriter -southbridge/amd/cs5536 +southbridge/amd/cs5536 \family default -directory. + directory. We fix the includes so that they have proper names, and add Doxygen comments, which as of June 1, 2007, are required for all commits. Also, all functions save smbus_read_byte are static, as only that one function @@ -2474,10 +2533,6 @@ \end_layout \begin_layout Standard - -\end_layout - -\begin_layout Standard Now it is time to fix the compilation errors. First, we need to get the pll_reset.c function from V2. This function requires few changes.

2 2

[LinuxBIOS] r511 - LinuxBIOSv3/doc/design
by svn＠openbios.org 17 Nov '07

17 Nov '07

Author: hailfinger Date: 2007-11-17 16:28:02 +0100 (Sat, 17 Nov 2007) New Revision: 511 Modified: LinuxBIOSv3/doc/design/newboot.lyx Log: Update the design doc to match a mixture of wishful thinking and reality. * We use LAR and not CPIO * printk() can be called from stage 1 without ill effects * stage 2 phase 1 is without purpose Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Ronald G. Minnich <rminnich(a)gmail.com> Modified: LinuxBIOSv3/doc/design/newboot.lyx =================================================================== --- LinuxBIOSv3/doc/design/newboot.lyx 2007-11-16 11:17:57 UTC (rev 510) +++ LinuxBIOSv3/doc/design/newboot.lyx 2007-11-17 15:28:02 UTC (rev 511) @@ -85,7 +85,7 @@ \begin_layout Standard The new LinuxBIOS boot architecture depends on CAR, with payloads appearing - as files in a CPIO archive. + as files in a LAR archive. The device tree is defined by a device tree blob (DTB) and all the activities flow from that. For now, the DTC will produce a standard LinuxBIOS v2 device tree; this @@ -150,7 +150,7 @@ is the layout of the whole FLASH. Note that we can kill the buildrom tool, since the FLASH code is now a - CPIO archive. + LAR archive. Note that the linker script will now be very simple. The initram is roughly what is in auto.c, although the early hardware setup from auto.c is now in the pre-initram, so that we have serial output and @@ -162,7 +162,7 @@ etc. The DTB can be modified by the flashrom tool, and hence a platform can be customized from a binary FLASH image. - Each CPIO file has a checksum attached to the end, so that the system can + Each LAR file has a checksum attached to the end, so that the system can verify that the data is uncorrupted. We now build at least four targets for a platform: \end_layout @@ -290,9 +290,9 @@ \emph default , which define an address range that is picked up by default if no other resource claims it. - + \emph on - Subtractive address ranges +Subtractive address ranges \emph default are typically used for legacy PC address ranges. @@ -734,7 +734,7 @@ It is actually included in the stage0_*.S file; but we maintain a distinction in the stage nomenclature for now. This code sets up cache-as-ram, zeros a memory area, sets up a stack, and - then calls Stage 1. + then calls stage 1. \end_layout @@ -758,16 +758,56 @@ Stage 1: C, in arch/{architecture} \end_layout +\begin_layout Standard +Initial entry point for stage 1 is arch/{architecture}/stage1.c:stage1_main(). +\end_layout + +\begin_layout Standard +printk() may be used from anywhere in C code, but it will output characters + only after the welcome banner has been printed. +\end_layout + \begin_layout Enumerate -Preboot hardware, as from auto.c (C) +POST(0x02). + (C) \end_layout \begin_layout Enumerate -Decide whether we can proceed or must recover from serial port. +Stop secondary processors. (C) \end_layout \begin_layout Enumerate +Preboot hardware, as from auto.c (C). + hardware_stage1() +\end_layout + +\begin_layout Enumerate +Initialize serial port. + (C) +\end_layout + +\begin_layout Enumerate +Initialize USB debug port. + (C) +\end_layout + +\begin_layout Enumerate +Print welcome banner to celebrate working printk() output. + (C) +\end_layout + +\begin_layout Enumerate +Enable ROM. + (C) +\end_layout + +\begin_layout Enumerate +Decide whether we can proceed or must recover from serial port. + Criteria? (C) +\end_layout + +\begin_layout Enumerate Checksum the top flash \begin_inset Quotes eld \end_inset @@ -778,7 +818,7 @@ , if it is bad then ... recover from serial port (C, PIC). - We can definitely reflash CPIO archive, but NOTE: reflashing the boot block + We can definitely reflash LAR archive, but NOTE: reflashing the boot block is tricky ... (C) \end_layout @@ -791,16 +831,39 @@ \begin_inset Quotes eld \end_inset -fallback', etc.) (C) +fallback', etc.). + (C) \end_layout \begin_layout Enumerate -In that directory, need 'initram', 'payload.ext', and others. - make sure that in '/', there is a decompressor of the right type for each - extension needed. +In that directory, execute 'initram'. + If that fails, execute 'initram' in any other directory. + If that fails as well, recover from serial port. + (C, PIC) +\end_layout + +\begin_layout Enumerate +Make sure that in '/', there is a decompressor for each compression type + used. (C) \end_layout +\begin_layout Enumerate +In the directory named by the boot type, execute 'stage2'. + (C) +\end_layout + +\begin_layout Enumerate +In that directory, look for a file 'payload', and load all of 'payload/segment%d +'. + (C) +\end_layout + +\begin_layout Enumerate +Jump to the entry point of 'payload/segment0'. + (C) +\end_layout + \begin_layout Subsection Stage 2: Device tree \end_layout @@ -834,13 +897,11 @@ \end_layout \begin_layout Subparagraph* -Phase 1 -- making printk work +Phase 1 -- very early setup \end_layout \begin_layout Standard -These are any functions that are required to make printk operational. - No other code should be run in Phase 1. - +This phase existed to make printk work and has been obsoleted. \end_layout \begin_layout Standard @@ -867,8 +928,6 @@ \begin_layout Standard These are functions that are required before any PCI operations of any kind are run. - These functions may call printk. - \end_layout \begin_layout Standard @@ -1650,9 +1709,9 @@ \begin_layout Standard In our opinion, this is asking for trouble. We currently, in the superio code, can catch stupid errors in usage that - would be lost were we to go to this + would be lost were we to go to this \family sans - void * based approach. +void * based approach. In fact, we can argue that we ought to be adding stronger type checking to the tree, not taking it away. As of this version of the document, the handling of the superio is not @@ -2445,9 +2504,9 @@ This file is only used for the southbridge part, so, following LinuxBIOS include rules, cs5536.h does not go in include; rather, it goes in the \family typewriter -southbridge/amd/cs5536 +southbridge/amd/cs5536 \family default -directory. + directory. We fix the includes so that they have proper names, and add Doxygen comments, which as of June 1, 2007, are required for all commits. Also, all functions save smbus_read_byte are static, as only that one function @@ -2474,10 +2533,6 @@ \end_layout \begin_layout Standard - -\end_layout - -\begin_layout Standard Now it is time to fix the compilation errors. First, we need to get the pll_reset.c function from V2. This function requires few changes.

1 0

[LinuxBIOS] 1MB ROM for GA-M57SLI-S4 (PLCC32)?
by Andreas B. Mundt 17 Nov '07

17 Nov '07

Hi all, I've got a Gigabyte GA-M57SLI-S4 board (PLCC32 version) with LB running and would like to use a larger BIOS ROM to use LAB etc.. Currently my 512KB ROM chip is (from flashrom): SST49LF040B found at physical address 0xfff80000. Flash part is SST49LF040B (512 KB). Can I use a larger chip and if yes which one? Any experience appreciated. Thanks, Andi

2 1

[LinuxBIOS] just for fun
by ron minnich 17 Nov '07

17 Nov '07

http://www.vibelights.com/elwirebyfoot.html ron

1 0

← Newer
1
...
18
19
20
21
22
23
24
...
40
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2007