[coreboot] Fwd: Denverton: NVMe not detected when serial console logs are disabled
Hi Paul, When logs are (almost) disabled the error isn't shown, so if I add the delay with logs disabled the log output will have almost no difference at all. Following are the logs, including a log with Coreboot debug enabled + no delay. For all logs FSP loglevel is set to NoDebug: - nvme-err.log : no delay; coreboot debug_level=Error; NVMe error: at the end of the log is shown the error in the UEFI FW: ERROR: C4002:V02010007 I0 93B80004-9FB3-11D4-9A3A-0090273FC14D 7E90A998; - nvme-ok-delay.log : 20ms delay; coreboot debug_level=Error; NVMe ok; - nvme-ok.log : no delay; coreboot 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 NVMe is not detected when serial console logs are disabled, I mean by > > setting both Coreboot log_level=Error (or less) and FSP > > PcdFspDebugPrintErrorLevel=NoDebug. Looks like the enumeration fails then > > further on the device is not listed in the UEFI FW (same issue shown in > > either CorebootPayloadPkg or UefiPayloadPkg). When Linux boots the device > > appears normally. > > > > The problem is fixed by adding a small delay inside dev_enumerate() - a > > 20ms delay at the very beginning of the function is enough. I'm wondering > > if there is a better solution for this, the device is already defined 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? > > Please share the logs without and with the delay. > > > Kind regards, > > Paul > nvme-ok.log Description: Binary data nvme-err.log Description: Binary data nvme-ok-delay.log Description: Binary data ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[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/coreboot@coreboot.org/thread/MCRPRU7ETWDJFG7RQPFYPOTICCJLT4SL/#FTE6TVQU5VCZMJTBE2NFNC2AME5A7PBB ) пн, 16 авг. 2021 г. в 20:58, Sumo : > 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 < > jaytalb...@sysproconsulting.com> 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:kingsu...@gmail.com] >> *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... >> >> >> >> 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 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, dponamo...@gmail.com 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 -- 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: A different lapic number in devicetree.cb needed for CPU with the same SKU and steping (Intel Atom C3538).
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 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:kingsu...@gmail.com] > *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... > > > > 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 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, dponamo...@gmail.com 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 -- 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: Denverton: NVMe not detected when serial console logs are disabled
Dear Sumo, Am 16.08.21 um 18:38 schrieb Sumo: The NVMe is not detected when serial console logs are disabled, I mean by setting both Coreboot log_level=Error (or less) and FSP PcdFspDebugPrintErrorLevel=NoDebug. Looks like the enumeration fails then further on the device is not listed in the UEFI FW (same issue shown in either CorebootPayloadPkg or UefiPayloadPkg). When Linux boots the device appears normally. The problem is fixed by adding a small delay inside dev_enumerate() - a 20ms delay at the very beginning of the function is enough. I'm wondering if there is a better solution for this, the device is already defined 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? Please share the logs without and with the delay. Kind regards, Paul ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: A different lapic number in devicetree.cb needed for CPU with the same SKU and steping (Intel Atom C3538).
The solution to this problem has already been discussed here. You just need to replace in the file devicetree.cb "lapic 4" to "lapic 0xbeef". *device cpu_cluster 0 on#device lapic 4 on enddevice lapic 0xbeef on end #NOTE: correct Local APIC ID is set in in dev_enumerate() end* This works for two cores (C3338), quad cores (C3538), eight cores, twelve cores, and 16 cores - I've tested this. пн, 16 авг. 2021 г. в 19:45, Jay Talbott : > 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:kingsu...@gmail.com] > *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... > > > > 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 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, dponamo...@gmail.com 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 -- 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: A different lapic number in devicetree.cb needed for CPU with the same SKU and steping (Intel Atom C3538).
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:kingsu...@gmail.com] 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... 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 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, dponamo...@gmail.com 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 -- 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] Denverton: NVMe not detected when serial console logs are disabled
Hi, The NVMe is not detected when serial console logs are disabled, I mean by setting both Coreboot log_level=Error (or less) and FSP PcdFspDebugPrintErrorLevel=NoDebug. Looks like the enumeration fails then further on the device is not listed in the UEFI FW (same issue shown in either CorebootPayloadPkg or UefiPayloadPkg). When Linux boots the device appears normally. The problem is fixed by adding a small delay inside dev_enumerate() - a 20ms delay at the very beginning of the function is enough. I'm wondering if there is a better solution for this, the device is already defined 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@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[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... 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 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, dponamo...@gmail.com 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 -- 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: Build for F2A85-M Foobared, any ideas?
On 16/8/21 8:43 pm, Paul Menzel wrote: It’s in the path name or logs in the directory I referenced: 4.13-917-g192177d34d refers to commit hash 192177d34d. I've tried both hash's refrencing both sucessfull builds for F2A85-M board. I just get: error: pathspec '192177d34d' did not match any file(s) known to git error: pathspec 'fdfc473380' did not match any file(s) known to git ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Build for F2A85-M Foobared, any ideas?
Dear Keith, Am 16.08.21 um 12:39 schrieb Keith Emery: I went one further and just deleted the whole working directory, re-cloned coreboot and built using that exact configuration. All to little avail. Please do not leave the other questions/requests unanswered. How do I go about finding the exact commit that was used in the log? It’s in the path name or logs in the directory I referenced: 4.13-917-g192177d34d refers to commit hash 192177d34d. Kind regards, Paul PS: It’s common to interleaved style when replying (on mailing lists). ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Build for F2A85-M Foobared, any ideas?
Dear Keith, Am 16.08.21 um 09:16 schrieb Keith Emery: coreboot-4.14-1405-gad08265740-dirty Sun Aug 15 07:12:41 UTC 2021 The dirty flag suggests, you have local changes. Please paste the output of `git status` and `git diff`. Also, please attach `defconfig` generated by `make savedefconfig`, and tell us your memory configuration, and test with different DIMM combinations. In January, Idwer uploaded logs from a successful boot to the board status repository (`asus/f2a85-m/4.13-917-g192177d34d/2021-01-11T01_03_00Z`) [1]. Maybe try with that configuration first. Kind regards, Paul [1]: https://review.coreboot.org/plugins/gitiles/board-status/+/71278e2819996f2e6b0ac9ff444e5d31b8073677 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Build for F2A85-M Foobared, any ideas?
coreboot-4.14-1405-gad08265740-dirty Sun Aug 15 07:12:41 UTC 2021 bootblock starting (log level: 7)... CBFS: Found 'fallback/romstage' @0x30e00 size 0x4c910 in mcache @0x00034f7c BS: bootblock times (exec / console): total (unknown) / 12 ms coreboot-4.14-1405-gad08265740-dirty Sun Aug 15 07:12:41 UTC 2021 romstage starting (log level: 7)... APIC 00: CPU Family_Model = 0663 APIC 00: ** Enter AmdInitReset [00020007] ASSERTION ERROR: file 'src/drivers/amd/agesa/state_machine.c', line 256 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/heapManager.c', line 332 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/Fch/Interface/InitResetDef.c', line 70 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/Fch/Interface/InitResetDef.c', line 73 Fch OEM config in INIT RESET ASSERTION ERROR: file 'src/vendorcode/amd/agesa/common/amdlib.c', line 768 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/common/amdlib.c', line 926 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/common/amdlib.c', line 817 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/common/amdlib.c', line 926 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/common/amdlib.c', line 768 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/common/amdlib.c', line 926 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/common/amdlib.c', line 817 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/common/amdlib.c', line 926 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/common/amdlib.c', line 768 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/common/amdlib.c', line 926 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/common/amdlib.c', line 817 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/common/amdlib.c', line 926 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/common/amdlib.c', line 768 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/common/amdlib.c', line 926 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/common/amdlib.c', line 817 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/common/amdlib.c', line 926 AmdInitReset() returned AGESA_SUCCESS APIC 00: Heap in LocalCache (2) at 0x0040 APIC 00: ** Exit AmdInitReset [00020007] APIC 00: ** Enter AmdInitEarly [00020002] ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/heapManager.c', line 332 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CreateStruct.c', line 205 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/Common/AmdInitEarly.c', line 169 ASSERTION ERROR: file 'src/drivers/amd/agesa/state_machine.c', line 256 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/heapManager.c', line 332 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/heapManager.c', line 332 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/heapManager.c', line 332 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/HT/htMain.c', line 562 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/heapManager.c', line 606 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 483 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/heapManager.c', line 606 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 872 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/heapManager.c', line 606 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 483 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/heapManager.c', line 606 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 872 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/heapManager.c', line 606 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 735 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/heapManager.c', line 606 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 483 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 261 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/heapManager.c', line 606 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 872 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 727 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 728 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/heapManager.c', line 606 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 735 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/heapManager.c', line 606 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 483 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 261 ASSERTION ERROR: file
