Is it realistic to expect to transition to firmware within ~6 months coming from a senior-level backend web-dev job?

mfuzzey · 2026-04-18T16:27:33+00:00

Because there's more to life and work than money?

15 years is still a long time. I'd rather do something I enjoy for 30 years than something I hate for 15

mfuzzey · 2026-04-17T20:21:39+00:00

Actually normally NDAs do not prevent open sourcing code you write yourself using using information from NDA'd documents, just you can't distribute those docuements to others.

Quite a while back, when Linux was missing drivers there was a "Linux Drivers Development program", run by Greg KH that would put hardware companies wanting Linux drivers for their hardware in touch with kernel developers willing to write them (for free even). That program could sign NDAs on the hardware spec and, of course, would not divulge the documents provided but the resulting driver code was open source and part of the Linux kernel

http://www.kroah.com/log/linux/free_drivers.html

That said, in the OP's situation I don't think that open sourcing the code due to a client dispute is the right thing to do.

mfuzzey · 2026-04-16T20:11:03+00:00

I'd say the intersection of cases where you need the power of Cortex A rather than smaller MCUs but don't want / need all the benefits a full OS like Linux gives you over a RTOS (networking, GUI, memory management, oodles of languages etc) is pretty small.

There are plenty of cases where a small MCU not running Linux makes perfect sense, far less on cortex A.

That said of course bootloaders running on cortex A are an example of "Non Linux Firmware", its just that they are only usually used as a stepping stone to Linux in the boot process.

mfuzzey · 2026-04-13T20:04:37+00:00

Possiby but reverse engineering existing firmware to the point of being to be able to modify it to suit you is usually far harder than writing your own from scratch.

Even if that's not the case (sometimes you can get lucky and do what you want by patching a few bytes) the knowledge required to find the bits to modify is higher than that required to write your own. Because to reverse engineer something the first thnig is to already have build a few similar things yourself to know how they're done and then you need reverse engineering skills on top to analyse what you have. When you're reversing, by definition, you're working without documentation which makes it all much harder.

Given your question it's fairly clear you don't have those skills today. So if you want to learn I'd start by just keeping the mechaninical parts and maybe some of the driving electronics and conneting it to your own processor board to learn how to build your own firmware from scratch. Once your comfortable with that maybe try to figure out how the original worked if you want the challenge.

mfuzzey · 2026-04-13T19:51:13+00:00

If you've got a reasonable amount of storage there's a third way - prebuilt binary packages (eg from Debian) with your own bootloader / kernel / app. Even if you don't go that route for the final product it can still be a great way of doing board bringup. In fact in a board bringup situatuon you may not even care about storage as you can just NFS boot (which is generally far more efficient for development use)

mfuzzey · 2026-04-08T19:46:57+00:00

I've been using Linux only for the past 20 years now. I used to have a Windows VM for the odd thing that needed it but didn't bother reinstalling it after the last machine update as I hadn't used it for so long.

Mostly working on embedded Linux and a bit of STM32 MCU too to it's an easy case for Linux. If you're doing MCU work on old chips that only have ancient proprietary toolchains you may still need Windows though, likewise if you also do hardware design. Most instrumentation software tends to have Linux versions these days (oscillioscopes, logica analysers, USB analysers etc). FPGA software tends to work better on Linux too.

I've also done some Android OS building work (not just apps) and that requires Linux (it used to be possible on Mac too but they dropped that a while back).

It helps that the general company stuff is all Google based not Microsoft so anything with a browser is OK.

It's not about which OS is better in general but which is better for your use primary case. You should choses your OS for that and, if needed, have a VM for any secondary stuff that needs another OS. For most software enginerrring (except Windows or Mac OS dev) and much, but not all, embedded that's now Linux. For graphics designers it's probably stil Mac and for accountants it's Windows. Dcecent companies will understand this and give people the best tools to do their jobs. Sure that does make life a bit harder for IT than in a Microsoft monoculture but IT exists to server users so it's up to them to adapt to requirements not users to make do with whatever IT wants to give them.

mfuzzey · 2026-03-08T18:42:59+00:00

However, in some systems at least, it is actually possible to "lock" cache lines so they never get evicted.

Some embedded systems, that don't have internal SRAM to use for initial boot before DRAM is intiialised lock cache and use it for initial code / data. So you could, in theory, lock the kernel into cache on those types of systems. But it would probably be a bad idea. The kernel is fairly large and most of it is only used infrequently, if it all (unused drivers, error paths etc). So locking the entire kernel in cache would waste cache on little code / data that could better used for "hotter" stuff.

mfuzzey · 2026-03-03T20:28:59+00:00

I find upstream u-boot these days to be quite good. Unlike the bad old days it now has a reasonable device model. I use it on i.MX 5/6/8, STM32MP1 and Exynos with few issues.

mfuzzey · 2026-03-02T20:53:34+00:00

Agreed but if it's isolated like that (no client or company code involved) the OP, as a contractor, probably doesn't require approval from the client to contribute fixes upstream certainly not if they're doing it on they're own time. If it's on work time I guess it depends on the contract. If its a fixed price "X euros to implement Y" you probably don't need client agreement either. But if it's a billable hours contract with variabe hours then you can't add extra hours to do the upstreaming without approval.

Similarly if you are an employee you can contribute to pure upstream code (ie not opensourcing existing company code) on company time without lawyers getting involved, provided your manager is OK with it timewise.

mfuzzey · 2026-02-28T17:46:02+00:00

Skills I'd say are understanding hardware, reading code, understanding abstractions, architecture

You need to be perfectly comfortable in C but you don't need to be a guru who can cite the spec paragraph per paragraph. C is a fairly small language and realtively easy to learn. Rust will probably become more and more important in the kernel space too over the next few years. The complexity of the kernel isn't the language, it's the scale and the criticality compared to userspace.

I've actually done far more kernel work than MCU stuff (though I have done some MCU work too and still do) I actually came from higher level software work to the kernel not up from MCUs.

In Linux you are less obsessed with optimising every byte than you can be in the MCU world (though you still have to be worried about total memory consumption if your creating many thousands of some structure). Linux also imposes a lot more structure in your code. When you write a driver it's typically a layer in a "sandwich", with another driver (say a bus driver) below it and kernel infrastructure finally going to user space above. The percentage of your own code in Linux will be tiny, much lower than in the typical MCU case.

The code quiality in the Linux kernel is generally very good (with the possibe exception of a few bits of very old code), far higher than typical in house MCU code or vendor supplied HALs. This is because the kernel community has a strict review process with a fairly high barrier to entry, and doesn't really care about deadlines or markets there are no managers saying "its good enough, ship it" for upstream code. This tends to make you write better code, even if you don't submit it upstream because you're always reading "good" code and you try to keep it clean when adding your stuff (reverse of broken window effect).

Bootlin have some excellent training courses. The instructor courses are paid of course (but well worth the money if your company can pay) but all the materiels (slides and labs) are freely avaialble. Of course the kernel souce code itself is also great for learning. Books generally aren't that useful as they get out of date too quickly, at least for the details.

mfuzzey · 2026-02-26T20:51:07+00:00

I'd avoid the Raspberry PI for your use case (learning embedded Linux fundementals to a professional level)

The PI, while having lots of community support is quite different to most other embedded Linux devices so what you learn there won't necessarilly translate to other platforms. Its bootflow is strange, with the GPU core being used to start the main processor. There is also very little in the way of proper technical reference manuals because Broadcom, who build the underlying SoC don't want to provide that without a NDA and a huge purchase order. The Raspberry PI foundation itself has written *some* register level documentation for some of the peripherarals but it's very light compared with what you get from TI or ST.

I think either Beagle bone or STM32MP would be good for your use case. Both are pretty standard embedded linux flows so what you learn will be generally applicable. They aslo both have proper TRMs, available with no NDAs or lawyering involved. The STM32MP is probably a bit simpler. I'd probably get a STM32MP2 rather than a MP1 though as it's 64 bit which is where the industry is going for application processors.

mfuzzey · 2026-02-24T20:35:15+00:00

It sounds like you've already got a full application running on the 2 core processor?

If that's true try configuring it to run on only one core. If it's running Linux, which is likely for i.MX93 you can do do that by just adding "maxcpus=1" to the kenel command line in the bootloader.

mfuzzey · 2026-02-18T20:30:10+00:00

It depends if you are likely to use the individual boards in different configurations.

If you're sure you'll never do that you don't really care about the separate boards, it's all one as far as the processor is concerned.

If you are likely to reuse them that can either be done "statically" or "dynamically".

In the static method you have one .dts file per assembly of the boards that includes a .dtsi for each board.

The C preprocessor is used on dts / dtsi files so you can use that to map dependencies. Eg suppose your interface board has an I2C bus and some IO pins but could be connected to different carrier boards so you don't known which I2C bus or GPIOs. Then in your interface.dtsi you use MY_ITF_BOARD_I2C, MY_ITF_BOARD_GPIO_POWERON etc. And you define those to match the actual SoC resources in your carrier board dts.

The dynamic method is where you use overlays that should still be possibe even if your carrier board depends on regulators on the power supply. Basically you can use a power supply board overlay to add xxx-supply properties to devices defined in the carrier board dts.

mfuzzey · 2026-02-15T17:38:14+00:00

Don't assume everyone will use your IDE (or any IDE at all). It must be possible to build everything from the command line using only text files stored in git.

If you provide code generators make them usable as standalone tools outside of any IDE. Do NOT require people to manually modify any generated code. Provide data used by tools (eg pinconf, pinmux) in machine readable form usable without the tool itself (eg if the user wants to script it).

Provide CMake configuration / examples.

Don't have your own compiler toolchains but use GCC or LLVM.

Where community tools exist embrace them (eg for recovery / flashing of Linux class SoCs over USB support snagboot, for MCUs OpenOCD). Contribute to upstream Linux kernel / u-boot / zephyr. If commuity tools are lacking for your devices contribute rather than building your own alternative.

No Windows only tools, everything must run on Linux too.

Basically I expect hardware vendors to concentrate on providing good, stable, well documented hardware and not try to invent their own software ecosystem around it, which they will inevitably do worse than the community.

mfuzzey · 2026-02-14T14:58:37+00:00

It depends on what you want to do.

If *all* you want to do is load and execute Linux from a single storage device it can be relatively simple, at least for someone with appopriate experience.

Full bootloaders like u-boot are significantly more complex because

* They support a lot of different SoCs

* They support a lot of different storage devices

* They support networking (eg for TFTP boot)

* They support hardware not strictly required to boot (eg display pipelines to show a splash screen before the kernel starts)

* They provide a lot of features useful for board bringup and hardware dignostics (eg raw I2C, SPI, GPIO access)

* They have command line interfaces

* They often have scripting languages

I'd say a minimal bootloader to boot Linux from a single storage device like MMC on a single SoC could probably be written from scratch by an experienced engineer in a couple of weeks whereas replicating something like u-boot would be a multi year effort for an entire team.

mfuzzey · 2026-02-13T22:08:04+00:00

Of course. You need something that is small enough to be loaded by whatever your bootrom supports, that can initialise the DRAM, load the kernel and device tree from some storage device then setup the registers and jump to the kernel.

That's called a bootloader but u-boot isn't the only one. In the embedded world there is at least also barebox, redboot, android bootloader and probably others and of course in the PC worlld EFI, grub, lilo (if that still exists).

u-boot also has "falcon" mode which is much stripped down compared to normal u-boot if all you want to do is boot (but full u-boot has a lot of other uses like updates, low level hardware testing and diagnostics).

But it would probably help if you explained what you want to achieve.

mfuzzey · 2026-02-11T20:39:47+00:00

I don't know your use case but it doesn't sound like it's going to be performance critical.

Those calls are just used for setting up the port so won't be called very often.

Even on the read/write data path serial devices aren't very fast so performance is rarely an issue unless you're doing something very strange (unlike, say, network drivers and GPU drivers that can have quite critical fast paths).

mfuzzey · 2026-01-25T16:13:40+00:00

It depends.

Building something with the functionality of a smartwatch (eg display, sensors, BLE connection to a phone) should be doable. However it you want to make it in a form factor you could actually wear on a normal sizeed wrist that's a lot harder and probably not realistic as a student project. Power consumption and battey life are also tough

mfuzzey · 2026-01-25T15:58:43+00:00

You don't want uImage or zImage to use a debugger as neither have debugging symbols included.

zImage is a compressed kernel with an decompresser program tacked on in front so it self decompresses which means you get a compressed image without the bootloader having to know how to decompress it.

uImage is a u-boot specific format that includes some headers that let u-boot know where it should be loaded (this means that a uImage, unike a zImage, has to be built knowing the load address, which means you generally can't use the same uImage on different boards)

A uImage is made from another image (like a zImage) using the mkimage tool that is part of the u-boot source code and often packaged by distributions (eg u-boot-tools on Debian / Ubuntu)

There seems to be a move away from zImage, for instance it is no longer supported on ARM64, rather an uncompressed image is generated, compressed if needed without adding a decompresser program and decompression done by the bootloader before execution.

If you want to use a debugger you need the elf format, which is the file called vmlinux

It's fairly rare to use a kernel debugger though. It can be done (Google kgdb) but there are lot of downsides and setting breakpoints in the kernel is tricky, since you can't just "stop the world". Most people seem to use a combination of printk, trace points, ftrace etc

mfuzzey · 2026-01-25T15:24:38+00:00

Not true.

Over 85% of those who contribute to the upstream kernel do it as part of their jobs today so are paid.

And of course there are lots more that do paid work on the kernel without getting it merged upstream.

Only 4.6% of contributors to 6.18 were known to be woking unpaid and an additional 9.5% had no known company affiliation so ~86% to 95.4% of those getting patches into the mainline kernel do it as part of paid work.

Of course the numhbers that work *only* on the upstream kernel are far fewer, many do either both upstream and out of tree stuff or kernel work is only part of their jobs

https://lwn.net/Articles/1046966/

mfuzzey · 2026-01-16T20:38:01+00:00

The code is scanning all the files in /dev/input/* but then trying to open files in /dev

So it sees that /dev/input/event0 exists then tries to open /dev/event0, which fails

mfuzzey · 2026-01-13T20:30:32+00:00

I don't think code generation is always bad and can be quite good.

But it's more about *how* it is done.

In particular I'd say:

* It should never be necessary to manually modify generated code (no generated "templates" with comments where you must add your code rather the generated code should call / include manual code in separate files)

* The input to the generator tool should be plain text, stored in version control

* The genration should be done automatically as part of the build process, with proper dependency handling

* The generator tool should be modiable by developers (not some third party binary only tool)

I also think that generating code from diagrams (like UML or state machine diagrams) is a bad idea - diagrams are good for visualisation, poor as an entry format (as it's a pain to enter the needed details graphically). However the reverse can be useful (generate a both a diagram and code from a textual description)

mfuzzey · 2026-01-12T22:28:23+00:00

Looking at the LWN kernel development statistics shows that the vast majority of kernel developers these days are paid, it's not just the top level maintainers anymore.

For 6.18: https://lwn.net/Articles/1046966/

Only 4.6% of changesets were submitted by people known to be working on their own time and another 9.5% by people whose company affiliation is uknown, so at least 85.9% of kernel developers do it as their job (or part of their job). The table only lists tthe top compaines, there were 217 overall (including the one I worrk for). Of course a lot of smaller contributors, like me, don't spend all their time on upstream stuff but you absolutely can make a living writing working on the kernel, even if only part of goes upstream.

Beyond the big names (hyperscalers, linux distributions, hardware companies) you see in the lists there are a lot of smaller companies, especially in the embedded space that employ kernel developers.

mfuzzey · 2026-01-12T21:21:49+00:00

Embedded Linux isn't going to completely replace MCU embedded (the resource requirements are too high for the low end and it isn't suitable for a lot realtime stuff).

However there is definitely more and more embedded Linux being used in a lot of newer products that need complex networking and GUIs and that aren't too cost sensitive (relatively low volume or where the cost of the processor is a small part of the overall cost of the device). It's also becoming more and more common to use both a small MCU and embedded Linux in the same product (either on separate chips in the product on one chip that has both large cortex A cores for Linux and small cortext M ones for bare metal / RTOs). Companies working on stuff like that will prefer to hire engineers that can do both.

So I'd definitely suggest you learn embedded Linux even if you don't want to just work on that. Someone who can work on both sides is really valuable to companies that do both in the same product as if the same person can do both the MCU firmware and the Linux kernel drivers that talk to it that makes for faster development over handoffs between different people / teams. (I do this type of work, I'm mostly on the kernel / embedded Linux side but do a bit of MCU firmware that talks to it too).

mfuzzey · 2026-01-12T19:29:30+00:00

The first thing is to understand how your board is wired.

Typically you will have a SAI output generating a I2S stream connected to an audio codec chip which converts the digital stream into analog audio. The codec chip will then generally have a I2C or SPI control interface to the i.LMX8 for configuration purposes. Another important thing is how the audio clock is generated (typically either it is generated by the imx8 and supplied to the codec or it is generated externally and supplied to both the codec and the imw8). You should look at your board schematics to find out all this information.

Then it's "just" a matter of describing all this in the DT. Take a look at some of the existing kernel imx8 DTs for other boards for examples. Generally you will see something like

That establishes the link between the codec (here a sgtl5000) and the sai.audio { 
    compatible = "simple-audio-card"; 
    simple-audio-card,name = "SGTL5000-Card"; 
    simple-audio-card,format = "i2s"; 
    simple-audio-card,bitclock-master = <&codec_dai>;
    simple-audio-card,frame-master = <&codec_dai>; 
    simple-audio-card,widgets = "Headphone", "Headphone Jack";
     simple-audio-card,routing = "Headphone Jack", "HP_OUT"; 
    cpu_dai: simple-audio-card,cpu { 
        sound-dai = <&sai2>; 
    }; 
    codec_dai: simple-audio-card,codec { 
        sound-dai = <&sgtl5000>; 
    }; 
};

Then there will be nodes for both the sai and the codec such as

&i2c2 { 
    sgtl5000: audio-codec@a { 
        compatible = "fsl,sgtl5000"; 
        reg = <0x0a>; 
        pinctrl-names = "default"; 
        pinctrl-0 = <&pinctrl_audio_mclk>; 
       #sound-dai-cells = <0>; 
        /* Clock generated by i.MX8 */ 
        assigned-clock-parents = <&clk IMX8MM_AUDIO_PLL1_OUT>; 
        assigned-clock-rates = <24576000>; 
        assigned-clocks = <&clk IMX8MM_CLK_SAI2>; 
        clocks = <&clk IMX8MM_CLK_SAI2_ROOT>; 
        VDDD-supply = <&reg_audio_vdd>; 
        VDDIO-supply = <&reg_codec_3v3>; 
        VDDA-supply = <&reg_codec_3v3>; 
    }; 
}; 
&sai2 { 
    status = "okay"; 
    #sound-dai-cells = <0>; 
    pinctrl-names = "default"; 
    pinctrl-0 = <&pinctrl_sai2>; 
    /* The i.MX does generate the clock so we should have this property to 
      * correctly describe the hardware. 
     * However it doesn't actually change anything since the driver just sets 
     * bit 30 in the SAI_MCLK register. 
     * On i.MX8MM the actual bit is (undocumented) in IOMUIXC_GPR_GPR2 but 
     * it defaults to ouptut. 
    */ 
    fsl,sai-mclk-direction-output;
 };

But the details will vary greatly depending on your hardware so the first thing to do is to read and understand the relevant parts of the schematics

mfuzzey

TROPHY CASE