This is a µATX mainboard with a LGA1151 socket and two DDR4 DIMM slots.
There are two possible BOM configurations: Sid has no legacy devices,
whereas Manny provides two serial ports, a parallel port, a PCI slot
and PS/2 keyboard/mouse connectors. These boards also have different
Super I/O models: Manny uses an ITE IT8625E, whereas legacy-free Sid
comes with an ITE IT8656E instead.
This coreboot port has been done using a Sid board, thus support for
Manny-specific features is missing. Booting should still be possible,
though: none of these legacy features is essential.
The board has an unpopulated 6-pin header, wired to PCH UART 2. This
can be used to retrieve coreboot logs.
Working:
- Both DIMM slots (Micron CT4G4DFS8213.8FA11, Hynix HMA851U6AFR6N-UH)
- PCH SerialIO UART 2 to get coreboot logs
- Rear USB ports
- Realtek RTL8111 GbE NIC
- Integrated graphics on DVI with libgfxinit
- At least one SATA port
- Flashing internally with flashrom
- S3 suspend/resume
- VBT
- SeaBIOS 1.14 to boot Arch Linux (kernel linux-5.10.15.arch1-1)
Untested:
- Audio
- VGA: DP2VGA chip uses DDI E, and libgfxinit doesn't support DDI E yet
- Front USB headers
- Non-Linux OSes
- PCI slot
- IT8625E peripherals: serial, parallel and PS/2 ports
Change-Id: Iadf11c187307a24b15039a5a716737d9d74944e6
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48386
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch changes the memlayout macro infrastructure so that the size
of a region "xxx" (i.e. the distance between the symbols _xxx and _exxx)
is stored in a separate _xxx_size symbol. This has the advantage that
region sizes can be used inside static initializers, and also saves an
extra subtraction at runtime. Since linker symbols can only be treated
as addresses (not as raw integers) by C, retain the REGION_SIZE()
accessor macro to hide the necessary typecast.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ifd89708ca9bd3937d0db7308959231106a6aa373
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49332
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This adds initial support for the Pine64 ROCKPro64 board.
The ROCKPro64 (http://pine64.org/rockpro64) is a SBC using the
RK3399 SoC with up to 4GB LPDDR4.
So far only the bootblock part works, the romstage starts to execute,
though.
For ramstage to work we'll need to port some of the changes required
for LPDDR4 vs LPDDR3. This will be addressed in follow up changes.
UART2 on the PI-2 connector can be used as a coreboot console.
GND is pin 6
TXD is pin 8
RXD is pin 10
Flashing:
I used an OpenWRT nightly for the ROCKPro64 and its builtin tool.
$ mtd write coreboot.rom /dev/mtd0
Recovering from a bad flash:
To recover from a bad flash bridging pins 23 and 25 on the PI-2
connector will make the board boot from SD card.
Signed-off-by: Moritz Fischer <moritzf@google.com>
Change-Id: I47d0031fff8ee10b11ad74935eaeb05f1f7eb4b3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50625
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The thing that this function initializes is the MPLL (Memory PLL). So,
call it by its name. Also add a missing newline in a printk, and update
a comment on the callsite of this function.
Tested on Asus P8Z77-V LX2, still boots.
Change-Id: I86ab643bc87253554346dfed3630eb9ddbd44eb3
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45502
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
This write was copied from Sandy Bridge. Neither Haswell reference code
nor Broadwell perform this write. Therefore, it seems safe to remove it.
Change-Id: I8869ff3e66362d9910235c554c3a07e91f479a82
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46994
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
cbfstool has always had a CBFS_FILENAME_ALIGN that forces the filename
field to be aligned upwards to the next 16-byte boundary. This was
presumably done to align the file contents (which used to come
immediately after the filename field).
However, this hasn't really worked right ever since we introduced CBFS
attributes. Attributes come between the filename and the contents, so
what this code currently does is fill up the filename field with extra
NUL-bytes to the boundary, and then just put the attributes behind it
with whatever size they may be. The file contents don't end up with any
alignment guarantee and the filename field is just wasting space.
This patch removes the old FILENAME_ALIGN, and instead adds a new
alignment of 4 for the attributes. 4 seems like a reasonable alignment
to enforce since all existing attributes (with the exception of weird
edge cases with the padding attribute) already use sizes divisible by 4
anyway, and the common attribute header fields have a natural alignment
of 4. This means file contents will also have a minimum alignment
guarantee of 4 -- files requiring a larger guarantee can still be added
with the --alignment flag as usual.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I43f3906977094df87fdc283221d8971a6df01b53
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47827
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Memlayout is a mechanism to define memory areas outside the normal
program segment constructed by the linker. Therefore, it generally
doesn't make sense to relocate memlayout symbols when the program is
relocated. They tend to refer to things that are always in one specific
spot, independent of where the program is loaded.
This hasn't really hurt us in the past because the use case we have for
rmodules (ramstage on x86) just happens to not really need to refer to
any memlayout-defined areas at the moment. But that use case may come up
in the future so it's still worth fixing.
This patch declares all memlayout-defined symbols as ABSOLUTE() in the
linker, which is then reflected in the symbol table of the generated
ELF. We can then use that distinction to have rmodtool skip them when
generating the relocation table for an rmodule. (Also rearrange rmodtool
a little to make the primary string table more easily accessible to the
rest of the code, so we can refer to symbol names in debug output.)
A similar problem can come up with userspace unit tests, but we cannot
modify the userspace relocation toolchain (and for unfortunate
historical reasons, it tries to relocate even absolute symbols). We'll
just disable PIC and make those binaries fully static to avoid that
issue.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ic51d9add3dc463495282b365c1b6d4a9bf11dbf2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50629
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Now that all ACPI names are moved to the corresponding PCI devices, the
functionality in the chip code isn't needed any more.
TEST=No warnings or errors on coreboot console or in the Linux ACPI
parser.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2d39b6d4bd53cd0ca189fb6f55ca26dab68793fc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50822
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
