Jump to content

Espressobin support development efforts


lanefu

Recommended Posts

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

 

 

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@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"

Link to comment
Share on other sites

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)

 

Link to comment
Share on other sites

 

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?

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines