First steps for building firmware for a new device?

Hello there!
I am a electronic engineering student. That means that I know the basics about programing, but I don't have the same amount of experience like you, guys.
So, for my research, I was trying to figure out what are the steps that are necessary to take for making a build of Openwrt for a new device.
I tried to read the developer guide ( https://openwrt.org/docs/guide-developer/start ), but it has so much info that I got lost. Haha.
So, If anyone with experience with this can help me... What steps did you take to make a new build for a new device?
Did you needed the source code of the original device's firmware, or maybe some hardware schematics? And if you have both... What's next?

Greetings from Paraguay! :slightly_smiling_face:

This really mostly depends on the exact device you are talking about. In the best case, e.g. when a vendor does it's own electronics, of course, one has full access to them schematics but likely no source code yet. Resp. in such case one usually starts with source code from a reference device (e.g. sometimes provided by chip vendors) or, alternatively, just any already supported devices which is as close as possible Hardware wise. However, the more common use case, especially for hobbyists, is to take a commercial device and try to port OpenWrt to it. In this case, likely no schematics are published anywhere publicly. With "good" vendors one may get access to more or less useful GPL sources which can definitely come in handy. Anyway, the first step is usually to get access to the bootloader via some serial UART header using an FTDI USB-to-serial adaptor or the like. And a next step might involve network- aka TFTP-booting an initial RAM disc based mage. This has the advantage that the device's flash does not need to be touched yet but stuff can somewhat easily be tried.

2 Likes

And, of course, before one can try booting an image one likely first has to build such customised image. So getting up-to-speed on how to do builds will also come in handy. In real tricky cases, you might not have access to any useful bootloader and would have to start doing such a port first which may get even more tricky if you would need to do e.g. the RAM initialization from scratch first. So you see it is all much case by case. The nice thing about this forum is, that you may talk about stuff step by step and get some specific guidance on the way. Good luck!

1 Like

Thank you very much for your answer!
So, based on your aswer, these wolud be some guide steps:

  • Look for schematics, or GPL sources for this "X" new device.
  • If source not avalaible, then look for similar hardware device's source for a reference.
  • Get access to bootloader via serial UART (adaptor may be needed).
  • build a custom image.
  • Try to do a TFTP booting of a RAM dis image, via network (Advantage:stuff in flash memory is not modyfied)

I have some doubts, tho.
We are talking about new hardware here. So, It seems logical to me that, in order to work, it should have it's own drivers for the operating system. Is that the case?
Or are there some generic drivers in this OS distribution that should work anyway?

You are very welcome.

Yes, that about cuts it.

If it is truly new hardware, meaning nobody has ever run any software on it yet then what needs to be done first is usually referred to as initial hardware bring-up which involves both hardware (e.g. checking main voltage rails, clocks/crystals resonating and stuff like that) and software (e.g. boot modes, RAM calibration, boot loader, Linux kernel aka device tree) activities.

Somewhat, yes. However, it is usually not you/us writing those. Resp. one would need to differentiate whether or not that particular SoC used is already supported. If it is an entirely new chip (family) then somebody with deep technical knowledge about that particular chip(s) with access to its datasheet would need to do initial software bring-up and sorting such "drivers". And even there, usually, one can somewhat base it on something close/else (e.g. ARM chips don't differ significantly) unless it would be a completely new chip architecture. As for higher-level (than boot loader) software it is rather rare to require entirely "new" drivers. Most work at the Linux kernel level involves writing a device tree aka hardware description so the existing drivers know where to find stuff (e.g. interrupt routing, pin muxing, etc.).

Well, generic or not but the Linux kernel definitely has thousands if not millions of drivers already supporting a wealth of devices.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.