| 5 Mar 2021 |
 a3f | vdl: Does barebox itself need access to something on the daughter board or does only Linux use it? | 19:32:22 |
 vdl | a3f: only linux | 19:32:54 |
| a3f | The recommended way to boot with barebox is to use the bootloader specification. That's a file at a well-known location that tells barebox where to find kernel, device tree and bootargs. Here is an example: https://git.pengutronix.de/cgit/DistroKit/tree/configs/platform-v7a/projectroot/loader/entries/boneblack.conf | 19:34:38 |
| a3f | bootloader spec files can contain a devicetree-overlay proeprty that points at a device tree overlay to apply on boot | 19:34:56 |
| a3f | So just like your daughter board overlays new HW functionality, you can have a device tree overlay that only describes your board. | 19:36:18 |
| a3f | But it's a case by case thing, really. Sometimes it's better just to patch the kernel device tree at build-time instead of overlaying at runtime. Depends on how often you change the daughterboards and such. What shouldn't be needed s to patch the barebox device tree. You can boot the kernel with the barebox device tree, but it's always more flexible to have a separate kernel device tree that you can update without touching the bootloader | 19:37:59 |
| vdl | a3f: it's like extlinux.conf files I suppose | 19:38:05 |
| a3f | Ye | 19:39:35 |
 peerst | @a3f[m]: thanks! For another platform we also want to boot on the same boards (RTEMS based, kind of a unikernel image): is there a library for barebox-state we could use? We have no normal shell or commands there | 20:03:16 |
| a3f | peerst: barebox-state is a small wrapper around dt-utils. If you are fine with linking against GPL-2.0 code, you could adapt it for your needs. There are people who reimplemented state access from documentation, but there's no public library I know of besides dt-utils | 20:06:02 |
| peerst | GPL is a problem for us | 20:06:28 |
| peerst | So for our GRiSP platform we'll probably reimplement it but do so in Erlang (GRiSP is RTEMS+Erlang VM run directly on hardware) which will be less work, so thats fine | 20:07:58 |
| a3f | peerst: there must be some concept of processes ther? perhaps change barebox-state to listen to a message queue or something? | 20:07:59 |
| peerst | No processes in RTEMS its only threads | 20:08:25 |
| peerst | Everything liked together | 20:08:40 |
| a3f | peerst: so you can't use any GPL-2.0 code there without making it all GPL-2.0? | 20:08:50 |
| peerst | Well Erlang has proper processes inside (more lightweight that threads but real processes) so we don't miss them that much | 20:09:19 |
| peerst | Yeah we can only link against it | 20:09:29 |
| peerst | RTEMS is under a special license that would not be a problem because its GPL with application linking exception (not LGPL they invented their own) | 20:10:06 |
| peerst | But the Erlang VM is Apache 2 which is fine against RTEMS but not vanilla GPL | 20:10:47 |
| a3f | I see. | 20:10:58 |
| a3f | If you decide to implement state, here are the docs: Here's the format description: https://www.barebox.org/doc/latest/user/state.html | 20:11:11 |
| peerst | Yeah looked at that and felt lazy so I asked | 20:11:59 |
| a3f | You likely won't need to implement all of it, just the parts you decide on using (there are wear leveling and such, you might not need if you use EEPROM) | 20:12:10 |
| peerst | The current Linux based project is already solved through barebox-state so thats fine | 20:12:34 |
| peerst | Yeah we have a EEPROM available | 20:13:08 |
| peerst | state is pretty fancy | 20:15:43 |
| a3f | yes, it's nice | 20:48:07 |
| 6 Mar 2021 |
|  shorne left the room. | 12:17:33 |
| shorne joined the room. | 12:34:33 |
