Buildscript

[lfuelling]

Hi,

This PR adds a build script and a proper README to go-play. The README explains how to build the firmware using the script and offers help for some potential pitfalls. There is nothing else the user has to install besides the dependencies of esp-idf. The script will very probably not run on Windows.

The odroid-go-firmware repo was added as subproject so the script has easy access to mkfw.

The script works by first building mkfw and the go-play subprojects, then it checks if a tile.raw file is existing and if not extracts it automagically from the latest prebuilt Go-Play.fw file available on GitHub using efwt. After that it fetches springboard.bin from a connected ODROID Go and compiles all the stuff using mkfw.

I used code from @23pieces' Odroid-Go-Tools project which is licensed under the Apache 2.0 license. I added headers where required to have the correct attribution.

[ghost]

Hey dude!

Nice stuff, maybe i didn't invest enough time into the description :D I changed fair a bit of the odroid firmware, pull request is still open^^

[lfuelling]

Nice, I hope it's merged before this PR gets, so it's included here.

[kamotswind]

I think this script would violate the Springboard license and/or Terms of Use.

[lfuelling]

Oh I didn't know there actually was a license for it. All I know about it is what @OtherCrashOverride wrote in the forum: It's not open source and you need to pull it from an already flashed Odroid to build go-play.

Additionally I'd really like to know which part the script violates as it doesn't provide/redistribute nor decompiles the springboard.bin.

[kamotswind]

I could be wrong, just wanted to mention it. @OtherCrashOverride is obviously the best resource on that information.

[OtherCrashOverride]

I mentioned in other places (issues, forum) that building a Go-Play.fw is not supported.

[nicolaisueper]

Taken from the ODROID-GO's web presence

It is not only a fun assembly project but also an educational tool to learn about all the hardware and software that goes into building such a device.

I think it is a bad decision to keep that whole springboard thing closed source. Many people could learn from these sources, especially the way how you handle ESP32 related code.

My 2 cents: it is not the idea of Open-Source-Software to keep the most interesting code closed.

[kamotswind]

Springboard is just a menu, there isn't anything really exciting there. It is actually a very very small part of the code. The emulators are the vast majority of what Go Play is made up of and they are all open source.

[lfuelling]

AFAIK Springboard contains the partitioning magic that add the ability to boot different programs without reflashing using the BIOS.

Also springboard doesn't generate strange sounds when controlling the display while every program I wrote up to this point does.

It's not about the menu, it's the ESP specific tweaks we're I am interested in.

[nicolaisueper]

Springboard is just a menu, there isn't anything really exciting there. It is actually a very very small part of the code. The emulators are the vast majority of what Go Play is made up of and they are all open source.

I think menus are quite exciting. Especially for Web-Devs who want to dive into microcontroller GUI programming. Unfortunately I cannot use React for that.

[OtherCrashOverride]

AFAIK Springboard contains the partitioning magic that add the ability to boot different programs without reflashing using the BIOS.

The partitioning "magic" is done by the odroid-go-firmware. It is specified as part of the .fw file and any application can make use of multiple partitions. https://github.com/OtherCrashOverride/odroid-go-firmware

The API used to select the active partition is open source and shared by go-play: https://github.com/OtherCrashOverride/go-play/blob/c573693f91864e116c6ccd6a18becbb020506f3b/odroid-go-common/components/odroid/odroid_system.c#L14-L29

Also springboard doesn't generate strange sounds when controlling the display while every program I wrote up to this point does.

Setting IO25 "low" or writing "zeros" to the internal DAC will mute the audio amplifier.

it's the ESP specific tweaks we're I am interested in.

Springboard does not contain any ESP "tweaks". It is a menu program that allows selecting a file and rebooting into an emulator to use that file. Any non-trivial functionality was moved into either odroid-firmware or go-play.

[OtherCrashOverride]

Its also worth noting that I am not a corporation or HardKernel employee. I am simply someone sharing a personal project on github like many others do.

[lfuelling]

Thank you very much for the information. ❤️

If springboard is not an integral part of go-play, why is it a problem to add a buildscript so people can try tweaking the firmware? (My side project is increasing the GBC emulation speed a bit)

It's not that you have to provide support for those. You can still add a disclaimer saying that the buildscript and any products of it are unsupported. It's just for the ones that like to fiddle with things to make it easier.

It's also worth noting that I am not a corporation or HardKernel employee. I am simply someone sharing a personal project on github like many others do.

Very impressive that you got your personal project to be factory delivered with the go. 👍

[BenMcLean]

I don't understand. Why the hell would something be closed source if it is trivial?

[kamotswind]

If someone spends their personal time creating something cool there is nothing requiring them to release the source code for it. A lot of work has gone in to the code that is public and work continues on the public code. I think it has been well over two months since Springboard has changed at all because there is nothing more to do on it. All of the innovation where the vast majority of development time was spent is part of the public code here on GitHub. Having a demanding attitude towards something you didn't pay for is a great way to kill the motivation of community developers.

The ODROID-GO continues to get really cool updates and expansion to its capabilities via software written as a hobby by community developers like @OtherCrashOverride @Schuemi @mad-ady @DavidKnight247 and others. I've also contributed a little and I hope to contribute more. I hope more developers jump in and start writing software for this platform. With the new hardware keyboard there are a lot of new possibilities. I have been so busy playing with the Commodore 64 emulator using the keyboard I haven't even seen the Springboard screen in weeks. 😃

Be supportive and constructive, not demanding and destructive.

[lfuelling]

I hope more developers jump in and start writing software for this platform

That's exactly what we want to do. We want to try to enhance a piece of software that we really like. But the maintainer now tells us we are not allowed to do so because while the software itself is "open source", some small component is not and because of this we have to treat the software as if it were closed source.

Tinkering with the emulator code (at least for me) requires constant rebuilding which is extremely accelerated using the script.

[kamotswind]

You have the script and it is working. I don't see an issue. If this pull request is merged in then the script becomes something that @OtherCrashOverride needs to maintain instead of you. I think the best solution is to host the script on a separate GitHub repository and open pull requests for updates to the emulators. There is nothing causing you to treat the software as closed source. The emulators will run fine without Springboard or any menu system.

Actually it looks like this pull request should be made to https://github.com/23pieces/Odroid-Go-Tools

[lfuelling]

Nah, he doesn't. As I already wrote it would be enough to write something like:

Please note that the manual compilation is not supported at all and if you want support you have to use the official image you can download on the releases page.

This way, people that want to build the rom themselves can do and there is no increase in TODOs for @OtherCrashOverride. I would also offer myself to write this information onto every ticket that gets opened because of selfmade roms.

---

No, I used code from that repo, modifed it and put it into this repo. This way you only have to clone this single repo and execute the script without any configuration to do a build.

[BenMcLean]

If someone spends their personal time creating something cool there is nothing requiring them to release the source code for it.

True, but if they don't, then the rest of the community ends up having to work around them and replace what they did.

[kamotswind]

@lfuelling I still recommend submitting the pull request to the other project and/or hosting your own Go Play repository with this script.

@BenMcLean I was actually going to write a replacement menu but I decided against it because everything I wanted to do with the firmware was outside of the menu anyway. Someone else is already working on a new menu but I can't recall the repo name right now. This is an open platform and anyone can make anything they want for it. Nothing is stopping or hindering that. Clearly scripts already exist that build Go Play without having the source code for the menu.

I really don't have anything more to say on this. I hope you both understand.

[BenMcLean]

@OtherCrashOverride all your efforts are much appreciated.

At the same time, if no one can build Go-Play except @OtherCrashOverride then it's time to fork.

[nicolaisueper]

When I bought the ODROID-GO I first thought "Hey, this is neat, an open sourced handheld emulator. Maybe you can learn how others do micro controllers / hardware stuff and extend this further" but I was disappointed.

I also appreciate all the efforts invested into this project / ecosystem as @BenMcLean already said, but one thing bothers me:

• Sell a 'open and hackable' device
• Let a person, which is not related to this product whatsoever (see @OtherCrashOverride 's comment) develop the firmware and UI
• Keep the UI closed source
• ???
• Profit

That's not really open source, isn't it?

And please consider the following fact:

Your project is based on others software, like the emulators for instance. Without these projects, you wouldn't be selling this product.

Open Source means Open Source and not "keeping the drawer closed source because of reasons and such".

[lfuelling]

Clearly scripts already exist that build Go Play without having the source code for the menu.

Yes, they do exactly what the script in this PR does: Pulling the springboard.bin from a prebuilt rom running on the Go.

[BenMcLean]

I seem to remember that GPLv2 allowed GPLv2 code to be bundled together with binary blobs like springboard, but GPLv3 doesn't. Is that correct?

[nicolaisueper]

@BenMcLean taken from https://en.wikipedia.org/wiki/GNU_General_Public_License#Terms_and_conditions

The fourth section for version 2 of the license and the seventh section of version 3 require that programs distributed as pre-compiled binaries be accompanied by a copy of the source code, a written offer to distribute the source code via the same mechanism as the pre-compiled binary, or the written offer to obtain the source code that the user got when they received the pre-compiled binary under the GPL.

[BenMcLean]

I don't see how that answers this specific question about binary blobs

[nicolaisueper]

I misunderstood you. Sorry.

I searched a while and only found this stackexchange answer, which addresses a different issue. Please see the topmost answer: https://opensource.stackexchange.com/questions/2688/do-you-violate-the-gpl-if-you-provide-source-code-that-cannot-be-compiled?answertab=votes#tab-top

[nicolaisueper]

If you distribute binaries, then GPL requires that you also distribute all the files necessary to rebuild that same binary, and to make modifications.

[BenMcLean]

If that is correct (GPL means "no binary blobs") then distributing these emulators together in the same binary with springboard may (not sure) violate the GPL.

[lfuelling]

That's why I don't distribute the springboard.bin. You need to have a preflashed Odroid Go connected for the build to work. (https://github.com/OtherCrashOverride/go-play/pull/78#issuecomment-430805165)

[nicolaisueper]

@lfuelling I think the point is that you are not allowed to distribute your compiled binaries (like the springboard.bin) along with GPL licensed projects (like the emulators) without providing the sources to build it all yourself.

[OtherCrashOverride]

The Go-Play.fw is a application provided by me. While HardKernel (HK) is kind enough to include it on ODROID-GO hardware, it is done as a convenience to their customers, and I have no involvement. Again, I do not sell ODROID-GO hardware nor do not receive profits from ODROID-GO hardware sales. If there are concerns regarding the "openness", the device flash can simply be erased and 100% open source software installed. The purpose of this repository is to provide the software that is open source. In the future, each emulator will be enhanced to provide its own file selection menu allowing it to be packaged stand-alone (https://github.com/OtherCrashOverride/go-play/issues/79).

Since it appears to be a point of confusion, I will investigate removing the pre-compiled Go-Play.fw application from this repository. Hosting it elsewhere should help distinguish what is an open source project and what is a 3rd party application. Since Go-Play.fw will no longer be provided here in the future, there is not a reasonable argument to merge a build script for something that will no longer exist.

As a software developer, license compliance is always a top concern of mine. The code in this repo is all licensed GPLv2 as per each sub-projects original designation. The menu program exists as a stand-alone application authored entirely by me and does not contain any open-source libraries or code other than what I have authored and retain copyright to. The menu program does not link any of the GPLv2 emulator code, nor is it resident in the system memory at the same time as any of them. It resides in its own flash partition, and the system reboots to activate an emulator. This is similar to having Windows and Linux on the same HDD or SDD.

[nicolaisueper]

lmfao this just made my day.

[lfuelling]

Thanks for clarifying this.

I think you (or odroid) should not call go-play "open source" as one is not able to rebuild it from source. Instead you should call it "using open source components" which makes it clear to keep your fingers away if you are interested in OSS. (Kind of like Google Chrome)

@nicolaisueper: seems like github.com/PocketSprite is proper open source (as in "builds") and their hardware also uses the ESP. Maybe we can do a port or sth.

[lfuelling]

@OtherCrashOverride You said, you don't get money from OGO sales nor the company as is.

Would you get less (than nothing, haha) by making springboard open source? Not that I'm still interested in contributing after this, I just don't see any logic besides "this is MINE" here.

[mad-ady]

I've been away for a while, sorry. I don't want to add fuel to the fire, but I'm not with @othercrashoverride on this one. But this may be due to the lack of respect for intellectual property/copyright environment I grew up in (Eastern Europe). So grabbing a binary and repackaging it sounds fine to me. I also see the use case - if somebody changes an emulator and wants to use the "stock" launcher, while keeping the option to flash something else and return later to the roms by writing their modified fw file.

The changes should be preserved in a fork or different project if they are not accepted.

By the way, this is the alternate launcher: https://github.com/rosarior/Rocket-Launcher

[OtherCrashOverride]

@mad-ady Thank you for your feedback. However, it should be pointed out that the alternative launcher link provided is also closed source.

[OtherCrashOverride]

This launcher appears to be open-source: https://github.com/jkent/odroid-go-launcher

[tuxBurner]

FACEPALM