iamromulan / quectel-rgmii-toolkit

Quectel module RGMII toolkit
Other
109 stars 49 forks source link

QuecManager minor issues #91

Open pipe2null opened 3 weeks ago

pipe2null commented 3 weeks ago

Minor UI issues:

Nice to have's:

Loving QuecManager so far, thanks!

dr-dolomite commented 3 weeks ago

image

ghost commented 3 weeks ago

@dr-dolomite - that new status screen does not require login? Nice. I think login should be required when viewing sensitive information or chaning modem properties.

pipe2null commented 3 weeks ago

Nice!

Thoughts for Cell Scanner / QSCAN UI's, not necessarily a feature request: One thing I have found extremely useful, that I have usually have to do straight AT console for, is getting specific tower IDs that can be used with Cellmapper.net, towermaps.com, and subsequently ispdesign.ui.com to get pretty accurate antenna alignment info. It is perhaps a bit niche, I am out at the edge of signal reception with both LPDA's and MIMO dish antennas, but determining the exact location of your tower(s) is good info to have regardless of where you are at.

dr-dolomite commented 3 weeks ago

@dr-dolomite - that new status screen does not require login? Nice. I think login should be required when viewing sensitive information or chaning modem properties.

Yup! Thats the preview screen if the user is not authenticated.

Nice!

Thoughts for Cell Scanner / QSCAN UI's, not necessarily a feature request: One thing I have found extremely useful, that I have usually have to do straight AT console for, is getting specific tower IDs that can be used with Cellmapper.net, towermaps.com, and subsequently ispdesign.ui.com to get pretty accurate antenna alignment info. It is perhaps a bit niche, I am out at the edge of signal reception with both LPDA's and MIMO dish antennas, but determining the exact location of your tower(s) is good info to have regardless of where you are at.

It was already implemented on the older SimpleAdmin 2.0 revision for x62 modems but since I transitioned QuecManager to use a different development approach, the Cell Scanner feature was delayed. However, it will for sure be included on the next release. About the tower id / TAC, etc., I will consider to add those.

ghost commented 3 weeks ago

@dr-dolomite - feature request :)

It would be nice if we can save custom AT commands in QuecManager, similar to LuCi.

dr-dolomite commented 3 weeks ago

@dr-dolomite - feature request :)

It would be nice if we can save custom AT commands in QuecManager, similar to LuCi.

Im still having 2nd thoughts about these features since it will constantly write on modem's flash but I will consider it.

ghost commented 3 weeks ago

@dr-dolomite - feature request :) It would be nice if we can save custom AT commands in QuecManager, similar to LuCi.

Im still having 2nd thoughts about these features since it will constantly write on modem's flash but I will consider it.

Commands will write to flash only for SET commands right? GET commands dont write to fflash?

dr-dolomite commented 3 weeks ago

@dr-dolomite - feature request :) It would be nice if we can save custom AT commands in QuecManager, similar to LuCi.

Im still having 2nd thoughts about these features since it will constantly write on modem's flash but I will consider it.

Commands will write to flash only for SET commands right? GET commands dont write to fflash?

We could save those in browser storage to avoid writing in flash. Ill try it.

iamromulan commented 3 weeks ago

@dr-dolomite From a default install take a look at /etc/config/atcommands.user That's where the luci app saves the custom commands. I have pre-packaged those commands. Could just share that file with the luci app

iamromulan commented 3 weeks ago

Here is how flash is setup

Here we see the MTD partitions of the modem. These are what are flashed to.

root@RM551EGL:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00400000 00040000 "sbl"
mtd1: 00280000 00040000 "mibib"
mtd2: 01600000 00040000 "efs2"
mtd3: 00280000 00040000 "rawdata"
mtd4: 00580000 00040000 "sys_rev"
mtd5: 00480000 00040000 "tz"
mtd6: 00180000 00040000 "tz_devcfg"
mtd7: 00180000 00040000 "cmnlib64"
mtd8: 00180000 00040000 "keymaster"
mtd9: 00180000 00040000 "ddr"
mtd10: 00180000 00040000 "apdp"
mtd11: 00180000 00040000 "xbl_config"
mtd12: 00200000 00040000 "xbl_ramdump"
mtd13: 00180000 00040000 "multi_oem"
mtd14: 00180000 00040000 "multi_qti"
mtd15: 00180000 00040000 "cdt"
mtd16: 00180000 00040000 "aop"
mtd17: 00180000 00040000 "aop_devcfg"
mtd18: 00200000 00040000 "qhee"
mtd19: 00180000 00040000 "abl"
mtd20: 004c0000 00040000 "uefi"
mtd21: 00180000 00040000 "loader_sti"
mtd22: 04700000 00040000 "boot"
mtd23: 06900000 00040000 "scrub"
mtd24: 07840000 00040000 "modem"
mtd25: 001c0000 00040000 "misc"
mtd26: 00180000 00040000 "devinfo"
mtd27: 04700000 00040000 "recovery"
mtd28: 001c0000 00040000 "fota"
mtd29: 03d00000 00040000 "recoveryfs"
mtd30: 00180000 00040000 "sec"
mtd31: 00180000 00040000 "ipa_fw"
mtd32: 00180000 00040000 "qupfw"
mtd33: 00180000 00040000 "shrm"
mtd34: 00180000 00040000 "cpucpfw"
mtd35: 00100000 00040000 "usb_qti"
mtd36: 20100000 00040000 "system"

Since this is a NAND flash with limited erase/write procedures UBIFS is utilized as the format as it helps prevent wear on the NAND storage.

Only 2 MTD partitions are utilized in the booted OpenWRT system

mtd36: 20100000 00040000 "system" which is attached to ubi0

and

mtd24: 07840000 00040000 "modem" which is attached to ubi1

Only one mount is from ubi1 (ubi1 volume 0 written as ubi1_0) at /firmware and we don't mess with it. I suspect its the radio's firmware files but I'm not sure.

The mount we write to is /dev/ubi0_1 I have setup an overlay mount where the root filesystem (/dev/ubi0_0) (/) is the lower and (/dev/ubi0_1) (/data/rootfs) is the upper

The lower and the upper are combined where I mount the overlay at. The lower is read only and the upper is where all write operations occur. Files in the upper take priority over the files in the lower, so if you edit, delete, or replace a file in the overlay that's not in the upper they are reflected in the overlay without touching the lower. I temporarily mount the overlay to /rootfs at boot but then use the pivit_root command to change the root mount / to it. The original rootfs mount gets moved to /real_rootfs and remains read only.

Check it out:

Filesystem                Size      Used Available Use% Mounted on
ubi0:rootfs             100.0M     53.8M     46.2M  54% /real_rootfs
/dev/ubi0_1             315.4M     34.9M    280.5M  11% /data
overlay                 315.4M     34.9M    280.5M  11% /

We can see the current health the the filesystem we write to like this

root@RM551EGL:~# ubinfo -d 0
ubi0
Volumes count:                           5
Logical eraseblock size:                 253952 bytes, 248.0 KiB
Total amount of logical eraseblocks:     2052 (521109504 bytes, 496.9 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes                 128
Count of bad physical eraseblocks:       0
Count of reserved physical eraseblocks:  80
Current maximum erase counter value:     3
Minimum input/output unit size:          4096 bytes
Character device major/minor:            491:0
Present volumes:                         0, 1, 2, 3, 4

I have put mtd36/ubi0 through a lot of abuse and as we can see there are 0 bad physical eraseblocks with 80 eraseblocks reserved for sacrifice

So it can pretty much loose 80 erase blocks before it breaks.

@dr-dolomite If you want to add storage health info to the stats ubinfo -d 0 can be used to check health status.

dr-dolomite commented 3 weeks ago

So far this is what Ive done. It all uses browser storage which it much simpler to implement also.

image

image