#109: flash base autodetection on AMD SC520
Reporter: stepan | Owner: stepan
Type: defect | Status: new
Priority: major | Milestone:
Component: adlo | Version: v2
Keywords: | Dependencies:
Patchstatus: patch needs review |
this code has been sitting on my hard disk for a while. It drops the nasty
ifdefs and implements auto detection for AMD SC520 systems, such as the
Technologic Systems TS5300.
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/109>
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.
- 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
- ps/2 keyboard
- onboard ethernet
- vga pci-e card (??)
- any other pci card I tried
- game port
- onboard audio (not supported by alsa anyway)
- ps/2 mouse
<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 /.)
Atttached is a patch that will restore blue background and bright yellow
menu title in Bayou v0.3, after (if) the tinycurses VGA color correction
patch is applied (see an earlier thread started today).
Build and run tested under QEMU with bayou-0.3+coreboot-v3.
Does anyone know what "ELF boot notes" are? I've seen this reference in
coreboot-v2/src/arch/i386/boot/boot.c. There's a struct named elf_boot_notes
whose pointer is passed to the payload via %ebx, and a magic signature in
%eax as well.
Which is very similar to Multiboot (possibly inspired by it?), as it uses the
same registers and is therefore impossible to support both things at the same
This interface is not in v3. Does this mean it's no longer being used? If
it's still in use with v2, I could add a build option that selects between
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
> Author: stepan
> Date: 2008-08-20 11:17:30 +0200 (Wed, 20 Aug 2008)
> New Revision: 3529
> this port seems somehow broken.. Now, is it using FAILOVER, or is it not?!
Hmm. This was supposed to be more or less equivalent to the approach
taken by the serengeti_cheetah_fam10 target, but I see it isn't quite...
It works as it is (was), but I can have a look at it again if there are
stylistic issues. I might not have exercised the abuild file, though --
what would be the recommended way of doing that so as to ensure that is
in correspondence with the regular config file?
Action: First import of code basis for mainboard msi/ms6147.
Most files are taken unchange for chipset i440bx/i371eb,
but decisive changes have gone into raminit.c and debug.c,
which are thus positioned in the mainboard directory.
Mainboard is booting with dynamic memory detection.
Signed-by: Mats Erik Andersson <mats.andersson(a)gisladisker.org>
My main contribution is to implement a functional detection
of populated RAM slots. The code has proven its ability to
detect, configure, and successfully initialize memory
ranging from 16MB+16MB in one slot, up to 64MB+64MB+64MB+64MB
in two slots. The mainboard has only two SDRAM slots, but the
code is able to work with one to four slots.
Mats Erik Andersson
Noticing that the main community of users for Artec Group's LPC dongle
has been at Coreboot, I have two announcements to make:
1) The current LPC dongle model is EOL. Some components no longer exist
on the market so, after the batch we're producing this month, it's gone.
2) We're already working on a new LPC dongle to replace the current one.
In conjunction with item #2 above, we are hereby giving the Coreboot
community an opportunity to influence the design of this new product.
While we cannot guarantee that every idea submitted will be used, we
will definitely be reading all the feedback we receive.
The end result will be an even better LPC dongle that serves the growing
needs of the embedded hardware developer community.
To compare with the current dongle design, see:
Looking forward to receiving your ideas for this new LPC dongle product.
Business Development Manager
Artec Group OÜ