[coreboot] Re: QEMU x86 i440fx/piix4 build fails for >= 32MB ROMs - Assertion IS_HOST_SPACE_ADDRESS(host_space_address) failed

[Mike Banon]

Hi there Arthur,

since QEMU could be a convenient playground for those who are using
this recent hardware (i.e. they would like to try embedding a small
Linux ISO into a coreboot+SeaBIOS ROM for QEMU and see how it works
from there) - it would've been nice to have this capability

On Tue, Feb 20, 2024 at 7:05 PM Arthur Heymans  wrote:
>
> Hi Mike
>
> Same thing as on that AMD platform. Qemu does not support that. In general 
> x86 will require a special memory map for larger than 16M boot medium, as 
> below 4G - 16M there are other default MMIO things that will conflict, like 
> the LAPIC base. That capability to deal with larger flash is only present on 
> fairly recent hardware and in that case coreboot often supports it.
>
> Kind regards.
>
> On Tue, Feb 20, 2024 at 4:42 PM Mike Banon  wrote:
>>
>> Dear friends, thank you very much for all your replies - especially to
>> Felix Held for his research on the possibility of >16 MB SPI flash on
>> these AMD boards.
>>
>> > I guess what I’m thinking is I’m not sure it’s worth the effort to make a 
>> > build work for something that is physically impossible
>>
>> Hmmm... there could be newer boards with 4-byte SPI Flash controller,
>> and by the way there is no physical impossibility for QEMU - which is
>> also failing.
>>
>> I just tried the latest coreboot (so without any git reverts of
>> restore_agesa.sh that restore the opensource AGESA boards) - picked a
>> virtual BOARD_EMULATION_QEMU_X86_I440FX board with almost-default
>> coreboot config (only set CONFIG_COREBOOT_ROMSIZE_KB_65536 and
>> CONFIG_CBFS_SIZE=0x0400 , everything else is unchanged) - but have
>> exactly the same error:
>>
>> ...
>> CC bootblock/mainboard/emulation/qemu-i440fx/bootmode.o
>> CC bootblock/mainboard/emulation/qemu-i440fx/fw_cfg.o
>> CC bootblock/southbridge/intel/common/reset.o
>> CC bootblock/southbridge/intel/common/rtc.o
>> CC bootblock/southbridge/intel/i82371eb/bootblock.o
>> LINK   cbfs/fallback/bootblock.debug
>> /my-path-to/coreboot-new/util/crossgcc/xgcc/bin/i386-elf-ld.bfd:
>> warning: build/cbfs/fallback/bootblock.debug has a LOAD segment with
>> RWX permissions
>> OBJCOPYcbfs/fallback/bootblock.elf
>> OBJCOPYbootblock.raw.elf
>> OBJCOPYbootblock.raw.bin
>> Created CBFS (capacity = 67108324 bytes)
>> BOOTBLOCK
>> CBFS   cbfs_master_header
>> CBFS   fallback/romstage
>> Image SIZE 67108864
>> cbfstool: /my-path-to/coreboot-new/util/cbfstool/cbfstool.c:1186:
>> cbfstool_convert_mkstage: Assertion
>> `IS_HOST_SPACE_ADDRESS(host_space_address)' failed.
>> Aborted (core dumped)
>> make: *** [Makefile.mk:1211: build/coreboot.pre] Error 13
>>
>> On Mon, Feb 19, 2024 at 9:24 PM ron minnich  wrote:
>> >
>> > I guess what I’m thinking is I’m not sure it’s worth the effort to make a 
>> > build work for something that is physically impossible
>> >
>> > On Mon, Feb 19, 2024 at 12:11 Felix Held  
>> > wrote:
>> >>
>> >> Hi Mike,
>> >>
>> >> SPI NOR flash chips with more than 16MByte use 4 byte addresses while
>> >> ones with up to 16MBytes use 3 byte addresses. The SPI flash controllers
>> >> on older systems often only support the 3 byte address mode. Also
>> >> typically only up to 16 MBytes worth of SPI flash contents can be mapped
>> >> right below the 4GB boundary, since the 16MByte below that contain the
>> >> MMIO of for example LAPIC and IOAPIC.
>> >> Had a quick look at the BKDG for family 16h model 30h, which is newer
>> >> than the chip used on G505S or A88XM-E, and it didn't have the registers
>> >> in the SPI controller that I'd expect to be present if it supports the 4
>> >> byte address mode.
>> >>
>> >> Regards,
>> >> Felix
>> >>
>> >> On 19/02/2024 19:55, Mike Banon wrote:
>> >> > Theoretically - yes, if someone finds & solders there a 32 MB (256
>> >> > megabit) SPI Flash chip with 8 pins. Hopefully, as the proprietary
>> >> > UEFIs become more & more bloated, these large capacity chips will
>> >> > become more widely available in the near future. And, since a coreboot
>> >> > itself consumes less than 1MB on these "opensource AGESA" AMD systems
>> >> > such as G505S and A88XM-E, all this room will allow some very
>> >> > interesting experiments! If even 3

[coreboot] Re: QEMU x86 i440fx/piix4 build fails for >= 32MB ROMs - Assertion IS_HOST_SPACE_ADDRESS(host_space_address) failed

[Mike Banon]

Dear friends, thank you very much for all your replies - especially to
Felix Held for his research on the possibility of >16 MB SPI flash on
these AMD boards.

> I guess what I’m thinking is I’m not sure it’s worth the effort to make a 
> build work for something that is physically impossible

Hmmm... there could be newer boards with 4-byte SPI Flash controller,
and by the way there is no physical impossibility for QEMU - which is
also failing.

I just tried the latest coreboot (so without any git reverts of
restore_agesa.sh that restore the opensource AGESA boards) - picked a
virtual BOARD_EMULATION_QEMU_X86_I440FX board with almost-default
coreboot config (only set CONFIG_COREBOOT_ROMSIZE_KB_65536 and
CONFIG_CBFS_SIZE=0x0400 , everything else is unchanged) - but have
exactly the same error:

...
CC bootblock/mainboard/emulation/qemu-i440fx/bootmode.o
CC bootblock/mainboard/emulation/qemu-i440fx/fw_cfg.o
CC bootblock/southbridge/intel/common/reset.o
CC bootblock/southbridge/intel/common/rtc.o
CC bootblock/southbridge/intel/i82371eb/bootblock.o
LINK   cbfs/fallback/bootblock.debug
/my-path-to/coreboot-new/util/crossgcc/xgcc/bin/i386-elf-ld.bfd:
warning: build/cbfs/fallback/bootblock.debug has a LOAD segment with
RWX permissions
OBJCOPYcbfs/fallback/bootblock.elf
OBJCOPYbootblock.raw.elf
OBJCOPYbootblock.raw.bin
Created CBFS (capacity = 67108324 bytes)
BOOTBLOCK
CBFS   cbfs_master_header
CBFS   fallback/romstage
Image SIZE 67108864
cbfstool: /my-path-to/coreboot-new/util/cbfstool/cbfstool.c:1186:
cbfstool_convert_mkstage: Assertion
`IS_HOST_SPACE_ADDRESS(host_space_address)' failed.
Aborted (core dumped)
make: *** [Makefile.mk:1211: build/coreboot.pre] Error 13

On Mon, Feb 19, 2024 at 9:24 PM ron minnich  wrote:
>
> I guess what I’m thinking is I’m not sure it’s worth the effort to make a 
> build work for something that is physically impossible
>
> On Mon, Feb 19, 2024 at 12:11 Felix Held  wrote:
>>
>> Hi Mike,
>>
>> SPI NOR flash chips with more than 16MByte use 4 byte addresses while
>> ones with up to 16MBytes use 3 byte addresses. The SPI flash controllers
>> on older systems often only support the 3 byte address mode. Also
>> typically only up to 16 MBytes worth of SPI flash contents can be mapped
>> right below the 4GB boundary, since the 16MByte below that contain the
>> MMIO of for example LAPIC and IOAPIC.
>> Had a quick look at the BKDG for family 16h model 30h, which is newer
>> than the chip used on G505S or A88XM-E, and it didn't have the registers
>> in the SPI controller that I'd expect to be present if it supports the 4
>> byte address mode.
>>
>> Regards,
>> Felix
>>
>> On 19/02/2024 19:55, Mike Banon wrote:
>> > Theoretically - yes, if someone finds & solders there a 32 MB (256
>> > megabit) SPI Flash chip with 8 pins. Hopefully, as the proprietary
>> > UEFIs become more & more bloated, these large capacity chips will
>> > become more widely available in the near future. And, since a coreboot
>> > itself consumes less than 1MB on these "opensource AGESA" AMD systems
>> > such as G505S and A88XM-E, all this room will allow some very
>> > interesting experiments! If even 3 MB is enough for me to put 9 of 10
>> > floppies of the collection described here (thanks to LZMA compression)
>> > - http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#Useful_floppies
>> > , guess what wonders we can do with 31 MB... ;-)
>> >
>> > On Mon, Feb 19, 2024 at 7:17 PM ron minnich  wrote:
>> >>
>> >> Can the system you are discussing actually use larger than 16 MB rom?
>> >>
>> >>   I am wondering about your use of the phrase “out of curiosity”
>> >>
>> >> On Mon, Feb 19, 2024 at 07:05 Mike Banon  wrote:
>> >>>
>> >>> Small bump, I am still having this error while (out of curiosity)
>> >>> trying to build the Lenovo G505S ROM for 32 MB or 64 MB spi flash:
>> >>>
>> >>>  OBJCOPYbootblock.raw.bin
>> >>> Created CBFS (capacity = 33488356 bytes)
>> >>>  BOOTBLOCK
>> >>>  CBFS   cbfs_master_header
>> >>>  CBFS   fallback/romstage
>> >>> Image SIZE 33554432
>> >>> cbfstool: 
>> >>> /media/mint/2183183a-158f-476a-81af-b42534a68706/shared/core/coreboot/util/cbfstool/cbfstool.c:1186:
>> >>> cbfstool_convert_mkstage: Assertion
>> >>> `IS_HOST_SPACE_ADDRESS(host_space_address)' failed.
>> >>> Aborted (core dumped)
>> 

[coreboot] Re: QEMU x86 i440fx/piix4 build fails for >= 32MB ROMs - Assertion IS_HOST_SPACE_ADDRESS(host_space_address) failed

[Mike Banon]

Theoretically - yes, if someone finds & solders there a 32 MB (256
megabit) SPI Flash chip with 8 pins. Hopefully, as the proprietary
UEFIs become more & more bloated, these large capacity chips will
become more widely available in the near future. And, since a coreboot
itself consumes less than 1MB on these "opensource AGESA" AMD systems
such as G505S and A88XM-E, all this room will allow some very
interesting experiments! If even 3 MB is enough for me to put 9 of 10
floppies of the collection described here (thanks to LZMA compression)
- http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#Useful_floppies
, guess what wonders we can do with 31 MB... ;-)

On Mon, Feb 19, 2024 at 7:17 PM ron minnich  wrote:
>
> Can the system you are discussing actually use larger than 16 MB rom?
>
>  I am wondering about your use of the phrase “out of curiosity”
>
> On Mon, Feb 19, 2024 at 07:05 Mike Banon  wrote:
>>
>> Small bump, I am still having this error while (out of curiosity)
>> trying to build the Lenovo G505S ROM for 32 MB or 64 MB spi flash:
>>
>> OBJCOPYbootblock.raw.bin
>> Created CBFS (capacity = 33488356 bytes)
>> BOOTBLOCK
>> CBFS   cbfs_master_header
>> CBFS   fallback/romstage
>> Image SIZE 33554432
>> cbfstool: 
>> /media/mint/2183183a-158f-476a-81af-b42534a68706/shared/core/coreboot/util/cbfstool/cbfstool.c:1186:
>> cbfstool_convert_mkstage: Assertion
>> `IS_HOST_SPACE_ADDRESS(host_space_address)' failed.
>> Aborted (core dumped)
>> make: *** [Makefile.mk:1210: build/coreboot.pre] Error 134
>>
>> Meanwhile, it builds fine for 4 MB / 8 MB / 16 MB , only these large
>> sizes are a problem
>>
>> On Sat, Jun 25, 2022 at 12:55 AM Julius Werner  wrote:
>> >
>> > I can see a little bug that makes this return a confusing error (it
>> > should have really failed with `SPI flash address(0x300) not in any
>> > mmap window!`), and we can fix that if you want. But that still won't
>> > make this build (and my patch didn't cause the underlying problem,
>> > before that it may have built an image but it probably wouldn't have
>> > booted). By default cbfstool only expects the top 16MB of the flash to
>> > be memory-mapped, so it cannot link XIP stages into areas outside of
>> > that. The real solution is to either change your FMAP to put the
>> > COREBOOT section into the top 16MB (we might want to change the
>> > auto-generated default FMAP to do that), or pass
>> > --ext-win-base/--ext-win-size options to cbfstool to tell it how to
>> > map areas below the top 16MB.
>> >
>> > On Thu, Jun 23, 2022 at 1:09 AM Paul Menzel  wrote:
>> > >
>> > > Dear Mike,
>> > >
>> > >
>> > > Am 23.06.22 um 09:49 schrieb Mike Banon:
>> > > > If I use a default config for i440fx/piix4, building a 16MB ROM works
>> > > > fine, but 32MB or 64MB doesn't work anymore:
>> > > >
>> > > > ...
>> > > >  CC postcar/southbridge/intel/common/rtc.o
>> > > >  LINK   cbfs/fallback/postcar.debug
>> > > >  OBJCOPYcbfs/fallback/romstage.elf
>> > > >  CREATE 
>> > > > build/mainboard/emulation/qemu-i440fx/cbfs-file.vqaXlP.out (from 
>> > > > /home/my_custom_path_to/coreboot/.config)
>> > > >  CC+STRIP   src/lib/cbfs_master_header.c
>> > > >  OBJCOPYcbfs/fallback/bootblock.elf
>> > > >  OBJCOPYbootblock.raw.elf
>> > > >  OBJCOPYbootblock.raw.bin
>> > > > Created CBFS (capacity = 33553892 bytes)
>> > > >  BOOTBLOCK
>> > > >  CBFS   cbfs_master_header
>> > > >  CBFS   fallback/romstage
>> > > > cbfstool: 
>> > > > /home/my_custom_path_to/coreboot/util/cbfstool/cbfstool.c:1145: 
>> > > > cbfstool_convert_mkstage: Assertion 
>> > > > `IS_HOST_SPACE_ADDRESS(host_space_address)' failed.
>> > > > make: *** [Makefile.inc:1116: build/coreboot.pre] Aborted
>> > >
>> > > Thank you for the report. It looks like a regression of commit
>> > > 20ad36547e25 (cbfstool: Do host space address conversion earlier when
>> > > adding files) [1].
>> > >
>> > > Building a 32 MB ROM also fails for emulation/qemu-q35
>> > > (`CONFIG_BOARD_EMULATION_QEMU_X86_Q35=y`).
>> > >
>> > >
>> > > Kind regards,
>> > >
>> > > Paul
>> > >
>> > >
>> > > [1]: https://review.coreboot.org/c/coreboot/+/60018
>> > ___
>> > coreboot mailing list -- coreboot@coreboot.org
>> > To unsubscribe send an email to coreboot-le...@coreboot.org
>>
>>
>>
>> --
>> Best regards, Mike Banon
>> Open Source Community Manager of 3mdeb - https://3mdeb.com/
>> ___
>> coreboot mailing list -- coreboot@coreboot.org
>> To unsubscribe send an email to coreboot-le...@coreboot.org



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: QEMU x86 i440fx/piix4 build fails for >= 32MB ROMs - Assertion IS_HOST_SPACE_ADDRESS(host_space_address) failed

[Mike Banon]

Small bump, I am still having this error while (out of curiosity)
trying to build the Lenovo G505S ROM for 32 MB or 64 MB spi flash:

OBJCOPYbootblock.raw.bin
Created CBFS (capacity = 33488356 bytes)
BOOTBLOCK
CBFS   cbfs_master_header
CBFS   fallback/romstage
Image SIZE 33554432
cbfstool: 
/media/mint/2183183a-158f-476a-81af-b42534a68706/shared/core/coreboot/util/cbfstool/cbfstool.c:1186:
cbfstool_convert_mkstage: Assertion
`IS_HOST_SPACE_ADDRESS(host_space_address)' failed.
Aborted (core dumped)
make: *** [Makefile.mk:1210: build/coreboot.pre] Error 134

Meanwhile, it builds fine for 4 MB / 8 MB / 16 MB , only these large
sizes are a problem

On Sat, Jun 25, 2022 at 12:55 AM Julius Werner  wrote:
>
> I can see a little bug that makes this return a confusing error (it
> should have really failed with `SPI flash address(0x300) not in any
> mmap window!`), and we can fix that if you want. But that still won't
> make this build (and my patch didn't cause the underlying problem,
> before that it may have built an image but it probably wouldn't have
> booted). By default cbfstool only expects the top 16MB of the flash to
> be memory-mapped, so it cannot link XIP stages into areas outside of
> that. The real solution is to either change your FMAP to put the
> COREBOOT section into the top 16MB (we might want to change the
> auto-generated default FMAP to do that), or pass
> --ext-win-base/--ext-win-size options to cbfstool to tell it how to
> map areas below the top 16MB.
>
> On Thu, Jun 23, 2022 at 1:09 AM Paul Menzel  wrote:
> >
> > Dear Mike,
> >
> >
> > Am 23.06.22 um 09:49 schrieb Mike Banon:
> > > If I use a default config for i440fx/piix4, building a 16MB ROM works
> > > fine, but 32MB or 64MB doesn't work anymore:
> > >
> > > ...
> > >  CC postcar/southbridge/intel/common/rtc.o
> > >  LINK   cbfs/fallback/postcar.debug
> > >  OBJCOPYcbfs/fallback/romstage.elf
> > >  CREATE 
> > > build/mainboard/emulation/qemu-i440fx/cbfs-file.vqaXlP.out (from 
> > > /home/my_custom_path_to/coreboot/.config)
> > >  CC+STRIP   src/lib/cbfs_master_header.c
> > >  OBJCOPYcbfs/fallback/bootblock.elf
> > >  OBJCOPYbootblock.raw.elf
> > >  OBJCOPYbootblock.raw.bin
> > > Created CBFS (capacity = 33553892 bytes)
> > >  BOOTBLOCK
> > >  CBFS   cbfs_master_header
> > >  CBFS   fallback/romstage
> > > cbfstool: /home/my_custom_path_to/coreboot/util/cbfstool/cbfstool.c:1145: 
> > > cbfstool_convert_mkstage: Assertion 
> > > `IS_HOST_SPACE_ADDRESS(host_space_address)' failed.
> > > make: *** [Makefile.inc:1116: build/coreboot.pre] Aborted
> >
> > Thank you for the report. It looks like a regression of commit
> > 20ad36547e25 (cbfstool: Do host space address conversion earlier when
> > adding files) [1].
> >
> > Building a 32 MB ROM also fails for emulation/qemu-q35
> > (`CONFIG_BOARD_EMULATION_QEMU_X86_Q35=y`).
> >
> >
> > Kind regards,
> >
> > Paul
> >
> >
> > [1]: https://review.coreboot.org/c/coreboot/+/60018
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] src/soc/intel/xeon_sp/Kconfig:95:warning: config symbol defined without type

[Mike Banon]

After this commit - https://review.coreboot.org/c/coreboot/+/79058 -
now I always have this warning while doing a "make menuconfig" :

src/soc/intel/xeon_sp/Kconfig:95:warning: config symbol defined without type

To fix this, please add the "bool" line before "default y" to specify
the config symbol type.

P.S. wrote about this problem under the change about ~1 month ago, but
maybe the notifications are not working for the merged changes - so
posting it here just in case
-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] 48 hours before DUG #4 & vPub 0x9 opensource online party!

[Mike Banon]

Dear friends, I invite you to a joint DUG #4 & vPub 0x9 event that
starts this Thursday at 5 PM UTC - in exactly 48 hours since this
e-mail. Would you like to learn & discuss about:

* coreboot-based Dasharo firmware distribution and its unique features?
* cool hardware devices supporting the opensource firmwares, like
NovaCustom new laptop?
* opensource firmware world and its current events in general, i.e.
AMD OpenSIL news?

Then this upcoming event - is an excellent opportunity for you to have
a great time in a friendly company of firmware enthusiasts.

The 1st part of our event - DUG #4 - is dedicated to Dasharo
distribution of coreboot opensource firmware with advanced features
like GUI & FLASHBIOS and the ecosystem around it. DUG will take place
between 5-7 PM UTC - and then around 7 PM UTC will switch to vPub
opensource online party! The past joint events have been highly
successful and I'm sure you will find this one interesting as well ;-)
Both sound/video and text chats will be available for your convenience

More details and Join links are available here -
[*] https://vpub.dasharo.com/e/11/dasharo-user-group-4

P.S. to avoid missing out future events,
join our Matrix or tiny-volume event notification newsletter:
[*] https://matrix.to/#/#dasharo-osf-vpub:matrix.org
[*] https://newsletter.3mdeb.com/subscription/0_K65I7ro
(just ~4 e-mails per year)

--
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: commit 0eab62b makes menuconfig more strict regarding the old configs

[Mike Banon]

Thank you, the patch at https://review.coreboot.org/c/coreboot/+/79298
really helps, I +1 it now

On Wed, Nov 29, 2023 at 8:39 PM Mike Banon  wrote:
>
> At the moment none of the suggestions work (tried make oldconfig, make
> olddefconfig, make menuconfig KCONFIG_WERROR=0
> KCONFIG_WARN_UNKNOWN_SYMBOLS=0 "). Any workaround alternative to git
> revert of this commit would be nice
>
> On Wed, Nov 29, 2023 at 1:41 PM Patrick Georgi via coreboot
>  wrote:
> >
> > On 29.11.23 00:20, Martin Roth via coreboot  wrote:
> > > Hey Mike,
> > > I think you should be able to just append change the kconfig values when 
> > > you run make to override the current settings.
> > >
> > > something like
> > > `make menuconfig KCONFIG_WERROR=0 KCONFIG_WARN_UNKNOWN_SYMBOLS=0`
> > >
> > > if we update where they're set in the makefile from := to ?=, you could 
> > > even just have them set as environment variables so they don't need to be 
> > > on the command line.
> >
> > Kconfig doesn't check for the value in the variables, just for their 
> > presence. Therefore we'd need to unexport the variables, and that's not 
> > possible per-target (despite the gnu make docs claiming otherwise) or on 
> > the make command line.
> >
> > I started a discussion in another thread on that, maybe we could discuss 
> > this over at 
> > https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/M543FU2OIHEMLAFAFAPCFHAD36ISAEKO/?
> > _______
> > coreboot mailing list -- coreboot@coreboot.org
> > To unsubscribe send an email to coreboot-le...@coreboot.org
>
>
>
> --
> Best regards, Mike Banon
> Open Source Community Manager of 3mdeb - https://3mdeb.com/



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: commit 0eab62b makes menuconfig more strict regarding the old configs

[Mike Banon]

At the moment none of the suggestions work (tried make oldconfig, make
olddefconfig, make menuconfig KCONFIG_WERROR=0
KCONFIG_WARN_UNKNOWN_SYMBOLS=0 "). Any workaround alternative to git
revert of this commit would be nice

On Wed, Nov 29, 2023 at 1:41 PM Patrick Georgi via coreboot
 wrote:
>
> On 29.11.23 00:20, Martin Roth via coreboot  wrote:
> > Hey Mike,
> > I think you should be able to just append change the kconfig values when 
> > you run make to override the current settings.
> >
> > something like
> > `make menuconfig KCONFIG_WERROR=0 KCONFIG_WARN_UNKNOWN_SYMBOLS=0`
> >
> > if we update where they're set in the makefile from := to ?=, you could 
> > even just have them set as environment variables so they don't need to be 
> > on the command line.
>
> Kconfig doesn't check for the value in the variables, just for their 
> presence. Therefore we'd need to unexport the variables, and that's not 
> possible per-target (despite the gnu make docs claiming otherwise) or on the 
> make command line.
>
> I started a discussion in another thread on that, maybe we could discuss this 
> over at 
> https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/M543FU2OIHEMLAFAFAPCFHAD36ISAEKO/?
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] commit 0eab62b makes menuconfig more strict regarding the old configs

[Mike Banon]

In my case, a csb_patcher.sh script [1] - among other things -
delivers the example config files for the opensource AGESA boards.
Although these configs haven't been updated for a while (i.e. a last
update of AMD Lenovo G505S config [2] is 1 year ago), I got away with
this: they are still working, just get refreshed when a user does
"menuconfig" & "make" and result in a working coreboot build. However,
with a commit 0eab62b [3] they are rejected [see 4].

Of course I'm going to manually "refresh" the configs to temporarily
fix this problem, but I see this could increase the maintenance burden
and reduce the usefulness of coreboot config files shared online...
Are there any advantages of KCONFIG_STRICT / KCONFIG_WERROR that
outweigh these potential issues?

[1] https://review.coreboot.org/c/coreboot/+/64873
[2] https://review.coreboot.org/c/coreboot/+/64829
[3] https://review.coreboot.org/c/coreboot/+/79259
[4]

./coreboot/$ make menuconfig
src/soc/intel/meteorlake/Kconfig:457:warning: config symbol defined without type
./coreboot/.config:26:warning: unknown symbol: COMPRESS_RAMSTAGE
./coreboot/.config:230:warning: unknown symbol: ARCH_ALL_STAGES_X86
./coreboot/.config:249:warning: unknown symbol: VBT_DATA_SIZE_KB
./coreboot/.config:256:warning: unknown symbol: UART_PCI_ADDR
./coreboot/.config:264:warning: unknown symbol: S3_DATA_POS
./coreboot/.config:265:warning: unknown symbol: S3_DATA_SIZE
./coreboot/.config:274:warning: unknown symbol: LOGICAL_CPUS
./coreboot/.config:459:warning: unknown symbol: INTEL_GMA_OPREGION_2_0
./coreboot/.config:572:warning: unknown symbol: PAYLOAD_YABITS
./coreboot/.config:574:warning: unknown symbol: PAYLOAD_TIANOCORE

ERROR: 10 warnings encountered, and warnings are errors.

make: *** [build/util/kconfig/Makefile.real:47: menuconfig] Error 1
-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Restoring the opensource AGESA boards takes just 1% of git reverts since their removal

[Mike Banon]

Behold: new restore_agesa.sh delivers coreboot 4.22.01 to Lenovo G505S
- boots fine! - and to other AMD AGESA boards which I didn't have the
opportunity to test yet ;-)
https://review.coreboot.org/c/coreboot/+/76832

On Sat, Sep 2, 2023 at 3:22 PM  wrote:
>
> Merci beaucoup!
> ;-)
>  Florentin
>
> - Mail original -
> De: "Mike Banon" 
> À: "coreboot" 
> Envoyé: Samedi 2 Septembre 2023 00:03:01
> Objet: [coreboot] Re: Restoring the opensource AGESA boards takes just 1% of 
> git reverts since their removal
>
> Now coreboot 4.21 boots flawlessly on AMD Lenovo G505S ! That's how we
> get coreboot 4.21 there ;-)
> a new "restore_agesa.sh" script compatible with coreboot master -
> https://review.coreboot.org/c/coreboot/+/76832
>
> On Sat, Aug 5, 2023 at 12:23 AM Mike Banon  wrote:
> >
> > Dear friends, please take a look at this change:
> >
> > https://review.coreboot.org/c/coreboot/+/76832
> >
> > This script reverts the opensource AGESA AMD boards removal that happened
> > after 5e8e911b7caee021faff96c4e82a77a42544ea62 (0 point of history, or 0 
> > PoH)
> > - by git-reverting:
> >1) the "bad commits" (marked as "CBF" = coreboot build failure)
> >   - that either remove or break a code needed for our boards
> >2) the "unlucky commits" (marked as "GRF" = git revert failure)
> >   - that are a roadblock for git-reverting the "bad commits"
> >
> > Right now at 3bd83b27afbc840f184b652a1dd8ed539623a258 (3765 PoH), it takes
> > 38 CBF git reverts - just 1% of 3765 commits since the OSS AGESA removal! -
> > - making this removal look questionable and the idea of restoration viable.
> >
> > Btw plenty of these git reverts could be avoided if the changes to the
> > "dropped code" are allowed: i.e. instead of git reverting the four
> > patches numbered 497-500 at the script above, one could simply add a
> > single " #define SPEEDSTEP_APIC_MAGIC 0xACAC " somewhere. Therefore
> > the real number of "bad commits" (which either remove our boards or
> > break the things for us) isn't that great and the opensource AGESA
> > boards really can be brought back to coreboot with a bunch of ifdef's
> > etc. Please let me know if you're interested in such a quest...
> >
> > SUCCESSFUL TESTS for the opensource AGESA boards which I own (Lenovo G505S -
> >- fam15 laptop, ASUS A88XM-E - fam15 desktop, ASUS AM1I-A - fam16 
> > desktop) :
> > 1) only build:
> >  69ffebf5ccf123bc0b3fb28b485985af0597761d (3698 PoH) for AM1I-A,
> >  most likely boot works too but I didn't have the time to test
> > 2) build & boot:
> >  69ffebf5ccf123bc0b3fb28b485985af0597761d (3698 PoH) for G505S and 
> > A88XM-E
> >  11ba8ebbcc662ebd1dc8e14372a020eb32f26561 (3741 PoH) for G505S test only
> > --
> > Best regards, Mike Banon
> > Open Source Community Manager of 3mdeb - https://3mdeb.com/
>
>
>
> --
> Best regards, Mike Banon
> Open Source Community Manager of 3mdeb - https://3mdeb.com/
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: make menuconfig - is broken after commit 7eab8ef (Linux 6.2's kconfig) and follow-ups

[Mike Banon]

Patrick, thank you so much for such a quick & working fix, it is
really appreciated ;-)


On Sun, Nov 26, 2023 at 9:20 PM Patrick Georgi  wrote:
>
> Am 26.11.2023 um 18:15 schrieb Mike Banon:
> > /usr/bin/ld: build/util/kconfig/lxdialog/yesno.o: warning: relocation
> > against `acs_map' in read-only section `.text'
> > /usr/bin/ld: build/util/kconfig/mconf.o: in function `show_help':
> > mconf.c:(.text+0x1770): undefined reference to `stdscr'
> > /usr/bin/ld: mconf.c:(.text+0x177c): undefined reference to `stdscr'
> > /usr/bin/ld: build/util/kconfig/lxdialog/checklist.o: in function 
> > `print_item':
> > checklist.c:(.text+0x82): undefined reference to `wattrset'
> > /usr/bin/ld: checklist.c:(.text+0x98): undefined reference to `wmove'
> > /usr/bin/ld: checklist.c:(.text+0xb2): undefined reference to `waddch'
> > /usr/bin/ld: checklist.c:(.text+0xd8): undefined reference to `wmove'
> > /usr/bin/ld: checklist.c:(.text+0xfe): undefined reference to `wattrset'
>
> > Curious, if anyone else has the same error? Please take a look at this
>
> Oops! https://review.coreboot.org/c/coreboot/+/79264 fixes it for me.
>
>
> Patrick



--
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] make menuconfig - is broken after commit 7eab8ef (Linux 6.2's kconfig) and follow-ups

[Mike Banon]

Dear friends, I just encountered a menuconfig problem on a fresh
coreboot. Steps to reproduce:
1) Testing environment - fully updated Artix Linux (arch w/o systemd):
6.5.11 linux kernel etc.
2) At the freshly cloned coreboot directory (+ submodules
checkout'ed), git reset --hard 7eab8ef and then make menuconfig - will
cause these errors:

/usr/bin/ld: build/util/kconfig/lxdialog/yesno.o: warning: relocation
against `acs_map' in read-only section `.text'
/usr/bin/ld: build/util/kconfig/mconf.o: in function `show_help':
mconf.c:(.text+0x1770): undefined reference to `stdscr'
/usr/bin/ld: mconf.c:(.text+0x177c): undefined reference to `stdscr'
/usr/bin/ld: build/util/kconfig/lxdialog/checklist.o: in function `print_item':
checklist.c:(.text+0x82): undefined reference to `wattrset'
/usr/bin/ld: checklist.c:(.text+0x98): undefined reference to `wmove'
/usr/bin/ld: checklist.c:(.text+0xb2): undefined reference to `waddch'
/usr/bin/ld: checklist.c:(.text+0xd8): undefined reference to `wmove'
/usr/bin/ld: checklist.c:(.text+0xfe): undefined reference to `wattrset'

3) One commit before - 7f93aa4 - the things worked OK

Curious, if anyone else has the same error? Please take a look at this

-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Restoring the opensource AGESA boards takes just 1% of git reverts since their removal

[Mike Banon]

Now coreboot 4.21 boots flawlessly on AMD Lenovo G505S ! That's how we
get coreboot 4.21 there ;-)
a new "restore_agesa.sh" script compatible with coreboot master -
https://review.coreboot.org/c/coreboot/+/76832

On Sat, Aug 5, 2023 at 12:23 AM Mike Banon  wrote:
>
> Dear friends, please take a look at this change:
>
> https://review.coreboot.org/c/coreboot/+/76832
>
> This script reverts the opensource AGESA AMD boards removal that happened
> after 5e8e911b7caee021faff96c4e82a77a42544ea62 (0 point of history, or 0 PoH)
> - by git-reverting:
>1) the "bad commits" (marked as "CBF" = coreboot build failure)
>   - that either remove or break a code needed for our boards
>2) the "unlucky commits" (marked as "GRF" = git revert failure)
>   - that are a roadblock for git-reverting the "bad commits"
>
> Right now at 3bd83b27afbc840f184b652a1dd8ed539623a258 (3765 PoH), it takes
> 38 CBF git reverts - just 1% of 3765 commits since the OSS AGESA removal! -
> - making this removal look questionable and the idea of restoration viable.
>
> Btw plenty of these git reverts could be avoided if the changes to the
> "dropped code" are allowed: i.e. instead of git reverting the four
> patches numbered 497-500 at the script above, one could simply add a
> single " #define SPEEDSTEP_APIC_MAGIC 0xACAC " somewhere. Therefore
> the real number of "bad commits" (which either remove our boards or
> break the things for us) isn't that great and the opensource AGESA
> boards really can be brought back to coreboot with a bunch of ifdef's
> etc. Please let me know if you're interested in such a quest...
>
> SUCCESSFUL TESTS for the opensource AGESA boards which I own (Lenovo G505S -
>- fam15 laptop, ASUS A88XM-E - fam15 desktop, ASUS AM1I-A - fam16 desktop) 
> :
> 1) only build:
>  69ffebf5ccf123bc0b3fb28b485985af0597761d (3698 PoH) for AM1I-A,
>  most likely boot works too but I didn't have the time to test
> 2) build & boot:
>  69ffebf5ccf123bc0b3fb28b485985af0597761d (3698 PoH) for G505S and A88XM-E
>  11ba8ebbcc662ebd1dc8e14372a020eb32f26561 (3741 PoH) for G505S test only
> --
> Best regards, Mike Banon
> Open Source Community Manager of 3mdeb - https://3mdeb.com/



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Tree maintenance and build nodes

[Mike Banon]

I've missed this discussion but have been linked there from
https://review.coreboot.org/c/coreboot/+/76832
("util/scripts/restore_agesa.sh - restores the opensource AMD AGESA
boards").

Atm I can only volunteer with testing (and I took this "git revert"
quest above for my ~1 week spare window only because the success was
guaranteed during this limited time) - that testing help will be
available since the end of August when I'll return to my hardware. But
since the unbricking is easy & quick and I have this FT232H-based
"corelogs" adapter -
http://dangerousprototypes.com/docs/Corelogs_adapter - I will be able
to help greatly!

On Wed, May 17, 2023 at 9:42 AM Kyösti Mälkki  wrote:
>
> On Wed, Apr 26, 2023 at 3:58 PM Peter Stuge  wrote:
> >
> > Kyösti Mälkki wrote:
> > > Is there someone (corporate) currently funding or hiring personnel
> > > with reviews and tree maintenance as a priority? Is there currently
> > > anyone actually assigning from their existing resources to put
> > > attention to frameworks, while customers' board ports and resolving
> > > their issues have tight schedules?
> >
> > This is an important question, thank you for that Kyösti.
> >
> > I suspect that the answer will be largely no and that's not very
> > sustainable for maintainability even in the medium term. :\
> >
>
> I guess the answer is largely no, with no response from 4 of the 5
> major players in the field. One of the past contributors said he tried
> to squeeze in tree maintenance work and improving subsystems in
> between the active projects. But that time slot quickly became a
> non-existing one with the increased rate of SoC generations and their
> FSP's appearing.
>
> Kyösti
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Restoring the opensource AGESA boards takes just 1% of git reverts since their removal

[Mike Banon]

Dear friends, please take a look at this change:

https://review.coreboot.org/c/coreboot/+/76832

This script reverts the opensource AGESA AMD boards removal that happened
after 5e8e911b7caee021faff96c4e82a77a42544ea62 (0 point of history, or 0 PoH)
- by git-reverting:
   1) the "bad commits" (marked as "CBF" = coreboot build failure)
  - that either remove or break a code needed for our boards
   2) the "unlucky commits" (marked as "GRF" = git revert failure)
  - that are a roadblock for git-reverting the "bad commits"

Right now at 3bd83b27afbc840f184b652a1dd8ed539623a258 (3765 PoH), it takes
38 CBF git reverts - just 1% of 3765 commits since the OSS AGESA removal! -
- making this removal look questionable and the idea of restoration viable.

Btw plenty of these git reverts could be avoided if the changes to the
"dropped code" are allowed: i.e. instead of git reverting the four
patches numbered 497-500 at the script above, one could simply add a
single " #define SPEEDSTEP_APIC_MAGIC 0xACAC " somewhere. Therefore
the real number of "bad commits" (which either remove our boards or
break the things for us) isn't that great and the opensource AGESA
boards really can be brought back to coreboot with a bunch of ifdef's
etc. Please let me know if you're interested in such a quest...

SUCCESSFUL TESTS for the opensource AGESA boards which I own (Lenovo G505S -
   - fam15 laptop, ASUS A88XM-E - fam15 desktop, ASUS AM1I-A - fam16 desktop) :
1) only build:
 69ffebf5ccf123bc0b3fb28b485985af0597761d (3698 PoH) for AM1I-A,
 most likely boot works too but I didn't have the time to test
2) build & boot:
 69ffebf5ccf123bc0b3fb28b485985af0597761d (3698 PoH) for G505S and A88XM-E
 11ba8ebbcc662ebd1dc8e14372a020eb32f26561 (3741 PoH) for G505S test only
-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] CPU with a faulty RAM controller? o_O AGESA debug info inside

[Mike Banon]

Faulty CPUs are truly rare... But recently while building the A88XM-E
coreboot test stand (more info at [1] "ProTip: buy a 5.25" fan
controller while you still can" link below) ---> I got a used A10-6700
online for a dirt cheap price: the listing looked nice - a clear photo
without any bent pins - but there was an intriguing note "one RAM slot
doesn't work". So I thought:

> That looks like a motherboard problem! Or something related to the seller's 
> RAM sticks: either a faulty stick or a badly mismatching pair. Shouldn't 
> happen on my spare well-tested A88XM-E with a known good RAM, especially with 
> a beautiful coreboot replacing the crappy proprietary UEFI, so lets save a 
> few bucks "

However, I ran into the same problem: the board boots fine to OS but
sees just one of two BLT8G3D1869DT1TX0 8GB RAM sticks, regardless if I
use the XMP profile to run them at 1866MHz CL9 (
CPU_AMD_AGESA_OPENSOURCE_MEM_XMP_1 stuff which I created two years ago
- [2] ) or keep them at turtle 1333Mhz CL9. Here are the most
interesting AGESA events which happen while trying to initialize the
RAM:

*) WARNING Event: 04012100 Data: 0, 0, 0, 0 [0m ; AGESA.h tells:
#define MEM_WARNING_CHANNEL_INTERLEAVING_NOT_ENABLED 0x04012100ul ///<
Channel Interleaveing Requested, but could not be enabled

*) WARNING Event: 04012200 Data: 0, 0, 0, 0 [0m ; AGESA.h tells:
#define MEM_WARNING_BANK_INTERLEAVING_NOT_ENABLED 0x04012200ul ///<
Bank Interleaveing Requested, but could not be enabled

*) ERROR Event: 04010300 Data: 0, 0, 0, 0 [0m ; AGESA.h tells:
#define MEM_ERROR_NO_DQS_POS_RD_WINDOW 0x04010300ul ///< No DQS
Position window for RD DQS

See the full AGESA log here - https://pastebin.com/FLWFk9SF . Please
keep in mind that, if I replace this with another (bought later)
A10-6700 - using the same A88XM-E / RAM / coreboot / OS - then
everything works fine. So it's clearly a CPU problem, but may be
possible to avoid from the firmware side...

Do you think it's possible to workaround this problem (no matter how
dirty the hack) from AGESA side and get this CPU working with both
sticks? Is there anything I could try before giving up and making a
DIY keychain or whatever? Any ideas?

[1] 
https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/message/RDMSYKLAYZOSUXOMCZSXVGGQAOYQEV5A/
- " ProTip: buy a 5.25" fan controller while you still can "
[2] https://review.coreboot.org/c/coreboot/+/40488 -
vc/amd/agesa/f.../Proc/Mem/Tech/DDR3: Support XMP memory profiles
--
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
[SPEW ]  AmdInitEarly: End

[INFO ]  Timestamp - back from AmdInitEarly: 7808722251
[DEBUG]  AmdInitEarly() returned AGESA_SUCCESS
[DEBUG]  APIC 00: Heap in LocalCache (2) at 0x0040
[DEBUG]  APIC 00: ** Exit  AmdInitEarly [00020002]
[INFO ]  Timestamp - before RAM initialization: 7892186693

[DEBUG]  APIC 00: ** Enter AmdInitPost [00020006]
[INFO ]  Timestamp - calling AmdInitPost: 7939035677
[SPEW ]  AmdInitPost: Start


[SPEW ]   * BOUNDS_CHK Event: 08040100 Data: a00a, 0, 0, 0


[SPEW ]   * BOUNDS_CHK Event: 08040100 Data: a00a, 0, 0, 0


[SPEW ]   * BOUNDS_CHK Event: 08040100 Data: a00a, 0, 0, 0


[SPEW ]   * BOUNDS_CHK Event: 08040100 Data: a00a, 0, 0, 0


[SPEW ]   * BOUNDS_CHK Event: 08040100 Data: a00a, 0, 0, 0


[SPEW ]   * BOUNDS_CHK Event: 08040100 Data: a00a, 0, 0, 0


[SPEW ]   * BOUNDS_CHK Event: 08040100 Data: a00a, 0, 0, 0


[SPEW ]   * BOUNDS_CHK Event: 08040100 Data: a00a, 0, 0, 0

[SPEW ]  AmdMemAuto: Start
[SPEW ]F15TnGetPstateFrequency - P3
[SPEW ]  FrequencyInMHz=3700, CpuFid=21, CpuDid=0
[SPEW ]  -READING SPD---
[SPEW ]  iobase: 0x0B00, SmbusSlave: 0x00A0, count: 256

[SPEW ]  -FINISHED READING SPD---
[SPEW ]  -READING SPD---
[SPEW ]  iobase: 0x0B00, SmbusSlave: 0x00A2, count: 256

[SPEW ]  -FINISHED READING SPD---

[SPEW ]   * BOUNDS_CHK Event: 08040100 Data: 1247000, 0, 0, 0

[SPEW ]F15TnGetNbPstateInfo - NB P3
[SPEW ]F15TnGetNbPstateInfo - NB P2
[SPEW ]F15TnGetNbPstateInfo - NB P1
[SPEW ]F15TnGetNbPstateInfo - NB P0
[SPEW ]  En:1 Fid:c Did:0 Vid:3e
[SPEW ]F15TnGetNbFreqNumeratorInMHz - NbFid=12
[SPEW ]  FreqNumeratorInMHz=1600
[SPEW ]F15TnGetNbFreqDivisor - NbDid=0
[SPEW ]  FreqDivisor=1
[SPEW ]F15TnCovertVidInuV
[SPEW ]  Vid=3e, VoltageInuV=1162500
[SPEW ]  NB Pstate 0 is Valid. NbVid=62 VoltageInuV=1162500
[SPEW ]F15TnGetNbPstateIn

[coreboot] Can't write new comments under "payloads/cbui: Add new payload CBUI" change

[Mike Banon]

Good day! So, I found this Gerrit change:

https://review.coreboot.org/c/coreboot/+/23586 - payloads/cbui: Add
new payload CBUI

Wanted to reply " Not tested yet, but looks like a nice idea " but got this:

Error 400 (Bad Request): One or more comments were rejected in
validation: Exceeding maximum number of comments: 5139 (existing) + 2
(new) > 5000

This issue might be blocking the further work on this change (and I
don't see why there should be any limit at all)

-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] DUG #2 + vPub v7 opensource online Party! - 6th July at 4 PM UTC

[Mike Banon]

Dear friends, I invite you to a joint DUG #2 + vPub v7 event that will
start this Thursday at 4PM UTC. Would you like to learn more about:

* the opensource firmware world and its current events, i.e. the
recent opensource firmware developments *(OpenSIL)* for new AMD PCs?
* interesting open hardware devices like Nitrokey opensource security tokens?

Then this upcoming event - is an excellent opportunity for you to have
a great time in the company of fellow firmware enthusiasts.

The 1st part of our event - DUG #2 - is dedicated to Dasharo
distribution of coreboot opensource firmware with advanced features
like GUI & FLASHBIOS and the ecosystem around it. DUG will take place
between 4-6 PM UTC - and then around 6 PM UTC will switch to vPub. The
past events have been highly successful, and I'm sure you will find
this time interesting as well ;-) Both sound/video and text chats will
be available for your convenience

More details and Join links are available here -
https://vpub.dasharo.com/e/7/dasharo-user-group-2

-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: I need you help.

[Mike Banon]

There is a batch of black CH341A s which are giving 5V instead of 3.3V
- which is dangerous for flashing - so please try to get a green
CH341A. There are plenty of them available from AliExpress / China.
And about the test clips, you can find a small review of different
test clips here
http://dangerousprototypes.com/docs/Flashing_a_BIOS_chip_with_Bus_Pirate
(double check that your BIOS chip is SOIC8 shape, otherwise that will
be useless for you). The build is not difficult, there are plenty of
manuals available online + a helpful community as you see ;-)

On Tue, Mar 14, 2023 at 2:41 PM  wrote:
>
> Thank you for reply.
>
> I found CH341A and SOIC8.
> But CH341A is not green. It is black edition.
> Doesn't it work?
>
> And build is not difficult?
>
> On Tue, March 14, 2023 10:14 am, Mike Banon wrote:
> > Usually, to flash a coreboot to a coreboot-supported laptop, you need
> > to build a coreboot.rom firmware image for this laptop's model - and then,
> > use the flashrom-supported programmer (i.e. a green PCB CH341A to simplify
> > the process and reduce the costs - it's much much cheaper and simpler than
> > RPi) together with a test clip which is compatible
> > with the laptop's BIOS chip shape (i.e. SOIC8). More helpful instructions
> > could be found online for your specific model; x230 is popular enough and
> > there are a lot of guides
> >
> > On Tue, Mar 7, 2023 at 9:58 PM email--- via coreboot
> >  wrote:
> >
> >>
> >> Hello.
> >>
> >>
> >> I would like to install Coreboot on my Lenovo x230, but I don't know
> >> how to do that. Please tell me how to do it. I have done a lot of
> >> research on my own, but I just can't figure it out. I am not a computer
> >> educated person.
> >>
> >> I don't have a rasberry pie. Do I need it?
> >>
> >>
> >> And what are skulls and heads, and what is the difference between them
> >> and coreboot?
> >>
> >>
> >>
> >> ___
> >> coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an
> >> email to coreboot-le...@coreboot.org
> >
> >
> >
> > --
> > Best regards, Mike Banon
> > Open Source Community Manager of 3mdeb - https://3mdeb.com/
> >
> >
>
>


-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: I need you help.

[Mike Banon]

Usually, to flash a coreboot to a coreboot-supported laptop, you need
to build a coreboot.rom firmware image for this laptop's model - and
then, use the flashrom-supported programmer (i.e. a green PCB CH341A
to simplify the process and reduce the costs - it's much much cheaper
and simpler than RPi) together with a test clip which is compatible
with the laptop's BIOS chip shape (i.e. SOIC8). More helpful
instructions could be found online for your specific model; x230 is
popular enough and there are a lot of guides

On Tue, Mar 7, 2023 at 9:58 PM email--- via coreboot
 wrote:
>
> Hello.
>
> I would like to install Coreboot on my Lenovo x230, but I don't know how
> to do that. Please tell me how to do it.
> I have done a lot of research on my own, but I just can't figure it out.
> I am not a computer educated person.
>
> I don't have a rasberry pie. Do I need it?
>
> And what are skulls and heads, and what is the difference between them and
> coreboot?
>
>
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] ProTip: buy a 5.25" fan controller while you still can

[Mike Banon]

Dear friends,

Unfortunately the 5.25" DVD/BluRay drives are less popular nowadays
and many companies stopped making the PC cases with 5.25" slots - to
make room for some stupid RGB lighting? - not realizing that a lot of
people have been using these 5.25" slots for alternative purposes! In
example, to host 1) a hot swap dual HDD bay with a built-in RAID
controller; or 2) a fan controller - with either a sensor LCD screen
or the rotary knobs to control the fan speeds of each channel and even
monitor the temperatures of its own thermal sensors.

As a result of reduced "with-5.25"" PC cases availability, many 5.25"
fan controllers have been discontinued already - in favor of those
"soulless" black boxes without any physical controls, that usually can
be controlled only with some Windows crapware. Yes, for some of them
(i.e. "Corsair Commander Pro") Linux support has been
reverse-engineered - however it's not always as refined &
feature-complete, obviously still doesn't work in the alternative OSes
like Kolibri, occupies an extra USB port for control data exchange,
and anyways - having to use a console to adjust the fans is a huge
extra hassle compared to an instant physical access.

So, especially considering that a coreboot+SeaBIOS do not provide a
built-in GUI for the fan speeds setup (+ even if existed, you'd need
to reboot your PC to access it) - a 5.25" fan controller is really a
must have! And, considering that the Chinese ALSEYE/STW controllers
from AliExpress seem to have a higher failure rate (IMHO based on
reviews) - it may be a good idea to get the more reliable branded ones
while their supplies last. One thing to consider: if it has to be a
VFD display, the VFDs have a longer lifespan if they are green -
https://en.wikipedia.org/wiki/Vacuum_fluorescent_display

Please share your opinion about the fan controllers. Maybe you are
already using one?

Myself, I'm happy with 'GELID SpeedTouch 6 FC-LC-01' (6 channels &
sensor display) in HAF XB EVO case - which simultaneously hosts two
AMD no-PSP coreboot motherboards - A88XM-E and AM1I-A - thanks to some
modding. Old photos here -
https://www.reddit.com/r/coreboot/comments/jn8is5/corebooted_2in1_amd_pc_asus_a88xme_a106700_am1ia/
- since that the construction has been improved thanks to a
Silverstone Nitrogon NT06-PRO, an unique horizontal cooler which
allows to place a fan beneath the heatsink, making it much easier to
use its heatsink as a support structure for a "second floor" with
AM1I-A.

Also, I was lucky enough to get 'Akasa FC.Trio' (3 channels & LCD &
rotary knobs) for my new Chieftec Pro Cube CI-02B-OP mATX case - which
I got to build the A88XM-E coreboot test stand with an instant access
to a BIOS chip. Btw this CI-02B-OP case is still widely available, has
a horizontal motherboard placement (so less stress from a heavy RX590
- the last AMD GPU without a built-in PSP), both 5.25" and 3.5" bays
(I used a 3.5" bay for two 2.5" HDDs with a hot swap), and an unique
fold-open construction for a super convenient access to the internals.
The only downside which I've encountered - is a bit tight cable
routing of a large PSU; but, if your PSU has the detachable cables
(which could be connected one-by-one after the PSU installation), this
is much easier to manage.

Please share your experiences ;-)
-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Toolchain build on Ubuntu 22.04 fails (at GCC 8.3.0)?

[Mike Banon]

Hi there Rafael,

Please tell me, what is a platform for which you are going to build a
coreboot? Seeing that you have downgraded your toolchain's GCC version
to 8.3.0, like I'm suggesting in this manual -
http://dangerousprototypes.com/docs/Lenovo_G505S_hacking - I suspect
that your platform is the "opensource AMD AGESA" one, i.e. Lenovo
G505S (or ASUS A88XM-E or ASUS AM1I-A). If that's really true, then
you don't need the gcc-ada at all, and it is preferable that you
remove a gcc-ada from your OS at all before trying to build a coreboot
8.3.0 toolchain to avoid the possible errors (so that the toolchain
gets built without Ada).

On Sat, Jan 7, 2023 at 2:51 AM Rafael Send  wrote:
>
> Hi,
> I'm trying to "make crossgcc" for coreboot, but it fails at building GCC 
> 8.3.0. As far as I can tell, coreboot uses (this) specific version to make 
> sure things work right, but I'm not sure why this is going wrong.
>
> The system gnat version is 10.4.0, but I did read somewhere that the Ada 
> version should match the gcc one. Does that mean gnat-8 is required? That's 
> not a thing that I can find.
>
> I've attached the suggested build.log file, can anyone suggest how to resolve 
> this issue?
>
> Thanks,
> Rafael
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Compatibility with legacy boards

[Mike Banon]

Seeing the success of running a P2B coreboot build on a P2B-B board
(another legacy board), there could be a chance ;-)

On Thu, Aug 11, 2022 at 8:47 PM Petr Cvek  wrote:
>
> Hi,
>
> The p5gc-mx is still supported (src/mainboard/asus/p5gc-mx in a git snapshot).
>
> It seems the mainboard consists of i945GC northbridge and ICH7 southbridge 
> (82801GX).
> Both are supported, in a fact I'm using a board with i945GM+ICH7 which is 
> almost the same.
>
> However there may be some outdated things. My board had incomplete devicetree 
> and chipset
> initialization had a weird problem with cache preload few weeks ago. But it 
> should be
> still possible to boot a linux system (or at least to report bugs ;-) ).
>
> If you are planning to test it, make sure you will be able to flash back the 
> original
> bios, or even better flash coreboot into a separate chip so you can hot swap 
> it.
>
> Having an RS232 adapter to see the logs is also extremely useful.
>
> ad boot: Coreboot only initialize the hardware and starts the payload. The 
> boot itself
> is made by one of the payloads, for example seabios. And yes seabios supports 
> booting
> from USB OHCI/EHCI/XHCI controller.
>
> Petr
>
> Dne 11. 08. 22 v 16:44 Benoît Dufour napsal(a):
> > Hello,
> > I saw one of my old board is listed compatible on the CoreBoot wiki :
> > https://www.coreboot.org/Board:asus/p5gc-mx
> > but knowing the wiki is "being retired".
> > I don't know if it is still supported by the latest version of CoreBoot.
> >
> > Then the Status (as of commit 5bb27b7815) chart has broken colors.
> > So it is hard to me to tell if everything is working fine or not.
> >
> > Then my board is the P5GC-MX/1333 and not the P5GC-MX.
> > I could attempt to flash the Coreboot BIOS to it, but
> > I would want to know if it could bring me some advantages other than
> > "it is free software". For example, the original manufacturer BIOS
> > doesn't supports booting from USB, does CoreBoot supports it?
> > ___
> > coreboot mailing list -- coreboot@coreboot.org
> > To unsubscribe send an email to coreboot-le...@coreboot.org
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Coreboot and open firmware RX590 efforts?

[Mike Banon]

Hi there Nico,

Thank you for your great summary of research, I'm going to CC it to a
coreboot mailing list just in case someone wants to add more
findings...

I'm not aware of any people currently working on the OpenAtom project,
or of any advances since the last activity long ago. Perhaps it's
because 1) AtomDis utility output already gives quite a good idea of
what functions/data are inside the AtomBIOS blob to get enough
confidence there are no backdoors, and 2) if I remember correctly
OpenAtom didn't promise any improvements of user experience (extra
features etc.), + the overclocking/underclocking is already achievable
by modding the AtomBIOS binary (just need to be careful around the
voltages). So, the people would be interested in OpenAtom mostly for
software freedom reasons (aka "FSF guys"), but probably it's not
enough as we see.

> Would you still recommend RX590 as being the best graphics card suitable for 
> open firmware development?

It'd be wonderful from the tech specs point of view - but the
development won't be easiest, seeing that AtomDis utility gives a
larger % of meaningful output for i.e. HD-8650G / HD-8570M / R5-M230
AtomBIOS blobs of coreboot-supported Lenovo G505S. Last commit to
AtomDis was in 2011, it hasn't been updated since that and therefore
starts having some trouble deciphering the newer AtomBIOSes (such as
RX590).

Although having an open firmware for a prominent RX590 would be a nice
end goal, it would be wiser to start with the G505S blobs, especially
since it seems the OpenAtom project has already been digging for the
HD-8650G of G505S. What is also good: while developing for G505S it
would be easier to try the custom ROMs: using a cbfstool utility from
a coreboot repository, simply remove the old AtomBIOS blob from your
coreboot.rom and add a new one (may even make a custom script, looking
at csb_patcher.sh -
http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#Introduction
), then flash the updated coreboot.rom into your G505S using a
flashrom's internal mode. If you don't see any image on a screen (in
case of a bad AtomBIOS), somehow boot to Linux (need to remember a
SeaBIOS drive letter) and connect to G505S from another PC using SSH
to try a coreboot.rom with another AtomBIOS blob.

> One option I was considering is to extract the ROM and add it to cbfs so I 
> wouldn't need SeaBIOS.

Without the AtomBIOS blob I think your GPU won't work at all, no
matter what your payload selection is.

If you have any other questions, we will be happy to help you.

On Sun, Jul 17, 2022 at 4:25 PM Nico Rikken  wrote:
>
> Hi Mike,
>
> Sorry for circumventing the Coreboot mailinglist, but it seems you have 
> posted most recently on this subject. Happy to go via the mailinglist, but I 
> didn't know what to write in a general way.
>
> I'm building a new computer based on the P8Z77-V. I'm considering adding a 
> dedicated graphics card to drive larger display resolutions and have more GPU 
> power for photo editing. I investgated what the current state of openness is. 
> I also posted on Reddit: 
> https://www.reddit.com/r/coreboot/comments/w080ng/requirements_for_adding_rx_590_graphics_card/
>
> I read the history on this subject including your comments over the years:
> - RX590 being the best before AMD PSP introduction
> https://www.mail-archive.com/coreboot@coreboot.org/msg54703.html
> - Lack of PSP is required to enable open source firmware like openAtom 
> https://www.reddit.com/r/Amd/comments/ex04ld/do_the_latest_amd_cards_include_psp_as_well/
> - There is/was some effort to open up Radeon cards with OpenAtom, also 
> mentioned in 
> https://www.reddit.com/r/Amd/comments/ex04ld/do_the_latest_amd_cards_include_psp_as_well/
> - There was an interest to work on it for the GSoC 2015 
> https://www.mail-archive.com/coreboot@coreboot.org/msg44492.html
>
> It seems all current efforts to further open AMD GPU firmware have stalled.
>
> One option I was considering is to extract the ROM and add it to cbfs so I 
> wouldn't need SeaBIOS. The again I saw your post about the trouble of dealing 
> with extracting certain ROMs: 
> https://www.mail-archive.com/coreboot@coreboot.org/msg49637.html But I think 
> that won't be so much of an issue in this case.
>
> So to summize my question: where do we stand with open GPU firmware on X86? 
> Would you still recommend RX590 as being the best graphics card suitable for 
> open firmware development? Are there still people working on this?
>
> Best,
> Nico

-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: I may have misconfigured my Coreboot ROM, what did I do wrong?

[Mike Banon]

Hi there Tristan, One of the ideas could be taking a config from some
successful board-status coreboot report available online, and diff'ing
it against your own config i.e. using the meld/kdiff3 utilities.


On Sat, Jun 25, 2022 at 4:26 PM Peter Stuge  wrote:
>
> Hi Tristan,
>
> Tristan Young wrote:
> > fixed it by flashing my previous Coreboot BIOS
>
> Great job - well done!
>
>
> > Should I send my .config file so that you can tell if any of the config
> > settings or combinations of them that I chose wouldn't work on my specific
> > model of ThinkPad?
>
> You can send the config but don't expect that someone else will
> analyze your problem.
>
> Ideally, please instead investigate this yourself and share your
> findings (also along the way if you like) - if you can arrive at a
> clear conclusion then there is at least some possibility that someone
> else improves the code in case that makes sense.
>
>
> Kind regards
>
> //Peter
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



--
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] QEMU x86 i440fx/piix4 build fails for >= 32MB ROMs - Assertion IS_HOST_SPACE_ADDRESS(host_space_address) failed

[Mike Banon]

If I use a default config for i440fx/piix4, building a 16MB ROM works
fine, but 32MB or 64MB doesn't work anymore:

...
CC postcar/southbridge/intel/common/rtc.o
LINK   cbfs/fallback/postcar.debug
OBJCOPYcbfs/fallback/romstage.elf
CREATE build/mainboard/emulation/qemu-i440fx/cbfs-file.vqaXlP.out
(from /home/my_custom_path_to/coreboot/.config)
CC+STRIP   src/lib/cbfs_master_header.c
OBJCOPYcbfs/fallback/bootblock.elf
OBJCOPYbootblock.raw.elf
OBJCOPYbootblock.raw.bin
Created CBFS (capacity = 33553892 bytes)
BOOTBLOCK
CBFS   cbfs_master_header
CBFS   fallback/romstage
cbfstool: /home/my_custom_path_to/coreboot/util/cbfstool/cbfstool.c:1145:
cbfstool_convert_mkstage: Assertion
`IS_HOST_SPACE_ADDRESS(host_space_address)' failed.
make: *** [Makefile.inc:1116: build/coreboot.pre] Aborted

-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] "vPub v5" opensource online Party! - this Thursday at 4 PM UTC

[Mike Banon]

Dear friends, I'm happy to tell you about the upcoming "vPub v5"
online party which starts this Thursday (26 May) at 4 PM UTC. Here's a
homepage of our online party - https://vpub.dasharo.com/

Aside from having fun, we'd like to discuss and learn more about the
wonderful open-source projects from the embedded world of firmware &
hardware - and their advantages of liberty, security and quality. Some
examples of the possible topics:

*) new opensource coreboot BIOS port for a fresh retail Intel Alder
Lake MSI PRO Z690-A WiFi DDR4 motherboard & its' testing results by
QubesOS users. This port has been done by our 3mdeb company and is
quite a spectacular accomplishment - because it's for a new
motherboard still widely available as new! (usually by the time an
opensource firmware is ported to some motherboard, it's long gone from
the market and the people have to search for the old used ones);
*) RustSBI - a software supervisor for RISC-V written on Rust
programming language;
*) qspimux - a hardware adapter for the safe remote flashing of SPI
flash chip (used for storing the firmwares) without detaching it from
a target motherboard;
*) lnDSO150 - an alternative firmware for the popular handheld DSO
oscilloscopes;
*) bcm5719-fw - an alternative firmware for the network card Broadcom BCM5719;
*) swtpm - a software Trusted Platform Module emulator and the ways of using it;
*) TrenchBoot - a framework which uses multiple projects to improve
the security of firmware booting.

Thank you for a wonderful time with us at our past parties and your
kind feedback! We hope that this one will be as exciting as the
previous ones (which lasted for 10-12 hours) - and will be waiting for
you. Expect a great time in a cosy community of opensource enthusiasts
from all over the world! ;-)
-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: No instructions for the Biostar AM1ML?

[Mike Banon]

y trial and error. Although
the sophisticated OS like Linux works fine even with the "bad irq
routing" (unless it is seriously messed up, in which case it will
freeze while booting), the floppy-based hobby OS like KolibriOS may
have a trouble accessing some peripheral devices (i.e. network card)
if you don't fix your IRQs. So, if you'd have some free time after
successfully coreboot'ing your board, you may try improving your IRQs.
And, if you do some unofficial patches (good IRQs, AtomBIOS ROM,
custom config, etc) after a review I may include them to my collection
above, for everyone's benefit and a speedy future coreboot builds for
AM1ML.

With the latest version of a proprietary UEFI is installed, run these
tools (getpir / mptable)
(https://review.coreboot.org/c/coreboot/+/48322) - their output is
partially wrong, but for a starting point it's better than nothing.
Then you copy-paste the "AMD good IRQs" code for i.e. AM1I-A which is
fam16h platform like your board (although I spent more time on G505S
fam15h so it could be higher quality) - and try to adjust it for your
board by trial and error.

> When do I know when I've got it right?

When a Linux is still able to boot fine (it freezes while booting if
seriously messed up), and KolibriOS correctly assigns the IRQs to your
PCI devices (you can check it in KolibriOS GUI utility available at
Control Panel) : so as result i.e. your network card is accessible to
Kolibri and you could browse the Internet or use IRCC for online
chatting (provided that an Ethernet driver is available for your
controller). Being able to do this - was my primary reason for
creating the "good IRQ" patches.

Hope this helps, if any questions I'll be glad to help you further ;-)

On Thu, Apr 21, 2022 at 12:56 PM Nicholas C. L. Ipsen via coreboot
 wrote:
>
> Hi everyone,
>
> I recently managed to find a Biostar AM1ML, primarily purchasing it because I 
> thought it would be a good board for a router with coreboot to make it 100% 
> open source. However, even though the board is listed as supported, I can 
> find no flashing instructions anywhere.
>
> Does anyone on this mailing list have experience flashing this board? I don't 
> need anyone to hold my hand, but I would appreciate knowing what flashing 
> method works, at least. Would hate to fry the chip.
>
>
> --
> Nicholas C. L. Ipsen
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



--
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] review.coreboot.org 's wget is working unreliable today

[Mike Banon]

Downloading the patches by wget from review.coreboot.org - really
often results in these errors today. my Internet connection is OK and
I'm able to load review.coreboot.org at the same time with a browser.

--2022-04-17 **:**:**--
https://review.coreboot.org/changes/58748/revisions/1/patch?zip
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving review.coreboot.org (review.coreboot.org)... 78.46.105.101,
2a01:4f8:121:1254::2
Connecting to review.coreboot.org
(review.coreboot.org)|78.46.105.101|:443... failed: Connection timed
out.
Connecting to review.coreboot.org
(review.coreboot.org)|2a01:4f8:121:1254::2|:443... failed: Network is
unreachable.

WARNING: can't download a ./patch?zip file !
 Please check your Internet connection and try again.

press [ENTER] to continue...

-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: vPub v4 opensource online Party! - 17 February at 8 PM UTC

[Mike Banon]

Just a friendly reminder that our vPub event is going on right now ;-)
Join the fun at https://vpub.dasharo.com/

On Sun, Feb 13, 2022 at 11:32 PM Mike Banon  wrote:
>
> Dear friends,
>
> on 17 February at 8 PM UTC we are having a Dasharo OSF vPub Winter
> 2022 opensource online party! There, we'll be discussing the
> opensource firm/hard-wares in a cosy community of enthusiasts from all
> over the world. And you are welcome to join us: for example, you may
> learn about some unusual hardware that supports an open-source
> firmware and could be a perfect fit for your collection. :-)
>
> Here's a homepage of our party - https://vpub.dasharo.com/ . Although
> a significant part of the event will be in a free-for-all format with
> its' exciting random flow of topics, there are some particular ones
> that we would like to observe: i.e. "Crowdfunding of open source
> firmware distribution for modern platforms". And you can suggest your
> ideas - and have your moment of fame by giving a demo/presentation of
> your project: please write to us at vPub Matrix room [2] to designate
> a special time for you.
>
> In any case, we will be honoured to see you among us for a great time
> together ;-)
>
> [1] https://vpub.dasharo.com/
> [2] https://matrix.to/#/#dasharo-osf-vpub:matrix.org
> --
> Best regards, Mike Banon
> Open Source Community Manager of 3mdeb - https://3mdeb.com/



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] vPub v4 opensource online Party! - 17 February at 8 PM UTC

[Mike Banon]

Dear friends,

on 17 February at 8 PM UTC we are having a Dasharo OSF vPub Winter
2022 opensource online party! There, we'll be discussing the
opensource firm/hard-wares in a cosy community of enthusiasts from all
over the world. And you are welcome to join us: for example, you may
learn about some unusual hardware that supports an open-source
firmware and could be a perfect fit for your collection. :-)

Here's a homepage of our party - https://vpub.dasharo.com/ . Although
a significant part of the event will be in a free-for-all format with
its' exciting random flow of topics, there are some particular ones
that we would like to observe: i.e. "Crowdfunding of open source
firmware distribution for modern platforms". And you can suggest your
ideas - and have your moment of fame by giving a demo/presentation of
your project: please write to us at vPub Matrix room [2] to designate
a special time for you.

In any case, we will be honoured to see you among us for a great time
together ;-)

[1] https://vpub.dasharo.com/
[2] https://matrix.to/#/#dasharo-osf-vpub:matrix.org
-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Fwd: T440P

[Mike Banon]

-- Forwarded message -
From: Patrick Bratu 
Date: Thu, Feb 10, 2022 at 1:56 PM
Subject: Re: [coreboot] T440P
To: Mike Banon 



Hello Mr. Banon


here is my config


thankyou very much

Best regards


Am 29.01.22 um 16:09 schrieb Mike Banon:
> Please share your coreboot .config , describe the errors and give us
> more info to help you
>
> On Tue, Jan 25, 2022 at 2:51 PM Patrick Bratu  wrote:
>> Hello dear team of Coreboot I tried to install CoreBoot with SeaBios on
>> my T440p with dGPU but I can not get the graphics card to show up and
>> when installing Arch also always come errors can you help me please?
>>
>> Best Regards
>>
>> ___
>> coreboot mailing list -- coreboot@coreboot.org
>> To unsubscribe send an email to coreboot-le...@coreboot.org
>
>


-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
#
# Automatically generated file; DO NOT EDIT.
# coreboot configuration
#

#
# General setup
#
CONFIG_COREBOOT_BUILD=y
CONFIG_LOCALVERSION=""
CONFIG_CBFS_PREFIX="fallback"
CONFIG_COMPILER_GCC=y
# CONFIG_COMPILER_LLVM_CLANG is not set
# CONFIG_ANY_TOOLCHAIN is not set
# CONFIG_CCACHE is not set
# CONFIG_FMD_GENPARSER is not set
# CONFIG_UTIL_GENPARSER is not set
# CONFIG_OPTION_BACKEND_NONE is not set
CONFIG_USE_OPTION_TABLE=y
# CONFIG_STATIC_OPTION_TABLE is not set
CONFIG_COMPRESS_RAMSTAGE=y
CONFIG_INCLUDE_CONFIG_FILE=y
CONFIG_COLLECT_TIMESTAMPS=y
CONFIG_TIMESTAMPS_ON_CONSOLE=y
CONFIG_USE_BLOBS=y
# CONFIG_USE_AMD_BLOBS is not set
# CONFIG_USE_QC_BLOBS is not set
# CONFIG_COVERAGE is not set
# CONFIG_UBSAN is not set
CONFIG_HAVE_ASAN_IN_ROMSTAGE=y
CONFIG_HAVE_ASAN_IN_RAMSTAGE=y
# CONFIG_ASAN is not set
# CONFIG_NO_STAGE_CACHE is not set
CONFIG_TSEG_STAGE_CACHE=y
# CONFIG_UPDATE_IMAGE is not set
# CONFIG_BOOTSPLASH_IMAGE is not set
# CONFIG_FW_CONFIG is not set
# end of General setup

#
# Mainboard
#

#
# Important: Run 'make distclean' before switching boards
#
# CONFIG_VENDOR_51NB is not set
# CONFIG_VENDOR_ACER is not set
# CONFIG_VENDOR_ADLINK is not set
# CONFIG_VENDOR_AMD is not set
# CONFIG_VENDOR_AOPEN is not set
# CONFIG_VENDOR_APPLE is not set
# CONFIG_VENDOR_ASROCK is not set
# CONFIG_VENDOR_ASUS is not set
# CONFIG_VENDOR_BAP is not set
# CONFIG_VENDOR_BIOSTAR is not set
# CONFIG_VENDOR_BOSTENTECH is not set
# CONFIG_VENDOR_CAVIUM is not set
# CONFIG_VENDOR_CLEVO is not set
# CONFIG_VENDOR_COMPULAB is not set
# CONFIG_VENDOR_DELL is not set
# CONFIG_VENDOR_ELMEX is not set
# CONFIG_VENDOR_EMULATION is not set
# CONFIG_VENDOR_EXAMPLE is not set
# CONFIG_VENDOR_FACEBOOK is not set
# CONFIG_VENDOR_FOXCONN is not set
# CONFIG_VENDOR_GETAC is not set
# CONFIG_VENDOR_GIGABYTE is not set
# CONFIG_VENDOR_GIZMOSPHERE is not set
# CONFIG_VENDOR_GOOGLE is not set
# CONFIG_VENDOR_HP is not set
# CONFIG_VENDOR_IBASE is not set
# CONFIG_VENDOR_INTEL is not set
# CONFIG_VENDOR_JETWAY is not set
# CONFIG_VENDOR_KONTRON is not set
CONFIG_VENDOR_LENOVO=y
# CONFIG_VENDOR_LIBRETREND is not set
# CONFIG_VENDOR_LIPPERT is not set
# CONFIG_VENDOR_MSI is not set
# CONFIG_VENDOR_OCP is not set
# CONFIG_VENDOR_OPENCELLULAR is not set
# CONFIG_VENDOR_PACKARDBELL is not set
# CONFIG_VENDOR_PCENGINES is not set
# CONFIG_VENDOR_PINE64 is not set
# CONFIG_VENDOR_PORTWELL is not set
# CONFIG_VENDOR_PRODRIVE is not set
# CONFIG_VENDOR_PROTECTLI is not set
# CONFIG_VENDOR_PURISM is not set
# CONFIG_VENDOR_RAZER is not set
# CONFIG_VENDOR_RODA is not set
# CONFIG_VENDOR_SAMSUNG is not set
# CONFIG_VENDOR_SAPPHIRE is not set
# CONFIG_VENDOR_SCALEWAY is not set
# CONFIG_VENDOR_SIEMENS is not set
# CONFIG_VENDOR_SIFIVE is not set
# CONFIG_VENDOR_STARLABS is not set
# CONFIG_VENDOR_SUPERMICRO is not set
# CONFIG_VENDOR_SYSTEM76 is not set
# CONFIG_VENDOR_TI is not set
# CONFIG_VENDOR_UP is not set
CONFIG_BOARD_SPECIFIC_OPTIONS=y
CONFIG_MAINBOARD_FAMILY="ThinkPad T440p"
CONFIG_MAINBOARD_PART_NUMBER="ThinkPad T440p"
CONFIG_MAINBOARD_VERSION="1.0"
CONFIG_MAINBOARD_DIR="lenovo/t440p"
CONFIG_VGA_BIOS_ID="8086,0416"
CONFIG_DIMM_MAX=4
CONFIG_DIMM_SPD_SIZE=256
CONFIG_FMDFILE=""
# CONFIG_NO_POST is not set
CONFIG_MAINBOARD_VENDOR="LENOVO"
CONFIG_CBFS_SIZE=0x20
CONFIG_ONBOARD_VGA_IS_PRIMARY=y
CONFIG_MAX_CPUS=8
# CONFIG_VBOOT is not set
CONFIG_VBOOT_VBNV_OFFSET=0x2a
CONFIG_DEVICETREE="devicetree.cb"
# CONFIG_VGA_BIOS is not set
CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="LENOVO"
CONFIG_INTEL_GMA_VBT_FILE="src/mainboard/$(MAINBOARDDIR)/data.vbt"
CONFIG_PRERAM_CBMEM_CONSOLE_SIZE=0xc00
CONFIG_POST_IO=y
CONFIG_OVERRIDE_DEVICETREE=""
CONFIG_CMOS_DEFAULT_FILE="src/mainboard/$(MAINBOARDDIR)/cmos.default"
CONFIG_CMOS_LAYOUT_FILE="src/mainboard/$(MAINBOARDDIR)/cmos.layout"
CONFIG_ME_CLEANER_ARGS="-S"
CONFIG

[coreboot] Re: Memtest 86+ fork

[Mike Banon]

I guess this work is still needed, seeing only these recent changes at
"Memtest86+ fork" repository -
https://review.coreboot.org/q/project:memtest86plus .
Another thing which I guess may be useful, is rebasing the
coreboot-specific "Memtest86+ fork" patches on top of the latest
official Memtest86+ version 5.31b -  https://www.memtest.org/#downcode
. CC'ing Patrick Rudolph for more details (since it was his ticket 3
years ago)

On Sat, Jan 29, 2022 at 6:43 PM Sameeruddin Shaik
 wrote:
>
> Hi all,
> I wanted to work on below ticket
>
> https://ticket.coreboot.org/issues/184
>
> Is there anyone working on it.
> Any inputs/hints would be appreciated.
>
> --sameer.
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: T440P

[Mike Banon]

Please share your coreboot .config , describe the errors and give us
more info to help you

On Tue, Jan 25, 2022 at 2:51 PM Patrick Bratu  wrote:
>
> Hello dear team of Coreboot I tried to install CoreBoot with SeaBios on
> my T440p with dGPU but I can not get the graphics card to show up and
> when installing Arch also always come errors can you help me please?
>
> Best Regards
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] FOSDEM'22 Open Source Firmware, BMC and Bootloader devroom CFP

[Mike Banon]

Dear friends, on behalf of 3mdeb I invite you to participate in
"FOSDEM'22 Open Source Firmware, BMC and Bootloader" online devroom!
It will take place on 5th February (Saturday), however - the talk
proposals should be submitted before 24th December UTC, so it is time
to act.

The devroom will focus on various topics related to the open source
firmware, BMC and bootloaders including security issues. It will help
to get together all interested people in one place, present and
discuss current developments and issues haunting the community.
Additionally, it will foster awareness among attendees about pre-OS
topics.

So, if you'd like to have your moment of fame - by sharing your deep
knowledge with fellow firmware hackers from all over the world -
please follow the instructions at [1] page below: it contains the
detailed submission instructions and also gives a list of the possible
topics

[1] https://lists.fosdem.org/pipermail/fosdem/2021q4/003320.html
-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

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

[Mike Banon]

> The word 'drop' has ominous connotations, but it's not a deletion. A board is 
> never really gone.

"Dropping" 50 boards may be ominous in relation to the future of the
coreboot project:

1. These boards will be gone for the people who check the "mainboards
supported by coreboot" and see only the "new Intel stuff". This
hinders the coreboot community growth around the "gone boards", and
also of the coreboot community in general: the fewer boards are
supported by coreboot, the more difficult it is for a potential
user/contributor to find the supported board and join us.

2. It's not just the loss of boards - it's also the loss of coreboot
users/contributors who only have these boards and don't want to switch
to anything else: i.e. because the newer coreboot-supported boards
have Intel ME / AMD PSP that are viewed negatively by many people out
of security considerations, - and security is one of the top reasons
why the people switch to coreboot in the first place.

3. Unless someone will be manually copying all the time, these boards
won't get the updates of the common coreboot parts, even if such
updates aren't related to the deletion reason. A reason which won't be
understood by the opensource-loving community around the world - on
Phoronix etc. - as good enough for "50 boards drop" - so doing this
may harm the reputation of a coreboot project.

Of course, the people may finally fork a coreboot to i.e.
"coreboot_extended" or "coreboot_notcorporate" (need a good name) and
continue contributing there. Such a fork may even become more popular
than the original coreboot of the future, because it will support
significantly more boards. But, if this happens, it will fragment the
coreboot community and split / spread thin our joint efforts for not a
good enough reason.

> It's just that active development ends, as no one is working to keep them up 
> to date. There is a cost to keeping boards too long when there is no one 
> maintaining them.

Even right now there's an active development & maintainership (as
evidenced by all these changes at review.coreboot.org), - just not for
this v4 resource allocator.

> Would it be ok with you to drop the board, and bring it back when it is 
> working again?

I'm not sure I understand: at least my boards from this list are
working perfectly at the moment.

> They may still build, but they can stop working. People should be able to 
> count on a board working if they build an image.

I am often build-testing my boards (didn't notice a
https://review.coreboot.org/c/coreboot/+/59636 problem for a while,
but only because I've been re-using the previously built toolchains to
save time). Also, I am actively tech-supporting 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 the project one day.

Hopefully my post above explains why I think "dropping 50 boards is a
bad idea", although I agree that it would be nice to get a resource
allocator v4 working on them.





On Thu, Nov 25, 2021 at 12:46 AM ron minnich  wrote:
>
> The word 'drop' has ominous connotations, but it's not a deletion. A
> board is never really gone. It's git. I can still find the Alpha
> boards in there if I go back far enough. It's just that active
> development ends, as no one is working to keep them up to date.
>
> Would it be ok with you to drop the board, and bring it back when it
> is working again?
>
> There is a cost to keeping boards too long when there is no one
> maintaining them. They may still build, but they can stop working.
> That's happened and in my view it's best not to let it happen. People
> should be able to count on a board working if they build an image.
>
> Thanks
>
> ron
>
>
> On Wed, Nov 24, 2021 at 12:16 PM Mike Banon  wrote:
> >
> > With all due respect, dropping support for the majority of AMD boards
> > - with a quite significant community around them! - doesn't seem like
> > a wise decision, if 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 all
> > costs...
> >
> > Some time ago I did https://review.coreboot.org/c/coreboot/+/41431
> > change where tried to get a resource allocator V4 working for these
> > AGESA boards, and despite a tiny size (less than 20 lines) - it almost
> > worked, judging by that fam15h A88XM-E booted fine (although there
> > might have been some other problems undercover). I wonder if it could
> >

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

[Mike Banon]

With all due respect, dropping support for the majority of AMD boards
- with a quite significant community around them! - doesn't seem like
a wise decision, if 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 all
costs...

Some time ago I did https://review.coreboot.org/c/coreboot/+/41431
change where tried to get a resource allocator V4 working for these
AGESA boards, and despite a tiny size (less than 20 lines) - it almost
worked, judging by that fam15h A88XM-E booted fine (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.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 fair. I just found this updated 
> release schedule in the meeting minutes.
> If we are going to release every 3 months then I guess that's a good way to 
> go.
>
> I started a CL: https://review.coreboot.org/c/coreboot/+/59618 . I'll update 
> it to reflect that schedule if it can be agreed upon.
>
> On Wed, Nov 24, 2021 at 6:07 PM Martin Roth  wrote:
>>
>> Hey Arthur,
>>
>> Nov 24, 2021, 05:50 by art...@aheymans.xyz:
>>
>> > Hi
>> > I would like to suggest to deprecate some legacy codepaths inside the 
>> > coreboot tree and therefore make some newer ones mandatory.
>> > ... snip ...>  About the timeline of deprecations. Is deprecating non 
>> > conforming platforms from the master branch after the 4.16 release in 6 
>> > months a reasonable proposal?
>> >
>> I have no strong opinion about the platform deprecations, although I suspect 
>> that PC Engines might be unhappy if it's platforms were removed from the ToT 
>> codebase.
>>
>>  My preference would be to announce deprecations in the release notes.  We 
>> just missed the 4.15 release, but we're switching to a 3 month release 
>> cadence, so the next release will be in early February, 2.5 months from now.
>>
>> 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.
>>
>> Would this schedule work?
>>
>> Martin
>>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



--
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Invitation: [Events] "vPub v3" online Party! - 16th November at 8 PM UTC

[Mike Banon]

Dear friends, our vPub v3 event starts in 15 minutes! :D Join us at
https://vpub.dasharo.com/

On Fri, Nov 12, 2021 at 1:25 PM Mike Banon  wrote:
>
> Dear friends,
>
> Thank you for a wonderful time with us on our past v1 and v2 online
> parties! :D Now we at 3mdeb are organizing a new event - Dasharo OSF
> vPub Fall 2021 (aka vPub v3) - with so many interesting topics for a
> pleasant discussion! Open/libre firmware/hardware, and more! Join us
> on 16th November at 8 PM UTC - using this page:
> https://vpub.dasharo.com/
>
> Our new vPub is directly after the "Linux Secure Launch" TrenchBoot
> Summit - https://trenchboot.org/secure-launch-summit/ - that we're
> co-hosting between 4 - 8 PM UTC on 16th Nov too. It's going to be a
> deep dive into the truly secure opensource firmware booting - an
> exciting journey for those interested in firmware hardening their
> systems.
>
> You are welcome to join any or both of these events, and we will be
> waiting for you! ;-) Let's try to stress test our servers'
> capabilities and beat the previous record of 50 attendees
> --
> Best regards, Mike Banon
> Open Source Community Manager of 3mdeb - https://3mdeb.com/



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Asus: A87XM-A

[Mike Banon]

Dear friend, I think you meant the A88XM-E and A88XM-A boards
respectively. A88XM-A is not supported yet, but if you are interested:
you can take the source code of A88XM-E as the base, and - using the
guidelines at https://www.coreboot.org/Developer_Manual and
https://www.coreboot.org/Motherboard_Porting_Guide - try to port a
coreboot for your board. However, if you are beginner, it may be
easier to just get a A88XM-E board: these used boards could be found
on i.e. AliExpress

On Sat, Nov 13, 2021 at 11:54 PM Yonatan Zilpa  wrote:
>
> I know that Asus: A87XM-E is supported. Does Asus: A87XM-A is also supported?
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Invitation: [Events] "vPub v3" online Party! - 16th November at 8 PM UTC

[Mike Banon]

Dear friends,

Thank you for a wonderful time with us on our past v1 and v2 online
parties! :D Now we at 3mdeb are organizing a new event - Dasharo OSF
vPub Fall 2021 (aka vPub v3) - with so many interesting topics for a
pleasant discussion! Open/libre firmware/hardware, and more! Join us
on 16th November at 8 PM UTC - using this page:
https://vpub.dasharo.com/

Our new vPub is directly after the "Linux Secure Launch" TrenchBoot
Summit - https://trenchboot.org/secure-launch-summit/ - that we're
co-hosting between 4 - 8 PM UTC on 16th Nov too. It's going to be a
deep dive into the truly secure opensource firmware booting - an
exciting journey for those interested in firmware hardening their
systems.

You are welcome to join any or both of these events, and we will be
waiting for you! ;-) Let's try to stress test our servers'
capabilities and beat the previous record of 50 attendees
--
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] coreboot Wiki contribution workflow, old Wiki and how to increase the contributions

[Mike Banon]

 On Fri, Aug 20, 2021 at 10:07 AM Keith Emery 
wrote:

> Guy's if the WiKi is unmaintained can we just get rid of it. Google loves
> directing people to it, and it's incredibly confusing / misleading.


Before getting rid of the old Wiki, the community should look through it
page-by-page and move all the important still-valid stuff to the new Wiki.
To avoid losing anything of value! Of course, if the contribution process
to the new Wiki would've been a real-time WYSIWYG write process
just like at so many established successful Wikis - and without requiring
the upvotes from other people to commit each contribution! - there'd be a
lot more activity and this would have already happened.

I believe that the current process of contributing to the coreboot
documentation is inefficient, and not just me. On one of 3mdeb's past
vBeers, Alexey Vazhnov described how tricky could it be to get merged the
coreboot docs and shared his experiences at this post:
https://www.reddit.com/r/coreboot/comments/lm7jh8/my_pain_with_documentation_contribution_in/

Old wiki died because the people willing to contribute were prevented from
doing so by a closed registration roadblock and had to go elsewhere with
their manuals - which now are scattered all over the Internet, i.e. stuff
like this could've been on a coreboot wiki -
http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate#Crafting_the_interface
. But, if the simplification of Wiki contribution process isn't done out of
fear of bots/spammers, you can always set up an advanced math captcha like

_||| 3*x^7 + x^6 + 2*x^5 + 4*x^4 + 4*x^3
lim --
x->0 ||| 5*x^5 + 4*x^4 + 3*x^3

which takes a minute to learn how to solve even if you don't know how at
the moment.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Installing coreboot to listed motherboards

[Mike Banon]

That's because you need to set up a coreboot config by yourself (make
menuconfig) because there are so many boards and options... You can take
someone's successful config from board status repository for your board,
and copy it to ./.config of your ./coreboot/ directory to use it as a base.

On Thu, Jun 3, 2021 at 5:19 PM Павел  wrote:

> Hello. I've typed `git checkout ` and `git submodule update
> --checkout` and git updated files and switch to this hash. But the
> config file did not appear in the directory. Is that how it should be?
> Do I have to download the configuration myself (from
> https://review.coreboot.org/plugins/gitiles/board-status/) and place it
> in the directory?
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>


-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [Part 2] Dell OptiPlex and coreboot BIOS - a story about porting cursed hardware

[Mike Banon]

Great news: we at 3mdeb have advanced in porting Dell Optiplex 7010⁄9010 to
coreboot! And, if you would like to see what it takes to add coreboot
support for the cursed hardware - from a coreboot developer's point of
view! - here's a new highly entertaining blog post by Michal Zygowski:
https://blog.3mdeb.com/2021/2021-06-01-optiplex_part2/
-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Free coreboot training! - and how you can help it

[Mike Banon]

This summer, free & open-source OpenSecurityTraining website - will be
relaunched as OpenSecurityTraining2 ( https://x.ost.fyi/ ) with even
higher quality free training courses! Since Piotr Król volunteered as
a content provider for coreboot-related topics, we at 3mdeb developed
a new "Architecture 4031: x86-64 Reset Vector Implementation:
coreboot" course.

And now, we're looking for beta testers for the introductory coreboot
class. If you:
* learned coreboot elsewhere and willing to provide your expert feedback,
* or you are getting started with coreboot and want to learn it faster,
- please help us to improve this class! Feel free to share your
valuable ideas, and even the fixes for the auto-generated captions
will be a huge help.

Beta testing will end by mid-June, so - if you're interested in this
course, please subscribe by this link to access its' beta version -
https://newsletter.3mdeb.com/subscription/23ERA9Fb0
-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Supporting different SUPER IO CHips in the Protectli FW6C /devices YANGLINGs you buy from aliexpress

[Mike Banon]

Do I understand this correctly: if a SuperIO ITE IT8772F of your
Protectli device got burned, and you replace this chip by IT8613E
manually (or with the help of a hardware repair shop) - then this is a
coreboot mod which you have to apply to get it working? Also, did you
have to flash any firmware to this replacement chip, or it worked
out-of-the-box?

On Thu, May 13, 2021 at 11:50 PM lain via coreboot
 wrote:
>
> this code worked for me i am hyped
> can we make something out of it ? 
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [Events] "vBeer v2" online Party! - 7th May at 3PM UTC

[Mike Banon]

Dear friends, on behalf of 3mdeb I invite you to a fresh "vBeer v2"!
Let's discuss the open/libre firmware/hardware and other nice embedded
things you have in mind. To join us go to http://vpub.3mdeb.com/may7th
on 7th May at 3PM UTC

at "v1" there was a great discussion with 50 firmware masters from all
over the world! Here's my blogpost [1] about it. And this time -
together with your surprise suggestions (you're welcome!) - we could
explore:
* new advances at opensource firmware/hardware world, like this new
initiative [2] for opensource FPGAs
* is the new emerging RISC-V hardware such as BeagleV [3] - truly open?
* results of "Ideal platform for coreboot training" survey [4] (which
is still going on btw)

- and much more! There'd be a productive talk with a cosy atmosphere
and good vibes - so, feel invited and take your beer! ;)
http://vpub.3mdeb.com/may7th , 7th May at 3PM UTC

[1] https://blog.3mdeb.com/2021/2021-02-23-osf_vpub_01/
[2] https://osfpga.org/osfpga-foundation-launched/
[3] https://beagleboard.org/beaglev
[4] https://corequest.limesurvey.net/274886?lang=en
-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [Survey] Ideal platform for coreboot training?

[Mike Banon]

I'm sorry this wasn't clear, but your answers would be valuable in any
case. As for

> Could have asked "what's your favorite x86 board in the tree and why?"

- this could be different: maybe you have a favorite x86 board, but at
the same time you understand it's not ideal for a coreboot training
(because too expensive/rare/advanced/unique if compared to some other
variants)

On Sun, May 2, 2021 at 2:45 PM Nico Huber  wrote:
>
> On 29.04.21 11:11, Mike Banon wrote:
> > Dear Friends, please share your thoughts to help us at 3mdeb to
> > advance a coreboot project - by participating in this opensource
> > survey of just 7 questions:
> >
> > * Ideal platform for coreboot training?
> > https://corequest.limesurvey.net/274886?lang=en
>
> Somehow noteworthy: Platform seems to mean "x86 mainboard" here. *Not*
> a platform that a board would be based on. That's not obvious from the
> first questions so I wasted a lot of time, I guess.
>
> Could have asked "what's your favorite x86 board in the tree and why?".
>
> Nico



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [Survey] Ideal platform for coreboot training?

[Mike Banon]

Dear Friends, please share your thoughts to help us at 3mdeb to
advance a coreboot project - by participating in this opensource
survey of just 7 questions:

* Ideal platform for coreboot training?
https://corequest.limesurvey.net/274886?lang=en

Thank you very much in advance!
--
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Discrete graphic vbios extraction

[Mike Banon]

Sorry, at the moment I could only suggest to "find" a Windows 7 USB,
do a clean install & drivers installation and use this Belkasoft tool
according to ultimate VGABIOS extraction writeup - that's if you need
it quick. However, if you'll achieve a similar access with Lime,
please let us know: it is much better if stuff like this could be done
with the opensource software and no Windows hassle.

On Fri, Apr 16, 2021 at 10:52 PM Peter Stuge  wrote:
>
> Gian Lorenzo Spisso wrote:
> > Thank you so much for your reply.
> >
> > Indeed, after a bit of research I've stumbled upon Lime which is a kernel
> > module allowing the dump of the whole memory which I'm doing right now.
>
> Oh good, that's worth a try.
>
>
> > Do you have any pointer on how to locate the bit I'm interested in?
>
> Here's a hex dump of the first 80 bytes of my VGA BIOS:
>
> 000: 55aa 80e9 a9e3 3030 3030 3030 3030 3030  U.00
> 010: 3030 b021 e9a1 2059 4000 e00a 3030 4942  00.!.. Y@...00IB
> 020: 4d20 5647 4120 436f 6d70 6174 6962 6c65  M VGA Compatible
> 030: 2042 494f 532e 2003 5b00 6b00 7900 8bc0   BIOS. .[.k.y...
> 040: 5043 4952 8680 a227  1800  0003  PCIR...'
>
> Bytes 0 and 1, 0x55 and 0xaa, mark the start of the option ROM,
> and offsets 0x44-48 (0x86 0x80 0xa2 0x27) contain the PCI ID of the
> graphics hardware that this option ROM is for.
>
> The PCI ID of my graphics hardware is 8086:27a2; note that the two
> 16-bit numbers are stored little-endian in the image.
>
> Searching for this in e.g. a large file again needs some programming,
> because the individual bytes (0x55, 0xaa, or the ID bytes) will occur
> quite frequently.
>
> One option might be to first look for some text strings in the
> internal VGA option ROM and see if they occur in more locations in
> the new memory dump, to then search only those regions manually.
>
>
> > I am alsok wondering, should I make sure my gpu is running since
> > its a discrete card for the vbios to be loaded in memory?
>
> Hm, I think that will depend on the particular hardware design of
> your GPU and of your mainboard. The GPU should not be powered down,
> because the option ROM is probably only accessible through the GPU.
>
>
> Finally, if the software approach fails, another method may be to look
> for the flash chip on the mainboard and read it out with hardware means.
>
>
> Kind regards
>
> //Peter



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: CB:46587 - pirq_routing

[Mike Banon]

Hi there Elyes,

Your "getpir" idea really helped me to implement a set of CB:48427
"AMD good IRQ" patches.
Thank you so much for your kind help! Wanted to thank you earlier but
it got lost in drafts ;-)
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [flashrom] Fail flashing

[Mike Banon]

I think the only way to prevent the current leaking to the surrounding
elements of a chip - is desoldering. So, if we are trying to avoid the
desoldering - yes, you could try reducing the length of wires between
a programmer and a test clip - i.e. to 10cm. That certainly wouldn't
hurt, and sometimes it really helps to achieve the successful flashing
by ISP (in-system programming) method.

Please note: while there are some successful examples of using the
external PSU for an ISP flashing (i.e. this [1] BBB example at
libreboot wiki), depending on a motherboard design this could be
dangerous according to Angel Pons comments under [2] - so using the
external PSU should be avoided unless all the other options have been
tried and you still don't want to solder/desolder.

While looking for the examples of L530 flashing I found a thread with
your comments [3]. To answer your question why the other people were
also targeting a ps08a chip: this is CMOS, and clearing a CMOS memory
sometimes is also important to ensure the successful boot of a
proprietary BIOS - but we haven't reached this stage yet, since we're
just trying to flash a BIOS into a SPI flash chip.

Have you ever tested your CH341A before in other setups? If not, do
you have a spare CH341A to try it with a different one? And could you
try a higher powered USB port to ensure that your CH341A itself is
sufficiently powered? (i.e. you may be using a USB extender for your
convenience, which is fine - but that extender also shouldn't be too
long)

[1] https://libreboot.org/docs/install/bbb_setup.html
[2] https://review.coreboot.org/c/flashrom/+/31830
(this was my patch for the older version of flashrom useful in a
unreliable flashing setup, but I only successfully read with it and
never successfully wrote).
[3] https://www.badcaps.net/forum/showthread.php?t=61517

P.S. I'm not sure how you can measure the leakage with a multimeter,
and in any case knowing the exact values isn't necessary - when we
already know the cause of unsuccessful flashing and just need to find
out how to resolve it.


On Wed, Mar 24, 2021 at 8:46 PM G. Nalin  wrote:
>
> HI,
>
> I have been recommended to desolder the BIOS chip to use the CH341a reliably, 
> but I would like to avoid it and use the clip instead! Should I simply cut 
> shorter the clip wires? Is there something I can do to ground the motherboard 
> or avoid the leaking? How can I measure it (I have just a multimeter here 
> atm).
>
> I don´t know how to supply the power externally while the EEPROM is connected 
> to the USB. Could you indicate me a reference?
>
> I tried to verify the dumo, but if fails because there is some writing 
> involved.
> $ sudo flashrom -V -p ch341a_spi -v bios1b.img
>
> I don´t have a reference so I can´t say if the HEX or BIN dump is actually at 
> least partially valid. It is not all FF and 00.
>
> Cheers,
>
> Giammarco Nalin
>
> Handy: +4915252667614
> Adresse: Hausener Weg 96, 60489, Frankfurt am Main
>
>
> 
> From: Mike Banon 
> Sent: 24 March 2021 13:40
> To: G. Nalin 
> Cc: flash...@flashrom.org 
> Subject: Re: [flashrom] Fail flashing
>
> Could you please verify that at least a part of the binary file got
> flashed correctly? If yes, these reliability problems could be caused
> by your setup - i.e. too long wires or the surrounding elements of the
> BIOS chip are drawing too much current - causing a voltage drop on the
> chip itself and the remaining is insufficient for the reliable
> flashing (in this case I could recommend using the external power
> supply for 3.3V line)
>
> On Wed, Mar 24, 2021 at 9:50 AM G. Nalin  wrote:
> >
> > Hi all,
> > I am trying to flash a WInbond w25q64bv BIOS chip of a Thinkpad L530. I am 
> > on Ubuntu 20.04. Using a EEPROM  ch341a and I am not able to copy correctly 
> > the content of the chip: diff and md5sum return all the time some errors. 
> > Trying to erase the chip gives random errors like
> >
> > Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
> > Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) on ch341a_spi.
> > Reading old flash chip contents... done.
> > Erasing and writing flash chip... FAILED at 0x000b6000! Expected=0xff, 
> > Found=0xae, failed byte count from 0x000b6000-0x000b6fff: 0x382
> > ERASE FAILED!
> >
> > and so on. When I prompt the internal status I get:
> >
> > $sudo flashrom -V -p internal
> >
> > flashrom v1.2 on Linux 5.8.0-45-generic (x86_64)
> > flashrom is free software, get the source code at https://flashrom.org
> >
> > flashrom was built with libpci 3.6.4, GCC 9.2.1 20200304, little endian
> > Command line (3 args): flashrom -V -p internal
> > Using clock_gettime for delay loops (clk_

[coreboot] TrenchBoot forum starts in 3 hours! what TrenchBoot can give you on top of coreboot?

[Mike Banon]

Dear friends, in just 3 hours (16:00 GMT) there's a TrenchBoot forum -
and you are welcome to visit us at
https://trenchboot.org/tdf-schedule.html . To those who are new to
TrenchBoot and wonder what it's all about:

1) please take a look at my small write-up on what advantage
TrenchBoot could give you on top of coreboot firmware - [1]
2) check out the 3mdeb articles about TrenchBoot - [2]
3) and of course join the #trenchboot channel on OSFW Slack - [3] -
for the archived videos with more info!

[1] 
https://www.reddit.com/r/3mdeb/comments/mbjak0/events_trenchboot_forum_on_24th_march_what/
[2] https://blog.3mdeb.com/tags/trenchboot/
[3] https://osfw.slack.com/
-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: CPU and MB temperature

[Mike Banon]

Hi there Gottfried,
This page [1] - has a great instruction on how to use this csb_patcher
and correct sequence of commands. You just need to do a [2] command
after git clone'ing the coreboot sources. Another thing you need to
consider: in the example config which I provide with csb_patcher, I'm
using a pci1002,990c.rom for HD-8670D iGPU of my A10-6700 CPU. If you
have another CPU installed to your A88XM-E - with another iGPU - you'd
need to additionally get your own AtomBIOS, go to menuconfig and
change the PCI IDs / filenames from "1002,990c" to whatever your CPU
has. Hope that helps, since it's unlikely the csb_patcher's unofficial
patches will get merged in the near future, we'll have to keep using
it to easily obtain these not-merged-yet patches that improve our user
experience. And, if you have any questions, I'll be happy to help you.

[1] http://dangerousprototypes.com/docs/Lenovo_G505S_hacking
[2] git reset --hard 9a5d6e958f4ff9fd35439bf6c6f37c852725592c

On Sun, Mar 21, 2021 at 7:34 PM web25322986p1
 wrote:
>
> Hi Mike
> I recorded the patch, unfortunately no success, does not boot. I'm not sure 
> that I did everything right, Google translators must use and the result is 
> not easy to understand. For the time being the .rom File without patching 
> again, so he starts. Everything with Menuconfig would manage the passable way 
> for a man of my age. Is the patch incorporated, in the future, so that I can 
> try again later?
> Best regards and thank you
> Gottfried
>
> --
> *
> Gottfried Kunze
> Telefon 03421 7732269
> Mobil   0160 91012179
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: CPU and MB temperature

[Mike Banon]

Good day Gottfried,

Maybe I could help you with A88XM-E. After git clone'ing the coreboot
sources, git reset --hard 9a5d6e958f4ff9fd35439bf6c6f37c852725592c -
to revert to a few days earlier (because my csb_patcher.sh script is
slightly outdated at the moment), then make crossgcc-i386 like usual
and apply the csb_patcher.sh script from
https://review.coreboot.org/c/coreboot/+/33509 - it will install a set
of not-merged-yet changes, some are beneficial for A88XM-E, and
provide a good refined config for A88XM-E. However, if it doesn't
bring satisfactory results, we will need to think together.

On Thu, Mar 18, 2021 at 10:41 AM web25322986p1
 wrote:
>
> Hi
> For me, Coreboot works on an Asus F2A85-M and A88XM-e. It lacks the CPU and 
> MB temperature in LM sensors, there are negative values and the fan control 
> does not work. I have not activated Hudson blobs and leave all settings, 
> except for the insertion of onboard graphic file and identifier. Which 
> settings in Menuconfig are the temperatures pass properly?
> Thanks for good tips
> Gottfried
>
> --
> *
> Gottfried Kunze
> Telefon 03421 7732269
> Mobil   0160 91012179
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] cbfstool without cloning the whole repos? Use this script for <4MB download

[Mike Banon]

The original script has been created by my friend Ivan Ivanov aka
qmastery [1] but I noticed that it doesn't work anymore - because a
cbfstool got a lot more new dependencies: 4MB of sources, compared to
the previous 2MB. Had to update this script heavily [2] and now it's
working fine as of today.

[1] 
https://mail.coreboot.org/hyperkitty/list/seab...@seabios.org/thread/VQHRAEFYDRFFMAN5JEG4BUH666KJEZGS/
[2] https://review.coreboot.org/c/coreboot/+/51393
-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/


cbfstool_get.sh
Description: application/shellscript
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Unable to run KolibriOS in QEMU with coreboot and SeaBIOS

[Mike Banon]

Hi Paul, as for me I could successfully run KolibriOS in QEMU/i440fx
4MB with coreboot and SeaBIOS. Here's my sequence of actions:

git clone https://review.coreboot.org/coreboot/
cd ./coreboot/
make crossgcc-i386
run a csb_patcher script from
https://review.coreboot.org/c/coreboot/+/33509 , mainly for the
SeaBIOS multiple floppies patch and to auto-download the floppy
collection
make menuconfig , then choose QEMU/i440fx and 4 MB (0x0040 CBFS size)
make
./csb_patcher.sh flop
add all the floppies that you'd like, then run a command
qemu-system-x86_64 -L . -m 256 -vga vmware -net nic,model=rtl8139 -net
user -soundhw ac97 -usb -usbdevice tablet -bios ./build/coreflop.rom
-serial stdio

As you see I'm not using KVM - that's because I don't have this kernel
module installed on a PC I'm at the moment. I believe your problem is
related to the QEMU flags - please start with my set of flags which is
more-or-less guaranteed to work, and slowly change one-by-one to your
liking. For your testing purposes,

Here's my coreflop image - https://www.sendspace.com/file/j4idzp , sha256 sums
68bfb64a68e37df0e8939391ee70aef41c7cd03d8de624b2a6d836d7e1ac8d55
./coreflop.tar.gz
dec8577a76bf190c72f69a4b7fe4f8ef53d53af19ac6890485311da7dd6eb2d5  ./coreflop.rom
coreboot revision - b77cf2299c516a7f5a9a4eccad2b21157278a283

You may also play with the other floppies inside if you'd like - it's fun!
-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [flashrom] error bios

[Mike Banon]

Glad to help you. For your future replies, make sure that you're
reposting to the mailing list as well.

On Tue, Mar 2, 2021 at 9:39 PM edvaldo silva  wrote:
>
> I performed all the tests I was using another version of linux I switched to 
> linux manjaro and apparently it worked out I changed the recording mode. 
> before I was using:
> sudo apt flashrom -p ch341a_spi -w (bios name) .bin, in manjaro I'm using it 
> like this and it's working: sudo --programmer ch341a_spi -w (bios name) .bin 
> and now it's recording normal.
>
> thanks
>
>
> Att,
>
> Edvaldo Silva
> edvaldo@zohomail.com
> +55 12 9 8209 6114
>
>
>
>
>  Ativado Ter, 02 mar 2021 13:24:31 -0300 Mike Banon  
> escreveu 
>
> Well, it looks like your flashing has failed. Why? Maybe your flashing
> setup wasn't reliable enough: long wires etc. Until we'll learn more
> of it, we can't help you
>
> On Fri, Feb 26, 2021 at 10:55 PM edvaldo silva via flashrom
>  wrote:
> >
> > Found GigaDevice flash chip "GD25Q64(B)" (8192 kB, SPI) on ch341a_spi.
> > Reading old flash chip contents... done.
> > Erasing and writing flash chip... Erase/write done.
> > Verifying flash... FAILED at 0x4500! Expected=0x45, Found=0xff, failed 
> > byte count from 0x-0x007f: 0x156b2
> > Your flash chip is in an unknown state.
> >
> > Att,
> >
> > Edvaldo Silva
> > edvaldo.si...@zohomail.com
> > +55 12 9 8209 6114
> >
> >
> >
> > ___
> > flashrom mailing list -- flash...@flashrom.org
> > To unsubscribe send an email to flashrom-le...@flashrom.org
>
>
>
> --
> Best regards, Mike Banon
> Open Source Community Manager of 3mdeb - https://3mdeb.com/
>
>
>


-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Question regarding reflashing/updating

[Mike Banon]

According to https://www.coreboot.org/Board:lenovo/x230#Internal_Flashing
, yes the internal flashing is possible on x230 - however, you may
have to boot with an extra iomem=relaxed Linux kernel flag. The simple
ways of verifying could be adding a custom splash screen or boot
message that you recognize, or reading a firmware internally and
checking its' SHA256 sometimes. Also, there are more advanced ways of
verification, such as vboot.

On Mon, Feb 22, 2021 at 8:57 PM Louis via coreboot
 wrote:
>
> Hello,
>
>
> Just wanted to say thank you for creating this firmware it is a great
> project and I hope I can contribute to it one day.
>
>
> I have an x230 preinstalled with Coreboot skulls, am I able to re-flash
> Coreboot skulls internally just through the OS or is there a way to
> verify that the firmware installed on the system hasn't been modified in
> any way, thank you.
>
>
> Kindest regards,
>
> Louis
>
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Display Port Monitor turns off during Ubuntu OS boot

[Mike Banon]

Is your platform coreboot-supported, if yes - have you tested it with coreboot?

On Thu, Feb 25, 2021 at 9:09 PM Rao G  wrote:
>
> Hi Coreboot Team,
>
> There is an external Monitor which works on HDMI/DVI and also DP , In BIOS 
> the display is good whereas in OS (Ubuntu 18.04) until the kernel is 
> initialized and i915 Video driver
> is loaded display is perfect, looks like the i915 OS driver switches off the 
> monitor and there is no signal
>
> Does ACPI GFX method have to return any External display specific data to the 
> OS driver ?
> Tried to make changes to VBIOS but did not help, thought ASL code is missing 
> under GFX0
>
> From the OS following data can be read
>
> External Monitor's EDID data can be read from I2C Bus
> Even VBT data from ACPI NVS can be read
>
>
> Tried to dig into some of these files
> https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/i915/display
>
> intel_dp.c, intel_acpi.c to understand what function is turning off DP link
> when i have the OS debug driver logs, can send it across
>
> Any clues will help, appreciate your time
>
> PS:The platform has Intel BayTrail SoC, ValleyView chipset and VBIOS. The 
> bios do not use GOP driver which replaces VBIOS
>
> Thanks
> Rao
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Lenovo T410: Regression in coreboot 4.13?

[Mike Banon]

Know it may be late, but you should've done a commit dichotomy to find
some bad commit which maybe happened between 4.12/4.13 and could've
been a real cause of your problem.

On Sat, Feb 20, 2021 at 11:45 PM Daniel Kulesz via coreboot
 wrote:
>
> Hi folks,
>
> I spent a long time trying to get coreboot 4.13 to work on a Lenovo T410, 
> trying various configuration options etc. but it never worked (fan, keyboard 
> LED and thinklight went on, screen stayed dark). I tried even the most basic 
> config, but no luck.
>
> I tried the same with coreboot 4.12 and this seems to work fine.
>
> Unfortunately, this is not my laptop and the owner needs his laptop back 
> asap, so I don't have the time to further debug this issue. Yet, I wanted to 
> report this regression as I I am wondering if anyone else is running 4.13 on 
> a T410 with success?
>
> Cheers, Daniel
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: what are requirements for coreboot IOMMU support?

[Mike Banon]

Have you verified that the Sapphire H61 "IOMMU enable" option is really working?

On Tue, Feb 23, 2021 at 2:26 PM ludphaeus via coreboot
 wrote:
>
> Hi
> I am trying to port a Haswell laptop and I would want it to have IOMMU 
> support. My chipset supports VT-d but CPU does not. The official info from 
> Intel says the PC needs chipset, CPU and BIOS to support VT-d to use IOMMU. I 
> think this is not true because I saw some boards in board status have working 
> IOMMU with no VT-d support in chipset but with coreboot advertising DMAR 
> table to OS and CPU with VT-d support. Sapphire H61 is a example of this. But 
> other H61 coreboot boards such as P8H61-M LX that have CPU without VT-d 
> advertise no IOMMU capability. So what is really required for full IOMMU ? Do 
> I have chance for full, working IOMMU on this laptop?
> Thanks,
> Lud
>
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Please review a tiny CB:48616 URL fix for a tint payload

[Mike Banon]

https://review.coreboot.org/c/coreboot/+/48616 - without this tiny URL
fix, building a secondary tint payload results in an error (since the
old archive became unavailable). Would be nice if you can review this
patch to bring back a wonderful tint game
-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Which of these mini-ITX mainboards is best supported?

[Mike Banon]

Hope you can find the way to keep or sell all these coreboot-supported
boards. Selling those which you don't personally need - shouldn't be
hard: since the CPUs are much more resilient than motherboards - there
should be a lot of old server's owners looking for a motherboard
replacement, and the coreboot support is a great selling point,
especially if you can preinstall a coreboot to their chips

On Sat, Feb 6, 2021 at 6:11 AM U'll Be King Of The Stars
 wrote:
>
> On 04/02/2021 05:11, Peter Stuge wrote:
> > U'll Be King Of The Stars wrote:
> >> -   Intel D510MO (my personal favorite of this list)
> >> -   Intel D945GCLF (and D945GCLF2, D945GCLF2D)
> >
> > I have 945 bias. But it's mature, has received a lot of work, and I
> > would expect it to work well or be easy to fix.
>
> Thank you Peter for your opinion.  I really value this (as well as
> Angel's information re: 410PT).
>
> I've been preparing to get rid of many of these boards.  The ideas I had
> for them were as follows.  For example...
>
> 1.  A cluster of cheap, corebooted (or Librebooted) boards to experiment
> with computational benefits of clustering.  For various reasons, it was
> much more appealing to do this with corebooted boards.
>
> 2.  An interesting look at whether a hyperconverged storage structure is
> feasbible.
>
> I was going to settle on the D510MO, but I heard some rumors that put me
> off.  I wish I could remember what these were, so I'll just forget I
> heard that there were rumors at all, and experiment with each model to
> get this started and help me decide what to keep and what not to keep...
> perhaps...
>
> Selling these boards is a lot of effort and wouldn't bring in much money
> anyway.  I may instead simply experiment with all of them and find a
> compact way of packing the away those that aren't used.
>
> Most of the hardware that is causing problems is large, heavy, unused
> old servers.
>
> Andrew
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [Events] Talk about coreboot on POWER + vBeer online party!

[Mike Banon]

Dear friends,

Next Thursday __4th Feb at 3PM GMT__ , 3mdeb invites you to talk about
the POWER9 support in coreboot opensource BIOS -
https://meet.google.com/xsy-ocfw-exm . You are going to learn: 1)
great benefits a coreboot will deliver to POWER-based PCs; 2) our
progress and interesting challenges we are facing; 3) unique features
of Dasharo coreboot-based firmware.

Also, soon we are having a vBeer online party! Will be happy to
discuss the open/libre firmwares (coreboot, Dasharo, etc.), related
hardwares and other nice embedded things you have in mind. Please visit
http://live.evenea.com/3mdeb-vbeer at 18th Feb 3PM GMT to have some
fun with us.

-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Questions about Asus A88XM-E

[Mike Banon]

I see. Hopefully your BIOS chip is resilient enough, as supplying 5V
instead of 3.3 V might have damaged it or reduced its reliability.
Even if you got one of the faulty CH341A with 5V instead of 3.3V, it's
possible to hardware mod it like
https://www.chucknemeth.com/usb-devices/ch341a/3v-ch341a-mod to make
it 3.3V.
In my opinion RPi is less secure than a simple tool like CH341A - so
even if you got the BIOS flashing working with RPi, repeating your
success with CH341A is still a worthy goal.

You need to press the ESCape key to open the SeaBIOS boot menu, not DELete.

On Sat, Jan 23, 2021 at 7:56 PM magiccat1--- via coreboot
 wrote:
>
> Hi Mike,
>
> Thank you so much for your help,
>
> I found out why Ch341a did not work.  It is outputting 5 V, when I replaced 
> that with 3.3 V from Raspberry pi, everything works.  Raspberry pi is a good 
> flashing tool.
>
> Then I have seabios working.  I am total new to Seabios, when I put in a USB 
> key and a SATA hard-drive, it always picks SATA hard-drive.  When I press 
> delete key, there is no option to move to USB key.
>
> I am not sure how to use seabios to boot with USB storage.
>
> Thanks,
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org



-- 
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Questions about Asus A88XM-E

[Mike Banon]

Hi there friend,

For 1), did you plug a BIOS chip into a CH341A directly? Or using a
DIP-8 test clip? + would be nice if you have more than one CH341A and
could try with both of them to exclude a programmer's fault (one of my
ch341a had a missing capacitor and another had a badly soldered chip
leg). Yes, a BIOS chip could be dead, but instead of getting a
replacement 8MB chip you can get a larger 16MB one in a DIP-8 shape.
For example, W25Q128FVIQ - I saw a lot of 2pcs of them on AliExpress
for $2.19 with a free shipping (
https://www.aliexpress.com/item/4000539812523.html ) . May be a better
deal per pcs from the other sellers if you need more of these chips.
With 16MB chips, and coreboot taking less than 1MB, there's a big room
for some interesting experiments (floppy-based OS images like
KolibriOS, tiny Linux, etc.)

2) Yes, it's a known problem that a TINT payload link is dead, I've
submitted a patch with a new link but seems it hasn't been merged to a
coreboot master yet. So you'd need to either manually fix a link or
disable Tint. Coreinfo should be fine and you could enable it again.

> When I boot with Coreboot, I see a black screen

It's expected if you're having the flashing problems, I wonder what %
of coreboot.rom really got flashed.

3) For the sample configuration, what is this file?
CONFIG_PAYLOAD_CONFIGFILE="$(top)/src/mainboard/$(MAINBOARDDIR)/config_seabios"

This config file for SeaBIOS contains a few lines for disabling some
of the configs irrelevant for our board. For example, if A88XM-E
doesn't have a TPM header, could just remove the TPM support from a
SeaBIOS build for it and save like 20 KB of free space.

Hope this helps ;)

On Thu, Jan 14, 2021 at 4:18 AM magiccat1--- via coreboot
 wrote:
>
> All,
> I have an Asus A88XM-E, and I am trying to install Coreboot on it.
>
> 1 ) The chip that came with the board says "GD25Q64(B)" (8192 kB, SPI). I 
> think the chip definitely broken somehow. Everytime I tried to flashrom, it 
> says
>
> Erasing and writing flash chip... FAILED at 0x! Expected=0xff, 
> Found=0x00, failed byte count from 0x-0x0fff: 0xd0c
>
> ERASE FAILED!
>
> when I tried sudo flashrom -w build/coreboot.rom --programmer ch341a_spi, it 
> says
>
> Verifying flash... FAILED at 0x! Expected=0x5f, Found=0xff, failed 
> byte count from 0x-0x007f: 0xb5
>
> Your flash chip is in an unknown state.
>
> I am having a hard time flashing back to original bios as well. Can I buy 
> W25Q64FVAIG to replace? The chip says GD25B64BP1G . Is that caused by using 5 
> V to be broken? I only performed flashrom -w and flashrom -r .
>
> 2) For configuration, I copied this configuration:
>
> https://review.coreboot.org/cgit/board-status.git/tree/asus/a88xm-e/4.12-3285-ga2118c7b54/2020-10-15T00_01_02Z/config.short.txt?
>
> to .config and added the board. I have exported the vga bios from Linux 
> using: cp /sys/devices/pci:00/:00:01.0/rom vgabios.bin .
>
> The above config does not work with make, it tries to go to a webpage for 
> secondary payload, and that webpage is changed. Removing those two lines 
> CONFIG_COREINFO_SECONDARY_PAYLOAD=y && CONFIG_TINT_SECONDARY_PAYLOAD=y will 
> let me build the rom. When I do sudo flashrom -w build/coreboot.rom 
> --programmer ch341a_spi, it sometimes says write done:
>
> Erasing and writing flash chip... Erase/write done.
>
> Verifying flash... FAILED at 0x! Expected=0x5f, Found=0xff, failed 
> byte count from 0x-0x007f: 0xb5
>
> Your flash chip is in an unknown state.
>
> When I boot with Coreboot, I see a black screen. I renamed vgabios.bin to 
> pci1002,990c.rom, and I put that file in the ~/Coreboot/ folder.
>
> Thanks for helping out,
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Segmentation error while compile Coreboot binary on branch 4.8.1

[Mike Banon]

Hi there Balazs, please tell why you'd need a 4.8.1 branch? Also you
may have to get some old LiveCD (i.e. CentOS 7 has both installation
DVD and a DVD with packages) and build the old coreboot under the
older Linux with everything older.

On Thu, Dec 24, 2020 at 12:03 PM Balázs Vinarz  wrote:
>
> Hi!
>
> Have you experienced anything like this while compiling from the branch 4.8.1?
> I have a fresh and a ~ 1 year old crossgcc pack, but both are end up
> after a make menuconfig ; make -j8 with the same way.
> In the latest crossgcc build, I had to apply an include string fix to
> binutils and a -Wl,--allow-multiple-definition to the acpica's
> LDFLAGS.
> 
> $ CC=/usr/bin/gcc make -d -j8
> GNU Make 4.3
> Built for x86_64-pc-linux-gnu
> Copyright (C) 1988-2020 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Reading makefiles...
> Reading makefile 'Makefile'...
> Reading makefile '/media/ramdisk/coreboot/util/kconfig/Makefile'
> (search path) (no ~ expansion)...
> Reading makefile '/media/ramdisk/coreboot/.config' (search path) (no ~
> expansion)...
> Reading makefile '.xcompile' (search path) (don't care) (no ~ expansion)...
> Reading makefile 'toolchain.inc' (search path) (no ~ expansion)...
> Reading makefile 'Makefile.inc' (search path) (don't care) (no ~ expansion)...
> Skipping submodule '3rdparty/blobs'
> Reading makefile 'util/crossgcc/Makefile.inc' (search path) (no ~ 
> expansion)...
> .
> .
> Reading makefile 'src/vendorcode/amd/pi/00670F00/Makefile.inc' (search
> path) (don't care) (no ~ expansion)...
> Segmentation error (core dumped)
> 
> $ dmesg | tail -1
> [30582.804975] make[750110]: segfault at 7fffb5d2dff8 ip
> 7fd105838cff sp 7fffb5d2e000 error 6 in
> libc-2.32.so[7fd1057d3000+14d000]
> [30582.804983] Code: 00 00 00 48 3b 1d 51 64 13 00 0f 82 ab 00 00 00
> 64 8b 04 25 18 00 00 00 85 c0 0f 85 23 01 00 00 48 89 ee 48 8d 3d 01
> 6d 13 00  cc e2 ff ff 49 89 c0 48 85 c0 0f 84 c8 00 00 00 48 8b 40
> f8 a8
> 
>
> Do you have any ideas? I'm using Arch Linux 5.9 with GCC 10.2
> I had a try on another machine with Arch Linux 4.19 LTS@GCC 10.2
>
> Thanks
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Max RAM problem

[Mike Banon]

Hi there Ale, two suggestions: 1) check this thread -
https://www.reddit.com/r/coreboot/comments/jdcn5y/latest_coreboot_for_the_asus_kcmad8/
, you may have to revert a specific commit for a fresher coreboot
build 2) try to backport my XMP / custom RAM timings patch to KGPE-D16
related sources and then artificially raise the custom timings, hoping
that would make your PC more bootable
https://review.coreboot.org/q/topic:%22AMD_XMP%22+(status:open%20OR%20status:merged)

On Tue, Dec 22, 2020 at 4:48 PM Ale via coreboot  wrote:
>
> Hello everyone,
> I have a kgpe d16 motherboard with coreboot and seabios, and 2 opteron 6282 
> SE processor with 64 gb of RAM: all the modules are 16 Gb hynix HMT42GR7AFR4C 
> - RD and all are inserted into the orange slots. The problem is, if I add 2 
> additional modules, inside the last 2 orange slots, the machine doesn't 
> starts and only black screen is shown, no log is detected over COM port. Any 
> suggestion? Maybe another RAM module configuration is needed, because I read 
> that 192 Gb of RAM is possible to obtain (I have followed the official Asus 
> manual for the RAM-Slots configuration)
>
> Thank you very much
> Best regards
> Ale
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Why a size of MPTABLE is limited by 600 bytes? Where this number comes from?

[Mike Banon]

Some boards, including my AMD Lenovo G505S laptop, have a MPTABLE size
which is slightly larger than 600, and I'm seeing the lines like

Skipping MPTABLE copy due to large size (628 bytes)

at the coreboot logs. Do you think MPTABLE size could be bumped to
i.e. 700 bytes, or there's some internal limitation which prevents
from doing this?

Best regards,
Mike Banon
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] nasm.us is currently down. temporary fix is to use fossies.org

[Mike Banon]

nasm is a part of coreboot's toolchain. For those who are in a hurry,
could open ./coreboot/util/crossgcc/buildgcc and replace a
NASM_ARCHIVE line with
NASM_ARCHIVE="https://fossies.org/linux/misc/nasm-${NASM_VERSION}.tar.bz2;
(its' checksum is going to be verified, so no trust issues)

Best regards,
Mike Banon
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Please could you review the XMP / custom RAM timings patches for AMD ?

[Mike Banon]

Patrick, thank you for good ideas, indeed they could be implemented in
the follow up commit. This patch has been tested relatively well
during these 6 months, so could be a good base for the following work.

P.S. Sorry for Jenkins spam - it has a "Failed to determine" error and
fails to build, but I guarantee that these patches build and work OK
on a coreboot master - tested it just yesterday.

https://review.coreboot.org/c/coreboot/+/40488
https://review.coreboot.org/c/coreboot/+/40489

>
> On Tue, Dec 1, 2020 at 11:51 PM Patrick Georgi  wrote:
>
> All of this is food for thought and may be suitable for follow-up work:
>
> The follow up commit provides AgesaCustomMemoryProfileSPD() for a manual 
> override. How about using that mechanism to select XMP1 or XMP2, too 
> (choosing functions that copy the values into the right spot instead of 
> changing the compiled-in offsets)?
>
> That way it would be easier to implement runtime selection and fallback 
> mechanisms (e.g. use an nvram value to select the profile and use boot_count 
> or "no XMP profile found" to fall back to a stable option)
>
>>
>> On Tue, Dec 1, 2020 at 11:27 PM Mike Banon  wrote:
>>
>> Dear friends,
>>
>> These patches are of a critical importance - they help to increase the
>> performance of AMD boards up to 20%. However, despite their small size
>> and simplicity, they are waiting for your review for more than 6
>> months already. :( And it's sad to see the "unofficial patches" list
>> of csb_patcher.sh growing. Please, could you take a look?
>>
>> https://review.coreboot.org/c/coreboot/+/40488
>> https://review.coreboot.org/c/coreboot/+/40489
>>
>> Best regards,
>> Mike Banon
>>
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Please could you review the XMP / custom RAM timings patches for AMD ?

[Mike Banon]

Dear friends,

These patches are of a critical importance - they help to increase the
performance of AMD boards up to 20%. However, despite their small size
and simplicity, they are waiting for your review for more than 6
months already. :( And it's sad to see the "unofficial patches" list
of csb_patcher.sh growing. Please, could you take a look?

https://review.coreboot.org/c/coreboot/+/40488
https://review.coreboot.org/c/coreboot/+/40489

Best regards,
Mike Banon
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: IRQ routing: how to do the mainboard_picr_data/_intr_data structures?

[Mike Banon]

Felix, thank you very much - this is exactly what I needed! Also now
found a "51192_Bolton_FCH_RRG.pdf" with slightly newer (but similar)
info.

Dear friends, thank you so much for your kind help! Now this important
work is completed for G505S
and you're welcome to take a look at
https://review.coreboot.org/c/coreboot/+/47852 .
Maybe we can fix the IRQs for some other AMD fam15h boards in a similar way.

Best regards,
Mike Banon


On Wed, Nov 18, 2020 at 2:14 AM Felix Held  wrote:
>
> Hi Mike!
>
> The PIRQ_MISC registers in the indirect I/O address space with 0xc00
> being the index register aren't IRQ numbers; those configuration bits.
> To get an idea, have a look at the interrupt routing register chapter of
> for example AMD publication number 45482 [1]. Not sure if that's the
> exact one you'll need, but it should be a good starting point.
>
> Regards
> Felix
>
> [1] https://www.amd.com/system/files/TechDocs/45482.pdf page 319
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: IRQ routing: how to do the mainboard_picr_data/_intr_data structures?

[Mike Banon]

Hi Nico, thank you very much for your kind help, it really helped to
advance! Please could you answer a small question:

While cleaning up some code I noticed there are Misc,Misc0,Misc1,Misc2
interrupts - with the following "magic" values respectively:

mainboard_picr_data:
[0x08] = 0x5A,0xF1,0x00,0x00,
mainboard_intr_data:
[0x08] = 0x00,0x00,0x00,0x00,

I tried replacing all these values by 0x1F ("unused") : the _intr_data
0x1F values got reverted to 0x00 during the boot time, while the
_picr_data 0x1F values stayed - but caused a SeaBIOS to hang while
booting (so I had to unbrick a laptop). Do you have any guess: from
where these 0x5A,0xF1,0x00,0x00 values for Misc interrupts come from,
and why are they essential for a SeaBIOS to work? Bolton FCH BIOS Dev
Guide doesn't tell anything about them, just mentions their offsets.

Best regards,
Mike

On Wed, Nov 11, 2020 at 2:43 AM Nico Huber  wrote:
>
> Hi Mike,
>
> On 10.11.20 19:22, Mike Banon wrote:
> > Thank you very much for your advice, dear Naresh, I will try matching
> > the UEFI routing.
>
> I wouldn't expect too much. If things are configurable in the chipset
> (they usually are these days) it's possible that coreboot configures
> them differently and then the tables have to differ too.
>
> >> this old "getpir" utility may help you ;)
> >> You may have to run:
> >> coreboot/util$ git revert 6c90f3334e65ff4b0ff4900df77bc33d53beb677
> >
> > What I already discovered:
> > *) To activate the irq_tables.c / intel_irq_routing_table code, I need
> > to enable CONFIG_HAVE_PIRQ_TABLE and CONFIG_GENERATE_PIRQ_TABLE. But I
> > don't see it having any visible effect on the IRQ routing: instead,
> > maybe this intel_irq_routing_table is supposed to be a reflection of
> > this routing?
>
> I would only give these things a look if you are 200% sure that you need
> it. Basically no major OS has used these in two decades, hence most of
> it in coreboot is untested and broken. I wouldn't be surprised if there
> isn't a single case of correct PIRQ tables in the tree.
>
> You should check what KolibriOS actually uses. If it's not ACPI there
> are these three options (that I know about):
>
> * MP table
> * PIRQ tables
> * INT_LINE registers in each PCI device' configuration space
>
> The latter is both exceptionally simple and fragile. It ignores that
> the OS could make any changes at runtime. The expected IRQ number for
> each PCI device is simply written into that register by the firmware.
> It's ignored by the hardware but can be read by the OS. Here's a
> simple example:
>
> * Assuming there's a device PCI 03:00.0 triggering PCI INTA.
> * The chipset is configured to translate that to PIRQ_B.
> * PIRQ_B is configured to trigger IRQ 4.
> * Then coreboot would just write 4 into INT_LINE of 03:00.0.
>
> The OS could then pick that 4 up and it would work as long as nothing
> changes the PIRQ configuration. As all the PIRQ information is lost,
> the OS can't optimize things; but KolibriOS probably wouldn't want to?
>
> > *) By adding to mainboard.c / mainboard_pirq_data structure these lines
> > {NB_PCIE_PORT3_DEVFN,{PIRQ_A, PIRQ_B, PIRQ_C, PIRQ_D}},/*
> > x4 PCIe:02.3 *//* 0:04.00 / 2:00.00 - IRQ 3 */
> > {NB_PCIE_PORT4_DEVFN,{PIRQ_A, PIRQ_B, PIRQ_C, PIRQ_D}},/*
> > x4 PCIe:02.4 *//* 0:05.00 / 3:00.00 - IRQ 3 */
> > I got the interrupts assigned to Ethernet 2:00.00 and WiFi 3:00.00
> > devices, which are behind the 0:04.00 and 0:05.00 bridges
> > respectively. And this assignment is even visible by KolibriOS now!
> > But I don't know if it's normal that a lot of devices are sharing the
> > same IRQ 3 now, is it bad?
>
> If sharing is bad depends on the type of devices. As long as they
> are all PCI devs, it should work (maybe not at maximum efficiency).
> But if, for instance, it's shared with a legacy UART port, that
> couldn't work (different mode of IRQ, level vs. edge triggered).
>
> I'm not 100% sure, but it seems that with these lines you can
> control how an interrupt INTA (/B/C/D) message (PCIe always uses
> in-band messages) is interpreted by the chipset. It looks like
> you tell it INTA (the most used one) will trigger PIRQ_A, INTB
> PIRQ_B, etc. If it's really configurable (otherwise I don't see
> why there should be such a table), you could try to shuffle these
> around. e.g.
>
> { NB_PCIE_PORT4_DEVFN, { PIRQ_B, PIRQ_C, PIRQ_D, PIRQ_A } },
>
>
>
> Hope that helps,
> Nico
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: IRQ routing: how to do the mainboard_picr_data/_intr_data structures?

[Mike Banon]

Thank you very much for your advice, dear Naresh, I will try matching
the UEFI routing.
Dear Elyes, huge thanks to you for telling me about "getpir" utility -
never heard about it before!

> this old "getpir" utility may help you ;)
> You may have to run:
> coreboot/util$ git revert 6c90f3334e65ff4b0ff4900df77bc33d53beb677

What I already discovered:
*) To activate the irq_tables.c / intel_irq_routing_table code, I need
to enable CONFIG_HAVE_PIRQ_TABLE and CONFIG_GENERATE_PIRQ_TABLE. But I
don't see it having any visible effect on the IRQ routing: instead,
maybe this intel_irq_routing_table is supposed to be a reflection of
this routing?
*) By adding to mainboard.c / mainboard_pirq_data structure these lines
{NB_PCIE_PORT3_DEVFN,{PIRQ_A, PIRQ_B, PIRQ_C, PIRQ_D}},/*
x4 PCIe:02.3 *//* 0:04.00 / 2:00.00 - IRQ 3 */
{NB_PCIE_PORT4_DEVFN,{PIRQ_A, PIRQ_B, PIRQ_C, PIRQ_D}},/*
x4 PCIe:02.4 *//* 0:05.00 / 3:00.00 - IRQ 3 */
I got the interrupts assigned to Ethernet 2:00.00 and WiFi 3:00.00
devices, which are behind the 0:04.00 and 0:05.00 bridges
respectively. And this assignment is even visible by KolibriOS now!
But I don't know if it's normal that a lot of devices are sharing the
same IRQ 3 now, is it bad?

*) For a moment I thought that only _pirq_data structure matters, and
set the contains of picr_data/_intr_data to all 0x1F to check this
though. But a laptop can't boot with such a change ;-)

What I have trouble understanding:
what is the relationship between mainboard_picr_data/_intr_data,
_pirq_data, and intel_irq_routing_table?
If I got the intel_irq_routing_table with getpir - how to convert its'
contents to these other tables so that they match each other?

Best regards,
Mike Banon





On Tue, Nov 10, 2020 at 5:52 PM Naresh G. Solanki
 wrote:
>
> Hi Mike,
>
> I see that IRQ routing that you set in Coreboot is different then that in 
> UEFI bios.
> I recommend you first try to match them.
> Required data is already available in the dump you took.
>
> Also this link can be of help:
> https://gist.github.com/mcastelino/4acda7c2407f1c51e68f3f994d8ffc98
>
> IRQ routing is mandatory for non-MSI capable devices so make sure you best 
> match them with UEFI bios for now.
>
> There might be some other issues other than IRQ routing but you can focus on 
> them later as they dont seem critical.
>
> Please let me know how it goes.
>
> Regards,
> Naresh G Solanki
>
> On Mon, Nov 9, 2020 at 7:43 PM Mike Banon  wrote:
>>
>> Dear Naresh, please check the attached archive for these files (and
>> tell if there's anything else I need to show)
>>
>> On Thu, Nov 5, 2020 at 8:08 PM Naresh G. Solanki
>>  wrote:
>> >
>> > Can you give following output with coreboot and OEM bios.
>> > lspci -vvvk
>> > dmesg
>> > cat /proc/interrupt
>> >
>> >
>> > On Thu, 5 Nov, 2020, 6:29 pm Mike Banon,  wrote:
>> >>
>> >> Still need your help, friend
>> >>
>> >> On Sat, Oct 24, 2020 at 11:15 AM Mike Banon  wrote:
>> >> >
>> >> > Although I found this article
>> >> > https://www.coreboot.org/Creating_Valid_IRQ_Tables , I'm not sure if
>> >> > it applies to mainboard_picr_data/_intr_data : considering a problem
>> >> > from my previous msg - where a copy-paste of old picr/intr data
>> >> > structures gave the bad results. Could you please clarify if this
>> >> > article is still valid for these new data structures? If not, how to
>> >> > get the correct values for mainboard_picr_data/_intr_data using Linux?
>> >> >
>> >> >
>> >> > On Tue, Oct 20, 2020 at 6:23 PM Mike Banon  wrote:
>> >> > >
>> >> > > Dear friends, I'm trying to properly program the IRQ tables for Lenovo
>> >> > > G505S, because the old IRQ routing is bad and doesn't work for a
>> >> > > simple OS like Kolibri. Full details are in the comments under this
>> >> > > change:
>> >> > >
>> >> > > https://review.coreboot.org/c/coreboot/+/46587/
>> >> > >
>> >> > > When I used the old picr_data/intr_data values of G505S for the new
>> >> > > structures, I got only 1 IRQ working. However, with a copy-paste of
>> >> > > AM1I-A - surprisingly 12 IRQs and a laptop boots, but still some
>> >> > > problems. Please advise how to compose mainboard_picr_data/_intr_data
>> >> > > and also a intel_irq_routing_table, your help will be very much
>> >> > > appreciated.
>> >> > >
>> >> > > Best regards,
>> >> > > Mike Banon
>> >> ___
>> >> coreboot mailing list -- coreboot@coreboot.org
>> >> To unsubscribe send an email to coreboot-le...@coreboot.org
>
>
>
> --
> Best regards,
> Naresh G. Solanki
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: IRQ routing: how to do the mainboard_picr_data/_intr_data structures?

[Mike Banon]

Dear Naresh, please check the attached archive for these files (and
tell if there's anything else I need to show)

On Thu, Nov 5, 2020 at 8:08 PM Naresh G. Solanki
 wrote:
>
> Can you give following output with coreboot and OEM bios.
> lspci -vvvk
> dmesg
> cat /proc/interrupt
>
>
> On Thu, 5 Nov, 2020, 6:29 pm Mike Banon,  wrote:
>>
>> Still need your help, friend
>>
>> On Sat, Oct 24, 2020 at 11:15 AM Mike Banon  wrote:
>> >
>> > Although I found this article
>> > https://www.coreboot.org/Creating_Valid_IRQ_Tables , I'm not sure if
>> > it applies to mainboard_picr_data/_intr_data : considering a problem
>> > from my previous msg - where a copy-paste of old picr/intr data
>> > structures gave the bad results. Could you please clarify if this
>> > article is still valid for these new data structures? If not, how to
>> > get the correct values for mainboard_picr_data/_intr_data using Linux?
>> >
>> >
>> > On Tue, Oct 20, 2020 at 6:23 PM Mike Banon  wrote:
>> > >
>> > > Dear friends, I'm trying to properly program the IRQ tables for Lenovo
>> > > G505S, because the old IRQ routing is bad and doesn't work for a
>> > > simple OS like Kolibri. Full details are in the comments under this
>> > > change:
>> > >
>> > > https://review.coreboot.org/c/coreboot/+/46587/
>> > >
>> > > When I used the old picr_data/intr_data values of G505S for the new
>> > > structures, I got only 1 IRQ working. However, with a copy-paste of
>> > > AM1I-A - surprisingly 12 IRQs and a laptop boots, but still some
>> > > problems. Please advise how to compose mainboard_picr_data/_intr_data
>> > > and also a intel_irq_routing_table, your help will be very much
>> > > appreciated.
>> > >
>> > > Best regards,
>> > > Mike Banon
>> ___
>> coreboot mailing list -- coreboot@coreboot.org
>> To unsubscribe send an email to coreboot-le...@coreboot.org


cmp.tar.gz
Description: application/gzip
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: IRQ routing: how to do the mainboard_picr_data/_intr_data structures?

[Mike Banon]

Still need your help, friend

On Sat, Oct 24, 2020 at 11:15 AM Mike Banon  wrote:
>
> Although I found this article
> https://www.coreboot.org/Creating_Valid_IRQ_Tables , I'm not sure if
> it applies to mainboard_picr_data/_intr_data : considering a problem
> from my previous msg - where a copy-paste of old picr/intr data
> structures gave the bad results. Could you please clarify if this
> article is still valid for these new data structures? If not, how to
> get the correct values for mainboard_picr_data/_intr_data using Linux?
>
>
> On Tue, Oct 20, 2020 at 6:23 PM Mike Banon  wrote:
> >
> > Dear friends, I'm trying to properly program the IRQ tables for Lenovo
> > G505S, because the old IRQ routing is bad and doesn't work for a
> > simple OS like Kolibri. Full details are in the comments under this
> > change:
> >
> > https://review.coreboot.org/c/coreboot/+/46587/
> >
> > When I used the old picr_data/intr_data values of G505S for the new
> > structures, I got only 1 IRQ working. However, with a copy-paste of
> > AM1I-A - surprisingly 12 IRQs and a laptop boots, but still some
> > problems. Please advise how to compose mainboard_picr_data/_intr_data
> > and also a intel_irq_routing_table, your help will be very much
> > appreciated.
> >
> > Best regards,
> > Mike Banon
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: IRQ routing: how to do the mainboard_picr_data/_intr_data structures?

[Mike Banon]

Although I found this article
https://www.coreboot.org/Creating_Valid_IRQ_Tables , I'm not sure if
it applies to mainboard_picr_data/_intr_data : considering a problem
from my previous msg - where a copy-paste of old picr/intr data
structures gave the bad results. Could you please clarify if this
article is still valid for these new data structures? If not, how to
get the correct values for mainboard_picr_data/_intr_data using Linux?


On Tue, Oct 20, 2020 at 6:23 PM Mike Banon  wrote:
>
> Dear friends, I'm trying to properly program the IRQ tables for Lenovo
> G505S, because the old IRQ routing is bad and doesn't work for a
> simple OS like Kolibri. Full details are in the comments under this
> change:
>
> https://review.coreboot.org/c/coreboot/+/46587/
>
> When I used the old picr_data/intr_data values of G505S for the new
> structures, I got only 1 IRQ working. However, with a copy-paste of
> AM1I-A - surprisingly 12 IRQs and a laptop boots, but still some
> problems. Please advise how to compose mainboard_picr_data/_intr_data
> and also a intel_irq_routing_table, your help will be very much
> appreciated.
>
> Best regards,
> Mike Banon
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] IRQ routing: how to do the mainboard_picr_data/_intr_data structures?

[Mike Banon]

Dear friends, I'm trying to properly program the IRQ tables for Lenovo
G505S, because the old IRQ routing is bad and doesn't work for a
simple OS like Kolibri. Full details are in the comments under this
change:

https://review.coreboot.org/c/coreboot/+/46587/

When I used the old picr_data/intr_data values of G505S for the new
structures, I got only 1 IRQ working. However, with a copy-paste of
AM1I-A - surprisingly 12 IRQs and a laptop boots, but still some
problems. Please advise how to compose mainboard_picr_data/_intr_data
and also a intel_irq_routing_table, your help will be very much
appreciated.

Best regards,
Mike Banon
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: ASUS A88XM-E internal flashing

[Mike Banon]

maybe Balazs could advise. However, to make sure you could easily
unbrick your A88XM-E in the case of a bad coreboot build, I really
recommend you to order a cheap USB CH341A programmer (preferably with
a Green PCB) - and PLCC clip to easily remove a DIP8 flash chip from a
motherboard's socket without bending the chip's legs. Then, you'll be
able to easily install a new coreboot image by plugging a DIP8 flash
chip into the programmer's socket and using the opensource flashrom
tool.

On Fri, Oct 16, 2020 at 10:04 AM mejim67741--- via coreboot
 wrote:
>
> The documentation says
>
> The main SPI flash can be accessed using flashrom, if the AmdSpiRomProtect 
> modules have been deleted in the factory image previously.
>
> So what does that mean? How can i do that? I would like to flash it internal
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Bios Corrupted

[Mike Banon]

Sadly, this DCL X4 is some local crappy "brand" without a proper place
for downloading the BIOS files. So, you could either contact DCL
directly (while this company still exists) and ask them for a BIOS
image. Or find someone else with the same laptop and ask them to dump
their BIOS. Searching by the BIOS version (NX300KSZ.05), I've found at
least one person -
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1877009 , could
contact them directly at launchpad and ask for help.

On Wed, Oct 7, 2020 at 1:05 PM Miraz Shuvra
 wrote:
>
> Yes sir ,
>
> hardware model : DCL X4
> DCL is for Daffodil Computers Limited
> X4 is the model
>
> It was running with,
> processor intel core i3 7th gen
> RAM single slot 4gb DDR4
> no optical drive
>
>
> On Wed, Oct 7, 2020, 3:46 PM Mike Banon  wrote:
>>
>> Could you at least tell us, what's the hardware model of your laptop?
>> You may be able to extract a good BIOS image from the "BIOS image"
>> utility provided by the manufacturer of your laptop. I.e. in my case,
>> I opened a winflash exe with 7zip, found many files including a large
>> binary file, opened it in a hex editor and found the right offset from
>> where to start cutting a BIOS image.
>>
>> On Wed, Oct 7, 2020 at 12:24 PM Miraz Shuvra
>>  wrote:
>> >
>> > I've surely collected the following information
>> >
>> > serial : 20B8EF2B
>> > BIOS Brand: AMI bios
>> > BIOS Version: NX300KSZ.05
>> >
>> >
>> > On Mon, Oct 5, 2020 at 10:36 AM Miraz Shuvra 
>> >  wrote:
>> >>
>> >> actually im not sure about all these ...
>> >>
>> >> I'm successful to collect the attached bin file from the bios chip using 
>> >> the mini programmer
>> >>
>> >> On Mon, Oct 5, 2020 at 2:28 AM Christian Walter 
>> >>  wrote:
>> >>>
>> >>> Hi Miraz,
>> >>> What laptop/mainboard are you running?
>> >>>
>> >>> Best,
>> >>> Chris
>> >>>
>> >>> Von meinem iPhone gesendet
>> >>>
>> >>> > Am 04.10.2020 um 22:19 schrieb Miraz Shuvra 
>> >>> > :
>> >>> >
>> >>> > 
>> >>> > Hello sir ,
>> >>> >
>> >>> >
>> >>> > I need a little bit help
>> >>> >
>> >>> > I accidentally corrupted bios of my laptop during bios update
>> >>> > ...before it blackout... i saw the txt .." searching for bios firmware 
>> >>> > ... bios firmware not found "
>> >>> >
>> >>> > I baught a ch341A usb bios programming device ...
>> >>> > I think a .bin file may bring my laptop back to life.
>> >>> >
>> >>> > My laptop ran with ami bios
>> >>> > The bios chip is 25Q80DVS IG 1646
>> >>> >
>> >>> > Can you pls help me anyway.
>> >>> > ___
>> >>> > coreboot mailing list -- coreboot@coreboot.org
>> >>> > To unsubscribe send an email to coreboot-le...@coreboot.org
>> >
>> > ___
>> > coreboot mailing list -- coreboot@coreboot.org
>> > To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Bios Corrupted

[Mike Banon]

Could you at least tell us, what's the hardware model of your laptop?
You may be able to extract a good BIOS image from the "BIOS image"
utility provided by the manufacturer of your laptop. I.e. in my case,
I opened a winflash exe with 7zip, found many files including a large
binary file, opened it in a hex editor and found the right offset from
where to start cutting a BIOS image.

On Wed, Oct 7, 2020 at 12:24 PM Miraz Shuvra
 wrote:
>
> I've surely collected the following information
>
> serial : 20B8EF2B
> BIOS Brand: AMI bios
> BIOS Version: NX300KSZ.05
>
>
> On Mon, Oct 5, 2020 at 10:36 AM Miraz Shuvra  
> wrote:
>>
>> actually im not sure about all these ...
>>
>> I'm successful to collect the attached bin file from the bios chip using the 
>> mini programmer
>>
>> On Mon, Oct 5, 2020 at 2:28 AM Christian Walter 
>>  wrote:
>>>
>>> Hi Miraz,
>>> What laptop/mainboard are you running?
>>>
>>> Best,
>>> Chris
>>>
>>> Von meinem iPhone gesendet
>>>
>>> > Am 04.10.2020 um 22:19 schrieb Miraz Shuvra 
>>> > :
>>> >
>>> > 
>>> > Hello sir ,
>>> >
>>> >
>>> > I need a little bit help
>>> >
>>> > I accidentally corrupted bios of my laptop during bios update
>>> > ...before it blackout... i saw the txt .." searching for bios firmware 
>>> > ... bios firmware not found "
>>> >
>>> > I baught a ch341A usb bios programming device ...
>>> > I think a .bin file may bring my laptop back to life.
>>> >
>>> > My laptop ran with ami bios
>>> > The bios chip is 25Q80DVS IG 1646
>>> >
>>> > Can you pls help me anyway.
>>> > ___
>>> > coreboot mailing list -- coreboot@coreboot.org
>>> > To unsubscribe send an email to coreboot-le...@coreboot.org
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Operating Systems for coreboot/flashrom/etc?

[Mike Banon]

Although not exactly on topic, this patch [1] contains a list of
Floppy-based OS that could be run by SeaBIOS from a coreboot's CBFS.
Even a PicoBSD is possible, if you have the skills to build it (quite
tricky to be honest).

https://review.coreboot.org/c/coreboot/+/33509


On Tue, Sep 29, 2020 at 10:48 PM Clay Daniels  wrote:
>
> I am a big FreeBSD fan, and also run NetBSD on an older machine. Haven't used 
> much Linux lately but installed Ubuntu to get a lspci for flashrom use. 
> Ubuntu is fine, but does not have superiotool available as best I see. 
> Looking back to FreeBSD I found superiotool just where I expected, as a port 
> to be compiled under sysutils. Works fine, but still never finds my hidden 
> bios I will call "SPI1" for lack of a better name.
>
> Anyway, I keep looking for more tools, and have an extra disk drive for 
> another OS if anyone has any good suggestions?
>
> Right now I'm in Ubuntu, listening to the coreboot & flashrom freenode IRC 
> channels. Quite a lot goes on there if you catch it right. Some real sharp 
> guys.
>
> Clay
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] ASAN-related build error at coreboot master

[Mike Banon]

Could be temporarily fixed by changing uintptr_t to unsigned int * :

...
GENbuild.h
CC bootblock/arch/x86/id.o
CC bootblock/arch/x86/memcpy.o
In file included from src/arch/x86/memcpy.c:5:
src/include/asan.h:63:1: error: unknown type name 'uintptr_t'; did you
mean 'wint_t'?
 uintptr_t __asan_shadow_offset(uintptr_t addr);
 ^
 wint_t
src/include/asan.h:63:32: error: unknown type name 'uintptr_t'; did
you mean 'wint_t'?
 uintptr_t __asan_shadow_offset(uintptr_t addr);
^
wint_t
cc1: error: unrecognized command line option
'-Wno-address-of-packed-member' [-Werror]
cc1: all warnings being treated as errors
make: *** [Makefile:362: build/bootblock/arch/x86/memcpy.o] Error 1
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: F2A85-M - amdgpu fails, integrated GPU works fine

[Mike Banon]

dGPU performance should be indifferent of a BIOS being used. Are you
confident that your program is really using a discrete GPU and not an
integrated one (with a poor performance in comparison). To ensure
this, please double check you're running it with DRI_PRIME=1 flag. One
of the easiest ways to test - is supertuxkart: it prints the logs
about a GPU being used and has a FPS counter. You should be able to
run it at 60 fps on ultra settings on a discrete GPU, while an
integrated one isn't that strong.

On Tue, Jul 14, 2020 at 2:14 PM Grzegorz Bogdał
 wrote:
>
> Hi, this time I'm using Debian testing. Drivers shouldn't be a problem since 
> I get drastically different results on the same hardware/software 
> combination, the only difference being different BIOS chip plugged in(F2-A85m 
> allows to swap them easily). One chip has proprietary BIOS, second one 
> Coreboot.
>
>
> 14 Jul 2020, 11:57 by mikeb...@gmail.com:
>
> Hi Grzegorz , please remind what Linux distro you're using and how
> fresh is its' drivers/software. AMD drivers really improved during the
> last couple of years, but if you're running some ancient "debian" - of
> course GPU performance is lower than expected. Myself, I'm currently
> using Artix Linux - while it has a really fresh software (just like
> Arch), it almost never breaks, and doesn't have a SystemD (good for
> you if you don't like it as well).
>
> On Mon, Jul 6, 2020 at 11:39 PM Grzegorz Bogdał
>  wrote:
>
>
> Sorry, I've been overeager with that report. GPU initializes and is good for 
> desktop use, but the performance in games is abysmal
>
>
> 6 Jul 2020, 20:56 by bogdal.grzeg...@tutanota.com:
>
> It took a while, but I've flashed coreboot from newest master on F2-A85m+RX 
> 570 and it works. Great stuff, thank you for your work: )
>
>
> 13 Jan 2020, 17:28 by mikeb...@gmail.com:
>
> Jan 12, 2020, 14:43 by mikeb...@gmail.com:
>
> Solution for your coreboot + discrete GPU problems like
>
> amdgpu kernel bo map failed [...] error -22
> amdgpu_vram_scratch_init failed [...] error -22
> fatal error in GPU initialization
>
> It turned out that a fix like
> https://review.coreboot.org/c/coreboot/+/38215 ( /* Set to 0xD0
> instead of 0xE0 to avoid the PCI resource allocation problems. */
> InitPost->MemConfig.BottomIo = 0xD0; // at the beginning of
> board_BeforeInitPost function at board's OemCustomize.c ) that worked
> for HD6670, is not enough for a huge RX590 - which is huge in all
> relations, but most importantly the memory ranges!
>
> To get RX590 working with ASUS A88XM-E, I had to decrease a BottomIo
> even further - to 0xC0 - and also to reduce the
> BLDCFG_UMA_ALLOCATION_SIZE at board's buildOpts.c from 0x2000 (512MB)
> to 0x1000 (256MB), - to get this extra "0xD0-0xC0"=0x1000 room.
> And then it worked perfectly, at least with DRI_PRIME=1 ./Supertuxkart
> GPU offloading: ultra settings on integrated - 4 or 5 fps, with
> offloading - 60 fps. I'm sure this fix will work for your other RX 5**
> as well, but don't know if I should be trying to commit it to master,
> since it lowers the integrated GPU's shared memory.
>
> RX590 is the most powerful AMD GPU which does not contain a Platform
> Security Processor aka PSP (yes, they've started adding this crap to
> the GPUs as well, and newer Vega / RX 5*** are all contaminated - see
> for yourself at freedesktop drm/amdgpu sources) . That's why it was
> really important to get RX590 working. So happy it was possible,
> thanks to you all ;-)
>
> On Mon, Jan 13, 2020 at 2:21 AM Grzegorz Bogdał 
>  wrote:
> Great job!: ) So, A10-6800k/FX-8xxx combined with RX 590 is probably the 
> strongest x86 desktop without PSP/ME that we'll get in this reality?
>
>
> Yes, if you meant x86 desktop "supported by coreboot master" -
> regarding the CPUs ;-) Otherwise there is a supported-by-coreboot-4.11
> M5A88-V motherboard with AM3+ (maybe can put FX-9590 there, if
> coreboot supports and without frying it?) and KGPE-D16 with its' two
> Opterons 6386 SE for a large desktop. Also, PDF [link 1] at page 12
> says Carrizo is the "1st ARM Trustzone Capable Performance APU", that
> means Kaveri and its' refresh Godavari (i.e. A10-7890K) doesn't have a
> PSP. A88XM-E motherboard is FM2+ socket, so theoretically it could
> support Godavari A10-7890K. However Balazs wrote that AGESA of Kaveri
> is a blob (not good!) and there's uncertainty if could get it working
> without getting this APU for trying.
>
> As you see, there are CPUs more powerful than A10-6800K which don't
> have a PSP crap but their coreboot master support is questionable. And
> don't want to be without coreboot, since UEFI could have many holes
> and stuff like Computrace which doesn't need to rely on ME/PSP to
> function. So yes, A10-6800K seems to be the best at the moment. I got
> A10-6700 only because its' quite hard to find a new A10-6800K for a
> reasonable price and I read about bad overclockers who played too much
> with core voltages and cores deteriorate, becoming 

[coreboot] Re: How newbie can contribute to the project as developper

[Mike Banon]

I think, first of all you need to either get a coreboot-supported
motherboard, or a motherboard the components of which are similar
enough to those already supported by coreboot and try to get this
board supported. Then you could: i.e. check what is working on this
board and try to fix what doesn't, or dig into some "more universal"
things that benefit all the coreboot boards. Because: although you
could still build a coreboot+SeaBIOS for QEMU and run it there, it's
not a real hardware and the scope of things which you could improve -
is more limited with QEMU (although it's still a great thing when you
i.e. would like to improve some SeaBIOS part or anything else
"universal")

On Fri, Jul 3, 2020 at 5:53 PM Tim Wawrzynczak  wrote:
>
> Hello,
>
> Just to double check, you are definitely not cloning the repository in 
> Windows?  Someone mentioned to me that 'con' is an invalid file or directory 
> name on Windows and I forgot to update that.  I can push a patch for that 
> today.
>
> Cheers,
> Tim
>
> On Fri, Jul 3, 2020, 8:06 AM NJONGSSI KOUAM Esaïe Ledoux 
>  wrote:
>>
>> Yes  have some problem with some test to getting started :
>>
>> git clone https://review.coreboot.org/coreboot coreboot
>> Clonage dans 'coreboot'...
>> remote: Counting objects: 637, done
>> remote: Finding sources: 100% (623/623)
>> remote: Total 553974 (delta 86), reused 553737 (delta 86)
>> Réception d'objets: 100% (553974/553974), 142.97 Mio | 1.51 Mio/s, fait.
>> Résolution des deltas: 100% (421681/421681), fait.
>> fatal: cannot create directory at 'src/drivers/intel/pmc_mux/con': Argument 
>> invalide
>> warning: Le clone a réussi, mais l'extraction a échoué.
>> Vous pouvez inspecter ce qui a été extrait avec 'git status'
>> et réessayer avec 'git restore --source=HEAD :/'
>>
>>
>> My system is kali linux , ... wich step can i allow it ?? please
>> can you give me some instruction step by step ...??
>> ___
>> coreboot mailing list -- coreboot@coreboot.org
>> To unsubscribe send an email to coreboot-le...@coreboot.org
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: F2A85-M - amdgpu fails, integrated GPU works fine

[Mike Banon]

Hi Grzegorz , please remind what Linux distro you're using and how
fresh is its' drivers/software. AMD drivers really improved during the
last couple of years, but if you're running some ancient "debian" - of
course GPU performance is lower than expected. Myself, I'm currently
using Artix Linux - while it has a really fresh software (just like
Arch), it almost never breaks, and doesn't have a SystemD (good for
you if you don't like it as well).

On Mon, Jul 6, 2020 at 11:39 PM Grzegorz Bogdał
 wrote:
>
> Sorry, I've been overeager with that report. GPU initializes and is good for 
> desktop use, but the performance in games is abysmal
>
>
> 6 Jul 2020, 20:56 by bogdal.grzeg...@tutanota.com:
>
> It took a while, but I've flashed coreboot from newest master on F2-A85m+RX 
> 570 and it works. Great stuff, thank you for your work: )
>
>
> 13 Jan 2020, 17:28 by mikeb...@gmail.com:
>
> Jan 12, 2020, 14:43 by mikeb...@gmail.com:
>
> Solution for your coreboot + discrete GPU problems like
>
> amdgpu kernel bo map failed [...] error -22
> amdgpu_vram_scratch_init failed [...] error -22
> fatal error in GPU initialization
>
> It turned out that a fix like
> https://review.coreboot.org/c/coreboot/+/38215 ( /* Set to 0xD0
> instead of 0xE0 to avoid the PCI resource allocation problems. */
> InitPost->MemConfig.BottomIo = 0xD0; // at the beginning of
> board_BeforeInitPost function at board's OemCustomize.c ) that worked
> for HD6670, is not enough for a huge RX590 - which is huge in all
> relations, but most importantly the memory ranges!
>
> To get RX590 working with ASUS A88XM-E, I had to decrease a BottomIo
> even further - to 0xC0 - and also to reduce the
> BLDCFG_UMA_ALLOCATION_SIZE at board's buildOpts.c from 0x2000 (512MB)
> to 0x1000 (256MB), - to get this extra "0xD0-0xC0"=0x1000 room.
> And then it worked perfectly, at least with DRI_PRIME=1 ./Supertuxkart
> GPU offloading: ultra settings on integrated - 4 or 5 fps, with
> offloading - 60 fps. I'm sure this fix will work for your other RX 5**
> as well, but don't know if I should be trying to commit it to master,
> since it lowers the integrated GPU's shared memory.
>
> RX590 is the most powerful AMD GPU which does not contain a Platform
> Security Processor aka PSP (yes, they've started adding this crap to
> the GPUs as well, and newer Vega / RX 5*** are all contaminated - see
> for yourself at freedesktop drm/amdgpu sources) . That's why it was
> really important to get RX590 working. So happy it was possible,
> thanks to you all ;-)
>
> On Mon, Jan 13, 2020 at 2:21 AM Grzegorz Bogdał 
>  wrote:
> Great job!: ) So, A10-6800k/FX-8xxx combined with RX 590 is probably the 
> strongest x86 desktop without PSP/ME that we'll get in this reality?
>
>
> Yes, if you meant x86 desktop "supported by coreboot master" -
> regarding the CPUs ;-) Otherwise there is a supported-by-coreboot-4.11
> M5A88-V motherboard with AM3+ (maybe can put FX-9590 there, if
> coreboot supports and without frying it?) and KGPE-D16 with its' two
> Opterons 6386 SE for a large desktop. Also, PDF [link 1] at page 12
> says Carrizo is the "1st ARM Trustzone Capable Performance APU", that
> means Kaveri and its' refresh Godavari (i.e. A10-7890K) doesn't have a
> PSP. A88XM-E motherboard is FM2+ socket, so theoretically it could
> support Godavari A10-7890K. However Balazs wrote that AGESA of Kaveri
> is a blob (not good!) and there's uncertainty if could get it working
> without getting this APU for trying.
>
> As you see, there are CPUs more powerful than A10-6800K which don't
> have a PSP crap but their coreboot master support is questionable. And
> don't want to be without coreboot, since UEFI could have many holes
> and stuff like Computrace which doesn't need to rely on ME/PSP to
> function. So yes, A10-6800K seems to be the best at the moment. I got
> A10-6700 only because its' quite hard to find a new A10-6800K for a
> reasonable price and I read about bad overclockers who played too much
> with core voltages and cores deteriorate, becoming unstable even at
> stock speeds (so one needs to underclock then). A10-6700 is the most
> powerful with a locked multiplier, so less attractive to overclockers
> and may be safer to buy used.
>
> GPUs: yes, RX590 is the most powerful GPU without PSP ! (not
> considering NVidia at all because of their proprietary driver tricks
> and hostility towards the opensource) . Although there is RX600 series
> [link 2], they are hard to buy and lower performance. Unlike the
> majority of people (who don't care about performance), I actually
> hoped there would be another refresh of Polaris architecture - simply
> because no PSP, but doesn't seem there would be more Polaris high end
> GPUs at the moment.
>
> As for the most powerful RX590, I suggest those which have 8400MHz
> memory by default - i.e. Sapphire Nitro+ parts. For myself I got a
> cute [link 3] SKU 11289-07-20G aka "Sapphire Nitro+ RX 590 8GB AMD
> 50th Anniversary Gold Edition" (golden shroud) 

[coreboot] Re: Lenovo R500

[Mike Banon]

It's a bit not obvious, but by searching at
./coreboot/src/mainboard/lenovo$ find . -type f -print0 | xargs -0
grep -n "R500" - I could see that R500 is a variant of Thinkpad
T400: i.e. " ./t400/Kconfig.name:10:config BOARD_LENOVO_R500 " . Since
this board_status table mentions each board type once, only T400
appears there.

So your R500 is supported by coreboot, almost certainly blobless.
coreboot's installation is identical to libreboot: you simply flash a
compiled BIOS image. Tool to change a mac address: I haven't checked
if it could be found in ./coreboot/util/ - but almost certainly a
libreboot's tool should be compatible with coreboot, and maybe
libreboot project took this tool from somewhere else where there's an
even newer version

On Tue, Jun 16, 2020 at 11:41 AM trabajo3 via coreboot
 wrote:
>
> Hello!, I wantt to know if the Lenovo R500 has coreboot support without any 
> blobs
> https://phoronix.com/scan.php?page=news_item=Coreboot-4.10-Released
> Here it says that is supported
> but
> https://coreboot.org/status/board-status.html
> doesnt appear
> and in the tree also no
>
> Another question is if there is any tool like in the libreboot proyect to 
> change mac address and if there is any complete video tutorial to install 
> libreboot, because in youtube there are full videos about libreboot but for 
> coreboot i didnt find anyone with good explanation.
> Thanks for ur time!
> Best Regards
>
>
> Sent with ProtonMail Secure Email.
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Resource allocator: multiple boards regression

[Mike Banon]

Hi again Furquan, happy to tell you that both f15tn A88XM-E and f16kb
AM1I-A - boot fine with this chain of changes applied on top of
master. Thank you a lot, I'm going to review it soon. Hopefully later
we'll come up with a solution better than my weird
https://review.coreboot.org/c/coreboot/+/41431 - I'll happily test any
proposed changes aimed on fixing a V4 allocator for these
chipsets/boards.

On Sat, May 16, 2020 at 2:41 AM Furquan Shaikh
 wrote:
>
> Hello MIke,
>
> IIUC, there are more things that will have to be looked at closely and
> reworked for the impacted AMD chipsets. As per the discussion on the
> IRC channel, I have prepared a patch series which does the following:
>
> - Revert the new resource allocator changes:
> https://review.coreboot.org/c/coreboot/+/41411
> https://review.coreboot.org/c/coreboot/+/41412
> https://review.coreboot.org/c/coreboot/+/41413
>
> - Split old resource allocator into its separate unit:
> https://review.coreboot.org/c/coreboot/+/41442
>
> - Reland new allocator guarded by a Kconfig:
> https://review.coreboot.org/c/coreboot/+/41443
>
> - Select old allocator for impacted chipsets and enable new allocator
> for all other boards:
> https://review.coreboot.org/c/coreboot/+/41444
> https://review.coreboot.org/c/coreboot/+/41445
>
> This should give us some more time to fix the impacted chipsets and
> keep the boards working in upstream.
>
> On Fri, May 15, 2020 at 11:11 AM Mike Banon  wrote:
> >
> > UPDATE: fam15tn A88XM-E is booting well if all 3 fixes applied
> > together with this patch above (separately not enough to get it
> > working) - tested it enough. However, when I tried a similar fix for
> > fam16kb AM1I-A - it got stuck in a boot loop (see the attached log).
> > Maybe I'm doing something wrong and it worked for fam15tn just by a
> > coincidence. Please take a look at change for a further review
> > https://review.coreboot.org/c/coreboot/+/41431
> >
> > On Fri, May 15, 2020 at 1:30 PM Mike Banon  wrote:
> > >
> > > Looking at your change 41369 - soc/amd/stoneyridge: add resources
> > > during read_resources() - I tried to do a similar style change on top
> > > of your 3 fixes above, and surprisingly it worked at first try - now
> > > I'm able to see the boot devices and floppies. New bootlog is
> > > attached. After testing it more (should be able to boot 100% of times)
> > > I'm going to submit it to review coreboot org soon, for your review -
> > > and also we will need to do a similar change for family14 and
> > > family16kb if this one succeeds.
> > >
> > > diff --git a/src/northbridge/amd/agesa/family15tn/northbridge.c
> > > b/src/northbridge/amd/agesa/family15tn/northbridge.c
> > > index 9d41e7a1f1..0194ea82ea 100644
> > > --- a/src/northbridge/amd/agesa/family15tn/northbridge.c
> > > +++ b/src/northbridge/amd/agesa/family15tn/northbridge.c
> > > @@ -666,6 +666,8 @@ static void domain_set_resources(struct device *dev)
> > > u32 reset_memhole = 1;
> > >  #endif
> > >
> > > +   domain_read_resources(dev);
> > > +
> > > pci_tolm = 0xUL;
> > > for (link = dev->link_list; link; link = link->next) {
> > > pci_tolm = find_pci_tolm(link);
> > > @@ -749,17 +751,18 @@ static void domain_set_resources(struct device *dev)
> > > }
> > >
> > > add_uma_resource_below_tolm(dev, 7);
> > > -
> > > +/*
> > > for (link = dev->link_list; link; link = link->next) {
> > > if (link->children) {
> > > assign_resources(link);
> > >     }
> > > }
> > > +*/
> > >  }
> > >
> > >  static struct device_operations pci_domain_ops = {
> > > -   .read_resources   = domain_read_resources,
> > > -   .set_resources= domain_set_resources,
> > > +   .read_resources   = domain_set_resources,
> > > +   .set_resources= pci_domain_set_resources,
> > > .scan_bus = pci_domain_scan_bus,
> > >  };
> > >
> > >
> > > On Fri, May 15, 2020 at 12:10 PM Mike Banon  wrote:
> > > >
> > > > Although it's still the same result even with three changes (either
> > > > can't boot or no boot devices, randomly) - there is a positive effect
> > > > that USB FT232H log now 't stop and I'm finally able to share a full
> > > > log for a boot problem. Please compare these two logs:
> > > > 1) 

[coreboot] Re: Resource allocator: multiple boards regression

[Mike Banon]

UPDATE: fam15tn A88XM-E is booting well if all 3 fixes applied
together with this patch above (separately not enough to get it
working) - tested it enough. However, when I tried a similar fix for
fam16kb AM1I-A - it got stuck in a boot loop (see the attached log).
Maybe I'm doing something wrong and it worked for fam15tn just by a
coincidence. Please take a look at change for a further review
https://review.coreboot.org/c/coreboot/+/41431

On Fri, May 15, 2020 at 1:30 PM Mike Banon  wrote:
>
> Looking at your change 41369 - soc/amd/stoneyridge: add resources
> during read_resources() - I tried to do a similar style change on top
> of your 3 fixes above, and surprisingly it worked at first try - now
> I'm able to see the boot devices and floppies. New bootlog is
> attached. After testing it more (should be able to boot 100% of times)
> I'm going to submit it to review coreboot org soon, for your review -
> and also we will need to do a similar change for family14 and
> family16kb if this one succeeds.
>
> diff --git a/src/northbridge/amd/agesa/family15tn/northbridge.c
> b/src/northbridge/amd/agesa/family15tn/northbridge.c
> index 9d41e7a1f1..0194ea82ea 100644
> --- a/src/northbridge/amd/agesa/family15tn/northbridge.c
> +++ b/src/northbridge/amd/agesa/family15tn/northbridge.c
> @@ -666,6 +666,8 @@ static void domain_set_resources(struct device *dev)
> u32 reset_memhole = 1;
>  #endif
>
> +   domain_read_resources(dev);
> +
> pci_tolm = 0xUL;
> for (link = dev->link_list; link; link = link->next) {
> pci_tolm = find_pci_tolm(link);
> @@ -749,17 +751,18 @@ static void domain_set_resources(struct device *dev)
> }
>
> add_uma_resource_below_tolm(dev, 7);
> -
> +/*
> for (link = dev->link_list; link; link = link->next) {
> if (link->children) {
> assign_resources(link);
> }
> }
> +*/
>  }
>
>  static struct device_operations pci_domain_ops = {
> -   .read_resources   = domain_read_resources,
> -   .set_resources= domain_set_resources,
> +   .read_resources   = domain_set_resources,
> +   .set_resources= pci_domain_set_resources,
> .scan_bus = pci_domain_scan_bus,
>  };
>
>
> On Fri, May 15, 2020 at 12:10 PM Mike Banon  wrote:
> >
> > Although it's still the same result even with three changes (either
> > can't boot or no boot devices, randomly) - there is a positive effect
> > that USB FT232H log now 't stop and I'm finally able to share a full
> > log for a boot problem. Please compare these two logs:
> > 1) ok_e6fb1344ed9188e19be4b54bdf1a76680b8c4523.txt - boot log for last
> > "working" commit (before the allocator changes)
> > 2) 3fixes.txt - boot log with 3 changes applied on top of
> > 6b95507ec5b087658178a325bdc68570bc48bb20 (after the allocator changes)
> > Hope this comparison will give enough clues about how to fix it
> > further - and I'll happily test your new changes aimed on fixing this
> >
> > Best regards,
> > Mike Banon
> >
> > On Fri, May 15, 2020 at 2:44 AM Furquan Shaikh
> >  wrote:
> > >
> > > I have uploaded 2 changes on top of Aaron's change. Can you please
> > > give these three changes a try:
> > > https://review.coreboot.org/c/coreboot/+/41363
> > > https://review.coreboot.org/c/coreboot/+/41418
> > > https://review.coreboot.org/c/coreboot/+/41419
> > >
> > > Thank you!
> > >
> > > - Furquan
> > >
> > > On Thu, May 14, 2020 at 4:16 PM Aaron Durbin  wrote:
> > > >
> > > >
> > > >
> > > > On Thu, May 14, 2020 at 3:46 PM Aaron Durbin  wrote:
> > > >>
> > > >>
> > > >>
> > > >> On Thu, May 14, 2020 at 2:46 PM Mike Banon  wrote:
> > > >>>
> > > >>> Unfortunately it seems a lot of boards are affected by this. A88XM-E
> > > >>> and Lenovo G505S (AMD fam15h) also got broken: they rarely succeed at
> > > >>> booting - and, when they do, no boot devices are available (virtual
> > > >>> floppies too, for some reason) - except coreinfo/tint secondary
> > > >>> payloads which became prone to freezing. I attach the A88XM-E logs
> > > >>> I've been able to obtain with USB FT232H:
> > > >>>
> > > >>> 1) ok_e6fb1344ed9188e19be4b54bdf1a76680b8c4523.txt - last coreboot
> > > >>> repo's revision where all the stuff works
> > > >>> 2) fail_1_3b02006

[coreboot] Re: Resource allocator: multiple boards regression

[Mike Banon]

Looking at your change 41369 - soc/amd/stoneyridge: add resources
during read_resources() - I tried to do a similar style change on top
of your 3 fixes above, and surprisingly it worked at first try - now
I'm able to see the boot devices and floppies. New bootlog is
attached. After testing it more (should be able to boot 100% of times)
I'm going to submit it to review coreboot org soon, for your review -
and also we will need to do a similar change for family14 and
family16kb if this one succeeds.

diff --git a/src/northbridge/amd/agesa/family15tn/northbridge.c
b/src/northbridge/amd/agesa/family15tn/northbridge.c
index 9d41e7a1f1..0194ea82ea 100644
--- a/src/northbridge/amd/agesa/family15tn/northbridge.c
+++ b/src/northbridge/amd/agesa/family15tn/northbridge.c
@@ -666,6 +666,8 @@ static void domain_set_resources(struct device *dev)
u32 reset_memhole = 1;
 #endif

+   domain_read_resources(dev);
+
pci_tolm = 0xUL;
for (link = dev->link_list; link; link = link->next) {
pci_tolm = find_pci_tolm(link);
@@ -749,17 +751,18 @@ static void domain_set_resources(struct device *dev)
}

add_uma_resource_below_tolm(dev, 7);
-
+/*
for (link = dev->link_list; link; link = link->next) {
if (link->children) {
assign_resources(link);
}
}
+*/
 }

 static struct device_operations pci_domain_ops = {
-   .read_resources   = domain_read_resources,
-   .set_resources= domain_set_resources,
+   .read_resources   = domain_set_resources,
+   .set_resources= pci_domain_set_resources,
.scan_bus = pci_domain_scan_bus,
 };


On Fri, May 15, 2020 at 12:10 PM Mike Banon  wrote:
>
> Although it's still the same result even with three changes (either
> can't boot or no boot devices, randomly) - there is a positive effect
> that USB FT232H log now 't stop and I'm finally able to share a full
> log for a boot problem. Please compare these two logs:
> 1) ok_e6fb1344ed9188e19be4b54bdf1a76680b8c4523.txt - boot log for last
> "working" commit (before the allocator changes)
> 2) 3fixes.txt - boot log with 3 changes applied on top of
> 6b95507ec5b087658178a325bdc68570bc48bb20 (after the allocator changes)
> Hope this comparison will give enough clues about how to fix it
> further - and I'll happily test your new changes aimed on fixing this
>
> Best regards,
> Mike Banon
>
> On Fri, May 15, 2020 at 2:44 AM Furquan Shaikh
>  wrote:
> >
> > I have uploaded 2 changes on top of Aaron's change. Can you please
> > give these three changes a try:
> > https://review.coreboot.org/c/coreboot/+/41363
> > https://review.coreboot.org/c/coreboot/+/41418
> > https://review.coreboot.org/c/coreboot/+/41419
> >
> > Thank you!
> >
> > - Furquan
> >
> > On Thu, May 14, 2020 at 4:16 PM Aaron Durbin  wrote:
> > >
> > >
> > >
> > > On Thu, May 14, 2020 at 3:46 PM Aaron Durbin  wrote:
> > >>
> > >>
> > >>
> > >> On Thu, May 14, 2020 at 2:46 PM Mike Banon  wrote:
> > >>>
> > >>> Unfortunately it seems a lot of boards are affected by this. A88XM-E
> > >>> and Lenovo G505S (AMD fam15h) also got broken: they rarely succeed at
> > >>> booting - and, when they do, no boot devices are available (virtual
> > >>> floppies too, for some reason) - except coreinfo/tint secondary
> > >>> payloads which became prone to freezing. I attach the A88XM-E logs
> > >>> I've been able to obtain with USB FT232H:
> > >>>
> > >>> 1) ok_e6fb1344ed9188e19be4b54bdf1a76680b8c4523.txt - last coreboot
> > >>> repo's revision where all the stuff works
> > >>> 2) fail_1_3b02006afe8a85477dafa1bd149f1f0dba02afc7.txt - this commit
> > >>> got the boards broken for the first time
> > >>> 3) fail_2_6b95507ec5b087658178a325bdc68570bc48bb20.txt - this is a log
> > >>> for coreboot's master top
> > >>>
> > >>> For some reason logs for 2) and 3) always stop after "PCI: 00:12.2
> > >>> EHCI Debug Port hook triggered".
> > >>>
> > >>> I hope these commits could be reverted before we figure out what's
> > >>> going on with them. Good thing we've noticed it fast enough.
> > >>>
> > >>
> > >> Thanks, Mike. The amd chipset code (all of it from what I can tell) is 
> > >> fundamentally broken and at odds with all of the resource allocation 
> > >> flow. They worked previously because dynamic resources were being 
> > >> assigned usin

[coreboot] Re: Change in coreboot[master]: nb/intel/i440bx: add resources during read_resources()

[Mike Banon]

Nice to see a possible fix. Thank you very much, going to test it tomorrow.

On Thu, May 14, 2020 at 11:29 PM Aaron Durbin via coreboot
 wrote:
>
>
>
> On Thu, May 14, 2020 at 2:25 PM Keith Hui  wrote:
>>
>> Hi Aaron,
>>
>> I think I have success after applying 41363 as well. Please see
>> attached and tell us if this is what you set out to do.
>
>
> That looks correct, and what I was expecting. Thanks for the help gathering 
> logs.
>
>>
>> Thanks
>> Keith
>>
>> On Thu, May 14, 2020 at 4:01 PM Aaron Durbin  wrote:
>> >
>> > Hi Keith,
>> >
>> > Did the newresalloc.log file contain this patch? 
>> > https://review.coreboot.org/c/coreboot/+/41363
>> >
>> > I ask because I see the fixed resources on the domain that are dram:
>> >   DOMAIN:  resource base 0 size a align 0 gran 0 limit 0 flags 
>> > e0004200 index a
>> >   DOMAIN:  resource base c size 2ff4 align 0 gran 0 limit 0 
>> > flags e0004200 index b
>> >
>> > However, I don't see them being removed the address space selection:
>> > DOMAIN:  mem: base: 0 size: 0 align: 0 gran: 0 limit: f
>> > update_constraints: PCI: 00:04.0 02 base ff80 limit  mem 
>> > (fixed)
>> > Resource ranges:
>> > Base: 0, Size: ff80, Tag: 200
>> > Base: 1, Size: f, Tag: 100200
>> >
>> > update_constraints isn't called for the resources above.
>> >
>> > On Thu, May 14, 2020 at 1:32 PM Keith Hui  wrote:
>> >>
>> >> Hi Aaron,
>> >>
>> >> Here are two more logs at SPEW. Old log is a separate branch where I
>> >> reverted all the problem commits; new log has everything.
>> >>
>> >> Thanks
>> >> Keith
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Need help with getting KGPE-D16 working.

[Mike Banon]

Hi there, KGPE-D16 friends.

1) Please look at my not-merged-yet "AMD_XMP" changes on
review.coreboot.org: they could help you to either use a XMP 1 or XMP
2 memory profile (should exist on ALL your sticks), or - preferably -
to set up your custom memory profile that will override the SPD
values. This way, maybe you could figure out the values to make your
RAM sticks run stable. You'll need to port this code to AMD fam10h
architecture to which KGPE-D16 belongs (if I'm not mistaken),
hopefully that wouldn't be hard.

2) USB is broken at floppy-based OS - maybe fam10h could have the same
"IRQ routing" issue as fam15h has. Sophisticated OS like Linux somehow
get around this issue, while the more simple OS couldn't.

3) Glad you liked my floppy patches and collection: there are
certainly a lot of goodies that are fun and useful. Usually the latest
revisions of these, and other, unofficial patches could be
automatically obtained with a csb_patcher.sh script from 33509 change
to save your time - I'm trying my best to keep up this stuff with a
coreboot master, as well as to get merged at least some of these
changes to reduce this maintenance.

Best regards,
Mike Banon

On Thu, May 14, 2020 at 9:28 PM Peter Stuge  wrote:
>
> ragna...@tenebr.is wrote:
> > 4.  For 32GB configuration (2 x 16GB sticks), installing to the
> > closest orange slot of each CPU would not boot, it booted when I
> > installed the sticks to the second closest orange slot of each CPU.
>
> If you install memory modules as far *away* from CPU/chipset as possible then
> you create more margin in DRAM signal integrity, which can make the system
> work more reliably even if memory initialization is not perfect.
>
> The reason is that signals reflect everywhere on the memory bus.
> When the chipset drives signals and modules are installed nearby, the
> signal will reflect back at the last slot and possibly interfere with
> either the controller's request or the DRAM's response.
>
> The same happens when the DRAM drives signals, in response to requests.
> They go out from the DRAM and both left to the chipset and right towards
> those unpopulated memory slots, and then reflects there, possibly
> interfering with what the DRAM sent or with the next request from the
> controller.
>
> Mainboard memory busses, especially with many slots, go right up to the
> limit of physics, and yes there is supposed to be a little bit of margin
> and there are some workarounds available, but all of that is the
> responsibility of the memory initialization, and it's very easy to
> not get everything 100% right. Then stuff doesn't always work.
>
> With this in mind, the safest bet should be, to populate a single DRAM
> module per channel, as far away from the chipset as possible.
>
>
> //Peter
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Linux kernel says "do_IRQ: 1.55 No irq handler for vector​"

[Mike Banon]

It seems to be a common problem for AMD: I've seen it on fam15h
Richland boards. This problem might be possible to fix, I just never
had the time to investigate and solve it. Aside from these angry
messages at dmesg, don't know if there are any extra side effects.

On Wed, May 13, 2020 at 4:54 AM Zheng Bao  wrote:
>
> not setting Extint can fix this IRQ issue.
>
> Is it a common problem or it is a AMD specific one?
>
>
> Zheng
>
> diff --git a/src/cpu/x86/lapic/lapic.c b/src/cpu/x86/lapic/lapic.c
> index 91b0fcd5ba..0dff625eb7 100644
> --- a/src/cpu/x86/lapic/lapic.c
> +++ b/src/cpu/x86/lapic/lapic.c
> @@ -29,6 +29,8 @@ void do_lapic_init(void)
>   lapic_write_around(LAPIC_SPIV,
>   (lapic_read_around(LAPIC_SPIV) & ~(LAPIC_VECTOR_MASK))
>   | LAPIC_SPIV_ENABLE);
> +
> + if (lapicid() == 0)
>   lapic_write_around(LAPIC_LVT0,
>   (lapic_read_around(LAPIC_LVT0) &
>   ~(LAPIC_LVT_MASKED | LAPIC_LVT_LEVEL_TRIGGER |
> @@ -38,6 +40,16 @@ void do_lapic_init(void)
>   | (LAPIC_LVT_REMOTE_IRR | LAPIC_SEND_PENDING |
>   LAPIC_DELIVERY_MODE_EXTINT)
>   );
> + else
> + lapic_write_around(LAPIC_LVT0,
> + (lapic_read_around(LAPIC_LVT0) &
> + ~(LAPIC_LVT_MASKED | LAPIC_LVT_LEVEL_TRIGGER |
> + LAPIC_LVT_REMOTE_IRR | LAPIC_INPUT_POLARITY |
> + LAPIC_SEND_PENDING | LAPIC_LVT_RESERVED_1 |
> + LAPIC_DELIVERY_MODE_MASK))
> +   | (LAPIC_LVT_REMOTE_IRR | LAPIC_SEND_PENDING)
> + );
> +
>   lapic_write_around(LAPIC_LVT1,
>   (lapic_read_around(LAPIC_LVT1) &
>   ~(LAPIC_LVT_MASKED | LAPIC_LVT_LEVEL_TRIGGER |
>
>
> 
> From: Zheng Bao 
> Sent: Wednesday, May 6, 2020 8:14 AM
> To: Nico Huber ; coreboot 
> Subject: [coreboot] Re: Linux kernel says "do_IRQ: 1.55 No irq handler for 
> vector"
>
> The Payload I run between Coreboot and Linux is SeaBIOS. Do you mean  SeaBIOS 
> should disable interrupt of all APs?
> I check the mail list and found this issue was raised before, but actually by 
> my colleague. We worked together and have not found the final solution.
>
> Zheng
>
>
> 
> From: Nico Huber 
> Sent: Sunday, May 3, 2020 4:28 PM
> To: Zheng Bao ; coreboot 
> Subject: Re: [coreboot] Linux kernel says "do_IRQ: 1.55 No irq handler for 
> vector"
>
> Hi Zheng,
>
> On 03.05.20 17:27, Zheng Bao wrote:
> > I am debugging the AMD Picasso board. When Linux kernel boots, there is 
> > some error message in dmesg.
> > do_IRQ: 1.55 No irq handler for vector
> >
> > The kernel can still boot.
> > What does this message mean? Can I just ignore this message?
>
> well, I'm worried. Even if it probably breaks nothing, it seems the APs
> are not in a state that Linux expects when it starts them up.
>
> 1.55 means interrupt vector 55 on CPU#1. This is in Linux' legacy
> interrupt range, should be IRQ 7 (offset by 48).
>
> That's where my Linux knowledge ended but I just had a quick look:
> In `arch/x86/kernel/smpboot.c` we have start_secondary() which runs
> on the AP. It calls:
>
> load_current_idt();
> ...
> lapic_online();
> ...
> local_irq_enable();
>
> A comment above the declaration of load_current_idt() indicates that
> we don't expect IRQs yet (before local_irq_enable() via `sti` I guess).
> That the kernel complains "No irq handler for vector" likely means that
> an interrupt is triggered before lapic_online() registered the handler.
>
> So, for me there are two mysteries:
>
>  1. Why is IRQ 7 triggerred?
>
>  2. Why does the AP process interrupts before `sti`? (if my assessment
> above is correct).
>
> Did you run any payload between coreboot and the kernel?
>
> Nico
>
> PS. I didn't thought you'd ask without googling first, there are
> mailing list threads about the issue already. Let's see what
> they say...
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Memtest86+ stuck

[Mike Banon]

On Thu, Apr 23, 2020 at 5:42 PM R S  wrote:
>
> On Thu, Apr 23, 2020 at 6:46 AM Paul Menzel  wrote:
>>
>> PS: By the way, Memtest86+ 5.31b was released [2].
>>
>> [1]: https://review.coreboot.org/c/coreboot/+/32613
>> [2]: https://www.memtest.org/
>
>
> That's huge! Thanks for picking up development.
>
> --
> LAN Engineer * NOC and IT Infrastructure Maintenance
> BCS Technology Department * Network Group
> ComicSans Awareness Campaign
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

Would like to add 2 notes:
1) Recently I've discovered that you could build a coreboot's "5.01
002" memtest86+ fork as a floppy instead of payload (and then manually
add a floppy to a coreboot BIOS build)
2) A good way to double check is to also use a Passmark's memtest86
4.37 floppy. If you're getting the same results, means that maybe a
RAM is faulty; if the different results - maybea false positive.

Thank you for telling about a new memtest86+, nice to see it active
again. I'd inform the developer about coreboot's fork and some other
forks, so that he could merge them into a one great memtest.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [gerrit] Impossible to delete some of the ancient changes

[Mike Banon]

i.e. would like to remove the worthless & abandoned 17439 , 17505 ,
17506 , 17507 changes I have done at 2016 year (this work has been
eventually merged, so nothing of a value will be lost) - but a Delete
button for them is not available.

Best regards,
Mike Banon
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: DRI_PRIME on G505s with enabled dGPU?

[Mike Banon]

On Sun, Mar 15, 2020 at 8:46 AM Matt B  wrote:
>
> Hi,
>
> Thanks for the info on DRI_PRIME. I'm looking at doing a motherboard+cooler 
> swap.
>
> Have you run battery life tests with/without the dGPU hidden?
> Isn't NVRAM the "correct" way to do it?
>
> -Matt
>
> On Wed, Mar 11, 2020 at 11:24 AM Mike Banon  wrote:
>>
>> On Sun, Mar 8, 2020 at 6:56 PM Matt B  wrote:
>> >
>> > To those who have a dual-GPU G505s and have enabled the recent support for 
>> > the dGPU, does DRI_PRIME GPU offloading work?
>> >
>>
>> Yes, DRI_PRIME GPU offloading works on G505S - and actually I think
>> it's the only possible way of using a discrete GPU on this coreboot'ed
>> laptop at the moment. However, it's usefulness really depends on your
>> software and how fast is the integrated GPU's RAM: you may have
>> 1600MHz CL9 RAM modules installed, while a discrete GPU's own soldered
>> chips are i.e. 1333MHz CL9 only. I recommend testing them side by side
>> in all the programs you care about and remember which one is better in
>> what cases.
>>
>> >
>> > Could here be an option created to enable/disable the dGPU at boot time 
>> > without recompiling?
>> >
>>
>> If there could be a real benefit from doing so (does it consume less
>> power if you "hide it" from your system by disabling a PCI bus?), such
>> a way could be implemented - however, I don't know how to do it
>> without using NVRAM (which I would like to avoid for various reasons)

Ideally I prefer a laptop as stateless as possible at least regarding
the BIOS - and also, at least some G505S laptops seem to have a broken
NVRAM (strong freeze on a write attempt to NVRAM and laptop doesn't
turn on until a full motherboard discharge).

A10-5750M TDP is 35W, after looking at the similar CPUs from this
table - https://www.eteknix.com/amd-kaveri-a10-7850k-overclocking-analysis/7/
, it seems that:

 Idle | GPU load | CPU+GPU load
15.6W |  23.66W  | 35W
44.5% |  67.6%   | 100%

And "where the ACPI VFCT Table is missing, Power States may not work
properly" - so a constant iGPU load, caused by the missing ACPI VFCT
for iGPU in our case, adds about 8W to power consumption ~ about 12%
less battery life. HD 8570M or R5 M230 might be 20W TDP at max load
(hard to find exact info), but its' ACPI VFCT table is loaded by
coreboot, so a power consumption difference shouldn't be as big.

Currently I'm trying to add the XMP profiles support ( see
https://review.coreboot.org/c/coreboot/+/40291 ) so it could take me a
while to return to this research.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: DRI_PRIME on G505s with enabled dGPU?

[Mike Banon]

On Sun, Mar 8, 2020 at 6:56 PM Matt B  wrote:
>
> To those who have a dual-GPU G505s and have enabled the recent support for 
> the dGPU, does DRI_PRIME GPU offloading work?
>

Yes, DRI_PRIME GPU offloading works on G505S - and actually I think
it's the only possible way of using a discrete GPU on this coreboot'ed
laptop at the moment. However, it's usefulness really depends on your
software and how fast is the integrated GPU's RAM: you may have
1600MHz CL9 RAM modules installed, while a discrete GPU's own soldered
chips are i.e. 1333MHz CL9 only. I recommend testing them side by side
in all the programs you care about and remember which one is better in
what cases.

>
> Could here be an option created to enable/disable the dGPU at boot time 
> without recompiling?
>

If there could be a real benefit from doing so (does it consume less
power if you "hide it" from your system by disabling a PCI bus?), such
a way could be implemented - however, I don't know how to do it
without using NVRAM (which I would like to avoid for various reasons)
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: SuzyQable - ChromeOS Debug Cable

[Mike Banon]

Is that something like a cable with two built-in FT232H chips ? (to
function as a USB dongle)
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: A Hardware enthusiast view on the usefulness of open source Firmwares like Coreboot

[Mike Banon]

Good day Zir,

It would've been helpful if your article had your e-mail in the end of
it or a reply form - I've stumbled upon your article some time ago,
but didn't find a quick way to share my feedback and got distracted by
something else, maybe the others did too...

1) Thanks for describing CH341A, as it is a simple, reliable and
affordable flashrom-supported SPI programmer. However, there's a
problem that some CH341A give 5V voltage instead of 3.3V - although,
as the time passes, these incorrect CH341A models will disappear, it
could be worth mentioning this problem so that your reader will test
the voltage of his CH341A before using it. By the way, even the
"incorrect ones" may be fixed by a small hardware mod.

2) I didn't like your opinion of SeaBIOS, that it's just "mostly used
to support legacy OSes and PCIe Cards with Option ROMs that have only
a BIOS compatible Device Firmware." Perhaps this statement has been
affected by your personal Tianocore-mostly experience - however, if
you'd look at the board_status reports contributed by our community,
~90% of them have SeaBIOS as payload, and judging by the mailing list
threads I find these stats pretty close to reality. SeaBIOS popularity
is well justified by its' simplicity: less than 50k lines of good
readable code, weights a few KB and "just works". Tianocore is quite
bloated in comparison and seems to be more difficult to configure and
get it working properly. Maybe that's why SeaBIOS is still a default
coreboot payload - and really, there's nothing Tianocore can do that
SeaBIOS theoretically couldn't. I've been using coreboot
for a few years and haven't found any good enough reason to switch
from SeaBIOS to Tianocore. You may argue that UEFI is much more
popular nowadays, however it's only because the newer PCs had UEFI
preinstalled; nobody asked the people if they want UEFI or not, this
choice has been kinda forced upon them. Also, I haven't encountered
any UEFI-only OS yet; if such an OS would be created one day - maybe
just for the purpose of being the first UEFI-only "modern OS" - well
that's an intentional reduction of potential userbase for no valid
technical reasons.

3) It a bit puzzles me why you didn't mention any interesting
floppy-based OS like Kolibri in the "floppy part". Windows 3.1 may
seem interesting, however there wouldn't be any updates or software
for it, it's stuck at whatever level has been reached during its'
lifetime, while a lot of the other floppy OS projects - i.e. some of
those I'm offering with csb_patcher.sh script (KolibriOS, FreeDOS,
MichalOS, Snowdrop, Fiwix, Memtest, Tatos, Plop, FloppyBird) - are
still being developed. At least you've mentioned a FreeDOS, but there
are many interesting floppy projects - including those with a
minimalistic Linux environment, and PicoBSD - which haven't been
mentioned even in brief. Perhaps that's because your Tianocore payload
does not support the floppies, so you didn't have a chance to explore
this wonderful world personally. I really feel this part is a bit
short and could be really expanded. In example, if KolibriOS supports
your Ethernet controller, you could access the Internet right from
your BIOS and IRCC chat with your friends.

4) By attempting to stay further from "anti-spy crowd", it seems like
the information security advantage of coreboot has been almost skipped
- i.e. Ctrl+F by Computrace gives no results. Maybe it's not a big
loss, considering this security part is well covered at the other
articles - however, it may be worth considering expanding this part if
you'd like your article to be truly wholesome.

5) Try to shrink your "wall of text" while preserving as much
information as possible. Aside from the issues above, your article
really seems great and well-written, but it takes some hard work to
get through it instead of TLDR hops between the interesting parts. If
you could succeed in compressing, will be much easier to read.

That's just my personal opinion, thank you for a good read and I wish
you the best in your adventures.

Best regards,
Mike
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org