[coreboot] Re: [SPECIFICATION RFC v3] The firmware and bootloader log specification
> Since it doesn't seem possible to have each boot component using the same log > format, we added a log_format and log_phys_addr fields to give flexibility in > how logs are stored. An example of a different log format that can be used is > the cbmem_console log format used by coreboot: I am not exactly sure how you expect this interoperability you seem to be suggesting here to work. Are you saying that your bf_log_header can sometimes point to the bf_log_buffer structure you define, and sometimes to a coreboot CBMEM console buffer? But that's a completely different format that requires a different reader implementation, how is that supposed to work? If this proposal is just "we define a wrapper structure that points to everyone's custom firmware log implementation", then I don't really see the point (the only benefit still left then might be discovery of the log buffer, but that's the part you leave open in your design while all those other implementations already have working discovery mechanisms of their own anyway). For the other structures you have defined, the same feedback that I think was already mentioned on the last iteration of this thread still applies: it seems incredibly bloated for a simple firmware logging mechanism. You have a whooping 24+n bytes of overhead *per line* which probably comes out to somewhere between 30-50% of total space wasted on overhead for the average log buffer. I guess there are just fundamentally different opinions on how featureful a firmware log mechanism needs to be so we're probably not gonna find a format that makes everyone happy here, but at least for the coreboot project I see little reason for us to implement something like this when we already have a well-working existing solution with tooling and wideranged support. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: [SPECIFICATION RFC v3] The firmware and bootloader log specification
Alec Brown wrote: > Below is how the layout of these logs would store their data. > > bf_log_header: >+---+ > u32| version | > u32| size | > u8[64] | producer | > u8[64] | log_format| > u64| flags | > u64| next_bflh_addr| > u64| log_addr | > u32| log_size | >+---+ I suggest to include a .magic at least in bf_log_header and an .xor_checksum or .crc32 only in bf_log_header. .magic doubles as endianess indicator when the structures are stored on movable media. (Pick an asymmetric magic bit pattern!) I suggest renaming .next_bflh_addr to .next_log_header and .log_addr to .log_buffer_addr. I suggest to remove .size and .log_size: The rationale for .size is "to allow for backward compatibility" but that seems redundant thanks to .version. .log_size can be calculated from the subordinate data and is thus mostly an unneccessary source of potential inconsistency. > bf_log_buffer: >+---+ > u32| version | > u32| size | > u8[64] | producer | > u32| next_msg_off | > bf_log_msg[l] | msgs | >+---+ I suggest replacing .size and .next_msg_off with .messages containing l: .size can then be calculated from .messages; again, reliably avoiding inconsistency between .size and .next_msg_off. Allocated size doesn't seem useful if writers must anyway maintain state containing the starting address. If writers must be allowed to be completely stateless then maybe at least rename .size to .allocated_size and see below for discovery. Having .messages also eliminates the need for an end-of-messages marker when the allocated space is not yet filled. > bf_log_msg: >+---+ > u32| size | > u64| ts_nsec | > u32| level | > u32| facility | > u32| msg_off | > u8[n] | type | > u8[m] | msg | >+---+ It seems inconsistent that log_header.size and log_msg.size cover only the respective struct itself while log_buffer.size also covers all subordinate messages. Skipping all .size in this version fixes that. And log_msg.size is not very useful since both .type and .msg have variable length; it's not possible to access .msg without scanning .type. Please at a minimum add .type_size but better yet replace .size with .type_size and .msg_size. > There is still the outstanding issue of how the logs will be sent to the OS. > If > UEFI is used, we can use config tables. If ACPI or Device Tree is used, we can > use bf_log_header.next_bflh_addr to present the logs. If none of these > platforms > are used, it becomes a lot trickier to solve this issue. > > Any suggestions are much appreciated and will be taken into consideration. Having bf_log_header.magic and some bf_log_header.$checksum, a strict rule for bf_log_header start address granularity and a strict maximum offset for the first header from top and/or bottom of memory allows to quickly discover a log in memory without explicit handover. > LPC System Boot and Security Micro-conference on the 22nd of September > at 7:50 AM PDT (14:50 UTC). Have fun! :) Heinrich Schuchardt wrote: > We already the EFI_TCG2_PROTOCOL and RFC 5424 (The syslog protocol). > Why do we need to start from scratch? That's a good question. I guess noone wants to settle for a standard from somewhere else. ;) I wouldn't mind if log_msg was a syslog transport, but I can understand if that's rejected because syslog messages require a lot of parsing for presentation while Alec's proposal seems focused on efficiency and simplicity. It's also nice to be able to strictly mandate UTF-8 for all fields. (RFC 5424 allows MSG to be anything.) Kind regards //Peter ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Mailing list archive not updating
I was just checking the mailing list archive and noticed that it isn't showing any new messages since September 9. I wasn't able to determine if there was a mailing list admin address to send this to, so I hope just sending it to the list is okay. (I did see this "mail...@coreboot.org alias for mailman admins" while searching, but wasn't sure about it, since it doesn't actually show up on the available lists page.) ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: T430: Flashing using plug contacts instead of fully disassembling the laptop
What you are looking is pomera clip. Try searching Ali for "soic8 clip" there are plenty even with proggrammers sometimes On September 17, 2021 4:44:19 PM UTC, Nico Huber wrote: >Hi Daniel, > >On 17.09.21 18:06, Daniel Kulesz via coreboot wrote: >> I plan to flash a Thinkpad T430. According to an article in the german >> "golem.de" magazine [1] accessing the flash via SPI is possible by >> connecting the wires from the SPI flasher to plug contacts on the upper side >> of the board - without disassembling the whole device. Unfortunately, I was >> unable to find the details regarding these contacts neither in the coreboot >> docs nor anywhere else. Did I look in the wrong places or is this simply not >> publically documented? > >I don't know any documentation about this. But a good reference are >the schematics which can usually be found easily on the web for these >old Thinkpads. Just google for the code name[2], this one should be >nozomi-4. > >Don't know if this is exactly what you are looking for. But there >are two headers shown, much like in the "example" *wink* ;) picture >attached. There, J27 is for emulation of both flash chips and J14 >is for directly flashing the second chip. I guess J14 can be used >for flashing the first chip too, by using -SPI_CS0 from J27. But >you will definitely want to attach VCC at J14 because that's where >the board is protected by a diode. > >Hope that helps, >Nico > >> [1] >> https://www.golem.de/news/coreboot-und-nitrokey-mein-acht-jahre-alter-laptop-wird-zur-festung-2012-152931.html >[2] https://doc.coreboot.org/mainboard/lenovo/codenames.html ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Coreboot help/teaching
Hi Patrick, Welcome to coreboot and I hope you have a lot of fun with it! Patrick Charon wrote: > But now, I want to go deeper again, and install it on a real machine. > The computer I selected is an old laptop from 2005 This isn't a great way to start - I'd suggest to select a computer known to work with coreboot rather than whatever happens to be available, and especially not to select a laptop. Making coreboot reliably work correctly on a previously unsupported laptop requires significant effort and can take between days and years (no joke) depending on a large number of factors, some of which are out of (y)our control. If you do want to go ahead with that hardware then please start by constructing a workable development environment, because as you anticipate the first attempt is not likely to be successful. At a bare minimum you need a way to recover from a non-booting system, ie. an external flash programmer. > P.-S.: this address is my "professional" address; my personal address > p...@galaxyhit.com often goes to spam. But if you answer, please use this > personal address! List etiquette differs from list to list, on the coreboot list the rule is to be subscribed with the address you want to use and to not Cc: all thread participants in replies, I've done so anyway because of your request but please arrange for your desired address to be subscribed. Remember that your outbound messages are resent by the mailing list which should mitigate any bad reputation your mailhost might have. Kind regards //Peter ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] custom board profile
So now that I have the GPIO for my board, what else is needed? How do I setup a custom board profile in coreboot? How much debug/testing would be needed? How would that be done? ___ 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
As pointed out by you, PCIe link might not yet have completed the training.
Maybe checking the link training completion bit until a certain timeout
can be an ideal solution.
Try the diff below:
diff --git a/src/device/pci_device.c b/src/device/pci_device.c
index 4b5e73b806..c96e9f1e9d 100644
--- a/src/device/pci_device.c
+++ b/src/device/pci_device.c
@@ -1213,6 +1213,7 @@ static void pci_scan_hidden_device(struct device *dev)
* @param min_devfn Minimum devfn to look at in the scan, usually 0x00.
* @param max_devfn Maximum devfn to look at in the scan, usually 0xff.
*/
+#define PCIE_TRAIN_RETRY 1
void pci_scan_bus(struct bus *bus, unsigned int min_devfn,
unsigned int max_devfn)
{
@@ -1254,6 +1255,14 @@ void pci_scan_bus(struct bus *bus, unsigned int
min_devfn,
continue;
}
+ /* Wait for training to complete */
+ u16 lnk, try, cap = pci_find_capability(dev,
PCI_CAP_ID_PCIE);
+ for (try = PCIE_TRAIN_RETRY; try > 0; try--) {
+ lnk = pci_read_config16(dev, cap + PCI_EXP_LNKSTA);
+ if (!(lnk & PCI_EXP_LNKSTA_LT))
+ break;
+ udelay(100);
+ }
/* See if a device is present and setup the device
structure. */
dev = pci_probe_dev(dev, bus, devfn);
Regards,
Naresh
On Tue, Sep 21, 2021 at 4:48 PM Sumo wrote:
> Hi,
>
> Anything else can be tried instead of using simple delays?
> Perhaps during the enumeration for some devices a delay is really
> required, for the NVMe case the vendor/device ID pair isn't detected at
> all... I'm not sure if the PCIe link is still training (I don't have an
> analyzer) 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 compare the logs with and without the delay.
>>
>> Here are my findings:
>> - without the delay in dev_enumerate() the NVMe because isn't detected at
>> all (i.e. the PCIe device isn't shown in the bus):
>> PCI: 00:0b.0 scanning...
>> do_pci_scan_bridge for PCI: 00:0b.0
>> PCI: 00:0b.0: Enabled LTR
>> PCI: pci_scan_bus for bus 04
>> POST: 0x24
>>
>> *PCI: Static device PCI: 04:00.0 not found, disabling it.*POST: 0x25
>> PCI: Leftover static devices:
>> PCI: 04:00.0
>> PCI: Check your devicetree.cb.
>> POST: 0x55
>> scan_bus: bus PCI: 00:0b.0 finished in 0 msecs
>>
>> - by adding the delay the device is detected and initialized:
>> PCI: 00:0b.0 scanning...
>> do_pci_scan_bridge for PCI: 00:0b.0
>> PCI: 00:0b.0: Enabled LTR
>> PCI: pci_scan_bus for bus 04
>> POST: 0x24
>>
>> *PCI: 04:00.0 [1987/5012] enabled*POST: 0x25
>> POST: 0x55
>> Enabling Common Clock Configuration
>> PCIE CLK PM is not supported by endpoint
>> L1 Sub-State supported from root port 11
>> L1 Sub-State Support = 0xf
>> CommonModeRestoreTime = 0x28
>> Power On Value = 0x6, Power On Scale = 0x1
>> ASPM: Enabled L1
>> PCIe: Max_Payload_Size adjusted to 256
>> PCI: 04:00.0: Enabled LTR
>> PCI: 04:00.0: Programmed LTR max latencies
>> scan_bus: bus PCI: 00:0b.0 finished in 0 msecs
>>
>> Also, another device is failing if I remove the delay - it's a I211
>> gigabit ethernet controller:
>> PCI: 00:0f.0 scanning...
>> do_pci_scan_bridge for PCI: 00:0f.0
>> PCI: 00:0f.0: Enabled LTR
>> PCI: pci_scan_bus for bus 05
>> POST: 0x24
>>
>> *PCI: Static device PCI: 05:00.0 not found, disabling it.*POST: 0x25
>> PCI: Leftover static devices:
>> PCI: 05:00.0
>> PCI: Check your devicetree.cb.
>> POST: 0x55
>> scan_bus: bus PCI: 00:0f.0 finished in 0 msecs
>>
>> With the delay the I211 is detected:
>> PCI: 00:0f.0 scanning...
>> do_pci_scan_bridge for PCI: 00:0f.0
>> PCI: 00:0f.0: Enabled LTR
>> PCI: pci_scan_bus for bus 05
>> POST: 0x24
>>
>> *PCI: 05:00.0 [8086/1539] enabled*POST: 0x25
>> POST: 0x55
>> Enabling Common Clock Configuration
>> PCIE CLK PM is not supported by endpoint
>> ASPM: Enabled L1
>> PCIe: Max_Payload_Size adjusted to 256
>> PCI: 05:00.0: No LTR support
>> scan_bus: bus PCI: 00:0f.0 finished in 0 msecs
>>
>> Full logs are attached.
>>
>> Kind regards,
>> Sumo
>>
>> On Mon, Aug 16, 2021 at 8:01 PM Sumo wrote:
>>
>>> 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
[coreboot] Re: Denverton: NVMe not detected when serial console logs are disabled
Hi, Anything else can be tried instead of using simple delays? Perhaps during the enumeration for some devices a delay is really required, for the NVMe case the vendor/device ID pair isn't detected at all... I'm not sure if the PCIe link is still training (I don't have an analyzer) 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 compare the logs with and without the delay. > > Here are my findings: > - without the delay in dev_enumerate() the NVMe because isn't detected at > all (i.e. the PCIe device isn't shown in the bus): > PCI: 00:0b.0 scanning... > do_pci_scan_bridge for PCI: 00:0b.0 > PCI: 00:0b.0: Enabled LTR > PCI: pci_scan_bus for bus 04 > POST: 0x24 > > *PCI: Static device PCI: 04:00.0 not found, disabling it.*POST: 0x25 > PCI: Leftover static devices: > PCI: 04:00.0 > PCI: Check your devicetree.cb. > POST: 0x55 > scan_bus: bus PCI: 00:0b.0 finished in 0 msecs > > - by adding the delay the device is detected and initialized: > PCI: 00:0b.0 scanning... > do_pci_scan_bridge for PCI: 00:0b.0 > PCI: 00:0b.0: Enabled LTR > PCI: pci_scan_bus for bus 04 > POST: 0x24 > > *PCI: 04:00.0 [1987/5012] enabled*POST: 0x25 > POST: 0x55 > Enabling Common Clock Configuration > PCIE CLK PM is not supported by endpoint > L1 Sub-State supported from root port 11 > L1 Sub-State Support = 0xf > CommonModeRestoreTime = 0x28 > Power On Value = 0x6, Power On Scale = 0x1 > ASPM: Enabled L1 > PCIe: Max_Payload_Size adjusted to 256 > PCI: 04:00.0: Enabled LTR > PCI: 04:00.0: Programmed LTR max latencies > scan_bus: bus PCI: 00:0b.0 finished in 0 msecs > > Also, another device is failing if I remove the delay - it's a I211 > gigabit ethernet controller: > PCI: 00:0f.0 scanning... > do_pci_scan_bridge for PCI: 00:0f.0 > PCI: 00:0f.0: Enabled LTR > PCI: pci_scan_bus for bus 05 > POST: 0x24 > > *PCI: Static device PCI: 05:00.0 not found, disabling it.*POST: 0x25 > PCI: Leftover static devices: > PCI: 05:00.0 > PCI: Check your devicetree.cb. > POST: 0x55 > scan_bus: bus PCI: 00:0f.0 finished in 0 msecs > > With the delay the I211 is detected: > PCI: 00:0f.0 scanning... > do_pci_scan_bridge for PCI: 00:0f.0 > PCI: 00:0f.0: Enabled LTR > PCI: pci_scan_bus for bus 05 > POST: 0x24 > > *PCI: 05:00.0 [8086/1539] enabled*POST: 0x25 > POST: 0x55 > Enabling Common Clock Configuration > PCIE CLK PM is not supported by endpoint > ASPM: Enabled L1 > PCIe: Max_Payload_Size adjusted to 256 > PCI: 05:00.0: No LTR support > scan_bus: bus PCI: 00:0f.0 finished in 0 msecs > > Full logs are attached. > > Kind regards, > Sumo > > On Mon, Aug 16, 2021 at 8:01 PM Sumo wrote: > >> 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 >>> >> ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
