Greetings, any other devs in here? Some related tooling requests

General
1

Howdy,
First off, to start, a sign of appreciation and thanks. Great work, the OS runs reliably, I know this is a big undertaking, and great work so far.

Second, a quick intro, I guess, I think I’ll be involved here a bit. I got an RG35XX first gen when they released. I wasn’t following the scene or anything, I just happened to want to play some old emulated games on the go, and the timing lined up with that model. Loved it, still have it. I upgraded to an -H model this month, because I wanted both analog sticks, and network connectivity. One of the reasons I wanted network connectivity was to SSH into the device and run some software tests on it without having to swap SD cards between my computer and the system.

Anyways, so like I said I wanted to test some software I had written, an I ran into a couple speed bumps that surprised me. I was wondering if they’re worthy of feature requests, or at least some discussion.

First off I couldn’t find any C compiler installed by default. I think this would be good to include as standard for any custom software anyone wants to try to build (along with make, autoconf, etc).

So I tried to install GCC. Downloaded the tarball, SCP’ed it over, extracted it… a new issue arises. The default GCC binaries use symbolic links, and the SD card formatting is ExFAT which doesn’t support symlinks. Possibly something I can work around with aliases and bash functionality, and sort out, but its easier for me to just make an ext4 disk to support symlinks.

So I insert a new SD card, try to run mkfs, and find out there’s no ext support! Not even ext2.

Of course, this is a consumer device and it’s wise to take some of the Apple philosophy to “dumb it down” a bit, if only to take footguns away from the user, but for those of us that want to use the device a bit more classically linux-y, I think it would be good to have these tools installed. I doubt the average user would ever discover them.

Again I want to express thanks for the hard work

2

I’d recommend to cross compile, not to compile on-device. It will likely be much faster and cause less headaches.

The device is just aarch64 linux. Nothing particularly special about the programs it can run. Now if your program is a graphical one it is a little different.

The main thing is for display, we are pretty limited because there’s no window manager/X11/Wayland. The program needs to use SDL2 or OpenGLES ( or OpenGL via gl4es ). There is westonpack from PortMaster that can give you a sway window manager to run wayland/X11 programs but that is a bit involved to get running. I generally recommend to target SDL2 for best performance either way.

GCC or any compilation toolchain isn’t included in the image because it would just be bloat for 99% of users. Same reason we don’t ship a package manager or a lot of other “normal” linux programs. Users who are savvy are of course free to install one themselves. ( You would install it to the rootfs which is ext4, not to the exfat roms partition )

Since there is no package manager, installing stuff can be a bit of a task ensuring you have all the necessary libraries and such. But it is certainly possible. You can use something like Soar/pkgforge to find statically built programs.

The kernel does support ext4, the rootfs is ext4. I believe you can create an ext4 filesystem with mkfs ( not mkfs.ext4 ), with the -t flag but I haven’t tried as there’s not really a reason to be creating filesystems on-device. The filesystems are setup when you flash the muOS image and run the first time setup on-device. Should have plenty of free space in rootfs to install gcc and other programs if you wanted.

Again the reason these things are not included is because it would significantly increase the size of the muOS image and most people will not use them. The dev team cross compiles everything for the devices, and that’s what I’d generally recommend others to do as well.

3 Likes
3

Thanks for the insights. I figured cross compilation would be the popular way to go, but I’m in this for a bit of a pedagogical exercise as well… so I’ll probably dig this path a little further until I hit bigger roadblocks. More than a little bit is a stubborn need to prove it can be done. Previously, I would test these on the Raspberry Pi hooked up to my TV, again compile on-device, to give you an idea of why it’s in my head.

mkfs does fail with both the ext4 type flag and the shortcut, they print the same error even, pointing to mkfs.ext4. Just a heads up. It looks like this is a busybox thing, it’s not included in that, so perhaps your installer is running a different userland?

No need for full DE, just some SDL/OpenGL experiments I would like to revisit (I like to pretend someday I’ll release a game). I figured I’d have to set up some libraries, that’s fine, it’s all lightweight, pretty much all C90, compile time wasn’t terrible (but the pi also has 4x the RAM…)

Thanks for the tips on lightweight package managers. Soar looks pretty good.

Appreciate the information!

4

Yeah the mkfs not having the ext4 support isn’t really a big concern.

Like I said there’s not a particularly good reason to do disk operations on-device. Especially for ext4. You will just have more issues than anything, since ext4 isn’t supported for SD2, and SD1 is already ext4 for rootfs.

Like if you were to format SD2 as ext4, last I checked, it will get mounted, but because of the case-sensitivity a lot of the internal scripts, portmaster, etc. can have issues since they all assume non-case sensitivity.

If you absolutely have to you can shrink the exfat roms partition on SD1 and enlarge the ext4 partition, though there should be around 3gb of free space in rootfs to start with.

5

Ah thank you, that’s good to know about the physical ports having different compatibility. Understandable for your use case not supporting it, but yeah the idea was to use dedicated partitions anyways for all this tinkering.

I don’t see any information on building or modifying the install image… Are you guys keeping it locked down so some mfg doesn’t just steal it and slap their name on it? Makes sense. But I think I’ll just try wiping the ROMS partition, splitting that, and then restoring it’s contents… on my laptop :face_with_steam_from_nose:. Maybe someday I’ll do it all on-device and put it on youtube just because.

Thanks again

6

Actually, soar worked great, got gcc installed, guile is available so I can crack my Scheme knuckles a bit.

Alright one last question since we made so much progress - is there any documentation on adding to the applications page?

Edit- possibly easier just to write a portmaster script for now?.. I’ll look around, thanks for the info

edit2- yeah gcc not working due to linking issues on fusefs. Its okay I will partition myself and fix

7

The ports don’t have different compatibility. That’s just how the system is set up.

And I still don’t know why you think you need to partition the drive.

Just use the rootfs to build on.

Also the application script and a portmaster launch script are almost identical. You can look at any of the included applications to see how it is done.

As for the muOS image, all the stuff you need to create a muOS image is in the github. There are no instructions or anything currently, but all the tools and such you need to do it are there.

8

A lot just stems from me trying to use this software in a totally non-standard way

The ports don’t have different compatibility. That’s just how the system is set up.

I get what you’re saying, but I’m generalizing a bit too, digging further than needed is comparable to hw differences, but hw differences wouldn’t be fs level I guess - would make sense to me. Just saying good to know there’s discrepancies to be aware of.

And I still don’t know why you think you need to partition the drive.
Just use the rootfs to build on.

More about having something close to a full linux machine with the partitions I want long term. I’ll probably use symlinks from big collections of .STL, .OBJ, and GLTF assets, some audio, etc. A big SD card is cheap, I’m already at 128 GB. Just let me pollute some partitions without worrying about crowding rootfs. Additionally things like just imaging a whole /mnt/assets partition are more convenient sometimes than copying file-level, especially with reformats.

Also the application script and a portmaster launch script are almost identical. You can look at any of the included applications to see how it is done.

That’s what it seemed like, thanks, just a basic executable + options wrapped in shell. I can figure that out. Later I may want to play with other custom launcher options.

I appreciate the insights. I don’t intend to frustrate you, I’m just looking at this at a different perspective… I’ll write up a blog post and link it here if I ever get to where I want.
It’s much more a look at using these at didactic tools, I was investigating these concepts with the raspberry pi… but this is a $50 comparable SBC with built in battery+management, backlit screen, etc. Keeping it on a RG “CFW” makes it more accessible - more people have these lying around, than say a raspberry pi, but we can use it to teach computing skills that are declining. A standardized hw platform is almost necessary for this. Additionally, one designed around programming that instant visual feedback compared to tty text, would grab attention of the later generations. This is why love2d has done well - now having actual success, but being a well regarded learning tool before then. The Racket language’s guide really leans into graphical output of programming at the start, and I think that helps keep it interesting to the latest generations. Same with scratch and others. But you could also use an RG35**** to teach C, SDL, use gamedev to teach really fundamentally important concepts like the heap, stack, pointers, etc by teaching C, and having a mostly-standardized, commonly used platform is near ideal for this. I’d rather blog about doing this than starting with a QEMU or VirtualBox emulator, and at least part of it is because the hardware is consistent.

Sorry, got off on a soapbox there, but this is something I’ve wanted to investigate and blog about for awhile, and the final pairing of SBCs with functional hardware like power management, displays, USB OTG drivers… it’s making an old idea more alive. So that’s why I’m asking these questions.

9

No frustration I just don’t really understand the point.

Calling it functional hardware is a bit of a stretch imo. It’s nearly e-waste, designed to be as cheap as possible. Not anywhere close to the level of a RPi. More like the 3rd party ones that have 0 support. And if you have used those you know what I mean. The manufacturer of the SoC won’t even comply with the GPL. Mainline only exists for the platform because of many peoples extensive reverse engineering work and it’s not at 100% feature parity with the BSP kernel yet.

They are embedded devices, and should be treated as such. You probably wouldn’t be trying to run GCC and compile stuff on your router, nor would I expect someone to do that here.

That said it is already a full linux machine and you can of course do whatever you want. Just because it is not a desktop linux environment doesn’t mean that these devices are not a “full” or “normal” linux.

Personally I see no real value in trying to do it on-device, mostly just frustration and wasting time ( waiting for things to transfer, compile, etc ). Even an old computer will be much faster than these devices for compilation.

I don’t think anyone wants to program on a 3.5" screen, or at least not for very long. So if you are probably SSH’d in already what difference would it make to compile on-device or on another machine and ssh the binary/whatever over.

The only argument really is over HDMI but with no window manager or anything, trying to run say an IDE or something will be quite difficult. You can of course just stick to a terminal IDE via one of the terminal apps ( SimpleTerminal, sdlterm ), but I don’t see how that is any better than just connecting to the device over ssh.

You mention instant visual feedback but I don’t see how that is a possibility really. At least with muOS. Just to run a process from the frontend you need a launch script, which you probably aren’t making with a GUI app on-device. Unless you also plan to make said GUI app.

The skills and learning you get from having to use a computer, learning how to cross compile and set up a dev environment, etc are IMO far more valuable and transferable than platform specific knowledge to get X running on Y hardware.

I am not trying to dissuade you or say don’t do it.

But to me it sounds like you would be better off building your own distro off mainline or the BSP kernel to achieve what you want from the device.

Even StockOS with a desktop environment might suit your needs more than muOS. Since there you can have a full DE with GUI apps, mouse cursor, keyboard, etc.

2 Likes