TS-119 - 'bootcmd' for this model.

[j1o1a]

Could this script be used with the QNAP TS-119?

I get the following error:

~# ./qnap_mtd_resize.py --dry-run
[Check of the QNAP model and see if supported]
kirkwood-qnap: machine: QNAP TS219 family
DTB file: kirkwood-ts219-6281.dtb
Checking: flashcp -V
Checking: flash_erase --version
Using 'libubootenv-tool' package

[find on which MTD device partitions are currently mounted]
   spi0.0

[Dump current U-boot config']
Current U-boot bootcmd:
    cp.b 0xf8200000 0x800000 0x200000;cp.b 0xf8400000 0xa00000 0x900000;bootm 0x800000
Current U-boot bootargs:
    console=ttyS0,115200 root=/dev/ram initrd=0xa00000,0x900000 ramdisk=32768

[Prepare new 'bootcmd']
"'cp.l 0xf8200000 0x800000 0x0*80000' not found in 'cp.b 0xf8200000 0x800000 0x200000;cp.b 0xf8400000 0xa00000 0x900000;bootm 0x800000'"
Don't know how to patch 'bootcmd' for this model. Please report this log.

Any hints?

For reference:

~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00080000 00040000 "U-Boot"
mtd1: 00200000 00040000 "Kernel"
mtd2: 00900000 00040000 "RootFS1"
mtd3: 00300000 00040000 "RootFS2"
mtd4: 00040000 00040000 "U-Boot Config"
mtd5: 00140000 00040000 "NAS Config"

And:

~# fw_printenv -c fw_env.config
ASset=min
MALLOC_len=1
autoload=no
baudrate=115200
bootargs=console=ttyS0,115200 root=/dev/ram initrd=0xa00000,0x900000 ramdisk=32768
bootargs_end=:::DB88FXX81:eth0:none
bootargs_root=root=/dev/nfs rw
bootcmd=cp.b 0xf8200000 0x800000 0x200000;cp.b 0xf8400000 0xa00000 0x900000;bootm 0x800000
bootdelay=3
bootp_vendor_class=F_TS-119
console=console=ttyS0,115200 mtdparts=cfi_flash:0xf40000(root),0xc0000(uboot)ro
disL2Cache=no
disL2Prefetch=yes
disaMvPnp=no
enaAutoRecovery=yes
enaCpuStream=no
enaDCPref=yes
enaICPref=yes
enaMonExt=no
enaWrAllo=no
ethact=egiga0
ethaddr=00:08:XX:XX:XX:XX
ethprime=egiga0
fileaddr=A00000
filesize=36464c
image_name=uImage
ipaddr=172.17.20.240
loadaddr=0x02000000
loads_echo=0
mainlineLinux=no
mvNetConfig=mv_net_config=(00:11:88:0f:62:81,0:1:2:3),mtu=1500
mvPhoneConfig=mv_phone_config=dev0:fxs,dev1:fxo
netbsd_en=no
netmask=255.255.254.0
netretry=no
pexMode=RC
rcvrip=169.254.100.100
rootpath=/mnt/ARM_FS/
sata_dma_mode=yes
serverip=172.17.20.5
setL2CacheWT=yes
standalone=fsload 0x2000000 $(image_name);setenv bootargs $(console) root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) $(mvPhoneConfig); bootm 0x2000000;
stderr=serial
stdin=serial
stdout=serial
update=tftp 0x800000 uImage; tftp 0xa00000 rootfs.gz;bootm 0x800000
usb0Mode=host
vxworks_en=no
yuk_ethaddr=00:00:00:EE:51:81

[hartkopp]

I converted my TS-119P+ without errors. What is you current Debian version? Buster? Or Stretch?

[j1o1a]

Debian Stretch (11.1)

[hartkopp]

That's not consistent. Stretch is Debian 9 Bullseye is Debian 11

Did you already upgrade to Bullseye without upgrading the kernel? What kernel are you currently using? See with uname -a

[amouiche]

Hello,

Le 05/12/2021 à 06:03, j1o1a a écrit :

Could this script be used with the QNAP TS-119?

I get the following error:

|~# ./qnap_mtd_resize.py --dry-run [Check of the QNAP model and see if supported] kirkwood-qnap: machine: QNAP TS219 family DTB file: kirkwood-ts219-6281.dtb Checking: flashcp -V Checking: flash_erase --version Using 'libubootenv-tool' package [find on which MTD device partitions are currently mounted] spi0.0 [Dump current U-boot config'] Current U-boot bootcmd: cp.b 0xf8200000 0x800000 0x200000;cp.b 0xf8400000 0xa00000 0x900000;bootm 0x800000 Current U-boot bootargs: console=ttyS0,115200 root=/dev/ram initrd=0xa00000,0x900000 ramdisk=32768 [Prepare new 'bootcmd'] "'cp.l 0xf8200000 0x800000 0x0*80000' not found in 'cp.b 0xf8200000 0x800000 0x200000;cp.b 0xf8400000 0xa00000 0x900000;bootm 0x800000'" Don't know how to patch 'bootcmd' for this model. Please report this log. |

Any hints?

• Did you, by yourself, already modify the uboot env variables in the past ?
• may be you QNAP was an early version (or flash with a early uboot version) that use "cp.b" instead of "cp.l" to load kernel and initrd from memory. In this case, there is not so much differences, but we the script must be careful when it reach a "different" way of uboot configuration (and that's why it report this issue)

Please answer to those 2 questions and I will update the script.

Arnaud

For reference:

|~# cat /proc/mtd dev: size erasesize name mtd0: 00080000 00040000 "U-Boot" mtd1: 00200000 00040000 "Kernel" mtd2: 00900000 00040000 "RootFS1" mtd3: 00300000 00040000 "RootFS2" mtd4: 00040000 00040000 "U-Boot Config" mtd5: 00140000 00040000 "NAS Config" |

And:

|~# fw_printenv -c fw_env.config ASset=min MALLOC_len=1 autoload=no baudrate=115200 bootargs=console=ttyS0,115200 root=/dev/ram initrd=0xa00000,0x900000 ramdisk=32768 bootargs_end=:::DB88FXX81:eth0:none bootargs_root=root=/dev/nfs rw bootcmd=cp.b 0xf8200000 0x800000 0x200000;cp.b 0xf8400000 0xa00000 0x900000;bootm 0x800000 bootdelay=3 bootp_vendor_class=F_TS-119 console=console=ttyS0,115200 mtdparts=cfi_flash:0xf40000(root),0xc0000(uboot)ro disL2Cache=no disL2Prefetch=yes disaMvPnp=no enaAutoRecovery=yes enaCpuStream=no enaDCPref=yes enaICPref=yes enaMonExt=no enaWrAllo=no ethact=egiga0 ethaddr=00:08:XX:XX:XX:XX ethprime=egiga0 fileaddr=A00000 filesize=36464c image_name=uImage ipaddr=172.17.20.240 loadaddr=0x02000000 loads_echo=0 mainlineLinux=no mvNetConfig=mv_net_config=(00:11:88:0f:62:81,0:1:2:3),mtu=1500 mvPhoneConfig=mv_phone_config=dev0:fxs,dev1:fxo netbsd_en=no netmask=255.255.254.0 netretry=no pexMode=RC rcvrip=169.254.100.100 rootpath=/mnt/ARM_FS/ sata_dma_mode=yes serverip=172.17.20.5 setL2CacheWT=yes standalone=fsload 0x2000000 $(image_name);setenv bootargs $(console) root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) $(mvPhoneConfig); bootm 0x2000000; stderr=serial stdin=serial stdout=serial update=tftp 0x800000 uImage; tftp 0xa00000 rootfs.gz;bootm 0x800000 usb0Mode=host vxworks_en=no yuk_ethaddr=00:00:00:EE:51:81 |

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/amouiche/qnap_mtd_resize_for_bullseye/issues/12, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADXHI5GAYCNZ646B55GGG4LUPLXB5ANCNFSM5JMLOEXA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[j1o1a]

That's not consistent. Stretch is Debian 9 Bullseye is Debian 11

Your right, it is Debian 11 Bullseye.

Did you already upgrade to Bullseye without upgrading the kernel?

Yes I Idid.

What kernel are you currently using? See with uname -a

#~ uname -a
Linux blackbox 4.19.0-17-marvell #1 Debian 4.19.194-3 (2021-07-18) armv5tel GNU/Linux 

Did you, by yourself, already modify the uboot env variables in the past ?

No, I'm not that proficient in embedded systems. Although I remember making some change in order to keep de ethernet MAC address against some bug or something long time ago: lists.debian.org

may be you QNAP was an early version (or flash with a early uboot version) that use "cp.b" instead of "cp.l" to load kernel and initrd from memory. In this case, there is not so much differences, but we the script must be careful when it reach a "different" way of uboot configuration (and that's why it report this issue)

I understand. Judging by the message in the Debian-Arm Mailing List I linked it seems that some versions do use "cp.b" instead of "cp.l". The U-Boot version of my TS-119 seems to be:

#~ strings /dev/mtd0ro | grep -i "^U-Boot" | grep -i version:
U-Boot 1.1.4 (Apr 23 2009 - 19:01:28) Marvell version: 3.4.4

Saludos!

[amouiche]

Hello. This case in now managed by latest (22 dec) version

[killemov]

I understand. Judging by the message in the Debian-Arm Mailing List I linked it seems that some versions do use "cp.b" instead of "cp.l". The U-Boot version of my TS-119 seems to be:

AFAIK the cp.b, cp.w and cp.l mean copy byte, word(2 bytes) and long(4 bytes). So that would be a bad thing to mix up unknowingly. It also means the boot time could be sped up a fraction if memory was copied 4 bytes at a time instead of 1. (The size probably needs to be divided by 4 then, that's all.)