coreboot December 2006

coreboot@coreboot.org

68 participants
183 discussions

Re: [LinuxBIOS] [RFC][PATCH 2/2] x86_64: earlyprintk usb debug device support.
by Lu, Yinghai 05 Dec '06

05 Dec '06

-----Original Message----- From: ebiederm(a)xmission.com [mailto:ebiederm@xmission.com] >arch/x86_64/kernel/early_printk.c | 574 +++++++++++++++++++++++++++++++++++++ > drivers/usb/host/ehci.h | 8 + > include/asm-x86_64/fixmap.h | 1 Can you separate usbdebug handle out from early_printk? So We can share the code in LinuxBIOS easier. I like the version like usbdebug_direct.c. Also separate related USB debug port defines in one separate header file too. YH

3 3

[LinuxBIOS] confusion about enabling resources
by Jon Dufresne 04 Dec '06

04 Dec '06

My ram initialization appears to work, at least enough to get me out of the romcc section. I am having quite a bit of difficulty getting the bios to run smoothly though. I am currently stuck somewhere either in filo or somewhere in elfboot. I think (once again) this has to do with the way LinuxBIOS understands the ram, and me not properly giving it the information it needs. As of right now if I put in code that looks more correct to me, the BIOS dies earlier than if I put in code that looks less correct. I'm guess that it is a lucky coincidence the less correct code works better, but it could be that I don't understand what is happening. In src/northbridge/intel/i855gm/northbridge.c (This northbridge isn't in the main tree but is based off of i855pm) I have see the following, mc_dev = dev->link[0].children; Which I've deduced will give me the PCI device 0:0.0, which is NOT the MCH for my northbridge. This is used by the line that says tomk = ((unsigned long)pci_read_config8(mc_dev, 0x63)) << 15; this will give tomk a value of 0, since that happens to always be in that register. Obviously I have more than 0 KiB of ram. To give what I think is the more correct value I modify it to say mc_dev = dev->link[0].children->sibling; This will give it the PCI device 0:0.1, which is the MCH. I then modify the read so it says tomk = ((unsigned long)pci_read_config8(mc_dev, 0x43)) << 15; which is the correct register holding the top of the memory (the shift just puts it into KiB). Now without my modifications the BIOS makes it into filo and can do some stuff before dying. With my modifications it dies within elfboot. With these statements at the end of the log: Jumping to boot code at 0x10af40 entry = 0x0010af40 lb_start = 0x00004000 lb_size = 0x00014000 adjust = 0x3ffe8000 buffer = 0x3ffd8000 elf_boot_notes = 0x0000eb80 adjusted_boot_notes = 0x3fff6b80 In the unmodified form these log statements look like Jumping to boot code at 0x10af40 entry = 0x0010af40 lb_start = 0x00004000 lb_size = 0x00014000 adjust = 0xfffe8000 buffer = 0xfffd8000 elf_boot_notes = 0x0000ec00 adjusted_boot_notes = 0xffff6c00 I am at a loss for what is going wrong here and would appreciate any insight that anyone has. Below is the unmodified form of the function. I commented out the pci_write's because those registers are not documented in my datasheet, nor is there any mention of low memory. Thanks for any help! static void pci_domain_set_resources(device_t dev) { device_t mc_dev; uint32_t pci_tolm; pci_tolm = find_pci_tolm(&dev->link[0]); mc_dev = dev->link[0].children; printk_debug("MC dev vid = %x\n", mc_dev->vendor); printk_debug("MC dev did = %x\n", mc_dev->device); if (mc_dev) { /* Figure out which areas are/should be occupied by RAM. * This is all computed in kilobytes and converted to/from * the memory controller right at the edges. * Having different variables in different units is * too confusing to get right. Kilobytes are good up to * 4 Terabytes of RAM... */ uint16_t tolm_r, remapbase_r, remaplimit_r; unsigned long tomk, tolmk; unsigned long remapbasek, remaplimitk; int idx; /* Get the value of the highest DRB. This tells the end of * the physical memory. The units are ticks of 64MB * i.e. 1 means 64MB. */ tomk = ((unsigned long)pci_read_config8(mc_dev, 0x63)) << 15; /* Compute the top of Low memory */ tolmk = pci_tolm >> 10; if (tolmk >= tomk) { /* The PCI hole does not overlap memory * we won't use the remap window. */ tolmk = tomk; remapbasek = 0x3ff << 15; remaplimitk = 0 << 15; } else { /* The PCI memory hole overlaps memory * setup the remap window. */ /* Find the bottom of the remap window * is it above 4G? */ remapbasek = 4*1024*1024; if (tomk > remapbasek) { remapbasek = tomk; } /* Find the limit of the remap window */ remaplimitk = (remapbasek + (4*1024*1024 - tolmk) - (1 << 15)); } /* Write the ram configuration registers, * preserving the reserved bits. */ /* tolm_r = pci_read_config16(mc_dev, 0xc4); tolm_r = ((tolmk >> 17) << 11) | (tolm_r & 0x7ff); pci_write_config16(mc_dev, 0xc4, tolm_r); remapbase_r = pci_read_config16(mc_dev, 0xc6); remapbase_r = (remapbasek >> 16) | (remapbase_r & 0xfc00); pci_write_config16(mc_dev, 0xc6, remapbase_r); remaplimit_r = pci_read_config16(mc_dev, 0xc8); remaplimit_r = (remaplimitk >> 16) | (remaplimit_r & 0xfc00); pci_write_config16(mc_dev, 0xc8, remaplimit_r); */ /* Report the memory regions */ printk_debug("tomk = %d\n", tomk); printk_debug("tolmk = %d\n", tolmk); printk_debug("remaplimitk = %d\n", remaplimitk); printk_debug("remapbasek = %d\n", remapbasek); idx = 10; ram_resource(dev, idx++, 0, 640); ram_resource(dev, idx++, 768, tolmk - 768); if (tomk > 4*1024*1024) { ram_resource(dev, idx++, 4096*1024, tomk - 4*1024*1024); } if (remaplimitk >= remapbasek) { ram_resource(dev, idx++, remapbasek, (remaplimitk + 64*1024) - remapbasek); } } assign_resources(&dev->link[0]); }

1 0

Re: [LinuxBIOS] [RFC][PATCH 2/2] x86_64: earlyprintk usb debug device support.
by Lu, Yinghai 04 Dec '06

04 Dec '06

Eric, Please check the version I modified for LinuxBIOS from your usbdebug_direct. Put the related info in struct ehci_debug_info { void *ehci_base; void *ehci_op_base; void *ehci_debug_base; unsigned devnum; unsigned endpoint_out; unsigned endpoint_in; int inited; }; So for CAR stage code, I could put it the range after stack and easy to retrieve. YH

1 0

[LinuxBIOS] Concepts for LX v3
by Anton 04 Dec '06

04 Dec '06

It would be nice to have TMS (Test Monitor System) onboard. Some big vendors have it on their systems for ages. Pros: a) Test for DRAM b) Test for Media (HDD, CF, SD, ..) connected to the host c) Test for Peripherals Cons: a) size. may not fit into 1/2/4 Mbit. TMS is a regular payload, access is done via RS232 (or USB in future), the same way as we all see printk messages nowdays. However, it's not yet clear to me is it possible to have multiple payloads at once and how to choose between them. Where to store boot options (CMOS is a way too small for it). Another concept to store big payloads which can't be stored in flash (even 16 Mbit is not enough) is to have dedicated partition. On booting media. With FAT16 or use a very simple FS to avoid licensing problems (no journaling features required). Pros: a) bigger and more payload sources at once from one place b) possibility to have several linuxbios images to be flashed back in case of emergency Cons: a) need to prepare boot media, like SATA/IDE device, to have dedicated partition b) need to add support lines for FS on dedicated FS (however, I see FILO can boot ext2 partition, hope this one will be enough). Comments are welcome.

3 2

[LinuxBIOS] LPC SuperIO "add-in card"
by Drew Lundsten 04 Dec '06

04 Dec '06

> Here's a wacko idea: for systems that use LPC memory, you > can use a "biossaviour" like plugin board, with not just > flash but also a superio chip on it. Only useful for > developers of course, not for the end user. A great wacko idea! Where do we find which SuperIO chip is the LinuxBIOS favorite? Maybe Maxim's SPI UARTs are the next logical hack. Anyone know if SPI-flash mobos also leaving off the RS-232 ports? Drew

6 15

[LinuxBIOS] r2518 - trunk/LinuxBIOSv2/util/flashrom
by svn＠openbios.org 04 Dec '06

04 Dec '06

Author: uwe Date: 2006-12-04 09:20:40 +0100 (Mon, 04 Dec 2006) New Revision: 2518 Modified: trunk/LinuxBIOSv2/util/flashrom/README Log: Update list of supported flash chips in the flashrom README (trivial). Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Modified: trunk/LinuxBIOSv2/util/flashrom/README =================================================================== --- trunk/LinuxBIOSv2/util/flashrom/README 2006-12-04 08:15:47 UTC (rev 2517) +++ trunk/LinuxBIOSv2/util/flashrom/README 2006-12-04 08:20:40 UTC (rev 2518) @@ -89,6 +89,7 @@ AMD AM-29F040B AMD AM-29F016D +ASD AE49F2008 Atmel AT-29C040A EMST F49B002UA Intel 82802AB (Firmware Hub) @@ -114,7 +115,10 @@ SST SST-49LF008A ST ST-M29F400BT ST ST-M29F040B -SyncMOS S29C51002T +SyncMOS S29C51001T/B +SyncMOS S29C51002T/B +SyncMOS S29C51004T/B +SyncMOS S29C31004T Winbond W29C011 Winbond W29C020C Winbond W49F002U

1 0

[LinuxBIOS] #52: flashrom: List the supported flash chips and southbridges in the README
by LinuxBIOS 04 Dec '06

04 Dec '06

#52: flashrom: List the supported flash chips and southbridges in the README ----------------------------------+----------------------------------------- Reporter: uwe | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Enhance the flashrom utility Component: flashrom | Version: Keywords: | Dependencies: Patchstatus: patch needs review | ----------------------------------+----------------------------------------- List the supported flash chips and southbridges in the flashrom README. Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> --- See also http://www.openbios.org/pipermail/linuxbios/2006-November/017056.html -- Ticket URL: <http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/52> LinuxBIOS <http://www.linuxbios.org/>

1 1

[LinuxBIOS] r2517 - trunk/LinuxBIOSv2/util/flashrom
by svn＠openbios.org 04 Dec '06

04 Dec '06

Author: uwe Date: 2006-12-04 09:15:47 +0100 (Mon, 04 Dec 2006) New Revision: 2517 Modified: trunk/LinuxBIOSv2/util/flashrom/README Log: List the supported flash chips and southbridges in the flashrom README file (trivial). Closes #52. Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Modified: trunk/LinuxBIOSv2/util/flashrom/README =================================================================== --- trunk/LinuxBIOSv2/util/flashrom/README 2006-12-03 23:46:36 UTC (rev 2516) +++ trunk/LinuxBIOSv2/util/flashrom/README 2006-12-04 08:15:47 UTC (rev 2517) @@ -84,3 +84,61 @@ Change CFLAGS in the Makefile to enable it: Remove -DDISABLE_DOC from CFLAGS. +Supported Flash Chips +--------------------- + +AMD AM-29F040B +AMD AM-29F016D +Atmel AT-29C040A +EMST F49B002UA +Intel 82802AB (Firmware Hub) +Intel 82802AC (Firmware Hub) +M-Systems MD-2802 (unsupported, disabled by default) +MX MX-29F002 +PMC PMC-49FL002 +PMC PMC-49FL004 +Sharp LHF-00L04 +SST SST-29EE020A +SST SST-28SF040A +SST SST-39SF010A +SST SST-39SF020A +SST SST-39SF040 +SST SST-39VF020 +SST SST-49LF040B +SST SST-49LF040 +SST SST-49LF020A +SST SST-49LF080A +SST SST-49LF002A/B +SST SST-49LF003A/B +SST SST-49LF004A/B +SST SST-49LF008A +ST ST-M29F400BT +ST ST-M29F040B +SyncMOS S29C51002T +Winbond W29C011 +Winbond W29C020C +Winbond W49F002U +Winbond W49V002A +Winbond W49V002FA +Winbond W39V040A +Winbond W39V040B + + +Supported Southbridges +---------------------- + +AMD CS5530 +AMD Geode SC1100 +AMD AMD-8111 +ATI SB400 +Intel ICH0-ICH8 (all variations) +Intel PIIX4/PIIX4E/PIIX4M +NVIDIA CK804 +NVIDIA MCP51 +SiS 630 +SiS 5595 +VIA VT8231 +VIA VT8235 +VIA VT8237 +VIA VT82C686 +

1 0

[LinuxBIOS] USB debug device
by Lu, Yinghai 04 Dec '06

04 Dec '06

Where to get USB-to-Serial or USB-to-USB device mentioned in the doc? http://www.usb.org/developers/presentations/pres0602/john_keys.pdf YH

9 31

[LinuxBIOS] 440BX progress.
by Uwe Hermann 04 Dec '06

04 Dec '06

Hi, I have now reached a state in my 440BX code where the RAM init _could_ work (maybe). The current code I have is mostly a very ugly hack and I won't post any patches until I cleaned up the mess. Also, I'm currently hard-coding some stuff from known-good 'lspci -xxx 0:0.0' values, so that's not really useful for anybody with a different configuration, anyway. Here's what I'm able to get over serial right now: [...] Testing DRAM : 10000000-02000000 DRAM fill: 10000000-02000000 10000000 DRAM filled DRAM verify: 10000000-02000000 10000000 DRAM range verified. Done. Copying LinuxBIOS to ram. Jumping to LinuxBIOS. I'm basically using this code in auto.c (based on bitworks/ims stuff): sdram_initialize(sizeof(cpu)/sizeof(cpu[0]), cpu); enable_mainboard_devices(); ram_check(0x10000000, 0x2000000); Is that the canonical way to test whether RAM init works? The above serial output _looks_ fine, but nothing happens after the "Jumping to LinuxBIOS." anymore (but that may have other reasons). I tried using different payloads (filo, memtest) but with no success. What else do I have to configure for a payload to be able to start? I added uses CONFIG_CONSOLE_VGA uses CONFIG_PCI_ROM_RUN default CONFIG_CONSOLE_VGA=1 default CONFIG_PCI_ROM_RUN=1 to Options.lb in the hope to get VGA output, but no luck. Also, I tried adding some stuff to Config.lb; still no luck. I guess this needs some more work later, but I don't want to fix all of that right now. What's the absolute minimum config I need to get _something_ to boot, so that I can verify that RAM init works? Can someone provide a known-good memtest payload with serial support I could use? Is that supposed to work if the ram_check() succeeds? Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

5 20

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 December 2006