summaryrefslogtreecommitdiffstats
path: root/Documentation/devel
Commit message (Collapse)AuthorAgeFilesLines
* ARM: document arm_setup_stack() pitfallsAhmad Fatoum2021-10-051-0/+21
| | | | | | | | | | | | | | | | | | | | | | Many arm32 board entry points use arm_setup_stack() to set up the stack from C code. This necessitates using __naked, which probably has been our most frequent cause of misscompiled C code. GCC is quite clear that: Only basic asm statements can safely be included in naked functions While using extended asm or a mixture of basic asm and C code may appear to work, they cannot be depended upon to work reliably and are not supported. But some boards use it anyway, because it's nice to avoid writing assembly. Reading generated assembly to spot compiler miscompilation isn't that nice though, so add some documentation, comments and compiler diagnostics to hopefully reduce future porting effort. Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Link: https://lore.barebox.org/20210917121152.16033-1-a.fatoum@pengutronix.de Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* Documentation: devel: background-execution: update bthread docsAhmad Fatoum2021-06-251-23/+11
| | | | | | | | | | | Using bthreads throughout means we'll need finer grained locking across the code base, which is too big a commitment for now. Previous commit limited bthread_reschedule to only happen in command context, like how it is for workqueues. Adjust the docs appropriately. Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Link: https://lore.barebox.org/20210622082617.18011-7-a.fatoum@pengutronix.de Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* Documentation: devel: porting: update after clk_hw syncAhmad Fatoum2021-06-211-1/+0
| | | | | | | | | | Clock code sync with Linux got way more straight forward, now that barebox knows about struct clk_hw. Remove the suggestion to replace clk_hw with clk when porting. Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Link: https://lore.barebox.org/20210621064646.19094-1-a.fatoum@pengutronix.de Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* Documentation: add barebox porter's guideAhmad Fatoum2021-04-132-0/+510
| | | | | | | | Make new porters' life easier by having a central place for porting advice and add some initial content there. Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* common: introduce bthreads, co-operative barebox threadsAhmad Fatoum2021-03-221-4/+33
| | | | | | | | | | | | | | | | | | | | With the new setjmp/longjmp/initjmp support, we have all the architecture support in place to have suspendable green threads in barebox. These are expected to replace pollers and workqueues. For now we still have a differentiation between the main and secondary threads. The main thread is allowed I/O access unconditionally. If it's in a delay loop, a secondary thread running needs to be wary of not entering the same driver and doing hardware manipulation. We already have slices as mechanism to guard against this, but they aren't used as widely as needed. Preferably, in the end, threads will automatically yield until they can claim a resource (i.e. lock a mutex). Until we are there, take the same care when using bthreads as with pollers. Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* Documentation: Add document about background execution in bareboxSascha Hauer2020-08-192-0/+139
With pollers, slices and now workqueues it's time to add some documentation how these things work and how they all play together. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>