[LinuxBIOS] [PATCH] Add support for the Asus A8V-E SE motherboard

Uwe Hermann uwe at hermann-uwe.de
Wed Oct 31 00:12:00 CET 2007


On Tue, Oct 30, 2007 at 09:58:50PM +0100, Rudolf Marek wrote:
> Hi Uwe,
>
>> Why this? Doesn't the usual method work?
>> #include "southbridge/via/vt8237r/vt8237r.h"
>
> Imho not, I tried with leading src/

The "src" is not needed. The above version should work, it does for
other boards AFAIK.


>>> +	memcpy(header->oem_id, "LXBIOS", 6);
>> "LinuxBIOS" as string? How long can the ID become?
>>> +	memcpy(header->oem_table_id, "LXBACPI ", 8);
>>> +	memcpy(header->asl_compiler_id, "LXB", 8);
>> Same here. How long?

OK, this can stay I guess. No need to change it.


>> Do you have 'superiotool -dV' output from the original BIOS so we can
>> check some of the commented values?
>
> Well I think we can enable something... Perhaps game port and midi.
>
> Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e...
> Found Winbond W83627EHF/EF/EHG/EG (id=0x88, rev=0x63) at 0x2e
> Register dump:
> idx 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
> val 88 63 ff 00 80 00 00 ff 50 04 01 00 f0 21 00 ff
> def 88 MM ff 00 MM 00 MM RR 50 04 00 RR 00 21 00 00
> LDN 0x00 (Floppy)
> idx 30 60 61 70 74 f0 f1 f2 f4 f5
> val 00 00 00 00 04 0e 00 ff 00 00
> def 01 03 f0 06 02 8e 00 ff 00 00
> LDN 0x01 (Parallel port)
> idx 30 60 61 70 74 f0
> val 01 03 78 07 03 3f
> def 01 03 78 07 04 3f

Probably needs an additional

 drq 0x74 = 3


> LDN 0x02 (COM1)
> idx 30 60 61 70 f0
> val 01 03 f8 04 00
> def 01 03 f8 04 00
> LDN 0x03 (COM2)
> idx 30 60 61 70 f0 f1
> val 00 00 00 00 00 00
> def 01 02 f8 03 00 00
> LDN 0x05 (Keyboard)
> idx 30 60 61 62 63 70 72 f0
> val 00 00 00 00 00 00 00 83
> def 01 00 60 00 64 01 0c 83
> LDN 0x06 (Serial flash interface)
> idx 30 62 63
> val 00 ff ff
> def 00 00 00

Nothing needed for this LDN, AFAICS.


> LDN 0x07 (GPIO 1, GPIO 6, game port, MIDI port)
> idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 f6 f7
> val 06 02 01 03 30 0a ff ff ff ff ff ff ff 00
> def 00 02 01 03 30 09 ff 00 00 00 ff 00 00 00

io 0x60 = 0x201
io 0x62 = 0x330
irq 0x70 = 0xa

(according to superiotool, but the current values might also work,
as far as I know these addresses are not hard requirements)


> LDN 0x08 (WDTO#, PLED)
> idx 30 f5 f6 f7
> val 00 ff 00 ff
> def 00 00 00 00
> LDN 0x09 (GPIO 2, GPIO 3, GPIO 4, GPIO 5, SUSLED)
> idx 30 e0 e1 e2 e3 e4 e5 f0 f1 f2 f3 f4 f5 f6 f7
> val 09 de 01 00 03 a4 00 ff ff ff 09 ff ff ff ff
> def 00 ff 00 00 ff 00 00 ff 00 00 00 ff 00 00 00
> LDN 0x0a (ACPI)
> idx 30 70 e0 e1 e2 e3 e4 e5 e6 e7 e8 f2 f3 f4 f6 f7
> val 00 00 01 00 ff 24 30 00 10 10 09 7c 00 00 00 00
> def 00 00 01 00 ff 08 00 RR 00 00 RR 7c 00 00 00 00
> LDN 0x0b (Hardware monitor)
> idx 30 60 61 70 f0 f1
> val 01 02 90 00 c1 3f
> def 00 00 00 00 c1 00

io 0x60 = 0x290

You can test with lm-sensors, but I guess you already know that ;-)


>>> +                                               end #end SIO
>>> +                                       end #end 11
>>> +
>>> +                                       device pci 12.0 off end # VIA LAN
>> Why off? Is this the integrated SB LAN or another onboard PCI device?
>
> yes it is in SB lan, which is not connected.

OK, add this as comment, it looks strange and people might wonder why
it's disabled.


>>> +        static const char sig[4] = "PCMP";
>>> +        static const char oem[8] = "LNXI    ";
>> Should be "ASUS    " probably, but I don't think that can break anything,
>> it's more a cosmetic issue AFAIK.
>
> We are the BIOS oem ;)
>
>>> +        static const char productid[12] = "A8V-E SE    ";

Hm, is "oem" really the _BIOS_ vendor? If so, what is productid then?
Is it really the board name? Or the BIOS version or something?


>>> Index: src/mainboard/asus/a8v-e_se/acpi_tables.c
>>> ===================================================================
>>> --- src/mainboard/asus/a8v-e_se/acpi_tables.c	(revision 0)
>>> +++ src/mainboard/asus/a8v-e_se/acpi_tables.c	(revision 0)
>>> @@ -0,0 +1,170 @@
>>> +/*
>>> + * This file is part of the LinuxBIOS project.
>>> + * written by Stefan Reinauer <stepan at openbios.org>
>>> + * ACPI FADT, FACS, and DSDT table support added by + * Nick Barker 
>>> <nick.barker9 at btinternet.com>, and those portions
>>> + *
>>> + * Copyright (C) 2007 Rudolf Marek <r.marek at assembler.cz>
>> Hm, please add
>> Copyright (C) xxxx Stefan Reinauer <stepan at openbios.org>
>> Copyright (C) xxxx Nick Barker <nick.barker9 at btinternet.com>
>> then. I think this is not done in the original file either, and should
>> be fixed there, too. Listing all copyright owners explicitly is important.
>
> What about xxxxx?

The year(s) of the copyright. 

 * (C) Copyright 2004 Nick Barker
 * (C) Copyright 2005 Stefan Reinauer

(if this is based on the epia-m version of the file)


>>> +##
>>> +## Build code to export a CMOS option table
>>> +##
>>> +default HAVE_OPTION_TABLE=0
>> Make this 1. If the file is there already, why not use it?
>
> I need to have cmos valid for old award bios, I need the defaults from the
> option table. Even if I do not write to CMOS some bits are strange and 
> confuses linuxbios configuration. I will fix together with proper CMOS 
> support.

OK.


>>> +default MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID=0x1043
>>> +#default MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID=0x1234
>> Is it really 0x1234? Looks like a dummy value, but I might be wrong.
>
> I dont know what should I put here.

The subsystem IDs of the board. lspci -vvv lists them, e.g.

 Subsystem: Micro-Star International Co., Ltd. Unknown device 7260

It's the 16-bit-values at 0x2c and 0x2e in the PCI config space
(see lspci -xxx output), in the above example:

[...]
20: 00 00 00 00 00 00 00 00 00 00 00 00 62 14 60 72
[...]

So 0x1462 is the subsystem vendor (MSI) and 0x7260 is the subsystem
device ID (note the byte order!).


HTH, Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071031/2d89dd1d/attachment.sig>


More information about the coreboot mailing list