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
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
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
#89: New product support - thin clients
------------------------------------+---------------------------------------
Reporter: andrey | Owner: somebody
Type: task | Status: new
Priority: major | Milestone:
Component: wiki/website/tracker | Version: v2
Keywords: | Dependencies:
Patchstatus: there is no patch |
------------------------------------+---------------------------------------
Hi guys! [[BR]]
I found that Lucida Technology Co., [http://www.lucidatech.com], sales
thin clients with LinuxBios inside -[[BR]]
[http://www.lucidatech.com/product/lt2610.htm]
[http://www.lucidatech.com/product/integrated.htm]
These are first inegrated LCD thin clients with LinuxBios I'v ever seen!
Good news, isn't it?[[BR]]
I think there should be mention about it on LinuxBios "Vendors & Products"
Wiki chapter.[[BR]]
Thanks!
--
Ticket URL: <http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/89>
LinuxBIOS <http://www.linuxbios.org/>
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>
