Add initial support for i855gme. This is a work in progress and I
don't expect it to work on all boards, or even any besides mine. This
is based heavily on i855pm.
Signed off by Jon Dufresne <jon.dufresne(a)gmail.com>
This patch includes config files for the asus/a8n5x port. It is the same as
asus/a8n_e with a different pnp layout, so I used #include's whenever possible.
System boots and is usable with usb keyboard.
works:
- serial port
- vga (old pci card)
- memtest86+ succeeds, but only with Rudolf's patch for unbuffered dimms
in K8. Otherwise you get spurious memory corruption.
- ide disk
- usb
doesn't:
- ps/2 keyboard
- onboard ethernet
- vga pci-e card (??)
- any other pci card I tried
wasn't tested:
- sata
- game port
- onboard audio (not supported by alsa anyway)
- ps/2 mouse
--
Robert Millan
<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)
Attached is a patch that enables AMD Geode CS5536 chipset support. I
have tested it successfully on a MSM800 board from digital logic. It
does, however, have a few issues that I would like some feedback on.
In my discussions with Marc Jones, Geode systems write protect the BIOS
via RCONFs (cache settings similar to MTRRs). Unlocking requires
changing MSR 0x1808 top byte to 0x22. Reading and writing to the msr,
however, requires instrucitons rdmsr/wrmsr, which are ring0 privileged
instructions so only the kernel can do the read/write. So my patch uses
the msr kernel module to access these instructions from user space using
the /dev/cpu/0/msr device.
My questions are:
- I do not think this is portable beyond linux. Is that an issue?
- My code assumes the msr kernel module is already loaded. Is there a
way to force a kernel module to load from the C code? My code does die
gracefully with a message reminding them to load the kernel module if
things fail.
- It seems like there should be a way to revert the msr back after
flashing is completed to put the bios back in write protect mode. Is
there a cleanup mechanism available? Something like disable_flash...
Thanks,
Lane Brooks
Have three motherboards running cn700, VT8237 chips set. All three
boards have W39V040BPZ bios chips. I can not program them with
flashrom. Flashrom see the chip as W39V040B. Flashrom start on the
flash and just sits there. When flashed with the -V option I can see
the memory address is not changing. But, big problem is the fact that
the chip does get a bit flashed, as, I can no longer boot. So there is
something happening.
Looking at the data sheet for the W39V040B, all the PZ gives me is the
PLCC package and lead free. So, is this a problem with the vt8237 south
bridge? Where should I go to start debugging?
-Adam
Hi all,
There is a problem with the ck804 code in the tree when it comes to SATA
support. I've observed this on a tyan s2891, and it has been confirmed by
folks with a sun ultra40.
This patch changes the southbridge/nvidia/ck804/ck804_early_setup.c file and
enables one extra SATA port. I've tested this on real hardware (tyan s2891).
There is a very similar file called
southbridge/nvidia/ck804/ck804_early_setup_car.c which seems to be used by
tyan/s2895
sunw/ultra40
I don't have access to a s2895, but YH thinks that all sata ports should work
on that board. It would be great if someone could verify that.
I'm not 100% sure why both the ck804_early_setup.c and the
ck804_early_setup_car.c file are included in the mainboards/sunw/ultra40/
tree; probably only one of those files is actually used.
I've spent quite a bit of time with 'dumpio' and tried to match register
values between the proprietary BIOS and LinuxBIOS, but to no avail. If
someone has ideas to get port 1 working on both sata controllers, that would
be great.
Thanks,
Ward.
--
Ward Vandewege <ward(a)fsf.org>
Free Software Foundation - Senior System Administrator
I am trying to get up to speed on LinuxBIOS and to that end have tried
to compile both v3 & v2 for qemu.
I have successfully compiled and run v3 with a filo package on my Fedora
8 system.
When I try to compile v2 with a filo.elf payload I get the :
collect2: ld terminated with signal 11 [Segmentation fault]
Error
In looking at the compile it has gotten through the compile part and is
linking.
rm -f linuxbios.a
ar cr linuxbios.a malloc.o pci_ops.o smbus_ops.o memset.o
pci_ops_auto.o linuxbios_table.o fallback_boot.o pciexp_device.o
keyboard.o pnp_device.o printk.o irq_tables.o pcix_device.o i8259.o
pci_device.o console.o elfboot.o hardwaremain.o boot.o exception.o
delay.o version.o pci_ops_mmconf.o memcmp.o isa-dma.o hypertransport.o
vtxprintf.o tables.o root_device.o cardbus_device.o uart8250.o
device_util.o ./option_table.o compute_ip_checksum.o device.o
northbridge.o memcpy.o agp_device.o vgabios.o clog2.o pirq_routing.o
memmove.o pci_ops_conf2.o pci_ops_conf1.o mc146818rtc.o rom_stream.o
c_start.o vsprintf.o cpu.o static.o
gcc -m32 -nostdlib -r -o linuxbios_ram.o c_start.o mainboard.o
uart8250_console.o linuxbios.a /usr/lib/gcc/i386-redhat-linux/4.1.2/libgcc.a
gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T
/home/mk216460/src/LinuxBIOSv2-2988/src/config/linuxbios_ram.ld
linuxbios_ram.o
collect2: ld terminated with signal 11 [Segmentation fault]
make[1]: *** [linuxbios_ram] Error 1
make[1]: Leaving directory
`/home/mk216460/src/LinuxBIOSv2-2988/targets/emulation/qemu-i386/qemu-i386/image'
In looking at the /var/log/messages you see
Nov 30 14:37:02 dhcp-uatl04-156-163 kernel: ld[3691]: segfault at
00000030 eip 08068b2c esp bfc6a0f0 error 4
Any help/pointers for what to look at would be helpful.
--
/*********************
Marc Karasek
MTS
Sun Microsystems
mailto:marc.karasek@sun.com
ph:770.360.6415
*********************/
Meant to send this to the list.
Marc
-------- Original Message --------
Subject: Re: [LinuxBIOS] AMD 690G chipset support in LinuxBIOS v2
Date: Mon, 10 Sep 2007 21:05:47 -0600
From: Marc Jones <Marc.Jones(a)AMD.com>
To: Darmawan Salihun <darmawan.salihun(a)gmail.com>
References: <46893e740709101937j32a4f32bu6dc296a628d36dc6(a)mail.gmail.com>
Darmawan Salihun wrote:
> Hi all,
> I've grepped through the source code last night but haven't found
> code for board that uses this chipset. Is there any support coming
> down the road? I'm planning to buy a new system for BIOS experiments
> in the next few days. This chipset is a candidate for me. I want a
> chipset with onboard video and K8 processor.
> I choose K8 because the datasheet for the memory controller is
> readily available. I'm open for any suggestion(s). Basically, I just
> want a system that can run Vista, support multicore processor and can
> be used for LinuxBIOS experiments (preferably without soldering stuff
> needed).
> Anyway, one further question: hot-flashing can be done on SPI
> chips as well, right?
>
>
> Regards,
>
> Darmawan Salihun
> --------------------------------------------------------------------
> -= Human knowledge belongs to the world =-
Hi Darmawan,
Currently there is no support in LinuxBIOS for any ATI(now AMD)
chipsets. We do plan to work on this in the next six months but I don't
have a specific release date.
==
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones@amd.com
http://www.amd.com/embeddedprocessors
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones@amd.com
http://www.amd.com/embeddedprocessors
On 23.09.2007 23:16, echelon(a)free.fr wrote:
> Quoting Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>:
>> OK, I have the 0.2 and 0.3 datasheet of IT8716F and I can't find any
>> difference in interfaces between the datasheets. Please be more specific
>> what you think has been replaced (including page numbers).
> Simply the pinout.. (please compare the pin-out diagram btw the 2 version of
> the DS).
I did. Pages 7-23 (Pin configuration) are exactly the same for 0.2 and
0.3. Please tell me the page number where you see any differences.
> In fact, there could be another explanation : I talked about this issue with a
> hardware specialist at my work (he has worked into the IC design..) and his
> hypothesis is that the component which is actually used on this motherboard is a
> "custom" revision especially crafted by ITE for Gigabyte.. (yes, they had
> "volume" so they could afford to make a deal for a custom revision..)
Maybe. I still want to find out why your data sheet seems to differ from
mine.
Regards,
Carl-Daniel
