This is a guide for when submitting code for a new platform from AndrewTurner. It is in no way official, and other committers may disagree with these.

/!\ this page is probably OBE as of 20190728.

These are to help work towards an armv6 GENERIC kernel.

Use FDT

All new armv6 platforms must use FDT. Where possible follow the Linux device tree bindings, or even better, use the Linux device tree source files.

You will need a good reason to use FDT_DTB_STATIC as it leads to an increase in the number of kernel configs we need to support for little gain, i.e. there are many boards we could support, but having a config file for each would be too much.

Use the loader

In general you should use the loader where possible, there is a version that works with U-Boot (ubldr), and UEFI (loader.efi).

It should load the device tree and pass it to the kernel.

Don't use kernel.tramp

You will need a good reason to need to use this as it needs to know about physical memory. It is built when KERNPHYSADDR is defined, this can be safely removed from kernel configs.

Build common files from sys/conf/files.arm

Any new files not specific to any SoC should be placed in sys/conf/files.arm with an option to enable them. If it's truly common then other configs may use it, and having an option simplifies finding which kernel configs use a given device.

Have a single kernel config for a family of SoCs

The code should be generic across multiple SoCs where possible. There are a few places where this isn't possible, but the SoC specific code shouldn't preclude this when these places are fixed.

When it's not possible to have a single kernel config, try to limit the number of kernel configs needed.

One place where having multiple configs is allowed is when one needs to build as arm, and another as armv6.

Use INTRNG

The old pre-INTRNG interrupt code is now deprecated. All new SoCs should use INTRNG fo rinterrupt handling.


CategoryStale

arm/NewPlatformGuideline (last edited 2019-09-06T21:32:00+0000 by anonymous)