On Fri, Aug 20, 2021 at 4:15 PM Szafranski, MariuszX
<[email protected]> wrote:
>
> Hi Dimitry,
>
>
>
> I can see it and my proposition isn`t “something new” (still updating lapicid
> with value detected while booting)
>
> Logically little different (keeping 0 in devicetree.cb) without introducing
> “0xbeef magic” and avoiding future questions like below:
>
> > I wish I could understand how this magic works :)! lapic 0xbeef .....
>
> As it is DNV specific it is just moved to DNV subdirectory without touching
> coreboot core.
>
>
>
> BR,
>
> Mariusz
>
>
>
> From: Дмитрий Понаморев <[email protected]>
> Sent: Friday, August 20, 2021 11:40 PM
> To: Szafranski, MariuszX <[email protected]>
> Cc: Sumo <[email protected]>; Jay Talbott
> <[email protected]>; Coreboot <[email protected]>
> Subject: Re: [coreboot] Re: A different lapic number in devicetree.cb needed
> for CPU with the same SKU and steping (Intel Atom C3538).
>
>
>
> Hi
>
>
>
> I don't understand why to invent something new. Sumo's patch works great. Why
> can't you use it?
>
> This Intel Atom Denverton C3000 processor has a maximum of 16 cores (4
> clusters of 4 processors each).
>
> The problem with the lapic ID is real for processors with less than 16 cores,
> especially for 2 and 4 cores - these processors are also 16 only with
> disabled cores in clusters.
>
> Intel turns them off randomly and therefore the value lapic ID floats.
>
> Changing this parameter as you suggest will suit you if you have one board -
> if there are many of them, it will not work.
>
>
>
> Best regards,
>
> Dmitry Ponamorev
>
>
>
> пт, 20 авг. 2021 г. в 23:56, Szafranski, MariuszX
> <[email protected]>:
>
> Hi,
>
>
>
> Maybe keep 0 for apicid in devicetree.cb and add something like below to
> denverton soc_init (or define separate function for check and fixup) in
> src/soc/intel/denverton_ns/chip.c.
>
> Could anyone with apicid != 0 test and let us know?
>
> BR,
>
> Mariusz
>
>
>
> static void soc_init(void *data)
>
> {
>
> unsigned long bsp_lapicid = lapicid();
>
> struct device *dev;
>
>
>
> if (bsp_lapicid){
>
> for (dev = &dev_root, cnt = 0; dev; dev = dev->next){
>
> if ((dev->path.type == DEVICE_PATH_APIC){
>
> if (bsp_lapicid != dev->path.apic.apic_id){
>
> printk(BIOS_SPEW,
>
> "soc_init: BSP lapic ID = 0x%lx - updating in devicetree\n",
>
> bsp_lapicid);
>
> dev->path.apic.apic_id = bsp_lapicid;
>
> } else {
>
> break;
>
> };
>
> };
>
> };
>
> };
>
> …..
>
>
>
>
>
> From: Дмитрий Понаморев <[email protected]>
> Sent: Monday, August 16, 2021 8:17 PM
> To: Sumo <[email protected]>
> Cc: Jay Talbott <[email protected]>; Coreboot
> <[email protected]>
> Subject: [coreboot] Re: A different lapic number in devicetree.cb needed for
> CPU with the same SKU and steping (Intel Atom C3538).
>
>
>
> Hi Sumo,
>
>
>
>
>
> > ... It’s also possible (but not confirmed) that for a particular SKU
> > (other than 16-core SKUs), it might not be consistent between parts
>
> I can confirm this, I have two C3558 SoC's with first core different APID
> ID's...
>
>
>
> I can confirm it too for C3338, C3538.
>
>
>
> Do you think I can submit my patch (see previous discussions) or do we have a
> better solution?
>
>
>
> Your patch works great for me ( for C3338, C3538, C3758, C3958).
>
> Thanks again! (from this thread:
> https://mail.coreboot.org/hyperkitty/list/[email protected]/thread/MCRPRU7ETWDJFG7RQPFYPOTICCJLT4SL/#FTE6TVQU5VCZMJTBE2NFNC2AME5A7PBB
> )
>
>
>
>
>
>
>
>
>
>
>
>
>
> пн, 16 авг. 2021 г. в 20:58, Sumo <[email protected]>:
>
> Hi Jay,
>
>
>
> > ... It’s also possible (but not confirmed) that for a particular SKU
> > (other than 16-core SKUs), it might not be consistent between parts
>
> I can confirm this, I have two C3558 SoC's with first core different APID
> ID's...
>
>
>
> Do you think I can submit my patch (see previous discussions) or do we have a
> better solution?
>
>
>
> Kind regards,
>
> Sumo
>
>
>
> On Mon, Aug 16, 2021 at 1:45 PM Jay Talbott <[email protected]>
> 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 cores, it may be a different number. It’s also
> possible (but not confirmed) that for a particular SKU (other than 16-core
> SKUs), it might not be consistent between parts. The solution is to basically
> ignore the value in devicetree and use the actual APIC ID from the first core.
>
>
>
> - Jay
>
>
>
> From: Sumo [mailto:[email protected]]
> Sent: Monday, August 16, 2021 9:15 AM
> To: Nico Huber
> Cc: Дмитрий Понаморев; Coreboot
> Subject: [coreboot] Re: A different lapic number in devicetree.cb needed for
> CPU with the same SKU and steping (Intel Atom C3538).
>
>
>
> Hi,
>
>
>
> > have you tried omitting the `device lapic` line from the devicetree?
>
> I have tested this, in this case Linux shows only one processor core.
> Therefore the 'device lapic' line is really needed...
Can you please try dropping `device lapic` from the devicetree along
with this patch:
diff --git a/src/soc/intel/denverton_ns/cpu.c b/src/soc/intel/denverton_ns/cpu.c
index 1dc0830d86..ecefd3a987 100644
--- a/src/soc/intel/denverton_ns/cpu.c
+++ b/src/soc/intel/denverton_ns/cpu.c
@@ -287,6 +287,9 @@ static const struct mp_ops mp_ops = {
void denverton_init_cpus(struct device *dev)
{
+ if (!dev->link_list)
+ add_more_links(dev, 1);
+
/* Clear for take-off */
if (mp_init_with_smm(dev->link_list, &mp_ops) < 0)
printk(BIOS_ERR, "MP initialization failure.\n");
I think once you drop the device from device tree, dev->link_list
would be NULL and so MP initialization failed for you. This problem is
not really unique to denverton and was fixed just a few days back for
other Intel SoCs using common/block/cpu/mp_init too:
https://review.coreboot.org/c/coreboot/+/56758
https://review.coreboot.org/c/coreboot/+/56852
>
>
>
> I can submit that Local APIC Fixup patch to gerrit but I'm not sure if this
> is really the best solution.
>
>
>
> Kind regards,
>
> Sumo
>
>
>
>
>
> On Wed, Oct 7, 2020 at 6:35 PM Nico Huber <[email protected]> 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/harcuvar`.
>
> What happens is that this `device lapic` line in the devicetree becomes
> an entry in a list at runtime. This list is later filled with the actual
> cores present. If any of the actual cores has the same APIC id as given
> in the devicetree, no additional entry is added for this core. However
> if none of the actual cores has that id, the original entry is left
> blindly in the list, causing coreboot to report the spurious, fifth
> core.
>
> On 07.10.20 21:27, [email protected] wrote:
> > Thank you so much Javier Galindo!
> >
> > Sorry for not finding this case myself ...
> > I checked it on the motherboard with lapic #4 - everything works as it
> > should.
> > Tomorrow I'll check it on the motherboard with lapic #0.
> > I wish I could understand how this magic works :)! lapic 0xbeef .....
>
> It's kind of a wildcard that gets replaced with the number found in the
> hardware. Nothing too special but probably unnecessary.
>
> Nico
> _______________________________________________
> coreboot mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
> --------------------------------------------------------------
> Intel Research and Development Ireland Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
>
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). Any review or distribution by others
> is strictly prohibited. If you are not the intended recipient, please contact
> the sender and delete all copies.
>
> --------------------------------------------------------------
> Intel Research and Development Ireland Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
>
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). Any review or distribution by others
> is strictly prohibited. If you are not the intended recipient, please contact
> the sender and delete all copies.
>
> _______________________________________________
> coreboot mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
