over the past year I did some research on AMD’s controversial Secure Processor (formerly known as Platform Security Processor or PSP). Its firmware is stored in an undocumented area of UEFI images and so I wrote a tool that can parse it. I thought some of you might be interested in that: https://github.com/cwerling/psptool <https://github.com/cwerling/psptool>
It is accompanied by PSPTrace, which can correlate an SPI capture of a boot procedure to the AMD firmware entries so you can deduct some boot logic from it.
A coworker noticed that nvramtool (and the nvramtool man page) both refer to the option CONFIG_HAVE_OPTION_TABLE as the option set to include cmos.layout into the coreboot tables.
"%s: Item %s not found in coreboot table. Apparently, the "
"coreboot installed on this system was built without specifying "
However, CONFIG_HAVE_OPTION_TABLE is set by the board to indicate whether the board is cmos.layout capable. The actual option is CONFIG_USE_OPTION_TABLE, which depends upon CONFIG_HAVE_OPTION_TABLE. The code in src/lib/coreboot_table.c only adds the lb record to the coreboot tables if CONFIG_USE_OPTION_TABLE is set.
The other choice is to make src/lib/coreboot_table.c add the lb record if the board has a cmos.layout (CONFIG_HAVE_OPTION_TABLE) but then userland will have access to a layout that is ignored. I suppose this is what happens if you set CONFIG_STATIC_OPTION_TABLE. This doesn't seem like the right answer to me.
I think this is only cosmetic, but should I submit a patch to change this so that others are not also sidetracked?
Hello fellow corebooters,
i have succesfully build an rom for the asus kgpe-d16, with microcode
Does anybody has experience with this systemboard.
Is the current included ucode working with Opteron 63XX processors?
coreboot leadership meeting notes are now public:
Anyone interested in joining the leadership meetings in the future can
check the calendar on the coreboot website for call-in information.
22 May 2019
Attendees: PatrickG, Werner, Jay Talbott, Martin, Matt DeVillier,
Felix Held, Stefan, Kerry Brown, Ron, Philipp, Dhendricks
* Results of polls (See
* Implement this after the 4.10 release.
* Winner in poll: Create an authors file and remove all existing
* Discuss with SFC - need to figure out if there are any issues
with removing copyright lines.
* Characters per line
* Winner in poll: 96 character lines.
* Will reformat in conjunction with the clang-format
* Update the contributor guidelines now, but the tree will lag
behind for a while longer
* Reformatting with clang-format
* Winner in poll: Submitters should run clang-format before
submitting a patch and it should be rejected in gerrit if it’s not
formatted properly with an error telling them how to format it.
* Will reformat the tree on a directory-by-directory basis and
enforcement will start as directories are reformatted
* Need to finalize clang-format options before we start
* src/vendorcode will not be reformatted
* Number of people voting varied by question 59/68/61
* coreboot contributor expectations
* This will be a guideline for now - No significant penalties at this point.
* Code should be maintained as long as a chip/platform is being sold?
* Stefan feels that we shouldn’t have different guidelines for
individuals and companies.
* David feels like rejecting patches is going to stifle progress.
* We will discuss this further on the mailing list.
* If we make guidelines, the community will likely take these as
rules and reject patches if they aren’t followed.
* No decision made for now, review again next week.
* Shall we add a CREDITS file a la Linux for people who contributed
but are no longer active?
* How is this different than the authors file?
* Credits is for people who are no longer involved in the
project. This is for people who authored code that is no longer in
the master branch.
* Can we make this part of the AUTHORS file? Or does it need to be
its own thing?
* Decision: Put the credits list in the Authors file.
* Can we adopt on principle removing all cpp guards on protos?
* Add cleanup task - remove guards specifically around prototypes?
* Having the prototypes outside of guards turns a compile time
error into a linker error.
* We should be more strict about how we define our blocks’ APIs.
We should make better definitions about what each block exports.
Document these better, and maybe be more strict about what code
consumes which function.
* Keep header file guards
* No decision made for now
* Release - still plan releasing on May 28th.
* Need to update release notes. Pad at
* Issue tracker:
* Philipp: Can we replace redmine?
* Stephan: Not with bugzilla. We've already tried bugzilla and trac.
* Monorail? Only runs on app engine.
* Some people are not sure how to address issues on current
bugtracker as there’s no gerrit integration.
* There is a Gerrit redmine plugin, which might help
* Use github as our bugtracker?
* This would probably encourage other github use like
merge-requests, which we don’t want.
* “its-redmine” (or other plug-in) for gerrit-redmine
8 May 2019
Attendees: PatrickG, Martin, Matt Devo, Felix Held, Stefan, Marc
Jones, Philipp, PatrickR, David Hendricks
* People are trying to subscribe to the coreboot security mailing
list. Who should be on that list (and what criteria decide this)?
* We don’t want this to be widely available to the public in case a
significant security issue is announced. We want to make sure we can
fix it before it’s announced to the public.
* There’s currently nothing on the list, maybe because out code is
great, and maybe because the list isn’t widely known.
* Who should have access?
* Currently Stefan & Patrick are the only 2 on the list
* Martin: people who can merge code to coreboot?
* Should we turn this into an alias instead of a mailing list?
* AI:Patrick Add the security list to the website and announce on
the mailing list.
* Decision: Keep as a list so that there’s an archive
* Decision: Keep the Stefan & Patrick as the only people on the list for now
* Decision: Bring this up again once there is activity on security@
and we know better what to do.
* Community votes
* Decision: The poll will be set up to start on Tuesday (May 14),
running until the next leadership meeting on May 22nd.
* 4.10 process (pgeorgi hasn’t announced anything yet)
* AI:Patrick will announce today
* 4 students have been accepted
* All have arrived on the mailing list or IRC
* Finding a leadership group replacement for Marc
* David Hendricks is the only one who responded to the self nomination.
* Werner supports David to replace Marc (as claimed by Martin)
* Stefan supports David
* Marc also supports David
* Decision: David Hendricks is voted in to replace Marc
* David: “Thank you”
* AI: Martin will notify the SFC (Done)
* Martin to push picasso documentation to coreboot
* Writing now, Need to get permission from AMD before publishing.
* OSF Hackathon (June, Bochum)
* Lunch will be served there, dinner is Hunt-Your-Own-Food
* We have some sponsors, but are still getting more
* Ron needs photos from people “looking younger than they look
today” for his anniversary talk
* FSP 1.0 migration
* Intel doesn’t seem to want to invest any resources in an update
* Who is the owner for these at Intel? Is there a contact at this point?
* Dhendricks might be able to work to get these updated to FSP 2.0
* AI: Patrick will look into the reasons for the migration
(mailing list etc) and potentially write up a doc
* Issue tracker
* Over 200 users have applied but haven’t been authorized (never logged in).
* Set up automatic notifications on IRC & current mailing list (&
Set up new Mailing list if the bugs become too noisy)
* AI: Patrick will look for plugins to get this set up.
The controversial decision but the console output is not connected directly
to the processor but to the superio Nuvoton.
I did not find any settings to enable LPC (LPC_EN) for the Atom C2000 to.
In atom-c2000-microserver-datasheet-334978.pdf I found register LPCC (LPC
This register includes LPC_CLKOUT1. As far as I understood, the nuvoton
uses this signal.
LPC Clock Enabling
> The LPC clock signal, LPC_CLKOUT1, is enabled or disabled by the software
> through the
> 32-bit LPCC register at offset 84h in the configuration space at bus 0,
> device 31
> (decimal), function 0.
> The LPC clock signal, LPC_CLKOUT0, is always enabled. It also has an
> bit in the 32-bit LPCC register at offset 84h, but the bit is read-only
> and always set to
> enable LPC_CLKOUT0.
I did not see any signals on the oscilloscope. I tried to enable it by
adding a function to the
/* Tutn on LPC_CLK1 for nuvoton
IBASE = 0x50
ILB_LPCC = 0x84 (LPC_CLCOUT[0:1])
static void soc_enable_lpc_clk1(struct device *dev)
u32 reg32 = 0;
u8 *ilb_base = (u8 *)(pci_read_config32(dev, IBASE) & ~0x0f);
reg32 = read32(ilb_base + ILB_LPCC);
write32(ilb_base + ILB_LPCC, (reg32 | 0x3));
Clock signals LPC_CLKOUT1 appeared, but it did not help. Super io does not
appear in Linux.
What else you need to configure in LPC controller and(or) in Nuvotone so
that the device can be seen in Linux?
What utility can I get it with?
> You can also compare the register banks of PCI 0:1f.0.
сб, 18 мая 2019 г. в 14:36, Shreesh Chhabbi <schhabbi(a)ircona.com>:
> Is the serial port where you are trying to capture logs, coming out of
> Nuvoton controller or the Atom Processor?
> If serial port is coming out of Nuvoton:
> Usually the controller connected on LPC to the main processor is accessed
> via IO ports. Controller needs to have code change to support this. If you
> have Intel CRB's reference code for main processor and controller, you
> could look for supported commands to EC. I have encountered post code print
> on the seven segment displays via EC from main processor. But serial
> console is always directly from main processor.
> If serial port is coming out of main processor:
> The UART controller is seen as a PCI device to the CPU. You need to
> enumerate this and initialize and use it for dumping bytes onto serial
> console (available in Intel CRB reference code usually).
> Shreesh Chhabbi
> Sr. Software Engineer
> Ircona (www.ircona.com)
> -----Original Message-----
> From: dponamorev(a)gmail.com <dponamorev(a)gmail.com>
> Sent: Friday 17 May 2019 16:02
> To: coreboot(a)coreboot.org
> Subject: [coreboot] How to add NUVOTON NCT6776F support with serial port
> logic enabled ???
> There is a Lanner FW-7573 platform based on the Intel Rangeley Atom C2000
> series processor.
> To work with the Serial port in this platform, the NUVOTON NCT6776F chip
> is connected via the LPC bus to the processor.
> I just can’t get Serial port working for debuging. I take as a basis intel
> littleplains board. I tried to add NCT6776F support following the example
> of other boards - without success. There is no output to the console, and
> in Linux, the superiotool program does not see the NCT6776F.
> On the official version of the BIOS I loaded linux OS and took a dump.
> (superiotool r => Found Nuvoton NCT6776F/D (C) (id=0xc333) at 0x4e) )
> How to add NUVOTON NCT6776F support with serial port logic enabled ???
> in devicetree.cb I add:
> device pci 1f.0 on # LPC bridge
> chip superio/nuvoton/nct6776
> device pnp 4e.0 off end #
> device pnp 4e.1 off end #
> Parallel port
> device pnp 4e.2 on #
> io 0x60 = 0x3f8
> irq 0x70 = 4
> device pnp 4e.3 off end #
> COM2, IR
> device pnp 4e.5 off end #
> device pnp 4e.6 off end #
> device pnp 4e.7 off end #
> device pnp 4e.107 off end #
> device pnp 4e.207 off end #
> device pnp 4e.307 off end #
> device pnp 4e.8 off end #
> device pnp 4e.108 off end #
> device pnp 4e.208 off end #
> device pnp 4e.308 off end #
> device pnp 4e.109 off end #
> device pnp 4e.209 off end #
> device pnp 4e.309 off end #
> device pnp 4e.409 off end #
> device pnp 4e.509 off end #
> device pnp 4e.609 off end #
> device pnp 4e.709 off end #
> device pnp 4e.a on end #
> device pnp 4e.b off end #
> HWM, front pannel LED
> device pnp 4e.d off end #
> device pnp 4e.e off end #
> CIR WAKE-UP
> device pnp 4e.f off end #
> device pnp 4e.14 off end #
> device pnp 4e.16 off end #
> Deep sleep
> device pnp 4e.17 off end #
> end # LPC bridge
> In superio.asl i add:
> #undef SUPERIO_DEV
> #undef SUPERIO_PNP_BASE
> #define SUPERIO_DEV SIO0
> #define SUPERIO_PNP_BASE 0x4e
> #define NCT6776_SHOW_PP
> #define NCT6776_SHOW_SP1
> #define NCT6776_SHOW_KBC
> #define NCT6776_SHOW_HWM
> #define NCT6776_SHOW_GPIO
> #include <superio/nuvoton/nct6776/acpi/superio.asl>
> in romstage.c add function mainboard_config_superio:
> void mainboard_config_superio(void)
> /* Enable UART */
> /* Select SIO pin states. */ As in Dump........
> pnp_write_config(GLOBAL_DEV, 0x13, 0xff);
> pnp_write_config(GLOBAL_DEV, 0x14, 0xff);
> pnp_write_config(GLOBAL_DEV, 0x1b, 0x53);
> pnp_write_config(GLOBAL_DEV, 0x1c, 0x80);
> pnp_write_config(GLOBAL_DEV, 0x24, 0x24);
> pnp_write_config(GLOBAL_DEV, 0x27, 0xc0);
> pnp_write_config(GLOBAL_DEV, 0x2b, 0x03);
> pnp_write_config(GLOBAL_DEV, 0x2a, 0x00);
> pnp_write_config(GLOBAL_DEV, 0x2c, 0x80);
> /* Power RAM in S3. */
> //pnp_write_config(ACPI_DEV, 0xe4, 0x10);
> nuvoton_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE); }
> coreboot mailing list -- coreboot(a)coreboot.org To unsubscribe send an
> email to coreboot-leave(a)coreboot.org
you can define the settings for unavailable clock synthesizer
An example of UART clock setting defined in
what are the configuration options to be set for IDT clock 9VRS4420DKLFT?
Do you have datasheet for 9VRS4420DKLFT
Is this the one?
From: Дмитрий Понаморев <dponamorev(a)gmail.com<mailto:email@example.com>>
Sent: Friday 24 May 2019 15:23
To: Kyösti Mälkki <kyosti.malkki(a)gmail.com<mailto:firstname.lastname@example.org>>
Cc: Shreesh Chhabbi <schhabbi(a)ircona.com<mailto:email@example.com>>; coreboot(a)coreboot.org<mailto:firstname.lastname@example.org>
Subject: [coreboot] Re: How to add NUVOTON NCT6776F support with serial port logic enabled ???
Thank for help!
The LPC_CLKOUT1 clock signal appeared but there is no nuvoton chip detected in linux.
I could not turn off the SOC UART yet. With my changes, the system does not start well (stops at post code 0x46, 0x47).
/*Disabled SOC UART1 & UART2*/
reg32 = pci_read_config32(SOC_LPC_DEV /*(0,1f,0)*/, UART_CONT /*0x80*/);
reg32 = reg32 & (~0x3);
pci_write_config32(SOC_LPC_DEV, UART_CONT, reg32);
And the most important thing is that the Nuvoton System Clock (48 MHz for the baud generator of the UARTs) is missing.
IDT clock synthesizer (9VRS4420DKLFT) is responsible for the formation of this clock. This clock synthesizer provides reference clocks for I/O interfaces, SATA, USB, Gbe and PCI Express.
At the initial moment of time, the clock synthesizer is initialized via the SMB bus (I can see it with an oscilloscope). But no 48 MHz clock for Nuvoton.
Nuvoton System Clock, use the USB_48M_2X contact of 9VRS4420DKLFT, which is normally not used.
How can I change the IDT clock synthesizer (9VRS4420DKLFT) settings in coreboot? Rather, where can I make changes in coreboot to properly configure IDT clock synthesizer (9VRS4420DKLFT)?
ср, 22 мая 2019 г. в 21:46, Kyösti Mälkki <kyosti.malkki(a)gmail.com<mailto:email@example.com>>:
On Wed, May 22, 2019 at 6:14 PM Дмитрий Понаморев <dponamorev(a)gmail.com<mailto:firstname.lastname@example.org>> wrote:
> The controversial decision but the console output is not connected directly to the processor but to the superio Nuvoton.
> I did not find any settings to enable LPC (LPC_EN) for the Atom C2000 to.
> In atom-c2000-microserver-datasheet-334978.pdf I found register LPCC (LPC control register).
> This register includes LPC_CLKOUT1. As far as I understood, the nuvoton uses this signal.
Okay then. The paragraphs of datasheet you should be interested are:
24.2.4 about the LPC routing rules. It says anything not positively
decoded by SOC integrated peripherals will be routed to LPC.
20.2 and 20.3 to disable the SoC's integrated UART devices. When
enabled, they would positively decode 0x3f8 and 0x2f8 (bases) and
prevent those from being routed to LPC controller.
If you previously did not have LPC_CLK running for the Nuvoton part in
your coreboot build, it explains why util/superiotool did not detect
Nuvoton. If you did not do so already, run that tool again. Hopefully
you see something on 0x4e now.
SuperIOs typically have another clock input pin (either 24 MHz or 48
MHz) for the baud generator of the UARTs. If you get that Nuvoton
detected, and disable SoC UARTs, and still have no serial output, I
would trace the source for that clock next.