PocketBeagle Arch Build

[summers]

Ok, aside from uboot, lets see if we can find a difference in our set up. Can you try:

fdisk -l:
$this->bbcode_second_pass_code('', 'sudo fdisk -l /dev/mmcblk0
[sudo] password for summers:
Disk /dev/mmcblk0: 29.83 GiB, 32010928128 bytes, 62521344 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x57f70b45

Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 2048 62521343 62519296 29.8G 83 Linux
')

tune2fs -l
$this->bbcode_second_pass_code('', 'sudo tune2fs -l /dev/mmcblk0p1
[sudo] password for summers:
tune2fs 1.45.6 (20-Mar-2020)
Filesystem volume name: <none>
Last mounted on: /
Filesystem UUID: be7e43d4-37bb-4c2e-93e0-7710c0901743
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 1954064
Block count: 7814912
Reserved block count: 390745
Free blocks: 4195750
Free inodes: 1359894
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Reserved GDT blocks: 1024
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8176
Inode blocks per group: 511
Flex block group size: 16
Filesystem created: Sat Mar 10 16:18:42 2018
Last mount time: Sat Jan 1 00:00:03 2000
Last write time: Sat Jan 1 00:00:03 2000
Mount count: 101
Maximum mount count: -1
Last checked: Sat Mar 10 16:18:42 2018
Check interval: 0 (<none>)
Lifetime writes: 251 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 40714e2c-8d3b-4adc-8eef-f02b2bb75072
Journal backup: inode blocks
')

ls -l /boot
$this->bbcode_second_pass_code('', 'ls -l /boot/{MLO,u-boot.img}
-rw-r--r-- 1 root root 78672 Mar 11 2018 /boot/MLO
-rw-r--r-- 1 root root 390536 Mar 11 2018 /boot/u-boot.img
')

Reason for looking at sizes, is I note that your 2020 uboot has quite a lot of functionality. We only have 1MB space before the first partition, and the offset of uboot is 384kB - so uboot can only at most be 600kB. Mine is only 390kB, so fits easilly - half wonder though if yours is too large.

Anyway post results here, and we can compare with what I go above, and see any differences ...

[TheJoker187]

Well this is what i've got :

fdisk -l:
$this->bbcode_second_pass_code('', 'pi@TheJoker187:~ $ sudo fdisk -l /dev/sda
Disk /dev/sda: 14.9 GiB, 15931539456 bytes, 31116288 sectors
Disk model: Mass-Storage
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x9ac91619

Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 31116287 31114240 14.9G 83 Linux
')

tune2fs -l
$this->bbcode_second_pass_code('', 'root@TheJoker187:/home/pi# tune2fs -l /dev/sda1
tune2fs 1.44.5 (15-Dec-2018)
Filesystem volume name: <none>
Last mounted on: /home/pi/mnt
Filesystem UUID: 4332b365-9c30-44e9-8ef2-1324d2035881
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags: unsigned_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 972944
Block count: 3889280
Reserved block count: 194464
Free blocks: 3801573
Free inodes: 972933
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Reserved GDT blocks: 1024
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8176
Inode blocks per group: 511
Flex block group size: 16
Filesystem created: Sat Oct 24 10:53:42 2020
Last mount time: Sat Oct 24 10:54:09 2020
Last write time: Sat Oct 24 10:54:09 2020
Mount count: 1
Maximum mount count: -1
Last checked: Sat Oct 24 10:53:42 2020
Check interval: 0 (<none>)
Lifetime writes: 68 MB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: fe30c155-a216-4c2e-99ff-4f2a03c1ab1f
Journal backup: inode blocks
Checksum type: crc32c
Checksum: 0xa675a60b
')

ls -l /boot

this one i was unable to try because i do not know where i should ls. Tried with sdcard mounted on my Pi at /mnt but if failed it say that is impossible to access the files i'm using root so do not know. I notice something strange, with the sdcard into the pocketbeagle if i type:
$this->bbcode_second_pass_code('', '
=> ext4ls mmc 0:1 /boot
fs_devread read outside partition 134217728
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
')

Why is reported as ext2 if i made ext4 ? Is it normal ?

[TheJoker187]

This is strange, i issued the command ls - l on the folder i saved the u-boot build output files (MLO and u-boot.img)
And this is what i found:
$this->bbcode_second_pass_code('', '
root@TheJoker187:/home/pi/u-boot# ls -l {MLO,u-boot.img}
-rw-r--r-- 1 pi pi 108256 Oct 20 18:34 MLO
-rw-r--r-- 1 pi pi 780588 Oct 20 18:32 u-boot.img
')

Are my files larger ? Is it normal ? those are the files i built if they are bigger shoul i specify the dimension when i use the dd commands:
$this->bbcode_second_pass_code('', '
dd if=mnt/boot/MLO of=/dev/sdX count=1 seek=1 conv=notrunc bs=128k
dd if=mnt/boot/u-boot.img of=/dev/sdX count=2 seek=1 conv=notrunc bs=384k
')

[summers]

OK - can see the problem now! u-boot.img is 780kB - and that means it overlays the ext4 file system, and so corrupts it!

When formatting the SD card try having the partition starting at 4096 rather than 2048 - that should give enough size.

Think the MLO is fine, IIRC that has a max size of 128kB - and you are inside that.

Anyway after lunch I'll package up my MLO and uboot, they are patched 2018 uboot - so not ideal, but had to be done at the time. So it would be good to move to 2020. Anyway if we can't get 2020 to work, my patched 2018 we have more evidence that it works.

And post lunch. If moving the start of the partition to 4096 doesn't work, you can get my patched 2018 uboot from https://davidjohnsummers.uk/PocketBeagleUboot.tar, its far smaller than 2020 - probably doesn't have the same functionality, but does have enough to boot. This works with the partition starting at 2048.

Oh yes - you asked about doing your own release of Arm Arch for Pocket Beagle. Guess I have mixed feelings on this. It isn't an officially supported Arm Arch board, but all that the Beagle Bone derivatives are *very* similar - and to my mind Arm Arch could support all with minimal hassle. uboot on these boards detects the board type and loads the right device tree. Probably all these boards could benefit from bring up serial and ethernet on the USB OTG port. All of this could be general, and this would be good.

However this isn't how Arm Arch works - think they had donated a Beagle Bone Black, which is why that is supported. So its a question of funding line, who would fund a generic Beagle Bone family, and who would do the work? This is the hard bit, I don't know the answer to these questions - but it would be what I favour, as it keeps the development in house.

Guess this is all tied up in how arm arch is supported. Its not really much more than a one man band, and a bunch of people that just get it working on their own devices. This isn't such a great model, but alas is how it works right now. I'm not sure I can see a way of changing it ...

Oh yes - also worth saying, when writing the 2020 uboot to the SD card, you'll need to change the count to make sure the whole thing gets transferred ... just make sure the whole file is written with the 384kB offset ... actually looking at it you uboot is just under 2 blocks of 384kB, so it will be fine. But actually what that says is that the original instruction in the beagle bone black install is wrong! As it has the possibility to overwrite the ext4 partition. Doah!

[TheJoker187]

$this->bbcode_second_pass_code('', '
Arch Linux 5.8.0-1-ARCH (ttyS0)

alarm login:
')

No more to add, IT WORKS ! just used 4096 as starting point AWESOME,

Now how can we proceed ? My uboot files are in the topic's posts and reading what we've done should help to have arch booted up, let me know what we should do and ... THANK YOU very much.

[summers]

[summers]

Oh yes, meant to check. Did you get usb gadget working on the USB OTG port?

It makes using the Pocket Beagle far easier - as just plugging it into a desk top, and the interfaces to access it come up.

[TheJoker187]

Hello Everyone, sorry if i reply so lately but I'm in quarantine because my doctor suspect i could be positive to Covid-19. In this time i prepared the github repo as we discussed, you can find it here: https://github.com/NitroProp/PocketBeagle-ARCH-ReARMed Thank a lot to summers for the precious help provided, and yes, i menaged to get the usb-otg functionality working but i need to update the github repo on that reguard. Hope the work done here will help even others.

[summers]

Looks good. Oh yes, in the README, I'd be tempted to say you did:
$this->bbcode_second_pass_code('', 'make distclean
make am335x_evm_defconfig
make')
To compile the uboot, as I don't think this is documented anywhere else, and its not commonly known.