-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
Its here! SATA issue solved (thanks for hint VIA!). This patch adds support for the VIA VT8237S south bridge. The VT8237R programming remains unchanged (tested on mine desktop) except of reverting the small change introduced by Bari (gpio/inta setup reg 0x5b). This should go for some board specific file. The change would broke at least mine board. But seems to be needed for jakllsch.
Please someone try to fix it.
Ok now back to patch.
VT8237S peripherals:
SPI flash - works, flashing fine SATA - now works, maybe need adjustments for your PCB USB - OK works IDE - OK works Network - OK works even if the board has no own flash - new code has to be called, default MAC will be 00:00:DE:AD:BE:EF. Sound - untested may work
ACPI - works APIC - works
Please try to ack the patch quickly, because a lot of people needs to dig into those files :)
Signed-off-by: Rudolf Marek r.marek@assembler.cz
Rudolf
Rudolf Marek wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
Its here! SATA issue solved (thanks for hint VIA!). This patch adds support for the VIA VT8237S south bridge. The VT8237R programming remains unchanged (tested on mine desktop) except of reverting the small change introduced by Bari (gpio/inta setup reg 0x5b). This should go for some board specific file. The change would broke at least mine board. But seems to be needed for jakllsch.
Please someone try to fix it.
Ok now back to patch.
VT8237S peripherals:
SPI flash - works, flashing fine SATA - now works, maybe need adjustments for your PCB USB - OK works IDE - OK works Network - OK works even if the board has no own flash - new code has to be called, default MAC will be 00:00:DE:AD:BE:EF. Sound - untested may work
ACPI - works APIC - works
Please try to ack the patch quickly, because a lot of people needs to dig into those files :)
Signed-off-by: Rudolf Marek r.marek@assembler.cz
Rudolf
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIwGW53J9wPJqZRNURAoLyAJoCFu/QwvZhTjnINYl6QPe4oNcCngCgiej+ PdLlpDgskjraKY/Y14LI1wU= =3s3C -----END PGP SIGNATURE-----
-- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
acked by: Bari Ari bari@onelabs.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
As Committed revision 3567.
Rudolf
On 05.09.2008 20:21, Rudolf Marek wrote:
As Committed revision 3567.
That checkin broke EPIA-CN compilation. See http://qa.coreboot.org/log_buildbrd.php?revision=3567&device=epia-cn&... for details.
Any idea how to fix it up?
Regards, Carl-Daniel
On Sat, Sep 6, 2008 at 3:04 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 05.09.2008 20:21, Rudolf Marek wrote:
As Committed revision 3567.
That checkin broke EPIA-CN compilation. See http://qa.coreboot.org/log_buildbrd.php?revision=3567&device=epia-cn&... for details.
Any idea how to fix it up?
Unknown attribute:packed
not sure where this is, but why are we using packed anyway? it's just asking for trouble.
ron
not sure where this is, but why are we using packed anyway? it's just asking for trouble.
Because that structure maps directly to ROM layout. Maybe it will work fine without it - dont know.
Rudolf
ron minnich wrote:
not sure where this is, but why are we using packed anyway? it's just asking for trouble.
Because without packed you can not use structs to describe hardware.
GCC is allowed to change the alignment of struct members at will. And it does.
Just curious: Why would you say packed is asking for trouble?
On Wed, Sep 10, 2008 at 1:37 PM, Stefan Reinauer stepan@coresystems.de wrote:
Just curious: Why would you say packed is asking for trouble?
it's actually burned me in the past, but I am fine with it when needed. It's not needed for sysinfo for example. Some of our uses seem gratuitous.
There are cases where people naively used packed and ended up slowing down the programs by several orders of magnitude (on alpha for example).
The Xen guys used it at first and then removed it. It's worth avoiding if you can.
ron
ron minnich wrote:
On Wed, Sep 10, 2008 at 1:37 PM, Stefan Reinauer stepan@coresystems.de wrote:
Just curious: Why would you say packed is asking for trouble?
it's actually burned me in the past, but I am fine with it when needed. It's not needed for sysinfo for example. Some of our uses seem gratuitous.
There are cases where people naively used packed and ended up slowing down the programs by several orders of magnitude (on alpha for example).
The Xen guys used it at first and then removed it. It's worth avoiding if you can.
Absolutely. The only reason to use it is when
a) reading from binary files directly into a struct b) using a struct to access hardware
When GCC adds padding to the struct, it does that to increase speed when accessing the members by removing the need to do slow, unaligned accesses.
That said, using it for sysinfo sounds like a bad idea, unless writing sysinfo and reading it again is done by 2 different compilers.
Carl-Daniel Hailfinger wrote:
On 05.09.2008 20:21, Rudolf Marek wrote:
As Committed revision 3567.
That checkin broke EPIA-CN compilation. See http://qa.coreboot.org/log_buildbrd.php?revision=3567&device=epia-cn&... for details.
Any idea how to fix it up?
Regards, Carl-Daniel
Lets fix this and get the CAR patch for C7 in for V2 so we can all use GCC.
-Bari
bari wrote:
Carl-Daniel Hailfinger wrote:
On 05.09.2008 20:21, Rudolf Marek wrote:
As Committed revision 3567.
That checkin broke EPIA-CN compilation. See http://qa.coreboot.org/log_buildbrd.php?revision=3567&device=epia-cn&...
for details.
Any idea how to fix it up?
Regards, Carl-Daniel
Lets fix this and get the CAR patch for C7 in for V2 so we can all use GCC.
Any takers?
This is broken since a week now,... Should we back it out until we have CAR ready?
Stefan Reinauer wrote:
This is broken since a week now,... Should we back it out until we have CAR ready
Yes, lets back it out until CAR for C7 ready.
-Bari
-
bari -
Carl-Daniel Hailfinger -
ron minnich -
Rudolf Marek -
Stefan Reinauer