[coreboot] [coreboot - Bug #327] MBOX3, OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) causes windows uefi tianocore BSOD ACPI_BIOS_ERROR

[Paul Menzel via coreboot]

Issue #327 has been updated by Paul Menzel.


@Mat, on what board did you test?

@Pawel, please do not post unrelated questions to this issue here. This issue 
(#327) is not about a regression as far as I know.


Bug #327: MBOX3, OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) causes 
windows uefi tianocore BSOD ACPI_BIOS_ERROR
https://ticket.coreboot.org/issues/327#change-977

* Author: xinhua wang
* Status: New
* Priority: Normal
* Start date: 2021-12-30

https://review.coreboot.org/c/coreboot/+/27711/7/src/drivers/intel/gma/acpi/configure_brightness_levels.asl#28

this line .. OperationRegion (OPRG, SystemMemory, ASLS, 0x2000)
the 0x2000 will cause BSOD ACPI_BIOS_ERROR when booting installer, os, etc

When set to 0x1000 windows UEFI tianocore mode boots fine



---Files
dmesg.txt (76.9 KB)
results.log (204 KB)


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [RFC] What to do with the issue/bug tracker and bugs?

[Paul Menzel via coreboot]

Dear coreboot folks,


In the past an issue/bug tracker was requested, and Lynxis set it up
[1] and maintains it.

Currently, there are 109 issue, where 78 of them are open.

In the last coreboot community meeting, it was discussed, if that needs
to and could be improved, and it was decided to start a discussion on
the mailing list.

The main question to the developers is, if a issue/bug tracker is still
wanted, and, if yes, what prevents you from using it more? Unawareness?
Bad usability?

One issue already pointed out is, that the issue/bug tracker should be
better integrated with Gerrit [2].

The next question is, how open bugs could be fixed? One proposal is,
that the “subsystem” maintainers should be responsible for that, at
least that the report is looked at and responded to.


Thanks,

Paul


[1] https://ticket.coreboot.org/issues/
[2] http://review.coreboot.org/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] [ANN] coreboot community meeting this Thursday, April 27th, 2017

[Paul Menzel via coreboot]

Dear coreboot folks,


Please don’t miss the coreboot community meeting [1] this Thursday
(tomorrow) on April 27th, 2017.

Please add your topics to the pad [2].


Thanks,

Paul


[1] https://www.coreboot.org/Coreboot_community_meeting
[2] https://coreboot-meeting.pads.ccc.de/CommunityMeetingTopics?

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer

[Paul Menzel via coreboot]

[For the GRUB folks, this is about coreboot commit d67c6876 (Turn CBMEM
console into a ring buffer that can persist across reboots) [1].
Julius’ message can be find in the coreboot list archive [2].]


Dear Julius,


Am Montag, den 10.04.2017, 15:50 -0700 schrieb Julius Werner:

[…]

> The change may also cause some hiccups if you're using a newer version of
> coreboot with an older version of cbmem (or SeaBIOS or whatever else reads
> the console): it will not crash and it will still print the whole log, but
> if the log has rolled over (into "ring buffer mode") it will print lines
> out of order. This is unfortunately the best I can do with the way current
> readers are implemented. I'm of course also updating the code for cbmem so
> as soon as you deploy the new version it will be able to display buffers
> from both old and new coreboot versions correctly. (I'll send patches to
> align SeaBIOS and the Linux memconsole driver in the same manner as soon as
> the coreboot patch is approved.)

Could you please also check, if GRUB’s CBMEM console driver, and the
the command cbmemc to display it need any updates?


Thanks,

Paul


PS: Where can I get your S/MIME certificate, used to sign your email?


[1] https://review.coreboot.org/18301
[2] https://mail.coreboot.org/pipermail/coreboot/2017-April/083950.html

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Resume problems on Lenovo X60t

[Paul Menzel via coreboot]

Dear coreboot folks,


Am Freitag, den 21.04.2017, 09:32 +0200 schrieb Paul Menzel:

> Am Donnerstag, den 20.04.2017, 21:35 +0200 schrieb Paul Menzel:
> 
> > With Linux 4.11-rcX sometimes the Lenovo X60t doesn’t correctly resume
> > anymore. I still have to do some more tests, but I believe I am unable
> > to reproduce this issue with Linux 4.10.8. But as I also do not know
> > how to reproduce it, despite doing suspend and resuming, and see how it
> > goes, I cannot know for sure. With Linux 4.11-rcX, I’d say the issue
> > happens one out of ten or 15 times.
> > 
> > ```
> > 12.951: [  350.898287] BUG: unable to handle kernel paging request at 
> > f8281008
> > 12.951: [  350.898346] IP: gen2_write32+0x62/0x130 [i915]
> > 12.951: [  350.898347] *pde = 34c88067 
> > 12.951: [  350.898349] *pte =  
> > 12.951: [  350.898349] 
> > 12.951: [  350.898352] Oops: 0002 [#1] SMP
> > 12.951: [  350.898353] Modules linked in: joydev(E) wacom_w8001(E) 
> > serport(E) cpufreq_powersave(E) cpufreq_conservative(E) 
> > cpufreq_userspace(E) iTCO_wdt(E) iTCO_vendor_support(E) acpi_cpufreq(E) 
> > coretemp(E) arc4
> > (E) kvm_intel(E) lpc_ich(E) kvm(E) mfd_core(E) irqbypass(E) iwl3945(E) 
> > iwlegacy(E) i915(E) evdev(E) snd_hda_codec_analog(E) 
> > snd_hda_codec_generic(E) snd_pcsp(E) pcmcia(E) serio_raw(E) mac80211(E) 
> > rng_core(E) snd
> > _hda_intel(E) yenta_socket(E) pcmcia_rsrc(E) drm_kms_helper(E) 
> > pcmcia_core(E) snd_hda_codec(E) snd_hda_core(E) snd_hwdep(E) 
> > thinkpad_acpi(E) snd_pcm(E) drm(E) cfg80211(E) battery(E) nvram(E) 
> > i2c_algo_bit(E) snd_
> > timer(E) fb_sys_fops(E) syscopyarea(E) sysfillrect(E) snd(E) rfkill(E) 
> > sysimgblt(E) soundcore(E) video(E) ac(E) button(E) shpchp(E) tpm_tis(E) 
> > tpm_tis_core(E) tpm(E) fuse(E) parport_pc(E)
> > 12.951: [  350.898397]  ppdev(E) lp(E) parport(E) autofs4(E) ext4(E) 
> > crc16(E) jbd2(E) fscrypto(E) mbcache(E) ecb(E) cbc(E) algif_skcipher(E) 
> > af_alg(E) dm_crypt(E) dm_mod(E) sg(E) sr_mod(E) sd_mod(E) cdrom(E) ata
> > _generic(E) sdhci_pci(E) psmouse(E) sdhci(E) uhci_hcd(E) e1000e(E) 
> > ata_piix(E) ahci(E) ehci_pci(E) firewire_ohci(E) libahci(E) i2c_i801(E) 
> > libata(E) ehci_hcd(E) ptp(E) mmc_core(E) firewire_core(E) crc_itu_t(E) s
> > csi_mod(E) usbcore(E) pps_core(E) thermal(E)
> > 12.951: [  350.898429] CPU: 1 PID: 1113 Comm: kworker/u4:32 Tainted: G  
> >   E   4.11.0-rc7 #23
> > 12.951: [  350.898431] Hardware name: LENOVO 636338U/636338U, BIOS CBET4000 
> > 4.5-1596-gccdb801 04/19/2017
> > 12.951: [  350.898436] Workqueue: events_unbound async_run_entry_fn
> > 12.951: [  350.898438] task: f2588480 task.stack: f258c000
> > 12.951: [  350.898483] EIP: gen2_write32+0x62/0x130 [i915]
> > 12.951: [  350.898484] EFLAGS: 00210282 CPU: 1
> > 12.951: [  350.898486] EAX: f8281008 EBX: f8d80eb0 ECX: 0001 EDX: 
> > f818
> > 12.951: [  350.898487] ESI: f658403c EDI: 0001 EBP: f258de44 ESP: 
> > f258de14
> > 12.951: [  350.898488]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> > 12.951: [  350.898490] CR0: 80050033 CR2: f8281008 CR3: 17589000 CR4: 
> > 06d0
> > 12.951: [  350.898492] Call Trace:
> > 12.951: [  350.898537]  ? i915_gem_restore_gtt_mappings+0x1ca/0x290 [i915]
> > 12.951: [  350.898581]  ? gen9_decoupled_read64+0x270/0x270 [i915]
> > 12.951: [  350.898622]  ? gen6_ggtt_invalidate+0x25/0x30 [i915]
> > 12.951: [  350.898665]  ? i915_gem_resume+0x2d/0x80 [i915]
> > 12.951: [  350.898701]  ? i915_drm_resume+0x38/0x180 [i915]
> > 12.952: [  350.898705]  ? pci_pm_resume+0x4b/0xc0
> > 12.952: [  350.898709]  ? dpm_run_callback+0x53/0x150
> > 12.952: [  350.898713]  ? wait_for_completion+0x2a/0x140
> > 12.952: [  350.898716]  ? pci_pm_thaw+0x90/0x90
> > 12.952: [  350.898718]  ? device_resume+0x87/0x170
> > 12.952: [  350.898720]  ? async_resume+0x1e/0x50
> > 12.952: [  350.898722]  ? async_run_entry_fn+0x35/0x190
> > 12.952: [  350.898726]  ? process_one_work+0x15f/0x3a0
> > 12.952: [  350.898729]  ? worker_thread+0x39/0x470
> > 12.952: [  350.898732]  ? kthread+0xdb/0x110
> > 12.952: [  350.898734]  ? process_one_work+0x3a0/0x3a0
> > 12.952: [  350.898736]  ? kthread_create_on_node+0x30/0x30
> > 12.952: [  350.898739]  ? ret_from_fork+0x1c/0x28
> > 12.952: [  350.898741] Code: d4 a6 e1 f8 bb 02 00 00 00 89 4c 24 08 89 5c 
> > 24 04 c7 04 24 49 d1 e0 f8 e8 bc 92 c8 ff 8b 97 d4 03 00 00 8b 45 e8 8b 7d 
> > e4 01 d0 <89> 38 83 c4 24 5b 5e 5f 5d c3 8d 74 26 00 64 8b 15 00 31 57 d7
> > 12.952: [  350.898813] EIP: gen2_write32+0x62/0x130 [i915] SS:ESP: 
> > 0068:f258de14
> > 12.952: [  350.898814] CR2: f8281008
> > 12.952: [  350.898817] ---[ end trace 478b15034b0b3e6a ]---
> > ```
> > 
> > Ticket #100739 in the Freedesktop.org Bugzilla [1] tracks this issue.
> > 
> > Chris Wilson replied already.
> > 
> > > The stacktrace is mostly garbage. A register mmio goes wrong. One of
> > > the suggestions is that the ioremap of the PCI bar is invalid upon
> > > resume.
> > 
> > coreboot has the TPM patches applied, and 

Re: [coreboot] Resume problems on Lenovo X60t

[Paul Menzel via coreboot]

Dear coreboot folks,


Am Donnerstag, den 20.04.2017, 21:35 +0200 schrieb Paul Menzel:

> With Linux 4.11-rcX sometimes the Lenovo X60t doesn’t correctly resume
> anymore. I still have to do some more tests, but I believe I am unable
> to reproduce this issue with Linux 4.10.8. But as I also do not know
> how to reproduce it, despite doing suspend and resuming, and see how it
> goes, I cannot know for sure. With Linux 4.11-rcX, I’d say the issue
> happens one out of ten or 15 times.
> 
> ```
> 12.951: [  350.898287] BUG: unable to handle kernel paging request at f8281008
> 12.951: [  350.898346] IP: gen2_write32+0x62/0x130 [i915]
> 12.951: [  350.898347] *pde = 34c88067 
> 12.951: [  350.898349] *pte =  
> 12.951: [  350.898349] 
> 12.951: [  350.898352] Oops: 0002 [#1] SMP
> 12.951: [  350.898353] Modules linked in: joydev(E) wacom_w8001(E) serport(E) 
> cpufreq_powersave(E) cpufreq_conservative(E) cpufreq_userspace(E) iTCO_wdt(E) 
> iTCO_vendor_support(E) acpi_cpufreq(E) coretemp(E) arc4
> (E) kvm_intel(E) lpc_ich(E) kvm(E) mfd_core(E) irqbypass(E) iwl3945(E) 
> iwlegacy(E) i915(E) evdev(E) snd_hda_codec_analog(E) snd_hda_codec_generic(E) 
> snd_pcsp(E) pcmcia(E) serio_raw(E) mac80211(E) rng_core(E) snd
> _hda_intel(E) yenta_socket(E) pcmcia_rsrc(E) drm_kms_helper(E) pcmcia_core(E) 
> snd_hda_codec(E) snd_hda_core(E) snd_hwdep(E) thinkpad_acpi(E) snd_pcm(E) 
> drm(E) cfg80211(E) battery(E) nvram(E) i2c_algo_bit(E) snd_
> timer(E) fb_sys_fops(E) syscopyarea(E) sysfillrect(E) snd(E) rfkill(E) 
> sysimgblt(E) soundcore(E) video(E) ac(E) button(E) shpchp(E) tpm_tis(E) 
> tpm_tis_core(E) tpm(E) fuse(E) parport_pc(E)
> 12.951: [  350.898397]  ppdev(E) lp(E) parport(E) autofs4(E) ext4(E) crc16(E) 
> jbd2(E) fscrypto(E) mbcache(E) ecb(E) cbc(E) algif_skcipher(E) af_alg(E) 
> dm_crypt(E) dm_mod(E) sg(E) sr_mod(E) sd_mod(E) cdrom(E) ata
> _generic(E) sdhci_pci(E) psmouse(E) sdhci(E) uhci_hcd(E) e1000e(E) 
> ata_piix(E) ahci(E) ehci_pci(E) firewire_ohci(E) libahci(E) i2c_i801(E) 
> libata(E) ehci_hcd(E) ptp(E) mmc_core(E) firewire_core(E) crc_itu_t(E) s
> csi_mod(E) usbcore(E) pps_core(E) thermal(E)
> 12.951: [  350.898429] CPU: 1 PID: 1113 Comm: kworker/u4:32 Tainted: G
> E   4.11.0-rc7 #23
> 12.951: [  350.898431] Hardware name: LENOVO 636338U/636338U, BIOS CBET4000 
> 4.5-1596-gccdb801 04/19/2017
> 12.951: [  350.898436] Workqueue: events_unbound async_run_entry_fn
> 12.951: [  350.898438] task: f2588480 task.stack: f258c000
> 12.951: [  350.898483] EIP: gen2_write32+0x62/0x130 [i915]
> 12.951: [  350.898484] EFLAGS: 00210282 CPU: 1
> 12.951: [  350.898486] EAX: f8281008 EBX: f8d80eb0 ECX: 0001 EDX: f818
> 12.951: [  350.898487] ESI: f658403c EDI: 0001 EBP: f258de44 ESP: f258de14
> 12.951: [  350.898488]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> 12.951: [  350.898490] CR0: 80050033 CR2: f8281008 CR3: 17589000 CR4: 06d0
> 12.951: [  350.898492] Call Trace:
> 12.951: [  350.898537]  ? i915_gem_restore_gtt_mappings+0x1ca/0x290 [i915]
> 12.951: [  350.898581]  ? gen9_decoupled_read64+0x270/0x270 [i915]
> 12.951: [  350.898622]  ? gen6_ggtt_invalidate+0x25/0x30 [i915]
> 12.951: [  350.898665]  ? i915_gem_resume+0x2d/0x80 [i915]
> 12.951: [  350.898701]  ? i915_drm_resume+0x38/0x180 [i915]
> 12.952: [  350.898705]  ? pci_pm_resume+0x4b/0xc0
> 12.952: [  350.898709]  ? dpm_run_callback+0x53/0x150
> 12.952: [  350.898713]  ? wait_for_completion+0x2a/0x140
> 12.952: [  350.898716]  ? pci_pm_thaw+0x90/0x90
> 12.952: [  350.898718]  ? device_resume+0x87/0x170
> 12.952: [  350.898720]  ? async_resume+0x1e/0x50
> 12.952: [  350.898722]  ? async_run_entry_fn+0x35/0x190
> 12.952: [  350.898726]  ? process_one_work+0x15f/0x3a0
> 12.952: [  350.898729]  ? worker_thread+0x39/0x470
> 12.952: [  350.898732]  ? kthread+0xdb/0x110
> 12.952: [  350.898734]  ? process_one_work+0x3a0/0x3a0
> 12.952: [  350.898736]  ? kthread_create_on_node+0x30/0x30
> 12.952: [  350.898739]  ? ret_from_fork+0x1c/0x28
> 12.952: [  350.898741] Code: d4 a6 e1 f8 bb 02 00 00 00 89 4c 24 08 89 5c 24 
> 04 c7 04 24 49 d1 e0 f8 e8 bc 92 c8 ff 8b 97 d4 03 00 00 8b 45 e8 8b 7d e4 01 
> d0 <89> 38 83 c4 24 5b 5e 5f 5d c3 8d 74 26 00 64 8b 15 00 31 57 d7
> 12.952: [  350.898813] EIP: gen2_write32+0x62/0x130 [i915] SS:ESP: 
> 0068:f258de14
> 12.952: [  350.898814] CR2: f8281008
> 12.952: [  350.898817] ---[ end trace 478b15034b0b3e6a ]---
> ```
> 
> Ticket #100739 in the Freedesktop.org Bugzilla [1] tracks this issue.
> 
> Chris Wilson replied already.
> 
> > The stacktrace is mostly garbage. A register mmio goes wrong. One of
> > the suggestions is that the ioremap of the PCI bar is invalid upon
> > resume.
> 
> coreboot has the TPM patches applied, and is built with native graphics
> initialization.
> 
> Has anybody else experienced any issues on the Lenovo X60t?
> 
> In #coreb...@irc.freenode.net it was mentioned that there might be low
> memory corruptions on the Intel 945 devices.
> 
> I’d welcome help also 

[coreboot] Resume problems on Lenovo X60t

[Paul Menzel via coreboot]

Dear coreboot folks,


With Linux 4.11-rcX sometimes the Lenovo X60t doesn’t correctly resume
anymore. I still have to do some more tests, but I believe I am unable
to reproduce this issue with Linux 4.10.8. But as I also do not know
how to reproduce it, despite doing suspend and resuming, and see how it
goes, I cannot know for sure. With Linux 4.11-rcX, I’d say the issue
happens one out of ten or 15 times.

```
12.951: [  350.898287] BUG: unable to handle kernel paging request at f8281008
12.951: [  350.898346] IP: gen2_write32+0x62/0x130 [i915]
12.951: [  350.898347] *pde = 34c88067 
12.951: [  350.898349] *pte =  
12.951: [  350.898349] 
12.951: [  350.898352] Oops: 0002 [#1] SMP
12.951: [  350.898353] Modules linked in: joydev(E) wacom_w8001(E) serport(E) 
cpufreq_powersave(E) cpufreq_conservative(E) cpufreq_userspace(E) iTCO_wdt(E) 
iTCO_vendor_support(E) acpi_cpufreq(E) coretemp(E) arc4
(E) kvm_intel(E) lpc_ich(E) kvm(E) mfd_core(E) irqbypass(E) iwl3945(E) 
iwlegacy(E) i915(E) evdev(E) snd_hda_codec_analog(E) snd_hda_codec_generic(E) 
snd_pcsp(E) pcmcia(E) serio_raw(E) mac80211(E) rng_core(E) snd
_hda_intel(E) yenta_socket(E) pcmcia_rsrc(E) drm_kms_helper(E) pcmcia_core(E) 
snd_hda_codec(E) snd_hda_core(E) snd_hwdep(E) thinkpad_acpi(E) snd_pcm(E) 
drm(E) cfg80211(E) battery(E) nvram(E) i2c_algo_bit(E) snd_
timer(E) fb_sys_fops(E) syscopyarea(E) sysfillrect(E) snd(E) rfkill(E) 
sysimgblt(E) soundcore(E) video(E) ac(E) button(E) shpchp(E) tpm_tis(E) 
tpm_tis_core(E) tpm(E) fuse(E) parport_pc(E)
12.951: [  350.898397]  ppdev(E) lp(E) parport(E) autofs4(E) ext4(E) crc16(E) 
jbd2(E) fscrypto(E) mbcache(E) ecb(E) cbc(E) algif_skcipher(E) af_alg(E) 
dm_crypt(E) dm_mod(E) sg(E) sr_mod(E) sd_mod(E) cdrom(E) ata
_generic(E) sdhci_pci(E) psmouse(E) sdhci(E) uhci_hcd(E) e1000e(E) ata_piix(E) 
ahci(E) ehci_pci(E) firewire_ohci(E) libahci(E) i2c_i801(E) libata(E) 
ehci_hcd(E) ptp(E) mmc_core(E) firewire_core(E) crc_itu_t(E) s
csi_mod(E) usbcore(E) pps_core(E) thermal(E)
12.951: [  350.898429] CPU: 1 PID: 1113 Comm: kworker/u4:32 Tainted: G  
  E   4.11.0-rc7 #23
12.951: [  350.898431] Hardware name: LENOVO 636338U/636338U, BIOS CBET4000 
4.5-1596-gccdb801 04/19/2017
12.951: [  350.898436] Workqueue: events_unbound async_run_entry_fn
12.951: [  350.898438] task: f2588480 task.stack: f258c000
12.951: [  350.898483] EIP: gen2_write32+0x62/0x130 [i915]
12.951: [  350.898484] EFLAGS: 00210282 CPU: 1
12.951: [  350.898486] EAX: f8281008 EBX: f8d80eb0 ECX: 0001 EDX: f818
12.951: [  350.898487] ESI: f658403c EDI: 0001 EBP: f258de44 ESP: f258de14
12.951: [  350.898488]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
12.951: [  350.898490] CR0: 80050033 CR2: f8281008 CR3: 17589000 CR4: 06d0
12.951: [  350.898492] Call Trace:
12.951: [  350.898537]  ? i915_gem_restore_gtt_mappings+0x1ca/0x290 [i915]
12.951: [  350.898581]  ? gen9_decoupled_read64+0x270/0x270 [i915]
12.951: [  350.898622]  ? gen6_ggtt_invalidate+0x25/0x30 [i915]
12.951: [  350.898665]  ? i915_gem_resume+0x2d/0x80 [i915]
12.951: [  350.898701]  ? i915_drm_resume+0x38/0x180 [i915]
12.952: [  350.898705]  ? pci_pm_resume+0x4b/0xc0
12.952: [  350.898709]  ? dpm_run_callback+0x53/0x150
12.952: [  350.898713]  ? wait_for_completion+0x2a/0x140
12.952: [  350.898716]  ? pci_pm_thaw+0x90/0x90
12.952: [  350.898718]  ? device_resume+0x87/0x170
12.952: [  350.898720]  ? async_resume+0x1e/0x50
12.952: [  350.898722]  ? async_run_entry_fn+0x35/0x190
12.952: [  350.898726]  ? process_one_work+0x15f/0x3a0
12.952: [  350.898729]  ? worker_thread+0x39/0x470
12.952: [  350.898732]  ? kthread+0xdb/0x110
12.952: [  350.898734]  ? process_one_work+0x3a0/0x3a0
12.952: [  350.898736]  ? kthread_create_on_node+0x30/0x30
12.952: [  350.898739]  ? ret_from_fork+0x1c/0x28
12.952: [  350.898741] Code: d4 a6 e1 f8 bb 02 00 00 00 89 4c 24 08 89 5c 24 04 
c7 04 24 49 d1 e0 f8 e8 bc 92 c8 ff 8b 97 d4 03 00 00 8b 45 e8 8b 7d e4 01 d0 
<89> 38 83 c4 24 5b 5e 5f 5d c3 8d 74 26 00 64 8b 15 00 31 57 d7
12.952: [  350.898813] EIP: gen2_write32+0x62/0x130 [i915] SS:ESP: 0068:f258de14
12.952: [  350.898814] CR2: f8281008
12.952: [  350.898817] ---[ end trace 478b15034b0b3e6a ]---
```

Ticket #100739 in the Freedesktop.org Bugzilla [1] tracks this issue.

Chris Wilson replied already.

> The stacktrace is mostly garbage. A register mmio goes wrong. One of
> the suggestions is that the ioremap of the PCI bar is invalid upon
> resume.

coreboot has the TPM patches applied, and is built with native graphics
initialization.

Has anybody else experienced any issues on the Lenovo X60t?

In #coreb...@irc.freenode.net it was mentioned that there might be low
memory corruptions on the Intel 945 devices.

I’d welcome help also from “normal users” to reproduce this issue.


Kind regards,

Paul


[1] https://bugs.freedesktop.org/show_bug.cgi?id=100739

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org

[coreboot] List of my changes to merge for coreboot 4.6

[Paul Menzel via coreboot]

Dear coreboot folks,


It’d be great if the small changes below could be reviewed and
submitted before coreboot 4.6 is released.

   1. https://review.coreboot.org/18907/
   2. https://review.coreboot.org/18906/
   3. https://review.coreboot.org/18794/
   4. https://review.coreboot.org/18829/


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Please test current code on your devices before coreboot 4.6 release

[Paul Menzel via coreboot]

Dear persmule,


Am Freitag, den 14.04.2017, 21:59 +0800 schrieb persmule:
> 在 2017年04月14日 07:48, Paul Menzel via coreboot 写道:
> > And if you notice a regression, please send a message to the list or
> > create an issue in the issue tracker [1].

Thank you for testing coreboot on the Lenovo X230.

> On a0729d9a56, if the first boot after flash is done on dock 433615W
> (http://www.thinkwiki.org/wiki/ThinkPad_Dock_Series_3#ThinkPad_Series_3_Docking_Stations_with_USB_3.0),
> it will highly possibly fail to light the screen when trying to resume
> from suspension.

Interesting. Please report that to the issue tracker. It’d be great if
you could get the Linux messages during resume with `drm.debug=0xe`.

> Besides, if usb 3.0 ports are used before suspension,
> the screen nearly always fails to resume after suspension.

I never heard of that. An issue with the corresponding logs would be
helpful too.

> The ME region has been cleansed and shrinked to minimal size with
> me_cleaner (0ac4b4bfd).
> 
> My board status has been uploaded via commit 201b7eeb0 of its own
> repository.

Thank you!

> The tpm on my x230 seems fine.

Interesting. Linux 4.9.13 and 4.9.18 seem to be able to detect the TPM
on the Lenovo X230.

```
+[5.155247] tpm_tis 00:06: 1.2 TPM (device-id 0x0, rev-id 78)
+[5.259246] tpm tpm0: A TPM error (6) occurred attempting to read a pcr 
value
+[5.259291] tpm tpm0: TPM is disabled/deactivated (0x6)
```

`device-id 0x0` looks strange though, and the Linux driver says it’s
deactivated.

I wouldn’t think that’s expected, but I am not sure about that.


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] [RFH] Please test current code on your devices before coreboot 4.6 release

[Paul Menzel via coreboot]

Dear coreboot folks,


coreboot 4.6 is planned to be released on Monday, so please take ten
minutes, and build the current master branch for your board, flash it,
boot it, and upload the status to the board status repository.

And if you notice a regression, please send a message to the list or
create an issue in the issue tracker [1].

Currently it’s unknown if on Lenovo laptops [2], the TPM is still
works, when TPM support is selected in Kconfig. Please note, that there
were two regressions in the Linux Kernel, so that you should not use
Linux 4.9 or the Linux 4.11 release candidates for testing.

If somebody tested the different QEMU targets that’d be great too.


Thanks,

Paul


[1] https://ticket.coreboot.org/
[2] https://review.coreboot.org/10411


signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] [RFH] Review of latest AMD AGESA changes needed

[Paul Menzel via coreboot]

Dear coreboot folks,


Kyösti pushed quite some patches for review [1] to improve the AGESA
integration, and also to fix some bugs in AGESA. It’d be great, if you
could participate in reviewing, as I am not knowledgeable enough about
most of the changes, so I could only test the changes on the ASRock
E350M1, and that works.

If you have an AMD board being affected by the commits, that means
which use AGESA, it’d be great, if you also tested these changes.


Thanks,

Paul


[1] https://review.coreboot.org/#/q/status:open+project:coreboot+branch
:master+topic:agesa-wrapper-killer

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [ANN] coreboot community meeting today

[Paul Menzel via coreboot]

Dear coreboot folks,


Please don’t miss the coreboot community meeting [1] today.


Thanks,

Paul


[1] https://www.coreboot.org/Coreboot_community_meeting

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Vikings D16: First FSF Respect Your Freedom (RYF) certified mother board

[Paul Menzel via coreboot]

Dear David,


Am Donnerstag, den 30.03.2017, 07:40 +0200 schrieb David Hedlund:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> [[[ Use this signature in you own emails to campaign for it. ]]]

s/you/your/

> "The Vikings D16 Mainboard was awarded Respects Your Freedom 
> certification on March 6th, 2017. Certification details, including 
> certified source code, will be posted soon.
> 
> Purchase product: 
> https://store.vikings.net/libre-friendly-hardware/d16-ryf-certfied; - 
> https://www.fsf.org/resources/hw/endorsement/respects-your-freedom
> 
> 
> I started https://www.coreboot.org/Board:vikings/d16, can you please add 
> it to https://www.coreboot.org/Supported_Motherboards ?

You do know that it is the same board as the Asus KGPE-D16, right? So I
wonder if the marketing name *Vikings D16 Mainboard* for the server
should be listed separately.

I suggest to just add a paragraph stating that it is the same board
with coreboot pre-installed, and link to the existing page.


Thanks,

Paul


[1] https://www.coreboot.org/Board:asus/kgpe-d16

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] How to update the repository and avoid dirty tree with submodules?

[Paul Menzel via coreboot]

Dear coreboot folks,


Often I am running into problems, when updating the tree.

Normally I do `git pull --rebase` to update my branch, and rebase my
changes on top of the upstream master branch. But if something in the
submodules, under `3rdparty` changes, I get a dirty tree. The same is
true, when bisecting or checking out a very old commit.

Just today, after running `git pull --rebase`

```
$ git show
commit 3c645391c0b7272f66d842bed454c29ceb9ce0bf
Author: Marshall Dawson 
Date:   Sat Mar 25 17:49:45 2017 -0600

3rdparty/blobs: Update for AMD Stoney Ridge

Add the binaryPI file for the FT4 package and add SMU firmware to
be consumed by fanless OPNs.

Change-Id: I1c9b5ded6b494fac1553cc2ec7756a7a47386ecf
Signed-off-by: Marshall Dawson 
Reviewed-on: https://review.coreboot.org/18988
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth 

diff --git a/3rdparty/blobs b/3rdparty/blobs
index 8090bdd598..b5e64d7cf4 16
--- a/3rdparty/blobs
+++ b/3rdparty/blobs
@@ -1 +1 @@
-Subproject commit 8090bdd59853599e469b7503ea473ca12e8c681b
+Subproject commit b5e64d7cf4984dcf8e284c1878d943e88d53de5d
$ git diff
diff --git a/3rdparty/blobs b/3rdparty/blobs
index b5e64d7cf4..8090bdd598 16
--- a/3rdparty/blobs
+++ b/3rdparty/blobs
@@ -1 +1 @@
-Subproject commit b5e64d7cf4984dcf8e284c1878d943e88d53de5d
+Subproject commit 8090bdd59853599e469b7503ea473ca12e8c681b
```

In this situation, I am manually changing the directory under
`3rdparty/`, in this case `blobs`, and do `git reset --hard `
there to get a clean state.

Do you know of tricks that the submodules are, by default, always in
the state of the commits noted in the coreboot branch?

Do you have other hints or suggestions on how to work with git
submodules?


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] PS/2 Mouse on KGPE-D16

[Paul Menzel via coreboot]

Dear cb,


Am Montag, den 20.03.2017, 21:15 + schrieb c...@imap.cc:
> Has anybody had any success using a PS/2 mouse on the KGPE-D16?
> 
> I tried a few PS/2 compatible USB mice, along with an adaptor, without
> success and thought that the mice might be to blame but I've just
> confirmed a native PS/2 mouse doesn't seem to work either.
> 
> I've tried booting directly from SeaBIOS and also with GRUB2 as a
> secondary and no combination I try seems to work.

1.  Please attach all the relevant logs from coreboot, SeaBIOS, and the
Linux Kernel. Please also send us the configuration files of coreboot
and SeaBIOS.

2.  Could you please try passing `i8042.nopnp` to Linux on its command
line, and see if that changes anything?

3.  Lastly, could you please try another payload, which doesn’t rely on
ACPI. I think FreeDOS supports PS/2 mice, but I am not sure.


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] PS/2 Mouse on KGPE-D16

[Paul Menzel via coreboot]

Dear cb,


Am Montag, den 20.03.2017, 21:43 + schrieb c...@imap.cc:
> Not a silly question:
> 
> # CONFIG_DRIVERS_PS2_KEYBOARD is not set
> 
> but the PS/2 keyboard works. Is that setting essential for a mouse to
> function?

No, as SeaBIOS, Linux, and soon libpayload based payloads should be
able to initialize the mouse themselves, if I am not mistaken.


Thanks,

Paul


PS: cb, Taiidan replied using interleaved style [1]. I think, it’d be
good netiquette if you did the same, when you receive such a message.


[1] https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] HTML messages and list archive (was: Power supply and X220)

[Paul Menzel via coreboot]

Dear persmule,


Am Mittwoch, den 22.03.2017, 00:32 +0800 schrieb persmule:

[…]

You sent just an HTML message. Currently, it’s hard to read such a
message in the archive [1].

So, please send at least a plain/text part in your message. That also
benefits people using an email client (MUA) on the command line.

In my personal opinion, plain text messages (no HTML) is the least
intrusive way, as almost all messages, sent to the list, just contain
text.


Thanks,

Paul


[1] https://www.coreboot.org/pipermail/coreboot/2017-March/083705.html

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] checkpatch: Question regarding asmlinkage and storage class

[Paul Menzel via coreboot]

Dear Joe,


Am Sonntag, den 19.03.2017, 01:31 -0700 schrieb Joe Perches:
> On Sat, 2017-03-18 at 13:15 +0100, Paul Menzel wrote:
> > Dear checkpatch developers,
> > 
> > 
> > The coreboot project started using checkpatch.pl, and now some effort
> > is going into fixing issues pointed out by `checkpatch.pl`.
> > 
> > The file `src/arch/x86/acpi_s3.c` in coreboot contains the code below.
> > 
> > ```
> >    205  void (*acpi_do_wakeup)(uintptr_t vector, u32 backup_source, u32 
> > backup_target,
> >    206  u32 backup_size) asmlinkage = (void *)WAKEUP_BASE;
> > ```
> > 
> > The warning is
> > 
> > > WARNING: storage class should be at the beginning of the declaration
> > 
> > which raised the question below [2].
> > 
> > > And I am waiting for someone to answer why checkpatch.pl claims
> > > asmlinkage as a storage-class in the first place.
> 
> []
> > In coreboot the macro is defined similarly to Linux.
> > 
> > ```
> > #define asmlinkage __attribute__((regparm(0)))
> > #define alwaysinline inline __attribute__((always_inline))
> > ```
> 
> Are they similar?
> 
> $ git grep -i "define.*ASMLINKAGE\b" include
> include/linux/linkage.h:#define CPP_ASMLINKAGE extern "C"
> include/linux/linkage.h:#define CPP_ASMLINKAGE
> include/linux/linkage.h:#define asmlinkage CPP_ASMLINKAGE

Yes, for x86 (with `CONFIG_X86_32`) they are.

```
$ git grep asmlinkage | grep regparm
arch/x86/include/asm/linkage.h:#def
ine asmlinkage CPP_ASMLINKAGE __attribute__((regparm(0)))
$ nl -ba arch/x86/include/asm/linkage.h | head -11
 1  #ifndef _ASM_X86_LINKAGE_H
 2  #define _ASM_X86_LINKAGE_H
 3  
 4  #include 
 5  
 6  #undef notrace
 7  #define notrace __attribute__((no_instrument_function))
 8  
 9  #ifdef CONFIG_X86_32
10  #define asmlinkage CPP_ASMLINKAGE __attribute__((regparm(0)))
11  #endif /* CONFIG_X86_32 */
```

> I believe asmlinkage is defined just to avoid
> possible asm/c++ symbol decorations.
> 
> > In Linux, commit 9c0ca6f9 (update checkpatch.pl to version 0.10) seems
> > to have introduced the check. The commit message contains “asmlinkage
> > is also a storage type”.
> > 
> > Furthermore, `checkpatch.pl` doesn’t seem to warn about the code below.
> > 
> > ```
> > void __attribute__((weak)) mainboard_suspend_resume(void)
> > ```
> > 
> > This raises the question below.
> > 
> > > It appears coreboot proper mostly followed this placement for
> > > function attributes before. It would be nice if we were consistent,
> > > specially if checkpatch starts to complaint about these.
> > 
> > Is there another reason, besides not having that implemented?
> > 
> > I am looking forward to your answers.


Kind regards,

Paul


> > [1] https://review.coreboot.org/#/c/18865/1/src/arch/x86/acpi_s3.c@205
> > [2] https://review.coreboot.org/18865/
> > [3] https://review.coreboot.org/#/c/18865/1/src/arch/x86/acpi_s3.c@244

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] checkpatch: Question regarding asmlinkage and storage class

[Paul Menzel via coreboot]

Dear checkpatch developers,


The coreboot project started using checkpatch.pl, and now some effort
is going into fixing issues pointed out by `checkpatch.pl`.

The file `src/arch/x86/acpi_s3.c` in coreboot contains the code below.

```
   205  void (*acpi_do_wakeup)(uintptr_t vector, u32 backup_source, u32 
backup_target,
   206  u32 backup_size) asmlinkage = (void *)WAKEUP_BASE;
```

The warning is

> WARNING: storage class should be at the beginning of the declaration

which raised the question below [2].

> And I am waiting for someone to answer why checkpatch.pl claims
> asmlinkage as a storage-class in the first place.

In coreboot the macro is defined similarly to Linux.

```
#define asmlinkage __attribute__((regparm(0)))
#define alwaysinline inline __attribute__((always_inline))
```

In Linux, commit 9c0ca6f9 (update checkpatch.pl to version 0.10) seems
to have introduced the check. The commit message contains “asmlinkage
is also a storage type”.

Furthermore, `checkpatch.pl` doesn’t seem to warn about the code below.

```
void __attribute__((weak)) mainboard_suspend_resume(void)
```

This raises the question below.

> It appears coreboot proper mostly followed this placement for
> function attributes before. It would be nice if we were consistent,
> specially if checkpatch starts to complaint about these.

Is there another reason, besides not having that implemented?

I am looking forward to your answers.


Kind regards,

Paul


[1] https://review.coreboot.org/#/c/18865/1/src/arch/x86/acpi_s3.c@205
[2] https://review.coreboot.org/18865/
[3] https://review.coreboot.org/#/c/18865/1/src/arch/x86/acpi_s3.c@244

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] GNU11 and C11

[Paul Menzel via coreboot]

Dear Ron,


Am Freitag, den 17.03.2017, 22:51 + schrieb ron minnich:
> On Fri, Mar 17, 2017 at 3:32 PM Paul Menzel wrote:
> 
> > I think there is
> > no objection to move to C11, if somebody rewrites the code using GNU11
> > extensions.
> 
> Paul, the discussion I read made it clear that there were lots of
> objections to moving away from GNU11 extensions, viz.
> 
> > There are many GNU extensions
> > which are simply necessary to write sane, readable and performant code
> > (e.g. to implement non-double-evaluating MIN()/MAX() macros, to
> > cleanly control linking into particular sections, to get performant
> > code generated for IO accessor functions, etc.). The C standard by
> > itself is simply insufficient to support all systems programming use
> > cases, and if we forbade GNU extensions we'd have to rewrite
> > significant parts of coreboot in pure assembly and add weird, hardly
> > readable workarounds for many code patterns. "
> 
> Now, I don't actually agree with all this, but the decision was made to go
> with GNU11, not C11.

You quoted Julius’ reply [1]. Later he also replied [2].

> Yes, just to be clear (this has split into so many different threads
> that I'm no longer sure what the latest decision is?), I only
> (prematurely) objected to forbidding GNU extensions. Otherwise, I'm
> totally in favor of switching to C11 and not aware of any difference
> between the versions that would cause a problem for us.

So I still believe, that the “move away from GNU11 discussion” didn’t
come to a conclusion, as that wasn’t the topic of the thread. So no
decision was made. At least not announced publicly.


Thanks,

Paul


[1] https://www.coreboot.org/pipermail/coreboot/2016-November/082576.html
[2] https://www.coreboot.org/pipermail/coreboot/2016-December/082588.html

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] GNU11 and C11 (was: coreboot community meeting minutes for March 16th, 2017)

[Paul Menzel via coreboot]

Dear Ron,


Am Freitag, den 17.03.2017, 20:48 + schrieb ron minnich:
> On Fri, Mar 17, 2017 at 11:30 AM Nico Huber wrote:

> > The decision was to make explicit what was already needed for a long
> > time (already last time Clang was working). Don't worry about Clang, it
> > can digest -std=gnu11 as well [1].
> 
> If that works for this project, then I guess that's ok. Harvey, on the
> other hand, also intends to use the intel compiler (ICC). -std=gnu11 is not
> an option we would ever use.

Currently, coreboot *does* use these GNU extensions. So the code would
not built, when disallowing the compiler to use them. I think there is
no objection to move to C11, if somebody rewrites the code using GNU11
extensions.


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] OT: In-Reply-To header field (was: How to improve the boot time of the Asus KGPE-D16?)

[Paul Menzel via coreboot]

Dear Daniel,


Am Mittwoch, den 15.03.2017, 22:09 +0100 schrieb Daniel Kulesz:

[…]

> P.S.
> Hope this time I've set the Reply-To header correctly.

Note, that you need to set the *In-Reply-To* header field. The field
*Reply-To* contains the address used as recipient, when you reply to
the message.


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [Regression] Asus M2V does not boot anymore

[Paul Menzel via coreboot]

Dear coreboot folks,


This is just a small heads-up, that coreboot master doesn’t boot on the
Asus M2V. If anybody has this board, or the similar board Asus M2V-MX
SE, I’d appreciate any feedback and help in debugging.


Thanks,

Paul


[1] https://ticket.coreboot.org/issues/101

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [ANNOUNCEMENT] Please join today’s CCM

[Paul Menzel via coreboot]

Dear coreboot folks,


Another two weeks have past since the last coreboot community meeting
[1]. So please join today’s community meeting.

Please add your topics to the pad [2].

I am looking forward to talk to you there.


Thanks,

Paul


[1] https://www.coreboot.org/Coreboot_community_meeting
[2] https://coreboot-meeting.pads.ccc.de/CommunityMeetingTopics?

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How come the community meeting is hosted by proprietary software?

[Paul Menzel via coreboot]

Dear Taiidan,


Am Dienstag, den 14.03.2017, 00:36 -0400 schrieb taii...@gmx.com:
> Discord is proprietary software, why don't we use something free and 
> open source?

1. Discord is not used anymore. Where did you find this outdated
information?

2. As there were a lot of problems with the connection quality with
Discord, a different solution was needed. Currently, BlueJeans is used
[1], which is also proprietary, and it works quite well.

There should also be some information in the minutes [2].

> I would be more than pleased to set up a SIP server or something to that 
> effect (I have only 10mbps upload but I know folks who will give me a 
> VPS if I want one).
> There are plenty of FOSS softphones for every OS and you can also use a 
> desktop VoIP phone so it would be more convenient.

The main requirement is, that it is usable from within a browser, and
all major operating systems and browsers are supported, for example
with WebRTC, so that people aren’t forced to install anything.
BlueJeans also allows to phone in from outside.

If you have a free solution, that works and let’s the community meeting
to work without any issues, *and* you can set it up, I guess we will
find some volunteers to test it out. If that works, a switch can be
discussed.


Thanks,

Paul


[1] https://bluejeans.com/616384323
[2] https://coreboot-meeting.pads.ccc.de/CommunityMeetingTopics?

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Regression with new toolchain and AGESA boards

[Paul Menzel via coreboot]

Dear coreboot folks,


GCC 6.3 shipped with the new coreboot toolchain 1.44 creates code
differently causing the boot to fail with the latest commits.

Yesterday, once again, Kyösti showed how awesome he, and pushed a fix
for review [1][2].

It’d be great if you could help test that.


Thanks,

Paul


[1] https://review.coreboot.org/18622/
"AGESA: Fix SSE regression and align stack early"
[2] https://review.coreboot.org/18691/
"binaryPI: Fix SSE regression and align stack early"

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] How to access bug reports referenced with `BUG=b:XXXXXXXXX)`?

[Paul Menzel via coreboot]

Dear coreboot folks,


Looking through the commits, I saw a syntax to reference bug reports, I
hadn’t noticed before.

> BUG=b:24676003

Looking through the commits, it looks like it goes back until even 2015
[1].

How can these be accessed?

Could Gerrit be adapted to mark these strings up as links?


Thanks,

Paul


[1] http://review.coreboot.org/12347

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Inteal Leafhill : Linux SATA driver fails when used with coreboot+grub

[Paul Menzel via coreboot]

Dear Gailu,


Am Montag, den 06.03.2017, 00:28 +0530 schrieb Gailu Singh:
> I tried to find out the details for following error
> 
> ata1: SATA link down (SStatus 4 SControl 300)
> 
> As per status register description
> 
> SStatus 4 : Phy in offline mode as a result of the interface being disabled
> or running in a BIST loopback mode
> 
> Is there any chance that coreboot/grub/Linux is putting SATA in to BIST
> loopback mode?
> 
> I am trying to understand who is responsible for SATA Linux status 4 and
> possible candidates are
> a) coreboot
> b) grub
> c) Linux

Please try the latest Linux kernel version [1] – currently 4.10.1 – to
rule out any problems in that regard. Please post the logs from that
Linux kernel.


Thanks,

Paul


PS: Please just send plain text messages to mailing lists.


[1] https://www.kernel.org/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] coreboot only takes 260 ms on Lenovo 430s!

[Paul Menzel via coreboot]

Dear coreboot folks,


Kamyl pushed the board status for the Lenovo 430s, and I am excited
looking at the time stamps! Gone in 260 ms! Awesome.

(RAM training results are cached.)

```
$ more 
lenovo/t430s/4.5-1105-gd55ea7b/2017-03-03T18_41_49Z/coreboot_timestamps.txt
21 entries total:

   0:1st timestamp 1,809
   1:start of rom stage59,610 (57,800)
   2:before ram initialization 60,859 (1,249)
   3:after ram initialization  74,194 (13,334)
   4:end of romstage   75,740 (1,546)
   8:starting to load ramstage 77,081 (1,341)
  15:starting LZMA decompress (ignore for x86) 77,298 (216)
  16:finished LZMA decompress (ignore for x86) 94,003 (16,704)
   9:finished loading ramstage 94,214 (211)
  10:start of ramstage 94,296 (82)
  30:device enumeration94,299 (3)
  40:device configuration  98,818 (4,519)
  50:device enable 100,528 (1,710)
  60:device initialization 100,661 (133)
  70:device setup done 223,845 (123,183)
  75:cbmem post223,846 (1)
  80:write tables  223,847 (1)
  85:finalize chips245,080 (21,232)
  90:load payload  245,081 (1)
  15:starting LZMA decompress (ignore for x86) 245,192 (110)
  16:finished LZMA decompress (ignore for x86) 262,007 (16,815)
  99:selfboot jump 262,024 (17)

Total Time: 260,208
```

So a big thank you to everyone involved in making that possible.
phcoder, the Googlers, siro, lynxis, and many, many more. This is great
work!


Thanks,

Paul


PS: Even the SMBIOS tables contain the embedded controller strings,
which takes over 100 ms on the Lenovo X60 for example.

```
thinkpad_acpi: ThinkPad BIOS CBET4000 4.5-1105-gd55ea7b, EC G7HT29WW-3.22
```


[1] https://review.coreboot.org/cgit/board-status.git/commit/?id=a2a34b4c7

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to improve the boot time of the Asus KGPE-D16?

[Paul Menzel via coreboot]

Dear Daniel,


Am Freitag, den 03.03.2017, 10:52 +0100 schrieb Daniel Kulesz:

> > I think most of the time is spent in RAM initialization.
> > 
> >1. Do board owners with similar amount of memory (independent of the
> >   board) have similar numbers?
> >2. What are the ways to improve that? Is it possible? For example, can
> >   the modules be probed in parallel (if that isn?t done already)?
> 
> Regarding 1: I am running 128GB in 8GB modules (LRDIMMs) and
> experiencing a similar issue. With just two UDIMMs, the boot times
> are *much* faster.

That’s good to hear. Do you have concrete numbers?

> Also, the vendor BIOS is faster from the time you press the poweron
> button to the time the monitor gets a signal.

I believe that’s a design decision in coreboot, that the display can
only be initialized after RAM has been initialized. The vendor firmware
seems to be able to do it beforehand. (If I am wrong, the vendor
firmware is really fast in configuring the memory.)


Thanks,

Paul


PS: Please note, your messages is not threaded correctly, as the mail
header fields *In-Reply-To* and References are not set.

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to improve the boot time of the Asus KGPE-D16?

[Paul Menzel via coreboot]

Dear Arthur, dear Timothy,


Am Donnerstag, den 02.03.2017, 13:38 -0600 schrieb Timothy Pearson:
> On 03/02/2017 01:30 PM, Arthur Heymans wrote:
> > Paul Menzel writes:
> > 
> > > I think most of the time is spent in RAM initialization.
> > > 
> > >1. Do board owners with similar amount of memory (independent of the
> > >   board) have similar numbers?
> > >2. What are the ways to improve that? Is it possible? For example, can
> > >   the modules be probed in parallel (if that isn’t done already)?
> > > 
> > 
> > I'm not the right person to answer this since I don't know this
> > code/hardware that well, but on modern Intel hardware native code uses
> > the MRC cache to store dram training results and restore those on
> > next boots (and resume from suspend) if no change in dimm configuration
> > was detected.
> >
> > Maybe something like this could also be applied here (or maybe it's already
> > the case since it includes code to access spi flash)?
> 
> Yes, this is already implemented as an option, and it does a fairly
> decent job of reducing training overhead to almost nothing,

Interesting. What option is that?

Also, besides the file `s3nv` I don’t see anything else in CBFS. Where
is the training data cached?

[…]


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] How to improve the boot time of the Asus KGPE-D16?

[Paul Menzel via coreboot]

Dear coreboot folks,


With 128 GB of RAM consisting of eight 16 GB modules, coreboot takes
over a minute to get to the payload on the Asus KGPE-D16 even without
serial console enabled [1]. This is not much faster than the vendor
firmware.

Please note that the timings below are incorrect. Comparing it with the
timings from SeaBIOS’ `script/read_serial.py`, I’d say the time values
need to be multiplied by two. (Somebody mentioned, that the reason
might be `cbmem -t` using some scaling factor to convert the time
stamps to seconds, and that might be wrong on the board.)

```
$ more 
asus/kgpe-d16/4.5-1093-g308aeff/2017-03-01T16_03_07Z/coreboot_timestamps.txt
21 entries total:

   0:1st timestamp 24,384
   1:start of rom stage25,061 (676)
   2:before ram initialization 913,502 (888,441)
   3:after ram initialization  35,548,889 (34,635,386)
   4:end of romstage   35,642,960 (94,070)
   8:starting to load ramstage 35,647,351 (4,391)
  15:starting LZMA decompress (ignore for x86) 35,647,872 (520)
  16:finished LZMA decompress (ignore for x86) 35,695,864 (47,991)
   9:finished loading ramstage 35,696,312 (447)
  10:start of ramstage 35,696,893 (581)
  30:device enumeration35,696,897 (3)
  40:device configuration  36,639,627 (942,730)
  50:device enable 36,644,848 (5,221)
  60:device initialization 36,646,012 (1,163)
  70:device setup done 37,044,848 (398,836)
  75:cbmem post37,044,850 (1)
  80:write tables  37,044,851 (1)
  85:finalize chips37,053,950 (9,099)
  90:load payload  37,324,647 (270,697)
  15:starting LZMA decompress (ignore for x86) 37,325,042 (395)
  16:finished LZMA decompress (ignore for x86) 37,349,321 (24,278)
  99:selfboot jump 37,349,328 (7)
```

I think most of the time is spent in RAM initialization.

   1. Do board owners with similar amount of memory (independent of the
  board) have similar numbers?
   2. What are the ways to improve that? Is it possible? For example, can
  the modules be probed in parallel (if that isn’t done already)?


Thanks,

Paul


[1] 
https://review.coreboot.org/cgit/board-status.git/commit/?id=4b4b7ab5865b15ae7caa43f0a99a80772818090f21 entries total:

   0:1st timestamp 24,384
   1:start of rom stage25,061 (676)
   2:before ram initialization 913,502 (888,441)
   3:after ram initialization  35,548,889 (34,635,386)
   4:end of romstage   35,642,960 (94,070)
   8:starting to load ramstage 35,647,351 (4,391)
  15:starting LZMA decompress (ignore for x86) 35,647,872 (520)
  16:finished LZMA decompress (ignore for x86) 35,695,864 (47,991)
   9:finished loading ramstage 35,696,312 (447)
  10:start of ramstage 35,696,893 (581)
  30:device enumeration35,696,897 (3)
  40:device configuration  36,639,627 (942,730)
  50:device enable 36,644,848 (5,221)
  60:device initialization 36,646,012 (1,163)
  70:device setup done 37,044,848 (398,836)
  75:cbmem post37,044,850 (1)
  80:write tables  37,044,851 (1)
  85: 37,053,950 (9,099)
  90:load payload  37,324,647 (270,697)
  15:starting LZMA decompress (ignore for x86) 37,325,042 (395)
  16:finished LZMA decompress (ignore for x86) 37,349,321 (24,278)
  99:selfboot jump 37,349,328 (7)

Total Time: 37,324,934


signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to reduce formal issues with new contributions from corporations?

[Paul Menzel via coreboot]

Dear Julius,


Am Montag, den 27.02.2017, 13:32 -0800 schrieb Julius Werner:
> I don't think it's helpful to single out "corporate developers" as the
> black sheep that submit all the style violations. Every contributor, paid
> or hobby, new or long-time, needs to pay attention to the project
> guidelines equally. Everyone overlooks stuff some time, and it's normal
> especially for new contributors to not be quite that familiar with
> everything yet.

I certainly didn’t mean it that way. I didn’t want to single out anyone
as the black sheep. I apologize, if I offended anyone. I totally agree
with your view.

My focus on corporate developers was motivate by the following two
things.

   1. Corporate developers certainly contribute most of the commits and
  code.
   2. I believe and assume corporations have *additional* ways to reach
  “their” developers.

> Its our responsibility as reviewers (especially those of us with +2
> rights) to educate them and make sure the rules are followed before a
> patch can get submitted.
> 
> That said, I do agree that we have a lot of potential in making this easier
> and more consistent for everyone involved. I think the best tool for that
> is more automated checking... like that recent idea to make Jenkins add the
> checkpatch result visibly to its Verified+1 message.
> 
> I'm not sure if the "where" of the guidelines really makes much of a
> difference... maybe we should just make them more discoverable either way?
> Could we put a big orange "please ensure that this patch conforms to the
> style guidelines at ..." banner in Gerrit somewhere near the submit button?

Most people push the commits from the command line I guess, so that –
especially in the beginning – they won’t even access the Web interface?

For corporations the following ideas came to my mind. The assumption is
that in corporations people are higher to see the colleagues in person
or to be in the same building.

   1. In each division there is some kind of QA person “holding the hands”
  for the first commit.
   2. Before somebody starts working on coreboot there is a small
  introduction by a colleague already familiar with the guidelines.
   3. Do for example Intel, Google or Siemens have documents (tutorials,
  videos, presentations) they could share? Would it make sense to
  create those?

[…]

Regarding improving the documentation, I guess everyone agrees (and
nobody wants/likes to do it). In my opinion the easiest way would be to
copy as much as possible from other project (like the Linux kernel).
Though that should be discussed separately.


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] payload coreinfo - no button press works

[Paul Menzel via coreboot]

Dear i1w5d7gf38keg,


Am Sonntag, den 26.02.2017, 21:23 +0100 schrieb i1w5d7gf38...@tutanota.com:
> Hardware: g41m-es2l, latest coreboot git, latest seabios git, native
> vga, ps2 keyboard + usb keyboard

Please always add the commit hashes to your reports, as reading the
mailing list archive [1] in the future, “latest” is harder to map to a
specific commit.

> I liked to try out coreinfo. It show the CPU Information page at
> start. When i then press any button (f1,f2,a,b,c,d) nothing happens.
> I also cant reboot by pressing ctrl+alt+del. Have to press the ATX-
> power-on/off-button.
> 
> I then shut down and connected a USB-Keyboard. I pressed in Seabios
> esc (usb keyboard is working) and then inside coreinfo i was again
> unable to get any functionality by pressing some button.

The payload *coreinfo* works with QEMU for me, so I guess it’s an issue
with the board. Please verify, if there are any differences if you use
the payload *coreinfo* directly. (The problem will probably be the
same.)

Then please try the same payload files/setup (SeaBIOS, coreinfo) with a
coreboot image built for QEMU.

If it works for you there, the reason is probably incomplete support
for your device. Please provide debug logs. Remember, that this is one
of the main advantages of coreboot, that you get elaborate messages.

Though, I have no idea, if somebody will have time and motivation to
fix this. So you might have to fix this yourself.

To not forget about this, and document this issue, it’d be great if you
created an issue in the coreboot bug tracker [2], and attach your
config files and captured log messages there.


Thanks,

Paul


PS: It’d be great, if you just send plain text messages with no HTML
parts to mailing lists.


[1] https://www.coreboot.org/pipermail/coreboot/2017-February/083418.html
[2] https://ticket.coreboot.org/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] ACPI S3 and S0ix (S0i3)

[Paul Menzel via coreboot]

Dear coreboot folks,


Recently in Linux and coreboot, support for the “S0ix states” [1] is
introduced.

> S0ix-states represent the residency in the Intel® SoC idle standby
> power states. The S0ix states shut off part of the SoC when they are
> not in use. The S0ix states are triggered when specific conditions
> within the SoC have been achieved, for example: certain components
> are in low power states. The SoC consumes the least amount of power
> in the deepest (for example, S0i3) state.
> 
> On Linux*, Android*, and Chrome* OS, ACPI-SState represent the
> system’s residency in the ACPI Suspend-To-RAM (S3). In the Suspend-
> To-RAM state, the Linux kernel powers down many of the systems’
> components while maintaining the system’s state in its main memory.
> The system consumes the least amount of power possible while in the
> Suspend-To-RAM state. Note that any wakelock will prevent the system
> from entering the Suspend-To-RAM state.

Microsoft Windows calls this *Connected Standby* [2], and I think
supports this since 2013 or 2014.

If I understand it correctly, the motivation is to decrease time to
“wake-up”, and also to keep the device always connected to the network.
As some devices still draw a little power compared to ACPI S3, the
power usage during S0i3 is a little higher.

Is at least the first item needed with coreboot? The Google Veyron_jaq
Chromebook (Medion AKOYA S2013) I have, is done resuming as soon the
lid if fully opened. Depending on the WLAN, I believe it’s also
reconnected quite fast.

Is Chrome OS going to use the new S0i3 over S3 in the future?


Thanks,

Paul


[1] https://software.intel.com/en-us/node/544551
[2] 
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/f46fc046-91bf-4d7c-bfb4-55e7554e3b98/clarification-on-system-states?forum=wdk

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] How to reduce formal issues with new contributions from corporations?

[Paul Menzel via coreboot]

Dear coreboot folks,


It’s great to see, that there a quite a few contributions – even the
majority – from people paid to do coreboot work.

Especially Intel and Google seem to employ a lot of developers working
on coreboot, and a lot of them push patches up for review. That’s
great.

My impression is though, that a lot of these contributions have formal
issues in the beginning. As the coding style and the commit message
guide lines are well documented in our Wiki [1][2], and there are even
scripts checking commits, the developers starting to work on coreboot
just don’t seem to know about this.

How can this be improved?

Could the companies make sure, that there developers read those, and
use the scripts?

Should this documentation be moved to the repository? A lot of the
“guideline Wiki pages” are locked anyway. People knowing the Linux
kernel, would expect that to also live in the source code repository?


Thanks,

Paul


[1] https://www.coreboot.org/Coding_Style
[2] https://www.coreboot.org/Git#Commit_messages

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] Always include coreboot banner in console independent of log level

[Paul Menzel via coreboot]

Dear Martin, dear Julius,


Am Freitag, den 24.02.2017, 16:41 -0700 schrieb Martin Roth:
> My argument is that if nothing at all is shown, its difficult to know if
> that's because nothing needs to be shown, or because the console is busted.

That was my original motivation too. The image for QEMU with log level
WARNING, didn’t print anything to the console, so I didn’t know if QEMU
was called incorrectly, or if there was another problem with the build.

> Maybe we break up the banner, and don't print both romstage and
> ramstage banners, but just the romstage banner.  I'd say that just printing
> the coreboot version should be sufficient, especially since the build date
> is based on the commit id:
> 
> So at loglevel 0, we get:
>   coreboot-4.5-1079-g613350897d

But can’t the version for romstage and ramstage differ? (Though very
unlikely.)

> At loglevel 5 (or whatever) we get the additional text:

With the current definitions, it should be log level 6 (INFO). 5
(NOTICE) is “Normal but significant conditions.”, while 6 (INFO) is
“Informational messages.”. (No idea how “significant” condition is
defined.)

>coreboot-4.5-1079-g613350897d Fri Feb 24 14:59:42 UTC 2017 romstage
> starting...

Julius, do you have any measurements, how much time printing 100
characters over the serial console would take?

Also, does that really matter for production systems? What log level
are they normally shipped with?


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] Always include coreboot banner in console independent of log level

[Paul Menzel via coreboot]

Dear Ron,


Am Freitag, den 24.02.2017, 21:56 + schrieb ron minnich:
> I agree with you. Always avoid new options.

Good. ;-)

> Just print the banner at spew. That's what spew is there for.

Hmm, as written, in my opinion the log level for that should actually
be lower, and not higher.

Could you please elaborate, why you think always having a banner is
useless?


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [RFC] Always include coreboot banner in console independent of log level

[Paul Menzel via coreboot]

Dear coreboot folks,


Playing a little with the log levels and QEMU, it turns out that there
are no coreboot messages below the log level *NOTICE*.

This is expected, but like with SeaBIOS, it’d be a good idea in my
opinion to at least output the “banner” of romstage and ramstage.

```
coreboot-4.5-1079-g613350897d Fri Feb 24 14:59:42 UTC 2017 romstage starting...

coreboot-4.5-1079-g613350897d Fri Feb 24 14:59:42 UTC 2017 ramstage starting...
```

This doesn’t map with the current log level description. Here are the
log levels with their help text from `src/console/Kconfig`.

> config DEFAULT_CONSOLE_LOGLEVEL_8
>   bool "8: SPEW"
>   help
> Way too many details.
> config DEFAULT_CONSOLE_LOGLEVEL_7
>   bool "7: DEBUG"
>   help
> Debug-level messages.
> config DEFAULT_CONSOLE_LOGLEVEL_6
>   bool "6: INFO"
>   help
> Informational messages.
> config DEFAULT_CONSOLE_LOGLEVEL_5
>   bool "5: NOTICE"
>   help
> Normal but significant conditions.
> config DEFAULT_CONSOLE_LOGLEVEL_4
>   bool "4: WARNING"
>   help
> Warning conditions.
> config DEFAULT_CONSOLE_LOGLEVEL_3
>   bool "3: ERR"
>   help
> Error conditions.
> config DEFAULT_CONSOLE_LOGLEVEL_2
>   bool "2: CRIT"
>   help
> Critical conditions.
> config DEFAULT_CONSOLE_LOGLEVEL_1
>   bool "1: ALERT"
>   help
> Action must be taken immediately.
> config DEFAULT_CONSOLE_LOGLEVEL_0
>   bool "0: EMERG"
>   help
> System is unusable.

In my opinion, it’d be a good idea to make an exception for the banner.

What do you think? Another solution would be, to make that a separate
Kconfig option like `CONSOLE_ALWAYS_PRINT_BANNER`, but I’d like to not
add other configuration options, if it’s not needed.


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] QA: Properly relay results of `checkpatch.pl` check

[Paul Menzel via coreboot]

Dear Martin,


Am Donnerstag, den 23.02.2017, 16:47 -0700 schrieb Martin Roth:

> checkpatch is currently not a gating item in jenkins and should always
> pass right now.  The checkpatch build was added to jenkins to allow people
> to see at the results of the console output for the patch without having to
> download and run checkpatch themselves.
> 
> Unfortunately, checkpatch is a lot stricter than we want to be.  It would
> require someone who fixes a misspelling on a line to also fix any other
> mistakes on that line.  Because of this, we don't want to fail the patch
> based on checkpatch errors styleguide issues.  We had discussed adding a
> non-failing 'lint' flag to gerrit to notify people that checkpatch was
> failing so that they could go look at it, but due to people's workloads,
> this hasn't happened yet.  Honestly, it's probably fallen off the radar.

The non-failing option, would indeed be a good compromise. I believe,
that right now the *SUCCESS* message is confusing, letting most people
think, that there are *no* problems. Could the message be adapted, or
is that a Gerrit/Jenkins limitation?

> Personally, I still think it's a bad idea to refuse patches that don't pass
> checkpatch, but I'd be glad to discuss it.

The other option would be, to make it a “gating item”, and see how many
of the unwanted situations occur. If it’s only a few, then the change-
set owner, could just add a comment, that it’s a such a situation
(“false positive”), and the Gerrit administrators could override the
result.

It’d be interesting, if that will be less work in the end, as less
reviewer time is spent on commenting the formal issues.

> Also, the error you mentioned WAS noticed, and fixed in a follow-on patch
> so that it could be pulled back into the chromium tree.

Yes, I know. I am sorry for not making that more clear in my message.


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] QA: Properly relay results of `checkpatch.pl` check

[Paul Menzel via coreboot]

Dear coreboot folks,


Each commit pushed to Gerrit is automatically tested for “formal”
issues by using `checkpatch.pl`. See for example [1].

Though despite missing a space violating our coding style, which is
also found by `checkpatch.pl` [2], the comment contains, that no errors
is found.

> https://qa.coreboot.org/job/coreboot-checkpatch/5142/ : SUCCESS

```
ERROR: space required before the open brace '{'
#49: FILE: src/mainboard/google/gru/pwm_regulator.c:61:
+   } else if (IS_ENABLED(CONFIG_BOARD_GOOGLE_KEVIN) && board_id() >= 6){

total: 1 errors, 0 warnings, 49 lines checked
```

Is there a reason for not relaying these errors?

If not, it’d be great to do so (and for the Chromium and Intel folks to
also do that in their repository).


Thanks,

Paul


[1] https://review.coreboot.org/18460
[2] https://qa.coreboot.org/job/coreboot-checkpatch/5142/console

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Ramstage region overlap with QEMU armv7 and GRUB (was: What payloads are easily usable with ARM targets?)

[Paul Menzel via coreboot]

Dear coreboot folks,


Am Freitag, den 17.02.2017, 09:28 +0100 schrieb Paul Menzel:

> What payload can be easily build and used for ARM targets?
> 
> If you have any scripts, could you please share those? Maybe they can
> be integrated into coreboot, so that there is also a default payload
> available for ARM targets.
> 
> Building GRUB resulted in a payload that is too big. I’ll try building
> with a bigger ROM chip size for the target *QEMU armv7* later.

It looks like, there is actually enough room, but cbfstool claims there
is an overlap.

```
[…]
CBFS   fallback/payload
INFO: Performing operation on 'COREBOOT' region...
ERROR: Ramstage region _postram_cbfs_cache overlapped by: fallback/payload
```

But there is enough room available. Any idea, what is going on? The
commands below work just fine.

```
$ git describe --tag
4.5-1004-g17335fab17
$ make V=1
[…]
printf "CBFS   fallback/payload\n"
CBFS   fallback/payload
build/util/cbfstool/cbfstool build/coreboot.pre.tmp add-payload -f 
payloads/external/GRUB2/grub2/build/default_payload.elf -n fallback/payload -t 
payload -c LZMA  -r COREBOOT   
true
mv build/coreboot.pre.tmp build/coreboot.pre
programs=$( build/util/cbfstool/cbfstool build/coreboot.pre print -v | sed -n 
'\%fallback/payload%,\%^[^ ]\{4\}%s%.*load: \(0x[0-9a-fA-F]*\),.*length: 
[0-9]*/\([0-9]*\).*%\1 \2%p' ; ) ; \
regions=$( echo ramstage ; arm-linux-gnueabi-objdump -t 
build/cbfs/fallback/ramstage.elf | sed -n '/ _ramstage$/s/^\([0-9a-fA-F]*\) 
.*/0x\1/p' ; arm-linux-gnueabi-objdump -t build/cbfs/fallback/ramstage.elf | 
sed -n '/ _eramstage$/s/^\([0-9a-fA-F]*\) .*/0x\1/p' ;   echo 
postram_cbfs_cache ; arm-linux-gnueabi-objdump -t 
build/cbfs/fallback/ramstage.elf | sed -n '/ 
_postram_cbfs_cache$/s/^\([0-9a-fA-F]*\) .*/0x\1/p' ; arm-linux-gnueabi-objdump 
-t build/cbfs/fallback/ramstage.elf | sed -n '/ 
_epostram_cbfs_cache$/s/^\([0-9a-fA-F]*\) .*/0x\1/p' ;   echo stack ; 
arm-linux-gnueabi-objdump -t build/cbfs/fallback/ramstage.elf | sed -n '/ 
_stack$/s/^\([0-9a-fA-F]*\) .*/0x\1/p' ; arm-linux-gnueabi-objdump -t 
build/cbfs/fallback/ramstage.elf | sed -n '/ _estack$/s/^\([0-9a-fA-F]*\) 
.*/0x\1/p' ;   echo ttb ; arm-linux-gnueabi-objdump -t 
build/cbfs/fallback/ramstage.elf | sed -n '/ _ttb$/s/^\([0-9a-fA-F]*\) 
.*/0x\1/p' ; arm-linux-gnueabi-objdump -t build/cbfs/fallback/ramstage.elf | 
sed -n '/ _ettb$/s/^\([0-9a-fA-F]*\) .*/0x\1/p' ; ) ; \
pstart= ; pend= ; \
for x in $programs; do \
if [ -z $pstart ]; then pstart=$(($x)) ; continue ; fi ; \
pend=$(($pstart + $x)) ; \
rname= ; rstart= ; rend= ; \
for y in $regions ; do \
if [ -z $rname ]; then rname=$y ; continue ; fi ; \
if [ -z $rstart ]; then rstart=$(($y)) ; continue ; fi ; \
rend=$(($y)) ; \
if [ $pstart -lt $rend -a $rstart -lt $pend ]; then \
echo "ERROR: Ramstage region _$rname overlapped by:" \
  fallback/payload ; \
exit 1 ; \
fi ; \
rname= ; rstart= ; rend= ; \
done ; \
pstart= ; pend= ; \
done
INFO: Performing operation on 'COREBOOT' region...
ERROR: Ramstage region _postram_cbfs_cache overlapped by: fallback/payload
```

Commit fffee873c86 (Makefile: Add build-time overlap check for programs
loaded after coreboot) [1] adds this check.


Thanks,

Paul


[1] https://review.coreboot.org/13949

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] What payloads are easily usable with ARM targets?

[Paul Menzel via coreboot]

Dear coreboot folks,


What payload can be easily build and used for ARM targets?

If you have any scripts, could you please share those? Maybe they can
be integrated into coreboot, so that there is also a default payload
available for ARM targets.

Building GRUB resulted in a payload that is too big. I’ll try building
with a bigger ROM chip size for the target *QEMU armv7* later.


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Building working QEMU armv7 image with Debian toolchain

[Paul Menzel via coreboot]

Dear coreboot folks,


Though not supported officially, I’d like to share, that I successfully
built the board *QEMU armv7 (vexpress-a9)* with the Debian ARM
toolchain from Debian Sid/unstable, and it worked with QEMU 2.8.0.

```
$ /usr/bin/arm-linux-gnueabi-gcc --version | head -1
arm-linux-gnueabi-gcc (Debian 6.3.0-5) 6.3.0 20170124
$ qemu-system-arm -version
QEMU emulator version 2.8.0(Debian 1:2.8+dfsg-2)
Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers
```

There are three crosscompilers for ARM in Debian.

1.  gcc-arm-linux-gnueabi
2.  gcc-arm-linux-gnueabihf
3.  gcc-arm-none-eabi

I wanted to install none-eabi, but just noticed, that by mistake
installed the package *gcc-arm-linux-gnueabi*. (No idea if that matters
for emulated boards like QEMU.)

Which one should be correct? The crossgcc script, sets the line below.

```
util/crossgcc/Makefile: @$(MAKE) build_tools BUILD_PLATFORM=arm-eabi
```

Anyway, running the resulting coreboot image with no payload, works.

```
$ git log --oneline -1
231c198e2c mainboard/google/eve: Generate FPC device using SPI SSDT generator
$ git describe --tag
4.5-991-g231c198e2c
$ build/cbfstool build/coreboot.rom print
Name   Offset Type Size
cbfs master header 0x0cbfs header  32
fallback/romstage  0x80   stage8964
fallback/ramstage  0x23c0 stage17728
config 0x6940 raw  117
revision   0x6a00 raw  575
(empty)0x6c80 null 4035096
header pointer 0x3dfec0   cbfs header  4
$ qemu-system-arm -machine vexpress-a9 -nographic -bios build/coreboot.rom
pulseaudio: set_sink_input_volume() failed
pulseaudio: Reason: Invalid argument
pulseaudio: set_sink_input_mute() failed
pulseaudio: Reason: Invalid argument


coreboot-4.5-991-g231c198e2c Thu Feb 16 07:42:38 UTC 2017 bootblock starting...
Exception handlers installed.
CBFS @ 20100 size 3dff00
CBFS: 'Master Header Locator' located CBFS at [20100:40)
CBFS: Locating 'fallback/romstage'
CBFS: Found @ offset 80 size 2304


coreboot-4.5-991-g231c198e2c Thu Feb 16 07:42:38 UTC 2017 romstage starting...
CBFS @ 20100 size 3dff00
CBFS: 'Master Header Locator' located CBFS at [20100:40)
CBFS: Locating 'fallback/ramstage'
CBFS: Found @ offset 23c0 size 4540


coreboot-4.5-991-g231c198e2c Thu Feb 16 07:42:38 UTC 2017 ramstage starting...
Exception handlers installed.
Enumerating buses...
Show all devs... Before device enumeration.
Root Device: enabled 1
I2C: 00:06: enabled 1
Compare with tree...
Root Device: enabled 1
 I2C: 00:06: enabled 1
Root Device scanning...
root_dev_scan_bus for Root Device
I2C: 00:06 enabled
root_dev_scan_bus for Root Device done
scan_bus: scanning of bus Root Device took 0 usecs
done
Allocating resources...
Reading resources...
Root Device read_resources bus 0 link: 0
I2C: 00:06 missing read_resources
Root Device read_resources bus 0 link: 0 done
Done reading resources.
Show resources in subtree (Root Device)...After reading.
 Root Device child on link 0 I2C: 00:06
  I2C: 00:06
Setting resources...
Root Device assign_resources, bus 0 link: 0
Root Device assign_resources, bus 0 link: 0
Done setting resources.
Show resources in subtree (Root Device)...After assigning values.
 Root Device child on link 0 I2C: 00:06
  I2C: 00:06
Done allocating resources.
Enabling resources...
done.
Initializing devices...
Root Device init ...
Devices initialized
Show all devs... After init.
Root Device: enabled 1
I2C: 00:06: enabled 1
Finalize devices...
Devices finalized
Could not add CBMEM for coreboot table.
CBFS @ 20100 size 3dff00
CBFS: 'Master Header Locator' located CBFS at [20100:40)
CBFS: Locating 'fallback/payload'
CBFS: 'fallback/payload' not found.
Payload not loaded.
```

So, using the Debian toolchain seems to work quite fine for those
wanting to save the time to build the coreboot toolchain. But keep in
mind it’s currently not supported officially.

The Debian toolchain also builds working images for the Lenovo X60
(Debian 8 (stable) with GCC 4.9.2) and the ASRock E350M1 (Debian 9
(unstable/sid) with GCC 6.3 (tested since GCC 4.9.2)).


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Working with flash emulator traces (Dediprog EM100Pro)

[Paul Menzel via coreboot]

Dear coreboot folks,


At work, I have access to a Dediprog EM100Pro, and I am currently to
use it to test coreboot on the Asus KGPE-D16.

The utility em100 for the emulator [1], also provides the switch `
--trace`, and the output looks like below [2].

```
Time: 00. command # 1  : 0x03 - read
00f0 : e9 25 f4 ff 
Time: 00.0879 command # 2  : 0x03 - read
00c0 : 00 00 00 00 
Time: 00.1635 command # 3  : 0x03 - read
00c4 : 00 00 00 00 
Time: 00.2333 command # 4  : 0x03 - read
00c8 : 00 00 Warning: EM100pro sends too much data.
00 00 
Time: 00.3024 command # 5  : 0x03 - read
00cc : 00 00 00 00 
Time: 00.3780 command # 6  : 0x03 - read
00d0 : 00 00 00 00 
Time: 00.4471 command # 7  : 0x03 - read
00d4 : 00 00 00 00 
Time: 00.5227 command # 8  : 0x03 - read
00d8 : 00 00 00 00 
Time: 00.5918 command # 9  : 0x03 - read
00dc : 00 00 00 00 
Time: 00.6674 command # 10 : 0x03 - read
00e0 : 00 00 00 00 
Time: 00.7373 command # 11 : 0x03 - read
00e4 : 00 00 00 00 
Time: 00.8064 command # 12 : 0x03 - read
00e8 : 00 00 00 00 
Time: 00.8820 command # 13 : 0x03 - read
00ec : 00 00 00 00 
Time: 00.9576 command # 14 : 0x03 - read
00f0 : e9 25 f4 ff 
Time: 00.00010267 command # 15 : 0x03 - read
00f4 : ff 66 90 66 
Time: 00.00011023 command # 16 : 0x03 - read
00f8 : 90 66 90 66 
Time: 00.00011714 command # 17 : 0x03 - read
00fc : 38 01 00 ff 
Time: 00.00012665 command # 18 : 0x03 - read
00fff400 : ff ff ff ff 
Time: 00.00013421 command # 19 : 0x03 - read
00fff404 : ff ff ff ff 
Time: 00.00014112 command # 20 : 0x03 - read
00fff408 : ff ff ff ff 
Time: 00.00014868 command # 21 : 0x03 - read
00fff40c : ff ff ff ff 
Time: 00.00015624 command # 22 : 0x03 - read
00fff410 : ff ff ff ff 
Time: 00.00016315 command # 23 : 0x03 - read
00fff414 : ff ff ff ff 
[…]
```

Are there tools available to analyze these traces? For example find out
 what parts take too long to read for example?

Are there tools available to help work with these traces, and for
example map certain areas to the corresponding code?

Is documentation available for working with these traces? What to look
for, how to use them to analyze the coreboot code?

How do you use it efficiently?


Thanks,

Paul


[1] https://www.coreboot.org/EM100pro
[2] https://www.molgen.mpg.de/~pmenzel/20170210%E2%80%93coreboot/201702
10%E2%80%93kgpe-d16%E2%80%93em100%E2%80%93trace.txt

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Saving truncated preram CBMEM messages

[Paul Menzel via coreboot]

Dear Nico,


Am Sonntag, den 08.01.2017, 15:23 +0100 schrieb Nico Huber:
> On 08.01.2017 14:38, Paul Menzel via coreboot wrote:

> > looking at the coreboot CBMEM console messages board status repository,
> > you’ll find a lot of truncated preram CBMEM console messages.
> > 
> > Currently the buffer size is 0xc00 – 3 kB, right –, which is too small
> > for quite some boards. The mainboard *Kabylake LPDDR3 RVP3* overrides
> > it to 0xd00.
> > 
> > So I am thinking about increasing it [1], but it’s of course not that
> > simple, especially as I don’t understand all the implications.
> > 
> > > Increasing this buffer reduces amount of available CAR stack, and
> > > apparently DDR3 raminit already struggles with the amount of
> > > cachelines available on fam10/15
> 
> This means a lower stack size (higher console buffer size) would result
> in a stack overflow. In other words, a brick.

One more question. How was the size 0xc00 chosen in the first place?

> > My first question is, what other downsides are there of increasing the
> > buffer size? I assume it’s unrelated to resulting usable RAM size, as
> > RAM sizes nowadays are much, much bigger? So would one megabyte be
> > reasonable/possible as a goal on boards supporting that?
> 
> No, no other downsides beside bricking.
> 
> > So if their is consensus that it should be increased, what would a way
> > be forward? I assume, overriding it per mainboard is not so useful, as
> > these messages are mostly from the chipset, so it should be chipset
> > dependent?
> 
> I would override it per chipset.

Understood. I adapted the change set accordingly for the Intel 945 [1].
Testers are welcome.

> But, for boards that implement the romstage main(), it has to be
> tested for each board (a single declaration in the main() could
> decide if the stack overflows or not).
> 
> A better option would be to reduce the verbosity: Identify log messages
> that are less useful (and could be hidden behind options like CONFIG_
> DEBUG_RAM_SETUP). Or something like disabling BIOS_SPEW messages if
> CBMEM is the only console.
>
> > Should that option be moved there?


Thanks,

Paul


> > [1] https://review.coreboot.org/18049/
> >"arch/x86: Increase preram CBMEM console buffer size"

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 and Samsung DDR3L memory sticks

[Paul Menzel via coreboot]

Dear Daniel,


Thank you for keeping us in the loop.


Am Samstag, den 11.02.2017, 16:14 +0100 schrieb Daniel Kulesz:
> To answer my question myself: It works partially.
> 
> > 1.) Samsung M393B1K70DH0-YK0
> > 
> > Type: DDR3 DIMM 240-Pin, reg ECC • Ranks/Banks: dual rank, x4 • Modules: 1x 
> > 8GB • JEDEC: PC3L-12800R • Voltage: 1.35V
> 
> I got 8 of these working with one CPU package on the KGPE-D16 with
> one of the latest Coreboot master versions:

(Please note, that coreboot is officially spelled all lowercase.)

How much did you pay for these modules?

Just to be sure. You got 64 GB of RAM working. If you plug in more
modules, it fails, right?

> Version: 4.5-963-gf57a768

Please upload your logs to the board status repository. (This commit
has not been uploaded by REACTS, so it wouldn’t overwrite anything.)

> However, the experience was not very good because I did not fit all
> of them at once and started with testing "partical" configurations
> with just two or four modules inserted. In these cases, raminit
> succeeded but when detecting the PCI devices the system hang up -
> especially when placing 4 modules in the orange slots. Also, with
> coreboot-4.5, I only managed to get four modules working when placing
> them in the slots most far away from CPU0 (two orange, two black).
> 
> Apart from that, the configured clock speed seems too low to me (the
> vendor bios runs the modules at 800 MHz instead of 667 MHz):
> 
> Handle 0x0007, DMI type 17, 40 bytes
> Memory Device
> Array Handle: 0x0006
> Error Information Handle: Not Provided
> Total Width: 72 bits
> Data Width: 64 bits
> Size: 8192 MB
> Form Factor: DIMM
> Set: None
> Locator: NODE 0 DIMM_A1
> Bank Locator: Not Specified
> Type: DDR3
> Type Detail: Synchronous Registered (Buffered)
> Speed: 667 MHz
> Manufacturer: Samsung
> Serial Number: xxx
> Asset Tag: Not Specified
> Part Number: M393B1K70DH0-YK0  
> Rank: 2
> Configured Clock Speed: 667 MHz
> Minimum Voltage: 1.35 V
> Maximum Voltage: 1.5 V
> Configured Voltage: 1.35 V

Without the logs, it’s hard to debug anything. Verbose logs are one of
the biggest advantages of coreboot. So please upload them, or attach
them.


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Documentation creation for the coreboot wiki - what to do?

[Paul Menzel via coreboot]

Dear Taiidan,


Am Freitag, den 27.01.2017, 19:16 -0500 schrieb taii...@gmx.com:

[…]

Thank you on planning to improve the documentation in the Wiki. Please
make sure to contact Zaolin and Martin, to be up-to-date, what the
current plans regarding documentation are.

> I would like to know as to how much we are allowed to indicate that x86 
> OEM's are generally hostile to the FOSFW movement? I don't want to 
> ruffle any feathers, as these days they are already significantly ruffled.
> 
> I was able to figure all this out but for the free firmware movement to 
> survive it needs to be spread to a wider audience thus things need to be 
> made a little bit easier, I have plenty of linux sysadmin acquaintances 
> but none of them use coreboot because they aren't yet fanatical enough 
> about FOSFW to bother with the difficulty level.

Do you have a suggestion on how the indication would look like?


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Proposal for new "Commenting" wiki text

[Paul Menzel via coreboot]

Dear Nico,


Thank you for taking this up again.


Am Samstag, den 28.01.2017, 15:00 +0100 schrieb Nico Huber:
> 
> sorry to revive this old, stale topic. I got stalled by a request to
> ensure the comment style with a script. Now, that I had a look at
> checkpatch.pl, I don't think this could be done easily without risking
> many false positives.
> 
> So I'm again asking to commit my proposal below. I've incorporated the
> comments from Martin.

Just to be clear, also for the proposal below, the style can’t be
checked, right?

> Even if it's not going to be my preferred style, I would really appre-
> ciate it if we could agree on one style.
> 
> Nico
> 
> > == Commenting ==
> > 
> > Comments are good, but there is also a danger of over-commenting. NEVER
> > try to explain HOW your code works in a comment: it's much better to
> > write the code so that the _working_ is obvious, and it's a waste of
> > time to explain badly written code.
> > 
> > Generally, you want your comments to tell WHAT your code does, not HOW.
> > Also, try to avoid complex comments inside a function body: if the
> > function is so complex that you need to separately comment parts of it,
> > you should probably go back to chapter 6 for a while.  You can make
> > small comments to note or warn about something particularly clever (or
> > ugly), but try to avoid excess.  Instead, put the comments at the head
> > of the function, telling people what it does, and possibly WHY it does
> > it.
> > 
> > coreboot style for comments is the C89 "/* ... */" style. You may also
> > use C99-style "// ..." comments.

Could we change that, C89 style comments are preferred, and add a note about 
consistency?

> … You may also use C99 style "// …" comments, if it’s beneficial.
> Also, the commenting should be consistent in one file.

Or is that wishful thinking, and both style will always be mixed?

> > The preferred style for concise multi-line comments that explain a
> > single piece of code is:

Please, emphasize *concise*, or elaborate right away with *i. e., one
paragraph*

> > 
> > /* This is the preferred style for
> >two or three line comments that
> >avoids excessive blank lines. */
> > 
> > Note that there shouldn't be leading asterisks on new lines in the
> > concise style.
> > 
> > The preferred style for long multi-line comments is:

Please emphasize *long*.

> > /*
> >  * This is the preferred style for multi-line
> >  * comments in the coreboot source code.
> >  *
> >  * Description: A column of asterisks on the left side,
> >  * with beginning and ending almost-blank lines.
> >  */
> > 
> > Some rules of thumb to decide which style to use:
> > * If you are commenting a whole function (indentation level 0) or
> >   something high level (indentation level 1), use the long style.
> > * If you want to explain a single piece of code and your comment
> >   doesn't span multiple paragraphs, use the concise style.
> > * Otherwise you might want to ask yourself why what you're going to
> >   explain doesn't deserve an own function.
> > 
> > It's also important to comment data, whether they are basic types or
> > derived types.  To this end, use just one data declaration per line (no
> > commas for multiple data declarations).  This leaves you room for a
> > small comment on each item, explaining its use.
> > 
> > If the author has reasonable arguments for breaking the recommended
> > style guide to improve readability, others should be respectful of those
> > differences.

Nico, thank you again.


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] C++

[Paul Menzel via coreboot]

Dear Philipp,


Am Samstag, den 28.01.2017, 15:13 +0100 schrieb Philipp Stanner:
> Could coreboot (or parts of it) be written in C++?

Sure, it’s possible and could be done.

> What would be the advantages and disadvantages?

As the others, I don’t see an advantage.

But, did you just mean coreboot, or “coreboot based firmware”, which
includes payloads?

If the later, I believe that you can indeed write payloads with C++, if
you know it well.

I have no idea about the size implications though.


Kind regards,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Let’s solve the Asus KCMA-D8 mess

[Paul Menzel via coreboot]

Dear coreboot folks,


As many of you know, last week was not pretty [1]. Unfortunately, no
solution was found.

Chances are slim, that the involved parties will get along in the
future, but hopefully they will.

I had hoped, that the community would have been asked for help before
to find a solution, that (all?) the money could not be raised.

Also, the coreboot project has the source code for the Asus KCMA-D8,
and the REACTS infrastructure is run to build test the board to find
regressions.

I propose, that the community steps in for Minifree(?) and raises the
$15,000 instead to settle the debts, forget about it and go on.

I’ll take my 1000 € pledge for the TALOS workstation and put 500 € on
top, so ten percents are covered.

Is anybody with me? Smaller amounts are as welcome as bigger. If nobody
else wants to, I would note down the amounts, already transferred.

Having not done that before, I hope tax rules and regulations don’t
make that difficult. Please advice how to best transfer the money.

I believe in our community, and I am hopeful to settle this.


Thanks,

Paul


[1] see the thread *ASUS KCMA-D8 workstation board port offer*

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] SeaBIOS IRC channel: #seab...@irc.freenode.net

[Paul Menzel via coreboot]

Dear coreboot folks,


No idea, if you already new this, but I didn’t know that there was a
dedicated SeaBIOS IRC channel, until somebody mentioned it in
#coreboot.

Just wanted to let you know, as it’s not documented yet [1].


Thanks,

Paul


[1] https://www.seabios.org

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] How to quit Tint payload?

[Paul Menzel via coreboot]

Dear coreboot folks,


Starting the Tint payload, in my case from SeaBIOS, when the game is
over, the score is shown. How can I quit the payload, which probably 
means restart the system?

Pressing ESC or Ctrl + Alt + Del don’t work. The only way I have found
so far, is hitting the reset button on the mainboard.


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Flash ROM access during boot

[Paul Menzel via coreboot]

Dear coreboot folks,


Playing around with the trace feature of the Dediprog EM100Pro, I
noticed several flash ROM accesses until the payload is loaded.

Are there ways or strategies to preload the whole flash ROM chip
content into memory for faster access right after RAM is set up for
example? What does that depend on? Does that make any sense at all?


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Speaker for Mix-IT wanted (Lyon, April 20th/21st, 2017)

[Paul Menzel via coreboot]

Dear coreboot folks,


At the last community meeting Philipp reported, that we were asked to
present coreboot at Mix-IT [1].

Is there somebody with time, who would be willing to present the
coreboot project there? That’d be awesome.


Thanks,

Paul


[1] https://www.mix-it.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Saving truncated preram CBMEM messages

[Paul Menzel via coreboot]

Dear coreboot folks,


looking at the coreboot CBMEM console messages board status repository,
you’ll find a lot of truncated preram CBMEM console messages.

Currently the buffer size is 0xc00 – 3 kB, right –, which is too small
for quite some boards. The mainboard *Kabylake LPDDR3 RVP3* overrides
it to 0xd00.

So I am thinking about increasing it [1], but it’s of course not that
simple, especially as I don’t understand all the implications.

> Increasing this buffer reduces amount of available CAR stack, and
> apparently DDR3 raminit already struggles with the amount of
> cachelines available on fam10/15

My first question is, what other downsides are there of increasing the
buffer size? I assume it’s unrelated to resulting usable RAM size, as
RAM sizes nowadays are much, much bigger? So would one megabyte be
reasonable/possible as a goal on boards supporting that?

So if their is consensus that it should be increased, what would a way
be forward? I assume, overriding it per mainboard is not so useful, as
these messages are mostly from the chipset, so it should be chipset
dependent?

Should that option be moved there?


Thanks,

Paul


[1] https://review.coreboot.org/18049/
   "arch/x86: Increase preram CBMEM console buffer size"

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Keyboard does not work in payload GRUB on Lenovo X60

[Paul Menzel via coreboot]

Dear coreboot folks,


Testing the GRUB payload on the Lenovo X60 with coreboot from latest
master, the keyboard doesn’t work in GRUB.

GRUB is built with `make && make default_payload.elf`.

Can you confirm that problem, and do you know of a solution.

Using SeaBIOS, a delay of three to five seconds has to be set with the
file `etc/ps2-keyboard-spinup` in CBFS.


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Dealing with PCI reset

[Paul Menzel via coreboot]

Dear Timothy,


Thank you for your reply.


Am Sonntag, den 11.12.2016, 15:54 -0600 schrieb Timothy Pearson:
> > Several devices using the Intel 945 chipset copied code for PCI reset,
> > costing 200 ms of boot time.
> > 
> > ```
> >  /* Force PCIRST# */
> >  pci_write_config16(PCI_DEV(0, 0x1e, 0), BCTRL, SBR);
> >  udelay(200 * 1000);
> >  pci_write_config16(PCI_DEV(0, 0x1e, 0), BCTRL, 0);
> > ```
> > 
> > The change-set Ia37d9f0ecf5655531616edb20b53757d5d47b42f [1] removes
> > that code from the Lenovo X60.
> > 
> > That code was added for some crypto card on a Roda device.
> > 
> > My question is, if removing that code is fine, or if it should be left
> > in and be made configurable (Kconfig/NVRAM)?
> > 
> > Are there often cases where there are extensions card with problems,
> > that need such a PCI reset?
> 
> We have run into this issue on the KGPE-D16 and LSI SAS controllers.
> However, in this case it's not so much the reset itself as it is the
> time it takes for the card to start up and become ready for PCI scan.
> 
> We handled this with a devicetree.cb option to set a delay between reset
> and PCI scan.  Perhaps something similar could be used in this instance?

I guess you are referring to the following line in
`src/mainboard/asus/kgpe-d16/devicetree.cb`?

```
register "pcie_settling_time" = "100" # Allow PIKE to be detected / 
configured
```

This option is only available for that particular southbridge, AMD
SR5650, right?

In the Lenovo X60 case, it’d probably would be better to have it as a
run time option in NVRAM, so that it can be configured depending if
such a problematic card is used or not.

Would it be feasible to implement something like that in `src/device`,
so that all devices can use it?

Or is that overkill, and such pluggable(?), that means external, cards
are rare, and the code should just be removed for the Lenovo X60?


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] TALOS project short of funding goals - where to now?

[Paul Menzel via coreboot]

Dear Elena,


Am Montag, den 12.12.2016, 14:50 +0100 schrieb Elena ``of Valhalla'':
> On 2016-12-12 at 13:18:42 +0100, Łukasz Dobrowolski wrote:
> > On 12/12/2016 03:27 AM, taii...@gmx.com wrote:
> > > (...) considering that the average linux sysadmin makes over
> > > $100K per year the community could have easily funded the
> > > project.
> > 
> > In Germany, US, France... Not in Poland, Ukraine... many hackers there.
> 
> Indeed. In my country 20k EUR per year is a good pay, but even with a
> pay of 60k EUR|$ a year, that would mean paying the whole earnings of a
> month for something that is still at the crowdfunding stage and may just
> disappear into nothing.
> 
> If you consider that people have to, well, live with that money, that
> would mean multiple months of savings / disposable income.
> 
> If somebody has a family, that probably goes in the range of expenses
> that have to be negotiated with the other family members.
> 
> All of this necessarily reduces the number of people who can even think
> about partecipating in that crowdfunding, not to say actually decide to
> put down their money for it.

Unfortunately, I don’t agree. There was the option to support the
project with less money. People can pledge $10, $250, or $500. In my
opinion, everybody interested in user-controlled hardware would be able
to spend at least $10. But it looks like there are well below 300
people interested in that. That is very sad to see, that people are not
willing to support to kick-start such a project to maybe profit in the
future from cheaper devices.

In my opinion, people are ignorant about the locked-down hardware issue
and some don’t care.

On the other hand, I also think, that maybe marketing was probably not
as successful as for other projects.

At least I didn’t see a lot of marketing support from the FSF, FSFE,
and EFF. The media also didn’t help very much.


Thanks,

Paul


PS: Wikipedia is also asking for donations right now. Despite the bad
things about Wikipedia, I guess most of us use it daily and want it to
remain maintained and free of advertisement.


[1] 
https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstation

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Dealing with PCI reset

[Paul Menzel via coreboot]

Dear coreboot folks,


Several devices using the Intel 945 chipset copied code for PCI reset,
costing 200 ms of boot time.

```
/* Force PCIRST# */
pci_write_config16(PCI_DEV(0, 0x1e, 0), BCTRL, SBR);
udelay(200 * 1000);
pci_write_config16(PCI_DEV(0, 0x1e, 0), BCTRL, 0);
```

The change-set Ia37d9f0ecf5655531616edb20b53757d5d47b42f [1] removes
that code from the Lenovo X60.

That code was added for some crypto card on a Roda device.

My question is, if removing that code is fine, or if it should be left
in and be made configurable (Kconfig/NVRAM)?

Are there often cases where there are extensions card with problems,
that need such a PCI reset?


Thanks,

Paul


[1] https://review.coreboot.org/17703

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Fund a TALOS Secure Workstation as coreboot build system

[Paul Menzel via coreboot]

Dear Martin,


Am Freitag, den 04.11.2016, 10:36 -0600 schrieb Martin Roth:
> Is getting a Talos workstation as a build server something that people are
> interested in contributing money for?

Yes, let’s do this.

> So far, we've got $2500 pledged from two contributors out of the $7500
> needed to get a server.

I pledge 1,000 $.

Everyone, the TALOS campaign only reached 10 % of the funding goal, and
there are only twelve days left. Only 184 people have pledged 10 $, and
only 15 pledged 250 $.

Please help spread the word. Do you know somebody working at some
newspaper, magazine, or has a blog, in the Linux kernel community, or
at the EFF or at Mozilla. Please tell them about that.

Currently, it looks like free software people don’t care about getting
control over their hardware back.


Thanks,

Paul


[1] 
https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstation

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [RFC] How to add “nested” time stamps?

[Paul Menzel via coreboot]

Dear coreboot folks,


I’d like to add more time stamps for instrumentation/benchmarking.

I started with the timer initialization, and submitted two change sets
[1][2].

After rebuilding the utility `cbmem`, the relevant output looks like
below.

```
  60:device initialization 457,880 (9,886)
 120:starting timer init   472,001 (14,121)
 121:finished timer init   472,008 (6)
  70:device setup done 472,751 (742)
```

Would that be acceptable to have nested entries? The down side is, the
time from *device initialization* to *device setup done* has to be
calculated manually now.

Also, I just chose the numbers 120 and 121 arbitrarily. Are there any
best practices for that to keep that extensible?


Thanks,

Paul


PS: If somebody has an idea on the weird build error on the DMP
Vortex86EX [3], I’d appreciate any help.

```
ROMCC  romstage.inc
timestamp_serialized.h:23.16: 
bad type specifier :ident:
src/arch/x86/Makefile.inc:254: recipe for target 
'/dev/cb-build/coreboot-gerrit.0/DMP_EX/mainboard/dmp/vortex86ex/romstage.inc' 
failed
make[1]: *** 
[/dev/cb-build/coreboot-gerrit.0/DMP_EX/mainboard/dmp/vortex86ex/romstage.inc] 
Error 1
make[1]: Leaving directory '/home/coreboot/slave-root/workspace/coreboot-gerrit'
```


[1] https://review.coreboot.org/17701
[2] https://review.coreboot.org/17702
[3] 
https://qa.coreboot.org/job/coreboot-gerrit/47088/testReport/junit/%28root%29/board/DMP_EX/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] Explicitly use C11/GNU11

[Paul Menzel via coreboot]

Dear Julius,


Am Mittwoch, den 30.11.2016, 20:10 -0800 schrieb Julius Werner:
> > Thank you for the elaborate explanation. I never intended to take on
> > that task, but if I had, you would have convinced me.
> > 
> > I hope using GNU11 suits everyone.
> 
> Yes, just to be clear (this has split into so many different threads
> that I'm no longer sure what the latest decision is?), I only
> (prematurely) objected to forbidding GNU extensions. Otherwise, I'm
> totally in favor of switching to C11 and not aware of any difference
> between the versions that would cause a problem for us.

As written, my current understanding is, that when switching the
coreboot toolchain from 4.9(?) to 5.3(?), the coreboot project switched
from GNU89 to GNU11.

My current proposal [1] is to explicitly set that, so that people can
still use GCC 4.9 – Debian 8.5 (Jessie/stable) ships GCC 4.9.2.

Reviews are welcome.


Thanks,

Paul


[1] https://review.coreboot.org/17636

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] Explicitly use C11/GNU11

[Paul Menzel via coreboot]

Dear Julius,


Am Dienstag, den 29.11.2016, 14:20 -0800 schrieb Julius Werner:
> > A lot of the GNU extensions are used in our codebase, so if somebody
> > feels strongly about moving away from GNU11 to C11, the code needs to
> > be cleaned up. But that should be done in a different patch set.
> 
> I'd like to explicitly object to that. There are many GNU extensions
> which are simply necessary to write sane, readable and performant code
> (e.g. to implement non-double-evaluating MIN()/MAX() macros, to
> cleanly control linking into particular sections, to get performant
> code generated for IO accessor functions, etc.). The C standard by
> itself is simply insufficient to support all systems programming use
> cases, and if we forbade GNU extensions we'd have to rewrite
> significant parts of coreboot in pure assembly and add weird, hardly
> readable workarounds for many code patterns. I don't see how this
> would be worth it just to try to get compatibility with compilers
> nobody wants to use anyway, or for some theoretical goal of "standards
> compliance" with no practical benefit. (Note that many GNU extensions
> are implicitly available even without -std=gnuXX, some of them even if
> you also enable -Werror=pedantic. But that doesn't not make them GNU
> extensions, and there'd be no reason to treat them differently from
> ones that require the -std flag. Ditching GNU extensions would mean
> that every __attribute__, every __builtin and every extended asm
> becomes illegal.)

Thank you for the elaborate explanation. I never intended to take on
that task, but if I had, you would have convinced me.

I hope using GNU11 suits everyone.


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] Explicitly use C11

[Paul Menzel via coreboot]

Dear coreboot folks,


Am Dienstag, den 29.11.2016, 00:38 +0100 schrieb Nico Huber:
> On 29.11.2016 00:23, Alexander Couzens wrote:
> > I like the idea of using C11.
> 
> I would be looking forward to that.

As GCC 5.3 from the coreboot toolchain uses GNU11 by default, there is
now a change set up for review, explicitly setting that [1].

A lot of the GNU extensions are used in our codebase, so if somebody
feels strongly about moving away from GNU11 to C11, the code needs to
be cleaned up. But that should be done in a different patch set.


Thanks,

Paul


[1] https://review.coreboot.org/17636/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] Explicitly use C89 (was: Setting C99 by default)

[Paul Menzel via coreboot]

Dear Ron,


Am Sonntag, den 27.11.2016, 22:44 + schrieb ron minnich:
> Seems reasonable, but on Harvey recently we went with c11. Any reason not
> to do that instead?

I am sorry, my statement about Linux was incorrect. Linux is explicitly
built with C89 [1][2][3].

```
HOSTCFLAGS   = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 
-fomit-frame-pointer -std=gnu89
```

So I’d say, coreboot also stays with C89 to be compatible with Linux.


Thanks,

Paul


[1] https://www.phoronix.com/scan.php?page=news_item=MTg0MTQ
[2] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=51b97e354ba9fce1890cf38ecc754aa49677fc89
[3] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Makefile#n304

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [RFC] Setting C99 by default

[Paul Menzel via coreboot]

Dear coreboot folks,


Using GCC 4.9.2 coreboot fails to build for certain boards, whose code
uses ‘for’ loop initial declarations.

```
$ gcc --version
gcc (Debian 4.9.2-10) 4.9.2
[…]
$ make # lenovo/x60 with native graphics initialization
[…]
CC ramstage/northbridge/intel/i945/gma.o
src/northbridge/intel/i945/gma.c: In function 'probe_edid':
src/northbridge/intel/i945/gma.c:570:2: error: 'for' loop initial declarations 
are only allowed in C99 or C11 mode
  for (int i = 0; i < 8; i++) {
  ^
src/northbridge/intel/i945/gma.c:570:2: note: use option -std=c99, -std=gnu99, 
-std=c11 or -std=gnu11 to compile your code
Makefile:316: recipe for target 'build/ramstage/northbridge/intel/i945/gma.o' 
failed
make: *** [build/ramstage/northbridge/intel/i945/gma.o] Error 1
```

As Linux has switched to C99 in version 3.18, I suggest that coreboot
also explicitly sets that in the Makefiles, so that code can easily be
copied and so that there is no dependency on the compiler default.

Are there any objections?


Thanks,

Paul


[1] https://review.coreboot.org/17623/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Fund a TALOS Secure Workstation as coreboot build system

[Paul Menzel via coreboot]

Dear coreboot folks,


At the last coreboot community meeting (CCC) [1][2] the TALOS Secure
Workstation was brought up, and most people said, they won’t be able to
afford the base system.

Martin said it’d be great to have one system as a coreboot build
system, and suggested that the coreboot community together funds a
workstation.

What do you think?


Thanks,

Paul


PS: Please spread the word of the crowdfunding to your friends, and
coworkers, and support it, so that it’ll be a success.


[1] https://www.raptorengineering.com/TALOS/prerelease.php
[2] 
https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstation

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [RFC] Finding a conference call solution for the CCC

[Paul Menzel via coreboot]

Dear coreboot folks,


At the last coreboot community meeting (CCC) [1][2], some participants
couldn’t here what other participants were saying with the current
conference call solution Discord [3].

As this greatly reduces the productivity, the conclusion was to find a
different solution, as this problem has been present since the
beginning and Discord doesn’t seem to be able to fix this.

So either somebody gets in contact with Discord, and they promise to
work on a solution for the next meeting, or we need to find a different
solution.

The requirements are.

1. Working conference call (audio) functionality
2. No registration necessary
3. Clients for all operating systems (packages at best in distribution
archive), or at least a Web client that runs with Mozilla Firefox (ESR
and last version), and Google Chromium (last version).

Chris(?) offered to set up a Mumble [4] server. Clients for all
operating systems are supposed to be available.

Also Tox was mentioned [5], which doesn’t feature a Web client, as far
as I can see.

So if you know of a solution, please tell us, so that technical
problems won’t spoil the fun of the CCCs.


Thanks,

Paul


[1] https://www.coreboot.org/Coreboot_community_meeting
[2] https://coreboot-meeting.pads.ccc.de/CommunityMeetingTopics?
[3] https://discordapp.com/
[4] https://wiki.mumble.info/wiki/Main_Page
"Mumble is an open source, low-latency, high quality voice chat
software primarily intended for use while gaming."
[5] https://tox.chat/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Change-sets for AMD Stoney Ridge, unifying PI directories

[Paul Menzel via coreboot]

Dear coreboot folks,


If you haven’t seen it yet, Marc uploaded change-sets for review adding
support for AMD Stoney Ridge (if I am not mistaken) [1][2], he and
Marshall worked on.

Are the different AMD PI using devices different enough, to have one
directory for each of them, or would it make sense to unify it?


Thanks,

Paul


[1] https://review.coreboot.org/17139
[2] https://review.coreboot.org/#/q/owner:%22Marc+Jones%22+status:open

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to pass custom defined data from Coreboot to GRUB2

[Paul Menzel via coreboot]

Dear Mohan,


Am Montag, den 03.10.2016, 11:06 + schrieb Mohan Shanmuga Sundaram:
> I have a requirement to pass the state value of a GPIO (on Intel ATOM
> Baytrail SoC) from Coreboot to GRUB2. Based on this GPIO state, I
> would script the GRUB2 to configuration to select an alternative OS
> from the GRUB menu list. Is there a facility to pass this custom
> defined data from Coreboot to GRUB2?

I suggest to use CBTABLES for that. GRUB also can read that.


Thanks,

Paul


[1] grub-core/kern/i386/coreboot/cbtable.c


PS: Please note, that coreboot is written all lowercase.
PPS: Please don’t add the disclaimer to the end of your messages.
PPPS: Please just send plain text messages, and no HTML ones.

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Adapting Linux kernel documentation setup with Sphinx and reStructuredText

[Paul Menzel via coreboot]

Dear coreboot folks,


The Linux kernel switched to Sphinx and reStructuredText [1] for its
documentation [2][3][4].

Would it make sense to also use that for coreboot? I would see the
following benefits.

1. It’s easier to import code like drivers from the Linux kernel to
coreboot.
2. Developers familiar with the Linux kernel have it easier to work on
coreboot.
3. The coreboot project could import all improvements the Linux kernel
documenation gets.


Thanks,

Paul


[1] https://en.wikipedia.org/wiki/ReStructuredText
[2] https://static.lwn.net/kerneldoc/index.html
[3] https://lwn.net/Articles/692704/
    "Kernel documentation with Sphinx, part 1: how we got here"
[4] https://lwn.net/Articles/692705/
    "Kernel documentation with Sphinx, part 2: how it works

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] where to put info about linux payload and kgpe-d16

[Paul Menzel via coreboot]

Dear Ron,


Am Donnerstag, den 29.09.2016, 20:09 + schrieb ron minnich:
> I'd lke to track some things I'm learning about linux paylaod on kgpe-d16
> 
> I'm thinking of keep track of
> working linux ref and a working .config
> working coreboot ref and a working .config
> 
> I'm not quite sure where in the wiki this belongs; ideas anyone?

If it’s really ASUS KGPE-D16 related, that as a subpage of the board
page. If not, that means, if it’s also related to for example QEMU, I’d
create a page *Linux Payload* or so.

> reon

Did you change your name? :P


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Proposal for new "Commenting" wiki text (was: [RFC] Deciding on style for multi-line comments)

[Paul Menzel via coreboot]

Dear Nico,


Thank you for sending the proposal around.

What ever is decided on, please make sure it can be automatically
checked by the commit hooks, and that the scripts are updated in the
repository at the same time the guidelines are changed.


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [RFC] Statement regarding AMD’s new architecture Zen

[Paul Menzel via coreboot]

Dear coreboot folks,


AMD presented the new processor architecture *Zen* [1], which – from
the published reports – looks quite promising to be competitive to
Intel once again.

No devices are sold yet, but I guess they are already worked on.
(Hopefully, there will be also Google Chromebooks and Chromeboxes.)

Should the coreboot community publish a statement, asking AMD to make
it possible to fully initialize these devices with free software? Is
there somebody good in English writing, and knowledgeable of the
current state, able to draft something up?

For example, will there still be a Platform Security Processor (PSP)
[2], and SMU (System(?) Management Unit) [3]?

What does the statement need to contain?

1. Request for free documentation for all parts (chipset (RAM) init,
PSP, SMU, …)
2. User controllable signing keys
3. Reference to Intel’s involvement to coreboot

Nice to have:

4. Code contributions from AMD

What else is missing?

(I am well aware, that such a statement has a small chance to change
anything. But better try than not.)


Thanks,

Paul


[1] https://en.wikipedia.org/wiki/Zen_%28microarchitecture%29
[2] https://www.coreboot.org/Binary_situation#recent_AMD

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [RFC] Deciding on style for multi-line comments

[Paul Menzel via coreboot]

Dear coreboot folks,


The coding style currently demands the following style of multi-line
comments [1].

> The preferred style for long (multi-line) comments is:


/*
 * This is the preferred style for multi-line
 * comments in the Linux kernel source code.
 * Please use it consistently.
 *
 * Description:  A column of asterisks on the left side,
 * with beginning and ending almost-blank lines.
 */

This is straight from the Linux Kernel coding style [2].

Certain parts of the code do not follow this style, so the question is
how to deal with this. There has been some discussion on Gerrit about
that [3]. But the list is the forum for such discussions, so I am
bringing it up here.

Julius’ last comment:

> No offense, but that part of the Wiki literally reads:
>
> > For files in net/ and drivers/net/ the preferred style for long
> > (multi-line) comments is a little different.
>
> ...so I'm not really sure why we should take something that has
> obviously been carelessly bulk-copy into there from Linux
> kernel sources eons ago as more authoritative than living development
> practice of the last few years.
>
> The coreboot wiki is, sorry I have to say it, for the most part
> pretty awful and outdated. It would probably be a good thing to fix
> if somebody has the time for it, but until then I don't think we
> should put too much stake into it (at least in the stuff that hasn't
> been updated and maintained recently).

I think that the extra blank lines in multi-line comments make them
stand out better, which I prefer over having more lines on the screen.

Also staying close to the Linux Kernel coding style makes it easier to
use their tools, and not having to adapt them, and people only have to
remember one style.

But in the end it’s a matter of taste.

So what should be done? Adapt the coreboot coding syle, or gradually
change the style in the existing code, but require the style in new
commits?


Thanks,

Paul


[1] https://www.coreboot.org/Coding_Style#Commenting
[2] https://www.kernel.org/doc/Documentation/CodingStyle
[3] https://review.coreboot.org/16060

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Linux 4.7 kernel payload with coreboot 4.4

[Paul Menzel via coreboot]

Dear Trammell,


Welcome to coreboot.


Am Mittwoch, den 10.08.2016, 07:03 -0600 schrieb Trammell Hudson:
> The Linux 4.7 kernel payload crashes early in the boot process 
> with CoreBoot 4.4.  I traced it to these instructions that are
> finding a safe spot to decompress the rest of the kernel and
> patched around it with a hard coded location:
> 
> diff -u --recursive 
> /home/hudson/build/clean/linux-4.7/arch/x86/boot/compressed/head_64.S 
> ./linux-4.7/arch/x86/boot/compressed/head_64.S
> --- /home/hudson/build/clean/linux-4.7/arch/x86/boot/compressed/head_64.S 
> 2016-07-24 15:23:50.0 -0400
> +++ ./linux-4.7/arch/x86/boot/compressed/head_64.S2016-08-05 
> 12:07:11.399854225 -0400
> @@ -340,9 +357,15 @@
>  1:
>  
>   /* Target address to relocate to for decompression */
> +#if 0
>   movlBP_init_size(%rsi), %ebx
>   subl$_end, %ebx
>   addq%rbp, %rbx
> +#else
> + // coreboot does not populate the init_size boot param?
> + // fake it with a hard coded value
> + movl$0x97b000, %ebx
> +#endif
>  
>   /* Set up the stack */
>   leaqboot_stack_end(%rbx), %rsp
> 
> It seems that the Linux kernel bzImage is supposed to set this value,
> rather than coreboot, so my comment is likely incorrect.
> 
> Dumping linux-4.7/arch/x86/boot/header.o, it looks like init_siez
> is supposed to be 0xcf5000, so I wonder if %rsi is pointing to the
> wrong location.
> 
> In 4.6.4 the computed address was hardcoded:
> 
> movl$LOAD_PHYSICAL_ADDR, %ebx
> /* Target address to relocate to for decompression */
> addl$z_extract_offset, %ebx
> 
>   3e:   bb 00 00 00 01  mov$0x100,%ebx
>   43:   81 c3 00 00 00 00   add$0x0,%ebx

I have no idea, but could it be related to KASRL (Kernel Address Space
Layout Randomization)?


Thanks,

Paul


PS: Please note, that officially coreboot is spelled all lowercase (see
your email subject). (Depending on your localization(?) you might want
to start it with a capital letter, but please never CamelCase.)

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] skylake support

[Paul Menzel via coreboot]

Dear Neal,


Am Dienstag, den 09.08.2016, 08:48 -0400 schrieb Neal Elliott:

> I really like coreboot and would like to use it on a current
> motherboard. the idea of having a open source alternative bios
> resonates with me. I would like to buy a motherboard with skylake
> chipsets that is supported by coreboot. does anyone recommend a
> supported skylake motherboard?

To my knowledge, only mobile Skylake variants are supported, that means
the Skylake variants shipped in Google Chromebooks and Google
Chromeboxes.

As you wrote *open source alternative*, please read the Wiki page
*Binary Situation* [1].

The commercially supported Intel chipsets come with a BLOB initializing
the memory (MRC – Memory Reference Code, FSP – Firmware Support
Package), and have a separate processor, the so called Management
Engine (ME), which also runs proprietary, non-free firmware.

For some devices exist native RAM initialization, which is free
software, but which still has some problems in certain configurations.

So with current Intel systems, you get a lot of advantages of the
coreboot firmware framework (payloads, speed, flexibility) but it’s not
fully free.

Unfortunately, as AMD’s current devices also come with closed
components, the only alternative is the not-yet-for-sale Talos Secure
Workstation using the IBM POWER8 processor and architecture [2].


Thanks,

Paul


PS: It’d be great if you just sent plain text messages to mailing
lists.


[1] https://www.coreboot.org/Binary_situation
[2] https://www.raptorengineering.com/TALOS/prerelease.php

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] hackathon in Berlin next weekend 12-14.

[Paul Menzel via coreboot]

Dear Alexander,


Thank you for announcing the event on the list.


Am Montag, den 08.08.2016, 18:00 +0200 schrieb Alexander Couzens:
> some people are visiting Berlin for a hackathon next weekend (12-14)
> The hackathon will taken place at the Finowstr. 2a.

Do you already have an agenda? What do you want hack on?

> It's between the subway station U Samariter, U Frankfurter Str.

The name of the station is *Frankfurter Allee*. ;-)

Hopefully see you there.


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] ASRock E350M1 boots fine with GCC 6.1.1 from Debian Sid/unstable

[Paul Menzel via coreboot]

Dear coreboot folks,


I just wanted to let you know, that the AMD Fusion board ASRock E350M1
boots fine with a coreboot firmware image with a SeaBIOS payload, built
with GCC 6.1.1 from Debian Sid/unstable.

```
$ gcc --version
gcc (Debian 6.1.1-11) 6.1.1 20160802
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```

The logs can be found in the board status repository.

• asrock/e350m1/4.4-1119-g35cca5a
• asrock/e350m1/4.4-1123-g5d41949


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] How to add Medion AKOYA S2013 (google/veyron_jaq)

[Paul Menzel via coreboot]

Dear coreboot folks,


I got the Rockchip RK3288 based Google Chromebook Medion AKOYA S2013
which is or is based on the google/veyron_jaq board.

In the tree, there is currently the Haier Chromebook 11, also based on
`google/veyron_jaq`. `src/mainboard/google/veyron/Kconfig.name`
contains:

  5 config BOARD_GOOGLE_VEYRON_JAQ
  6   bool "Haier Chromebook 11 (Veyron_Jaq)"
  7   select BOARD_GOOGLE_VEYRON
  8   select SYSTEM_TYPE_LAPTOP

How can the Medion AKOYA S2013 be added, so that it is available in the
list? Just add it to the description as it’s the same board?


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [ANNOUNCEMENT] Support for Intel Kaby Lake

[Paul Menzel via coreboot]

Dear coreboot folks,


Intel has started to submit change sets adding support for the new
chipset Intel Kaby Lake [1].

> Kaby Lake is Intel's codename for the upcoming 14 nanometer successor
> to the Skylake microarchitecture. Kaby Lake began shipping to
> manufacturers and OEMs in the second quarter of 2016, though volume
> production for the retail channel is anticipated late-2016.
> 
> Skylake was to be succeeded by the 10 nanometer Cannonlake, but it
> was announced on July 16, 2015, that Cannonlake has been delayed
> until the second half of 2017.

As it’s very similar to Intel Skylake, the goal is to adapt the Intel
Skylake code, so that it supports both chipsets. [2][3]


Thanks,

Paul


[1] https://en.wikipedia.org/wiki/Kaby_Lake
[2] https://review.coreboot.org/15768
[3] https://review.coreboot.org/16049
[4] https://review.coreboot.org/16050

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [ANNOUNCEMENT] Removal of NVIDIA Tegra T132 devices

[Paul Menzel via coreboot]

Dear coreboot folks,


this is just a notification, that the development boards google/rush
[1] and google/rush_ruy [2] using the NVIDIA Tegra T132 chipset are
going to be removed, as these development boards are not available
anymore, and never made it into a product.

The chipset code is also removed, as there are no users left [3].


Thanks,

Paul


[1] https://review.coreboot.org/16106
[2] https://review.coreboot.org/16107
[3] https://review.coreboot.org/16108

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Grub payload on X220: Reboot when trying to load Fedora with grub payload, works with SeaBIOS.

[Paul Menzel via coreboot]

Dear Evan,


Am Sonntag, den 31.07.2016, 21:20 -0700 schrieb Evan Cramer:
 
> I've gotten pretty far along with coreboot on my X220 running Fedora 23.
> I've extracted a VGA option ROM, and it loads correctly. I have grub
> configured as the primary payload, which can chainload SeaBIOS from its
> memdisk. The grub.cfg in cbfs can find and load the grub.cfg in /boot on my
> ssd.
> 
> However, here's my problem. While grub finds the grub.cfg on the ssd and
> presents me with a list of Fedora kernels to boot,  when I select one, the
> screen turns black and the system appears to reboot displaying "Welcome to
> GRUB!", and then drops me back to grub, presenting the options in my
> (cbfsdisk)/etc/grub.cfg menu.
> 
> However, if I chainload SeaBIOS, it correctly finds grub in the MBR on the
> ssd which loads the grub.cfg on the ssd, and when I select the Fedora
> kernel, it drops me at the LUKS password prompt as expected, and boots
> Fedora just fine after I enter my FDE password.
> 
> As mentioned before, I have extracted a working VGA option ROM and included
> it in the image. Since graphics in SeaBIOS works now I'm confident that's
> working. I have configured coreboot to load the VGA option ROM itself, as
> when I set native graphics initialization but included the option ROM in
> the cbfs disk, I got no video output in SeaBIOS. This is probably because
> SeaBIOS is in the Grub2 memdisk, not cbfs, and can't reach the option ROM.

To my knowledge, you can either use native graphics initialization with
SeaVGABIOS or the proprietary vendor Video BIOS, but not both together.

> Also mentioned before, I'm using LUKS full disk encryption. Grub doesn't
> complain about any missing modules, and my grub mkstandalone invocation is
> as follows:
> 
> ../grub-mkstandalone \
> --grub-mkimage=../grub-mkimage -O i386-coreboot -o ../grub2-X220.elf \
> --modules='ahci ehci uhci usb_keyboard usbms part_msdos xfs ext2 fat
> at_keyboard part_gpt usbserial_usbdebug cbfs minix_be minix minix3_be
> minix3 minix2_be minix2 ufs2 ufs1_be ufs1 udf romfs procfs odc nilfs2
> newc iso9660 cpio exfat cpio_be afs video_bochs password png keystatus
> sleep loopback gfxterm_background' \
> --install-modules='syslinuxcfg bsd ls cat echo linux linux16 search
> configfile normal cbtime cbls memrw iorw minicmd lsmmap lspci halt
> reboot hexdump pcidump regexp setpci lsacpi chain test lvm crypto
> cryptodisk luks gzio gfxterm all_video' \
> --fonts= \
> --themes= \
> --locales= \
> -d ../grub-core/ \
> /boot/grub/grub.cfg=../coreboot.cfg \
> $(find -type f)
> 
> I'm including luks, crypto, cryptodisk, and lvm, among many of things, so I
> don't think it's an issue with not having the modules necessary for
> mounting an encrypted disk. I'm not really sure where to go from here. I
> don't have any usb_serial or serial interfaces to do debug, but since I
> have video by this point I'm not really sure this would give me any more
> information. Is there some way I can get grub to print what problems it is
> having that makes it reboot? I suspect it's some kind of problem with
> video, since the prompt for the LUKS password has a background image. And
> since it works fine on SeaBIOS...
> 
> Also, if it helps, this is my config as extracted from the ROM.
> 
> This image was built using coreboot 4.4-523-gd71cfd2-dirty

Your source is marked as dirty. What changes do you have in coreboot?
(`git status`, `git diff` or `git diff --cached` should give a hint.)

> CONFIG_BOOTSPLASH_IMAGE=y
> CONFIG_BOOTSPLASH_FILE="~/Projects/blobs/bootsplash.png"
> CONFIG_VENDOR_LENOVO=y
> CONFIG_VGA_BIOS=y
> CONFIG_VGA_BIOS_FILE="~/Projects/blobs/vgabios.bin"
> CONFIG_HAVE_IFD_BIN=y
> CONFIG_HAVE_ME_BIN=y
> CONFIG_HAVE_GBE_BIN=y
> CONFIG_BOARD_LENOVO_X220=y
> # CONFIG_S3_VGA_ROM_RUN is not set
> CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
> CONFIG_BOOTSPLASH=y
> CONFIG_PAYLOAD_ELF=y
> CONFIG_PAYLOAD_FILE="/home/ecramer/Projects/grub/grub2-X220.elf"
> CONFIG_COREINFO_SECONDARY_PAYLOAD=y
> CONFIG_DEBUG_CBFS=y
> 
> Also, here is a link to my grub configs http://pastebin.com/CSitTf34

Please attach text files to messages. Use paste sites just for IRC.

> The first is the grub.cfg in /boot/grub2 and the second is the grub.cfg
> included in the CBFS in coreboot.rom
> 
> Does anybody have any tips of where I should go from here? I'm out of ideas
> on how to debug this.

More debugging messages are needed. Does `set debug=all` [1] – I think
that’s the syntax – help?

What happens if you enter the lines from the config manually on the
GRUB command line? Do you see on what line it reboots?


Thanks,

Paul


[1] https://www.gnu.org/software/grub/manual/html_node/debug.html

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Add support for Beagle Bone Black (was: coreboot on the open source Berkeley RISC V processor - available ?)

[Paul Menzel via coreboot]

Dear Punit,


Am Sonntag, den 31.07.2016, 13:31 +0530 schrieb Punit Vara:
> > On Sun, Jul 31, 2016 at 1:18 PM, punit vara wrote:

> > Btw I have Beagle Bone Black I can port coreboot on that one if
> > it's not available.  I was lurking on IRC and came to know that
> > there are few patches on Beagle bone available. I have checked it
> > out beagle bone has support for coreboot but not sure about beagle
> > bone black. I will try it on BBB and let you know about that :)
>
> patches for BBB are from 2013 and according to mailing list it's not
> finished yet. I would like to work on it :). I found the reason to
> contribute to coreboot :)

To my knowledge, the current support for the BeagleBone is only
minimal, meaning you can receive a message over the serial console and
not more. So all the fun, that means difficult, stuff is still not
implemented.

The upside is, that you can look at U-Boot or Barebox and other free
boot loader/firmware, to see what registers need to be set and so on.

So, I am looking forward to your work. Please ask any questions you
have.


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot on the open source Berkeley RISC V processor - available ?

[Paul Menzel via coreboot]

Dear Punit,


Am Samstag, den 30.07.2016, 15:35 +0530 schrieb punit vara:

> I am new to coreboot

Welcome to coreboot.

> and would like to contribute to "coreboot on the open source Berkeley
> RISC V processor". Is it available to work ? I am current GSOC
> student under RTEMS org developing BSP for beagle bone black for
> RTEMS RTOS. If I can work on this project Please what are
> the things I need to set up to work on?

Sure. As coreboot is free software you of course can work on it. There
are already people working on it. Mainly Jonathan Neuschäfer as you can
see from the blog posts about his GSoC progress [1] and his change sets
[2] (`git log --author=Neusch`).

So I suggest, to get familiar with that work, build the current state
and get it running with QEMU. Then just dive in the things you are
interested in.


Thanks,

Paul


[1] https://blogs.coreboot.org/blog/author/jneuschaefer/
[2] 
https://review.coreboot.org/#/q/owner:%22Jonathan+Neusch%25C3%25A4fer+%253Cj.neuschaefer%2540gmx.net%253E%22

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] More Fn+key on X60T

[Paul Menzel via coreboot]

Dear Alexandre,


Am Mittwoch, den 29.10.2014, 04:43 +0100 schrieb Garreau, Alexandre:
 I noticed some Fn+key present with previous BIOS still are unimplemented
 with coreboot in Lenovo Thinkpad X60T: Fn+Space (zoom?), Fn+F9 (eject??),
 Fn+PgUp (ThinkLed??), Fn+Print (“SysRq”), Fn+Pause (“Break”). That’s
 unfortunate since it means less functions usable to remap.
 
 For instance I was remapping CapsLock to “Win” key (to get symmetric Alt
 and AltGr and still have a modifier separate from Alt for i3), and I’d
 like to keep it in a less accessible place (I really use rarely, but
 sometimes I do), analogously to Num Lock key, hence I was thinking to
 Fn+Pause or Fn+Print, but these not being defined, they return no
 keycode and I can’t map anything with Fn.
 
 Could it be possible in a next release?

What do you mean by release? What coreboot revision do you use?


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Add Macronix MX25U6435F and MX25L6495F support

[Paul Menzel via coreboot]

Dear Alex,


Am Montag, den 20.10.2014, 15:49 +0800 schrieb alex...@mxic.com.tw:

 Please help to update the new Macronix SPI Flash support 
 in the ~coreboot/src/driver/spi/macronix.c .

thanks a lot for your contribution. Idwer Vollering submitted it for
code review [1] and, after review, it was submitted to the coreboot
repository.

The coreboot project uses Git for managing the source code and Gerrit
for reviewing proposed change sets. Please read the Git Wiki page [2] on
how to submit the (hopefully) next patches! We are looking forward to
it!


Thanks,

Paul


[1] http://review.coreboot.org/7194/
[2] http://coreboot.org/Git


PS: Just a reminder that the note below is of no use when sending it to
a mailing list. ;-)

 CONFIDENTIALITY NOTE:

[…]


signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Most compatible laptop

[Paul Menzel via coreboot]

Dear anonymous,


Am Freitag, den 24.10.2014, 07:59 + schrieb corebootlap...@yopmail.com:
 Which $300 to $500 laptop would be the topmost pick for CoreBoot
 compatibility?

first, please note that the official spelling of coreboot is all
lowercase. (At least never CamelCase.)

 I need CoreBoot to Just Work as I cannot afford the risk or time for
 development. So the unit needs solid reliable support. The laptop will
 boot into Linux if you're wondering

You need to do a lot more research yourself! A lot depends on your stand
towards binary BLOBs [2].

 but I guess CoreBoot also does Windows.

It needs to be tested, but (on x86 based systems) it often works.

 Can be new or slightly used. I'm happy to buy one or two generations
 old. Yet it needs HDMI output to drive a second 27-in. screen (as either
 (a) added pixel space, Virtual Xdim Ydim under X11, or (b) just as
 primary monitor with laptop's screen off). So video might need to be
 decent. I don't really care about the size of the laptop screen itself.

That’s mostly dependent on the graphics stack in the operating system.

 I prefer AMD and/or Radeon over Intel, but only found one such laptop on
 the support list. The Pavilion m6 1035dx overheats say the reviews.

If you do not want to use BLOBs, you should get an Acer Chromebook 13
using the Nvidia Tegra K1 processor [1]. Note, it is ARM based. The
coreboot based firmware does not use any binary BLOBs to my knowledge.
But you have to research yourself, how good the free drivers in
GNU/Linux are. I heard, that Chromium OS is using the binary driver due
to deadlines, but that the free driver should work too.

 I'd like to buy off-the-shelf retail. I'd love a CoreBoot guru to scour
 the offerings on retail websites (BestBuy, Walmart, the usual suspects).
 But mail-order warehouse vendors (NewEgg, TigerDirect) are OK. The main
 need is total CoreBoot compatibility.

Sorry, no time for that and it is very blunt to expect that from anyone
for free.

[…]


Thanks,

Paul


[1] http://www.cnet.com/products/acer-chromebook-13/
[2] http://www.coreboot.org/Binary_situation


signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Most compatible Mini-ITX board

[Paul Menzel via coreboot]

Dear anonymous,


Am Freitag, den 24.10.2014, 07:59 + schrieb corebootlap...@yopmail.com:

[…]

 As long as I'm here I may as well ask about miniITX too. If the laptop
 is too problematic then that's another way I can go. What's the most
 compatible miniITX on the market?

I’d recommend the ASRock E350M1 [1][2] although it still has some
problems like non-implemented STR (suspend to RAM) support.

The GizmoSphere Gizmo is also a nice board, but even smaller and does
not have an HDMI connector though.

[…]


Thanks,

Paul


[1] http://www.asrock.com/mb/amd/e350m1/
[2] http://coreboot.org/Board:asrock/e350m1
[3] http://www.gizmosphere.org/


signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot