Jump to content

Search the Community

Showing results for tags 'nanopct4'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Community
    • Announcements
    • Feature Requests
  • Using Armbian
    • Beginners
    • Software, Applications, Userspace
    • Advanced users - Development
  • Upcoming Hardware (WIP)
    • News
    • Odroid M1
    • ROCK 5B
  • Maintained Hardware
    • Board does not start
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families
  • Unmaintained (CSC/EOL/TVB) / Other
    • TV boxes
    • Off-topic
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Matrix


Mastodon


IRC


Website URL


XMPP/Jabber


Skype


Github


Discord


Location


Interests

  1. Hello, I have had a nanopc-t4 and a few others for a long time now. I have tried to create a working dtb for it a few different times. My understanding of device trees is superficial I have not had good success. I have read the kernels DT docs many times. I can of course run an ancient 4.19 kernel but I would much rather be at the edge. Currently I've got armbian 22, but no edp. I can boot Friendly's lubuntu and then the edp works. Although it is edp or hdmi not both. I must unplug the edp to get the hdmi port to work. Which is really undesirable. If I remember, it can only enable 2 of its 3 hdmi ports at a time, so that is likely a simple DT change. I am wondering if it is even reasonable to wish for a working edp port with a modern kernel on any arm board. Or if possibly someone has a device tree for it that enables the edp. I have not tried an LTS version of armbian, I'm not familiar with the names and versions. I will look. So I'm wondering if anyone has the edp working or can explain where to look and maybe even why this situation exists where device support is lacking in newer kernels. Any help would be appreciated, Erica
  2. Hi, community! I wish you have a nice day! Started investigating why do I have problems trying to hear something from headphones. So, I believe there is something about HDMI audio codec related to panfrost, attached you will find info about. I guess this will be useful to catch bugs. I'm 73 years old, started on computers on NCR Century 100 as field engineer. From those years to now, a long development has brought to life.... Cheers, and many thanks to you! dmesg112222.txt armbianmonitor112122.txt
  3. root@nanopct4:/home/paco# pulseaudio -check pulseaudio: opción inválida -- 'c' E: [pulseaudio] main.c: Falló al analizar la línea de comando.
  4. I planned to upgrade and skip current 5.18 (EOL) with edge 5.19 or just use LTS 5.15. Offcial images 5.19/edge (e.g. Armbian_22.08.1_Nanopct4_sid_edge_5.19.5.img.xz) won't boot at all, maybe a short uboot screen. Using uboot v22.04 like other rk3399 boards did not fix it. SInce the nanopct4.conf is boardfamily=media but also works with rockchip64 (which was changed some time ago), building with boardfamily=rockchip64 current 5.15 or edge 5.19 works fine, the cli builds boot as expected. Maybe a general question, which bordfamily fits now best to nanopct4. I remember exactly problems which were fixed bei 150balbes maintainer when pulling it to media. Thankfully all patches found their way to rockchip64, which seems to be more active for rk3399 in general. Do you have any plans to combine them again?
  5. root@nanopct4:/boot/overlay-user# armbian-add-overlay lcd-mipi-opi4.dts Armbian is not installed properly. Missing armbian-release or armbianEnv.txt I found 22.08 using extlinux.conf instead of the legacy set of boot.scr + text files. That will miss overlay function when using extlinux ?
  6. Hello everyone, I want to use uart4 port for zigbee2mqtt,but I don't know how to activates it.
  7. Myy

    Mainline VPU

    So, I tried to adapt @Kwiboo and @jernej patches on my 5.6 branch, but this made the kernel fail to boot for no visible reason. Since I were able to boot it without the VPU patches, I'm convinced that it's their readaptation that broke something. The patches applied are here : https://github.com/Miouyouyou/RockMyy64 If someone wants to play with them and determine which one break the boot process.
  8. Test version with EFI\Grub support (with HDMI output) for rk3399. for station p1 https://disk.yandex.ru/d/HZ34T76zxS9pnw for nanopc t4 https://disk.yandex.ru/d/SjBMYJ37U6699A firefly-rk3399 https://disk.yandex.ru/d/BfrzRRyvdtavIg
  9. Hello, nanopc t4 folks, Some, not so long time ago, I worked on fusb302.ko driver and device tree improvements in order to make USB Type-C port working properly in the mainline 5.* kernel. I managed to get DisplayPort over type-C + some general type-c handling improved before my board simply died. Unfortunately, I was not able to finish all the planned work and cannot continue further However, I guess, working DP is already fairly good achievement that might be interesting for many of us. Hereby, I want to publish some patches to the mainline!!! driver and device tree that add missing functionality, so one can get DP+type-C working on NanoPC T4 (and all RK3399 based boards with Fairchild FUSB302 chip for PD with relatively small DT adjustments). I would be very happy if results of my work can be helpful to others and extremely happy if there any volunteers, who are willing to continue work on this subject. My primary goal was to contribute to Armbian, first of all, with a potential mainline repo contribution. What was added: Extcon notifications support (type-c related cables) in the stock fusb302 driver (developed by Google folks, but also used by Intel if I understand correctly) DisplayPort altmode is registered automatically, if device tree has proper modelling for that DisplayPort altmode is entered as soon as DP cable connection is detected (both DP+USB3.0 and DP only pin assignments are supported) DisplayPort altmode is handled by the unified DP altmode driver rather than custom out-of-tree PD chip driver "connector" node modelling in the device tree according to the mainline kernel docs and modern requirements fusb node phandle is still specified as extcon source for Rockchip's proprietary drivers, however, last can be easily adjusted to resolve extcon directly from connector node link (as soon as extcon property is declared as deprecated for all new development). fusb302 driver is now correctly linked to dwc3 driver which provides role_switch functionality (+1 step to correct "Dual Role" mode handling based on the cable detection). This also eliminates annoying error message in the boot log: "OF: graph: no port node found in /i2c@ff3d0000/typec-portc@22" Please, also notice that type-c mode is forced to Host as in the most of rk3399 based SBC dtbs presently. This is rather a workaround for such boards, than a permanent solution, until all necessary bits are developed for correct role switching in the drivers. I kindly ask some NanoPC T4 owners to build mainline kernel with my patches and test whether expected functionality also works for you. Those patches apply to linux kernel since 5.6 when I started to work, but should also apply to way earlier versions according to my brief analysis of kernel commits history. fusb302-add-extcon.patch rk3399-nanopc-t4-type-c-modeling.patch
  10. I have a weird issue where I have everything working as I want it a few different services running in docker (Pi-Hole, Motioneye, Home Assistant, Emby) and all their individual management pages are accessible. However as soon as i move the install over to emmc, all networking seems to break, with services no longer working, but some admin pages report everything is fine. Pi-Hole for example shows as running but no devices accessing the dns cant load webpages and the pi-hole management pages stop showing any further queries received. ive repeated the process of doing a clean install to sd , everything fine. move to emmc stops working ☹️
  11. https://github.com/sigmaris/u-boot First I tried the mainline uboot v2022.04 version and the sigmaris uboot, in the uboot command line I executed the nvme info command and found no nvme devices available. https://github.com/radxa/u-boot Since the radxa version does not have the relevant configuration files for nanopc-t4, the compilation and testing of the radxa version is abandoned. Is the patch in this thread for the mainline v2020.04 release? @piter75 @Hover
  12. Hi, since latest upgrade to new kernel 22.02 stable the system becomes unstable. There are issues writing to mmc2 and "EXT4-fs (mmcblk2p1): Remounting filesystem read-only". This does not allow most of the apps to work properly (e.g. openmediavault stops working) I tried to switch back to previous kernel version through armbian-config but that does not work too Pls help. Thanks
  13. Edit: This is a duplicate already reported and a pull request in place. mods please delete The solution is to revert a patch related to power management. Symptoms are that ethernet link comes up, but no ip, dhcp, cannot assign ip address. the following patch resolves the issue on my system. I did not raise this in bug tracker since its not allowed to put things in there that are not supported. Unsure what else to do with info, hopefully it will help someone else. From ad63cb5d37f9634fc097249ddda4240c10f041d7 Mon Sep 17 00:00:00 2001 From: Dan Johansen <strit@manjaro.org> Date: Tue, 7 Sep 2021 16:26:09 +0200 Subject: [PATCH] Revert "net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings" This reverts commit 2d26f6e39afb88d32b8f39e76a51b542c3c51674. --- drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c index ed817011a94a..280ac0129572 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c @@ -21,6 +21,7 @@ #include <linux/delay.h> #include <linux/mfd/syscon.h> #include <linux/regmap.h> +#include <linux/pm_runtime.h> #include "stmmac_platform.h" @@ -1528,6 +1529,9 @@ static int rk_gmac_powerup(struct rk_priv_data *bsp_priv) return ret; } + pm_runtime_enable(dev); + pm_runtime_get_sync(dev); + if (bsp_priv->integrated_phy) rk_gmac_integrated_phy_powerup(bsp_priv); @@ -1536,9 +1540,14 @@ static int rk_gmac_powerup(struct rk_priv_data *bsp_priv) static void rk_gmac_powerdown(struct rk_priv_data *gmac) { + struct device *dev = &gmac->pdev->dev; + if (gmac->integrated_phy) rk_gmac_integrated_phy_powerdown(gmac); + pm_runtime_put_sync(dev); + pm_runtime_disable(dev); + phy_power_on(gmac, false); gmac_clk_enable(gmac, false); } -- 2.33.0
  14. tkaiser

    NanoPC T4

    This is something hopefully suitable to become a 'Board Bring up' thread. The NanoPC T4 was the smallest RK3399 board around featuring full set of interfaces (Rock960 was smaller but there you can't use GbE without a proprietary expander) but in the meantime he got two smaller siblings: NanoPi M4 and the cute NEO4. Pros: Another RK3399 board so software support is already pretty mature Rich set of interfaces (2 x USB2 without shared bandwidth, 2 x USB3, triple display output and so on) No powering hassles due to 12V (2A) PSU requirement 16GB superfast eMMC 5.1 Usable and performant Wi-Fi (dual band and dual antenna so MIMO can be used, for numbers see here) All 4 PCIe lanes exposed (M.2 M key connector on the bottom, suitable for NVMe SSDs, or to attach a 4 port SATA controller or a PCIe riser card) Cons: A bit pricey (but if you compare with RockPro64 for example and order all Add-Ons you end up with a similar price) High idle consumption (4W PSU included in idle), maybe this is just bad settings we can improve over time heatsink too small for continous loads I started relying on @hjc's work since he's currently using different kernels than we use on RockPro64 or ODROID-N1 (though all the 4.4 kernels are more or less just RK's 4.4 LTS branch with some modifications, with mainline I didn't had a look what's different in Heiko's tree and 'true' mainline). Tinymembench numbers with RK 4.4 vs. mainline kernel (the latter both showing lower latency and higher bandwidth). Internal 16 GB eMMC performance: eMMC / ext4 / iozone random random kB reclen write rewrite read reread read write 102400 4 23400 28554 26356 26143 27061 29546 102400 16 48364 48810 85421 85847 84017 47607 102400 512 48789 49075 273380 275699 258495 47858 102400 1024 48939 49053 290198 291462 270699 48099 102400 16384 48673 49050 295690 295705 294706 48966 1024000 16384 49243 49238 298010 298443 299018 49255 That's what's to be expected with 16 GB and exactly same numbers as I generated on ODROID-N1 with 16 GB size. When checking SD card performance it maxed out at 23.5 MB/s which is an indication that no higher speed modes are enabled (and according to schematics not possible since not able to switch to 1.8V here -- I didn't try to adjust DT like with ODROID-N1 where SDR104 mode is possible which led to some nice speed improvements when using a fast card -- see here and there) Quick USB3 performance test via the USB-3A port: Rockchip 4.4.132 random random kB reclen write rewrite read reread read write 102400 4 24818 29815 33896 34016 24308 28656 102400 16 79104 90640 107607 108892 80643 89896 102400 512 286583 288045 285021 293431 285016 298604 102400 1024 315033 322207 320545 330923 320888 327650 102400 16384 358314 353818 371869 384292 383404 354743 1024000 16384 378748 381709 383865 384704 384113 381574 mmind 4.17.0-rc6-firefly random random kB reclen write rewrite read reread read write 102400 4 37532 42871 22224 21533 21483 39841 102400 16 86016 104508 87895 87253 84424 102194 102400 512 274257 294262 287394 296589 287757 304003 102400 1024 294051 312527 317703 323938 323353 325371 102400 16384 296354 340272 336480 352221 339591 340985 1024000 16384 367949 189404 328094 330342 328136 139675 This was with an ASM1153 enclosure which shows slightly lower numbers than my usual JMS567 (all currently busy with other stuff). Performance with RK 4.4 kernel as expected, with mainline lower for whatever reasons. I also tried to test with my VIA VL716 enclosure directly attached to the USB-C port but ran into similar issues as with RockPro64 but since my enclosure and the cable also show problems when using at a MacBook Pro I suspect I should blame the hardware here and not USB-C PHY problems with RK3399. This is NanoPC T4 with vendor's heatsink, lying flat on a surface that allows for some airflow below, running cpuburn-a53 on all 6 cores after half an hour: 13:57:31: 1008/1416MHz 8.44 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:40: 1008/1416MHz 8.52 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:48: 1008/1416MHz 8.51 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:57: 1200/1416MHz 8.47 100% 0% 99% 0% 0% 0% 90.6°C 0/5 13:58:05: 1200/1416MHz 8.47 100% 0% 99% 0% 0% 0% 91.1°C 0/5 So with heavy workloads you most probably need a fan to prevent throttling. Development related questions: IMO we should try to rely on single sources for all the various RK3399 boards that are now available or will be soon. And I would prefer ayufan's since he's somewhat in contact with RK guys and there's a lot of great information/feeback provided by TL Lim. What do others think? Also an issue is IRQ affinity since on boards where PCIe is in use those interrupts should clearly end up on one of the big cores while on other boards USB3 and network IRQs are better candidates. I already talked about this with @Xalius ages ago and most probably the best idea is to switch from static IRQ affinity set at boot by armbian-hardware-optimization to a daemon that analyzes IRQ situation every minute and adopts then dynamically the best strategy. Wrt information for endusers. All RK3399 boards basically behave the same since the relevant stuff is inside the SoC. There's only different DRAM (matters with regard to consumption and performance), different interfaces exposed and different power circuitry (and obviously different settings like e.g. cpufreq behaviour but I think we should consolidate those for all RK3399 boards). So you already find a lot of information in my ODROID-N1 'review', my SBC storage performance overview and most probably also a lot around RockPro64. No idea where to inform about RK3399 GPU/VPU stuff since not interested in these areas at all (hope others add references or direct information).
  15. Is anyone having issues with the Cinnamon desktop version restarting the desktop when using the menu app launcher? Can be repeated by launching with super key and typing anything for search or just launching any application. Happens with all 3 major menu app launchers. menu, cinnamenu and cinnstark Pinebook pro
  16. Hi, I am trying to disable UAS mode on attached USB HDs (I have quite a good amount of those) to avoid quite common issues. However, it seems that the usb_storage.quirks string is limited to 127 chars! dmesg shows: usb_storage.quirks: string doesn't fit in 127 chars I do not really see the point of limiting the string length to 127 chars..a bit more would be appreciated. Thanks
  17. I suggest adding a small patch for all u-boot for rk33xx. It allows to enable direct booting from USB media and significantly facilitates the use of RK33xx models for users. Allows you to easily launch any system from USB without the need for complex settings and manipulations with existing (main) systems on devices on SD or eMMC. The entire path fits in two lines. https://github.com/150balbes/Build-Armbian/blob/master/patch/u-boot/u-boot-arm-64/u-boot-0010-rk-usb-start.patch#L18
  18. Hello to everyone , We have several T4 boards and can't get the NVMe SSD we currently have - Toshiba KBG30ZMS256GA - working ... Tried different 4.4 kernels and various distros . The SSD itself proofed to be working in Mikrotik RouterBoard RBM33G . Before we buy some other NVMe SSDs to try , I want to ask for advise . Is it ok to get such messages from kernel : # dmesg | grep -i pci PCI I/O : 0xffffffbffee00000 - 0xffffffbfffe00000 ( 16 MB) [ 0.119383] PCI/MSI: /interrupt-controller@fee00000/interrupt-controller@fee20000 domain created [ 1.540416] PCI: CLS 0 bytes, default 64 [ 1.948302] phy phy-pcie-phy.5: Looking up phy-supply from device tree [ 1.948312] phy phy-pcie-phy.5: Looking up phy-supply property in node /pcie-phy failed [ 1.950471] rockchip-pcie f8000000.pcie: GPIO lookup for consumer ep [ 1.950482] rockchip-pcie f8000000.pcie: using device tree for GPIO lookup [ 1.950510] of_get_named_gpiod_flags: parsed 'ep-gpios' property of node '/pcie@f8000000[0]' - status (0) [ 1.950757] rockchip-pcie f8000000.pcie: Looking up vpcie3v3-supply from device tree [ 1.950858] rockchip-pcie f8000000.pcie: Looking up vpcie1v8-supply from device tree [ 1.950870] rockchip-pcie f8000000.pcie: Looking up vpcie1v8-supply property in node /pcie@f8000000 failed [ 1.950884] rockchip-pcie f8000000.pcie: no vpcie1v8 regulator found [ 1.950892] rockchip-pcie f8000000.pcie: Looking up vpcie0v9-supply from device tree [ 1.950901] rockchip-pcie f8000000.pcie: Looking up vpcie0v9-supply property in node /pcie@f8000000 failed [ 1.950913] rockchip-pcie f8000000.pcie: no vpcie0v9 regulator found [ 1.971648] rockchip-pcie f8000000.pcie: invalid power supply [ 2.471703] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout! [ 2.471905] rockchip-pcie: probe of f8000000.pcie failed with error -110 [ 2.593787] ehci-pci: EHCI PCI platform driver Our system is current Armbian # uname -a Linux boise 4.4.174-rk3399 #31 SMP Sun Feb 10 00:37:23 CET 2019 aarch64 aarch64 aarch64 GNU/Linux The diagnostics is uploaded to http://ix.io/1EIL Many thanks in advance
  19. I've built everything into the kernel that I can think of: Device Drivers ---> [*] USB support --> [*] USB Type-C Support --> ** built everything other than alternative mode / display port drivers [*] PHY Subsystem ---> ... [*] Rockchip TYPEC PHY Driver Nothing seems to get it working (other than using the legacy kernel). If I plug in a USB type-c ethernet adapter, the light stays on solid but nothing shows up under lsusb.. I'm not sure what else to try. Any help would be appreciated.
  20. There are several questions on the topic: Between the moment of transfer of control to the kernel from the u-boot and the moment of start of the kernel operation it takes 1.5 -2 minutes. I assume that during this period of time there is decompression of the code and placement in memory. But why so long? The 4.4.x kernel starts instantly. When I first turned on a nanopc-t4 with a 5.x.x (4.20) kernel, I already thought the kernel was corrupted. And quite accidentally waited for the green LED to blink. Why is there still no sound in fdt for nanopc-t4? I corrected fdt, but I can 't put it in kernel.org. It is possible that my patch goes against the established structure, but now I use sound. Maybe there are some subtle nuances that I 'm not aware of? Why can 't the kernel turn off power? The 4.4.x kernel was fine. It 's a flaw in fdt, in the kernel, something else? Thanks.
  21. Hi, I want to know if there is another way to power the Nanopc-t4 besides the 12V input power jack. As far as I know the 12V power input is the only way but If someone have another idea or way to do power the board, it could be very helpful for me. Thanks.
  22. Has anybody successfully used the USB type-c displayport of the nanopc-t4? How do you configure it? It works on the images provided by friendlyelec, so, I guess it is just a config/install issue ?
  23. Hi, I'm a user of nanoPC T4( RK3399), now i'm using offical ubuntu release. did Armbian for nanoPC T4 support it's MIPI dual camera? ISP? and other media function? thank you!
  24. Hello all, I have this board and It's suffering crashes and reboots all day. I think the logs are stored in RAM because I can't never find anything related to this issue. Is there anything I can do to find the cause? Many thanks. Regards.
  25. So I noticed my NanoPC-T4's will not boot an image made with the latest armbian build script. I did a binary search on the commits and tracked down the breaking change: commit 75d0f64e3d75e7c34466871b9723ef1a238609d8 <- THIS COMMIT AND ANYTHING AFTER IS BROKEN Author: Piotr Szczepanik <piter75@gmail.com> Date: Fri Apr 17 21:30:37 2020 +0200 Switch rk3399 to u-boot v2020.04 (#1873) * Switched rk3399 to u-boot 2020.04-rc4 * Switched rk3399 u-boot to v2020.04, synchronized configs * Updated to u-boot v2020.04 final * Fixed OrangePi 4 device tree reference commit cc98ba3c0d3ff8d84ed08bfbf691b3bc94a6bc2b <- THIS BOOTS FINE Author: Igor Pečovnik <igorpecovnik@users.noreply.github.com> Date: Fri Apr 17 21:29:06 2020 +0200 Disable MESA on bionic (#1895) Also enable xfce4 power manager on some boards Signed-off-by: Igor Pecovnik <igor.pecovnik@gmail.com> I checked the output on the serial console, it looks like the board gets stuck in an infinite boot loop: ######## POWER ON BOARD ######## DDR Version 1.24 20191016 In Channel 0: LPDDR3, 800MHz CS = 0 MR0=0x58 MR1=0x58 MR2=0x58 MR3=0x58 MR4=0x2 MR5=0x1 MR6=0x6 MR7=0x0 MR8=0x1F MR9=0x1F MR10=0x1F MR11=0x1F MR12=0x1F MR13=0x1F MR14=0x1F MR15=0x1F MR16=0x1F CS = 1 MR0=0x58 MR1=0x58 MR2=0x58 MR3=0x58 MR4=0x2 MR5=0x1 MR6=0x6 MR7=0x0 MR8=0x1F MR9=0x1F MR10=0x1F MR11=0x1F MR12=0x1F MR13=0x1F MR14=0x1F MR15=0x1F MR16=0x1F Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=32 Size=2048MB Channel 1: LPDDR3, 800MHz CS = 0 MR0=0x58 MR1=0x58 MR2=0x58 MR3=0x58 MR4=0x2 MR5=0x1 MR6=0x6 MR7=0x0 MR8=0x1F MR9=0x1F MR10=0x1F MR11=0x1F MR12=0x1F MR13=0x1F MR14=0x1F MR15=0x1F MR16=0x1F CS = 1 MR0=0x58 MR1=0x58 MR2=0x58 MR3=0x58 MR4=0x2 MR5=0x1 MR6=0x6 MR7=0x0 MR8=0x1F MR9=0x1F MR10=0x1F MR11=0x1F MR12=0x1F MR13=0x1F MR14=0x1F MR15=0x1F MR16=0x1F Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=32 Size=2048MB 256B stride ch 0 ddrconfig = 0x101, ddrsize = 0x2020 ch 1 ddrconfig = 0x101, ddrsize = 0x2020 pmugrf_os_reg[2] = 0x3AA0DAA0, stride = 0xD OUT Boot1: 2019-03-14, version: 1.19 CPUId = 0x0 ChipType = 0x10, 248 mmc: ERROR: sdhci_complete_adma: transfer error, stat 0x408000, adma error 0, retry 9996026, cmd 0x83a mmc: ERROR: sdhci_complete_adma: transfer error, stat 0x408000, adma error 0, retry 9996025, cmd 0x83a emmc reinit mmc: ERROR: sdhci_complete_adma: transfer error, stat 0x408000, adma error 0, retry 9996026, cmd 0x83a mmc: ERROR: sdhci_complete_adma: transfer error, stat 0x408000, adma error 0, retry 9996027, cmd 0x83a emmc reinit mmc: ERROR: sdhci_complete_adma: transfer error, stat 0x408000, adma error 0, retry 9996021, cmd 0x83a mmc: ERROR: sdhci_complete_adma: transfer error, stat 0x408000, adma error 0, retry 9996022, cmd 0x83a SdmmcInit=2 1 mmc0:cmd5,20 SdmmcInit=0 0 BootCapSize=0 UserCapSize=128001MB FwPartOffset=2000 , 0 StorageInit ok = 121149 SecureMode = 0 SecureInit read PBA: 0x4 SecureInit read PBA: 0x404 SecureInit read PBA: 0x804 SecureInit read PBA: 0xc04 SecureInit read PBA: 0x1004 SecureInit read PBA: 0x1404 SecureInit read PBA: 0x1804 SecureInit read PBA: 0x1c04 SecureInit ret = 0, SecureMode = 0 atags_set_bootdev: ret:(0) GPT 0x3380ec0 signature is wrong recovery gpt... GPT 0x3380ec0 signature is wrong recovery gpt fail! LoadTrust Addr:0x4000 No find bl30.bin No find bl32.bin Load uboot, ReadLba = 2000 hdr 0000000003380880 + 0x0:0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, Load OK, addr=0x200000, size=0xad9e8 RunBL31 0x40000 NOTICE: BL31: v1.3(debug):42583b6 NOTICE: BL31: Built : 07:55:13, Oct 15 2019 NOTICE: BL31: Rockchip release version: v1.1 INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3 INFO: Using opteed sec cpu_context! INFO: boot cpu mask: 0 INFO: plat_rockchip_pmu_init(1190): pd status 3e INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will reK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 U-Boot 2020.04-armbian (Apr 26 2020 - 00:46:29 +0000) SoC: Rockchip rk3399 Reset cause: POR Model: FriendlyElec NanoPC-T4 DRAM: 3.9 GiB PMIC: RK808 MMC: dwmmc@fe310000: 2, dwmmc@fe320000: 1, sdhci@fe330000: 0 Loading Environment from MMC... *** Warning - No block device, using default environment "Synchronous Abort" handler, esr 0x96000045 elr: 0000000000231550 lr : 00000000002314ec (reloc) elr: 00000000f4576550 lr : 00000000f45764ec x0 : 00000000f254a3c0 x1 : 00000000f8000000 x2 : 00000000f82a4000 x3 : 0000000000000000 x4 : 0000000011b3dc40 x5 : 0000000011b3dc40 x6 : 00000000ffffdff1 x7 : 0000000000000128 x8 : 0000000000000129 x9 : 0000000000000008 x10: 0000000000000008 x11: 0000000000000001 x12: 000000000000012a x13: 0000000000005dc0 x14: 0000000000000000 x15: 00000000f252d698 x16: 0000000000008080 x17: 0000000000000032 x18: 00000000f253cdd8 x19: 00000000f254a3c0 x20: 00000000f25415a0 x21: 00000000f252d480 x22: 00000000f45ea6c8 x23: 00000000f45ea6c8 x24: 00000000f254a368 x25: 00000000f254a370 x26: 00000000f254a130 x27: 00000000f254a378 x28: 0000000000000002 x29: 00000000f252d430 Code: 8b020022 eb02003f 54fffee2 b9403403 (b8004423) Resetting CPU ... resetting ... ######## OUTPUT REPATS AT THIS POINT ########
×
×
  • Create New...