Oskar Enoksson wrote:
> Myles Watson wrote:
>>> I think Myles was right, there is a i2c mux in this server that somehow
>>> multiplexes DIMM devices on the i2c bus. I was able to guess which i2c
>>> ports contain the DIMM info, and which port is the mux, then added the
>>> mux to devicetree.cb and the DIMM ports under it. Now I'm able to use
>>> memory from both CPU's, at least for the combination of DIMM's I have
>>> (2x2x1GB and 2x2x512MB).
>> I'm glad it worked out!
>>> So I'm basically able to use these servers now. I would love to have
>>> ACPI and Cool'nQuiet of course, perhaps I'll try to do that later.
>>> Thanks very much for all help! If you want me to commit the new
>>> mainboard to your svn repository let me know.
>> Yes, please. If you'll send your latest patch with a Signed-off-by: line,
>> I'll take it from there.
> I hope this file is the way you want it. I did "svn cp
> src/mainboard/tyan/s2881 src/mainboard/hp/dl145_g1" and then modified
> the files, then "svn diff src/mainboard" so I assume you should do the
> same svn cp operation, then apply my patch, then commit to retain the
> original files' history.
I have fixed several problems and now it boots reliably for both and
older dual Opteron 248 server and an upgraded dual Opteron 280 server.
memtest86+ doesn't work, but according to another mailinglist thread
memtest cannot handle tables in high memory, so that seems to be a
Attached is a cleaned-up patch. Thanks to Myles and others for excellent
help and support. I hope someone finds the result useful.
We found this with some testing at BTDC. This patch sets max freq
defaults for ddr2 and ddr3for fam10. It may be overridden by a
developer setting it in romstage.c.
Signed-off-by: Marc Jones <marcj303(a)gmail.com>
(cross-posted to both mailing lists)
i am currently designing a small and cheap platform to recover from
coreboot and other failures easily.
the reason i am writing this is to get feedback from you regarding
desired features of and interest in such a device.
right now my plan is the following:
an avr atmegaXXu2 is connected via usb and implements the serprog
protocol to let flashrom make use of it. the avr can operate down to
3.0V which would allow easy interfacing with today's spi flashes
without any level shifting. to get the desired supply voltage from
usb's 5V i will use a fixed 3.3V ldo voltage regulator (ld1117). apart
from a few supporting parts (caps, fuse, usb line termination etc.) the
only things missing are sockets for the spi chips.
at the moment i am planing to include:
- soic8 pads (combined for 150 and 200mil devices) and enough room for
a soic8 zif adapter (like the one from http://bios-repair.co.uk)
- vias for a 24 pin zif dip/dil socket (150 and 300mil spacing
combined): 8 pins for dip8 flashes and 16 for soic16 flashes (those
would require a soic to dip adapter). 8pin and 16pin flashes dont
share pins therefore the large socket...
- vias for a single row 8pin header to allow attaching probes/test clips
(e.g. http://www.pomonaelectronics.com/images/large/6109.jpg) to hook
up in-situ flashes.
parts for this excluding the pcb would be in the 10-25$ range.
depending on how many pcbs i/we would produce the whole thing would
cost probably about 40$. not THAT cheap, but quite better than
the dediprog stuff :)
it would also be more convenient and open than the FT2232SPI based on
the DLP-USB1232H (http://flashrom.org/FT2232SPI_Programmer). the
willem programmers seem to be lpt only? are there any other cheap
flashers i dont know?
i am not sure about what to do with soic16 chips. the solution laid out
above which requires an additional adapter and wastes a lot of space is
awkward. should i just include soic16 pads instead? should i drop
support for them altogether and let the user hook them up with clips?
are they in use anywhere? my intel desktop board has pads for it, but i
am not sure if there are any boards in the wild which really use them...
i was also thinking about an offline mode which uses an SD-card or
another flash to store/load an image for the target flash. push
buttons would activate a cloning operation. this way one could clone
chips easily without a pc, but i am not sure at all if thats worth it.
what do you think?
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
The attached changes for the AMD Persimmon board improve OS support and reduce boot time.
DOS boot from SSD drive is 640 ms. Windows 7, Windows XP, and linux can install from
DVD and boot from hard disk.
Signed-off-by: Scott Duplichan <scott(a)notabs.org>
Adds RS740 HT and internal graphics PCI ids.
Adds support for RS740 in RS690 code (some of the fam10 code from RS780).
Adds support for ECS A740GM-M.
This definitely needs more patches and fine-tuning.
Only tested on RS740.
Signed-off-by: Ivaylo Valkov <ivaylo(a)e-valkov.org>
And thank you for all the work you have done so far.
This is kind of long e-mail, so for the impatient - with these patches I
am able to initialize the RS740 chipset on the ECS A740GM-M motherboard and
boot GNU/Linux (with Xorg), but the code definitely needs more fine-tuning
All my hardware died recently, so I bought two identical ECS A740GM-M
 replacement boards with AMD RS740/740G chipset as an opportunity to
help the coreboot project gather some information. The requested
information for flashrom and the RS740 chipset is attached. One thing
led to another and I've gone a lot further - the board seems usable.
Flashrom works on the board. The flash chip is recognised as MX25L8005,
but it is actually  MX25L8006.  In spite of that I was able to
flash it and boot the proprietary BIOS and coreboot. I've experienced
some CMOS checksum errors with the proprietary BIOS after flashing, but
everything worked fine after setting the date. This does not happen
always and I can't see a pattern when it does. Should I post the
flashrom related information on the flashrom mailing list?
With flashrom working and the information on this list (and few other
places) that the RS740 is RS690 with new graphics I decided to test the
RS690 code on the board. So, after nearly a month of cut-and-paste from
mahogany_fam10 and dmb690t, new code in RS690, borrowed from RS780, ACPI
from mahogany_fam10 for the board and some modifications I ended up
with something usable. The CPU is Sempron 140 (AM3/AM2+ socket).
I have some basic and blurry understanding of the boot process. I do not
know why exactly all that I've done worked. It is fair to say that I
have read almost zero documentation. All was achieved only by reading
the available code and observing the logic. Maybe it wasn't the smartest
and safest thing to do, but worth it.
So carefully review the code. Some of it is there so I could build. It
might be irrelevant. Patches are attached.
I used a cmos.layout from mahogany_fam10 to build, but images with
enabled CONFIG_USE_OPTION_TABLE (use CMOS/NVRAM values instead of hard
coded ones) in menuconfig do not boot at all - not even single serial
line of output. With recent changes and the move of CMOS to CBFS I can't
build with that option.
I am able to boot GNU/Linux. USB, network, sound, ATA and SATA are
working. PCI worked with external graphic and network card. PCIe is not
The master and stable releases of SeaBIOS hang when there is a USB mouse
connected after printing "USB mouse initialized". USB works fine under
HT is initialized to 200MHz. The lspci output (also attached) after
coreboot loads, shows that 1.6GHz link frequency is possible. The
documented limit for RS690 is 1GHz. The RS780 code is implemented
differently, so it has k8 and fam10 support. Do you think it will be
possible to use something from RS780 code? I am not confident and
competent to make the changes myself, but I am willing to test patches
The lspci output for the board with coreboot running differs(in
places). I think it is ACPI and devicetree.cb related. Don't know how to
fix it right now.
After coreboot initializes the board, the CPU has two states - 1.9 GHz
and 2.7GHz. With proprietary BIOS the CPU can do two more - 1.5GHz and
800MHz. That is ACPI issue, righ? Before adding ACPI the only possible
frequency was 2.7GHz.
The code that prints the CPU revision (in get_cpu_revision) is taken
from RS780. I think it prints (only that!) wrong revision - "K8_10"
instead of "Fam 10". It seems it should be "eax <= 0x100fff" instead of
"eax <= 0x100f00", but as I've said I didn't read enough documentation.
I've extracted a VGA BIOS image from the proprietary BIOS and the
internal graphics card worked. Both DVI and VGA connectors work. Xorg
loads, but if the resolution is higher than or equal to 1024x768 the
screen flickers and I see horizontal lines.  When the display is
refreshed (key press, mouse move, by programs) it is awful.  For
lower resolutions it is not noticeable or even missing. This is tested
on deblobed Linux-libre kernel only, and the drivers do not load the
binary-blob firmware for 3D acceleration.
Is it possible to initialize the internal graphics on RS690/RS740 from
coreboot code and use VGA BIOS image from SeaBIOS? Like it is done for
the M2V-MX SE board? Yes I know it uses VIA chipset and it has
documentation. I guess what I am asking is, is it there enough
documentation released by AMD to make it work. I've hacked a PCI header
for the VGA BIOS image from SeaBIOS, so it can be loaded by coreboot
(vendor/device ID complains). The ROM is loaded, but SeaBIOS hangs. Not
that I was expecting to just work.
There are microcode patches for some CPUs that are non-free binary-blobs
(examine their license headers). Is it possible to make loading such
microcode configurable? I am unable to build the fam10 code without a
microcode filename. I understand that AMD (and other companies) might
not want to release such information for various reasons, but I prefer
to use "crippled" CPU instead of non-free microcode, when I am running
free software BIOS. Do I really need them for Sempron anyway? It works
without them. Didn't notice any difference in performance with them. Not
that the current state of the board can be used for measuring
performance. The work-around I am using right now is zero-filled
microcode patch file in the board directory, that does nothing.
Images of the board and the chips can be found on my "web site" .
I've copied the copyright notices from files that had such and I've used
code from. For the rest I've put a comment pointing to the file I've
borrowed from. Hope that is the right way to do it. Unfortunately the
code I used restricts me to GPLv2 only, I prefer GPLv2(or later). What
is the policy on GPLv3 (or later) code for that matter? Just thinking
for possible future contributions.
P.S. This is a lot of information (and issues). If anything has to go in
the issue tracker I will do it.