Bunnie – Linux in the Flesh: Adventures Embedding Linux in Hardware
As CPU speeds growth has stall mobile CPUs have caught up with Desktop CPUs
Cost of Mobile CPUs $20 on intro vs $X00 on intro for desktop CPUs
Time spend making a product
- 11% on Hardware design – schematic and PCB layout
- 20% on product and software dev
- 33% in mass production ramp
Giving Linux a body
- Consumers don’t like bare boards
- Comprehensive 3D models
- Build injection molds – Steel cut, EDM tidy, Hand polish
- Around $20k to create tool
- People like Apple will start multiple tool runs and keep the best
- General rule – $99 product you want to sell wholesale for $30
- Magic prices products sell at $99, $149, $199
- 90% of hardware sales between Black Friday and Christmas. Can’t ship just after Christmas
Chellenges of Embedding Linux
- Embedded CPUs have lots of weird bugs
- Bootloaders
- CPU-Specific media loaders
- Firmware has raw Iron – NO MMU, No DRAM, etc
- Small memory footprint
- Linux runs just a few MB of memory
- Every $ counts, lots of time fixing code
- Flash File Systems
- Few 1000 read/write cycles
- No write g’teed to succeed
- Power-down corruption is a fact of life, need backup or read-only copies
- Power Management
- Reduce frequency and voltage when CPU is lightly loaded
- Need to adjust for high and low load
- Rouge processes can chew CPU/Power
- Lots of auditing needed
- User apps are hard
- Suspended / Sleep hard
- Drivers might be written with this in mind
- Huge number of devices that can be plugged in, lots of drivers to verify
- Dev community
- Smaller pop that desktop
- Updates and patches and rollout and distribution hard to do, must do yourself
- Software is the major bottleneck – cause it is easy, you can do anything
- System architect must create a useful cage for the software dev
Case Study: Robot Vision
- Kovan
- Needs to do image processing
- Lots of choices
- Using FPGA on PCIe uses up all of memory bandwidth in small systems
- Connect via USB means it is just a “camera driver”
- Connect between Soc and the Screen
- Or between SoC and the DRAM
- Ended up between SoC and LCD
- Ends up as /dev/fpga
- Handle multiple types by probing
Case: NeTV
- Goes between device and screen
- Overlay stuff over video
- But signal is all encrypted
- Sync Pixels and replace one by one using Man-in-the-middle attack on encrypted signal!!!
- Very hard to get timing, drift of 100s of pixels per frame
- Source clock from the incoming signal
- A few other tricks
Dev Enviroment
- Created Amazon AMI to help people get up and going
- But hardware devs not used to using these
- Not a 100% fit to normal dev model