Regarding the problem there are three way to solve.
1. move the pgtbl after 1M. this should work for a while....
the future 32 node abd quad core = 128 cpu, will have stack
128*8=1M, It will cross the 0xa000 again...
2. in linuxbios_ram.ld, force bss, stack and heap all after 1M, the
total ram section will be larger then 1M (about 1.5M),
(linuxbios_ram.bin still about 64K), it works well except the back and
forth in two linuebios ram image in jmp_to_elf_entry will clear the
0xf0000-0x100000, the irq table ( and acpi region ) region
3. the best solution seems to set _RAMBASE=0x10400, so it will not clear
our irq table and acpi tables...., the only thing to do is some 16 bit
code in secondary.S need to move to rom....other wise the ap can not be
started....
YH
-----Original Message-----
From: linuxbios-bounces(a)openbios.org
[mailto:linuxbios-bounces@openbios.org] On Behalf Of yhlu
Sent: Wednesday, December 07, 2005 12:47 AM
To: Eric W. Biederman; LinuxBIOS
Subject: [LinuxBIOS] Fwd: [issue50] put pgtbl after 1M
Eric,
I moved the pgtbl to the last 1M of CONFIG_LB_MEM_TOPK....
Please check it.
YH
---------- Forwarded message ----------
From: Yinghai Lu <lxbios(a)openbios.org>
Date: Dec 7, 2005 12:43 AM
Subject: [issue50] put pgtbl after 1M
To: ollie(a)lanl.gov, rminnich(a)lanl.gov, stepan(a)openbios.org,
yinghailu(a)gmail.com
New submission from Yinghai Lu <yinghailu(a)gmail.com>:
This one is needed for 8 way dual core with VGA support enabled.
The reason is every cpu page table will be 20k, and if there is 16 cpu
will need
320k, it will push the stack and heap cross the 0xa0000, the region for
vga font
buffer. TO use that need to set CONFIG_LB_MEM_TOPK in MB Options.lb
It also remove the hardcode 1M in clear_1m_ram.c to use
CONFIG_LB_MEM_TOPK.
YH
----------
files: 1207_put_pgtbl_after_1m.diff
messages: 299
nosy: ollie, rminnich, stepan, yhlu
priority: urgent
status: chatting
title: put pgtbl after 1M
________________________________________________
LinuxBIOS issue tracker <lxbios(a)openbios.org>
<https://openbios.org/roundup/linuxbios/issue50>
________________________________________________
I am working to get LinuxBIOS (v2) running on an embedded board with a
Geode GX1 CPU and CS5530A companion device.
To my joy, the board is already happily booting LinuxBIOS and running the
linux kernel: after a little bit of tuning it races from power on to
Linux prompt in 3 seconds!!
Great job, linuxbios programmers!
I have 2 questions:
1)
I would like to be able to do a reboot (reset) and/or poweroff from
software. Does anybody know how to get this done for this hardware?
I don't know if the reset interface is standard or dependent on specific
board design. I tried writing 0x1 to i/o port 0x92 (as suggested in the
CS5530A data book), but is does not work.
2)
I noticed that in my configuration the cache is not turned on. That made
the booting of the kernel very slow. I worked around this by calling
"enable_cache" in auto.c, but I guess this is not the right way to do it.
I see there is x86_enable_cache in
cpu/amd/model_gx1/model_gx1_init.c:model_gx1_init(), but this function is
never called.
Here is the boot log from LinuxBIOS:
-----
0.000:
0.011: LinuxBIOS-1.1.8.0Fallback ma dec 5 15:04:24 CET 2005 starting...
0.020: Setting up default parameters for memory
0.236: Sizing memory
0.241: Probing for DIMM0
0.245: Found DIMM0
0.251: Page Size: 00001000
0.256: Component Banks: 4
0.259: Module Banks: 1
0.267: DIMM size: 04000000
0.269: Probing for DIMM1
0.273: MC_BANK_CFG = 00701420
0.577: Copying LinuxBIOS to ram.
0.632: Jumping to LinuxBIOS.
0.641: LinuxBIOS-1.1.8.0Fallback Mon Dec 5 19:41:22 CET 2005 booting...
2.265: clocks_per_usec: 413
2.273: Enumerating buses...
2.274: Finding PCI configuration type.
2.275: PCI: Using configuration type 1
2.280: PCI_DOMAIN: 0000 enabled
2.281: PCI: pci_scan_bus for bus 0
2.288: PCI: 00:00.0 [1078/0001] enabled
2.296: PCI: 00:02.0 [1282/9102] enabled
2.296: PCI: 00:12.0 [1078/0100] enabled
2.297: PCI: 00:12.1 [1078/0101] enabled
2.302: PCI: 00:12.2 [1078/0102] enabled
2.310: PCI: 00:12.3 [1078/0103] enabled
2.311: PCI: 00:12.4 [1078/0104] enabled
2.312: PCI: 00:13.0 [0e11/a0f8] enabled
2.319: PNP: 002e.0 enabled
2.325: PNP: 002e.1 enabled
2.326: PNP: 002e.2 enabled
2.326: PNP: 002e.3 disabled
2.327: PNP: 002e.4 enabled
2.327: PNP: 002e.5 enabled
2.337: PNP: 002e.6 enabled
2.338: PNP: 002e.7 enabled
2.338: PNP: 002e.8 disabled
2.340: PCI: 00:12.1 disabled
2.341: PCI: 00:12.2 enabled
2.367: PCI: 00:12.3 disabled
2.368: PCI: 00:12.4 disabled
2.369: PCI: pci_scan_bus returning with max=00
2.371: done
2.373: Allocating resources...
2.374: Reading resources...
2.378: Done reading resources.
2.379: Setting resources...
2.380: BC_DRAM_TOP = 0x03bfffff
2.386: MC_GBASE_ADD = 0x00000078
2.387: I would set ram size to 60 Mbytes
2.389: PCI: 00:02.0 10 <- [0x0000001000 - 0x00000010ff] io
2.390: PCI: 00:02.0 14 <- [0x00febc2000 - 0x00febc20ff] mem
2.397: PCI: 00:02.0 30 <- [0x00feb80000 - 0x00febbffff] romem
2.400: PCI: 00:12.1 10 <- [0x00febc3000 - 0x00febc30ff] mem
2.408: PCI: 00:12.2 20 <- [0x0000001400 - 0x000000147f] io
2.416: PCI: 00:12.3 10 <- [0x00febc4000 - 0x00febc407f] mem
2.425: PCI: 00:12.4 10 <- [0x00febc0000 - 0x00febc0fff] mem
2.426: PCI: 00:13.0 10 <- [0x00febc1000 - 0x00febc1fff] mem
2.428: Done setting resources.
2.429: Done allocating resources.
2.456: Enabling resourcess...
2.456: PCI: 00:00.0 cmd <- 147
2.457: PCI: 00:02.0 cmd <- 143
2.460: PCI: 00:12.0 cmd <- 14f
2.461: PNP: 002e.4 missing enable_resources
2.462: PCI: 00:12.2 missing enable_resources
2.467: PCI: 00:12.1 cmd <- 142
2.467: PCI: 00:12.2 cmd <- 141
2.468: PCI: 00:12.3 cmd <- 142
2.473: PCI: 00:12.4 cmd <- 142
2.474: PCI: 00:13.0 cmd <- 142
2.474: done.
2.475: Initializing devices...
2.478: Root Device init
2.478: PCI: 00:00.0 init
2.479: northbridge: northbridge_init()
2.480: PCI: 00:12.0 init
2.480: PNP: 002e.0 init
2.488: PNP: 002e.1 init
2.489: PNP: 002e.2 init
2.489: PNP: 002e.5 init
2.489: PNP: 002e.6 init
2.490: PNP: 002e.7 init
2.490: PCI: 00:02.0 init
2.491: PCI: 00:12.1 init
2.498: PCI: 00:12.2 init
2.504: PCI: 00:12.3 init
2.504: PCI: 00:12.4 init
2.510: PCI: 00:13.0 init
2.511: Devices initialized
2.512: Copying IRQ routing tables to 0xf0000...done.
2.513: Verifing copy of IRQ routing tables at 0xf0000...failed
2.514: Moving GDT to 0x500...ok
2.527: Wrote linuxbios table at: 00000530 - 000006bc checksum 91c5
2.527:
2.528: Welcome to elfboot, the open sourced starter.
....
-----
I attached the Config.lb that I created for this board.It was adapted from
the eaglelion/5bcm.
Regards,
Joep
Hi Folks,
I'm working on pricing out an embedded system board for a PBX
application. Two of the manufacturers I have contacted, regarding
pricing and preformance requirements, have suggested using a dual core
pentium platform.
The target is going to boot from an integrated IDE compact flash target,
which should be pretty easy using LinuxBIOS, however..
Is there any chipset support present in LinuxBIOS that covers the
Pentium D dual core solution? Since I have direct control over the
design, it'd be easier to stick to what's known to work.
Thanks,
Justin
Eric,
I moved the pgtbl to the last 1M of CONFIG_LB_MEM_TOPK....
Please check it.
YH
---------- Forwarded message ----------
From: Yinghai Lu <lxbios(a)openbios.org>
Date: Dec 7, 2005 12:43 AM
Subject: [issue50] put pgtbl after 1M
To: ollie(a)lanl.gov, rminnich(a)lanl.gov, stepan(a)openbios.org, yinghailu(a)gmail.com
New submission from Yinghai Lu <yinghailu(a)gmail.com>:
This one is needed for 8 way dual core with VGA support enabled.
The reason is every cpu page table will be 20k, and if there is 16 cpu will need
320k, it will push the stack and heap cross the 0xa0000, the region for vga font
buffer. TO use that need to set CONFIG_LB_MEM_TOPK in MB Options.lb
It also remove the hardcode 1M in clear_1m_ram.c to use CONFIG_LB_MEM_TOPK.
YH
----------
files: 1207_put_pgtbl_after_1m.diff
messages: 299
nosy: ollie, rminnich, stepan, yhlu
priority: urgent
status: chatting
title: put pgtbl after 1M
________________________________________________
LinuxBIOS issue tracker <lxbios(a)openbios.org>
<https://openbios.org/roundup/linuxbios/issue50>
________________________________________________
Please check the patch on issue tracker
47: put chain on bus 0, 0x40, 0x80, and 0xc0
48: using hcdn to simplify the mptable.c and irqtable.c
Also there is ck804_early_setup_car.c for s2895 and other MB with multi
ck804
YH
Dear friends,
I wonder if it is possible to use LinuxBIOS on my hardware, or if not, what
labour costs the porting?
CPU: Pentium 166
MotherBoard: Eagles, E-AD586-3P21-401
Chipset: NEC PowerTX ADC 009B 026
kropotkin:~# lspci -vvv
0000:00:1c.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RT8139
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR+
Latency: 64 (8000ns min, 16000ns max)
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at 7000 [size=256]
Region 1: Memory at e2000000 (32-bit, non-prefetchable) [size=256]
Expansion ROM at 000d0000 [disabled] [size=64K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:1e.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W
[Millennium II] (prog-if 00 [VGA])
Subsystem: Matrox Graphics, Inc.: Unknown device 2007
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 12
Region 0: Memory at e0000000 (32-bit, prefetchable) [size=16M]
Region 1: Memory at e1000000 (32-bit, non-prefetchable) [size=16K]
Region 2: Memory at e1800000 (32-bit, non-prefetchable) [size=8M]
kropotkin:~#
I have no idea what "SuperIO chip" is, but the biggest one after NEC is
labelled as "LGS Prime 3C 993/R".
BIOS Looks like old UV-eraseable ROM: under an "Eagles" sticker there is
something like a circle-shaped window.
Actually, the main trouble with current BIOS is that it can count all the 128M
of DIMM installed, but reports to Linux kernel (2.6.8) only the first 64M.
Playing with mem="640K@0M 127M@1M" (or other variations does not help: kernel
hangs at boot saying "Loading kernel"). memtest86+'s probe reports those 128M
and tests run fine.
Soryy for the off-topic.
With the best regards,
Andrey.
>
>
> Howdy,
> Can I take it from this thread that the S2895 Tyan board will
> not work now? I am just getting into this and was going to experiment
> on the S2895.
>
> Thanks,
> Jeff Young
>
The Tyan S2895 _should_ work with the current SVN tree, but it is still
untested. This applies for most other boards in the latest tree. We'll
gladly assist you if you are going to test this. As an option you can
always choose a snapshot from 1.5 months ago.
Stefan
Hey all you via dudes:
I'm looking at using one of these small ITX or mini-ITX boards for a
personal project. And of course I want it to boot LinuxBIOS.
I'm going to need LCD output to a >= 800x600 screen and X allthough I
could probally make it work with the framebuffer as well. I don't
need a lot of power just enough to run a pyQT3 python app play mp3's.
What some MB board names I should I start looking for? There's loads
of options.
Which ones so far are known to boot?
Which ones are bios hacker friendly? (Meaning it has a PLCC or DIP
flash rather than TSOP)
--
Richard A. Smith
Hi,
after the LinuxBIOS tree was in a quasi permanent state of adaption
during the last two months, it is getting to a state where we need heavy
testing and reporting from users out there.
Ron, Ollie, Yinghai and me have been trying to do some heavy fixing
to get things going again, and the result can be seen here:
http://snapshots.linuxbios.org/stats/abuild-LinuxBIOSv2-2131.log
Now no more than three (3!) mainboards fail compilation:
agami/aruma
intel/xe7501devkit
momentum/apache
The next step should be to switch more mainboards over to cache as ram
(especially the agami/aruma, which fails due to lack of registers in
romcc) and, again, to test the current tree. Please go ahead and try any
supported systems you have access to and send reports to this list, or
to me.
Best regards,
Stefan
