I've done this for a cortex-m in qemu (meaning I wrote the chip and peripheral emulation code too for the timer, uart, sd controller with dma, and rcc). But I used buildroot. So much easier to keep track of everything and it's very easy to start with (unlike yocto). I recommend taking a look at buildroot.
You also don't need an MMU to run Linux. Just helps compatibility.
Great post, so neat to see it running in the browser! One question: why not thin the config a little? USB, SOUND, VGA, etc. are all slowing down the boot but don't have hardware to control.
This is a valid point a friend brought up as well. There's no reason all of this is enabled except for keeping the config simple. I only recently learned about `make tinyconfig` though which should let you creating a absolutely minimal config to start off of. I might add that as a note at the end
This complicated project was well executed, and I enjoyed it. I'm sorry your post wasn't more popular, I hope you won't be discouraged from sharing your adventures in the future!
really enjoyed this - great to see modern C++ as well, we were all on Assembly and C when I had to do this on a Freescale/iMX chipset for a wireless router!
So good though taking a reference design, re-laying it out with new modules and then bringing it to life with a scope and a datasheet.
I can only imagine how much will have changed with LLMs being able to be read and have a harness to do the hard work for you!
It tends to be vendor drivers / vendor patches. Getting frustrated that my changes aren't applied just to see that the vendor decided to hardcode a field or dynamically patch the device tree in undocumented ways is what usually gets me
I've done this for a cortex-m in qemu (meaning I wrote the chip and peripheral emulation code too for the timer, uart, sd controller with dma, and rcc). But I used buildroot. So much easier to keep track of everything and it's very easy to start with (unlike yocto). I recommend taking a look at buildroot.
You also don't need an MMU to run Linux. Just helps compatibility.
Good work
Excellent post. Your file format RE looks like an additional one to add to the reading queue as well: https://werwolv.net/posts/file_format_reverse_engineering/
Great post, so neat to see it running in the browser! One question: why not thin the config a little? USB, SOUND, VGA, etc. are all slowing down the boot but don't have hardware to control.
This is a valid point a friend brought up as well. There's no reason all of this is enabled except for keeping the config simple. I only recently learned about `make tinyconfig` though which should let you creating a absolutely minimal config to start off of. I might add that as a note at the end
This complicated project was well executed, and I enjoyed it. I'm sorry your post wasn't more popular, I hope you won't be discouraged from sharing your adventures in the future!
really enjoyed this - great to see modern C++ as well, we were all on Assembly and C when I had to do this on a Freescale/iMX chipset for a wireless router!
So good though taking a reference design, re-laying it out with new modules and then bringing it to life with a scope and a datasheet.
I can only imagine how much will have changed with LLMs being able to be read and have a harness to do the hard work for you!
What tends to be the biggest surprise when bringing Linux up on completely new hardware?
It tends to be vendor drivers / vendor patches. Getting frustrated that my changes aren't applied just to see that the vendor decided to hardcode a field or dynamically patch the device tree in undocumented ways is what usually gets me