Newer but not the last patch. I would love if somebody could help updating the LEDE branch to the lastest patch version including the packages.
why don't you try it?
you have everything that's needed
this community members are more than happy to help you get started on compiling - just open a new thread
I compiled OpenWrt before. That is not the problem. The problem is to learn a good workflow to update all packages without spending a month on it.
We need to update the packages and the patches in Openwrt that are applied on top of them. Even assuming this is not difficult, there is a high chance of introducing regression bugs. And then you fix problem on a router and you break another one.
Then there are patches that are committed on the main branch 18.06 and some of them should be applied on LEDE too. Which ones? Not sure.
Assuming I can make it work, in one month the process needs to be repeated. It is not something that just one person can maintain. The reason why we do not have an updated LEDE is because the core developers do not want to do. They think it is too much work. More people can help for sure.
Maybe we can simplify. My goal is mostly to keep the router secure (security patches applied) and not introducing new vulnerabilities.
It would be good to learn best practices. For example what do core developers do when the time of a release come up? How do you update the packages in an efficient way? Are there some scripts that make the process easier?
the first thing you should do is accept the idea that you can't apply all security patches that appears. then follow the code of a release like 17.01 that will soon be EOL 
(but the kernel of 18.06 is too big so far..)
this similar device now appears to have a larger kernel layout ?
MTDPARTS := spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,16000k(firmware),64k(art)ro
http://www.gl-inet.com/products/gl-usb150/
https://openwrt.org/toh/hwdata/gl.inet/gl.inet_gl-usb150
https://git.lede-project.org/?p=source.git;a=commit;h=90d8c0f0a2f4c902348a2f514ba33f2c9c34e005
281 define Device/gl-usb150
282 DEVICE_TITLE := GL.iNet GL-USB150
283 DEVICE_PACKAGES := -swconfig
284 BOARDNAME := GL-USB150
285 IMAGE_SIZE := 16000k
286 CONSOLE := ttyATH0,115200
287 MTDPARTS := spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,16000k(firmware),64k(art)ro
288 SUPPORTED_DEVICES := gl-usb150
289 IMAGE/sysupgrade.bin = append-kernel | pad-to $$$$(BLOCKSIZE) | \
290 append-rootfs | pad-rootfs | append-metadata | check-size $$$$(IMAGE_SIZE)
291 endef
292 TARGET_DEVICES += gl-usb150
1 Like
it would be awesome if of this gl-usb150 uboot would be a drop in replacement...
I think the best way to handle the size problem is patching the bootloader.
Probably I could make it possible soon. I will write if I have some news
2 Likes
I write some configs to make it automatic build image weekly, here is the project:
It's simply patch 0001-Zsun.patch to the latest 17.01 code and build it.
Files download there (sdk and image builder include):
https://ci.appveyor.com/project/puteulanus/zsun-builder/build/artifacts
NOTE that I lost my wireless hardware last month when I weld the ttl, so there is NO TEST for those images.
4 Likes
Before we can change mtd parts layout in u-boot, remove IPv6 support may be a way to reduce the kernel size for 18.06... At least, for me only, I dont need that.
1 Like
I bought a new zsun device and tested build 1.0.72 (based on LEDE Reboot 17.01-SNAPSHOT r4013-981f5f7e40), it works.
Uh, please tell me more...
Where did you get this one?
What tweaks have been made to make kernel fit etc...
Oh, I mistakenly read 18.06 instead of 17.01 my bad.
Although I never did get the sdcard to work correctly with 17.01 iirc.
Hi,
I bricked my Zsun in my experiments. I tried serial uploading maurer's openwrt-ar71xx-generic-zsun-sdreader-min270416.bin (SHA1: 2681d410f99cf7b796d85922ac9bc962acfea968) with https://github.com/maurerr/ubootwrite
python ubootwrite.py --serial=/dev/ttyUSB0 --write=openwrt-ar71xx-generic-zsun-sdreader-min270416.bin then erase 9f020000 +270000 and cp.b 80060000 9f020000 270000 as instructed by the script.
But when I try to boot afterward, I got
## Booting image at 9feb0000 ... Bad Header Checksum
Could anyone help me with reocvering this? What did I do wrong?
Thank you
You should write the mini image twice.
This is the mini image layout:
# binwalk openwrt-ar71xx-generic-zsun-sdreader-min270416.bin
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 Squashfs filesystem, little endian, version 4.0, compression:xz, size: 1404282 bytes, 557 inodes, blocksize: 262144 bytes, created: 2016-04-27 10:46:19
1572864 0x180000 uImage header, header size: 64 bytes, header CRC: 0x640615F8, created: 2016-04-27 10:46:20, image size: 978457 bytes, Data Address: 0x80060000, Entry Point: 0x80060000, data CRC: 0x2E1DC8BB, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS OpenWrt Linux-3.18.20"
1572928 0x180040 LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 3019372 bytes
This is the mtd parts layout:
# cat /proc/mtd
dev: size erasesize name
mtd0: 00010000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00e90000 00010000 "rootfs"
mtd3: 00130000 00010000 "uImage"
mtd4: 00010000 00010000 "NVRAM"
mtd5: 00010000 00010000 "ART"
For a normal image, there are blank datas in between. 9F020000 is based on an address 9F000000, which means the start of the mtd. 020000 is the hex of 131072byte (128kb), because we have 64kb mtd0 "u-boot" and 64kb mtd1 "u-boot-env". So when you write "rootfs - blank_data - kernel" to that address, roofts data and blank data will full the mtd2 "rootfs", then kernel data will in mtd3 "uImage", the blank data helps to keep the kernel data in the right location.
But mini image doesn't have blank data, that's why it's small.
So, first wipe rootfs and kernel(erase 9f020000 +fc0000), after upload the image to the ram(80060000) you should copy 180000 to 9F020000(cp.b 80060000 9f02000 180000), then copy F0000 to 9FEB0000(cp.b 801e0000 f0000).
What you have done is write both rootfs and kernel in mtd2 "rootfs", that's why when u-boot try to boot from 9FEB0000(15400960bytes = 64kb u-boot + 64kb u-boot-env + 14912kb rootfs, so that address is begining of mdt3 "uImage") it said Bad Header Checksum, you didn't write kernel to mtd3.
BTW, write the u-boot is faster way. You can write Eddiecz's u-boot by ubootwrite.py to 9FE00000 which means mtd0 and then use Ymod download upload normal image to ram. It's much more faster than ubootwrite.py. But also be noted that it's dangerous, broke u-boot means you almost lost everything.
1 Like
I forked pepe2k/u-boot_mod and add some config for zsun. Commit dcf9c7d works with Ymodem.
***************************************
* U-Boot 1.1.4-c8367107-dirty *
* Build: 2019-05-31 *
***************************************
** Warning: bad env CRC, using default,
use 'saveenv' to save it in FLASH
BOARD: ZSUN WiFi SD Card Reader
SOC: AR9330 rev. 1
CPU: MIPS 24Kc
RAM: 64 MB DDR2 16-bit CL3-4-4-10
FLASH: 16 MB Winbond W25Q128FW
MAC: 00:03:7F:11:56:48
CLOCKS: CPU/RAM/AHB/SPI/REF
400/400/200/ 20/ 25 MHz
Keep button pressed for at least:
- 5s for U-Boot console
- 7s for network console
. . . . . . . . . . 0xA seconds
## Error: 10s limit reached!
Continuing normal boot...
Hit any key to stop booting: 0
Booting image from 0x9FEB0000...
Image name: MIPS LEDE Linux-4.4.167
Build date: 2019-04-20 13:42:38 UTC
Architecture: MIPS
OS/image type: Linux Kernel
Compression: LZMA
Data size: 1.1 MB (1196959 bytes)
Load address: 0x80060000
Entry point: 0x80060000
Header CRC... OK!
Data CRC... skipped
Uncompressing Kernel... OK!
Starting kernel...
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
Please press Enter to activate this console.
Boot address is in u-boot/include/configs/ap121.h:280 and mtdparts seems in u-boot/include/configs/ap121.h:181. Now we can increase kernel partition instead of reduce kernel size for 18.06.
u-boot can be made by command: make zsun-sdreader
3 Likes
Resize mtdparts and build openwrt 18.06.1 with IPv6 success.
***************************************
* U-Boot 1.1.4-dcf9c7d2-dirty *
* Build: 2019-06-01 *
***************************************
** Warning: bad env CRC, using default,
use 'saveenv' to save it in FLASH
BOARD: ZSUN WiFi SD Card Reader
SOC: AR9330 rev. 1
CPU: MIPS 24Kc
RAM: 64 MB DDR2 16-bit CL3-4-4-10
FLASH: 16 MB Winbond W25Q128FW
MAC: 00:03:7F:11:56:48
CLOCKS: CPU/RAM/AHB/SPI/REF
400/400/200/ 25/ 25 MHz
Hit any key to stop booting: 0
Booting image from 0x9FEB0000...
## Error: unsupported image header
Booting image from 0x9FDE0000...
Image name: MIPS OpenWrt Linux-4.9.120
Build date: 2018-08-16 07:51:15 UTC
Architecture: MIPS
OS/image type: Linux Kernel
Compression: LZMA
Data size: 1.2 MB (1251113 bytes)
Load address: 0x80060000
Entry point: 0x80060000
Header CRC... OK!
Data CRC... skipped
Uncompressing Kernel... OK!
Starting kernel...
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
Please press Enter to activate this console.
BusyBox v1.28.3 () built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 18.06.1, r7258-5eb055306f
-----------------------------------------------------
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
root@OpenWrt:/#
New mtdparts: 64k(u-boot)ro,64k(u-boot-env)ro,14080k(rootfs),2048k(kernel),64k(nvram),64k(art),16128k@0x20000(firmware).
By rewriting boot command the u-boot will try to boot from 9FEB0000 and 9FDE0000, so both old and new firmware can work with.
u-boot download here, build based on commit 03f8ecc.
openwrt 18.06.1 download here, build based on commit 54de7cb.
3 Likes
I'm a nearly complete newb. How do i get this to work on my lede-flashed zsun?
This is my first device, my friend solders for me:
The TTL works but unlucky I lost wireless part working. So then I buy a new one and try it myself (bad quality, taken by my phone):
I think what should do is make the two rx solder joint connect:
After solder I use hook to access serial:
This is how I connect the hook:
I'm not EE and I dont know is there something wrong, especially the GND...But it works!
This is what I used to solder, it's cream at room temperature, and can be cured by hair dryer, it's more earier for me to use than solder stick.
@Kopfpalme You mean u-boot?
Thanks for showing this, very inspiring.
He definately means uboot, because you cant flash that size firmware unless you have a modified uboot, right? I guess he just wants the steps you do it...
download uboot
download firmware
flash uboot
flash firmware
live long and prosper, type thing.
do you need soldering skills to reap the benefits of your work or is it possible otherwise?
/J
@Kopfpalme I build a uboot-r/w version lede, you can use it and mtd command to flash the uboot.
- Download this lede and flash it in luci.
- Download new u-boot to /tmp as uboot.bin, cd to /tmp in ssh.
- Flash the uboot by command
mtd write uboot.bin u-boot - Flash Openwrt 18.06.1 in luci.
@JuggernauT To be honest I dont have soldering skills 
, that's why I use conductive paste. It's more like writing something by a pen.
I use two needles to make a tiny and thin conductive paste wire, put it between the two rx solder joint, then use hair dryer make it cured.
The most difficult part is, the two rx solder joint is too small, which will requires some craftsmanship. If you put conductive paste in wrong place or make it diffusion on board to connect to other element, you need clean it and try again.
And set the hook also need some practice, but acceptable.
1 Like
After flashing LuCI reports: LEDE Reboot 17.01-SNAPSHOT r4021-d92713d / LuCI lede-17.01 branch (git-19.055.62634-0cc62b4)
root@zsun0:/tmp# mtd write uboot.bin u-boot
Unlocking u-boot ...
Writing from uboot.bin to u-boot ...
root@zsun0:/tmp# █
Houston, we got a prompt again!
\o/
After flashing, LuCI reports: OpenWrt 18.06.1 r7258-5eb055306f / LuCI openwrt-18.06 branch (git-18.228.31946-f64b152)
\o/
$ ssh root@zsun0
root@zsun0's password:
BusyBox v1.28.3 () built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 18.06.1, r7258-5eb055306f
-----------------------------------------------------
root@zsun0:~# █
...and now the same for zsun1...
1 Like