NanoPi R4S-RK3399 is a great new OpenWrt device

No, you can update via LuCi update page with the linked image, you don't have to write it a microSD, just update.

This because the command to update is sysupgrade :grin:

If you're already running OpenWrt, just update from the UI with the SquashFS build, or you can keep the ext4FS if you prefer: https://duckduckgo.com/?q=squashfs+vs+ext4&t=osx

Thanks I am familiar with the upgrade process. I have OpenWrt on RPi for a while now.

But since there is no factory image to start with for R4S, what image are you burning to a blank microSD card for R4S ?

Everything you have linked so far is sysupgrade but you can't start with that with a blank microSD card obviously.

The sysypgrade etx4. I have never tried to start with the squashFS.

1 Like

I see. So even though normally with openWRT you have a 'factory' image before installing 'sysupgrade':

in the case of R4S you can actually just burn sysupgrade ext4 image to a blank microSD and it will start working?

Yes because "normal" routers don't have a microSD but have alredy a OEM OS, so with the "factory" you can -> go to OpenWrt.

Yes, but is the same for the RaspberryPI :thinking:

Anyway I can help but I don't know if this is not the correct place where ask these things, maybe ask in https://forum.openwrt.org/c/general/6?

My question is specific to R4S (this thread). I only mentioned RPi to say I am familiar with upgrade progress.

WIth RPi i see this below (see highlighted).

So when I got R4S and did not see factory image, I was obviously confused when you said to install sysupgrade image.

But thanks for clarifying that I can install R4S sysupgrade ext4 image to a blank microSD card !

Use a Factory image to flash a router with OpenWrt for the first time. You normally do this via the web interface of the original firmware.

Well, I don't know how a RaspberryPI can already run OpenWrt if it has no OS :thinking:

Reading the screenshot just above and what I highlighted, isn't that exactly what the factory image is for?

Factory = fresh install on blank microSD

Sysupgrade = already existing OpenWrt installation?

That's how I interpreted those descriptions.

Hence my confusion when you said I could start with sysupgrade ext4 image with a blank microSD card

So I know a factory image for R4S doesn't exist but I was confused that in this case you can start with sysupgrade image immediately

Factory is to switch from factory/OEM firmware to OpenWrt, but Raspberry PI has no firmware by default. I don’t know why it’s called in this way.

Maybe I’m wrong and some devs/more experts than me can answer.

1 Like

Ah ok! Well at least you can see why I confused when I was reading that screenshot above of factory vs sysupgrade.

So maybe this helps a future R4S owner here also. When they first get it and trying to install the first time

So previously I installed this build that someone linked early in this thread and then ran sysupgrade 22.03 rc6:

OpenWrt-AO-NanoPiR4S-full-21.02-20220806-ext4

I used that because I thought we needed a "full" installation, before the sysupgrade.

But now i know i can skip this first step. I just directly burned the latest 22.03 rc6 image below to microSD and it works fine. I was so confused but now its simple and working great

Even this description says 'to update a router that already runs OpenWrt' - but in my case it works fine with a blank microSD card :man_shrugging:

The name of the file/build could be whatever but the build you have linked is a normal ‘sysupgrade’ build, it’s only compiled by the GitHub user, as you can read from the changelog:

NanoPi R4S : r8168 driver for R4S (realtek) instead of kernel r8169 + r8169 firmwares package

The online builder has the same text for a router with internal flash storage, where you need the “factory” to switch to OpenWrt from OEM and the “upgrade”, and another x86/arm device that boot from an external card or it don’t runs any “router/modem firmware”.

It’s only a cosmetic issue, I’ve never read so carefully those texts, my fault :sweat_smile:

1 Like

All good! Thanks for your patience. I'm certain there will another person with same confusion so this will help them I think :laughing:

I am really liking R4S :slight_smile: So quick and easy to setup.

Only thing I install is stubby for DNS over TLS.

I thought not having HDMI would be an issue (I'm used to doing initial setup with a keyboard and monitor) but now I can see its easy to do all via SSH.

I enabled SSH keys, disabled normal SSH login, disabled Luci because I won't need it again until I do next firmware update.

Such a great router. I hope it stays supported by OpenWrt for many years.

I made a donation to OpenWrt also.

I have a dual gigabit RPi Computer Module 4 also coming.

I will compare the ease of setup with R4S.

The easier one , I will give to my parents. I want them to have something that I can update easily remotely.

1 Like

OpenWrt build appends some extra information as metadata at the end of the ".img.gz" image files. This metadata is used by the OpenWrt sysupgrade process to validate and verify the image before flashing.

This is why when expanding the R4S sysupgrade ".img.gz" images with 7-Zip we get the warning "There are some data after the end of the payload data" (this is the sysupgrade metadata).

Also, as others already explained, for regular routers the factory images are packaged in a special way (specific for each router manufacturer/model) so that they are accepted by the stock firmware in the first OpenWrt flash. For RaspberryPi and NanoPi there is no such thing as stock firmware since the initial flash is basically write the image to an empty SD card.

With that said, the RaspberryPi factory image is the same as the sysupgrade image except the fact that the factory image does not have the extra sysupgrade metadata. This was done just to prevent the warning messages when extracting the ".img.gz" image for the first SD writing. You can safely use the sysupgrade image also for the RaspberryPi the same way as for the NanoPi (just ignore the ".img.gz" unzip waring due to the sysupgrade metadata).

5 Likes

I finished to write the article of my “switch” from the R7800 as router and AP, to the R4S as router + AP: https://giuliomagnifico.blog/networking/2022/08/14/home-network_v3.html (long read). I hope it’s all correct.

5 Likes

Short update. Over the weekend I tested a few builds:

  • 22.03.0-rc6 ... works, did not find any issues
  • Latest master with kernel 5.15.60 (git as of yesterday morning) ... works, did not find any issues, now running it on my main router
  • I previously ran master with kernel 5.15.45 without any issues ... uptime about 1 month before I updated to 5.15.60

This is not meant to trigger yet another discussion which build one should use (release candidate vs. snapshot vs. custom build vs. FriendlyWrt), it merely states that those builds are working and I did not find any issues when it comes to my use cases.

7 Likes

I'll be honest, i don't think there was ever a discussion about which build is better to begin with...

What happened is that some people are still having reboot related issues with official openwrt, so others suggested that these people should try either friendlywrt or immortalwrt to see if the problem persists on those systems or not and if not, then clearly there is something wrong with official openwrt for the r4s and that maybe there is some code\patch from either friendlywrt or immortalwrt that should be ported to oficial openwrt.

But some decided that instead of doing a simple and fast test(which is to flash either friendlywrt or immmortalwrt and do some reboots), to just keep complaining like the problem will magically fix itself the more complaining one does :person_shrugging:

Also the kernel 5.15 PR for rockchip devices is still in limbo it seems :stuck_out_tongue:

2 Likes

Which build number? I tried the r20337 and it has k5.10.

I compiled r20337 with the testing kernel 5.15.60 on my build environment.

Everything for 5.15.60 is already in git, the last missing piece is pr10123 which addresses issues with some kernel modules under kernel 5.15 (one might not need) … thus I‘d recommend adding this patch if you build yourself.

Oh okay, because I download it from the repo and it still has k5.10. I’ll wait until will be merged in the master at least.