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

  • Armbian
    • Armbian project administration
  • Community
    • Announcements
    • SBC News
    • Framework and userspace feature requests
    • Off-topic
  • Using Armbian
    • Beginners
    • Software, Applications, Userspace
    • Advanced users - Development
  • Standard support
    • Amlogic meson
    • Allwinner sunxi
    • Rockchip
    • Other families
  • Community maintained / Staging
    • TV boxes
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families
  • Support

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. Now the mainline u-boot has decent pcie and pcie phy driver for rk3399. The only deficiency is the clock of pcie phy not included. The first attached patch add this clock so that u-boot proper can load linux kernel residing in an ext4 partition of nvme ssd.pcie_phy_clk.patch The second patch enables loading the environment from a file in an ext4 partition of nvme ssd.env_nvme.patch More conveniently the u-boot proper(u-boot.itb) could be an ordinary file residing in an ext4 partition of nvme ssd. The idbloader(tpl/spl in spi/emmc/sdcard) could load it if pcie nvme support is enabled in spl. That's the third attachment.spl_nvme.patch The usb and usb phy is working so the usbkbd can be used to choose a boot option without a serial port debug console. The last attachment set the default env to enable usbkbd and vidconsole.env_vidconsole_usbkbd.patch And for your convenience my u-boot config for nanopc-t4 also attached here.u-boot.config
  2. Hello, i'm using the NanoPC-T4 with Armbian Bookworm (23.8.1 with Linux 6.1.63-current-media) Kernel and Mainsail/Klipper is running on in smooth and gently. Since i want to record timelapse videos, i've decided to buy the orginial "FriendlyELEC Cam1320 PI Camera Module" based on the OV13850. I've connected it in the expectation that it should work together. But the System is not detecting the camera module. $ v4l2-ctl --list-devices rockchip,rk3399-vpu-enc (platform: hantro-vpu): /dev/video2 /dev/video4 /dev/media1 rockchip-rga (platform:rga): /dev/video0 rkvdec (platform:rkvdec): /dev/video3 /dev/media0 rockchip-iep (platform:rockchip-iep): /dev/video1 I found a project which contains patches for the camera module, is there any way to see if these patches are integrated in the armbian kernel? And if not, is it possible to add these patches or is there a way to build a custom kernel with these patches easily? Or am I looking at the wrong place?
  3. 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
  4. After recent kernel update, USB3.0 ports no longer work, There is an error printed in kernel log. [ 2.826383] phy phy-ff800000.phy.6: phy poweron failed --> -110 [ 2.827119] dwc3 fe900000.usb: error -ETIMEDOUT: failed to initialize core [ 2.827881] dwc3: probe of fe900000.usb failed with error -110 I found this issue in NanoPC T4, but it might also appear in other RK3399 boards. lsusb didn't show any USB3.0 controller. Confirmed this isn't my hardware's problem, another board have this issue too. dwc3.txt
  5. I don't have a NanoPC-T4, but I have a NanoPC-T6 which I mainly bought because of the Dual Camera options of the MCAM400 on the T4 and the high-speed encoding properties of the Rockchip... those possibilities should be very similar for the T6 actually... Whatever, the camera configuration seems to be mostly here but I struggle to do the similar thing with the device tree of the T6... Anyone who has an idea about this and is willing to help me with that?
  6. NanoPC-T4 My above board successfully installs and is accessible via SSH on all of the following releases. Armbian Bullseye Server and Desktop Armbian Bookworm Server and Desktop Armbian Jammy Desktop In all cases neither the CLI Screen or the desktop screen ever show up via the HDMI. Ive changed HDMI cable, different monitor and different PSU I wondered if there any CLI commands that might help my confirm what the fault is or if the board is broken? Thanks for any help!
  7. Hello, I have been trying to get back to a working nanopc-t4. I'm traveling with an almost worthless computer since I accidently let armbian update itself. The next few days I have access to a TV. To get my screen to work I convert the - media - version to support dtb overlays, the build the driver and overlay. This needs the build in the modules to be present. Using uname -r gives me this path. usr/lib/modules/6.2.0-rc8-media/build I can install Linux headers through armbian-config. That does nothing for allowing make in the modules which is what I need. What am I missing and how do I get it? I have installed kernel source and headers and build essential. Thank you
  8. How to use GPIOS like the FriendlyELEC's official system? Wiringpi does not work on Armbian, can you adapt the Armbain system of Nanopc T4 to Wiringpi?
  9. Hello, I stupidly upgraded without thinking about the possible consequences. 6.1 to 6.2. Ive had my /home on nvme. But the nvme drive is no longer recognized. I have managed to get my display back, Im not sure about my panel yet. I had restore my device tree overlay. Ive hacked around losing the nvme. But it would be good to get my nvme drive back. I've got some work to do to deal with not having that storage and what was on it. Can anyone point me in the right direction? Alternatively, maybe it's not too hard to roll back to 6.1? I haven't contemplated that.
  10. 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.
  11. 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.
  12. NanoPC-T4 only has 16GRAM, which is still a bit small for daily use. So I want to put u-boot on emmc or sd card, and install the system on nvme solid state drive. If I want to realize this function, can the armbian-config tool help me realize it quickly? Or do I need to set u-boot parameters and compile by myself, thus installing the system in nvme SSD?
  13. I bought a NanoPC-T4 development board designed by friendlyelec and installed the Armbian operating system. But the heat generated by the Rk3399 main control chip is too high. I bought an official PWM fan. According to the official wiki, the fan can work normally. However, under the same configuration under Armbian, the fan can’t work normally, so I What work needs to be done? Thanks.
  14. Hello, I have been building images for the NanoPC-T4 with armbian successfully in the past. However I now get the error "could not resolve 'ports.ubuntu.com'" when the build tries to install ping_5.1-1_arm64.deb (full log below). Do you have any idea what this comes from and how I could solve/debug this ? Thank you Additional info : I added 8.8.8.8 as an alternative DNS server on my machine, I can ping ports.ubuntu.com successfully. I have cloned the armbian build and head points to this commit https://github.com/armbian/build/commit/5b8d86ae5f6f34cf6cc13edf6b1def2773f66f0a Best regards, Rick
  15. 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
  16. 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
  17. root@nanopct4:/home/paco# pulseaudio -check pulseaudio: opción inválida -- 'c' E: [pulseaudio] main.c: Falló al analizar la línea de comando.
  18. 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?
  19. 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 ?
  20. Hello everyone, I want to use uart4 port for zigbee2mqtt,but I don't know how to activates it.
  21. 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
  22. 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 ☹️
  23. 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
  24. 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
  25. 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).
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines