coreboot September 2008

coreboot@coreboot.org

59 participants
415 discussions

v3 CS5536 SMBus bug
by Carl-Daniel Hailfinger 15 Sep '08

15 Sep '08

v3 can't use global variables in stage1 or initram. Same applies to static local variables. See the bug below. Ideas for fixes? The generic variable infrastructure would be one option. int smbus_read_byte(u16 device, u8 address) { //BUG here! static int first_time = 1; if (first_time) { smbus_init(); first_time = 0; } return do_smbus_read_byte(SMBUS_IO_BASE, device, address); } Regards, Carl-Daniel -- http://www.hailfinger.org/

3 7

Re: [coreboot] FILO creating filo.conf
by Joseph Smith 15 Sep '08

15 Sep '08

On Fri, 12 Sep 2008 15:37:41 +0200, Stefan Reinauer <stepan(a)coresystems.de> wrote: > I think this might be even better... > > writing to drives from firmware might be a bad idea, > Why? Even if it is simple text file? > > though... can this > be done with cmos bits? > Not sure....you would have basicly convert a kernel command line into hex and store it in cmos??? > This is why I asked you if it was possible to have a small read/write area in flash possibly at the end of the payload. > > An interesting thing would also be to parse syslinux config files and > put them in the grub menu.. these are used on basically all linux > install cds/dvds.. > Yeh I like this idea for read only media. I hope you don't mind if I forward this to the list for more opinions. -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org

7 17

v2: [RFC] Dynamic RAM detection for intel/i440bx
by Mats Erik Andersson 15 Sep '08

15 Sep '08

Hello all, I send a patch which is not intended for insertion as is, but I have to draw the line somewhere in order to get your comments. The patch alters coreboot-v2/src/northbridge/intel/i440bx/raminit.c and it implements dynamic calculation of the registers DRB#, RPS and PGPOL. It does this using alternate methods, chosen by macro switches in the beginning of the file. In order to successfully compile the new source, it is unfortunately necessary to use Romcc with optimisation "-mcpu=p2" to provide scratch registers for normal/fallback, and also "-O2" to shrink the fallback image. A script "optim.sh", that mends the makefiles, is appended to this message. I have successfully (in the sense of complete image build) done this alteration for all relevant mainboards in the source tree: abit/be6-ii_v2_0 asus/p2b asus/p2b-f asus/p3b-f a-trend/atc-6220 a-trend/atc-6240 (needs one PRINT_DEBUG less!) azza/pt-6ibd biostar/m6tba compaq/deskpro_en_sff_p600 gigabyte/ga-6bxc msi/ms6119 tyan/s1846 and for my own mainboard msi/ms6147 I can actually boot into Filo with many different combinations and positions of SDRAM devices. However, there are still some issues with timings, which lead to the strange phenomenon that one particular double sided 128 MB card in my possession, boots well enough into Filo when positioned in DIMM1, but cannot enter the second phase of Coreboot when used in DIMM0. Other 128 MB cards work in both positions. These differences are probably due to my incomplete understanding of the northbridge register MBSC, as well as the buffer strength bits in NBXCFG. Since ms6147 only has two DIMM-slots, I have not been able to test the patch for use with USE_DIMM2 or USE_DIMM3 activated. The function do_ram_command() has two outcommented work arounds in order to activate the different RAM position, but a true dynamic code has not yet been taken into consideration. I now desire other people to test this code against their mainboards, in order that we (or mainly I) could get indications as to push forward to choose one of the methods the code offers for its SPD-detection, and to provide me with more information on SDRAM timings that do not work with the present values in MBSC and NBXCFG. The values present now are _not_ the only values I have _inconclusively_ tried! I welcome all feedback. The 48 first SPD-bytes of malfunctioning SDRAM cards would be most valuable. Testers should take care to add one or more read32() inside do_ram_command() in order to perform a read in any additional memory bank. That read32() bears the sole responsibility of awakening the SDRAM chips, as this mechanism is independent of any configuration the northbridge i440bx gets from any code for dynamic detection. Best regards and with the best intents, Mats Erik Andersson

3 4

Trac reminder: list of new ticket(s)
by coreboot tracker 15 Sep '08

15 Sep '08

1 0

Combined K8 and Fam 10h CAR
by Carl-Daniel Hailfinger 14 Sep '08

14 Sep '08

Hi, I think I may have a working version of combined K8 and Fam 10h CAR code, performing a runtime selection of the right MTRR settings. This will allow us to keep Fam10h and earlier support in one image. Some verification by inspection is pending, I'll release a patch in due time. This is just a heads-up in case anybody else wanted to tackle that unification as well. Regards, Carl-Daniel -- http://www.hailfinger.org/

1 0

r3578 build service
by coreboot information 12 Sep '08

12 Sep '08

Dear coreboot readers! This is the automated build check service of coreboot. The developer "stepan" checked in revision 3578 to the coreboot source repository and caused the following changes: Change Log: * Implement scrolling in tinycurses * Fix an off by one bug Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Jordan Crouse <jordan.crouse(a)amd.com> Build Log: Compilation of jetway:j7f24 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3578&device=j7f24&vendor=j… Compilation of via:epia-cn is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3578&device=epia-cn&vendor… If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system

1 0

r3578 - trunk/payloads/libpayload/curses
by svn＠coreboot.org 12 Sep '08

12 Sep '08

Author: stepan Date: 2008-09-12 23:50:57 +0200 (Fri, 12 Sep 2008) New Revision: 3578 Modified: trunk/payloads/libpayload/curses/tinycurses.c Log: * Implement scrolling in tinycurses * Fix an off by one bug Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Jordan Crouse <jordan.crouse(a)amd.com> Modified: trunk/payloads/libpayload/curses/tinycurses.c =================================================================== --- trunk/payloads/libpayload/curses/tinycurses.c 2008-09-12 20:39:04 UTC (rev 3577) +++ trunk/payloads/libpayload/curses/tinycurses.c 2008-09-12 21:50:57 UTC (rev 3578) @@ -70,7 +70,7 @@ static struct ldat ldat_list[MAX_WINDOWS][SCREEN_Y]; static int ldat_count = 0; -/* One item bigger than SCREEN_X to reverse place for a NUL byte. */ +/* One item bigger than SCREEN_X to reserve space for a NUL byte. */ static NCURSES_CH_T linebuf_list[SCREEN_Y * MAX_WINDOWS][SCREEN_X + 1]; static int linebuf_count = 0; @@ -305,8 +305,8 @@ stdscr = newwin(SCREEN_Y, SCREEN_X + 1, 0, 0); // TODO: curscr, newscr? - for (y = 0; y < stdscr->_maxy; y++) { - for (x = 0; x < stdscr->_maxx; x++) { + for (y = 0; y <= stdscr->_maxy; y++) { + for (x = 0; x <= stdscr->_maxx; x++) { stdscr->_line[y].text[x].chars[0] = ' '; stdscr->_line[y].text[x].attr = A_NORMAL; } @@ -817,6 +817,22 @@ return ERR; if (n != 0) { + int x, y; + + for (y = 0; y <= (win->_maxy - n); y++) { + for (x = 0; x <= win->_maxx; x++) { + win->_line[y].text[x].chars[0] = win->_line[y + n].text[x].chars[0]; + win->_line[y].text[x].attr = win->_line[y + n].text[x].attr; + } + } + + for (y = (win->_maxy+1 - n); y <= win->_maxy; y++) { + for (x = 0; x <= win->_maxx; x++) { + win->_line[y].text[x].chars[0] = ' '; + win->_line[y].text[x].attr = A_NORMAL; + } + } + // _nc_scroll_window(win, n, win->_regtop, win->_regbottom, win->_nc_bkgd); // _nc_synchook(win); }

1 0

r3577 build service
by coreboot information 12 Sep '08

12 Sep '08

Dear coreboot readers! This is the automated build check service of coreboot. The developer "hawke" checked in revision 3577 to the coreboot source repository and caused the following changes: Change Log: For the jetway jf2/4 series of mainboards: * change the comment for device f.0 from "IDE" to "SATA" * turn on firewire device a.0 * turn on pata device f.1 * don't turn on the unusable device 10.5 (built-in vt8237 ethernet?) Signed-off-by: Alex Mauer <hawke(a)hawkesnest.net> Acked-by: Ronald G. Minnich <rminnich(a)gmail.com> Build Log: Compilation of jetway:j7f24 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3577&device=j7f24&vendor=j… Compilation of via:epia-cn is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3577&device=epia-cn&vendor… If something broke during this checkin please be a pain in hawke's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system

1 0

r3577 - trunk/coreboot-v2/src/mainboard/jetway/j7f24
by svn＠coreboot.org 12 Sep '08

12 Sep '08

Author: hawke Date: 2008-09-12 22:39:04 +0200 (Fri, 12 Sep 2008) New Revision: 3577 Modified: trunk/coreboot-v2/src/mainboard/jetway/j7f24/Config.lb Log: For the jetway jf2/4 series of mainboards: * change the comment for device f.0 from "IDE" to "SATA" * turn on firewire device a.0 * turn on pata device f.1 * don't turn on the unusable device 10.5 (built-in vt8237 ethernet?) Signed-off-by: Alex Mauer <hawke(a)hawkesnest.net> Acked-by: Ronald G. Minnich <rminnich(a)gmail.com> Modified: trunk/coreboot-v2/src/mainboard/jetway/j7f24/Config.lb =================================================================== --- trunk/coreboot-v2/src/mainboard/jetway/j7f24/Config.lb 2008-09-11 17:44:45 UTC (rev 3576) +++ trunk/coreboot-v2/src/mainboard/jetway/j7f24/Config.lb 2008-09-12 20:39:04 UTC (rev 3577) @@ -97,15 +97,16 @@ # Both cables are 40pin. register "ide0_80pin_cable" = "0" register "ide1_80pin_cable" = "0" - device pci f.0 on end # IDE register "fn_ctrl_lo" = "0x80" register "fn_ctrl_hi" = "0x1d" + device pci a.0 on end # Firewire + device pci f.0 on end # SATA + device pci f.1 on end # IDE device pci 10.0 on end # OHCI device pci 10.1 on end # OHCI device pci 10.2 on end # OHCI device pci 10.3 on end # OHCI device pci 10.4 on end # EHCI - device pci 10.5 on end # UDCI device pci 11.0 on # Southbridge LPC chip superio/fintek/f71805f # Super I/O device pnp 2e.0 off # Floppy

1 0

the eternal pre-post car debate in v3
by ron minnich 12 Sep '08

12 Sep '08

ok, here is one more proposal for the eternal pre/post car discussion. I hope this covers all possibilities. It will allow all current implementations to remain unchanged, which is the nice part. But it sets a few simple rules for the next CPUs, such as core 2. To recap: At some point stage1 needs to turn off CAR. The stack (which includes sysinfo and global variables) needs to be moved to RAM. We play a nice trick on Geode and K8, where there is RAM behind the CAR area: once it is time to turn off CAR, we just "push" the CAR into that RAM location, and continue as though nothing had happened. Although the K8 code is a bit more complex than this simple description, that is more or less what happens. This trick is not 100% portable. On some systems (core 2) CAR is located where there is NEVER going to be any DRAM. So, on some systems, once you disable CAR, the CAR data is gone, and so is your stack and sysinfo struct. That CAR data has to be moved to DRAM, and that data will be at a different address. My concern has been that any pointers on the stack won't survive a stack move. I don't want to get Clever and try to adjust pointers on the stack because, in the limit, you can't distinguish pointers from data. So we make a rule or two: 1. stage1 never returns. Hence there will never be an issue with stage1 returning to its caller. We need not worry about any stack being lost after stage 1 starts. 2. Stage 1 is the "outer loop". So any pointers in functions that stage1 calls don't matter. 3. in stage1, code should assume, post disable_car, that no pointers used pre disable_car are valid. So you can use pointers in stage1, you just can not share them across the disable_car boundary. Think of disable_car as a kind of "dead pointer zone" across which pointers don't survive. 4. There shall be no pointers in sysinfo. This makes sysinfo location-independent: the variables in sysinfo are valid no matter where sysinfo is locate. So, since sysinfo is location-independent, there are no issues with it being relocated as part of disable_car. Given these rules, here is how disable_car can work on core 2 and others that don't back CAR with RAM. 1. compute a new stack area. The minimum size is the size of the stack. Note that stack contains sysinfo (at its base). It is acceptable to copy only the "active" stack; it is acceptable to copy all of CAR. It is acceptable to copy more data than the "active" stack and less data than all of CAR. This flexibility makes writing disable_car easier. 2. copy the data to the new stack area in ram 3. disable CAR 4. adjust the return address on stack if needed (unlikely, since we're executing from ROM, but who knows what the future may bring) and then return. That's about it. This will work I think for core2. It requires zero changes for K8 and geode. I think we can close this discussion. We need to add comments to stage1 to explain proper pointer usage, i.e. that pointers created before disable_car is called must be adjusted or recomputed or not used after disable_car is called. ron

4 6

← Newer
1
...
26
27
28
29
30
31
32
...
42
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 September 2008