[LinuxBIOS] A8N5X port
by Robert Millan
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 /.)
10 years, 8 months
[LinuxBIOS] W39V040BPZ or vt8237. Flashing problems.
by Adam Talbot
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
11 years, 4 months
[LinuxBIOS] [Fwd: Re: AMD 690G chipset support in LinuxBIOS v2]
by Marc Jones
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
11 years, 6 months
Re: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI)
by Carl-Daniel Hailfinger
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
11 years, 6 months
[LinuxBIOS] [RFC] i82801 generic patch
by Corey Osgood
The attached patch is a unified version of the current ports of the
i82801 series currently in LinuxBIOS. Since most of the ports are nearly
identical, I've taken for each file and chosen the cleanest or best
version of the code, then checked over the datasheets to *some* of the
series, including the aa, ba, ca, and db, to make sure that it would
work. I've also made some changes here and there, mostly cleanup and
clarification. The only things left to look at are the huge difference
between this version's lpc init and the i82801er's, finding a better way
to select which chip is present on the board, and gpl headers in all
files. Anyways, comments, suggestions, even flames are welcome ;)
Testing on other chips can be done at this point as well, this is tested
and working on one model, the i82801aa.
-Corey
11 years, 6 months
[LinuxBIOS] [PATCH] Remove Bitworks IMS
by Corey Osgood
Well, as there seems to be a lot of cleaning up going on lately, might
as well add this to the docket. The attached patch removes the Bitworks
IMS, as 1) there's no video support for it, 2) no one objected when this
was discussed previously, and 3) no one seems to have one, and they
aren't readily available. Any comments are welcome.
Signed-off-by: Corey Osgood <corey_osgood(a)verizon.net>
11 years, 7 months
[LinuxBIOS] [PATCH] LAR verison field
by Alex Beregszaszi
Hi,
this adds a 32bit version field after the magic. I choose 200709061 as a starting version, where the last 1 is a counter ranging to 9, thus there can be 9 different version per day (lol).
It is not going to try any backward compatibility or workaround based on version, just bail out or skip when a different version than we are running is encountered.
It might be a better idea grouping len and offset fields after or before version field, and make then fixed by design, so we can do correct skipping instead the 16-byte aligned walking.
Note: the "/* NOTE -- This and the user-mode lar.h are NOT IN SYNC. Be careful. */" message (which is present both in include/lar.h and utils/lar/lar.h) is not valid anymore.
--
Alex
11 years, 7 months
