I think it makes sense to make it public if the person of interest wishes to do
so. After all that rule should only exist to protect the person of interest and
not anyone else.
I may be far fetching here, but I think we are all mature enough to discuss
this calmly as a community. No shitstorm
Hi Paul,
My responses are inline.
Feb 19, 2024, 15:26 by pmen...@molgen.mpg.de:
> Dear coreboot folks,
>
>
> Am 19.02.24 um 22:24 schrieb mina--- via coreboot:
>
> […]
>
>> ### [Nico] Revoking Gerrit privileges as punishment.
>> I would like to discuss two matters about this. Not sure about the
This is another example of "don't try to support impossible hardware" :-)
The real bug is that coreboot build system let you build the i440fx with
APIC2, right? I assume that's what Paul meant.
OTOH, it is a way to test that linux properly fails when told to use
impossible hardware :-)
On Mon,
Dear coreboot folks,
Am 19.02.24 um 22:24 schrieb mina--- via coreboot:
[…]
### [Nico] Revoking Gerrit privileges as punishment.
I would like to discuss two matters about this. Not sure about the order.
* My own case: I was removed from the core developers and reviewers groups
20
Dear community,
Please note that the upcoming coreboot leadership meeting is scheduled for next
Wednesday, February 21, 2024.[1]
You are welcome to update the current agenda items with matters you wish to see
addressed during the meeting.[2]
## Current Agenda Items
### We’ve switched to
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
Issue #524 has been updated by Felix Held.
This isn't really a coreboot bug, since qemu doesn't support x2apic emulation:
https://gitlab.com/qemu-project/qemu/-/issues/330
Also the i440fx chipset is much older than the first CPU supporting x2apic mode.
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
Hi guys,
I was unable to build crossgcc. The important tail end of build log is
included at the end.
I couldn't figure out why. There should be no binutils-2.33.1 anywhere
on my system. The build script is pulling in 2.41, and my host
binutils is 2.40.
Appreciate any help.
Thanks
Keith
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
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
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
12 matches
Mail list logo
