Beginners step-by-step guide to building your own firmware


#1

Inspired by the Quick Image Building Guide I've written a guide which is meant to show any Windows or Debian/Ubuntu user exactly what to do in order to set up a system to build their own firmware. Let me know what you think: https://openwrt.org/docs/guide-user/additional-software/beginners-build-guide


#2

Docs are always hard. But always good to have more. I found the quick start guide was adequately simple. But I like that yours goes into those cases where the target is not straight forward. And should be good for those running windows.

I really wish that the devs would accept that PR (pull-request) on github for xconfig. That would be a BIG improvement for the config stage. Much better than menuconfig by far. It will be more familiar to windows users too.


#3

You could add that on windows 10 there is linux subsystem by default and users can use it to make it even simpler without that virtual OS stuff :slight_smile:


#4

Thanks, I've added a notice about it.


#5

@Per and @matemana2608 was just reading about postmarketos and they are saying that it's not possible to build under the win10 linux subsystem. Has LEDE build been tested under win10 linux subsystem?


#6

@per, as one of the Windows users here I appreciate you taking a stab at this, but at least for this (dumb) Windows user I really do not understand the tool sets and not clear which one I am using here.

Let me try to frame things a bit. I think there are 2 basic tools, Image Builder and Toolchain. Not sure I got the names correct. One creates from a set of packages and the other from source code which I guess are all the pieces on github. I also think that I can do either of these for snapshot or based upon the the latest LEDE release version, which I would suspect, assuming my device is supported, to be the safest way to build and also offer a fixed set of packages to use if I want to add more stuff later. Unfortunately the docs do not explicitly state which tool is being used, at least not in terms I understand.

I am not sure which process this guide is focused on, when\how to install the Supplementary Files located at the bottom of these pages or what file is what.
https://downloads.lede-project.org/releases/17.01.4/targets/ar71xx/generic/
https://downloads.lede-project.org/snapshots/targets/ar71xx/generic/

Regarding the Quick Image Building Guide (I realize you did not author this) am I correct that this totally omits my point directly above?

Finally, why would I use one too over the other?


#7

If all you want to do is customize an image quickly (add/remove packages, add files, modify default settings) -- you can use Image Builder. You can also use SDK in this case, but Image Builder is a simpler and quicker way to go.

If you want to patch drivers/packages or modify the compilation settings for a package -- you have to use SDK.


#8

@Blarty_Runfaster: It seems to build just fine. I haven't actually tried the resulting firmware and I did get a few warnings the first time I tried building. I haven't seen the errors again in subsequent builds, even when I tried to recreate them by deleting everything and checking out again. It's extremely slow, though, particularly if the virus scanner is enabled.

@RangerZ: I haven't used the SDK and I don't know the specifics about it. The guide uses the image builder. If you follow the guide you'll get a release image, and if you skip the "git checkout" under section 2.1 you'll get the snapshot (also called trunk). I can empathize with your need to understand "everything", I'm kind of like that myself. However, I have tried to skip explaining alternatives most users don't needed to know about in order to build a firmware. I think the guide is a bit long already.


#9

Hi.
What is the difference between
git clone https://git.lede-project.org/source.git lede
cd lede
git checkout tag_name

and
git clone -b tag_name https://git.lede-project.org/source.git lede

????


#10

I don't think there are any important differences in the resulting checkout. I just don't want to hard code a particular version in the documentation.


#11

This is good info to add to the docs. That way someone will know what to expect if they try it.