aprayoga
-
Posts
138 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Community Map
Posts posted by aprayoga
-
-
11 hours ago, uzair said:
Hi, I seem to have a problem with my batch 2 Helios4 that I'm unable to figure out why it happens.
every time I put it in standby mode, it does not stay in standby but restarts after approx. a minute.I've tested it with 2 different SD-cards, one with a clean install.
During the standby I also tested it with disconnecting the network cable, so it seems the it's an internal trigger or crash
which makes the Helios4 restart.I'm using the latest Armbian version: 5.77 and kernel 4.14.106.
One thing I've noticed is that the system time is always incorrect after the forced restart.
after a normal restart the time is correct. Could it be related? I don't know, I'm out of ideas
and it's driving me crazy for the last few days. Hope you guys can help.Could you do the following and connect the serial console
On 4/2/2019 at 2:13 AM, aprayoga said:Hi,
could you append extraargs=no_console_suspend ignore_loglevel to /boot/armbianEnv.txt and set loglevel to 8?
echo "extraargs=no_console_suspend ignore_loglevel" | sudo tee -a /boot/armbianEnv.txt sudo sed -i 's/exit 0/dmesg -n 8\nexit 0/g' /etc/rc.local
then reboot the system to apply the changes.
Those command would disable log filtering and print some debug info when the system entering suspend mode.
We need more info what event causing the system to wake up.
and how did you put the system to standby?
-
On 4/1/2019 at 9:04 PM, djurny said:
Hi,
Box #0 (4x WD Red 4TB):
- /dev/sda 30 WDC WD40EFRX-68N32N0 WD-WCC7K1KS6EUY
- /dev/sdb 32 WDC WD40EFRX-68N32N0 WD-WCC7K2KCR8J9
- /dev/sdc 31 WDC WD40EFRX-68N32N0 WD-WCC7K1RVY70H
-
/dev/sdd 31 WDC WD40EFRX-68N32N0 WD-WCC7K6FE2Y7D
Box #1 (4x WD Blue 2TB):
- /dev/sda 32 WDC WD20EZRZ-00Z5HB0 WD-WCC4M2VFJPP7
- /dev/sdb 31 WDC WD20EZRZ-00Z5HB0 WD-WCC4M0JNZ8EX
- /dev/sdc 31 WDC WD20EZRZ-00Z5HB0 WD-WCC4M6HPXZFZ
- /dev/sdd 29 WDC WD20EZRZ-00Z5HB0 WD-WCC4M6HPX4AP
No other devices connected to either box. The 2nd colum is HDD reported temperature in Celcius, it's always around 30~35.
I've sligthly modified fancontrol to link the top fan (-j10) to maintain the average HDD temperature around between 30~45 Celcius. Bottom fan (-j17) is linked to CPU temperature (/dev/thermal-cpu/temp1_input).
Groetjes,
Hi,
could you append extraargs=no_console_suspend ignore_loglevel to /boot/armbianEnv.txt and set loglevel to 8?
echo "extraargs=no_console_suspend ignore_loglevel" | sudo tee -a /boot/armbianEnv.txt sudo sed -i 's/exit 0/dmesg -n 8\nexit 0/g' /etc/rc.local
then reboot the system to apply the changes.
Those command would disable log filtering and print some debug info when the system entering suspend mode.
-
8 hours ago, tuxd3v said:
I realized that, for having the OS in a Hard drive...better it to be a 2.5", so less power consumption..
But that also means penalize one disk for the mdRaid..
Its not a easy answer in fact,
A Solution could be having a small harddrive 2.5", attached to USB, with the OS, and logs..
Or have it, like its already..., in a SDCard, with logs in a Zram..
Right now after, your response and also after thinking better at it sdcard seems a easier way to go.
But could be nice to have there a USB boot option, for a pendrive or a usb attached disk.
Well, you could boot from USB but first you need to set Helios4 to boot from SPI NOR flash. You can check how to do it on our wiki.
In the end of the page there is Moving RootFS to Other Device section to transfer your existing OS in SDCard to USB Storage.
Or if you want to start fresh, you could also write/burn the Armbian image directly to USB pendrive instead of SDCard.
-
On 2/5/2019 at 8:23 PM, tuxd3v said:
Doubts about OS in Disk array,
Could we put OS in hard drives?
Or should we put it in a spare one/usb pendrive or let it in sdcard
Regarding OS on hard drive, it's possible as long as it does not reside on top of RAID. U-Boot does not understand MD so it could not load boot files from there.
You need to sacrifice 1 drive to be used as OS drive or maybe, since i haven't tried it, allocated a partition for OS and let MD use the rest of the disk capacity.
That being said, currently we don't support OS on hard drive.
Personally I opt for OS in sdcard, because it does not poke out/extrude, easier to update the bootloader and i have plenty of them. I admit those are not strong reason.
Small dimension reason can easily dismissed by some USB pendrive model that quite small such as these SanDisk Ultra Fit.
Also there might be performance advantage using pendrive. SanDisk Ultra Fit stated that it has speed up to 130MB/s while SanDisk Extreme Pro *only* 100 MB/s.
I'm not sure how reliable the USB pendrive to run in 24/7. Early model of SanDisk Ultra Fit (right hand side on above photo), quite hot after a while.
The current model, which is fully plastic, does not have such issue.
-
On 1/18/2019 at 7:57 PM, djurny said:
Hi,
Eager to test out the new linux-4.14.94-mvebu kernel, but I'm having some boot issues with it; SDcard refuses to be detected by the kernel:
<snip> [ 1.657831] Key type encrypted registered [ 1.658709] USB-PWR: supplied by power_brick_12V [ 1.739202] mmc0: error -110 whilst initialising SD card [ 1.860846] ata1: SATA link down (SStatus 0 SControl 300) [ 1.861044] ata2: SATA link down (SStatus 0 SControl 300) <snip>
Hopefully it's just the SDcard itself being broken. (Although it's a 4 weeks old branded one.)
I'll give an update once I get my box going.
-[ update ]-
SDcard is fine. There is something NOK with the new image/headers/dtb. After hacking it back to 4.14.92-mvebu all was fine again.
I still want to test this, but I'm not sure what is causing the mmc driver from not detecting my SDcard? Do I need to update/install more than just image, headers and dtb packages?
-[ edit ]-
Also, do note that during 4.14.94-mvebu kernel boot, both modules mentioned before are still opting for SW methods instead of using the xor engines. It looks like mv_xor initialization/publishing is still done after the benchmark & selection is done by crypto/async_tx & raid6?
Thanks,
Groetjes,
I'm sorry, my bad, I accidentally include UHS-I SD card patch on that test kernel, the DTB to be exact, and apparently your card does not compatible. You can read more about this at SDIO (SD Card) page on our wiki. You just need to install the linux-image package. No need to install the dtb and headers.
Regarding XOR, yes i notice it too. I think it would default to software implementation first then override later by async_tx if the hardware offload engine is available.
You can see on kernel message below, the async_tx initialized quite late compared to xor and raid6.
[ 0.004600] xor: measuring software checksum speed [ 0.043885] arm4regs : 2533.000 MB/sec [ 0.083885] 8regs : 1947.000 MB/sec [ 0.123884] 32regs : 1804.000 MB/sec [ 0.163884] neon : 1840.000 MB/sec [ 0.163887] xor: using function: arm4regs (2533.000 MB/sec) <...> [ 0.240055] raid6: int32x1 gen() 262 MB/s [ 0.307944] raid6: int32x1 xor() 271 MB/s [ 0.376037] raid6: int32x2 gen() 351 MB/s [ 0.443939] raid6: int32x2 xor() 329 MB/s [ 0.512026] raid6: int32x4 gen() 393 MB/s [ 0.579947] raid6: int32x4 xor() 319 MB/s [ 0.647890] raid6: int32x8 gen() 422 MB/s [ 0.715956] raid6: int32x8 xor() 324 MB/s [ 0.783897] raid6: neonx1 gen() 1212 MB/s [ 0.851888] raid6: neonx1 xor() 1150 MB/s [ 0.919918] raid6: neonx2 gen() 1296 MB/s [ 0.987897] raid6: neonx2 xor() 1347 MB/s [ 1.055893] raid6: neonx4 gen() 1349 MB/s [ 1.123902] raid6: neonx4 xor() 1377 MB/s [ 1.191883] raid6: neonx8 gen() 1073 MB/s [ 1.259882] raid6: neonx8 xor() 1041 MB/s [ 1.259885] raid6: using algorithm neonx4 gen() 1349 MB/s [ 1.259888] raid6: .... xor() 1377 MB/s, rmw enabled [ 1.259891] raid6: using neon recovery algorithm <...> [ 1.425544] mv_xor f1060800.xor: Marvell shared XOR driver [ 1.457595] mv_xor f1060800.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr ) [ 1.457693] mv_xor f1060900.xor: Marvell shared XOR driver [ 1.485586] mv_xor f1060900.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr ) <...> [ 4.580251] async_tx: api initialized (async)
I built another test kernel with "DMA Engine verbose debugging" option enabled. These lines printed repeatedly (well, not exactly same address) during dd from /dev/zero to /dev/md0 and the interrupt counter increased.
[ 416.505470] mv_xor f1060800.xor: mv_xor_prep_dma_xor src_cnt: 1 len: 4096 dest 0x216eb000 flags: 32 [ 416.514571] mv_xor f1060800.xor: mv_xor_prep_dma_xor sw_desc ed89d780 async_tx ed89d79c [ 416.522719] mv_xor f1060800.xor: mv_xor_tx_submit sw_desc ed89d780: async_tx ed89d79c [ 416.530582] mv_xor f1060800.xor: mv_chan_start_new_chain 190: sw_desc ed89d780 [ 416.537865] mv_xor f1060800.xor: activate chan. [ 416.542544] mv_xor f1060800.xor: intr cause 2 [ 416.546915] mv_xor f1060800.xor: mv_chan_clear_eoc_cause, val 0xfffffff8 [ 416.553658] mv_xor f1060800.xor: mv_chan_slot_cleanup 280 [ 416.559076] mv_xor f1060800.xor: current_desc 7f056380 [ 416.564253] mv_xor f1060800.xor: mv_chan_clean_completed_slots 227 [ 416.570461] mv_xor f1060800.xor: mv_desc_clean_slot 247: desc ed89d780 flags 32 [ 416.577803] mv_xor f1060800.xor: mv_xor_prep_dma_xor src_cnt: 1 len: 4096 dest 0x2ceaf000 flags: 32 [ 416.586894] mv_xor f1060800.xor: mv_xor_prep_dma_xor sw_desc ed89da00 async_tx ed89da1c [ 416.595019] mv_xor f1060800.xor: mv_xor_tx_submit sw_desc ed89da00: async_tx ed89da1c [ 416.602890] mv_xor f1060800.xor: mv_chan_start_new_chain 190: sw_desc ed89da00 [ 416.610142] mv_xor f1060800.xor: activate chan.
---
16 hours ago, lanefu said:so i copied the boot.cmd from the helios4 armbian 5.67 image and then made the boot.scr from it and put it on the sd card... booted up cleanly.
the file size between the old boot.cmd and the failing one is significant... failing one is like half the sizehere's a diff
lane@gpiolite:~$ diff boot.cmd badboot.cmd
6d5
< setenv load_addr "0x300000"
11a11
> setenv spi_workaround "off"
17,20c17,19
< echo "Boot script loaded from ${devtype}"
<
< if load ${devtype} ${devnum} ${load_addr} ${prefix}armbianEnv.txt; then
< env import -t ${load_addr} ${filesize}
---
> # fdtfile should come from compile-time u-boot patches
> if test -z "${fdtfile}"; then
> setenv fdtfile "armada-388-clearfog.dtb"
23c22,24
< setenv bootargs "console=ttyS0,115200 root=${rootdev} rootwait rootfstype=${rootfstype} ubootdev=${devtype} scandelay loglevel=${verbosity} usb-storage.quirks=${usbstoragequirks} ${extraargs}"
---
> test -z "${boot_interface}" && setenv boot_interface "mmc"
>
> echo "Boot script loaded from ${boot_interface}"
25,55c26,27
< load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/${fdtfile}
< load ${devtype} ${devnum} ${ramdisk_addr_r} ${prefix}uInitrd
< load ${devtype} ${devnum} ${kernel_addr_r} ${prefix}zImage
<
< fdt addr ${fdt_addr_r}
< fdt resize 65536
< for overlay_file in ${overlays}; do
< if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/overlay/${overlay_prefix}-${overlay_file}.dtbo; then
< echo "Applying kernel provided DT overlay ${overlay_prefix}-${overlay_file}.dtbo"
< fdt apply ${load_addr} || setenv overlay_error "true"
< fi
< done
< for overlay_file in ${user_overlays}; do
< if load ${devtype} ${devnum} ${load_addr} ${prefix}overlay-user/${overlay_file}.dtbo; then
< echo "Applying user provided DT overlay ${overlay_file}.dtbo"
< fdt apply ${load_addr} || setenv overlay_error "true"
< fi
< done
< if test "${overlay_error}" = "true"; then
< echo "Error applying DT overlays, restoring original DT"
< load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/rockchip/${fdtfile}
< else
< if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/overlay/${overlay_prefix}-fixup.scr; then
< echo "Applying kernel provided DT fixup script (${overlay_prefix}-fixup.scr)"
< source ${load_addr}
< fi
< if test -e ${devtype} ${devnum} ${prefix}fixup.scr; then
< load ${devtype} ${devnum} ${load_addr} ${prefix}fixup.scr
< echo "Applying user provided fixup script (fixup.scr)"
< source ${load_addr}
< fi
---
> if load ${boot_interface} 0:1 ${loadaddr} ${prefix}armbianEnv.txt; then
> env import -t ${loadaddr} ${filesize}
57a30,38
> setenv bootargs "console=ttyS0,115200 root=${rootdev} rootwait rootfstype=${rootfstype} ubootdev=${boot_interface} scandelay loglevel=${verbosity} usb-storage.quirks=${usbstoragequirks} ${extraargs}"
>
> load ${boot_interface} 0:1 ${fdt_addr} ${prefix}dtb/${fdtfile}
> load ${boot_interface} 0:1 ${ramdisk_addr_r} ${prefix}uInitrd
> load ${boot_interface} 0:1 ${kernel_addr_r} ${prefix}zImage
>
> setenv fdt_high 0xffffffff
> setenv initrd_high 0xffffffff
>
60a42,43
> fdt addr ${fdt_addr}
> fdt resize
76c59
< bootz ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}
---
> bootz ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr}6 hours ago, integros said:Here is the serial console log:
U-Boot SPL 2018.11-armbian (Nov 26 2018 - 09:25:57 +0100)
High speed PHY - Version: 2.0
Detected Device ID 6828
board SerDes lanes topology details:
| Lane # | Speed | Type |
--------------------------------
| 0 | 6 | SATA0 |
| 1 | 5 | USB3 HOST0 |
| 2 | 6 | SATA1 |
| 3 | 6 | SATA3 |
| 4 | 6 | SATA2 |
| 5 | 5 | USB3 HOST1 |
--------------------------------
High speed PHY - Ended Successfully
mv_ddr: mv_ddr-armada-17.10.4
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
DDR Training Sequence - Start scrubbing
DDR3 Training Sequence - End scrubbing
mv_ddr: completed successfully
Trying to boot from MMC1
U-Boot 2018.11-armbian (Nov 26 2018 - 09:25:57 +0100)SoC: MV88F6828-A0 at 1600 MHz
DRAM: 2 GiB (800 MHz, 32-bit, ECC enabled)
MMC: mv_sdh: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environmentModel: Helios4
Board: Helios4
SCSI: MVEBU SATA INIT
Target spinup took 0 ms.
Target spinup took 0 ms.
AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
flags: 64bit ncq led only pmp fbss pio slum part sxsNet:
Warning: ethernet@70000 (eth1) using random MAC address - aa:61:eb:18:90:59
eth1: ethernet@70000
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
1979 bytes read in 106 ms (17.6 KiB/s)
## Executing script at 03000000
Boot script loaded from mmc
load - load binary file from a filesystemUsage:
load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]]
- Load binary file 'filename' from partition 'part' on device
type 'interface' instance 'dev' to address 'addr' in memory.
'bytes' gives the size to load in bytes.
If 'bytes' is 0 or omitted, the file is read until the end.
'pos' gives the file byte position to start reading from.
If 'pos' is 0 or omitted, the file is read from the start.
load - load binary file from a filesystemUsage:
load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]]
- Load binary file 'filename' from partition 'part' on device
type 'interface' instance 'dev' to address 'addr' in memory.
'bytes' gives the size to load in bytes.
If 'bytes' is 0 or omitted, the file is read until the end.
'pos' gives the file byte position to start reading from.
If 'pos' is 0 or omitted, the file is read from the start.
4707429 bytes read in 886 ms (5.1 MiB/s)
5457936 bytes read in 1033 ms (5 MiB/s)
## Loading init Ramdisk from Legacy Image at 02880000 ...
Image Name: uInitrd
Created: 2019-01-19 11:57:53 UTC
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 4707365 Bytes = 4.5 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OKStarting kernel ...
Uncompressing Linux... done, booting the kernel.
Error: unrecognized/unsupported machine ID (r1 = 0x00000000).
Available machine support:
ID (hex) NAME
ffffffff Generic DT based system
ffffffff Marvell Armada 39x (Device Tree)
ffffffff Marvell Armada 380/385 (Device Tree)
ffffffff Marvell Armada 375 (Device Tree)
ffffffff Marvell Armada 370/XP (Device Tree)
ffffffff Marvell DovePlease check your kernel config and/or bootloader.
Initially I had no idea why the update break the system. I did several time testing the update scenario from 5.64 to 5.68 & 5.69 (both are internal release). Then I realized that I missed that you started from 5.67 which i thought never released.
I would say, the 5.67 contains broken u-boot 2018.11. It only compatible with boot-mvebu-next.cmd. It already fixed on this commit part of PR #1169. So version 5.68 onward should be compatible with both, boot-marvell.cmd and boot-mvebu-next.cmd.
Since the fix just modify the environment variable, I suggest to run these commands to make it also compatible with boot-marvell.cmd.
setenv boot_a_script 'load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; setenv boot_interface ${devtype};source ${scriptaddr}' setenv loadaddr 0x02000000 setenv fdt_addr ${fdt_addr_r} saveenv
I have tested it on 5.67
-
@djurny Thanks to bring this up to us.
Apparently we missed CONFIG_ASYNC_TX_DMA=y in kernel configuration during the transition from mvebu-default (LK 4.4) to mvebu-next (LK 4.1x).After enabling, recompile the kernel and creating new 8GB array (RAID 5, 3x 4GB), here is what i got
46: 483063 0 GIC-0 54 Level f1060800.xor 47: 554757 0 GIC-0 97 Level f1060900.xor
You can find the kernel on our repo.
We did some test and found no difference in term of CPU load and performance. We still investigating how to take advantage of MV_XOR to improve perf and/or system load.
-
@taziden which kernel version/release currently installed on your system?
you can check usinguname -r
if it's 4.14.88-mvebu you can download the header and install it using
wget https://apt.kobol.io/pool/main/l/linux-4.14.88-mvebu/linux-headers-next-mvebu_5.68_armhf.deb sudo dpkg -i linux-headers-next-mvebu_5.68_armhf.deb
Other than that version you can install it using the usual apt
sudo apt-get install linux-headers-next-mvebu
-
@malcolm armbianmonitor get the value from wrong sensor. It's inherited from sensor list under Linux kernel 4.4.
We have reported it to Armbian on this issue 1135.We are working to fix this. Since this could affect other board as well, we need to test carefully.
The correct reading is the one reported by htop. You could also read the CPU temp usingcat /sys/devices/virtual/thermal/thermal_zone0/temp
-
7 hours ago, thermalz said:
Hi all,
received my kit last week and put it together today.
I seem to be having issues with one of the fans. Only one will spin up, the other connected to J17 does not rotate. It's specific to J17 as swapping the fans around reverses the fan which doesn't spin.
I unplugged J17 connector and plugged it back in, the fan spun up for around 3 seconds then stopped, so I currently have a system with only 1 fan functioning.
Does anyone have any hints?
Hi @thermalz, could you try
sudo systemctl stop fancontrol echo 255 | sudo tee -a /sys/devices/platform/j17-pwm/hwmon/hwmon*/pwm1
and see whether the fan running full speed
-
Hi @Zykr, I just wanted to add on top of @gprovost instruction
On 12/8/2018 at 3:36 PM, gprovost said:@Zykr to complement what I wrote before. You could use following u-boot commands to boot manually on the correct kernel. Then once booted as wrote above, you should fix the wrong symlink in /boot ;-)
setenv bootargs "console=ttyS0,115200 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 ubootdev=mmc scandelay loglevel=1" load mmc 0:1 ${fdt_addr} /boot/dtb-4.14.83-mvebu/${fdtfile} load mmc 0:1 ${ramdisk_addr_r} /boot/initrd.img-4.14.83-mvebu load mmc 0:1 ${kernel_addr_r} /boot/vmlinuz-4.14.83-mvebu setenv fdt_high 0xffffffff setenv initrd_high 0xffffffff bootz ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr}
Replace the loglevel in the bootargs with "ignore_loglevel earlyprintk earlycon" so the kernel can output debug message as earliest as possible.
And since you encountered problem with the ramdisk, maybe just skip it for now
Below is the modified command
setenv bootargs "console=ttyS0,115200 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 ubootdev=mmc scandelay ignore_loglevel earlyprintk earlycon" load mmc 0:1 ${fdt_addr} /boot/dtb-4.14.83-mvebu/${fdtfile} load mmc 0:1 ${kernel_addr_r} /boot/vmlinuz-4.14.83-mvebu setenv fdt_high 0xffffffff setenv initrd_high 0xffffffff bootz ${kernel_addr_r} - ${fdt_addr}
Helios4 Support
in Marvell mvebu
Posted · Edited by aprayoga
Hi,
yes, you can see the boot process from serial. you can follow the instruction in our wiki. After the serial terminal ready, you can press the reset button to see the boot process since very beginning.
You should see something like:
U-Boot SPL 2018.11-armbian (Jan 20 2019 - 20:02:45 -0800) High speed PHY - Version: 2.0 Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type | -------------------------------- | 0 | 6 | SATA0 | | 1 | 5 | USB3 HOST0 | | 2 | 6 | SATA1 | | 3 | 6 | SATA3 | | 4 | 6 | SATA2 | | 5 | 5 | USB3 HOST1 | -------------------------------- High speed PHY - Ended Successfully mv_ddr: mv_ddr-armada-17.10.4 DDR3 Training Sequence - Switching XBAR Window to FastPath Window DDR Training Sequence - Start scrubbing DDR3 Training Sequence - End scrubbing mv_ddr: completed successfully Trying to boot from MMC1 U-Boot 2018.11-armbian (Jan 20 2019 - 20:02:45 -0800) SoC: MV88F6828-A0 at 1600 MHz DRAM: 2 GiB (800 MHz, 32-bit, ECC enabled) MMC: mv_sdh: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment Model: Helios4 Board: Helios4 SCSI: MVEBU SATA INIT Target spinup took 0 ms. SATA link 1 timeout. AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq led only pmp fbss pio slum part sxs Net: Warning: ethernet@70000 (eth1) using random MAC address - 52:fc:90:b3:be:70 eth1: ethernet@70000 Hit any key to stop autoboot: 3 2 1 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 1979 bytes read in 104 ms (18.6 KiB/s) ## Executing script at 03000000 Boot script loaded from mmc 220 bytes read in 86 ms (2 KiB/s) 19717 bytes read in 353 ms (53.7 KiB/s) 4714605 bytes read in 852 ms (5.3 MiB/s) 5460016 bytes read in 1037 ms (5 MiB/s) ## Loading init Ramdisk from Legacy Image at 02880000 ... Image Name: uInitrd Created: 2019-02-07 11:42:01 UTC Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 4714541 Bytes = 4.5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02040000 Booting using the fdt blob at 0x2040000 Using Device Tree in place at 02040000, end 02047d04 Starting kernel ...
But i think you won't see that screen.
LED8 near power inlet indicate the input voltage, if it's blink (nothing fancy here, just LED connected to
12V3.3V) then it's a hardware problem.most probably the power adapter.Do you have a voltmeter? Could you measure the voltage on these pin
to determine whether it's power adapter or on-board regulator failure.