-
Notifications
You must be signed in to change notification settings - Fork 0
Maintainer Yocto Layer Design Choices
This page is intended to document choices made during the development of the system's Yocto layer and other OS configuration, especially when such choices may have involved trade-offs of functionality. This is aimed at maintainers of the LOKI project rather than developers using it as a platform for their applications.
There are two MMC devices on the board:
- eMMC: The embedded card, used as the default boot device and as storage for some non-volatile config overrides
- SD: The Micro-SD card slot, optionally used as a boot device (typically for recovery)
As of the new 2023 toolchain (status: https://github.com/stfc-aeg/loki/pull/68), these cards are mounted to /mnt/emmc and /mnt/sd to more clearly indicate which device is which.
The old mountpoints were /mnt/sd-mmcblk0p1 and /mnt/sd-mmcblk1p1 respectively, and were created automatically.
The mountpoints are now created using fstab entries, which can be modified in project-spec/meta-user/recipes-core/base-files/base-files_%25.bbappend.
They are mounted with no sync option, so files are not immediately synced to the devices.
This has some benefits: the system is more responsive, especially when interacting via the loki-update UI.
It means that control is returned far quicker, and the remaining writing can take place in the background while completing other tasks, making it more efficient.
However, there are some limitations that users should be aware of:
Warning
Due to the lack of immediate sync, after uploading a new image to eMMC or SD the system must be synced by shutting down or rebooting in a controlled manner to prevent corrupting the boot files. The best way to to this is to restart via the UI, or otherwise log in over ssh and execute a command. This must be done before a power-on-reset.
This was considered a reasonable risk to take on the occasion that the image is updated, since most users ignorant of the file syncing should be using the web UI. Image upload is the only time this is an issue; the MMC cards are not otherwise written to routinely, and are not where the booted root filesystem is mounted from.
There is one major master I2C bus used by the system, which is then split using two TCA9548A MUXes into 16 channels.
These are mapped out as follows:
| MUX | Address |
|---|---|
| U7 | 0x73 |
| U8 | 0x72 |
| MUX | Bus Number | Kernel Bus Number | Usage |
|---|---|---|---|
| U7 | 0 | 2 | Application Support Devices (on LOKI), such as general use clock generator and temperature monitor. |
| U7 | 1 | 3 | Power Monitoring - routed out to the main application connector, intended for power monitoring. |
| U7 | 2 | 4 | - |
| U7 | 3 | 5 | - |
| U7 | 4 | 6 | - |
| U7 | 5 | 7 | User EEPROM on LOKI carrier- for application-defined use |
| U7 | 6 | 8 | - |
| U7 | 7 | 9 | - |
| U8 | 0 | 10 | Application-specific General-purpose 1 |
| U8 | 1 | 11 | Application-specific General-purpose 2 |
| U8 | 2 | 12 | Application-specific, intended for target board management (identification etc) |
| U8 | 3 | 13 | - |
| U8 | 4 | 14 | PLL-loopback for LOKI SoM, and SoM EEPROM (for MAC Address) |
| U8 | 5 | 15 | Debug Header 1 |
| U8 | 6 | 16 | Debug Header 2 |
| U8 | 7 | 17 | - |
In the 2020 tools at least, you can list the relation between bus address/IC output number and kernel bus number like so:
petalinux-custom:~$ ls /sys/bus/i2c/devices/0-0072/channel-0/i2c-dev/
i2c-10The ZLx clock generator has a two-part write/read transaction in its function for reading registers that is very sensitive- it fails to work properly if there is any transaction between the two on the bus.
Due to this, it has been necessary to remove the i2c-mux-idle-disconnect tag in the device tree for its MUX, which will prevent the bus being disconnected between the two transactions (which involves traffic to the MUX itself).
Note
Required: Proper fix
At some point, the control of the ZLx needs to be updated so that it will work without this bodge, as it introduces some fragility into the I2C buses, which luckily so far has not caused any issues. This may either involve somehow ensuring that the transactions take place as a single atomic one as far as the bus handling is concerned, or otherwise somehow grabbing control of all I2C buses until the transaction is complete.
Warning
Impact: Address conflicts on 0x74 and 0x77
Due to the above, the Application Support bus can be left connected at times, meaning that whatever bus is selected on the U8 MUX may conflict with these always-active addresses. Avoid.