coreboot September 2008

coreboot@coreboot.org

59 participants
415 discussions

#109: flash base autodetection on AMD SC520
by coreboot 03 Dec '08

03 Dec '08

#109: flash base autodetection on AMD SC520 ----------------------------------+----------------------------------------- Reporter: stepan | Owner: stepan Type: defect | Status: new Priority: major | Milestone: Component: adlo | Version: v2 Keywords: | Dependencies: Patchstatus: patch needs review | ----------------------------------+----------------------------------------- this code has been sitting on my hard disk for a while. It drops the nasty ifdefs and implements auto detection for AMD SC520 systems, such as the Technologic Systems TS5300. -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/109> coreboot <http://www.coreboot.org/>

1 4

[LinuxBIOS] A8N5X port
by Robert Millan 21 Nov '08

21 Nov '08

This patch includes config files for the asus/a8n5x port. It is the same as asus/a8n_e with a different pnp layout, so I used #include's whenever possible. System boots and is usable with usb keyboard. works: - serial port - vga (old pci card) - memtest86+ succeeds, but only with Rudolf's patch for unbuffered dimms in K8. Otherwise you get spurious memory corruption. - ide disk - usb doesn't: - ps/2 keyboard - onboard ethernet - vga pci-e card (??) - any other pci card I tried wasn't tested: - sata - game port - onboard audio (not supported by alsa anyway) - ps/2 mouse -- Robert Millan <GPLv2> I know my rights; I want my phone call! <DRM> What use is a phone call, if you are unable to speak? (as seen on /.)

8 27

[PATCH 2/2] bayou: adjust color pairs
by Ulf Jordan 08 Nov '08

08 Nov '08

Hello! Atttached is a patch that will restore blue background and bright yellow menu title in Bayou v0.3, after (if) the tinycurses VGA color correction patch is applied (see an earlier thread started today). Build and run tested under QEMU with bayou-0.3+coreboot-v3. /ulf

2 3

[PATCH 1/2] bayou: use ACS for line drawing
by Ulf Jordan 07 Nov '08

07 Nov '08

Hello! Attached is a patch to update Bayou v0.3 to use ACS_ macros for the line drawing characters in the menu window border. Build and run tested under QEMU with bayou-0.3+coreboot-v3. /ulf

2 2

what are ELF boot notes?
by Robert Millan 04 Nov '08

04 Nov '08

Hi, Does anyone know what "ELF boot notes" are? I've seen this reference in coreboot-v2/src/arch/i386/boot/boot.c. There's a struct named elf_boot_notes whose pointer is passed to the payload via %ebx, and a magic signature in %eax as well. Which is very similar to Multiboot (possibly inspired by it?), as it uses the same registers and is therefore impossible to support both things at the same time. This interface is not in v3. Does this mean it's no longer being used? If it's still in use with v2, I could add a build option that selects between them. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all."

3 6

[v2][patch] update k8 fid/vid setup
by Marc Jones 03 Nov '08

03 Nov '08

See attached patch. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones@amd.com http://www.amd.com/embeddedprocessors Update K8 FID/VID setup. Add support for 100MHz FIDs (revG). Signed-off-by: Marc Jones <marc.jones(a)amd.com> Index: coreboot-v2/src/cpu/amd/model_fxx/fidvid.c =================================================================== --- coreboot-v2.orig/src/cpu/amd/model_fxx/fidvid.c 2008-08-22 07:38:01.000000000 -0600 +++ coreboot-v2/src/cpu/amd/model_fxx/fidvid.c 2008-08-22 13:08:15.000000000 -0600 @@ -99,27 +99,34 @@ static unsigned set_fidvid(unsigned apicid, unsigned fidvid, int showmessage) { - /* for (cur, new) there is one <1600MHz x8 to find out next_fid */ - static const uint8_t next_fid_a[] = { - /* x4 x5 x6 x7 x8 x9 x10 x11 x12 x13 x14 x15 */ -/* x4 */ 0, 9, 9, 8, 9, 9, 9, 9, 9, 9, 9, 9, -/* x5 */ 9, 0, 11, 11, 9, 9, 10, 11, 11, 11, 11, 11, -/* x6 */ 11, 11, 0, 13, 11, 11, 11, 11, 12, 13, 13, 13, -/* x7 */ 13, 13, 13, 0, 13, 13, 13, 13, 13, 13, 14, 15, -/* x8 */ 4, 9, 9, 9, 0, 9, 9, 9, 9, 9, 9, 9, -/* x9 */ 4, 5, 10, 10, 8, 0, 0, 0, 0, 0, 0, 0, -/*x10 */ 9, 5, 11, 11, 9, 0, 0, 0, 0, 0, 0, 0, -/*x11 */ 10, 5, 6, 12, 10, 0, 0, 0, 0, 0, 0, 0, -/*x12 */ 11, 11, 6, 13, 11, 0, 0, 0, 0, 0, 0, 0, -/*x13 */ 12, 12, 6, 7, 12, 0, 0, 0, 0, 0, 0, 0, -/*x14 */ 13, 13, 13, 7, 13, 0, 0, 0, 0, 0, 0, 0, -/*x15 */ 14, 14, 14, 7, 14, 0, 0, 0, 0, 0, 0, 0, -/* 0:x4, 2:x5....BASE=4, MIN=4, MAX=25, INC=2 result = (xX-BASE)*INC */ + +/* CurrentFID--> 4x(00h) 5x(02h) 6x(04h) 7x(06h) ... + * -------------------------------------- + * TargetFID | Next_FID, Next_FID, Next_FID, Next_FID ... + * | | Next_FID, Next_FID, Next_FID, Next_FID ... + * \|/ | Next_FID, Next_FID, Next_FID, Next_FID ... + */ + static const uint8_t next_fid_200[] = { +/* x4 x5 x6 x7 x8 x9 x10 x11 x12 x13 x14 x15 x16 */ +/* x4 */ 0, -1, -1, -1, 0, 0, 9, 10, 11, 12, 13, 14, 15, /* 800 */ +/* x5 */ -1, 0, -1, -1, -1, 5, 5, 5, 11, 12, 13, 14, 15, /* 1000 */ +/* x6 */ -1, -1, 0, -1, -1, -1, -1, 6, 6, 6, 13, 14, 15, /* 1200 */ +/* x7 */ -1, -1, -1, 0, -1, -1, -1, -1, -1, 7, 7, 7, 15, /* 1400 */ +/* lower table to upper table boarder (table 70 and 71 in BKDG) */ +/* x8 */ 8, -1, -1, -1, 0, 8, 9, 10, 11, 12, 13, 14, 15, /* 1600 */ +/* x9 */ 9, 9, -1, -1, 9, 0, 9, 10, 11, 12, 13, 14, 15, /* 1800 */ +/*x10 */ 9, 10, -1, -1, 9, 10, 0, 10, 11, 12, 13, 14, 15, /* 2000 */ +/*x11 */ 9, 11, 11, -1, 9, 10, 11, 0, 11, 12, 13, 14, 15, /* 2200 */ +/*x12 */ 9, 11, 12, -1, 9, 10, 11, 12, 0, 12, 13, 14, 15, /* 2400 */ +/*x13 */ 9, 11, 13, 13, 9, 10, 11, 12, 13, 0, 13, 14, 15, /* 2600 */ +/*x14 */ 9, 11, 13, 14, 9, 10, 11, 12, 13, 14, 0, 14, 15, /* 2800 */ +/*x15 */ 9, 11, 13, 15, 9, 10, 11, 12, 13, 14, 15, 0, 15, /* 3000 */ +/*x15 */ 9, 11, 13, 15, 9, 10, 11, 12, 13, 14, 15, 16, 0, /* 3200 */ }; msr_t msr; - uint32_t vid; - uint32_t fid; + uint32_t vid_new; + uint32_t fid_new; uint32_t vid_max; uint32_t fid_max; uint32_t vid_cur; @@ -140,19 +147,20 @@ return fidvid; } - fid = (fidvid >> 8) & 0x3f; - vid = (fidvid >> 16) & 0x3f; + fid_new = (fidvid >> 8) & 0x3f; + vid_new = (fidvid >> 16) & 0x3f; msr = rdmsr(0xc0010042); vid_cur = msr.hi & 0x3f; fid_cur = msr.lo & 0x3f; - if ((vid_cur==vid) && (fid_cur==fid)) + if ((vid_cur==vid_new) && (fid_cur==fid_new)) return fidvid; vid_max = (msr.hi>>(48-32)) & 0x3f; fid_max = ((msr.lo>>16) & 0x3f); /* max fid */ + #if FX_SUPPORT if (fid_max>=((25-4)*2)) { /* FX max fid is 5G */ fid_max = ((msr.lo >> 8) & 0x3f) + 5 * 2; /* max FID is min fid + 1G */ @@ -163,10 +171,20 @@ #endif /* set vid to max */ + /* TODO - make this more correct. Not a big deal for setting max... + * BKDG figure 11 + * if TargetFID > InitialFID + * TargetVID = FinalVID - RVO + * else + * if CurrentVID > FinalVID + * TargetVID = FinalVID - RVO + * else + * TargetVID = CurrentVIDD - RVO + */ msr.hi = 1; msr.lo = (vid_max << 8) | (fid_cur); #if SB_VFSMAF == 1 - msr.lo |= (1<<16); /* init changes */ + msr.lo |= (1 << 16); /* init changes */ #endif wrmsr(0xc0010041, msr); #if SB_VFSMAF == 0 @@ -181,31 +199,63 @@ } vid_cur = msr.hi & 0x3f; - steps = 8; //?? - while ((fid_cur != fid) && (steps-- > 0)) { + /* BKDG figure 12 and 13 + * if current fid is odd + * current fid -1 (next lower and even fid)(odd fid for rev G) + * if current fid in high-freq table + * while current fid < target fid + * transition to next higher fid in table + * else if target fid > VCO portal of current fid + * transition to highest portal fid in higher fid table + * while current fid < target fid + * transition to next higher fid in table + * else + * transition to target fid + */ + + steps = 8; /* max 8 steps just in case... */ + while ((fid_cur != fid_new) && (steps-- > 0)) { uint32_t fid_temp; - if ((fid_cur > (8-4)*2) && (fid> (8-4)*2)) { - if (fid_cur<fid) { - fid_temp = fid_cur + 2; - } else { + + /* If more than a 200Mhz step */ + if ((fid_cur - 2 != fid_new) && (fid_cur + 2 != fid_new)) { + /* Find the table value if it is in the table */ + if (fid_new <= 0x18) { /* 3200 max table value */ + int temp; + + temp = next_fid_200[((fid_cur/2) * 13) + (fid_new/2)]; + + if (temp > 0) + fid_temp = (temp-4) * 2; + else if (temp == 0) + fid_temp = fid_new; + else + break; /* table error */ + + } else { /* above table, step +/- 200MHz at a time */ + if (fid_cur < fid_new) + fid_temp = fid_cur + 2; + else fid_temp = fid_cur - 2; - } - } else { - /* there is one < 8, So we need to lookup the table to - * find the fid_cur */ - int temp; - temp = next_fid_a[(fid_cur/2)*12+(fid/2)]; - if (temp <= 0) break; - fid_temp = (temp-4) * 2; + } + } else { /* just do the 200Mhz step */ + fid_temp = fid_new; + } + + /* The table adjust in 200MHz increments. If the next table + * entry is higher than the requested fid we can do + * the 100MHz increment if the CPU supports it.*/ + if (cpuid_ecx(0x80000007) & (1 << 6)) { /* 100MHz? */ + if ((fid_temp > fid_new) && (fid_cur < fid_new)) + fid_temp = fid_new; } - if (fid_temp > fid_max) - break; - fid_cur = fid_temp; + if(fid_temp>fid_max) + break; /* set target fid */ - msr.hi = (100000/5); - msr.lo = (vid_cur << 8) | fid_cur; + msr.hi = 0x190; /* 2 us for AMD NPT Family 0Fh Processors */ + msr.lo = (vid_cur << 8) | fid_temp; #if SB_VFSMAF == 1 msr.lo |= (1 << 16); /* init changes */ #endif @@ -231,14 +281,24 @@ #if K8_SET_FIDVID_DEBUG == 1 if (showmessage) { - print_debug_fv_64("status msr fid, vid ", msr.hi, msr.lo); + print_debug_fv_64("status msr fid, vid ", msr.hi, msr.lo); } #endif } /* set vid to final */ + /* TODO - make this more correct. Not a big deal for setting max... + * BKDG figure 11 + * if TargetFID > InitialFID + * TargetVID = FinalVID - RVO + * else + * if CurrentVID > FinalVID + * TargetVID = FinalVID - RVO + * else + * TargetVID = CurrentVIDD - RVO + */ msr.hi = 1; - msr.lo = (vid << 8) | (fid_cur); + msr.lo = (vid_new << 8) | (fid_cur); #if SB_VFSMAF == 1 msr.lo |= (1 << 16); // init changes #endif @@ -257,10 +317,10 @@ fidvid = (vid_cur << 16) | (fid_cur << 8); if (showmessage) { - if (vid!=vid_cur) { + if (vid_new!=vid_cur) { print_err("set vid failed for apicid ="); print_err_hex8(apicidx); print_err("\r\n"); } - if (fid!=fid_cur) { + if (fid_new!=fid_cur) { print_err("set fid failed for apicid ="); print_err_hex8(apicidx); print_err("\r\n"); } }

4 14

[PATCH] flashrom: More SPI erase functions
by Carl-Daniel Hailfinger 02 Nov '08

02 Nov '08

As promised to Stefan, here's the flashrom patch I've been talking about. Add additional SPI sector erase and chip erase command functions to flashrom. Not all chips support all commands, so allow the implementer to select the matching function. Fix a layering violation in ICH SPI code to be less bad. Still not perfect, but the new code is shorter, more generic and architecturally more sound. TODO (in a separate patch): - move the generic sector erase code to spi.c - decide which erase command to use based on info about the chip - create a generic spi_erase_all_sectors function which calls the generic sector erase function Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: flashrom-spi_erase/flash.h =================================================================== --- flashrom-spi_erase/flash.h (Revision 3471) +++ flashrom-spi_erase/flash.h (Arbeitskopie) @@ -417,7 +417,10 @@ int spi_command(unsigned int writecnt, unsigned int readcnt, const unsigned char *writearr, unsigned char *readarr); void spi_write_enable(); void spi_write_disable(); +int spi_chip_erase_60(struct flashchip *flash); int spi_chip_erase_c7(struct flashchip *flash); +int spi_block_erase_52(const struct flashchip *flash, unsigned long addr); +int spi_block_erase_d8(const struct flashchip *flash, unsigned long addr); int spi_chip_write(struct flashchip *flash, uint8_t *buf); int spi_chip_read(struct flashchip *flash, uint8_t *buf); uint8_t spi_read_status_register(); Index: flashrom-spi_erase/spi.c =================================================================== --- flashrom-spi_erase/spi.c (Revision 3471) +++ flashrom-spi_erase/spi.c (Arbeitskopie) @@ -266,6 +266,22 @@ } } +int spi_chip_erase_60(struct flashchip *flash) +{ + const unsigned char cmd[JEDEC_CE_60_OUTSIZE] = {JEDEC_CE_60}; + + spi_disable_blockprotect(); + spi_write_enable(); + /* Send CE (Chip Erase) */ + spi_command(sizeof(cmd), 0, cmd, NULL); + /* Wait until the Write-In-Progress bit is cleared. + * This usually takes 1-85 s, so wait in 1 s steps. + */ + while (spi_read_status_register() & JEDEC_RDSR_BIT_WIP) + sleep(1); + return 0; +} + int spi_chip_erase_c7(struct flashchip *flash) { const unsigned char cmd[JEDEC_CE_C7_OUTSIZE] = {JEDEC_CE_C7}; @@ -282,6 +298,24 @@ return 0; } +int spi_block_erase_52(const struct flashchip *flash, unsigned long addr) +{ + unsigned char cmd[JEDEC_BE_52_OUTSIZE] = {JEDEC_BE_52}; + + cmd[1] = (addr & 0x00ff0000) >> 16; + cmd[2] = (addr & 0x0000ff00) >> 8; + cmd[3] = (addr & 0x000000ff); + spi_write_enable(); + /* Send BE (Block Erase) */ + spi_command(sizeof(cmd), 0, cmd, NULL); + /* Wait until the Write-In-Progress bit is cleared. + * This usually takes 100-4000 ms, so wait in 100 ms steps. + */ + while (spi_read_status_register() & JEDEC_RDSR_BIT_WIP) + usleep(100 * 1000); + return 0; +} + /* Block size is usually * 64k for Macronix * 32k for SST Index: flashrom-spi_erase/ichspi.c =================================================================== --- flashrom-spi_erase/ichspi.c (Revision 3471) +++ flashrom-spi_erase/ichspi.c (Arbeitskopie) @@ -452,17 +452,8 @@ static int ich_spi_erase_block(struct flashchip *flash, int offset) { - printf_debug("ich_spi_erase_block: offset=%d, sectors=%d\n", - offset, 1); - - if (run_opcode(2, curopcodes->opcode[2], offset, 0, NULL) != 0) { - printf_debug("Error erasing sector at 0x%x", offset); - return -1; - } - - printf("DONE BLOCK 0x%x\n", offset); - - return 0; + /* FIMXE: call the chip-specific spi_block_erase_XX instead. */ + return spi_block_erase_d8(flash, offset); } static int ich_spi_read_page(struct flashchip *flash, uint8_t * buf, int offset, int maxdata) -- http://www.hailfinger.org/

2 3

Re: [coreboot] r3529 - trunk/coreboot-v2/targets/tyan/s2912_fam10
by Arne Georg Gleditsch 30 Oct '08

30 Oct '08

svn(a)coreboot.org writes: > Author: stepan > Date: 2008-08-20 11:17:30 +0200 (Wed, 20 Aug 2008) > New Revision: 3529 > > Modified: > trunk/coreboot-v2/targets/tyan/s2912_fam10/Config-abuild.lb > Log: > this port seems somehow broken.. Now, is it using FAILOVER, or is it not?! Hmm. This was supposed to be more or less equivalent to the approach taken by the serengeti_cheetah_fam10 target, but I see it isn't quite... It works as it is (was), but I can have a look at it again if there are stylistic issues. I might not have exercised the abuild file, though -- what would be the recommended way of doing that so as to ensure that is in correspondence with the regular config file? -- Arne.

5 9

[PATCH] v2: Original import for mainboard msi/ms6147
by Mats Erik Andersson 27 Oct '08

27 Oct '08

Action: First import of code basis for mainboard msi/ms6147. Most files are taken unchange for chipset i440bx/i371eb, but decisive changes have gone into raminit.c and debug.c, which are thus positioned in the mainboard directory. Mainboard is booting with dynamic memory detection. Signed-by: Mats Erik Andersson <mats.andersson(a)gisladisker.org> --- My main contribution is to implement a functional detection of populated RAM slots. The code has proven its ability to detect, configure, and successfully initialize memory ranging from 16MB+16MB in one slot, up to 64MB+64MB+64MB+64MB in two slots. The mainboard has only two SDRAM slots, but the code is able to work with one to four slots. Best regards Mats Erik Andersson

4 4

brainstorm: new LPC dongle from Artec Group
by Martin-Éric Racine 26 Oct '08

26 Oct '08

Greetings, Noticing that the main community of users for Artec Group's LPC dongle has been at Coreboot, I have two announcements to make: 1) The current LPC dongle model is EOL. Some components no longer exist on the market so, after the batch we're producing this month, it's gone. 2) We're already working on a new LPC dongle to replace the current one. In conjunction with item #2 above, we are hereby giving the Coreboot community an opportunity to influence the design of this new product. While we cannot guarantee that every idea submitted will be used, we will definitely be reading all the feedback we receive. The end result will be an even better LPC dongle that serves the growing needs of the embedded hardware developer community. To compare with the current dongle design, see: http://artecgroup.myshopify.com/products/programmable-lpc-dongle Looking forward to receiving your ideas for this new LPC dongle product. Best Regards, -- Martin-Éric Racine Business Development Manager Artec Group OÜ

9 16

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot September 2008