Espressobin support development efforts

[arm-push]

@ebin-dev

I think it was my fault. I saved the environment variables and boot, now it is working.  This time it runs with flash-image-1000_800.bin

I'll let it run and see how it goes.

One more thing, I noticed this error while the system was being started,

** File not found boot/dtb/marvell/armada-3720-espressobin.dtb **

 

Thanks.

[ebin-dev]

10 hours ago, arm-push said:

One more thing, I noticed this error while the system was being started,

** File not found boot/dtb/marvell/armada-3720-espressobin.dtb **

 

If your environment variables are set correctly this error should not appear - the system is not even supposed to start without the dtb.

I checked all flash images for the 1GB Espressobin again and all of them are working well. I also use the current Armbian image 4.4.89 ...

My SBC is stable while running with 1200 MHz (https://pastebin.com/7qnJyQEF)

 

Btw - if you select another CPU frequency than 1000MHz you should adapt /etc/default/cpufrequtils to values displayed by 'cpufreq-info' and reboot

[arm-push]

15 minutes ago, ebin-dev said:

 

If your environment variables are set correctly this error should not appear - the system is not even supposed to start without the dtb.

I checked all flash images for the 1GB Espressobin again and all of them are working well. I also use the current Armbian image 4.4.89 ...

My SBC is stable while running with 1200 MHz (https://pastebin.com/7qnJyQEF)

 

Btw - if you select another CPU frequency than 1000MHz you should adapt /etc/default/cpufrequtils to values displayed by 'cpufreq-info' and reboot

 

Please see my output. it has outputs for flashing, setting envs and boot.

https://pastebin.com/vgFYBKHN

[ebin-dev]

10 hours ago, arm-push said:

Please see my output. it has outputs for flashing, setting envs and boot.

 

OK - so the latest flash-images-17.10 also work on your 1GB EspressoBin and the latest Armbian image 4.4.89 boots.

 

You can ignore the "File not found" message in your log file: A few days ago the boot script was changed to cover dtb's for the EspressoBin with two alternative names. Since only one of the two names exists in the file system you get an error for the other one. If you don't like that you can use the earlier environment settings and the error will disappear from your log file:

setenv boot_interface mmc
setenv image_name boot/Image
setenv fdt_name boot/dtb/marvell/armada-3720-community.dtb
setenv fdt_high "0xffffffffffffffff"
setenv rootdev "/dev/mmcblk0p1"
setenv rootfstype "ext4"
setenv verbosity "1"
setenv initrd_addr "0x1100000"
setenv initrd_image "boot/uInitrd"
setenv bootcmd 'mmc dev 0; ext4load mmc 0:1 $kernel_addr $image_name;ext4load mmc 0:1 $initrd_addr $initrd_image; ext4load mmc 0:1 $fdt_addr $fdt_name;setenv bootargs $console root=$rootdev rw rootwait; booti $kernel_addr $initrd_addr $fdt_addr'

 

[arm-push]

2 hours ago, ebin-dev said:

 

OK - so the latest flash-images-17.10 also work on your 1GB EspressoBin and the latest Armbian image 4.4.89 boots.

 

You can ignore the "File not found" message in your log file: A few days ago the boot script was changed to cover dtb's for the EspressoBin with two alternative names. Since only one of the two names exists in the file system you get an error for the other one. If you don't like that you can use the earlier environment settings and the error will disappear from your log file:

setenv boot_interface mmc
setenv image_name boot/Image
setenv fdt_name boot/dtb/marvell/armada-3720-community.dtb
setenv fdt_high "0xffffffffffffffff"
setenv rootdev "/dev/mmcblk0p1"
setenv rootfstype "ext4"
setenv verbosity "1"
setenv initrd_addr "0x1100000"
setenv initrd_image "boot/uInitrd"
setenv bootcmd 'mmc dev 0; ext4load mmc 0:1 $kernel_addr $image_name;ext4load mmc 0:1 $initrd_addr $initrd_image; ext4load mmc 0:1 $fdt_addr $fdt_name;setenv bootargs $console root=$rootdev rw rootwait; booti $kernel_addr $initrd_addr $fdt_addr'

 

 

Yes. they work. However I noticed that cpu frequency is not changed with the load. armbianmonitor -m seems to be showing incorrect values. Therefore I directly cat the sysfiles. 

See the output here,

https://pastebin.com/iANmRthJ

[ebin-dev]

23 minutes ago, arm-push said:

Yes. they work. However I noticed that cpu frequency is not changed with the load.

 

If you select a flash-image with another CPU frequency than 1000MHz you must adapt min/max values in /etc/default/cpufrequtils to available values displayed by 'cpufreq-info' and reboot (otherwise cpufreq will not work).

Then you can use 'cpufreq-info' and you will see that the ondemand governor it is in fact working as expected.

 

Armbianmonitor, armbian-config and kernel config need some finishing touches.

[arm-push]

33 minutes ago, ebin-dev said:

 

If you select a flash-image with another CPU frequency than 1000MHz you must adapt min/max values in /etc/default/cpufrequtils to available values displayed by 'cpufreq-info' and reboot (otherwise cpufreq will not work).

Then you can use 'cpufreq-info' and you will see that the ondemand governor it is in fact working as expected.

 

Armbianmonitor, armbian-config and kernel config need some finishing touches.

 

@ebin-dev

Thanks. I can see the transitions. It's interesting that 600000 has been utilized less 

 

root@espressobin:/sys/devices/system/cpu/cpu0/cpufreq/stats# cat trans_table 
   From  :    To
         :    200000    300000    600000   1200000 
   200000:         0       306         3       290 
   300000:       353         0         0       162 
   600000:         5         1         0         1 
  1200000:       242       208         4         0 

 

[ebin-dev]

27 minutes ago, arm-push said:

Thanks. I can see the transitions. It's interesting that 600000 has been utilized less 

 

Fine. Your EspressoBin also operates with 1200 MHz.

But you should change the min value in /etc/default/cpufrequtils from 200000 to 300000 - you do not save any energy by using 200000 as the min value and 600000 will be used more frequently.

The fact that the intermediate frequency of 600000 is currently not used that much demonstrates that cpufreq ramps up quickly.

You can change the scaling behaviour - but that is beyond the scope of this thread.

 

Thank you for testing.

 

If you are happy with Armbian please consider a donation.

[easter]

Hi,

 

as you can see in the attachment, my espressobin was running without a crash for a one night. I was using the 600 Mhz file and edited the cpufrequtils accordingly.

Do you think the 800mhz file is worth a try ?

[ebin-dev]

2 hours ago, easter said:

Hi,

 

as you can see in the attachment, my espressobin was running without a crash for a one night. I was using the 600 Mhz file and edited the cpufrequtils accordingly.

Do you think the 800mhz file is worth a try ?

 

You are the first one to confirm that a flash-image for the EspressoBin-2GB works (u-boot 17.10, atf/a3700-utils 17.08 with a modified DDR_TOPOLOGY) !

 

Can you confirm that you can address 2GB of memory now ? EDIT: I can see it in your screen shot .

 

Please try the other flash images with your 2GB EspressoBin - 800_800 will work just as fine as your first flash image - with 2GB of available memory. Your CPU will probably produce kernel panics again if you use 1000_800 or 1200_750 - but those images should work for other 2GB EspressoBins.

 

Edit: There is a new Armbian image 4.4.89 available - please use that one.

[easter]

2 hours ago, ebin-dev said:

 

Please try the other flash images with your 2GB EspressoBin - 800_800 will work just as fine as your first flash image

 

I tested the 800_800 image together with the armbian 4.4.89 image.

I can confirm, that it boots. i was able to run the pts/crafty test again. It went down from about 1100seconds with the 600_600 image to 784seconds.

[ebin-dev]

5 hours ago, easter said:

I tested the 800_800 image together with the armbian 4.4.89 image.

I can confirm, that it boots. i was able to run the pts/crafty test again.

 

Thank you for testing. The working images for the EspressoBin-2GB are now included in the flash-images package.

 

It would be very helpful if someone out there could test the EspressoBin-512MB flash-images. 

 

At this stage some finishing touches to armbianmonitor, armbian-config and the kernel configuration would be necessary to finalise the WIP.

Hopefully experienced Armbian developers will join now in order to finish the image for the EspressoBin.

[Igor]

48 minutes ago, ebin-dev said:

would be necessary to finalise the WIP.

It's not "just" kernel. We need to go deeper and also provide simple u-boot and ATF update. Currently, it's non-existing and we rely on a stock which is somewhere between alfa and beta. AFAIK certain problems are already solved upstream, but you need to update the board. I haven't got that far yet ... idea was to conduct those tests on SD card, but it's not possible to boot from while it's possible from SATA. Recompiling ATF, U-BOOT, leaving SPI alone and trying to boot from SATA with most recent ATF/U-boot might be a good next step.

[ebin-dev]

26 minutes ago, Igor said:

you need to update the board.

 

You can safely use one of the flash images to update your board to the very latest version now (u-boot 17.10.1, atf1.3-17.10 for the 512MB and 1GB version released a week ago, atf1.3-17.08 for the 2GB version) (flash-instructions are included) (nobody bricked a device with them)

 

The sources are available on Github and the build process is not complicated - you have explained it earlier in this forum. Official support for the 2GB EspressoBin is also expected soon.

 

May be I do not understand you correctly - but any further tests using a bootloader on SATA drives to confirm that the images are working do not seem to be necessary.

 

Once you have updated your board any new u-boot can be chainloaded using tftp to test its functionality - the process works (but not with the preinstalled u-boot / atf 17.02). 

 

Nevertheless, I will see what needs to be done to boot directly from SATA leaving SPI alone.

[Igor]

I updated u-boot and now even mPCI works, but not the most interesting one Atheros AC WiFi. I tried few others and updated compatibility list on the download page: https://www.armbian.com/espressobin/ There are also quick instructions with links to u-boot download that one can update his Espresso. It's a progress.

Do we have/know where are temperature readings?

[ebin-dev]

1 hour ago, Igor said:

Do we have/know where are temperature readings?

 

A search in /sys leads to 

/sys/fs/cgroup/devices/system.slice/hddtemp.service
/sys/fs/cgroup/systemd/system.slice/hddtemp.service

but I could not find any temperature values in there. 

[Igor]

Just now, ebin-dev said:

/sys/fs/cgroup/devices/system.slice/hddtemp.service
/sys/fs/cgroup/systemd/system.slice/hddtemp.service

I mean SoC temp.

[ebin-dev]

19 hours ago, Igor said:

Recompiling ATF, U-BOOT, leaving SPI alone and trying to boot from SATA with most recent ATF/U-boot might be a good next step.

 

So - I have recompiled ATF/U-boot with BOOTDEV=SATA for all EspressoBins and all available CPU_DDR frequencies.

@Igor : I sent you a PM with a link to all the files and my build scripts for flash and sata images.

 

To boot from SATA leaving SPI alone the jumper settings need to be changed from up-down-down to down-down-up and the ATF/U-boot file needs to be placed in the image on LBA1 next to MBR using dd.

 

Thank you for updating the download page: https://www.armbian.com/espressobin/  !

[umiddelb]

I've tried both the 1000_800 and the 1200_750 firmware for the 2GB board today. The 1000_800 variant seems to use a different partitioning layout and didn't find the u-boot environment created by the stock firmware. The 1200_750 firmware instead uses the same offsets and booted without any hassle.

[ebin-dev]

3 hours ago, umiddelb said:

I've tried both the 1000_800 and the 1200_750 firmware for the 2GB board today. The 1000_800 variant seems to use a different partitioning layout and didn't find the u-boot environment created by the stock firmware. The 1200_750 firmware instead uses the same offsets and booted without any hassle.

 

Could you please try again the 1000_800 and press the reset button to restart ?

All images were build using a script  - they should be fine.

If the problem remains please post a logfile.

[arm-push]

On 10/1/2017 at 2:15 PM, Igor said:

Do we have/know where are temperature readings?

 

Don't we need CONFIG_HWMON enabled?

[Igor]

39 minutes ago, arm-push said:

Don't we need CONFIG_HWMON enabled?

No idea, but I enable all those sensors. https://github.com/armbian/build/commit/89b681fe61607bde7636d28a5bc843872ed62722

[arm-push]

11 minutes ago, Igor said:

No idea, but I enable all those sensors. https://github.com/armbian/build/commit/89b681fe61607bde7636d28a5bc843872ed62722

 

I'll test. Thanks.

[jm02]

On 9/25/2017 at 12:35 AM, ebin-dev said:

 

Please post a log file (console output) - and the MAC address and hardware version of your device. I will try to figure out the reason of those issues.

As a test I rebooted my EspressoBin 10 times in a row without any problems (output of armbianmonitor -m: http://sprunge.us/Kaac )

 

Edit: If your EspressoBin produces a kernel panic you need to flash u-boot with a lower CPU frequency (u-boot 17.10.1 flash images)

I flashed the different u-boot images as you suggested, and only the 800 one allows my unit to boot. I went by what you were saying and ordered another espressobin, and it works perfectly with the 1200 image. I'm sending the 800 one back as defective. Thanks a lot for the help. I probably wouldn't have realized it was a bad unit in time without going through this process.

[arm-push]

 

Quote

No idea, but I enable all those sensors. https://github.com/armbian/build/commit/89b681fe61607bde7636d28a5bc843872ed62722

 

No luck. May be thermal interface for this SOC is not supported yet.  

root@espressobin:~# cd /sys/class/thermal/
root@espressobin:/sys/class/thermal# ls -la
total 0
drwxr-xr-x  2 root root 0 Jan  1  1970 .
drwxr-xr-x 50 root root 0 Jan  1  1970 ..
root@espressobin:/sys/class/thermal# 


root@espressobin:/sys/devices/virtual/hwmon/hwmon0# ls -la
total 0
drwxr-xr-x 3 root root    0 Oct  6 04:30 .
drwxr-xr-x 3 root root    0 Oct  6 04:30 ..
-r--r--r-- 1 root root 4096 Oct  5 22:36 name
drwxr-xr-x 2 root root    0 Oct  5 22:36 power
lrwxrwxrwx 1 root root    0 Jan  1  1970 subsystem -> ../../../../class/hwmon
-r--r--r-- 1 root root 4096 Oct  5 22:36 temp1_input
-rw-r--r-- 1 root root 4096 Oct  5 22:36 temp1_max
-r--r--r-- 1 root root 4096 Oct  5 22:36 temp1_max_alarm
-rw-r--r-- 1 root root 4096 Jan  1  1970 uevent
root@espressobin:/sys/devices/virtual/hwmon/hwmon0# 

 

[umiddelb]

On 03/10/2017 at 8:25 PM, ebin-dev said:

 

Could you please try again the 1000_800 and press the reset button to restart ?

All images were build using a script  - they should be fine.

If the problem remains please post a logfile.

Due to a stuck board during kernel compilation I've switched back to the 1000_800 firmware (from September, 30th).

I can see both u_boot environments (each of 64k size):

- 1200_750 (and stock firmware) environment starts at offset 0x000000180000 (which I use as the beginning of /dev/mtd1)

- 1000_800 environment starts at offset 0x0000003F0000 (last 64 k block of spi32766.0)

 

 

[FoodGenius]

Is there a special reason for change of mac-address after upgrading the bootloader/firmware?

its now 00:51:82:xx:xx:xx instead of the old one f0:ad:4e:xx:xx:xx
also its the same mac address for all interfaces lan0/lan1/wan
how to fix this? the board really should have the mac address that is printed on the barcode-label
on top of the rj45 ports.

 

[ebin-dev]

17 hours ago, FoodGenius said:

its now 00:51:82:xx:xx:xx instead of the old one f0:ad:4e:xx:xx:xx
also its the same mac address for all interfaces lan0/lan1/wan
how to fix this?

Your EspressoBin uses bridged interfaces based on systemd-networkd. If no MAC address is specified in the config files (see /etc/systemd/network) then the bridge will get another (virtual) one.

 

What needs to be done is to edit  /etc/systemd/network/10-br0.netdev to include the real MAC address of your EspressoBin:

cat /etc/systemd/network/10-br0.netdev 

[NetDev]
Name=br0
Kind=bridge
MACAddress=f0:ad:4e:xx:xx:xx

 You may need to delete any existing MAC/IP assignement of your EspressoBin in your router (to avoid any "hiccups") and then reboot your EspressoBin.

 

@Igor Could this be automated during firstrun - read the real MAC address from the environment settings and insert it into /etc/systemd/network/10-br0.netdev ?

[tkaiser]

8 minutes ago, ebin-dev said:

Could this be automated during firstrun - read the real MAC address from the environment settings and insert it into /etc/systemd/network/10-br0.netdev ?

Sure. And if the Espressobins really come with a real MAC address we should also take care to preserve the address when updating u-boot and stuff when it's set in the flash by factory.

[ebin-dev]

5 hours ago, tkaiser said:

Sure. And if the Espressobins really come with a real MAC address we should also take care to preserve the address when updating u-boot and stuff when it's set in the flash by factory.

 

Some environment settings were posted earlier in this thread - they include the real MAC address of the devices (ethaddr= ...) preset by the manufacturer. 

If users are manually flashing their devices from 17.02 to currently 17.10 the environemt variables are lost and we should ask users to set at least their MAC address again before pressing the reset button:

Marvell>> setenv ethaddr=..:..:..:..:..:..
Marvell>> saveenv

(... until we find out how to flash SPI from linux)