Using Device Tree Overlays, Example on BeagleBone Boards(bootlin.com)

54 pointsby pabs34 tahun yang lalu9 comments

Using Device Tree Overlays, Example on BeagleBone Boards

https://bootlin.com/blog/using-device-tree-overlays-example-on-beaglebone-boards/

9 comments

ktownsend4 tahun yang lalu

The same concept is also used in smaller embedded systems, like Zephyr RTOS: https://docs.zephyrproject.org/latest/guides/dts/index.html

Useful video if you're interested in how DT applies to Zephyr, such as defining I2C sensors available on your board target: https://www.youtube.com/watch?v=sWaxQyIgEBY

koz10004 tahun yang lalu

I wouldn't call it the same concept. Zephyr uses the Devicetree format to create headers and configure the compilation of the kernel, but userspace code has zero visibility into whatever was set up in the devicetree file.

Zephyr is chock full of these creature comforts to make Linux developers feel at home but only deliver 50% of the usability. I went back to FreeRTOS.

blippage4 tahun yang lalu

I've downloaded Zephyr, but haven't produced anything useful with it. I was put off by the learning curve. It also suffers from a lot of these OS's do: layer upon layer of abstraction. I also hate everyone's weird and wonderful build tool.

Some stuff looks like it might be implemented well in these OS's, like using DMA, and suchlike. So they could possibly be fast. And yet, I think the way to bet is that they will be slower. Get comfortable with CMSIS, and your results are likely to be substantially faster.

Maybe throw in a bit of FreeRTOS if you feel you need it. I haven't experimented with tinygo yet, but I wonder if that's the way to go if you want concurrency.

I think that the whole notion of abstracting away the machine is an ill-conceived idea anyway, particularly when it comes to microcontrollers. The whole point of mcus is to use their particular features and strengths, which basically the opposite of abstraction.

I dunno, if something is complicated enough to use Zephyr, then maybe it's complicated enough to just ditch it and use a Raspberry Pi.

koz10004 tahun yang lalu

There's this intersection point in the MCU/SoC world where you can get by with a Cortex-M3/M4/M7 and need solid multitasking but don't have an MMU. ucLinux is a dead end, and then you have FreeRTOS (sorry, AmazonRTOS) or ThreadX (cough, AzureRTOS). And if you can afford GreenHills Integrity you probably aren't reading HN anyway.

I spent a year hacking with a Broadcom-supplied fork of Zephyr to Cortex-A and it was just a mess. It never worked right. Maybe it does now and it's mainline but I wouldn't trust it.

For a project started by WindRiver, taken over by Intel, then released to OSS it's mind-boggling how bad of a state it was in given its age.

pantalaimon4 tahun yang lalu

I mean on the small ROM of MCUs you don't usually want to keep the device tree around, so it's just sensible that it gets turned into macros and is not accessible at run time.

Given that FreeRTOS does not deal with hardware at all, I don't see how it is a comparison.

koz10004 tahun yang lalu

It's not a comparison, but if you're looking for a lightweight RTOS and trying to decide between the two Zephyr looks appealing at first because you think you're getting a lot of facilities that are equivalent to a Linux-class kernel.

And then you discover you're not getting any of that.

If all Zephyr DT is doing is making a fancy header file for me, I'd rather just build my own and skip the learning curve.

dexterhaslem4 tahun yang lalu

on the flip side there is u-boot device tree overlays

rgrs4 tahun yang lalu

Can I remove an applied overlay?

Something like,

- apply overlay

- use the device

- unbind device & driver

- remove applied overlay

ghostpepper4 tahun yang lalu

Yep, believe the remove flag to dtoverlay is -r