[coreboot] build service results for r6101

Dear coreboot readers! This is the automatic build system of coreboot. The developer "uwe" checked in revision 6101 to the coreboot repository. This caused the following changes: Change Log: Merge all spd_addr.h into the resp. romstage.c files. Except for one instance the spd_addr.h were now v

[coreboot] [commit] r6101 - in trunk/src/mainboard: amd/serengeti_cheetah_fam10 hp/dl165_g6_fam10 msi/ms9652_fam10 supermicro/h8dmr_fam10 supermicro/h8qme_fam10 tyan/s2912_fam10

Author: uwe Date: Sat Nov 20 21:36:40 2010 New Revision: 6101 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6101 Log: Merge all spd_addr.h into the resp. romstage.c files. Except for one instance the spd_addr.h were now very tiny, there's not much point in keeping that stuff in an ext

Re: [coreboot] [PATCH] Some more DIMM0 related cleanups and deduplication

Am 20.11.2010 21:00, schrieb Uwe Hermann: > Some more DIMM0 related cleanups and deduplication. > > - VIA VT8235: Do the shift in smbus_read_byte() as all other chipsets do. > > - spd.h: Move RC00-RC63 #defines here, they were duplicated in lots of >romstage.c files and lots of spd_addr.h f

Re: [coreboot] protected_start and __protected_start!

On Sat, Nov 20, 2010 at 5:30 AM, ali hagigat wrote: > Would you please tell me how Coreboot jumps to the label, > protected_start in src/cpu/x86/32bit? > There is a jump instruction (jmp        protected_start) in reset16.inc but > it seems it will never be executed. If you have access to qemu or

Re: [coreboot] How M2V-MX SE implemented the S4 sleep?

Hi, I am trying to understand how ASUS m2v-mx se implements S4 sleep. I think it implemented this because I tested it on a physical machine with coreboot and LINUX installed. And the machine can go to hibernation and wake up without any problem. Yeah because OS is doing the stuff. In the past

[coreboot] protected_start and __protected_start!

Would you please tell me how Coreboot jumps to the label, protected_start in src/cpu/x86/32bit? There is a jump instruction (jmpprotected_start) in reset16.inc but it seems it will never be executed. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/

[coreboot] [commit] r6099 - in trunk/src: include mainboard/amd/db800 mainboard/amd/dbm690t mainboard/amd/mahogany mainboard/amd/mahogany_fam10 mainboard/amd/norwich mainboard/amd/pistachio mainboard/

Author: oxygene Date: Sat Nov 20 11:31:00 2010 New Revision: 6099 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6099 Log: Unify DIMM SPD addressing. For Geode, change the addressing scheme to match the rest of the tree (0x50 instead of 0xa0). abuild tested. Signed-off-by: Patrick Geo

Re: [coreboot] [PATCH]Refactor SPDROM access

On Sat, Nov 20, 2010 at 12:31:14AM +0100, Patrick Georgi wrote: > A later change would be to move the 90% of spd_read_byte implementations > in the boards to a unified one (weak function) that can be overridden by > boards that really behave differently (eg. those with fixed RAM without > SPD ROMs)

[coreboot] [PATCH]Some more mptables updates

Hi, conversion of mptable.c to use mptable_write_buses is still ongoing. This patch handles a set of boards that do the bus handling reasonably similar to each other. All of them are abuild tested, none are boot tested. This patch touches: amd/dbm690t amd/mahogany amd/mahogany_fam10 amd/pistachio