TIM-1.0
mv_ddr-devel-g251bc63 DDR4 16b 2GB 2CS
WTMI-devel-18.12.1-1d97715
WTMI: system early-init
SVC REV: 5, CPU VDD voltage: 1.213V
Setting clocks: CPU 1200 MHz, DDR 750 MHz
CZ.NIC's Armada 3720 Secure Firmware 0b68a33-dirty (May 16 2022 17:51:06)
Running on ESPRESSObin
NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v2.6(release):a921da5e
NOTICE:  BL1: Built : 17:55:48, May 16 2022
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v2.6(release):a921da5e
NOTICE:  BL2: Built : 17:55:48, May 16 2022
NOTICE:  BL1: Booting BL31
NOTICE:  BL31: v2.6(release):a921da5e
NOTICE:  BL31: Built : 17:55:48, May 16 2022


U-Boot 2022.04-armbian (May 16 2022 - 17:50:52 +0000)

DRAM:  2 GiB
Core:  38 devices, 20 uclasses, devicetree: fit
WDT:   Not starting watchdog@8300
Comphy chip #0:
Comphy-0: USB3_HOST0    5 Gbps
Comphy-1: PEX0          5 Gbps
Comphy-2: SATA0         6 Gbps
SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
flags: ncq led only pmp fbss pio slum part sxs
PCIe: Link down
MMC:   sdhci@d0000: 0, sdhci@d8000: 1
Loading Environment from SPIFlash... SF: Detected mx25u3235f with page size 256 Bytes, erase size 4 KiB, total 4 MiB
OK
Model: Globalscale Marvell ESPRESSOBin Board
Net:   eth0: ethernet@30000
Hit any key to stop autoboot:  0

=> mmc list
sdhci@d0000: 0
sdhci@d8000: 1
=> mmc dev 0
MMC: no card present
=> mmc dev 1
switch to partitions #0, OK
mmc1(part 0) is current device
=> mmcinfo
Device: sdhci@d8000
Manufacturer ID: 15
OEM: 0
Name: 4FTE4R
Bus Speed: 52000000
Mode: MMC High Speed (52MHz)
Rd Block Len: 512
MMC version 5.1
High Capacity: Yes
Capacity: 3.6 GiB
Bus Width: 8-bit
Erase Group Size: 512 KiB
HC WP Group Size: 8 MiB
User Capacity: 3.6 GiB WRREL
Boot Capacity: 4 MiB ENH
RPMB Capacity: 512 KiB ENH
Boot area 0 is not write protected
Boot area 1 is not write protected

 

 

When I enter armbian, mmc cannot be detected........Several versions have the same problem, 22.11, 22.08, 22.05

 

root@espressobin:~# lsblk
NAME      MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda         8:0    1  28.7G  0 disk
└─sda1      8:1    1  28.4G  0 part /
mtdblock0  31:0    0   3.9M  0 disk
mtdblock1  31:1    0    64K  0 disk
zram0     254:0    0 993.7M  0 disk [SWAP]
zram1     254:1    0    50M  0 disk /var/log
zram2     254:2    0 993.7M  0 disk /tmp


root@espressobin:~# dmesg|grep -i mmc
[    1.393013] mmc0: SDHCI controller on d00d0000.sdhci [d00d0000.sdhci] using ADMA

 

Edited November 29, 20223 yr by armbianfans023

Can you tell me what FDT you're using?  If you aren't passing the right tree, it may be disabling the emmc.

 

Check by:

"cat /proc/device-tree/soc/internal-regs@d0000000/sdhci@d8000"

On 12/1/2022 at 2:40 AM, ManoftheSea said:

Can you tell me what FDT you're using?  If you aren't passing the right tree, it may be disabling the emmc.

 

Check by:

"cat /proc/device-tree/soc/internal-regs@d0000000/sdhci@d8000"

 

root@espressobin:~# cat /proc/device-tree/soc/internal-regs@d0000000/sdhci@d8000
cat: /proc/device-tree/soc/internal-regs@d0000000/sdhci@d8000: Is a directory


root@espressobin:~# cd /proc/device-tree/soc/internal-regs@d0000000/sdhci@d8000
root@espressobin:/proc/device-tree/soc/internal-regs@d0000000/sdhci@d8000# ls
'#address-cells'   interrupts                mmc-ddr-1_8v     pinctrl-names
 bus-width         marvell,pad-type          mmc-hs400-1_8v   reg
 clock-names       marvell,xenon-emmc        name            '#size-cells'
 clocks            marvell,xenon-tun-count   non-removable    status
 compatible        mmccard@0                 pinctrl-0

 

Edited December 2, 20223 yr by armbianfans023

root@espressobin:~# cat /boot/armbianEnv.txt
board_version=v7
verbosity=1
rootdev=UUID=ea6c33de-9fb0-4d48-afc8-639a9682ec9a
rootfstype=ext4
fdtfile=marvell/armada-3720-espressobin-v7-emmc.dtb

 

Sorry, I provided the directory, yes.  Cat the "status" file within it - that should not say "disabled".  If it is, your FDT is wrong.  If it's enabled... hmm, I'll have to think more about that one.

 

Do you have the dtb file available to u-boot?  In /dtb/ or /boot/dtb?

39 minutes ago, ManoftheSea said:

Sorry, I provided the directory, yes.  Cat the "status" file within it - that should not say "disabled".  If it is, your FDT is wrong.  If it's enabled... hmm, I'll have to think more about that one.

 

Do you have the dtb file available to u-boot?  In /dtb/ or /boot/dtb?

 

 

Yes, it's in there，thanks

 

root@espressobin:/boot/dtb/marvell# ls
armada-3720-db.dtb		     armada-8040-mcbin-singleshot.dtb
armada-3720-espressobin.dtb	     armada-8040-puzzle-m801.dtb
armada-3720-espressobin-emmc.dtb     armada-8080-db.dtb
armada-3720-espressobin-ultra.dtb    cn9130-crb-A.dtb
armada-3720-espressobin-v7.dtb	     cn9130-crb-B.dtb
armada-3720-espressobin-v7-emmc.dtb  cn9130-db-B.dtb
armada-3720-turris-mox.dtb	     cn9130-db.dtb
armada-3720-uDPU.dtb		     cn9131-db-B.dtb
armada-7040-db.dtb		     cn9131-db.dtb
armada-8040-clearfog-gt-8k.dtb	     cn9132-db-B.dtb
armada-8040-db.dtb		     cn9132-db.dtb
armada-8040-mcbin.dtb

 

"cat /proc/device-tree/soc/internal-regs@d0000000/sdhci@d8000/status"

 

This is "okay"?  If it is okay, then it seems like there's some issue with the linux driver, for which I don't have an answer.  If it is not okay, then we need to fix that, which I suspect is a problem of passing the device-tree.

This can be executed, but there is no information output..Only one ‘disabled’ output

root@espressobin:~# cat /proc/device-tree/soc/internal-regs@d0000000/sdhci@d8000/status
disabled

root@espressobin:~#

Edited December 3, 20223 yr by armbianfans023

hi~ManoftheSea：

 

here's another problem.When I full-upgrade, the network does not start automatically, I need to execute:

root@espressobin:~# ifconfig eth0 up
root@espressobin:~# dhclient wan
/etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf
root@espressobin:~#

After execution, I can get the LAN IP, but I can't resolve the domain name, and then I add dns to /etc/resolv.conf to resolve the domain name normally

When I restart, I need to repeat the operation again, how can I get it up and running automatically?

 

Alright, that's actually promising, because that is something I might know how to help with.  Like I said, you're getting the wrong device tree.  So now, the question is *why*. 

 

And the answer is because the espressobin uses FIT images now.  Ones that only include the v5 and v7 configurations.  This is my fault, and I can fix it.  But if you'd like to follow along, there's a script that runs when a kernel is installed that uses an .its file to create the FIT image.  We would need to add the "v5-emmc" and "v7-emmc" configurations to it.  Alternately, we can switch the ebin back to using the boot script, or go into using UEFI booting (my preference) which will allow u-boot to decide the correct DTB.

 

https://github.com/armbian/build/pull/4521

 

Network problem is known.  Run "systemctl unmask systemd-networkd; systemctl start systemd-networkd"

Probably understood~ Thank you for all your help and replies, look forward to the new version to solve these problems, thank you again ~~

hi ManoftheSea~🥺

Edited December 8, 20223 yr by ABF023

hi ManoftheSea~

Except add the "v5 emmc" and "v7 emmc" configurations to it， How to use UEFI booting?

 

I would like to refer to your usage

Thank you.

Edited December 8, 20223 yr by ABF023

@ABF023It's not supported by armbian (yet?) but: If you put a UEFI application on an ESP on a GPT-partitioned disk in the right location, u-boot will boot it.  And I think u-boot (2023.01-rc4, at least) will pass an internally saved DTB to the UEFI app. 

 

So you need to partition your disk as GPT, add a vfat filesystem with UEFI parttype (EF00 in gdisk), and put either the kernel or systemd-boot at EFI\BOOT\BOOTAA64.EFI (which systemd-boot will handle).  This is possible in latest Ubuntu and Debian Unstable.