David Hendricks schrieb am Mi., 29. Jan. 2020,
00:51:
> we'd first need to invent a way to
> send an electric shock thru the keyboard to users who complain to (or
> about) Intel when something goes wrong with the code.
>
That may have been necessary in the era of the fdiv bug but I'm not sure
Hello Jose,
Thanks, you must have missed my reply to the thread a few days back.
Everything is working perfectly now, I had to disable VGA_BIOS as you also
suggests.
Regards,
Mogens Jensen
‐‐‐ Original Message ‐‐‐
On Tuesday, January 28, 2020 5:01 PM, Jose Trujillo
wrote:
> Hello
> Writing new code could considerably reduce its complexity
> and make things much easier. After a few years with FSP, I'm convinced
> that writing clean code would be cheaper than the FSP integration with
> all its avoidable complexity. Intel might not like it, but you could
> reach proper
Hi Marshall,
On 28.01.20 02:12, Marshall Dawson wrote:
>> That's why I always encourage people to ask for documentation instead
>> of code. Opening code that was developed in private is a pain for both
>> sides. However, I guess it could be taken as a good omen; that a silicon
>> vendor won't
Hi Jonathan,
On 27.01.20 23:01, Jonathan Zhang (Infra) wrote:
> On 1/27/20, 10:56 AM, "Nico Huber" wrote:
>> We had this before: Something that nobody really cared about was
>> upstreamed. And then later, it was copied for newer platforms and
>> people were confused by the feedback that they
Earlier this month Paul reached out to me in private and asked me
about a few of my board status uploads. We collectively noticed the
romstage now takes significantly longer to the tune of 1.5 seconds. We
were not quite sure where the problem was because I also tried
reverting to romcc bootblock
On Mon, Jan 27, 2020 at 04:24:00PM -0600, Matt DeVillier wrote:
> having a src/mainboard/stub/ for **all** SoC might not be a bad idea,
> especially if it were to select less common/non-default options that other
> in-tree boards don't select by default, to ensure full coverage of all SoC
>
Hi everybody,
one thing that became clear to me in the recent (and not-so-recent)
discussions broadly related to coding style, code duplication, code
submission strategies, documentation requirements and similar things
is that there have to be many different styles of approaching coreboot
Am Di., 28. Jan. 2020 um 08:03 Uhr schrieb David Hendricks <
david.hendri...@gmail.com>:
> Please correct me if I'm way off base with that example. The stubs
> Patrick proposed in the other thread might help address the issue,
> however it can also mean adding code which exists only to satisfy
Hello Mogens,
If you want to use LIBGFXINIT please disable VGA_BIOS and for SeaBIOS choose
"Legacy VGA text mode" as framebuffer mode in "Display".
Let us know if the problem remains after this.
Jose Trujillo.
‐‐‐ Original Message ‐‐‐
On Thursday, January 23, 2020 12:41 PM, Mogens
Hi,
As Kyösti pointed, MP tables and IRQ is broken on AGESA boards. Most of
the mainboards have mindlessly copy-pasted code that generates MP tables
and IRQ tables. Those often contain entries of non-existing devices as a
result. Since the most preferred way of IRQ routing is ACPI and most
Hello,
adding nosmp pci=noacpi results in same behaviour - linux can't assign irq
to usb controllers(but I don't see IRQ >15 anymore). Adding nosmp
pci=biosirq,noacpi allow system to boot.
сб, 25 янв. 2020 г. в 03:14, Kyösti Mälkki :
> On Thu, Jan 16, 2020 at 5:21 PM awokd via coreboot
>
12 matches
Mail list logo
