SK-AM62B: Increasing the image after programming. Limited RAM for loading a RFS via Ethernet. U-boot seems to support about 174MB RFS image download via DHCP.

Part Number: SK-AM62B

Tool/software:

2 Questions:

1) using bdinfo from u-boot I can see the RAM space is 2 GB, the

=> bdinfo
boot_params = 0x0000000000000000
DRAM bank = 0x0000000000000000
-> start = 0x0000000080000000
-> size = 0x0000000080000000 2GB
flashstart = 0x0000000000000000
flashsize = 0x0000000000000000
flashoffset = 0x0000000000000000
baudrate = 115200 bps
relocaddr = 0x00000000ff616000
reloc off = 0x000000007ee16000
Build = 64-bit
current eth = ethernet@8000000port@1
ethaddr = 1c:63:49:22:50:97
IP addr = <NULL>
fdt_blob = 0x00000000fd5e7860
new_fdt = 0x00000000fd5e7860
fdt_size = 0x000000000000f520
Video = dss@30200000 inactive
multi_dtb_fit= 0x0000000000000000
lmb_dump_all:
memory.cnt = 0x1
memory[0] [0x80000000-0xffffffff], 0x80000000 bytes flags: 0 RSVD
reserved.cnt = 0x4
reserved[0] [0x9ca00000-0x9cafffff], 0x00100000 bytes flags: 0
reserved[1] [0x9cb00000-0x9e6fffff], 0x01c00000 bytes flags: 4
reserved[2] [0x9e780000-0x9fffffff], 0x01880000 bytes flags: 4
reserved[3] [0xfc5dc000-0xffffffff], 0x03a24000 bytes flags: 0
devicetree = separate
arch_number = 0x0000000000000000
TLB addr = 0x00000000ffff0000
irq_sp = 0x00000000fd5e6ff0
sp start = 0x00000000fd5e6ff0
Early malloc usage: 3c28 / 8000
=>

RAM LOAD ADDRESS

=> echo $loadaddr
0x82000000
=>

If we imply RAM available for image load starts at 0x8200 0000 and goes to 0x9ca0 0000 (begin of reserved space).

QUESTION 1) - This gives 448 MB for a tftp landing pad starting at ${loadaddr}. However I'm only able to get 174 MB images successfully onto the device.

(Perhaps there is a problem with the math util in u-boot... where I calculate the erase size for the file system partitions?)

blkcnt seems to overrun at greater than x5 700 blocks (512 bytes each) but this seems like an odd number. If I increase the size this incorrectly gets a block count of xB ???

This will truncate the flash space for the RFS needed (massively)

cmd_17=setexpr blkcnt ${filesize} + 0xfff && setexpr blkcnt ${blkcnt} / 200
cmd_18=echo "Block Count: -------"
cmd_19=echo " $blkcnt"

# u-boot will actually erase from 0x0 to x400 aligned blocks on this device.
# clean up needed space in both partitions
cmd_20=mmc erase 0x00000022 ${blkcnt}
cmd_21=mmc erase 0x003f8022 ${blkcnt}

QUESTION 2) - Sticking with something working for now - I have 174 MB image loaded. How do I increase it to the full space available so the file system can grow as it is used?

=> echo $loadaddr
0x82000000
=>
0x82000000
=> mmc part

Partition Map for MMC device 0 -- Partition Type: EFI

Part Start LBA End LBA Name
Attributes
Type GUID
Partition GUID
1 0x00000022 0x003f8021 "primary" ~ 2GB of flash space for primary partition
attrs: 0x0000000000000000
type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
guid: e7dbd504-c47a-493d-a1d4-aa34686b4b5b
2 0x003f8022 0x007f0021 "secondary" ~ 2GB of flash space for secondary partition (backup file system image)
attrs: 0x0000000000000000
type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
guid: 93e4c649-cb27-4c27-ab7f-eb65a9ec348c
=> ls mmc 0:1 /
<DIR> 4096 .
<DIR> 4096 ..
<DIR> 16384 lost+found
<DIR> 4096 bin
<DIR> 4096 boot
<DIR> 4096 dev
<DIR> 4096 etc
<DIR> 4096 home
<DIR> 4096 lib
<SYM> 19 linuxrc
<DIR> 4096 media
<DIR> 4096 mnt
<DIR> 4096 proc
<DIR> 4096 run
<DIR> 4096 sbin
<DIR> 4096 srv
<DIR> 4096 sys
<DIR> 4096 tmp
<DIR> 4096 usr
<DIR> 4096 var
=> ls mmc 0:2 /
<DIR> 4096 .
<DIR> 4096 ..
<DIR> 16384 lost+found
<DIR> 4096 bin
<DIR> 4096 boot
<DIR> 4096 dev
<DIR> 4096 etc
<DIR> 4096 home
<DIR> 4096 lib
<SYM> 19 linuxrc
<DIR> 4096 media
<DIR> 4096 mnt
<DIR> 4096 proc
<DIR> 4096 run
<DIR> 4096 sbin
<DIR> 4096 srv
<DIR> 4096 sys
<DIR> 4096 tmp
<DIR> 4096 usr
<DIR> 4096 var
=>

However in the booted system..

bootcmd=mmc dev 0 1;mmc read ${loadaddr} 0x3400 0x800; env import -t ${loadaddr} 0x800; run user_commands;

=>run bootcmd

Environment size: 11415/126972 bytes
=> run bootcmd
switch to partitions #1, OK
mmc0(part 1) is current device

MMC read: dev # 0, block # 13312, count 2048 ... 2048 blocks read: OK
Executing uEnv.txt.emmc command list
switch to partitions #0, OK
mmc0(part 0) is current device

Partition Map for MMC device 0 -- Partition Type: EFI

Part Start LBA End LBA Name
Attributes
Type GUID
Partition GUID
1 0x00000022 0x003f8021 "primary"
attrs: 0x0000000000000000
type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
guid: e7dbd504-c47a-493d-a1d4-aa34686b4b5b
2 0x003f8022 0x007f0021 "secondary"
attrs: 0x0000000000000000
type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
guid: 93e4c649-cb27-4c27-ab7f-eb65a9ec348c
<DIR> 4096 .
<DIR> 4096 ..
<DIR> 4096 EFI
<SYM> 37 Image
15442432 Image-6.1.80-rt26-ti-rt-g3c08dbfd7bfd
<DIR> 4096 dtb
<SYM> 40 fitImage
6599338 fitImage-6.1.80-rt26-ti-rt-g3c08dbfd7bfd
<DIR> 4096 .
<DIR> 4096 ..
<DIR> 4096 EFI
<SYM> 37 Image
15442432 Image-6.1.80-rt26-ti-rt-g3c08dbfd7bfd
<DIR> 4096 dtb
<SYM> 40 fitImage
6599338 fitImage-6.1.80-rt26-ti-rt-g3c08dbfd7bfd
Prepping to launch emmc image
bootargs=console=ttyS2,115200n8 root=PARTUUID=e7dbd504-c47a-493d-a1d4-aa34686b4b5b rw rootfstype=ext4 rootwait
## Error: "main_cpsw0_qsgmii_phyinit" not defined
15442432 bytes read in 101 ms (145.8 MiB/s)
59970 bytes read in 17 ms (3.4 MiB/s)
Working FDT set to 88000000
## Flattened Device Tree blob at 88000000
Booting using the fdt blob at 0x88000000
Working FDT set to 88000000
Loading Device Tree to 000000008feee000, end 000000008fffffff ... OK
Working FDT set to 8feee000

Starting kernel ...

[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]

<SNIP>

_____ _____ _ _
| _ |___ ___ ___ ___ | _ |___ ___ |_|___ ___| |_
| | _| .'| . | . | | __| _| . | | | -_| _| _|
|__|__|_| |__,|_ |___| |__| |_| |___|_| |___|___|_|
|___| |___|

Arago Project mni-irfu-evm -

Arago 2023.10 mni-irfu-evm -

mni-irfu-evm login: [ 9.443767] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 9.444571] am65-cpsw-nuss 8000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 11.235753] platform 2b300050.target-module: deferred probe pending

mni-irfu-evm login:
mni-irfu-evm login: root
[ 162.107736] audit: type=1006 audit(1651172419.619:2): pid=239 uid=0 old-auid=4294967295 auid=0 tty=(none) old-ses=4294967295 ses=1 res=1
[ 162.107808] audit: type=1300 audit(1651172419.619:2): arch=c00000b7 syscall=64 success=yes exit=1 a0=8 a1=ffffc6be4d38 a2=1 a3=0 items=0 ppid=1 pid
=239 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="(systemd)" exe="/lib/systemd/systemd" key=(null)
[ 162.107847] audit: type=1327 audit(1651172419.619:2): proctitle="(systemd)"
root@mni-irfu-evm:~#
root@mni-irfu-evm:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 138.5M 135.2M 0 100% /
devtmpfs 901.9M 0 901.9M 0% /dev
tmpfs 966.8M 0 966.8M 0% /dev/shm
tmpfs 386.7M 8.7M 378.0M 2% /run
tmpfs 4.0M 0 4.0M 0% /sys/fs/cgroup
tmpfs 966.8M 0 966.8M 0% /tmp
tmpfs 16.0M 0 16.0M 0% /media/ram
tmpfs 50.0M 8.0K 50.0M 0% /var/volatile
tmpfs 193.4M 0 193.4M 0% /run/user/0
root@mni-irfu-evm:~#

Above you can see the RFS image copied shows it as 'full' at 135.5M available, yet the GPT table from u-boot shows it as being sized for 2 GB.

I'm not quite sure how to 'resize' this with the GPT partion size as the goal? Any poiters appreciated.

NOTE: fdisk was not available, but I'm now working on installing the gptfdisk layers etc..

root@mni-irfu-evm:~# ls -l /dev/mmc*
brw-rw---- 1 root disk 179, 0 Apr 28 18:57 /dev/mmcblk0
brw-rw---- 1 root disk 179, 32 Apr 28 18:57 /dev/mmcblk0boot0
brw-rw---- 1 root disk 179, 64 Apr 28 18:57 /dev/mmcblk0boot1
brw-rw---- 1 root disk 179, 1 Apr 28 18:57 /dev/mmcblk0p1 <-- My Primary partion
brw-rw---- 1 root disk 179, 2 Apr 28 18:57 /dev/mmcblk0p2 " Secondary "
crw------- 1 root root 240, 0 Apr 28 18:57 /dev/mmcblk0rpmb
root@mni-irfu-evm:~#

over 1 year ago

0 RG over 1 year ago

Intellectual 480 points

I've added the fdisk utility to my build now. And noticed that the df -h shows /dev/root as the physical mount point.

Reading up on this indicates that the /dev/root may be used early in boot for ram disks.

Thus, I'm a bit confused given I flashed to /dev/mmcblk0p1 above.

Any input appreciated. Thanks.

NOTE: FDISK shows:

root@mni-irfu-evm:~# fdisk /dev/mmcblk0p1
Device contains neither a valid DOS partition table, nor Sun, SGI, OSF or GPT disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that the previous content
won't be recoverable.

The number of cylinders for this disk is set to 65024.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p
Disk /dev/mmcblk0p1: 2032 MB, 2130706432 bytes, 4161536 sectors
65024 cylinders, 4 heads, 16 sectors/track
Units: sectors of 1 * 512 = 512 bytes

0 RG over 1 year ago in reply to RG

Intellectual 480 points

I've added the fdisk utility to my build now. And noticed that the df -h shows /dev/root as the physical mount point.

Reading up on this indicates that the /dev/root may be used early in boot for ram disks.

Thus, I'm a bit confused given I flashed to /dev/mmcblk0p1 above.

Any input appreciated. Thanks.

NOTE: FDISK shows:

root@mni-irfu-evm:~# fdisk /dev/mmcblk0p1
Device contains neither a valid DOS partition table, nor Sun, SGI, OSF or GPT disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that the previous content
won't be recoverable.

Command (m for help): p
Disk /dev/mmcblk0p1: 2032 MB, 2130706432 bytes, 4161536 sectors
65024 cylinders, 4 heads, 16 sectors/track
Units: sectors of 1 * 512 = 512 bytes

OK, so FDISK not GPT compatible, perhaps growpart will work, but I did not find a layer on open embedded with my quick search.

Thoughts?

(UPDATE tried to install parted/partprobe - only partprobe apears in my RFS updated, but need parted as well (not sure what is up with parted).)

Looking at other options ... gdisk - but needs to work with mounted partitions TBD...

0 RG over 1 year ago in reply to RG

Intellectual 480 points

OK, I see after reviewing U-boot code and documentation on various ways to increase RAM footprint. I tested moving the loadaddr around and noticed I could download 200MB images without issue. The failure does apear to be related to the block count math used to erase the landing pad for the RFS image.

Back to correcting the count calculation:

cmd_17=setexpr blkcnt ${filesize} + 0xfff && setexpr blkcnt ${blkcnt} / 200
cmd_18=echo "Block Count: -------"
cmd_19=echo " $blkcnt"

0 RG over 1 year ago in reply to RG

Intellectual 480 points

Downloads OK,

however even though: my file system will probably never need to be larger than the RAM footprint for TFTP download.

I don't want to leave flash on the table - and want to still expand my filesystem say 500MB into each half of an 8GB GPT partitioned flash chip.

So I want to still expand 500MB or less Flash RFS filesystem image to the full ~4GB space.

Note this fixed my crash at loading larger than 174MB images ( odd ?).

cmd_17=setexpr blkcnt ${filesize} + 0x3ff && setexpr blkcnt ${blkcnt} / 200
cmd_18=echo "File Size : -------"
cmd_19=echo " $filesize (h)"
cmd_20=echo "Block Count: -------"
cmd_21=echo " $blkcnt (h)"

Works with larger images. Flash erase block size is 0x400, thus 0x3FF needed for alignment.

Anyhoos: issue with parted not being added to the RFS by YOCTO. Probably not a TI issue...

in my tisdk-tiny-image.bbappend I've added this

IMAGE_INSTALL += "\

mni-diag-app \

memtester \

dropbear \

parted \

rfuapp \

And it seems this should bring it into the RFS, it does add it to /irfu/tisdk/build/arago-tmp-default-glibc/work/<custom_board_name>/tisdk-tiny-image/1.0-r0 (mni_master)

~/irfu/tisdk/build/arago-tmp-default-glibc/work/mni_irfu_evm-oe-linux/tisdk-tiny-image/1.0-r0 (mni_master)
$ find . -name parted
./rootfs/usr/sbin/parted
./recipe-sysroot-native/usr/include/parted
./recipe-sysroot-native/usr/sbin/parted

Yet the final image does not have it "./rootfs/usr/sbin/parted"

Ideas?

0 RG over 1 year ago in reply to RG

Intellectual 480 points

No luck with parted still - pulled that out as a separate question (for yocto dropping from the final RFS).

I did SCP it and supporting libraries to the target but discovered I COULD not use it because the root / is mounted on /dev/root?

I attempted to set the bootargs command :

=> setenv bootargs "console=ttyS2,115200n8 root=/dev/mmcblk0p1 rootfstype=ext4 rootwait"

However the next call in the script I believe is interfering with this.

=> bootcmd_ti_mmc

root@mni-irfu-evm:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 160.0M 135.2M 11.7M 92% /
devtmpfs 901.9M 0 901.9M 0% /dev
tmpfs 966.8M 0 966.8M 0% /dev/shm
tmpfs 386.7M 8.7M 378.0M 2% /run
tmpfs 4.0M 0 4.0M 0% /sys/fs/cgroup
tmpfs 966.8M 0 966.8M 0% /tmp
tmpfs 16.0M 0 16.0M 0% /media/ram
tmpfs 50.0M 8.0K 50.0M 0% /var/volatile
tmpfs 193.4M 0 193.4M 0% /run/user/0
root@mni-irfu-evm:~# cat /proc/con
config.gz consoles
root@mni-irfu-evm:~# cat /proc/cmdline
console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000 mtdparts=spi-nand0:512k(ospi.tiboot3),2m(ospi.tispl),4m(ospi.u-boot),256k(ospi.env
),256k(ospi.env.backup),98048k@32m(ospi.rootfs),256k@130816k(ospi.phypattern);omap2-nand.0:2m(NAND.tiboot3),2m(NAND.tispl),2m(NAND.tiboot3.ba
ckup),4m(NAND.u-boot),256k(NAND.u-boot-env),256k(NAND.u-boot-env.backup),-(NAND.file-system) root=PARTUUID=e7dbd504-c47a-493d-a1d4-aa34686b4b5b rw rootfstype=ext4 rootwait
root@mni-irfu-evm:~#
root@mni-irfu-evm:~#

Need to surf around on tie2e tomorrow and decode the bootcmd_ti_mmc.

0 RG over 1 year ago in reply to RG

Intellectual 480 points

FYI: cmdline seems right to set up root to the /dev/mmcblk0p1..

tmpfs 193.4M 0 193.4M 0% /run/user/0
root@mni-irfu-evm:~# cat /proc/cmdline
console=ttyS2,115200n8 root=/dev/mmcblk0p1 rootfstype=ext4 rootwait
root@mni-irfu-evm:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 160.0M 135.2M 11.7M 92% /
devtmpfs 901.9M 0 901.9M 0% /dev
tmpfs 966.8M 0 966.8M 0% /dev/shm
tmpfs 386.7M 8.7M 378.0M 2% /run
tmpfs 4.0M 0 4.0M 0% /sys/fs/cgroup
tmpfs 966.8M 0 966.8M 0% /tmp
tmpfs 16.0M 0 16.0M 0% /media/ram
tmpfs 50.0M 8.0K 50.0M 0% /var/volatile
tmpfs 193.4M 0 193.4M 0% /run/user/0
root@mni-irfu-evm:~#

I corrected the command line from using the uuid value (this required some manipulations of the . But when I reviewed the MOUNT command following this update and the df -h command I see the correct p1 partition.

uEnv.txt UPDATES:

cmdlineargs="console=ttyS2,115200n8 root=/dev/mmcblk0p1 rootfstype=ext4 rootwait"

setenv mni_cmd 1 (This forces the if statememnt to use $cmdlineargs - adjusting what args_mmc does)

setenv args_mmc "if test ${mni_cmd} -eq 1;then setenv bootargs $cmdlineargs; else run finduuid; setenv bootargs console=${console} ${optargs} root=PARTUUID=${uuid} rw rootfstype=${mmcrootfstype}; fi;"

bootcmd_ti_mmc (this command uses args_mmc which has been updated to use cmdlineargs per update above)

The above correction may not have been necessary - but it was a good exercise to see if I could correct it ==>

RESIZING the RFS IMAGE on the TARGET can be done thus:

BEFORE:

root@mni-irfu-evm:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 160.0M 151.1M 0 100% /

ACTIONS:

root@mni-irfu-evm:~# resize2fs /dev/mmcblk0p1

AFTER:

root@mni-irfu-evm:~# df -h /
Filesystem Size Used Available Use% Mounted on
/dev/root 3.4G 151.1M 3.1G 4% /

YEAH Ill say it again (resize2fs is a great command to expand RFS to fill out a partition):

/dev/root 3.4G 151.1M 3.1G 4% /

Processors

Processors forum

SK-AM62B: Increasing the image after programming. Limited RAM for loading a RFS via Ethernet. U-boot seems to support about 174MB RFS image download via DHCP.