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>
Both the IO-APIC and PIC mode PCI IRQ tables are incorrect for ADL; the
2nd field in each package is supposed to be pin, not function number,
and some of the IRQ #s differ from what the FSP programs, therefore
align the ACPI table to match what the FSP is currently programming.
BUG=b:180105941
TEST=boot brya, no more `GSI INT` or `failed to derive IRQ routing`
errors seen in dmesg
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I182be69e8d9ebd854ed74dbb69f4d1f1a539cf2f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50599
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Bilby is the reference board for AMD Raven, Raven2 and Picasso APUs.
Bilby mainboard code is taken from mandolin variant Cereme.
These new files are a renamed copy and subsequent patches will be
applied to create a working bilby implementation.
Change-Id: I426966d782e259a971ec36bac2498bc62b4ce7e2
Signed-off-by: Ritul Guru <ritul.bits@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50315
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
TEST=Boot majolica to linux and see IO-APIC logs
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
IOAPIC[0]: apic_id 16, version 33, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
ACPI: IRQ0 used by override.
ACPI: IRQ9 used by override.
Using ACPI (MADT) for SMP configuration information
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ib8094c3edf401659d9d740e2cc6266ddd5f91da9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50803
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
