January 2007 - coreboot - mail.coreboot.org

[LinuxBIOS] [PATCH] e820 table correction

by Roman Kononov

Hello, I have this situation: Linuxbios boots an Opteron motherboard with 1GB memory. Linuxbios directly loads a recent linux kernel. The memory layout is like this: BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000000e18 (reserved) BIOS-e820: 0000000000000e18 - 00000000000a0000 (usable) BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable) BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved) BIOS-e820: 00000000000f0400 - 0000000040000000 (usable) The f0000-f0400 region contains IRQ and ACPI tables. At some point the kernel builds a resource table containing all physical address ranges and type of hardware the addresses are mapped to. The table is accessible via /proc/iomem: # cat /proc/iomem 00000000-00000e17 : reserved 00000e18-0009ffff : System RAM 000a0000-000bffff : Video RAM area 000c0000-000cbfff : Video ROM 000f0000-000fffff : System ROM e0000000-efffffff : PCI Bus #03 e0000000-efffffff : 0000:03:00.0 f0000000-f3ffffff : GART f4000000-f60fffff : PCI Bus #03 f4000000-f4ffffff : 0000:03:00.0 f5000000-f5ffffff : 0000:03:00.0 f6000000-f601ffff : 0000:03:00.0 f6100000-f6100fff : 0000:00:01.0 f6101000-f6101fff : 0000:00:02.0 f6101000-f6101fff : ohci_hcd f6102000-f6102fff : 0000:00:04.0 f6103000-f6103fff : 0000:00:07.0 f6103000-f6103fff : sata_nv f6104000-f6104fff : 0000:00:08.0 f6104000-f6104fff : sata_nv f6105000-f6105fff : 0000:00:0a.0 f6106000-f61060ff : 0000:00:02.1 f6200000-f620ffff : 0000:40:01.0 As you can see, the 00000000000f0400-0000000040000000 region is not listed. It is not listed because the kernel unconditionally adds "000f0000-000fffff : System ROM" first (look for "request_resource(&iomem_resource, &system_rom_resource)"), and then the attempt to add f0400-40000000 range fails because of overlapping. The kernel does not care that the range is not listed there. Kexec does. It uses the /proc/iomem file to instruct the kexec system call how to place the segments of a new kernel in the physical memory. Kexec fails to start a new kernel because it cannot locate enough physical memory. This must be fixed either in linux or linuxbios. Assuming that linuxbios is to be fixed, I cooked a patch which provides this memory layout: BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000000e18 (reserved) BIOS-e820: 0000000000000e18 - 00000000000a0000 (usable) BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 0000000040000000 (usable) The /proc/iomem contains: # cat /proc/iomem 00000000-00000e17 : reserved 00000e18-0009ffff : System RAM 000a0000-000bffff : Video RAM area 000c0000-000cbfff : Video ROM 000f0000-000fffff : System ROM 00100000-3fffffff : System RAM 00100000-00203c61 : Kernel code 00203c62-00248c3f : Kernel data e0000000-efffffff : PCI Bus #03 e0000000-efffffff : 0000:03:00.0 f0000000-f3ffffff : GART f4000000-f60fffff : PCI Bus #03 f4000000-f4ffffff : 0000:03:00.0 f5000000-f5ffffff : 0000:03:00.0 f6000000-f601ffff : 0000:03:00.0 f6100000-f6100fff : 0000:00:01.0 f6101000-f6101fff : 0000:00:02.0 f6101000-f6101fff : ohci_hcd f6102000-f6102fff : 0000:00:04.0 f6103000-f6103fff : 0000:00:07.0 f6103000-f6103fff : sata_nv f6104000-f6104fff : 0000:00:08.0 f6104000-f6104fff : sata_nv f6105000-f6105fff : 0000:00:0a.0 f6106000-f61060ff : 0000:00:02.1 f6200000-f620ffff : 0000:40:01.0 Kexec is happier with the patch. Regards, Roman

13 years, 5 months

1
0
0 0

[LinuxBIOS] 16 Mb group buy

by ron minnich

some time ago I offered to do a group buy of the 16 Mbit parts. I'm still willing to do that if we can pick the right part and get the people together. So, again, what's the part, and how many do we all need? 16 Mbit part -- this is pretty exciting, it will allow us to have a pretty full-featured kernel+busybox in there. thanks ron

13 years, 5 months

6
5
0 0

Re: [LinuxBIOS] CoreDuo Support

by Stefan Reinauer

Hi Greg, Martin, Greg A (Greg) wrote: > Hi, I am new to the list. I am attempting to port LinuxBios to a CoreDuo Processor > coupled with an Intel 3100 system controller. I seem to be having some problem with > the memory and cache coherency, but as I am relatively new to x86 (ppc is my background) > I am unsure if I am getting the cpu initialized properly. I started with one on the e7520 > based systems and seem to have the memory functioning, but memory tests fail with what > looks like cache line pushouts of erroneous data. Does this make sense to anybody? The biggest difference between the 7520 and the 3100 is that the 3100 uses DDR2 memory. This requires a more complex initialization sequence. I suggest the following information: ftp://download.intel.com/design/intarch/datashts/31345802.pdf ftp://download.intel.com/design/intarch/specupdt/31345901.pdf Especially chapters 10.1.2.2 and 12 might be interesting. Given the difference to the e75xx is not too fundamental, you might be lucky with this information, but chances are good that you need the Core Duo BIOS Writer's Guide, which Intel is giving out under an NDA. Best regards, Stefan

13 years, 5 months

1
0
0 0

[LinuxBIOS] linuxbios debug full log

by michal wan

Press <Enter> for default boot, or <Esc> for boot prompt... 5^H ^H4^H ^H3^H ^H2^H ^H1^H ^Htimed out boot: hda1:/boot/vmlinuz-2.6.15-1.2054_FC5 root=/dev/hda1 console=tty0 console=ttyS0,115200 malloc_diag: alloc: 376 bytes (5 blocks), free: 16000 bytes (1 blocks) malloc_diag: alloc: 392 bytes (6 blocks), free: 15984 bytes (1 blocks) file_open: dev=hda1, path=/boot/vmlinuz-2.6.15-1.2054_FC5 find_ide_controller: found PCI IDE controller 1022:209a prog_if=0x80 find_ide_controller: primary channel: compatibility mode find_ide_controller: cmd_base=0x1f0 ctrl_base=0x3f4 ide_software_reset: Waiting for ide0 to become ready for reset... ok IDE time out No drive detected on IDE channel 0 devopen: failed to open ide malloc_diag: alloc: 376 bytes (5 blocks), free: 16000 bytes (1 blocks) malloc_diag: alloc: 280 bytes (4 blocks), free: 16096 bytes (1 blocks) boot: hda1:/boot/vmlinuz-2.6.15-1.2054_FC5 root=/dev/hda1 console=tty0 console=ttyS0,115200 _________________________________________________________________ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn

13 years, 5 months

1
0
0 0

[LinuxBIOS] Filo boot from CD-Rom syntax

by roger

Can somebody please update the Filo README file (and/or the Linuxbios Filo documentation) to including the following concerning CD-ROM device file syntax? ie. CD-ROM device is to be specified as "hdc1" and not "hdc"! Following is the relevant Filo documentation clippings: According to: http://te.to/~ts1/filo/CHANGES "* Support for mounting boot disk image of El Torito bootable CD-ROM. ("hdc1" means the boot disk image of the CD-ROM at hdc.)" However, I only see a very vague reference for the syntax of specifying a CD-ROM drives within Filo's README: "Notation of DEVICE for IDE disk and CD-ROM is same as in Linux (eg. hda1 means the first partition of master device on primary IDE channel)." (With the above Filo README information, the user is going to think "/dev/hdb" or "hdb" instead, FILO wants to see "hdb1"!) -- Roger http://www.eskimo.com/~roger/index.html Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61 Sun Jan 28 20:16:23 PST 2007

13 years, 5 months

7
11
0 0

[LinuxBIOS] CoreDuo Support

by Martin, Greg A (Greg)

Hi, I am new to the list. I am attempting to port LinuxBios to a CoreDuo Processor coupled with an Intel 3100 system controller. I seem to be having some problem with the memory and cache coherency, but as I am relatively new to x86 (ppc is my background) I am unsure if I am getting the cpu initialized properly. I started with one on the e7520 based systems and seem to have the memory functioning, but memory tests fail with what looks like cache line pushouts of erroneous data. Does this make sense to anybody? Greg

13 years, 5 months

1
0
0 0

[LinuxBIOS] linuxbios debug full log

by michal wan

configure environment in filo-0.4.2 SUPPORT_PCI = 1 PCI_BRUTE_SCAN = 1 DEBUG_ALL = 1 in LinuxBIOSV2510 use targets/artecgroup/dbe61 the problem is "find_ide_controller: PCI IDE #0 not found" the full log is in the attached file any advice would be appreciated! _________________________________________________________________ 免费下载 MSN Explorer: http://explorer.msn.com/lccn

13 years, 5 months

2
1
0 0

[LinuxBIOS] VGA Console does not start if ROM_SIZE > 512

by Alan Carvalho de Assis

Hi guys, I am testing LinuxBIOS on 2MB flash in tyan s2850. If I compile LinuxBIOS to 512KB (-36KB from VGA ROM) and complete the head of ROM file with 0's to get 2MB everything work fine, LinuxBIOS starts and I can see the GRUB menu on VGA monitor. This is the working option: option ROM_SIZE = 512*1024-36*1024 If I change it to 1MB or 2MB VGA console don't work: option ROM_SIZE = 2048*1024-36*1024 But serial console and everything (except VGA) still working. I searched for something related to it on source code, but don't found anything about it. How to fix this problem? Cheers, -- ------------------------------------------------------------ | Alan Carvalho de Assis | ------------------------------------------------------------ -- Não importa o que os outros irão pensar, A cura para a infelicidade é a felicidade

13 years, 5 months

2
2
0 0

[LinuxBIOS] more big range for HT_CHAIN_UNITID_BASE and HT_CHAIN_UNITID_BASE

by Lu, Yinghai

Please check the diff to fb2_mcp55_full_01172007. More range for HT_CHAIN_UNITID_BASE and HT_CHAIN_END_UNITID_BASE. For example: in C51/MCP55 or C51/MCP51 Will allow 1. C51 at 0x10 to 0x14, and MCP at 0 to 4 2. C51 at 1 to 4, and MCP at 7 to 0x0a The reason is c51/mcp51/mcp55 reported unitid is 0x0f (far beyond it needed), and will prevent us from putting them on bus 0. Typical values for c51/mcp55 or c51/mcp51: HT_CHAIN_UNITID_BASE = 0x10 # for C51 HT_CHAIN_END_UNITID_BASE = 0 # for mcp If only have mcp with c51, HT_CHAIN_UNITID_BASE = 0 # for MCP #HT_CHAIN_END_UNITID_BASE = 0 # default value 0x20 Signed-off-by: Yinghai Lu <yinghai.lu(a)amd.com> -----Original Message----- From: linuxbios-bounces(a)linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of Lu, Yinghai Sent: Thursday, January 18, 2007 9:06 PM To: Ronald G Minnich; Eric W. Biederman Cc: linuxbios(a)linuxbios.org Subject: [LinuxBIOS] MCP55 LinuxBIOS with USB debug etc. Please check the MCP55 support with usbdebug. MB included: Nvidia l1_2pvv Gigabyte m57sli Supermicro h8dmr Tyan s2912 --- with HTX Signed-off-by: Yinghai Lu <yinghai.lu(a)amd.com>

13 years, 5 months

2
1
0 0

[LinuxBIOS] Filo problems booting El Torito (LiveCD) CD-ROMS?

by roger

Could it be I'm just having problems using Linuxbios & Filo under Qemu emulation instead of actually booting from a flash device? Anyways, here's my debug info: I'm successfully using Qemu to load Linuxbios with a filo payload specifying "hdc1" as my CD-ROM device within the Filo Config file. /dev/hdc = DVD-ROM with DVD+R LiveCD /dev/hdd = CD-ROM with CD-R LiveCD Using an actual CD-ROM (DVD-ROM) device with the Qemu "-cdrom /dev/hdc" option : $ /home/roger/tmp/qemu/bin/qemu -L ~ -nographic -cdrom /dev/hdc -boot d <snip Linuxbios & Filo messages> boot: hdc1 malloc_diag: alloc: 208 bytes (5 blocks), free: 16168 bytes (1 blocks) malloc_diag: alloc: 224 bytes (6 blocks), free: 16152 bytes (1 blocks) file_open: dev=hdc1, path=<NULL> find_ide_controller: found PCI IDE controller 8086:7010 prog_if=0x80 find_ide_controller: secodary channel: compatibility mode find_ide_controller: cmd_base=0x170 ctrl_base=0x374 ide_software_reset: Waiting for ide1 to become ready for reset... ok init_drive: Testing for hdc init_drive: Probing for hdc print_status: IDE: status=0x41, err=0x4 init_drive: Testing for hdc init_drive: Probing for hdc hdc: ATAPI: QEMU CD-ROM init_drive: Testing for hdd init_drive: Probing for hdd print_status: IDE: status=0x0, err=0x1 init_drive: Testing for hdd init_drive: Probing for hdd print_status: IDE: status=0x0, err=0x1 atapi_detect_medium: block_len=2048 atapi_detect_medium: sectors=520415 1016MB medium detected open_pc_partition: pc partition magic number not found open_eltorito_image: El-Torito boot catalog at sector 53 open_eltorito_image: id='' Disc doesn't use boot disk emulation devopen: can't open partition 1 malloc_diag: alloc: 208 bytes (5 blocks), free: 16168 bytes (1 blocks) malloc_diag: alloc: 192 bytes (4 blocks), free: 16184 bytes (1 blocks) boot: hdc1 Using a Loop ISO Filesystem specified as a "-cdrom" option for Qemu: $ /home/roger/tmp/qemu/bin/qemu -L ~ -nographic -cdrom /home/roger/gentoo/install cd/install-x86-minimal-2006.1.iso <snip Linuxbios & Filo messages> boot: hdc1 malloc_diag: alloc: 208 bytes (5 blocks), free: 16168 bytes (1 blocks) malloc_diag: alloc: 224 bytes (6 blocks), free: 16152 bytes (1 blocks) file_open: dev=hdc1, path=<NULL> find_ide_controller: found PCI IDE controller 8086:7010 prog_if=0x80 find_ide_controller: secodary channel: compatibility mode find_ide_controller: cmd_base=0x170 ctrl_base=0x374 ide_software_reset: Waiting for ide1 to become ready for reset... ok init_drive: Testing for hdc init_drive: Probing for hdc print_status: IDE: status=0x41, err=0x4 init_drive: Testing for hdc init_drive: Probing for hdc hdc: ATAPI: QEMU CD-ROM init_drive: Testing for hdd init_drive: Probing for hdd print_status: IDE: status=0x0, err=0x1 init_drive: Testing for hdd init_drive: Probing for hdd print_status: IDE: status=0x0, err=0x1 atapi_detect_medium: block_len=2048 atapi_detect_medium: sectors=27737 54MB medium detected open_pc_partition: pc partition magic number not found open_eltorito_image: El-Torito boot catalog at sector 34 open_eltorito_image: id='' Disc doesn't use boot disk emulation devopen: can't open partition 1 malloc_diag: alloc: 208 bytes (5 blocks), free: 16168 bytes (1 blocks) malloc_diag: alloc: 192 bytes (4 blocks), free: 16184 bytes (1 blocks) boot: hdc1 -- Roger http://www.eskimo.com/~roger/index.html Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61 Sun Jan 28 20:40:16 PST 2007

13 years, 5 months

1
0
0 0

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot January 2007