Espressobin support development efforts

[y52]

On 18/03/2018 at 12:58 PM, Tazz said:

GlobalScaleTechnologies .dtb is for their own provided kernel.

As you are using Armbian, use what is provided by Armbian.

The Armbian's dtb raises kernel panic on my board

setenv fdt_name_a boot/dtb/marvell/armada-3720-community.dtb

 

[  OK  ] Reached target Graphical Interface.
         Starting Update UTMP about System Runlevel Changes...
[  OK  ] Started Update UTMP about System Runlevel Changes.

Debian GNU/Linux 9 espressobin ttyMV0

espressobin login: [  108.552976] Unable to handle kernel paging request at virtual address 555555555555cd
[  108.560575] pgd = ffffffc07780e000
[  108.564546] [555555555555cd] *pgd=000000007697c003, *pud=000000007697c003, *pmd=0000000000000000
[  108.573474] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[  108.579140] Modules linked in: bridge stp llc xt_nat iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 ip6t_rt nf_defrag_ipv4 xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter iptable_filter ip6_tables ip_tables x_tables
[  108.602572] CPU: 1 PID: 7 Comm: rcu_preempt Not tainted 4.4.112-mvebu64 #8
[  108.609767] Hardware name: Marvell Armada 3720 Community Board (DT)
[  108.615981] task: ffffffc07807c500 ti: ffffffc0780b8000 task.ti: ffffffc0780b8000
[  108.623909] PC is at mv_udc_irq+0x730/0xc00
[  108.628135] LR is at mv_udc_irq+0x728/0xc00

....

[  115.737495] Process kworker/1:3 (pid: 554, stack limit = 0xffffffc0777c4020)
[  115.744526] Stack: (0xffffffc0777c7cd0 to 0xffffffc0777c8000)

...

[  115.961471] Call trace:
[  115.964001] [<ffffffc000095f9c>] check_and_switch_context+0x2c/0x450
[  115.970582] [<ffffffc0009e44cc>] __schedule+0x17c/0x5d8
[  115.975633] [<ffffffc0009e496c>] schedule+0x44/0xb8
[  115.981036] [<ffffffc0000cd5dc>] worker_thread+0x1ac/0x4d0
[  115.986626] [<ffffffc0000d3250>] kthread+0xf8/0x110
[  115.991669] [<ffffffc000085dd0>] ret_from_fork+0x10/0x40
[  115.997251] Code: a90363f7 a90153f3 2a0103f7 a9046bf9 (b9413382) 

 

The board is stable at 1000/800 u-boot with the GlobalScaleTechnologies's dtb

setenv fdt_name_a boot/dtb/marvell/armada-3720-community-v5.dtb

 

 

 

 

[Tazz]

yes, 4.4.112-mvebu64 is the BSP/global scale kernel. Armbian provided 4.4.112 kernel should be updated with latest dtb.

I only use latest/mainline Armbian kernel. BSP kernels are a dead end in my opinion.

 

For crypto: the armv8 crypto extension support is very good.

safexcel aka EIP support in the bsp (4.4) suck. We should wait mainline support (with added algo too). But the best perf with EIP will be obtained by in kernel users (ipsec, block encypt, future TLS app sockets). Cryptodev is not the panacea for userspace. It will mainly offload main CPUs for other tasks.

[y52]

19 minutes ago, Tazz said:

Armbian provided 4.4.112 kernel should be updated with latest dtb.

The " boot/dtb/marvell/armada-3720-community.dtb" came with the Armbian distribution.

root@espressobin:~# uname -a
Linux espressobin 4.4.112-mvebu64

 

It is discrepant if the dtb doesn't correspond to the Armbian's build and might be a source of instability.

 

[Tazz]

Things evolve and fix are made, even in the dts/dtb.

[y52]

2 hours ago, Tazz said:

Things evolve and fix are made, even in the dts/dtb.

Where could they be retrieved from?

 

22 hours ago, Tazz said:

EIP will be obtained by in kernel users (ipsec, block encypt

I also wait for the crypto support for the router's ipsec feature.

[Tazz]

BSP version is 4.4.52 armada-17.10.3 which is not very "secure" to use on a networked platform.

So Armbian developers updated the BSP with patches. Great piece of boring work. Big thanks to them.

https://github.com/armbian/build/tree/development/patch/kernel/mvebu64-default

Something broke and is disabled so work when using the BSP dtb.

Try with the latest Armbian version in the repo 4.4.121-mvebu64 or build the 4.4.122-mvebu64. The problem is perhaps fixed.

[y52]

I shall not be able building the 4.4.122-mvebu64 now, while the prebuilt image is a 4.4.112-mvebu64 only. It is worth updating it, so that it could be tested by a wider audience (like me).

If I manage setting up a production board with the docker's service, I shall probably setup a build infrastructure within it.

 

[Tazz]

apt-get update/upgrade or dpkg -i and you should be able to intal 4.4.121 no ?

[y52]

2 hours ago, Tazz said:

apt-get update/upgrade or dpkg -i and you should be able to intal 4.4.121 no ?

Nope. It doesn't change anything at all :

root@espressobin:~# uname -a
Linux espressobin 4.4.112-mvebu64 #8 SMP PREEMPT Wed Jan 24 22:53:43 CET 2018 aarch64 GNU/Linux

[tom_i]

Hi all,

so I've bought this SATA miniPCI card for to have 2 or more HDD (SSD) together, like some NAS or so.

Booting with SSD works just when I connect SSD to SATA connector on my EspressoBin. If I connect it to miniPCI card, it doesn't boot from u-boot.

So if I connect SSD to SATA connector on EspressoBin, it boots, but problem is when I connect HDD to the miniPCI slot.

Booting is ok till Armbian decided that /dev/sda1 is HDD and /dev/sdb1 is SSD which is wrong.

Is there any hack for u-boot to change booting option from that miniPCI card?

My actual ENV from u-boot:

Marvell>> printenv 
baudrate=115200
boot=interface scsi
boot_interface=scsi
bootargs=console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=/dev/sda1 rw rootwait
bootcmd=scsi scan; scsi dev 0; ext4load scsi 0:1 $kernel_addr $image_name;ext4load scsi 0:1 $initrd_addr $initrd_image; ext4load scsi 0:1 $fdt_addr $fdt_name_a;ext4load scsi 0:1 $fdt_addr $fdt_name_b;setenv bootargs $console root=$rootdev rw rootwait; booti $kernel_addr $initrd_addr $fdt_addr
bootdelay=2
console=console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000
eth1addr=00:51:82:11:22:01
eth2addr=00:51:82:11:22:02
eth3addr=00:51:82:11:22:03
ethact=neta@30000
ethaddr=F0:AD:XX:XX:XX:XX
ethprime=eth0
fdt_addr=0x4f00000
fdt_high=0xffffffffffffffff
fdt_name=boot/dtb/marvell/armada-3720-community.dtb
fdt_name_a=boot/dtb/marvell/armada-3720-community.dtb
fdt_name_b=boot/dtb/marvell/armada-3720-espressobin.dtb
fdtcontroladdr=7f7182d8
gatewayip=10.4.50.254
get_images=tftpboot $kernel_addr $image_name; tftpboot $fdt_addr $fdt_name; run get_ramfs
get_ramfs=if test "${ramfs_name}" != "-"; then setenv ramfs_addr 0x8000000; tftpboot $ramfs_addr $ramfs_name; else setenv ramfs_addr -;fi
hostname=marvell
image_name=boot/Image
initrd_addr=0x1100000
initrd_image=boot/uInitrd
initrd_size=0x2000000
ipaddr=0.0.0.0
kernel_addr=0x5000000
loadaddr=0x5000000
netdev=eth0
netmask=255.255.255.0
ramfs_addr=0x8000000
ramfs_name=-
root=root=/dev/sda1 rw
rootdev=/dev/sda1
rootfstype=ext4
rootpath=/srv/nfs/
serverip=0.0.0.0
set_bootargs=setenv bootargs $console $root ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none nfsroot=$serverip:$rootpath $extra_params
stderr=serial@12000
stdin=serial@12000
stdout=serial@12000
verbosity=1

Environment size: 1772/65532 bytes

 

[Igor]

47 minutes ago, tom_i said:

Booting is ok till Armbian decided that /dev/sda1 is HDD and /dev/sdb1 is SSD which is wrong.

It doesn't appear that you are using armbian boot environment. How-to is written on the download page: https://www.armbian.com/espressobin/ but in this case, it might not help.

 

If those SATA ports on addon are not recognized from u-boot, you can't boot from it anyway and you need to boot from some other media: SD, eMMC, USB,  SATA on Espressobin.

[umiddelb]

1 hour ago, tom_i said:

Booting is ok till Armbian decided that /dev/sda1 is HDD and /dev/sdb1 is SSD which is wrong.

You can hardwire the partition to boot the userland from by its UUID, e.g. root=UUID=cc255a80-136b-4c36-9bba-2dd32fa5d750 instead of root=/dev/sda1

You need to modify bootargs environment variable either by modifying it directly or by facilitating the Armbian way of booting and editing /boot/armbianEnv.txt

 

# sudo blkid

 

tells you which UUID  belongs to which partition.

[tom_i]

@Igor - I used to use SD card for running EspressoBin, but it was slow, so I decided to buy SSD and use HDD for "home" data. I've used "nand-sata-install" to copy data from SD card to SSD.

@umiddelb - "/boot/armbianEnv.txt" had that UUID saved, with it no boot if the normal HDD is connected. And then I've tried to setup "root=UUID=0f9d4af6-12cd-3e33-b234-3385f706f468", "saveenv" but that parameter isn't saved

There is still "root=root=/dev/sda1"

[tom_i]

Loading, please wait...
starting version 238
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems
done.
Begin: Will now check root file system ... fsck from util-linux 2.31.1
[/sbin/fsck.ext4 (1) -- /dev/sda1] fsck.ext4 -a -C0 /dev/sda1 
/dev/sda1: recovering journal
/dev/sda1: clean, 31481/61054976 files, 208644350/244190390 blocks
done.
[    8.717541] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
done.
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... mount: No such file or directory
mount: invalid option --
done.
mount: No such file or directory
run-init: opening console: No such file or directory
Target filesystem doesn't have requested /sbin/init.
run-init: opening console: No such file or directory
run-init: opening console: No such file or directory
run-init: opening console: No such file or directory
run-init: opening console: No such file or directory
run-init: opening console: No such file or directory
No init found. Try passing init= bootarg.
(initramfs)

 

[umiddelb]

You need to modify `rootdev´, not `root´. `set_bootargs´ is never called.

(The u-boot environment isn't in a good shape)

[tom_i]

 

6 hours ago, umiddelb said:

You need to modify `rootdev´, not `root´. `set_bootargs´ is never called.

(The u-boot environment isn't in a good shape)

Oh.. ok thank you, I'll try it today...

Anyway you meant my u-boot isn't in a good shape? Should I remove some stuff from there?

[umiddelb]

It's the stored u-boot environment. You might consider to load the Armbian defaults for the espressobin.

[tom_i]

Setup "rootdev" for using UUID doesn't help.

But I think, that u-boot is ok. It boots to armbian, but after Armbian checks disks it changes names. So HDD is /dev/sda1 and SSD is /dev/sdb1. 

[martinayotte]

9 minutes ago, tom_i said:

It boots to armbian, but after Armbian checks disks it changes names

Did you also check UUID in /etc/fstab ?

[tom_i]

Yes of course, there are right UUIDs

for SSD /

and for HDD which is currently commented.

 

Actual situation when both are connected:

(initramfs) blkid
/dev/sdb1: UUID="0f9d4af6-98bf-4e76-bf12-3f85f706f468" TYPE="ext4" PARTUUID="669c2e15-01"
/dev/sda1: UUID="5d577507-8c81-4be3-ba3d-5776baf857d1" TYPE="ext4" PARTUUID="aa448862-01"

From /etc/fstab:

root@espressobin:~# cat /etc/fstab 
# <file system>                                 <mount point>   <type>  <options>                                                       <dump>  <pass>
tmpfs                                           /tmp            tmpfs   defaults,nosuid                                                 0       0
/var/swap none swap sw 0 0
#UUID=05f654b5-c16f-49ed-86c1-6474b04e92da      /media/mmcboot  ext4    defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide    0       1
#/media/mmcboot/boot                            /boot           none    bind                                                            0       0
UUID=0f9d4af6-98bf-4e76-bf12-3f85f706f468       /               ext4    defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide    0       1
#UUID=5d577507-8c81-4be3-ba3d-5776baf857d1 /media/multimedia ext4 auto,rw,user 0 1

As you can see, that SSD is configured to mount to "/" but it doesn't :-/

 

armbianEnv.tct:

root@espressobin:~# cat /boot/armbianEnv.txt 
verbosity=1
emmc_fix=off
...
rootdev=UUID=0f9d4af6-98bf-4e76-bf12-3f85f706f468
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

 

[Igor]

If your u-boot doesn't load our boot.scr it's irrelevant what's inside armbianEnv.txt since it's not loaded.

[tom_i]

Ahaa, so I should use these:

setenv initrd_addr 0x1100000
setenv image_name boot/Image
setenv load_script 'if test -e mmc 0:1 boot/boot.scr; then echo \"... booting from SD\";setenv boot_interface mmc;else echo \"... booting from USB/SATA\";usb start;setenv boot_interface usb;fi;if test -e \$boot_interface 0:1 boot/boot.scr;then ext4load \$boot_interface 0:1 0x00800000 boot/boot.scr; source; fi'
setenv bootcmd 'run get_images; run set_bootargs; run load_script;booti \$kernel_addr \$ramfs_addr \$fdt_addr'

But configure it for using SSD.

So it should look like this:

setenv boot_interface scsi
setenv rootdev "/dev/sda1"
setenv root root=/dev/sda1 rw
setenv initrd_addr 0x1100000
setenv image_name boot/Image
setenv load_script 'if test -e mmc 0:1 boot/boot.scr; then echo \"... booting from SD\";setenv boot_interface mmc;else echo \"... booting from USB/SATA\";usb start;setenv boot_interface usb;fi;if test -e \$boot_interface 0:1 boot/boot.scr;then ext4load \$boot_interface 0:1 0x00800000 boot/boot.scr; source; fi'
setenv bootcmd 'run get_images; run set_bootargs; run load_script;booti \$kernel_addr \$ramfs_addr \$fdt_addr'

And what about this parameters?

setenv bootcmd 'scsi scan; scsi dev 0; ext4load scsi 0:1 $kernel_addr $image_name;ext4load scsi 0:1 $initrd_addr $initrd_image; ext4load scsi 0:1 $fdt_addr $fdt_name;setenv bootargs $console root=$rootdev rw rootwait; booti $kernel_addr $initrd_addr $fdt_addr'

Something should be there too right?

[umiddelb]

8 hours ago, tom_i said:

Setup "rootdev" for using UUID doesn't help.

But I think, that u-boot is ok. It boots to armbian, but after Armbian checks disks it changes names. So HDD is /dev/sda1 and SSD is /dev/sdb1. 

Choosing the root device partition by its UUID only works when you boot via an intermediate initrd. 

[y52]

Is there a solution powering down the board from the command line?
The result of "shutdown -h now" will only unmount the OS, but the hardware will stay under power.

[tom_i]

I think there is no possiblity like this, because it hasn't ATX power supply

Anyway, I'm shutting it down via

sudo halt

 and it unmount drives and turn off HDD, but when I'm listening it carefully HDD make some low noise. So maybe EspressoBin can't turn HDD completely off.

[tom_i]

My problem with no boot with SSD and HDD I've solved with renaming

rootdev

root

and

bootargs root

 with /dev/sdb1

Of course, I've updated U-Boot from Armbian

[y52]

15 hours ago, tom_i said:

I think there is no possiblity like this, because it hasn't ATX power supply

I run different other arm boards. BananaPI board, for example, executes power down and switches off the LEDs. It is not heating in a powered down state.

Espressobin leaves the LED turned on and the CPU continue heating.

[Tazz]

It seems that because how the led is wired, it could not be controlled by software (not a gpio capable pin).

For the rest, surely need more kernel support.

[y52]

On 01/04/2018 at 10:04 PM, Tazz said:

not a gpio capable pin

Does the board schematics wire the LED as gpio capable?

 

At the same time, is the board equipped with the thermal zone? I haven't yet discovered the means controlling the board components temperature, what worries me, as CPU may heat significantly even under average rated loads. 

[chrisf]

7 hours ago, y52 said:

Does the board schematics wire the LED as gpio capable?

 

At the same time, is the board equipped with the thermal zone? I haven't yet discovered the means controlling the board components temperature, what worries me, as CPU may heat significantly even under average rated loads. 

The green power LED is wired directly to the input power rail.

The schematic is available from http://wiki.espressobin.net/tiki-index.php?page=Schematics