[coreboot] coreboot leadership meeting minutes for May 8 & May 22

[Martin Roth]

coreboot leadership meeting notes are now public:

https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ/edit#heading=h.j7tqwova2640

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

Topics:
* Results of polls (See
https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/OWHSSHB4F7FESMUGJKFRB37PR2AYM5LQ/)
   * Implement this after the 4.10 release.
   * Copyrights
  * Winner in poll: Create an authors file and remove all existing
copyright lines
  * 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
https://piratenpad.de/p/coreboot4.10-release-checklist

* 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
integration? https://github.com/cyrilix/its-redmine



8 May 2019
Attendees: PatrickG, Martin, Matt Devo, Felix Held, Stefan, Marc
Jones, Philipp, PatrickR, David Hendricks

Topics:
* 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 agai

[coreboot] Re: How to add NUVOTON NCT6776F support with serial port logic enabled ???

[Kyösti Mälkki]

On Wed, May 22, 2019 at 6:14 PM Дмитрий Понаморев  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.

Regards,
Kyösti
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to add NUVOTON NCT6776F support with serial port logic enabled ???

[Shreesh Chhabbi]

Usually LPC_CLKOUTx signals are programmed to native function, so that 
controller inside SOC generates the clock required. FSP code for LPC is stable 
enough to configure LPC controller registers to generate clocks. Did you verify 
configuration of all LPC gpios? They should be programmed to modes as 
recommended in EDS/data sheet.

Thanks,
Shreesh Chhabbi
Sr. Software Engineer
Ircona (www.ircona.com)

From: Дмитрий Понаморев 
Sent: Wednesday 22 May 2019 16:08
To: Shreesh Chhabbi 
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] How to add NUVOTON NCT6776F support with serial port 
logic enabled ???

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.

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 
enable/disable
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 coreboot-4.9/src/southbridge/intel/fsp_rangeley/lpc.c file:


/* 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 
mailto:schha...@ircona.com>>:
Hi,

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).

Thanks,
Shreesh Chhabbi
Sr. Software Engineer
Ircona (www.ircona.com)

-Original Message-
From: dponamo...@gmail.com 
mailto:dponamo...@gmail.com>>
Sent: Friday 17 May 2019 16:02
To: coreboot@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 # Floppy
device pnp 4e.1 off end # 
Parallel port
device pnp 4e.2 on  # COM1
io 0x60 = 0x3f8
irq 0x70 = 4
end
device pnp 4e.3 off end # COM2, 
IR
device pnp 4e.5 off end # 
Keyboard
device pnp 4e.6 off end # CIR
 

[coreboot] Re: How to add NUVOTON NCT6776F support with serial port logic enabled ???

[Дмитрий Понаморев]

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.

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
> enable/disable
> 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
coreboot-4.9/src/southbridge/intel/fsp_rangeley/lpc.c file:


/* 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 :

> Hi,
>
> 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).
>
> Thanks,
> Shreesh Chhabbi
> Sr. Software Engineer
> Ircona (www.ircona.com)
>
> -Original Message-
> From: dponamo...@gmail.com 
> Sent: Friday 17 May 2019 16:02
> To: coreboot@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 #
> Floppy
> device pnp 4e.1 off end #
> Parallel port
> device pnp 4e.2 on  #
> COM1
> io 0x60 = 0x3f8
> irq 0x70 = 4
> end
> device pnp 4e.3 off end #
> COM2, IR
> device pnp 4e.5 off end #
> Keyboard
> device pnp 4e.6 off end #
> CIR
> device pnp 4e.7 off end #
> GPIO6
> device pnp 4e.107 off end   #
> GPIO7
> device pnp 4e.207 off end   #
> GPIO8
> device pnp 4e.307 off end   #
> GPIO9
> device pnp 4e.8 off end #
> WDT
> device pnp 4e.108 off end   #
> GPIO0
> device pnp 4e.208 off end   #
> GPIOA
> device pnp 4e.308 off end   #

[coreboot] Ballot results

[Patrick Georgi via coreboot]

Hi everybody,

thanks to all contributors who voted on the issues brought up by
the coreboot leadership team. We had 119 eligible voters and three
questions.

I'll now summarize the results:

# How to handle copyright notices
https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_9e4f5ea789b9ceb9
59 of 119 eligible contributors voted

The options to choose from were:
- Create an authors file and remove all existing copyright lines
- Create an authors file but leave existing copyright lines
- Don't create an authors file or change existing copyright lines

"Create an authors file and remove all existing copyright lines"
won over both other options.


# Line length
https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_4707336f38d21793
68 of 119 eligible contributors voted

The options to choose from were:
-  96 characters
-  80 characters
-  88 characters
- 120 characters
- 132 characters
- no length limit

"96 characters" won over all other options.


# Automatic code formatting
https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_47ad51b336de3a6b
61 of 119 eligible contributors voted

The options to choose from were:
- 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.
- coreboot should stick with manual formatting.
- Code should just get automatically reformatted on a regular basis.

"Submitters should run clang-format ..." won over both other options.


There's a coreboot leadership meeting today where I'll present the
results to leadership in detail and decisions will be finalized there,
but the long and short of it is that out of the options presented,
contributors (overall) prefer automatically formatted code that
aims for 96 characters and without individual copyright lines in the
file headers over all other options.

There will be work to be done before these are implemented however.

I'll happily answer any questions on the election, its methodology
and the outcome.


Thanks,
Patrick // election supervisor
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado


signature.asc
Description: PGP signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Asus M5A88-V (EVO?) Status

[Mike Banon]

> did the ASUS KFSN4-DRE ever receive family 15h support, in addition to 10h? 
> or was that only the KGPE boards?

When I go to a "./src/mainboard/asus/kgpe-d16" or
"./src/mainboard/asus/kcma-d8" and do this search:
find . -type f -print0 | xargs -0 grep -n "15h"
 - there are multiple matches at their ./romstage.c and
./resourcemap.c , but when I'm doing the same at
"./src/mainboard/asus/kfsn4-dre", there is only one match:
./romstage.c:42:#include  ,
although there's the same single match for a "10h" search as well.

So it's a bit unclear if there's a "15h" support at KFSN4-DRE
currently, and - if there is none - maybe this 15h code from KGPE-D16
and KCMA-D8 could be somehow re-used for KFSN4-DRE. Hopefully, Timothy
Pearson could help to reply to your question, since he is a maintainer
for KFSN4-DRE board.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Gpg keys for coreboot distribution

[Mike Banon]

What's good about the AtomBIOS ROMs: you can use AtomDis tool ( [1] /
[2] ) to get some idea - about what's inside them and what they're
doing. Run "make" to compile it and then use a command like ./atomdis
pci1002,990b.rom F > pci1002,990b.rom.dis . I'm sharing my
disassemblies as .dis files at [3] repository and you're welcome to
take a look at them.

Although I don't think they could do anything malicious, as an
additional security measure you could consider the YABEL options
explained at the end of this message. E.g. " [to prevent] the Option
ROMs from doing dirty tricks with the CPU (such as installing SMM
modules or hypervisors) " . Personally I have the following
combination inside my .config shared at [4] , and haven't experienced
any GPU problems from them. Maybe a slightly stricter set of these
options would work perfectly as well, I haven't checked.

PCI_OPTION_ROM_RUN_YABEL [=y] Secure mode
YABEL_DIRECTHW [=y] Direct hardware access
YABEL_PCI_ACCESS_OTHER_DEVICES [=y] Allow Option ROMs to access other devices
YABEL_PCI_FAKE_WRITING_OTHER_DEVICES_CONFIG [=n] Fake success on
writing other device's config space
YABEL_VIRTMEM_LOCATION [=0x100] ( that was a default address, unchanged )

If you don't want to rely on someone else's AtomBIOS ROMs, you could
extract them by yourself while a proprietary UEFI is still flashed.
1) to get the integrated GPU AtomBIOS ROM, can use the "Retrieval via
Linux kernel" method: [5]
2) to get the discrete GPU AtomBIOS ROM, use (a bit time consuming!)
instructions provided here: [6]

Then you'll be able to compare them with what I have submitted. Extra
check is always good, e.g. because Matt's self-extracted AtomBIOS ROM
for iGPU turned out a bit different because of some minor hardware
differences (perhaps a slightly different LCD panel) - read a
discussion [7] . Soon I'm going to test his iGPU ROM version on my PC,
as well as maybe he would test my ROM version at his, to make sure
they are crosscompatible and that I don't have to provide the multiple
iGPU ROM versions inside my [8] patch.

[1] - https://cgit.freedesktop.org/~mhopf/AtomDis/
[2] - https://github.com/mikebdp2/AtomDis
[3] - https://github.com/mikebdp2/atombioses
[4] - https://review.coreboot.org/c/coreboot/+/32352
[5] - https://www.coreboot.org/VGA_support#Retrieval_via_Linux_kernel
[6] - https://mail.coreboot.org/pipermail/coreboot/2017-July/084660.html
[7] - 
https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/LKB4VKBFQ26ACC6D2D5I6FAKJY3WNAJB/
[8] - https://review.coreboot.org/c/coreboot/+/31944

=> YABEL configuration options: ( use / key at make menuconfig menu to
find out their menu path )

CONFIG_PCI_OPTION_ROM_RUN_YABEL: If you select this option, the x86emu
CPU emulator will be used to execute PCI Option ROMs. This option
prevents Option ROMs from doing dirty tricks with the system (such as
installing SMM modules or hypervisors), but it is also significantly
slower than the native Option ROM initialization method.

CONFIG_YABEL_PCI_ACCESS_OTHER_DEVICES: Per default, YABEL only allows
Option ROMs to access the PCI device that they are associated with.
However, this causes trouble for some onboard graphics chips whose
Option ROM needs to reconfigure the north bridge.

CONFIG_YABEL_PCI_FAKE_WRITING_OTHER_DEVICES_CONFIG: By default, YABEL
aborts when the Option ROM tries to write to other devices' config
spaces. With this option enabled, the write doesn't follow through,
but the Option ROM is allowed to go on. This can create issues such as
hanging Option ROMs (if it depends on that other register changing to
the written value), so test for impact before using this option.

CONFIG_YABEL_VIRTMEM_LOCATION: YABEL requires 1MB memory for its CPU
emulation. This memory is normally located at 16MB.

CONFIG_YABEL_DIRECTHW: YABEL consists of two parts: It uses x86emu for
the CPU emulation and additionally provides a PC system emulation that
filters bad device and memory access (such as PCI config space access
to other devices than the initialized one).
When choosing this option, x86emu will pass through all hardware
accesses to memory and I/O devices to the underlying memory and I/O
addresses. While this option prevents Option ROMs from doing dirty
tricks with the CPU (such as installing SMM modules or hypervisors),
they can still access all devices in the system.
Enable this option for a good compromise between security and speed.

Best regards,
Mike Banon






On Tue, May 21, 2019 at 10:31 PM Chris Laprise  wrote:
>
> On 5/20/19 12:02 PM, Mike Banon wrote:
> > Huge Thanks to Martin Roth, finally we got a permission from AMD to
> > merge the new microcode patches - and Martin has just merged them !
> > ;-) So the things became slightly easier and luckily now you could
> > disregard some microcode-related parts of my last message. And we need
> > to walk the same path for the AtomBIOS ROMs - should be successful
> > there as well, although perhaps would take another year or so :P
>
>

[coreboot] Re: inteltool does not properly dump gpio values for south bridge CM238 chipset

[justidl3]

Thanks, I was actually able to get it up and running on coreboot 4.9. The main 
issue was that i am on fedora, and CONFIG_STRICT_DEVMEM is enabled by default. 
adding GRUB_CMDLINE_LINUX"iomem=relaxed" while also adding the proper defines 
in gpio.c and gpio_group.c seemed to fix the issue. my output is now

= GPIOS =

--- GPIO Community 0 ---

PCR Port ID: 0xaf

--- GPIO Group GPP_A ---
0x0400: 0x301844000502 GPP_A0   RCIN#   
0x0408: 0x001944000402 GPP_A1   LAD0
0x0410: 0x001a44000402 GPP_A2   LAD1
0x0418: 0x001b44000402 GPP_A3   LAD2
0x0420: 0x001c44000402 GPP_A4   LAD3
0x0428: 0x001d44000600 GPP_A5   LFRAME# 
0x0430: 0x241e44000402 GPP_A6   SERIRQ  
0x0438: 0x001f44000900 GPP_A7   n/a 
0x0440: 0x002044000500 GPP_A8   CLKRUN# 
0x0448: 0x002144000600 GPP_A9   CLKOUT_LPC0 
0x0450: 0x002244000600 GPP_A10  CLKOUT_LPC1 
0x0458: 0x002344100102 GPP_A11  GPIO
0x0460: 0x002444000102 GPP_A12  GPIO
0x0468: 0x002544000600 GPP_A13  SUSWARN#/SUSPWRDNACK
0x0470: 0x302644000600 GPP_A14  SUS_STAT#   
0x0478: 0x002744000502 GPP_A15  SUS_ACK#
0x0480: 0x002844000201 GPP_A16  GPIO
0x0488: 0x002944000201 GPP_A17  GPIO
0x0490: 0x002a44000402 GPP_A18  ISH_GP0 
0x0498: 0x002b44000402 GPP_A19  ISH_GP1 
0x04a0: 0x002c44000402 GPP_A20  ISH_GP2 
0x04a8: 0x002d44000502 GPP_A21  ISH_GP3 
0x04b0: 0x002e44000201 GPP_A22  GPIO
0x04b8: 0x002f44100102 GPP_A23  GPIO
--- GPIO Group GPP_B ---
0x04c0: 0x003044000101 GPP_B0   GPIO
0x04c8: 0x003144000201 GPP_B1   GPIO
0x04d0: 0x003244000300 GPP_B2   GPIO
0x04d8: 0x003344000201 GPP_B3   GPIO
0x04e0: 0x003444000502 GPP_B4   CPU_GP3 
0x04e8: 0x003504000102 GPP_B5   GPIO
0x04f0: 0x003644000700 GPP_B6   SRCCLKREQ1# 
0x04f8: 0x003744000700 GPP_B7   SRCCLKREQ2# 
0x0500: 0x003844000700 GPP_B8   SRCCLKREQ3# 
0x0508: 0x003944000700 GPP_B9   SRCCLKREQ4# 
0x0510: 0x003a44000700 GPP_B10  SRCCLKREQ5# 
0x0518: 0x003b44000601 GPP_B11  n/a 
0x0520: 0x003c44000601 GPP_B12  SLP_S0# 
0x0528: 0x003d44000601 GPP_B13  PLTRST# 
0x0530: 0x003e42840101 GPP_B14  GPIO
0x0538: 0x003f44000300 GPP_B15  GPIO
0x0540: 0x004084800102 GPP_B16  GPIO
0x0548: 0x004144000201 GPP_B17  GPIO
0x0550: 0x004244000200 GPP_B18  GPIO
0x0558: 0x004344000200 GPP_B19  GPIO
0x0560: 0x00000600 GPP_B20  GSPI1_CLK   
0x0568: 0x004544000502 GPP_B21  GSPI1_MISO  
0x0570: 0x004644000600 GPP_B22  GSPIO_MOSI  
0x0578: 0x004744000201 GPP_B23  GPIO
--- GPIO Community 1 ---

PCR Port ID: 0xae

--- GPIO Group GPP_C ---
0x0400: 0x004844000602 GPP_C0   SMBCLK  
0x0408: 0x004944000402 GPP_C1   SMBDATA 
0x0410: 0x104a44000502 GPP_C2   SMBALERT#   
0x0418: 0x304b44000602 GPP_C3   SML0CLK 
0x0420: 0x304c44000402 GPP_C4   SML0DATA
0x0428: 0x004d44000200 GPP_C5   GPIO
0x0430: 0x GPP_C6   RESERVED
0x0438: 0x GPP_C7   RESERVED
0x0440: 0x005044000502 GPP_C8   UART0_RXD   
0x0448: 0x005144000600 GPP_C9   UART0_TXD   
0x0450: 0x005244000600 GPP_C10  UART0_RTS#  
0x0458: 0x005344000502 GPP_C11  UART0_CTS#  
0x0460: 0x005444000502 GPP_C12  UART1_RXD   
0x0468: 0x005544000600 GPP_C13  UART1_TXD   
0x0470: 0x005644000600 GPP_C14  UART1_RTS#  
0x0478: 0x005744000502 GPP_C15  UART1_CTS#  
0x0480: 0x305844000402 GPP_C16  I2C0_SDA
0x0488: 0x305944000602 GPP_C17  I2C0_SCL
0x0490: 0x305a44000402 GPP_C18  I2C1_SDA
0x0498: 0x305b44000602 GPP_C19  I2C1_SCL
0x04a0: 0x005c44000502 GPP_C20  UART2_RXD   
0x04a8: 0x005d44000600 GPP_C21  UART2_TXD   
0x04b0: 0x005e44000600 GPP_C22  UART2_RTS#  
0x04b8: 0x005f44000502 GPP_C23  UART2_CTS#  
--- GPIO Group GPP_D ---
0x04c0: 0x006044000600 GPP_D0   n/a 
0x04c8: 0x006144000600 GPP_D1   n/a 
0x04d0: 0x006244000500 GPP_D2   n/a 
0x04d8: 0x006344000600 GPP_D3   n/a 
0x04e0: 0x306444000402 GPP_D4   ISH_I2C2_SDA
0x04e8: 0x006544