Massive GL-S1300 stock to openwrt firmware

makedit · 2021-04-13T08:33:29.026Z

We have 200 GL-S1300 and need to install our custom openwrt image.

Is there any method to flash the transition image automatically? For example, by tftp.

Would be possible to prepare a system with a tftp server so we could start uboot and update itself or would we have to manually install the transition image?

Thanks,

makedit · 2021-07-26T18:06:16.036Z

Hi @hansome, is there any method to install s1300-factory-to-openwrt.img and openwrt automatically when booting into uboot with the reset button?

I could prepare two GL-AR300M with TFTP and use one to flash s1300-factory-to-openwrt.img and another one for the openwrt image, this way it would boot plugged to the first one and when finished it would boot plugged to the second one.

Thanks

hansome · 2021-07-27T04:08:19.292Z

Hi,

Automatic upgrade by tftp can be turned on by setting uboot env:
By openwrt command:

fw_setenv tftp_upgrade 1

or uboot command

setenv tftp_upgrade 1
saveenv

And the filename should be renamed:
s1300-factory-to-openwrt.img → qsdk-gl-s1300.bin
openwrt.bin → openwrt-gl-s1300.bin
and it should be put on two tftp server as you think.

Better flash openwrt-gl-s1300.bin firstly, when finished it will still boot to factory firmware, then power off and switch to tftp server with qsdk-gl-s1300.bin file.

Here’s the latest uboot source and s1300-factory-to-openwrt.img

makedit · 2021-07-27T09:45:20.522Z

Thanks, i will try it.

Is possible to activate IP by DHCP instead 192.168.1.1? That way i could connect multiple GL-S1300 at the same time.

alzhao · 2021-07-27T10:16:40.834Z

You cannot connect multiple at the same time. Just one by one.

makedit · 2021-07-28T12:27:54.571Z

I’ve prepared the environment and works like a charm.

I’ve to compile the final image and start the process.

Is there any problem if I leave tftp_upgrade activated or should disable it after flashed?

hansome · 2021-07-29T08:07:49.050Z

Some user will think it is a security issue, say, if the system reboot, and there’s a tftpd server with ip of 192.168.1.1 on your LAN network and firmware file ready, the firmware will be flashed.

makedit · 2021-07-29T09:19:18.648Z

Yes i’m thinking about that, i see more as a feature than a security issue.

Let me explain, Three conditions must be met in order to upgrade:

There must be a host with the ip of the update server.
It must have a TFTP server.
It must have exactly the file name you are looking for.

If these three conditions are met … you know what you are doing, why should I stop you?

My question was more about whether there might be a conflict, but I’ve already seen that a problem was solved if there was a host with the ip of the update server but the TFTP server was not responding.

In any case, I’ll probably end up installing uboot-envtools and /etc/fw_env.config in our firmware to disable the auto-update once the process is finished.

Thanks.

alzhao · 2021-07-29T15:32:47.980Z

Anyway I think you should disable the environment after you use.

makedit · 2021-08-03T18:09:58.096Z

I’ve compiled uboot-envtools to be able to disable de auto update once finished, but i get …

root@XXXX:/# fw_setenv tftp_upgrade
Can't open /dev/mtd5: Permission denied
Error: can't write fw_env to flash

I’ve added the same fw_env.config file that is in the stock firmware.

root@XXXX:/# cat /etc/fw_env.config
/dev/mtd5 0x0 0x00010000 0x00010000 1

What is missing?

Thanks.

makedit · 2021-08-04T07:30:10.353Z

I’ve been able to update uboot env making the partition writable, removing the line

github.com

openwrt/openwrt/blob/b37f0dde78656a352914c4d01010979530589103/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4029-gl-s1300.dts#L197


      
          
          
			DDRPARAMS@d0000 {
          				label = "DDRPARAMS";
          				reg = <0xd0000 0x10000>;
          				read-only;
          			};
          
          
			APPSBLENV@e0000 {
          				label = "APPSBLENV";
          				reg = <0xe0000 0x10000>;
          				read-only;
          			};
          
          
			APPSBL@f0000 {
          				label = "APPSBL";
          				reg = <0xf0000 0x80000>;
          				read-only;
          			};
          
          
			ART@170000 {
          				label = "ART";

But stock firmware can write uboot env and partition is read only. I’ve seen in the files (i don’t know what are you using in stock firmware)

Branch openwrt-19.07.7

github.com

gl-inet/openwrt/blob/3e71f9692444831c1996af741c5e103339e5c7d8/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-s1300.dts#L231


      
          
          
		DDRPARAMS@d0000 {
          			label = "DDRPARAMS";
          			reg = <0xd0000 0x10000>;
          			read-only;
          		};
          
          
		APPSBLENV@e0000 {
          			label = "APPSBLENV";
          			reg = <0xe0000 0x10000>;
          			read-only;
          		};
          
          
		APPSBL@f0000 {
          			label = "APPSBL";
          			reg = <0xf0000 0x80000>;
          			read-only;
          		};
          
          
		ART@170000 {
          			label = "ART";

Branch openwrt-18.06-s1300

github.com

gl-inet/openwrt/blob/e27d3da8908ad48227ba4f7907259b7eb7740c6b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-s1300.dts#L243


      
          
          
		DDRPARAMS@d0000 {
          			label = "DDRPARAMS";
          			reg = <0xd0000 0x10000>;
          			read-only;
          		};
          
          
		APPSBLENV@e0000 {
          			label = "APPSBLENV";
          			reg = <0xe0000 0x10000>;
          			read-only;
          		};
          
          
		APPSBL@f0000 {
          			label = "APPSBL";
          			reg = <0xf0000 0x80000>;
          			read-only;
          		};
          
          
		ART@170000 {
          			label = "ART";

Branch openwrt-trunk

github.com

gl-inet/openwrt/blob/b7349722a31deb5b7ec5f7698b1ab8a0afa4a56d/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4029-gl-s1300-emmc.dts#L201


      
          
          
			DDRPARAMS@d0000 {
          				label = "DDRPARAMS";
          				reg = <0xd0000 0x10000>;
          				read-only;
          			};
          
          
			APPSBLENV@e0000 {
          				label = "APPSBLENV";
          				reg = <0xe0000 0x10000>;
          				read-only;
          			};
          
          
			APPSBL@f0000 {
          				label = "APPSBL";
          				reg = <0xf0000 0x80000>;
          				read-only;
          			};
          
          
			ART@170000 {
          				label = "ART";

Is there any other way, more secure, to be able to update uboot env without making the partition writable?

hansome · 2021-08-05T06:35:36.972Z

Removing read-only is secure as you do. And in stock firmware all partitions are writable, can be checked here, it’s not using the gl-inet/openwrt repository.