Skip to content

Support for Kria K26 SOM#427

Merged
Ivan-Velickovic merged 3 commits intoseL4:mainfrom
SeedRizvi:kria_k26_support
Mar 12, 2026
Merged

Support for Kria K26 SOM#427
Ivan-Velickovic merged 3 commits intoseL4:mainfrom
SeedRizvi:kria_k26_support

Conversation

@SeedRizvi
Copy link
Contributor

@SeedRizvi SeedRizvi commented Mar 6, 2026

Add the AMD/Xilinx Kria K26 SOM as a supported board, which is largely similar to ZCU102. Made with support from @potanin .

This is part of a set of related PRs across microkit, seL4, sDDF, and seL4-docs to add Kria K26 support.

  • build_sdk.py: register kria_k26 with KernelARMPlatform=kria_k26
  • loader/src/uart.c: add UART support using base address 0xff010000 (UART1), integrated with the pre-existing ZCU102 #define block as it's identical
  • loader/src/aarch64/init.c: skip PSCI version check for Kria K26 platform

@SeedRizvi SeedRizvi force-pushed the kria_k26_support branch 2 times, most recently from 2a06735 to 332577f Compare March 6, 2026 02:19
Copy link
Contributor

@midnightveil midnightveil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM after seL4 changes are merged and pulled in-tree.

@SeedRizvi
Copy link
Contributor Author

This has now been refactored to instead work without any changes to seL4 by placing the overlay file directly within Microkit based on commit b866313.

build_sdk.py Outdated
elif isinstance(val, KernelPath):
str_val = f"{sel4_dir.absolute()}/{val.path}"
elif isinstance(val, Path):
str_val = val.absolute()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this probably shouldn't just be val.absolute() which goes relative to the current directory, we should probably go relative to where build_sdk is located.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, adding KernelPath doesn't seem an improvement compared to the original code? It makes things more complicated with no gain as far as I can tell.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some of the DTS overlays are local to Microkit while some come from the kernel, we need to be able to refer to paths relative to both. The path to seL4 is supplied by the user so we need a way of converting to a kernel relative path.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't you just check both locations? If it's not locally present, try to find it in the kernel path?

We removed this f37bb59 but
there are some cases where the Microkit board is more specific
than the seL4 platform.

One example of this is where it is the same exact SoC but say
the default UART is different for one board is different to
another.

Until the loader is more generic (e.g parsing the DTB) we have
to do something like this.

Signed-off-by: Ivan Velickovic <i.velickovic@unsw.edu.au>
Ivan-Velickovic and others added 2 commits March 12, 2026 14:18
A bit annoying since when we refer to the kernel path we don't know
exactly where the kernel is since it's a user-supplied argument

Signed-off-by: Ivan Velickovic <i.velickovic@unsw.edu.au>
Signed-off-by: SeedRizvi <syedasadrazarizvi1@gmail.com>
Signed-off-by: Ivan Velickovic <i.velickovic@unsw.edu.au>
@Ivan-Velickovic Ivan-Velickovic merged commit f687922 into seL4:main Mar 12, 2026
9 of 11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants