I remember you saying that your SATA performance was low on this board.
Have you ever tried uncommenting the soft_reset in cache_as_ram_auto.c?
That makes it so that the HyperTransport links all run at 200 MHz 8-bit
instead of 1 GHz 16-bit (factor of 10 difference in bandwidth)
The unfortunate thing about HyperTransport is that you can't tell if it's
running at speed from the lspci. The new values are there, but only take
effect at the next soft reset.
Hi, i'm working with these mainboard fanless:
The bios chip is one Winbond W25X80,
i have released a simple circuit with one transistor
BC547, and the rest connected directly to the
paralel port in mode ECP, data buses are 3.3V
Also i have release a simple program to erase, test
and program it. If one are interesed in this, tell-me.
The flashprogram not works correctly with this chip, but
i can try to solve.
The CPU is the Atom N270, normally i used VIA's but, i will
test my aplications with it, with VIA i cannot use my SSE2
optimizations, they are more slow that direct use of 32bit
This have a Fintek SuperIO F71862FG that is similar to
The base is the ich7m and i945GSE.
I have tested and make that it works, except the VGA
and the Audio, i have solved the problems with acpi,
and linux kernel boots normally with the SATA.
I have only one problem, with the variable MTRR
if i activate variable MTRR's for have cache, the
kernel immediately makes a triple fault.
I not known if in the moment of activate MTRR this
chip generates a spurious interrupt or similar, and
when the kernel creates the IDT table, hangs.
Have one show this problem in the past?
I have send to local APIC's the EOI, but the problem
Harald Gutmann wrote:
> > * hda: UDMA/33 compared to UDMA/66 with prop. BIOS
> My suggestion would be to open up a new ML-thread according to this
> It should be "easy" to fix, and I think that it has nothing to do
> with the DMA modes itself, but with the "88pin-wire-cable-bit"
> (but I don't know if it's for real a bit which needs to be set).
Usually there is.
> I also tried to investigate that problem, but ran out of time the
> evening I started. (check kernel ide-drivers amd7xxx.c (or similar)
> to find out what's going on there).
I hope the bit we want isn't hidden in a chipset doc which we can't
-----BEGIN PGP SIGNED MESSAGE-----
Harrison, Jon (SELEX GALILEO, UK) wrote:
> Hi Folks,
> I've added initial ACPI support to my EPIA-NL/CN400 Port.
Hmm pity is that it is not here so mine help is limited.
> I think the issues are concerned with the South Bridge Init (VT8237R), There
> a bunch of USB UHCI problems reported and then the boot hangs
> configuring/mounting sda1
Perhaps it seems that PCI routing does not work. Does the CPU lacks APIC? I
think PIC only mode needs some tuning to PCI router.
I dont know how you have done the LNKA etc devices in ACPI but you need to
change the 0x55-0x57 in SB to reflect current settings.
You will need to implement _CRS and _SRS for that. Also there is some in kernel
quirk that IRQ routing (non APIC) works only if the 0x3c is written with right
value. Kernel will fix that.
OperationRegion (SREG, PCI_Config, Zero, ...
Field (SREG, ByteAcc, NoLock, Preserve)
and then for LNKA for example:
_SRS will need to parse the the IRQ resource from OS, which is stored as bitmap.
Using findsetright bit/dec create a IRQ nr and store it in the PIRA ;)
Something could be taken from amd8111_pic.asl
Second possibility would be to create a PIR table and store the right routing
values in the SB init code + ECLR should be modified. I never finished this code
for VT8237R. Check VT8235 vt8235_lpc.c for details pci_routing_fixup.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
#137: S2895 no function after coreboot 2 flash
Reporter: anonymous | Type: defect
Status: new | Priority: major
Milestone: | Component: buildrom
Version: v2 | Keywords:
Dependencies: | Patchstatus: there is no patch
I am not sure whether i am correct here with you guys. But i have some
troubles after flashing the tyan-s2895.rom that has been generated with
seabios as payload by the buildrom tool.
There are no logs in the log folders and everything worked fine.
But after flashing the coreboot bios to the board using "flashrom -v -w
tyan-s2895.rom" and i "halt" the system, it will come up for a second and
switches off immediately. I tried clearing the CMOS, but this did not
solve the problem.
Any idea what i am doing wrong?
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/137>
I've been working on some code to ensure I can debug a system even if
coreboot fails to boot an OS. The attached patch adds this code to the
- serialprobe watches the serial port for about a second, and boots
the system normally unless 32 consecutive null bytes are seen.
- xcshell allows the CPU to be controlled via the serial port, using
a binary protocol.
The code assembles to about 1 KB, so it can be left in an image for
emergency use. It's also modular in case someone wants to use it with
something other than a serial port.
xcsinterp.inc describes the protocol, and xccmd.inc describes the
Signed-off-by: Michael Gold <mgold(a)ncf.ca>
It should possible to jump to the 'xcshell' or 'serialprobe' symbol
(with the return address in ESP) as soon as the serial port is
configured and the CPU is executing 32-bit code (e.g., after
console_init in auto.c). I'm using these lines in my mainboard's
Config.lb to include the code:
I'm not sure whether there's anything that needs to be added, but
suggestions are welcome. I'm hoping the command set is sufficient to
initialise RAM, though so far I've only tested cache-as-RAM mode
(which just seems to work for data, not code).