coreboot February 2009

coreboot@coreboot.org

67 participants
232 discussions

Re: [coreboot] coreboot on s4882?
by David Melik 06 Feb '09

06 Feb '09

Thanks again (Myles & everyone) for discussing coreboot for s4882 until I could compile & install. After doing so, my s4882 just has a blank screen and continually does 2 alternating beeps (like a siren.) I saw no POST codes on coreboot.org. I saved coreboot.rom and now have a Slackware pII system up (no coreboot) as well as a Windows 2.4GHz Athlon. What next? I only installed grub2 as payload; grub2 may not be the problem: IIRC, I included chainloader in grub2.elf: my '/' has LILO. Coreboot.org has 'official grub' (grub2) and 'grub2' pages, which say different things, though they likely mean the same thing. I neither want to re-flash old BIOS nor yet try coreboot on my alternate Slackware system, though I plan to after any possible functional s4882 build. Coreboot compiles within about 1 min. on 8-core a880 w/8Gb and would be relatively quick even on dual pIII. I am unsure about pII (I skipped from pI.) Does DJGPP work well on XP, or are Cygwin or MinGW like it? I have never done GUI programming--incl. 'programming on an OS requiring GUI (except in class)' and would rather not boot Windows until I learn to add it to BOINC ( http://boinc.berkeley.edu ) on a LAN. --David

2 3

CoreBoot and Payloads
by Piotr Brostovski 05 Feb '09

05 Feb '09

Hello, i have a strange problem with executing payloads under coreboot. What *do* work: - CoreBoot-V2 from SVN repository + Tint Payload or - CoreBoot-V2 from SVN repository + EtherBoot 5.2.6 or 5.4.4 Payload or - CoreBoot-V2 from SVN repository + coreinfo Payload I can even use the coreinfo.elf or tint.elf as bootfile with "normal" clients which only have a gPXE rom. But i can't use a linux kernel as a NBI or ELF image with etherboot 5.2.6 or 5.4.4. I used the tools mknbi and wraplinux for making an NBI or elf image from the kernel. I also tried to make an NBI image from a working gPXE.lkrn image. I make everything exactly as described here: http://markmail.org/message/ncdrofxylpofgl5m?q=nbi+gpxe especially -> wraplinux -N gpxe.lkrn > gpxe.nbi Neither a kernel NBI image or a gpxe NBI image do work. The gpxe.lkrn works perfectly from grub or PXE Bootmenu. As current gpxe version doesn't compile as a compatible payload for coreboot i have to use etherboot 5.4.4 which can only load NBI or ELF images. So i wanted to use the etherboot payload in coreboot as a chainloader for a gpxe elf/nbi image. But, it doesn't work. The gpxe.nbi image doesn't work as a coreboot payload, neither as a loadable image for a normal client with a gpxe rom loader, like tint.elf or coreinfo.elf do. Coreboot and gPXE loads the NBI file, printing "... ok, rhine disable" - and hang - no further output on screen or serial console. The Hardware is a bcom-winnet-p680. (Via C7 CPU and Chipset + Via VT6102 [Rhine-II] 1106:3065 Do anyone have an idea why this doesn't work? -- Regards, Piotr

8 23

Bridge Mem Window/Prefetch Window
by Dan Lykowski 05 Feb '09

05 Feb '09

Can anyone point me in the right direction as to where the Bridge Mem Window/Prefetch Window PCI configurations are defined/setup/used/etc. Coreboot does not set these correctly in my case. ( As compared to the standard BIOS ) Thanks, Dan Lykowski

3 4

780/700 Documentation
by Bao, Zheng 05 Feb '09

05 Feb '09

Hi, All, We have been working on the RS780/SB700 for about 2 weeks. Before we can submit our code, we realized that it doesn't make sense if the documentation is not available. We can get the datasheet as an AMD engineer. How can the developer in Coreboot.org get? Do we need any official procedure to make the document public? Joe

3 2

libpayload/libc/memory.c copied from buggy HelenOS code
by Jiri Svoboda 05 Feb '09

05 Feb '09

Hi there folks, my name is Jiri Svoboda, of HelenOS project. While it delights us that Coreboot makes use of some of our code, I'd like to warn you that the memxxx() operations in libpayload/libc/memory.c you copied from the HelenOS C library are terribly flawed. They have been fixed in HelenOS since. So I'd suggest either syncing with our code or re-writing them or something. More specifically: memmove() - this is completely wrong. It will fail when moving by less than 4 bytes. memcpy() and memmove() - both will only work on word-aligned blocks on non-Intel platforms (this may not be a concern to you) If you don't care about non-Intel, the easiest way would be to copy a recent version of memmove() from our trunk and that should do the trick - remove the problem when moving by less than word size. Note that I'm not on this mailing list. If you want to reach me, Cc me. Cheers, Jiri

1 0

Re: [coreboot] SB600 HDA can't find codec fix
by Dan Lykowski 04 Feb '09

04 Feb '09

Maggie, Oops, I can't convert binary to hex.. 7 should have been 15. and it should have been bits [3..0]. Is this what you are referring to? I don't understand what you mean by pci_locate_device is only used during early setup. I see it called in the SATA driver to find the SMBus. Is this incorrect also? What would be the best way to get the SMBus? Is the device being stored somewhere that I don't currently see? Thanks, Dan Lykowski --- On Sun, 2/1/09, Li, Maggie <Maggie.Li(a)amd.com> wrote: From: Li, Maggie <Maggie.Li(a)amd.com> Subject: Re: [coreboot] SB600 HDA can't find codec fix To: "Dan Lykowski" <engineerguy3737(a)yahoo.com> Cc: "Marc Jones" <marcj303(a)gmail.com>, "Carl-Daniel Hailfinger" <c-d.hailfinger.devel.2006(a)gmx.net>, coreboot(a)coreboot.org Date: Sunday, February 1, 2009, 3:28 AM Hi, Dan I have tested your patch on my dbm690t (ALC882) and pistachio (ALC885) board. It really works. However, I have a suggestion for you. /* Read in Codec location (BAR + 0xe)[2..0]*/ dword = readl(base + 0xe); dword &= 7; if (!dword) goto no_codec; The above phrase is not correct all the time, at lease to my pistachio board. It will give me the wrong msg "No codec!". I would appreciate and ack the patch if you can modify it. BTW, pci_locate_device is only used in early setup stage. So, you can remove it. Best regards Maggie li -----Original Message----- From: coreboot-bounces(a)coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Marc Jones Sent: Thursday, January 29, 2009 1:10 PM To: Dan Lykowski Cc: Carl-Daniel Hailfinger; coreboot(a)coreboot.org Subject: Re: [coreboot] SB600 HDA can't find codec fix On Tue, Jan 27, 2009 at 11:07 AM, Dan Lykowski <engineerguy3737(a)yahoo.com> wrote: > Diff was being silly and I wanted to get the patch posted before I left work > for the day. I've cleaned up the patch and included it. > > I wasn't able to find where INTA was used so I used what the RPR lists as > default. INTG. After looking at the mptable, I agree INTA is the correct > answer. I've corrected it. I used dev_find_slot because I copied from the > SATA driver. I've added the comment just like the SATA driver has. I don't > know what the difference is, or why the SATA driver did this. > > The reordering was based on what order things happen in the BIOS Developers > guide, RPR, and SATA driver. I fixed the order of the devices that didn't > matter to clean up the change log. > 1. Enable the Chip > 2. Setup the SMBus registers > 3. Setup the Device Registers > 4. Look for Codec > 5. Init Codec > > The codec init was changed to match the description in the RRG pg 235. > Mem Reg: Base + 08h Bit 0. There were unneeded things happening. > So here is the second try. > > Thanks, > Dan Lykowski > > Signed-off-by: Dan Lykowski <lykowdk(a)gmail.com> This looks good to me. The hda_init looks like it was writing to the wrong device for the interrupt line setup. It would be good if the the AMD guys or Carl-Daniel can test and ack it. Marc -- coreboot mailing list: coreboot(a)coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot(a)coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

4 10

r3930 - trunk/coreboot-v2/src/southbridge/amd/sb600
by svn＠coreboot.org 04 Feb '09

04 Feb '09

Author: hailfinger Date: 2009-02-05 03:18:42 +0100 (Thu, 05 Feb 2009) New Revision: 3930 Modified: trunk/coreboot-v2/src/southbridge/amd/sb600/sb600_hda.c Log: Use the correct device for switching on HDA. Reorder HDA (HD Audio) init: The reordering was based on what order things happen in the BIOS Developers guide, RPR, and SATA driver. I fixed the order of the devices that didn't matter to clean up the change log. 1. Enable the Chip 2. Setup the SMBus registers 3. Setup the Device Registers 4. Look for Codec 5. Init Codec The codec init was changed to match the description in the RRG pg 235. Mem Reg: Base + 08h Bit 0. There were unneeded things happening. Added 1ms delay to match the BKDG while waiting for BAR+0xe to set its bits. Signed-off-by: Dan Lykowski <lykowdk(a)gmail.com> Tested on AMD DBM690T and AMD Pistachio by Maggie Li. Works. Tested on Asus M2A-VM by Carl-Daniel Hailfinger. Improves the situation, but some warnings remain. Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/coreboot-v2/src/southbridge/amd/sb600/sb600_hda.c =================================================================== --- trunk/coreboot-v2/src/southbridge/amd/sb600/sb600_hda.c 2009-02-03 22:37:22 UTC (rev 3929) +++ trunk/coreboot-v2/src/southbridge/amd/sb600/sb600_hda.c 2009-02-05 02:18:42 UTC (rev 3930) @@ -35,23 +35,27 @@ u32 dword; int count; + /* Write (val & ~mask) to port */ val &= mask; dword = readl(port); dword &= ~mask; dword |= val; writel(dword, port); + /* Wait for readback of register to + * match what was just written to it + */ count = 50; do { + /* Wait 1ms based on BKDG wait time */ + mdelay(1); dword = readl(port); dword &= mask; - udelay(100); } while ((dword != val) && --count); + /* Timeout occured */ if (!count) return -1; - - udelay(540); return 0; } @@ -59,32 +63,31 @@ { u32 dword; - /* 1 */ - set_bits(base + 0x08, 1, 1); + /* Set Bit0 to 0 to enter reset state (BAR + 0x8)[0] */ + if (set_bits(base + 0x08, 1, 0) == -1) + goto no_codec; - /* 2 */ - dword = readl(base + 0x0e); - dword |= 7; - writel(dword, base + 0x0e); + /* Set Bit 0 to 1 to exit reset state (BAR + 0x8)[0] */ + if (set_bits(base + 0x08, 1, 1) == -1) + goto no_codec; - /* 3 */ - set_bits(base + 0x08, 1, 0); + /* Delay for 1 ms since the BKDG does */ + mdelay(1); - /* 4 */ - set_bits(base + 0x08, 1, 1); - - /* 5 */ + /* Read in Codec location (BAR + 0xe)[3..0]*/ dword = readl(base + 0xe); - dword &= 7; - - /* 6 */ - if (!dword) { - set_bits(base + 0x08, 1, 0); - printk_debug("No codec!\n"); - return 0; - } + dword &= 0x0F; + if (!dword) + goto no_codec; + return dword; +no_codec: + /* Codec Not found */ + /* Put HDA back in reset (BAR + 0x8) [0] */ + set_bits(base + 0x08, 1, 0); + printk_debug("No codec!\n"); + return 0; } static u32 cim_verb_data[] = { @@ -262,20 +265,38 @@ static void hda_init(struct device *dev) { + u8 byte; + u32 dword; u8 *base; struct resource *res; u32 codec_mask; + device_t sm_dev; + + /* Enable azalia - PM_io 0x59[4], disable ac97 - PM_io 0x59[1..0] */ + pm_iowrite(0x59, 0xB); + + /* Find the SMBus */ + /* FIXME: Need to find out why the call below crashes. */ + /*sm_dev = dev_find_device(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_ATI_SB600_SM, 0);*/ + sm_dev = dev_find_slot(0, PCI_DEVFN(0x14, 0)); - /* SM Setting */ + /* Set routing pin - SMBus ExtFunc (0xf8/0xfc) */ + pci_write_config32(sm_dev, 0xf8, 0x00); + pci_write_config8(sm_dev, 0xfc, 0xAA); + /* Set INTA - SMBus 0x63 [2..0] */ + byte = pci_read_config8(sm_dev, 0x63); + byte &= ~0x7; + byte |= 0x0; /* INTA:0x0 - INTH:0x7 */ + pci_write_config8(sm_dev, 0x63, byte); - /* Set routing pin */ - pci_write_config32(dev, 0xf8, 0x0); - pci_write_config8(dev, 0xfc, 0xAA); - /* Set INTA */ - pci_write_config8(dev, 0x63, 0x0); - /* Enable azalia, disable ac97 */ - pm_iowrite(0x59, 0xB); + /* Program the 2C to 0x437b1002 */ + dword = 0x437b1002; + pci_write_config32(dev, 0x2c, dword); + /* Read in BAR */ + /* Is this right? HDA allows for a 64-bit BAR + * but this is only setup for a 32-bit one + */ res = find_resource(dev, 0x10); if (!res) return;

1 0

flashrom doesn't work on asus P5K-E wifi, ICH9-R
by blink＠nm.ru 04 Feb '09

04 Feb '09

Hello! Is it normal or am I doing something wrong? Log: addr-75:~/coreboot-v3/util/flashrom # ./flashrom -w -v P5K-E-1102.ROM Calibrating delay loop... OK. No coreboot table found. Found chipset "Intel ICH9R", enabling flash write... OK. Found chip "SST SST25VF016B" (2048 KB) at physical address 0xffe00000. Flash image seems to be a legacy BIOS. Disabling checks. Programming page: Verifying flash... FAILED at 0x0006e9a4! Expected=0x84, Read=0x78 addr-75:~/coreboot-v3/util/flashrom # ./flashrom -w -v P5K-E-1202.ROM Calibrating delay loop... OK. No coreboot table found. Found chipset "Intel ICH9R", enabling flash write... OK. Found chip "SST SST25VF016B" (2048 KB) at physical address 0xffe00000. Flash image seems to be a legacy BIOS. Disabling checks. Programming page: Verifying flash... FAILED at 0x001dc000! Expected=0xff, Read=0x05 addr-75:~/coreboot-v3/util/flashrom # ./flashrom -w -v bios.bin Calibrating delay loop... OK. No coreboot table found. Found chipset "Intel ICH9R", enabling flash write... OK. Found chip "SST SST25VF016B" (2048 KB) at physical address 0xffe00000. Flash image seems to be a legacy BIOS. Disabling checks. Programming page: Verifying flash... FAILED at 0x00000000! Expected=0x4c, Read=0x41 addr-75:~/coreboot-v3/util/flashrom # ./flashrom -w -v bios.bin Calibrating delay loop... OK. No coreboot table found. Found chipset "Intel ICH9R", enabling flash write... OK. Found chip "SST SST25VF016B" (2048 KB) at physical address 0xffe00000. Flash image seems to be a legacy BIOS. Disabling checks. Programming page: Verifying flash... FAILED at 0x00000000! Expected=0x4c, Read=0x41 addr-75:~/coreboot-v3/util/flashrom # ./flashrom -w -v last.rom Calibrating delay loop... OK. No coreboot table found. Found chipset "Intel ICH9R", enabling flash write... OK. Found chip "SST SST25VF016B" (2048 KB) at physical address 0xffe00000. Flash image seems to be a legacy BIOS. Disabling checks. Programming page: Verifying flash... VERIFIED. (I've read it by flashrom -r) addr-75:~/coreboot-v3/util/flashrom # ./flashrom -E Calibrating delay loop... OK. No coreboot table found. Found chipset "Intel ICH9R", enabling flash write... OK. Found chip "SST SST25VF016B" (2048 KB) at physical address 0xffe00000. Erasing flash chip... FAILED! ERROR at 0x00000000: Expected=0xff, Read=0x41 addr-75:~/coreboot-v3/util/flashrom # addr-75:~/coreboot-v3/util/flashrom # ./flashrom -w -v P5K-E-1102.ROM Calibrating delay loop... OK. No coreboot table found. Found chipset "Intel ICH9R", enabling flash write... OK. Found chip "SST SST25VF016B" (2048 KB) at physical address 0xffe00000. Flash image seems to be a legacy BIOS. Disabling checks. Programming page: Verifying flash... FAILED at 0x0006e9a4! Expected=0x84, Read=0x78 Thanks in advace, JonB

2 1

VIA pc2500e for a start ?
by Bandan Das 04 Feb '09

04 Feb '09

Hello everybody, I have been playing around with coreboot on qemu for a while. I am on the lookout for a cheap development board to try coreboot on some real hardware and stumbled upon the VIA pc2500e mainboard (http://www.via.com.tw/en/initiatives/empowered/pc2500_mainboard/index.jsp). It has initial support with coreboot -v2 and I can find some cheap ones for sale on ebay. Is this a good board to start hacking with ? Can someone suggest some other sources to check out evaluation boards ? I also saw clubit.com mentioned in a lot of posts, but that site seems to exist no more. Thanks, Bandan -- BSD

2 2

Re: [coreboot] coreboot Digest, Vol 48, Issue 13
by David Melik 04 Feb '09

04 Feb '09

> > > I did that, then did not see Opterons listed in it or on > > > coreboot.org/buildrom/. > > ? > The current buildrom just seems to omit Opteron 800 (or any) series, and that link omits s4882 from 'supported boards.' > > > I thought I read in the archives that someone patched coreboot for s4882[...] > > It should still work. Here's what I did. > > cd coreboot/svn/targets > ./buildtarget tyan/s4882/ > make -C tyan/s4882/s4882/ > > make[1]: *** No rule to make target > `../../../../payloads/tg3--filo_hda2_vga.zelf', needed by `payload'. Stop. > > // Same error you got. > > gvim tyan/s4882/Config.lb > change ../../../../payloads/tg3--filo_hda2_vga.zelf to ../grub2.elf > > cp ../../../../deploy/grub2-payload.elf tyan/s4882/s4882/grub2.elf > make -C tyan/s4882/s4882/ > > ERROR: payload (206476) + coreboot (131072) - Size is 124556 bytes larger > than ROM size (212992). > make[1]: *** [coreboot.rom] Error 1 > > // Different error, but important. > /* It's configured to have two images in the ROM and there isn't enough > space for two copies of grub2+coreboot. If fallback is really important to > you, you can start using compression, but lets get something working for you > first. */ > > gvim tyan/s4882/Config.lb > > gvim tyan/s4882/Config.lb > > -------------SNIP ---------------- > # Sample config file for > # the Tyan s4882 > # This will make a target directory of ./s4882 > > target s4882 > mainboard tyan/s4882 > > romimage "fallback" > option USE_FALLBACK_IMAGE=1 > option FALLBACK_SIZE=ROM_SIZE > option ROM_IMAGE_SIZE=0x20000 > option XIP_ROM_SIZE=0x20000 > option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" > payload ../grub2.elf > end > > buildrom ./coreboot.rom ROM_SIZE "fallback" > > -------------SNIP ---------------- > > make -C tyan/s4882/s4882/ > > That should work. Let me know. Exact error messages and what you type will > help us help you. > > Thanks, > Myles Great! It appeared to work, but I am unsure if I will test it today or in few/one day(s) after I upgrade with slamd64-12.2-dvd.iso (downloading.) So, how hard is it to build coreboot for unsupported boards? I have 15 - 20 boards around, incl. a few working (mostly '90s:) perhaps I should try others if I wait for my OS download.... --David

2 1

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 February 2009