> > On Wed, 27 Jul 2005, Huang-Jen Wang wrote:
> > > Excuse me , this is my first time porting....do you tell me more
> > > detail..
> > > like need what information or which file need to modify...
> * Ronald G. Minnich <rminnich(a)lanl.gov> [050727 18:30]:
> > you're not getting clock IRQ, which is usually IRQ 0. you need to
> > see how your interrupt hardware and/or clock is working to create
> > interrupts.
On 7/28/05, Stefan Reinauer <stepan(a)openbios.org> wrote:
> Usually you have to correct your pirq and mptable (or ACPI tables, if
> available) (Check the APIC entries in your mptable, as a first try)
In my previous post, I mentioned a good way to proceed is booting from
the commercial BIOS and running LB util/getpir to view the PIRQ table
and compare it to the irq_table.c of the LinuxBIOS being booted.
To check the MP table, boot the COTS BIOS & Linux and run LinuxBIOS
util/mptable which will generate an mptable.c file on stdout. Compare
this code to the actual mptable.c code in the LinuxBIOS that caused
the boot problem. (The code that util/mptable generates must be hand
edited to work under LinuxBIOS v2, so some differences should exist.)
Please note that some people consider running either util/getpir or
util/mptable to be a waste of time. (I agree; Maybe these utilities
could be fixed so they would be more useful on LinuxBIOS v2.)
Hope this helps.
Ken Fuchs <kfuchs(a)winternet.com>
On Wed, 27 Jul 2005, Huang-Jen Wang wrote:
> Excuse me , this is my first time porting....do you tell me more detail..
> like need what information or which file need to modify...
you're not getting clock IRQ, which is usually IRQ 0. you need to see how
your interrupt hardware and/or clock is working to create interrupts.
I have been looking into some thermal shutdown issues with our board,
and discovered that LinuxBIOS is not enabling the P4's ability to
throttle back when the internal sensors indicate that the processor is
getting too hot.
According to the System Programming Guide, Vol. 3 of the IA-32 Intel
Architecture Software Developer's Manual (p. 13-24):
"BIOS is required to enable only one automatic thermal monitoring modes
(sic). Operating systems and applications must not disable the operation
of these mechanisms."
Has this been considered for LB? I didn't see any discussions in the
mailing list archives.
It would be relatively easy to implement support for "TM1" thermal
control, since that's just setting a MSR bit if the proper CPUID flag is
set. "TM2" control would be a little more complicated, since there is
the added ability to control the operating frequency and voltage when
the processor trips into thermal management mode.
Yh Lu wrote:
> 1. use latest kernel.
2.4.20-8 is a very old Red Hat patched kernel.
I'd strongly advise using at least 2.6.9. Maybe use Fedora Core 4's
default 2.6.x kernel would be good enough.
The current stable Linux kernel at kernel.org is 188.8.131.52.
This would also be a good choice and probably the one that YH is
suggesting. If possible, use 184.108.40.206.
> 2. problem could be still with LinuxBIOS stage.
Perhaps, LinuxBIOS is using an incorrect IRQ routing table?
If you have a commercial BIOS, please try that and maybe try
running getpir in the util directory of LinuxBIOS. Compare
the code it generates with the irq_table.c your LinuBIOS kernel
used when it generated the output appended below. (The output
of getpir may need to be hand edited to get things just right.)
Hope this helps.
Ken Fuchs <kfuchs(a)winternet.com>
> On 7/26/05, Huang-Jen Wang <huangjen.wang(a)gmail.com> wrote:
> > Dear all,
> > My linuxbios tried to boot the linux...but has a
> problem..hope you can
> > give me some advice...thanks....the message is follow:
> > .....
> > ollect_sys_info: 00000000000c0000-00000
> > pci_init: 01:02.0 1166:0130 0604 00
> > pci_init: 01:03.0 1166:0132 0604 00nt addr 0x1258e0 size
> 0x48 offset 0
> > pci_init: 01:04.0 1166:0132 0604 00
> > pci_init: 01:05.0 1166:0132 0604 00n PT_LOAD segment
> > pci_init: 01:06.0 1166:0132 0604 000000000000100000 memsz:
> > pci_init: 01:07.0 1166:0036 0604 00
> > pci_init: 01:09.0 1166:0223 0c03 10
> > pci_init: 01:09.1 1166:0223 0c03 10
> > 00000000000048
> > pci_init: 01:09.2 1166:0223 0c03 20
> > FILO
> > pci_init: 02:06.0 1000:0030 0100 00domain) Fri Jul 22
> 19:47:38 CST 200
> > pci_init: 03:04.0 14e4:1668 0200 00
> > pci_init: 03:04.1 14e4:1668 0200 000xe1fb007
> > pci_init: 08:0d.0 1166:0104 0604 00ebx = 0x1ffe9420
> > Press <Enter> for default boot, or <Esc> for boot prompt...
> timed out
> > collect_linuxbios_info: Searching for L
> > boot: hda1:/vmlinuz-2.4.20-8 root=/dev/hda2 console=tty0
> > console=ttyS0,115200nd_lb_table: Found canidate at: 00000500
> > collect_linuxbios_info: Found LinuxBIOS tabl
> > find_ide_controller: cmd_base=0x1f0 ctrl_base=0x3f4
> > convert_memmap: 0x000000000000
> > ide_software_reset: Waiting for ide0 to become ready for reset... ok
> > convert_memmap: 0x00000000000de0 0x0000000009f220 1
> > init_drive: Testing for hda
> > convert_memmap
> > init_drive: Probing for hda0030000 1
> > init_drive: LBA mode, sectors=12672450rt_memmap:
> 0x000000000f0000 0x00000000
> > init_drive: Init device params... ok
> > init_drive: Probing for hdb
> > print_status: IDE: status=0x0, err=0x0
> > Mounted ext2fs
> > Found Linux version 2.4.20-8
> (bhcompile(a)stripples.devel.redhat.com) #1 Thu Mar 1
> > 3 17:18:24 EST 2003 bzImage.
> > Loading kernel... ok
> > Jumping to entry point...
> > Linux version 2.4.20-8
> (bhcompile(a)stripples.devel.redhat.com) (gcc version 3.2.2
> > 20030222 (Red Hat Linux 3.2.2-5)) #1 Thu Mar 13 17:18:24 EST 2003
> > BIOS-provided physical RAM map:
> > BIOS-e820: 0000000000000de0 - 00000000000a0000 (usable)
> > BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
> > 0MB HIGHMEM available.
> > 512MB LOWMEM available.
> > hm, page 00000000 reserved twice.
> > On node 0 totalpages: 131072
> > zone(0): 4096 pages.
> > zone(1): 126976 pages.
> > zone(2): 0 pages.
> > Kernel command line: root=/dev/hda2 console=tty0
> > Initializing CPU#0
> > Detected 1995.061 MHz processor.
> > Console: colour dummy device 80x25
> > Calibrating delay loop...
On Tue, 26 Jul 2005, Gernot Butschek wrote:
> I'm working on an embedded project and am using a Kontron embedded board
> (see details below). I'm wondering if LinuxBIOS supports this board in
> order to get rid of the last piece of proprietary software.
we have never had an 815 ported to linuxbios, but if you can get docs, it
should not be hard.
I'm working on an embedded project and am using a Kontron embedded board
(see details below).
I'm wondering if LinuxBIOS supports this board in order to get rid of the
last piece of proprietary software.
Thanks for your help.
0 Brief description
Kontron ETX industrial PC board: ETX-P3T 4000
Processor: Intel Celeron Processor (0.13 µ) in Micro-FCBGA (µBGA479)
Bus: 100MHz CPU bus, 100MHz memory bus
Chipset: Intel 815 (north bridge)
Intel 82801DB (south bridge)
Super I/O: Winbond W83627HF connected by using an LPC interface
Cache: On-die Second level 256k
Memory: One 144-pin SO-DIMM 3.3V PC-PC-133 or PC-100 unbuffered SDRAM,
up to 512MB
Enhanced Intelligent Drive Electronics (EIDE): Two Peripheral Component
Interconnect (PCI) Bus Master IDE ports (up to four devices) support:
- Ultra 33 Direct Memory Access (DMA) mode
- Programmed Input/Output (PIO) modes up to Mode 4 timing
- Multiword DMA Mode 0,1,2 with independent timing
Universal Serial Bus (USB): Four USB 1.1/2.0 ports (UHCI and EHCI)
Integrated Ethernet: Intel 82562 10/100 Mbps Fast Ethernet controller
Onboard video graphics array (VGA): Integrated in Intel® 815:
- Graphics memory controller hub
- Up to 1MB Video RAM (UMA)
Audio: Integrated in Intel 82801DB southbridge
- SoundBlaster? AC97, Windows Sound System? compatible
BIOS: Phoenix, 512k Flash-BIOS
- NV-EEPROM for CMOS-setup retention without battery
BIOS support for additional super I/O devices (COM3, COM4, LPT, and
1 LSPCI output
0000:00:00.0 Host bridge: Intel Corp. 82815 815 Chipset Host Bridge and
Memory Controller Hub (rev 04)
0000:00:02.0 VGA compatible controller: Intel Corp. 82815 CGC [Chipset
Graphics Controller] (rev 04)
0000:00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02)
0000:00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02)
0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 82)
0000:00:1f.0 ISA bridge: Intel Corp. 82801DB/DBL (ICH4/ICH4-L) LPC Bridge
0000:00:1f.1 IDE interface: Intel Corp. 82801DB/DBL (ICH4/ICH4-L)
UltraATA-100 IDE Controller (rev 02)
0000:00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus
Controller (rev 02)
0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 02)
0000:01:08.0 Ethernet controller: Intel Corp. 82801BD PRO/100 VE (CNR)
Ethernet Controller (rev 82)
2 Super IO chip
Winbond W83627HF connected by using an LPC interface
3 Type of BIOS device
Flash Memory 8 Mbit (1M x8, Uniform Block), 3V Supply Firmware Hub Flash
ST Microelectronic M50FW080 (Package TSOP 40)
4 URL to Mainboard specifications
Hello all guys here.
Finally, the very foolish guy in Tokyo has succeeded to run
LX2 on my EPIA M/B. Thank you all. Thanks for all helps. Thank you!!!.
But, of course, there are problems and questions.
first, the biggest issue is, DIMMs are really picky. The M/B
is natively picky, I mean, even with Award BIOS, it is picky.
but the problem is much more serious with LX2.
I tested with two EPIA M/B and 5 DIMMs which all
are confirmed to work well with Award BIOS. And the result
is too much great. Only one combination worked in these
10 combinations. Guys, can you help?
I think that one solution is hard coding the params of mem
in a BIOS image. But, how?
The second issue is, booting time. It is very fast before
a kernel loaded, but after this, there are three glitches.
I know at least two of them are not LX2 issue, but I hope any advice.
1. Just after "Jumping to entry point...".
Probably this waiting is caused by "Uncompressing Linux kernel",
but it is much slower than normal booting. Takes about 2 sec.
"Console: colour dummy device 80x25
Memory: 128128k/131072k available"
This comes from memory checking? It takes about 1 sec.
3. IDE recognizing.
I added "ide0=0x1f0,0x3f6,14 ide1=noprobe", but it takes about 2 secs.
The third issue is, VGA.
I read the FreeVGA paper. Yes, it seems great.
But such complicated technology is really necessary?
For example, this guy succeeded to use normal VGA bios, although I failed.
Or, just using Xfree86 driver doesnt work?
--- Okajima, Jun. Tokyo, Japan.
I met one system: 4 way and every node has one ck804.
because current mem and pref-mem allocation will make every node two
mem range ( not together), So PCI_DEV(0, 0x18,1) 0x80-0xbf regs that
record mmio range will be used up.
So they there is some problem to enable VGA console, because vga
console need [0xa0000, 0xc0000) to be set as mmio too.
I remember that very beginning the PCI resource treat pref-mem io as
memio, and at last when setting that just make the upper 32 base and
limit to 0....
If you agree, I will put the old code back and add one CONFIG_NO_PREF_MEM....
Greetings to all!
I was recently attempting to build Linuxbios primarily to see how it
works and what OpenBIOS is all about.
Therefore, I'm building LB under a Debian 3.1 machine. OpenBIOS has been
compiled as the payload and set under
targets/emulation/qemu-i386/config.lb. LinuxBIOS compiles fine (the
latest snapshot, SVN complains that some udelay is undefined). Qemu
preforms the following double-backflip and dies:
PCI_DOMAIN: 0000 enabled
PCI_DOMAIN: 0000 scanning...
PCI: pci_scan_bus for bus 0
PCI: 00:00.0 Cannot find pci bus operations
It halts there till the end of time. Any ideas? Is Qemu support
currently broken? (I'm waiting to build my geode based LinuxBIOS box
until I can test it out somewhere else).