Signed-off: Marc Bertens <mbertens(a)xs4all.nl>
Tested: Marc Bertens <mbertens(a)xs4all.nl>
I added superio registers for mainly the AUX device, to get it as the
orginal bios. With its the LEDs in the front panel can be controlled and
the JP900 and JP901 can be read.
I changed the flash ROM size 512Kb this was from the beginning a typo.
I removed the board_enable code due that all is in the devicetree.cb
file now.
Changed the irq_tables.c to avoid IRQ9.
At the moment eth0 and eth3 work properly.
The Cardbus interface the inserting en eject works correct and is seen
by the OS (Linux 2.6.35 (ubuntu distro)
Hard disk and CDROM work correct on IDE0.
TODO:
- eth1 and eth2 those still work no completely (they are buggy)
- IDE1 needs to be tested
- USB connections need to be found on the board and enabled
- the HACK in the /arch/x86/boot/pirq_tables.c still needs to be fixed.
Marc
For gx2/northbridgeinit.c
-some white space fixes
-some codingstyle fixes
-some comment fixes.
Signed-off-by: Nils Jacobs <njacobs8(a)hetnet.nl>
Thanks, Nils.
Dear maintainers of the superiotool,
I have the following "feature request" (maybe not a bug report):
I have this idea that superiotool should be able to detect more than
one SuperIO chip in the system. Such detection of multiple chips may
work in some cases, but may fail in others.
The primary cause seems to be that
winbond.c :: probe_idregs_winbond()
and
ite.c :: probe_idregs_ite()
call
if (chip_found) return; // this is a global variable!
after every "init sequence" tried.
Therefore, after the first chip detected (of any kind),
only the first init sequence is ever tried, in any subsequent calls
to the aforementioned probe_* functions.
My immediate hack was to comment out all occurrences of
if (chip_found) return;
in those probe functions.
Makes me wonder if this has some adverse effects, such as repeatedly
scanning some EFER bases / init sequences by probes belonging to
different chip families.
And my conclusion for the moment is that this repeated probing should
be harmless, and that the current behavior (stop after the first init
sequence tried) is flawed anyway :-)
My motivation is simple: right now I'm working with an embedded PC
that has two SuperIO chips on the inside: W83627 + W83977.
But I've seen other models in the past as well.
Your SuperIOtool is quite useful for a quick overview of the SuperIO
chips in the system, including a thorough dump of their registers.
In the past I myself have written and reused some simple snippet of
code / a tiny library (in DOS) to help me debug/tweak SuperIO stuff,
but I never got as far as making it truly universal and extensible.
As for SuperIOtool, I could fancy a writing capability, and maybe an
external configuration file, potentially allowing for extensions
without coding in C, maybe human-readable interpretations /
annotations of the register dump etc - but I admit that's too much
work to be worth the bother, certainly for me at the moment :-)
Keep up the excellent work that you're doing...
Frank Rysanek
1) If I use coreboot's "Run VGA Option ROMs", I can get VGA up and the first
thing displayed is one text line of something like "SeaBIOS Version...".
And then I usually get some of my other PCI devices option roms executing as
well on the VGA display.
But when I turn "Run VGA & other Option ROMs" off in Coreboot and then modify SeaBIOS
config.h with any of these options:
// Support finding and running option roms during post.
#define CONFIG_OPTIONROMS 1
// Set if option roms are already copied to 0xc0000-0xf0000
#define CONFIG_OPTIONROMS_DEPLOYED 0
// When option roms are not pre-deployed, SeaBIOS can copy an optionrom
// from flash for up to 2 devices.
#define OPTIONROM_VENDEV_1 0x00000000
#define OPTIONROM_MEM_1 0xf9000000
#define OPTIONROM_VENDEV_2 0x00000000
#define OPTIONROM_MEM_2 0x00000000
I get no VGA display. I even tried specifying the address of PCI VGA 01:00,
but I don't know if I have the correct address of the nvidia option rom. I had
better success with letting coreboot copy the vga pci option rom into 0x0c000
(or 0xc000) and then letting SeaBIOS to try simply executing it. I would get
the one line "Seabios Version ..." and then nothing else on the VGA console.
2) SeaBIOS seems to find a lot of things, but still tries to boot from floppy
device (or image), for which I have neither. I thought SeaBIOS was able to
boot from the first hard drive partition (ie. grub)? This is what I see on
serial console along with the quick f12 boot pause. But pressing f12 only
pauses longer with nothing else displayed via serial console. But, I can press
ESC and have it reboot, or the wonderful Windows Key will print it's scancode
on screen, but no other keys. (See very last lines in log.)
Attaching log with max debug on.
--
Roger
http://rogerx.freeshell.org/
Hello
Will coreboot work with the following hardware?
Acer Travelmate 8100
main board (dmidecode): Acer Kingfisher
cpu: Intel M 730 1,6GHz, 533MHz fsb, 2MB L2 cache
northbridge (lspci): Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03)
southbridge (lspci): Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
memory: 2x512MB DDR2 SO-DIMM SDRAM
vga: ATI Mobility Radeon X700 (PCIE)
best regards,
Saku Sammakko
-update gx2/northbridgeinit.c to lx standards
-remove not longer needed code from gx2/northbridge.c
Signed-off-by: Nils Jacobs <njacobs8(a)hetnet.nl>
Thanks, Nils.
