Dear coreboot folks,
as you all know after LinuxTag  there is going to be a coreboot
workshop/hackfest/you name it/meeting on Sunday and Monday .
The Infrastructure Projects page in the Wiki  lists a lot of things,
which we can hack on, and on Sunday morning it is planned to have a
planning session for what to work on.
If you already know of something which should be mentioned in that
session, just name it here in a reply as it won’t hurt to think about
that beforehand already.
I start by listing with what I heard already and my suggestions. (No
order of priority.)
1. Think about ACPI and romstage.c unification.
1. Implement `EARLY_CBMEM_INIT` for at least AGESA boards.
2. Get timing stuff working.
3. Integrate AGESA debug into Kconfig.
4. Optimize boot speed.
5. Suspend to RAM and resume for the ASRock E350M1.
6. Test DDR3 modules on the ASUS F2A85-M.
7. Fix the ASUS M2A-VM patch and commit it to corebootv4 repository.
8. Port the ASRock A780FullHD.
1. Try coreboot on the MiniPC system with a LX800 board.
1. Get native graphics init working on the Lenovo ThinkPad X60 (and
Dear coreboot folks,
Author: Jens Rottmann <JRottmann(a)LiPPERTembedded.de>
Date: Tue Feb 19 14:46:31 2013 +0100
AMD Fam14 boards: dimmSpd.c: Set `iobase` to `SMBUS0_BASE_ADDRESS` instead of `0xB00`
which I expanded to the ASRock E350M1, overlooking the new error
message, Linux complains about an already used base address index
calling i2c_piix4_init+0x0/0x1000 [i2c_piix4] @ 559
piix4_smbus 0000:00:14.0: SMBus base address index region 0xcd6 already in use!
piix4_smbus: probe of 0000:00:14.0 failed with error -16
The address 0xb00 was used before and this should not have been changed
with the patch above. But it did. I looked through the code but could
not find where 0xcd6 comes from. Any pointers would be very much
Hello, all. I'll be at LinuxTAG and hackathon. This mail is to ask if
someone needs some of hw I can take with me (list at the end), I won't
take it unless I have requests.
Does anybody want to share rooms to save on hotel costs?
PL2303 USB-RS232 converter
2 SOIC 8-pin clips
Thinkpad X201 (coreboot)
USB rollable keyboard
cables of all kind
gear for network
USB 3G modems
Thinkpad X230 (my next port)
Asus A8N-E (corebootable)
PLCC32 parallel flash chips
PLCC32 FWH/LPC chips
Lemote Yeeloong 2F
Lemote Fuloong 2F
Lemote Yeeloong 3A
Apple Powerbook G4
Too big for transport but I can setup SSH in advance if needed: ia64,
alpha, sparc64, SGI Indy, hppa
Am Freitag, den 10.05.2013, 01:21 -0600 schrieb David Hubbard:
> I pulled the version from http://review.coreboot.org/#/c/3200/ but my
> F2A85-M still halts in the same place:
> ASSERTION FAILED: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/Mem/Main/mmExcludeDimm.c', line 263
very strange. I did not find, how these troubles started. Was not the
ASUS F2A85-M and these RAM modules work fine in the past?
> I am using CONFIG_BOARD_ASUS_F2A85_M_DDR3_VOLT_150
I have no idea if the SMBus writes in there are actually correct as I do
not have the board to verify it. As Rudolf suggested, try with the 1.6
Volts. But if I am not mistaken you did so already without any luck.
What voltage is used with the vendor BIOS?
Could you test with other modules maybe borrowed from another system or
> I uncommented the #define IDSOPT_IDS_ENABLED in
> src/mainboard/asus/f2a85-m/OptionsIds.h and captured the serial output.
> What do you think I should pursue first, option A or B:
> Option A is where AGESA says:
> > MemClkFreq changed: 333 MHz -> 800 MHzMemFInitTableDrive
>  Start
> MemFInitTableDrive End
> > No Rtt entries
> > * ERROR Event: 04063500 Data: 0, 0, 0, 0
> > Disable DCT0 due to unsupported DIMM configuration
> > Memclk Freq: 800
> > RdPtr: 6
> It sounds like AGESA needs a table with Rtt entries?
I understood the code the way, that this is only needed, when
autodetection fails. But the values should be autodetected. Maybe you
can add some output in the loops above to see where it actually fails.
As a workaround you can try to hard code your values though.
> Option B is where AGESA says:
> > Going into training stage 2. Complete training at DDR667 is done.
> If DDR3-667 works but AGESA fails at DDR3-1600, is it possible to go back
> to DDR3-667 or try an intermediate speed, say DDR3-1333 ?
Maybe there is an option in AGESA where you can limit the maximum
$ more src/mainboard/asus/f2a85-m/buildOpts.c
#define BLDCFG_MEMORY_BUS_FREQUENCY_LIMIT DDR1866_FREQUENCY
#define BLDCFG_MEMORY_CLOCK_SELECT DDR1600_FREQUENCY
> I put a sample log at https://gist.github.com/davidhubbard/5552910
Thanks. The list’s size limit should definitely be raised so such logs
can be attached to the message.
> Here are some things I did:
> 1. cold boot after removing AC power for ~30 s
> 2. try the other DIMM in slot A1 (still just a single DIMM in the machine)
> 3. hit the reset switch a couple of times
> The manufacturer page for the memory says: 
> Tested Speed DDR3-2133 MHz
> Tested Latency 11-11-11-30 2N
> Tested Voltage 1.5 -1.6V
> SPD Speed 1600 MHz
> SPD Voltage 1.5V
> Some useful snippets from the log:
> MemoryClockSelect : 800
> AmdMemAuto: Start
> MEM PARAMS:
> BottomIo : 00E0
> MemHoleRemap : 1
> LimitBelow1TB : 1
> UserTimingMode : 0
> MemClockValue : 800
> BankIntlv : 1
> NodeIntlv : 0
> ChannelIntlv : 1
> EccFeature : 0
> PowerDown : 1
Any idea, what the above means?
> OnLineSpare : 0
> Parity : 0
> BankSwizzle : 1
> MemClr : 1
> UmaMode : 1
> UmaSize : 8192
> MemRestoreCtl : 0
> SaveMemContextCtl : 0
> ExternalVrefCtl : 0
> ForceTrainMode : 2
> Node0: 1.5V -> 800MHz
> MemClkFreq: 333 MHz
> MemClkFreq changed: 333 MHz -> 800 MHz
I am sorry to not be able to offer you a solution.
Could you try to find out with `bios_extract` for example what AGESA
version the vendor BIOS uses.
PS: David, Google Mail changed the compose interface and they send HTML
message in addition to text by default. Could you change that to just
plain text please ?
>  http://www.gskill.com/products.php?index=397
>  this is the same product:
The board does boot, but only at DDR667. (I tried each option up to DDR1600)
On Tue, May 21, 2013 at 7:19 PM, David Hubbard <
> > > If DDR3-667 works but AGESA fails at DDR3-1600, is it possible to go
> > > to DDR3-667 or try an intermediate speed, say DDR3-1333 ?
> > Maybe there is an option in AGESA where you can limit the maximum
> > frequency.
> > $ more src/mainboard/asus/f2a85-m/buildOpts.c
> > […]
> > #define BLDCFG_MEMORY_BUS_FREQUENCY_LIMIT DDR1866_FREQUENCY
> > […]
> > #define BLDCFG_MEMORY_CLOCK_SELECT DDR1600_FREQUENCY
> > […]
> This is a great suggestion.
> I have spent a few days studying the AGESA code to find out what
> frequencies it tries. I concluded that the built-in AGESA autodetection is
> very limited. It may be there is a bug in the AGESA autodetection because
> this is not the same code path generally used in vendor BIOSes. The error
> messages about missing tables are suspicious. I believe it means AMD has
> the motherboard OEM (i.e. Asus) provide parameter tables measured with a
> scope that help the timings match the production board.
> Specifically I added IDS_HDT_CONSOLE (MEM_FLOW, "MemPPSCFlow enter "
> __FILE__ ":%d\n", __LINE__); and IDS_HDT_CONSOLE (MEM_FLOW, "MemPPSCFlow
> exit " __FILE__ ":%d\n", __LINE__); to the function MemPPSCFlow() in
> I attempted setting BLDCFG_MEMORY_BUS_FREQUENCY_LIMIT and
> diff --git a/src/mainboard/asus/f2a85-m/buildOpts.c
> index 7f893f9..b9346b7 100644
> --- a/src/mainboard/asus/f2a85-m/buildOpts.c
> +++ b/src/mainboard/asus/f2a85-m/buildOpts.c
> @@ -102,7 +102,7 @@
> #define BLDCFG_AMD_PLATFORM_TYPE AMD_PLATFORM_MOBILE
> -#define BLDCFG_MEMORY_BUS_FREQUENCY_LIMIT DDR1866_FREQUENCY
> +#define BLDCFG_MEMORY_BUS_FREQUENCY_LIMIT DDR1333_FREQUENCY
> #define BLDCFG_MEMORY_MODE_UNGANGED TRUE
> #define BLDCFG_MEMORY_QUAD_RANK_CAPABLE TRUE
> #define BLDCFG_MEMORY_QUADRANK_TYPE QUADRANK_UNBUFFERED
> @@ -116,8 +116,8 @@
> #define BLDCFG_POWER_DOWN_MODE
> #define BLDCFG_ONLINE_SPARE FALSE
> #define BLDCFG_BANK_SWIZZLE TRUE
> -#define BLDCFG_TIMING_MODE_SELECT TIMING_MODE_AUTO
> -#define BLDCFG_MEMORY_CLOCK_SELECT DDR1600_FREQUENCY
> +#define BLDCFG_TIMING_MODE_SELECT TIMING_MODE_LIMITED
> +#define BLDCFG_MEMORY_CLOCK_SELECT DDR1333_FREQUENCY
> #define BLDCFG_DQS_TRAINING_CONTROL TRUE
> #define BLDCFG_IGNORE_SPD_CHECKSUM FALSE
> #define BLDCFG_USE_BURST_MODE FALSE
> I then ran make clean; make and tried booting coreboot, but hit the same
> error (ASSERTION FAILED mmExcludeDimm.c line 26). I'm going to keep trying
> lower speeds.
> I also attemped configuring coreboot with 1.65V though my memory is only
> rated to 1.60V. I checked with the vendor BIOS that the memory is at least
> bootable at 1.65V. Then I tried booting coreboot at 1.65V (without the
> previous memory bus limit), but it stopped at the same assertion.
> > Could you try to find out with `bios_extract` for example what AGESA
> > version the vendor BIOS uses.
> I have not had time to run bios_extract but I did identify that the BIOS
> file supplied on Asus' website for the F2A85-M/CSM is identical to the data
> on the chip after stripping the first 2048 bytes. For example:
> dd if=f2a85-m-asus-5103-2012.09.10.v2.10.1208.cap of=f2a85-flashrom.bin
> bs=2048 skip=1
> > PS: David, Google Mail changed the compose interface and they send HTML
> > message in addition to text by default. Could you change that to just
> > plain text please ?
> I think this is now plain-text only, please let me know if gmail sends it
> as HTML. Sorry!
would someone please be so kind and record the coreboot talks at
LinuxTag? A few of my colleagues can't be at LinuxTag, but they have
expressed interest in watching the talks if any recording is made available.
Thanks in advance!
I am trying to debug an issue on Parmer.
1) use "pm-suspend" to suspend.
2) use USB keyboard to wake up.
3) use "pm-suspend" to suspend. FAIL To SUSPEND.
After wake up by USB keyboard, I got some errors in dmesg:
[ 55.585935] Disabling IRQ #9
I don't know why this is happened. It seems that ACPI method (_PTS,
_WAK) have nothing to do with suspend and wake up.
Does anybody can help me?
1) What is the workflow of USB keyboard wake up from S3?
2) What are differences between power button wake up and USB keyboard wake up?
[ 55.585874] irq 9: nobody cared (try booting with the "irqpoll" option)
[ 55.585880] Pid: 691, comm: X Tainted: P O 3.6.11-1-ARCH #1
[ 55.585882] Call Trace:
[ 55.585884] <IRQ> [<ffffffff810daffd>] __report_bad_irq+0x3d/0xe0
[ 55.585895] [<ffffffff810db2f3>] note_interrupt+0x1a3/0x1f0
[ 55.585899] [<ffffffff810e1bdf>] ? rcu_process_callbacks+0xaf/0x5b0
[ 55.585903] [<ffffffff810d8bcf>] handle_irq_event_percpu+0xbf/0x260
[ 55.585907] [<ffffffff8105e952>] ? __do_softirq+0x122/0x240
[ 55.585910] [<ffffffff810d8db8>] handle_irq_event+0x48/0x70
[ 55.585913] [<ffffffff810dbe0a>] handle_fasteoi_irq+0x5a/0x100
[ 55.585917] [<ffffffff81017502>] handle_irq+0x22/0x40
[ 55.585921] [<ffffffff8149c04a>] do_IRQ+0x5a/0xe0
[ 55.585925] [<ffffffff8149356a>] common_interrupt+0x6a/0x6a
[ 55.585926] <EOI> [<ffffffff8149a4ed>] ? system_call_fastpath+0x1a/0x1f
[ 55.585931] handlers:
[ 55.585933] [<ffffffff812b758f>] acpi_irq
[ 55.585935] Disabling IRQ #9
Dear coreboot folks,
as LinuxTag approaches and some of the systemd developers are going to
be there, I remembered the discussion how systemd only supports exposing
performance data on EFI systems .
Christian already brought up coreboot/SeaBIOS in that discussion. H.
Peter Anvin (Syslinux) also voiced a need for a having that for non-EFI
Christin, are there any news?
Thanks to the CBMEM console, the cbmem utility can read, and the timer
work, we have performance data available now. If I am not mistaken,
Chrome OS also supports reading these values. So maybe such an interface
could be designed during LinuxTag and implemented afterward.
If I am right about Chrome OS, do the developers have any suggestions?
Are you content with your interface and can it be generalized for
different boot loaders?