[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
12 years, 4 months
[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
12 years, 4 months
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
12 years, 4 months
[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
12 years, 4 months
[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
12 years, 4 months
[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
12 years, 4 months
[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
12 years, 4 months
[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
12 years, 4 months
[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>
12 years, 4 months
[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
12 years, 4 months
