Issue #388 has been updated by King Sumo.
King Sumo wrote:
> Postcar is crashing when using configured to teardown the CAR using FSP.
> Therefore the bug may occur in other platforms than denverton as well.
> See also the discussion here:
> https://mail.coreboot.org/hyperkitty/l
Issue #388 has been reported by King Sumo.
Bug #388: denverton_ns: crash when starting postcar
https://ticket.coreboot.org/issues/388
* Author: King Sumo
* Status: New
* Priority: Normal
* Assignee: Arthur Heymans
* Category: board support
* Target
Issue #318 has been updated by King Sumo.
King Sumo wrote in #note-1:
> Fixed:
>
> ommit 3990da0bfe18e3b76751fd35fef9e5ec55c2fd29
> Author: Kyösti Mälkki
> Date: Mon Nov 15 17:25:54 2021 +0200
>
> soc/intel/denverton_ns: Fix MRC_RW_CACHE
>
>
Issue #318 has been updated by King Sumo.
Status changed from New to Response Needed
Bug #318: denverton_ns: Fix MRC cache write
https://ticket.coreboot.org/issues/318#change-959
* Author: King Sumo
* Status: Response Needed
* Priority: Normal
* Start
/exit_car.S we have a $ sign...
The fsp1_1/exit_car.S module must be fixed as well
Thanks,
Sumo
On Tue, Jun 14, 2022 at 3:25 PM Arthur Heymans wrote:
>
> So basically Temp RAM Exit is broken, since we need to use
>> NO_FSP_TEMP_RAM_EXIT which selects
>> "./src/soc/intel/common/b
op, %esp
+ mov _estack, %esp
/* Align the stack. */
andl$0xfff0, %esp
/* Call C code */
callmain
The question is why we can't reach main() anymore. Any clues?
Kind regards,
Sumo
On Tue, Jun 14, 2022 at 6:27 AM Arthur Heymans wro
t the same...
By configuring coreboot this way, the Temp RAM FSP is not used? So for the
coreboot latest Temp RAM FSP support is broken right?
Thanks,
Sumo
On Mon, Jun 13, 2022 at 1:38 PM Arthur Heymans wrote:
> Hi
>
> Can you try selecting "NO_FSP_TEMP_RAM_EXIT" in the den
this change looks like a base for
future implementations... Please let me know if you need more tests.
Kind regards,
Sumo
On Mon, Jun 13, 2022 at 9:37 AM Sumo wrote:
> Thanks Paul, I'll try bisect.
>
> Do we have any instructions of how to use the normal/fallback coreboot
> stage pref
BOOTBLOCK_NORMAL + normal prefix, and then reuse a
prebuilt coreboot.rom with fallback stages included? Anything else needed
besides having a cmos layout?
Kind regards,
Sumo
On Sat, Jun 11, 2022 at 3:15 AM Paul Menzel wrote:
> Dear Suma,
>
>
> Am 11.06.22 um 00:16 schrieb Sumo:
>
> >
,
Sumo
coreboot-4.17.log
Description: Binary data
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
) or
if the device is still booting...
Kind regards,
Sumo
On Tue, Aug 17, 2021 at 8:34 AM Sumo wrote:
> Hi,
>
> I have managed to disable the UART console and collect the logs via cbmem
> tool. Therefore it will not add any additional delay even with debug logs
> enabled so we can c
Hi Furquan,
I can confirm your proposal is working, could you please submit the patch
for review?
Thanks,
Sumo
On Fri, Aug 20, 2021 at 9:52 PM Szafranski, MariuszX <
mariuszx.szafran...@intel.com> wrote:
> Hi Furquan,
>
> Thanks for pointing. I`ve missed this patch series.
out.
The patch was submitted for review:
https://review.coreboot.org/c/coreboot/+/57033
Thanks,
Sumo
On Fri, Jun 11, 2021 at 9:05 AM Szafranski, MariuszX <
mariuszx.szafran...@intel.com> wrote:
> Hi Sumo,
>
>
>
> It should be simple as adding SPI early init to bootblock.
>
debug_level=Spew; NVMe ok: the coreboot
log output is enough to make NVMe work properly;
The NVMe is in the root port 00:0b.0, it is shown as 04:00.0
Thanks,
Sumo
On Mon, Aug 16, 2021 at 2:57 PM Paul Menzel wrote:
> Dear Sumo,
>
>
> Am 16.08.21 um 18:38 schrieb Sumo:
>
> > The
ons) or do we have
a better solution?
Kind regards,
Sumo
On Mon, Aug 16, 2021 at 1:45 PM Jay Talbott
wrote:
> Unfortunately, for the Denverton SoC (C3000 series), the APIC ID of the
> first core is not always the same. For 16-core SKUs, it’s always 0, but for
> SKUs with a lower number of c
in
the devicetree.cb (set as on). Maybe coreboot is too fast and the NVMe is
still booting up - or the PCIe link is still training, not sure. Coreboot
doesn't retry if the device is not detected right away?
Kind regards,
Sumo
___
coreboot mailing list -- coreboot
est solution.
Kind regards,
Sumo
On Wed, Oct 7, 2020 at 6:35 PM Nico Huber wrote:
> Hi,
>
> have you tried omitting the `device lapic` line from the devicetree?
> It would only matter if there is configuration associated with it, but
> I can't see anything like that for `intel/h
time during
manufacturing as some resets can't be avoided (here at least 1 reset always
happens). It would be good if this can be implemented somehow in coreboot
latest...
Hopefully this info could be useful to someone ;)
Kind regards,
Sumo
On Thu, Jun 10, 2021 at 3:41 PM Mariusz Szafrański via
in 'RW_MRC_CACHE'
MRC: cache data 'RW_MRC_CACHE' needs update.
SPI Transaction Error at Flash Offset 81 HSFSTS = 0x01046003
REGF metadata allocation failed: 1949 data blocks 4096 total blocks
MRC: failed to update 'RW_MRC_CACHE'.
Any clues?
Thanks,
Sumo
Hi Arthur,
It works, thanks!
Kind regards,
Sumo
On Thu, Jun 10, 2021 at 10:36 AM Arthur Heymans wrote:
> Hi
>
> Try with https://review.coreboot.org/c/coreboot/+/55389 applied.
>
> Kind regards
> Arthur
>
> On Thu, Jun 10, 2021 at 3:16 PM Sumo wrote:
>
>> H
in the console output.
Any advice?
Kind regards,
Sumo
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
0x" # IPC3
device cpu_cluster 0 on
- device lapic 4 on end
+ device lapic 0xbeef on end # NOTE: correct Local APIC ID is
set in in dev_enumerate()
end
device domain 0 on
Thanks,
Sumo
On Fri, Apr 24, 2020 at 12:50 PM Jay Talbott <
jayta
(IA32_MISC_ENABLE, msr);
- }
+// }
}
King regards,
Sumo
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
is that this is not changing the system performance at all.
Probably the only side effect is the bad cpu enumeration...
Kind regards,
Sumo
On Tue, Feb 19, 2019 at 6:56 AM Дмитрий Понаморев
wrote:
> The processor and memory are very slow. Compiling the ixgbe network card
> driver takes 10 m
is available in:
https://github.com/tianocore/edk2-staging/tree/UEFIPayload
Kind regards,
Sumo
On Thu, Feb 14, 2019 at 8:09 PM Patrick Georgi via coreboot <
coreboot@coreboot.org> wrote:
> Also, there may be users interested in the "whole" UEFI experience,
> with secure boot validatin
USB works a charm using CorebootPayloadPkg from Tianocore/EDK2 instead of
using GRUB2 as payload (you can use grub anyway to load linux later on, or
use any other bootloader without sticking this in the SPI flash image).
Em qua, 22 de ago de 2018 às 07:45, Hilbert Tu(杜睿哲_Pegatron) <
let me know if this happens to you and if the same fix can be
applied!
Thanks,
Sumo
2018-06-04 9:46 GMT-03:00 Julien Viard de Galbert <
jviarddegalb...@online.net>:
>
>
> Le 29 mai 2018 à 16:48, Sumo a écrit :
>
> Hi,
>
> Today denverton_core_init() is enabling the In
ABLED)"
test and always enable the SpeedStep technology.
Thanks,
Sumo
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Hi Julien,
Yes, I'm interested. But no need to hurry up, do it in your own time. ;)
Thanks,
Sumo
2018-03-27 6:54 GMT-03:00 Julien Viard de Galbert <
jviarddegalb...@online.net>:
>
>
> Le 26 mars 2018 à 21:24, Sumo <kingsu...@gmail.com> a écrit :
>
> Hi all,
&
controller definition in the ACPI tables.
I want to add/implement the INTC3000 in the ASL code, but since I don´t
want to reinvent the wheel I´m asking if such ASL code is already available
somewhere (at least in the Intel Pine Lake CRB there´s no such reference to
INTC3000 in the ACPI tables).
Th
blob in the coreboot
build? I´m not sure about this, some board maintainer can confirm
this?
Do we have any documentation regarding the coreboot port for Harcuvar?
Thanks,
Sumo
2018-02-26 19:42 GMT-03:00 Philipp Stanner <stan...@posteo.de>:
> Am Montag, den 26.02.2018, 17:14 -0300 schrieb
firmware)
Thanks,
Sumo
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
32 matches
Mail list logo
