u-boot.git/board/cssi/cmpc885/u-boot.lds, branch master Unnamed repository; edit this file 'description' to name the repository. powerpc: Update linker scripts to ensure appended device tree is aligned 2026-01-20T18:07:20+00:00 Tom Rini trini@konsulko.com 2026-01-15T22:19:37+00:00 87d3780ebc242e28a180606f72335ce37d8bcca1 With commit 0535e46d55d7 ("scripts/dtc: Update to upstream version v1.7.2-35-g52f07dcca47c") it is now a fatal error to U-Boot if our device tree is not 8-byte aligned. In commit 85f586035d75 ("ARM: OMAP2+: Pad SPL binary to 8-byte alignment before DTB") Beleswar Padhi explains that we must have ALIGN(x) statements inside of a section to ensure that padding is included and not simply that the linker address counter is incremented. To that end, this patch: - Aligns the final section before _end by 8-bytes by adding '. = ALIGN(8);' or changing an existing ALIGN(4) statement. - Ensure that we do have alignment by adding an ASSERT so that when not aligned we fail to link (and explain why). Signed-off-by: Tom Rini <trini@konsulko.com> 
With commit 0535e46d55d7 ("scripts/dtc: Update to upstream version
v1.7.2-35-g52f07dcca47c") it is now a fatal error to U-Boot if our
device tree is not 8-byte aligned. In commit 85f586035d75 ("ARM: OMAP2+:
Pad SPL binary to 8-byte alignment before DTB") Beleswar Padhi explains
that we must have ALIGN(x) statements inside of a section to ensure that
padding is included and not simply that the linker address counter is
incremented. To that end, this patch:
- Aligns the final section before _end by 8-bytes by adding '. =
  ALIGN(8);' or changing an existing ALIGN(4) statement.
- Ensure that we do have alignment by adding an ASSERT so that when not
  aligned we fail to link (and explain why).

Signed-off-by: Tom Rini <trini@konsulko.com>
kbuild: Bump the build system to 5.1 2025-07-08T19:10:03+00:00 Ilias Apalodimas ilias.apalodimas@linaro.org 2025-06-27T18:57:16+00:00 5f520875bdf0ff1269e535fe215ec0ce481c7792 Our last sync with the kernel was 5.1. Even that was a partial one as some patches from 4.x kernels were already missing making the transition to a modern kbuild infeasible. We are so out of sync now, that tracking the patches and backporting them one by one makes little sense and it's going to take ages. This is an attempt to sync up Makefile[.lib/.kbuild]. Unfortunately due to sheer amount of patches this is not easy to review, but that's what we decided during a community call. One of the biggest changes is get rid of partial linking entirely and build .a archives isntead of .o. We diaviate from the kernel on that. Instead of calling a custom script to create the archive symbol table, we call ar with rcTP (isntead of rcSTP) since we want a resulting archive that's sauble with the linker. The only affected platforms are PPC ones. Unfortunately I don't have any of them around to test, but the objdump of the resulting files -- arch/powerpc/lib/built-in.[oa] looks identical. Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> 
Our last sync with the kernel was 5.1. Even that was a partial one
as some patches from 4.x kernels were already missing making the
transition to a modern kbuild infeasible.

We are so out of sync now, that tracking the patches and backporting
them one by one makes little sense and it's going to take ages.

This is an attempt to sync up Makefile[.lib/.kbuild].
Unfortunately due to sheer amount of patches this is not easy to review,
but that's what we decided during a community call.

One of the biggest changes is get rid of partial linking entirely and
build .a archives isntead of .o.
We diaviate from the kernel on that. Instead of calling a custom script
to create the archive symbol table, we call ar with rcTP (isntead of
rcSTP) since we want a resulting archive that's sauble with the linker.

The only affected platforms are PPC ones. Unfortunately I don't have any
of them around to test, but the objdump of the resulting files --
arch/powerpc/lib/built-in.[oa] looks identical.

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
board: cssi: Add new board MCR3000_2G 2023-02-11T07:47:58+00:00 Christophe Leroy christophe.leroy@csgroup.eu 2022-10-14T10:54:50+00:00 dac3c6f625e03be0b5017b0d436c73aeeb1a673e This adds a new board from CS GROUP. The board is called MCR3000_2G, and has a CPU board called CMPC885. That CPU board is shared with another equipment that will be added in a later patch. That board stores Ethernet MAC addresses in an EEPROM which is accessed using SPI bus. This patch was originally written by Charles Frey who's email address is not valid anymore as he left the company. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Reviewed-by: FRANJOU Stephane <stephane.franjou@csgroup.eu> 
This adds a new board from CS GROUP. The board is called
MCR3000_2G, and has a CPU board called CMPC885.

That CPU board is shared with another equipment that will
be added in a later patch.

That board stores Ethernet MAC addresses in an EEPROM which
is accessed using SPI bus.

This patch was originally written by Charles Frey who's
email address is not valid anymore as he left the company.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Reviewed-by: FRANJOU Stephane <stephane.franjou@csgroup.eu>