[coreboot] RFC: implementing a way to force external EDID use.

be implemented: NB code, read_edid in drivers, decode_edid in lib, somewhere else? How do you think this feature should be turned on: nvram option or build option? Thank you for your comments -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Documentation on msr bits on intel cpuid 6ex and later

the "Intel® 64 and IA-32 Architectures Software Developer’s Manual" those bits are marked as reserved... I would like to know more about this, so if someone can help me on this... -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] gfx_uma_size on GM45

t;ggc |= 0x0800; } Kind regards -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] ps2 keyboard init in seabios

Hi In a few boards (at least x60, x200, google peppy and likely more) ps2 keyboard does not work consistently in seabios unless a timeout value is set (3sec default for x60), which adds a file etc/ps2-keyboard-spinup containing the max timeout value. A way to fix this to add this delay in the

Re: [coreboot] Back to original BIOS

) bios which does not write protect its bootblock. With this it is possible to flash the vendor bios without having to rely on an external programmer to re-flash coreboot. Backup are essential! -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mail

Re: [coreboot] T520 2630QM 16GB DIMM

hen it starts testing. > According to Sandy bridge datasheets only up to 4GB DDR3 technology is supported, which makes it possibly to use dimms with 2 ranks, with each rank having a capacity of 4GB, hence max 8GB per DIMM. This is a hardware limitation. <#secure method=pgpmime mode=sign>

Re: [coreboot] T520 2630QM 16GB DIMM

Thomas Richter <coreb...@tricnet.de> writes: > Hi, > > Zitat von Arthur Heymans <art...@aheymans.xyz>: > >>> TL;DR - Has anybody either successfully used 16GB DDR3 modules on >>> SandyBridge, can rule it out, or has ideas about how to dig deeper? >>

[coreboot] Warning: Changed changed cmos.layout on many systems

t: Make multibyte options byte aligned" https://review.coreboot.org/#/c/18321/ Kind regards --- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Warning: changed location of EC nvram settings on thinkpad X60 and T60

e, nvramtool -w bluetooth=Enable, etc" Kind regards ------ Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] No external PCIe GPU possible/working on Gigabyte g41m-es2l

Arthur Heymans <art...@aheymans.xyz> writes: > <i1w5d7gf38...@tutanota.com> writes: > >> Hardware: Gigabyte g41m-es2l, latest coreboot git, latest seabios git, two >> nvidia gpu cards tested >> >> I tried to use some external GPU on a g41m-es2l to

Re: [coreboot] Freeze after few bootups

e a hardware issue? > I had this problem also on an other g41m-es2l mainboard with latest libreboot > image installed. So it does not seem to be hardware related and not fixed in > latest > coreboot. > > Anything i could do to help fixing this bug? I have never seen anything

Re: [coreboot] Freeze after few bootups

e a hardware issue? > I had this problem also on an other g41m-es2l mainboard with latest libreboot > image installed. So it does not seem to be hardware related and not fixed in > latest > coreboot. > > Anything i could do to help fixing this bug? I have never seen

Re: [coreboot] No external PCIe GPU possible/working on Gigabyte g41m-es2l

w.coreboot.org/#/c/18511/ (not sure if needed) and https://review.coreboot.org/#/c/18513/ (works but might be improved) fix this issue. -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] No external PCIe GPU possible/working on Gigabyte g41m-es2l

led/disabled. Linux is sometimes unhappy if no form of initialisation (option rom or native) has been performed. > > With OEM-bios the intel card gets disabled and a PCIe GPU works fine. OEM bios does the right thing :) -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Getting an WXGA+ LED MVA panel to work on T400: "G141C1-L01"

isplay-solution.com/pdf/tft-displays/Chi%20Mei%20Innolux/G141C1-L01_V2.0_20100802.pdf > From what I can understand from datasheets this is a dual channel LVDS (as expected)... > > > > -- > Merlin Büge <t...@bluenox07.de> Kind regards -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Attempt to porting coreboot to Gigabyte ga-945gcm-s2l

http://x86.renejeschke.de/html/file_module_x86_id_325.html. What does this mean? Did the raminit not work? -- Kind regards Arthur Heymans coreboot.log13 Description: coreboot.log -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Petitboot based bootloader

://github.com/open-power/op-build Kind Regards -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ISOLINUX gfx problems under qemu/coreboot/SeaBIOS

ck to a > text-based menu. A quick test shows me that selecting CONFIG_SEABIOS_VGA_COREBOOT is the culprit. This change https://review.coreboot.org/#/c/16965/ selects this by default when native graphic init is used but apparently needs an exception for QEMU. Kind regards -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Attempt to porting coreboot to Gigabyte ga-945gcm-s2l

e (like thinkpad x60). Having read all the i945 raminit code (this is not MRC but native coreboot code AFAIK) it does seem to be written with 667MHz fsb (945gm laptops like thinkpad x60)and 533MHz fsb (945gc inteld945gclf) in mind. So I will soon try to confirm this theory with 533MHz fsb cpu. > >

Re: [coreboot] Attempt to porting coreboot to Gigabyte ga-945gcm-s2l

nly) and 533fsb (Intel d945gclf atom board). I guess I'll have to run vendor through serialICE and see how MCHBARS are configured with inteltool with 800fsb and 1067fsb cpus. Kind regards -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Removing ME on G45 desktop chipset - same as GM45 mobile?

d ICH10R southbridge. ICH10 supports descriptorless mode just like ICH9, so like ICH9 you can probably modify the firmware descriptor to boot without updating ME firmware, or simply remove the firmware descriptor. No idea if the 'procedure?' to do this would be the same. Kind regards -- Arthur H

Re: [coreboot] Overheating on f2a85-m

on vendor UEFI, so this issue is > specific to Coreboot. Any idea what I can do? > If you notice a difference in CPU fan speed, that would be my guess since it looks fan control (super I/O) is rather minimally configured in coreboot. Kind regards. -- Arthur Heymans -- coreboot maili

Re: [coreboot] Lenovo Thinkpad X201: cannot boot encrypted Debian w/Coreboot & GRUB2

ode written in ada/spark, which might set up display correctly... > Is there anyone on the list who has Coreboot working on an X201 who > would be willing to share their .config file, so that I might see how > they succeeded where I am failing? > > Thanks! Kind regards -- Arthur Heyma

Re: [coreboot] Rowhammer DRAM Refresh

printk(BIOS_DEBUG, "Refresh: %s\n", sysinfo->refresh?"7.8us":"15.6us"); } -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VGA and Graphics

his should allow getting rid of the option ROM if real mode support is >not required. Would great to have indeed, who knows if other OS drivers will mandate VBT one day. Kind regards. -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] kfsn4-dre: Tested RAM configurations?

disable a dimm if they are unmatched. -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Where to get ME image/flash descriptors for the x220?

the EC firmware if > that could potentially cause problems, I of course do not know if it > has DMA. > Only existing tool to flash EC is using vendor tool. EC are only accessed trough port mapped IO (or on newer ones also via memory mapped IO). EC itself does not have DMA afaik. -- A

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

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)? > > Thanks, > > Paul Kind regards -- Arthur Heyma

Re: [coreboot] Some updated instructions to flash coreboot to the Thinkpad X60 from vendor bios

Peter Stuge <pe...@stuge.se> writes: > Arthur Heymans wrote: >> https://gist.github.com/ArthurHeymans/c5ef494ada01af372735f237f6c6adbe > > I note these differences from what I wrote up in the wiki: > (that may no longer be there though) > It's still there for the most

[coreboot] Some updated instructions to flash coreboot to the Thinkpad X60 from vendor bios

Hi With some new code and methods the process of flashing a thinkpad x60 from vendor bios (and to some extend a thinkpad t60) can be eased a bit and wrote down a hopefully useful guide: Here is the link: https://gist.github.com/ArthurHeymans/c5ef494ada01af372735f237f6c6adbe Feedback is of

Re: [coreboot] x86: best approach to debug consumer hardware?

ed some tweaking). Kind regards -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot community meeting: August 17, 2017

(no EFI bootloader on it), it seemed to work fine and greeted me with the tianocore loading screen. -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] [RFC] Removing RTC configurable baud rate

Hi In the latest CCM[1] the question was raised whether someone still uses the configuration option baud_rate from RTC nvram (CMOS) and if not maybe think about removing this. The issues raised with this code were: * they are an extra burden to maintain since console init is done over multiple

Re: [coreboot] Blobless coreboot on Sandy Bridge and Ivy Bridge?

it for every display output). There is an FSP path for sandy bridge but it is not used much due to native code being easier to work with. > > Thanks <#secure method=pgpmime mode=sign> -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] GM45 ich9deblob and intel ME question

f vendor_layout Then only flash the descriptor region: flashrom -w x200-descriptor --layout vendor_layout --image fd > Thanks in advance, > Michael Widlok -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] problems with compilation for asrock g41c-gs-2.0

rc/misc.o > Compile checking out/src/stacks.o > Compile checking out/src/output.o > Not sure what you are asking here... > Third How can I test my ROM with and emulator before installing it? > Not possible unless the rom is compiled for a virtual target like qemu. On real hardwar

[coreboot] Why does src/soc/intel/ exist?

/northbridge/amd memory controller code resides, while in src/southbridge the code for both the northbridge and the southbridge resides. So my question is why does the newer codebase need to be separated like this and what is the benefit of doing so? Kind regards Arthur Heymans -- coreboot

Re: [coreboot] Why does src/soc/intel/ exist?

Ok thanks for clarifying. Aaron Durbin <adur...@google.com> writes: > On Tue, May 2, 2017 at 5:24 AM, Arthur Heymans <art...@aheymans.xyz> wrote: >> Hi >> >> I am wondering why newer intel code is being pushed to src/soc/intel/*/ >> instead of the tradi

Re: [coreboot] Problems building coreboot 4.6

util/cbfstool/lz4frame.c: Add comment to fall through" Kind regards -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] wiki backup

It is however read- only. Kind regards -- Arthur Heymans 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] 16 GPUs on one board

you think Coreboot will get around this hangup and, if so, > can you advise a > motherboard for me to test with? > > Its been a long time sense I last compiled linuxbios. ;-) > > Thanks > -Adam Kind regards -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] 16 GPUs on one board

he win! > > Is this just a BIOS level issue? Or is there some hardware component I should > be aware of? > > Thanks for the help. > -Adam > -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] coreboot community meeting January 5th, 2017 report

Dear coreboot community This is the report of yesterdays community meeting: General coreboot news & Discussion == There is patch [1] up for review that implements LinuxBoot as payload. - Currently with u-root in the initrd, which is an userspace entirely

Re: [coreboot] Are multiple GPUs with lots of memory (ex: 8GB+8GB) supported in coreboot?

common 2G mmio space below 4G I think it is unlikely for 2 external GPU's to be an issue. It would of course be nice to have 64bit BAR support but that would require substantial changes in the allocator and more importantly a lot of time spend in a sane and thoughtful design... > Thanks! -- ===

Re: [coreboot] [AMD/fam15h] coreboots update_microcode is NOT working, and I know why

"cpu_microcode_bins" isnt defined, microcode_amd_fam15h.bin > isnt included, and update_microcode.c is either never launched or > gives an error > It is tested and the update is done quite early on to make sure the CPU operates properly before done any other initialization. -- ==

[coreboot] How to handle vbt.bin

on devices from big coreboot vendors (like Google). So what are your thoughts on this? Kind regards Arthur Heymans -- [1] https://review.coreboot.org/#/c/coreboot/+/18902/ [2] https://review.coreboot.org/#/c/coreboot/+/19905/ -- coreboot mailing list: coreboot@coreboot.org https

Re: [coreboot] Looking for a volunteer to add Fam15h spectre MSR to coreboot

hich case it needs to be programmed on each AP... Kind regards -- == Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Looking for a volunteer to add Fam15h spectre MSR to coreboot

lso dispatch >serializing). > >This mode of LFENCE may be enabled by setting MSR C001_1029[1]=1. > >This is important and covers a variety of boards such as the KGPE-D16, >KCMA-D8 and G505s (all the last and best owner controlled x86_64 >systems) -- Arthur Heymans-- coreboot

Re: [coreboot] FSP 1.0 Sandy-/Ivybridge removal

t in place to keep that fsp bootpath happy) I fully endorse the removal of this code. -- == Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Fallback mechanisms on x86 with C_ENVIRONMENT_BOOTBLOCK

a proper default FMAP, populate the CBFS FMAP regions, implementing a cbfs_locator) but does allow for nice features like locking the fallback CBFS region to make sure the fallback can't be erased by accident. Any thought or suggestions? Kind regards Arthur Heymans

Re: [coreboot] [flashrom] [LinuxBoot] FOSDEM 2019 deadline today

ome hardware to showcase but I don't own shiny new stuff. Maybe my setup using Felix's qspimux that I use to quickly test roms on hardware can be interesting to showcase? Kind regards -- ====== Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mail

[coreboot] Testing modernizing patches on ASUS KGPE-D16. (was Re: Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?)

ith DDR3 (implements S3 resume) and a SPI boot medium, that would be fun. It does not look this has anything to do with the original thread title so sorry for hijacking it a little... > Regards > > Felix Kind regards -- == Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Testing asked, implementing POSTCAR stage

globals can be dropped are FSP1.0 platforms and geode_lx. geode_lx still has to implement EARLY_CBMEM (requirement for 4.7 and 4.9 is coming soon)... Kind regards Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] AMD fam10 relocatable ramstage

and resetting and programming that value on AP's Kind regards Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Further coreboot releases, setting new standards

ds >> > in the tree is a nice service to Jay. Thanks, but we're well >> aware. >> > Can you also convince us that it's a good service to the users of >> > Jay's boards who expect master (and any future release) to work, given >> > that there's code for boards of that specific name? >> > >> >> First, it's more than just me. I know for a fact that we aren't the only >> ones developing coreboot-based solutions based on both Broadwell-DE >> and Bay Trail that would like to see support continued, not arbitrarily >> removed because it didn't conform to the proposal. So please don't >> belittle it down to being just a "nice service to Jay". This is much bigger >> than just me, my company, or our clients. >> >> > >> > (Jay, sorry for singling you out like that) >> > >> > Regards, >> > Patrick >> > -- >> > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und >> > -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg >> > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado >> >> >> -- >> coreboot mailing list: coreboot@coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot -- == Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] GSOC submission

? Kind regards Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Further coreboot releases, setting new standards

Patrick Georgi via coreboot writes: > Am Fr., 23. Nov. 2018 um 14:43 Uhr schrieb Arthur Heymans > : > > I'd argue for requiring the following: > > In which time frame? The next release, ie May 2019? In two releases, > November 2019? > That is indeed w

[coreboot] Further coreboot releases, setting new standards

Dear coreboot community While the next coreboot release is due for november 2018, I think it is worthwhile to think about further releases and standards we want to set. In the past coreboot adapted numerous general improvements, which were not always ported to all coreboot targets. Keeping those

Re: [coreboot] Supported Mainboard in coreboot is missing because of using LATE_CBMEM_INIT

is this > a > git repository? > Makefile:18: recipe for target 'seabios' failed You can try to build the payload separately. > > Could someone fix the MSI MS6178 mainboard so that it can be used with the > recent coreboot? That would require that platform (i810) to have

Re: [coreboot] Coreboots Board Status have privacy issues for contributors

ease fix this to: > 1) Remove kernel log and replace it with "uname -r" to just know the kernel > version. The kernel log does contain other useful information, so dropping it would make the board status repo less useful. -- == Arthur Heymans -- coreboot mail

Re: [coreboot] Further coreboot releases, setting new standards

ree not to integrate such monsters into coreboot in the future? BTW baytrail has a non FSP port that will likely be in better shape. Kind regards Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Further coreboot releases, setting new standards

5 > (480) 445-9895 (FAX) > jaytalb...@sysproconsulting.com > http://www.sysproconsulting.com > > Original Message ---- > Subject: Re: [coreboot] Further coreboot releases, setting new standards > From: Arthur Heymans > Date: Fri, November 23, 2018 8:32 am > To: Patrick G

[coreboot] Depreciating FSP1.1 on soc/intel/quark along with util/checklist

symbols are found. Supposedly it allows board porters to gradually work towards with a checklist of things to do while in reality its just an extra burden to maintain a list of symbols. So can we remove util/checklist? [1] does that. Kind regards Arthur Heymans [1] https://review.coreboot.org/c

[coreboot] getting rid of CAR_GLOBAL and early_variables.h

Hi Currently most x86 platforms have CONFIG_NO_CAR_GLOBAL_MIGRATION set by implementing POSTCAR_STAGE. This means that global variables during CAR stages don't need to be migrated to cbmem when initializing cbmem, as stages are cleanly separated programs (in other words you don't tear down CAR

[coreboot] Re: getting rid of CAR_GLOBAL and early_variables.h

Arthur Heymans writes: > Now moving forward it would be a nice goal to set for the October > release 2020 to have NO_CAR_GLOBAL_MIGRATION as a mandatory feature? > This was already discussed in [2], without a decisive conclusion. I meant Oktober 2019, that is 9 months from now which s

[coreboot] Re: [EC] ACPI DSDT not complete

ase) implements the things you are asking for. Just wondering is this a mainline driver in FreeBSD? Linux got one quite recently. -- == Arthur Heymans ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Shubhendra - GSoC proposal Inquiry about "Port payloads to RISC-V"

People can contribute to coreboot without even owning a physical device on which coreboot runs, let alone *your* favorite board. The board you suggest is not a good example at all. The code supporting that board has some serious quality issues. Kind regards -- == Arthur Heym

[coreboot] Re: T440P: Unable to initialize memory speeds above 1600 MT/s

with a similar PEI/mrc.bin is better at guarding against invalid values. Maybe that code should be adapted to haswell. 1600MT/s is what the controller officially supports. Anything faster is overclocking and the mrc.bin likely does not support that. -- Arthur Heymans _

[coreboot] Re: [RFC] Using relocatable module program parameters to pass cbmem_top() on X86

iew.coreboot.org/c/coreboot/+/36143/ https://review.coreboot.org/c/coreboot/+/36144 https://review.coreboot.org/c/coreboot/+/36145/ > Any thoughts? > > Arthur Heymans > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsu

[coreboot] [RFC] Using relocatable module program parameters to pass cbmem_top() on X86

as on S3 resume the ramstage is typically fetched from RAM (cbmem or tseg stage cache). Any thoughts? Arthur Heymans ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: System hangs during pci init

ic mailing list... > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > Kind regards -- == Arthur Heymans ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe s

[coreboot] Re: Gotta look for the next target after Asus P2B family and i440BX

is not pro, but I don't > know off my head what the difference is. And I get to deal with ME. > Best way to deal with ME is to not deal with it at all and just flash the BIOS region ;). Some possible differences are enabled/disabled pci devices and gpio's. You should be able to add th

[coreboot] Re: coreboot not starting on denverton_ns

Hi Try with https://review.coreboot.org/c/coreboot/+/55389 applied. Kind regards Arthur On Thu, Jun 10, 2021 at 3:16 PM Sumo wrote: > Hi, > > Coreboot is not starting on denverton due to this commit: > * 0f068a600e drivers/intel/fsp2_0: Fix the FSP-T position > (found this by doing a manual

[coreboot] Re: asus/p2b - not enough space in cbfs for default build since i440bx bootblock console enable

of boot performance on this platform. - I also have some WIP code to merge postcar into ramstage which would save 15k. Maybe on coreboot release 4.15 you will have a better time building a fully working image with the default configuration. Kind regards Arthur Heymans On Fri, May 21, 2021 at 7:08 AM

[coreboot] Re: Dropping the "cbfs master header" file

Hi Werner Sounds good. I got rid of the SeaBIOS dependency on the CBFS master haeder: https://mail.coreboot.org/hyperkitty/list/seab...@seabios.org/thread/PSLZAMCG7C5IU6TLEGXWZCESXHPYUS76/ Maybe that can be of use for you? Arthur On Fri, Apr 30, 2021 at 12:38 PM Zeh, Werner wrote: > Hi

[coreboot] Dropping the "cbfs master header" file

ption or add a pointer to "fsp-t" at a fixed location in the bootblock and have the tooling update the pointer during the build process. I think the Kconfig option is the least amount of work and cbfstool is already overloaded with options and flags, so my pre

[coreboot] Re: Intel CBnT tooling and dealing with NDA

Hi Thanks for your input! Peter Stuge writes: > Arthur Heymans wrote: >> To make Intel CBnT (Converged Bootguard and TXT) useful in coreboot some >> tooling is required to generate both a Key Manifest (A signed binary, that >> is checked against a key fused into the ME,

[coreboot] Re: Intel CBnT tooling and dealing with NDA

Patrick Georgi via coreboot writes: > Am Di., 9. Feb. 2021 um 11:34 Uhr schrieb Arthur Heymans : > >  So TL;DR: >  - Is (temporarily) adding a tool to the blobs repo ok? > > If it matches the requirements of the blobs repo wrt. license terms and documentation, I don't see why

[coreboot] Intel CBnT tooling and dealing with NDA

we hope that this is an acceptable solution to the community. So TL;DR: - Is (temporarily) adding a tool to the blobs repo ok? - Is integrating an (optional) not yet open tool into the build system ok? Let me know what you think. Kind regards. Arthur Heymans 9elements GmbH, Kortumstraße 19-21

[coreboot] Re: There is a python in our toolchain?!?

> > As a rule of thumb, any project involving a substantial amount of Python > always ends up needing a Docker container to build. So I'm in the "no" camp > for making Python a dependency, however I think it's fine to keep things > as-is where it can be used for helper scripts and utilities for

[coreboot] Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3

Hi I would like to suggest to deprecate some legacy codepaths inside the coreboot tree and therefore make some newer ones mandatory. The first one I'd like to deprecate is LEGACY_SMP_INIT. This also includes the codepath for SMM_ASEG. This code is used to start APs and do some feature

[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3

> We could announce this deprecation in the 4.16 release notes, then deprecate after 4.18 (8.5 months from now). At that point, we'd create a branch and set up a verification builder so that any deprecated platforms could be continued in the 4.18 branch. That timeline of 8.5 months does sound

[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3

(although there > might have been some other problems undercover). I wonder if it could > help and will be happy to test the new changes related to this. > > > On Wed, Nov 24, 2021 at 8:52 PM Arthur Heymans > wrote: > > > > > We could announce this deprecation in the 4

[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3

we still care about the coreboot marketshare on > > > the worldwide-available consumer PCs. Small improvement in the common > > > source, but a huge loss of boards? (almost 50!). For the sake of the > > > bright future of the coreboot project, this must be prevented at a

[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3

> To address the OP, it seems like there is some activity on getting an > AGESA RESOURCE_ALLOCATOR_V4 working, but is an AGESA PARALLEL_MP init > also needed (and is there any activity or something I can do to help?) > Realize resources may not exist to spoon feed problem definitions to a > level

[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3

lt;< 1) > +#define H_SMRAME (1 << 7) Those are northbridge specific register on how to handle the SMM windows (SMRAM). The BKDG should have something similar. TSEG is also an interesting search parameter. On Thu, Nov 25, 2021 at 7:39 PM awokd via coreboot wrote: > Arthur Hey

[coreboot] Re: TigerLake RVP TCSS init failure

Hi That MTRR setup looks suboptimal for sure, but not fatally flawed. What's located at 0x7700 till 0x8000? I suspect it's just dram but maybe allocated for different purposes like TSEG, GFX stolen memory, If you mark it as such during resource allocation the MTRR solution will be

[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3

ing all the > > > > people who would like to build coreboot for AMD boards from this > list, even right now I am in an > > > > active message exchange with >10 people who are switching to these > boards to run coreboot > > > > on them - and any user may give back to

[coreboot] Re: Proposition to revert GCC 11

Hi It looks like alignment on a packed struct being cast two times to different integers was the root cause for the ironlake platform. https://review.coreboot.org/c/coreboot/+/61938 fixed the issue. Kind regards On Mon, Feb 14, 2022 at 9:12 AM Arthur Heymans wrote: > Hi > > There

[coreboot] Proposition to revert GCC 11

Hi There have been some reports of GCC11 not booting on some AGESA fam15 platforms and on Intel ironlake. I confirmed that on my X201 (ironlake). The system hangs at an endless loop during heci init. The code generated doing that part is not wrong, which makes me think that other code in that

[coreboot] Re: Multi domain PCI resource allocation: How to deal with multiple root busses on one domain

Hi all Thanks a lot for the input. I looked a bit further into this and it looks like only the resource allocation parts assumes one downstream bus under link_list. The rest of coreboot seems to properly account for sibling busses, so maybe making the allocator loop over ->next in busses is not

[coreboot] Re: 2022-03-29 - coreboot UEFI working group meeting minutes

Hi I would like to add a few notes to the meeting notes to clarify things a bit better. * In the coreboot meeting, it was suggested that we push to just use > coreboot tables as they’re already supported in a number of > payloads. This really isn’t practical however. Intel would

[coreboot] Re: Multi domain PCI resource allocation: How to deal with multiple root busses on one domain

this situation (multiple root busses on > one stack) we "virtually" splitted this stack and its resource window to > two or more virtual stacks and later handled as separate stacks. > > Mariusz > > W dniu 17.03.2022 o 19:03, Arthur Heymans pisze: > > Hi > > &

[coreboot] Re: Multi domain PCI resource allocation: How to deal with multiple root busses on one domain

that I was used for some time was to use > something like: > domain 0 > //first root bus > pci 0:0.1end > > //second root bus > pci 0x20:0end //overflow at 0x20 pci bus number boundary > > end &g

[coreboot] Re: Multi domain PCI resource allocation: How to deal with multiple root busses on one domain

Hi Hi > > >> e.g. if we got from HOB info that physical stack x has preallocated PCI >> buses 0x20..0x2f, io form 0x2000..0x2fff, mem 0xd000..0xdfff, mem >> 0x100...0x1ff and there are 2 root buses 0x20 and 0x28 >> instead of adding one domain with "physical" stack we

[coreboot] Re: Multi domain PCI resource allocation: How to deal with multiple root busses on one domain

nction would essentially be a loop over the devicetree struct which seems more fragile when things are being appended to it (scan_bus). On Tue, Mar 22, 2022 at 2:11 PM Mariusz Szafrański via coreboot < coreboot@coreboot.org> wrote: > W dniu 22.03.2022 o 12:38, Arthur Heymans pisze: > >

[coreboot] Re: Security notice: SMM can be hijacked by the OS on APs

might affect a lot more systems than I initially thought. Kind regards Arthur On Fri, Apr 8, 2022 at 12:43 AM Arthur Heymans wrote: > Hi > > When refactoring the coreboot SMM setup I noticed that there is a security > vulnerability in our SMM setup code. > > It boils down to this:

[coreboot] Another day, another SMM loader vulnerability

Hi After last week's SMM loader problem on all but the BSP, I noticed another problem in the SMM setup. The permanent smihandler is currently built as a relocatable module such that coreboot can place it wherever it thinks it's a good idea. (TSEG is not known at buildtime). These relocatable

[coreboot] Re: Another day, another SMM loader vulnerability

roblem in future? Do you think we could find a way to > catch this programmatically soon, rather than humanly too late? > > On Mon, Apr 11, 2022 at 2:48 AM Arthur Heymans > wrote: > > > > Hi > > > > After last week's SMM loader problem on all but the BSP, I

[coreboot] Re: Security notice: SMM can be hijacked by the OS on APs

ve seen us do that in the past (because issues are quite often just fixed in master). Kind regards Arthur On Tue, Apr 12, 2022 at 12:52 AM Peter Stuge wrote: > Arthur Heymans wrote: > > I think this issue might affect a lot more systems than I initially > thought. > > Would it

  1   2   >