Jump to content

kjn260

Members
  • Posts

    11
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi All, So after some learning and playing, there are three options that worked for me: 1) use nanopi-air config, use armbian build to patch device tree for uboot, and patch device tree for kernel to add sun8i emac device. Patch air defconfig to include CONFIG_SUN8i_EMAC = Y. 2) use nanopi-neo config, use armbian build to patch device tree for uboot , and patch device tree for kernel to add mmc device(s). Use Igor's patch above to patch the neo defconfig. 3) write custom board configuration, defconfig, and device trees (uboot and kernel) for a "nanopi-neo-core", patch the kernel device tree makefile and make a custom core image [nanopi-air (+ ethernet) (-wireless)] Option 3 worked the best for me, and I now have a nanopi neo core image (and build defs) that supports installation (and boot) from eMMC and also has functioning ethernet in uboot and kernel, that I can run from armbian build. Huzzah. I suppose I could push my files from 3) to mainline, but I have never been a contributor (so I don't know the rules) and this goes against the intended plans for the "CORE" Devices. Igor, what are your thoughts?
  2. Ok, so the problem seems to be the same as ethernet to air image as emmc to neo image? Is it as simple as patchinng the u--boot nanopi_neo_defconfig : CONFIG_MMC_SUNXI_SLOT_EXTRA=2? or does the device tree also need updating to initialise the eMMC device?? ## u-boot/arch/arm/dts/sun8i-h3-nanopi-neo-air.dts ## &mmc0 { pinctrl-names = "default"; pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>; vmmc-supply = <&reg_vcc3v3>; bus-width = <4>; cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */ cd-inverted; status = "okay"; }; Or is there additional configuration required that I still don't know? Edit: Are DTS files compiled at build time in Armbian build? can I generate a userpatch to patch the DTS file if required? or is it a different method?
  3. Both, but this is only based on my observations of the function in the nano pi neo. Does ethernet have to be enabled in u-boot to properly initialize the device for the kernel driver?
  4. Hello Igor, Forgive my ignorance of the armbian build environment - I think I have already done what you asked: 1) Create file nanopi_neo_air_defconfig_2 to include line "CONFIG_SUN8I_EMAC=y" 2) diff -Naur nanopi_neo_air_defcong nanopi_neo_air_defconfig_2 > nanopi_core_emac.patch (contents quoted above) 3) copy nanopi_core_emac.patch to /userpatches/u-boot/u-boot-sunxi 4) run build environment "sudo ./compile.sh" 5) option for full image 6) note application of patches (from: output/debug/patching.log): ... Processing file /home/armbian/build/patch/u-boot/u-boot-sunxi/lower-default-cpufreq-H5.patch Processing file /home/armbian/build/userpatches/u-boot/u-boot-sunxi/nanopi_core_emac.patch Processing file /home/armbian/build/patch/u-boot/u-boot-sunxi/sun8i-set-machid.patch ... 7) flash image and check. No success..... Or am I missing something? Does the behavior of "CONFIG_SUN8I_EMAC=y" add the required lines to the device tree for example: ## u-boot/arch/arm/dts/sun8i-h3-nanopi-neo.dts ## &emac { phy-handle = <&int_mii_phy>; phy-mode = "mii"; allwinner,leds-active-low; status = "okay"; }; or likewise with your suggestion of adding "CONFIG_MMC_SUNXI_SLOT_EXTRA=2" to the neo defconfig add to the device tree for emmc support, for example: ## u-boot/arch/arm/dts/sun8i-h3-nanopi-neo-air.dts ## &mmc0 { pinctrl-names = "default"; pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>; vmmc-supply = <&reg_vcc3v3>; bus-width = <4>; cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */ cd-inverted; status = "okay"; };
  5. There are obvious differences here too: https://github.com/RobertCNelson/u-boot/blob/master/arch/arm/dts/sun8i-h3-nanopi-neo-air.dts v https://github.com/RobertCNelson/u-boot/blob/master/arch/arm/dts/sun8i-h3-nanopi-neo.dts Do I need to patch the air dts file also during build? does the armbian build environment recompile dts > dtb at build time?
  6. Hi, Please see my comments in the other thread: Essentially when booting a Neo Core using the current air/core mainline image, the onboard fast ethernet is not being initialised. At a guess its because this is not included in the device tree (dtb/dts) for the nano pi air image or in uBoot config - however, if the image is to serve both boards it almost needs to - or they need to be separated. Both are probably reasonable options. Right now i'm trying to understand where the board defs for ethernet are collected during the image build using the armbian build environment and try and get a functional image with fast ethernet for the core, with eMMC support (the big difference). As per the other thread there was a difference in the Uboot config via the nano pi neo and the nano pi air, where the neo image initializes ethernet I built the following patch: diff --git a/configs/nanopi_neo_air_defconfig b/configs/nanopi_neo_air_defconfig index 11eb3ab13b..9f83068dd7 100644 --- a/configs/nanopi_neo_air_defconfig +++ b/configs/nanopi_neo_air_defconfig @@ -15,6 +15,7 @@ # CONFIG_SPL_DOS_PARTITION is not set # CONFIG_SPL_ISO_PARTITION is not set # CONFIG_SPL_EFI_PARTITION is not set +CONFIG_SUN8I_EMAC=y CONFIG_USB_EHCI_HCD=y CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y CONFIG_MMC_SUNXI_SLOT_EXTRA=2 And ran through build, even though the patch applies successfully there is still no init - what am I missing? Thanks
  7. So I went hunting through all the board defs - I only found one difference between the air and core: https://github.com/u-boot/u-boot/blob/master/configs/nanopi_neo_air_defconfig v https://github.com/u-boot/u-boot/blob/master/configs/nanopi_neo_air_defconfig Line 16 - which seems like it could be related. However, I tried modifying the build patch to include but it was unsuccessful - I guess I will have to keep looking.
  8. So I flashed the latest nano pi (non-core) image: root@nanopineo:~# dmesg | grep eth [ 0.000000] psci: probing for conduit method from DT. [ 4.313531] dwmac-sun8i 1c30000.ethernet: PTP uses main clock [ 4.313606] dwmac-sun8i 1c30000.ethernet: No regulator found [ 4.313782] dwmac-sun8i 1c30000.ethernet: Current syscon value is not the default 148000 (expect 58000) [ 4.313809] dwmac-sun8i 1c30000.ethernet: Chain mode enabled [ 4.313821] dwmac-sun8i 1c30000.ethernet: No HW DMA feature register supported [ 4.313832] dwmac-sun8i 1c30000.ethernet: Normal descriptors [ 4.313843] dwmac-sun8i 1c30000.ethernet: RX Checksum Offload Engine supported [ 4.313855] dwmac-sun8i 1c30000.ethernet: COE Type 2 [ 4.313865] dwmac-sun8i 1c30000.ethernet: TX Checksum insertion supported [ 4.314836] dwmac-sun8i 1c30000.ethernet: Found internal PHY node [ 4.315018] dwmac-sun8i 1c30000.ethernet: Switch mux to internal PHY [ 4.315031] dwmac-sun8i 1c30000.ethernet: Powering internal PHY [ 16.373120] dwmac-sun8i 1c30000.ethernet eth0: device MAC address 2a:18:44:a1:fb:f6 [ 16.383095] dwmac-sun8i 1c30000.ethernet eth0: No MAC Management Counters available [ 16.383114] dwmac-sun8i 1c30000.ethernet eth0: PTP not supported by HW [ 16.383550] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 54.889366] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 54.889461] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready root@nanopineo:~# Difference is: -the inbuild fast ethernet driver is enabled and worked. -USB<>Serial was disabled and I had to SSH into the board to get my dmesg.
  9. root@nanopiair:~# dmesg | grep eth [ 0.000000] psci: probing for conduit method from DT. root@nanopiair:~# and root@nanopiair:~# ifconfig eth0 eth0: error fetching interface information: Device not found root@nanopiair:~# so no driver is loaded. FYI: Armbian_5.38_Nanopiair_Ubuntu_xenial_next_4.14.15 so out of curiosity I plugged in a USB<>Ethernet Cable I had lying around: root@nanopiair:~# dmesg | grep eth [ 0.000000] psci: probing for conduit method from DT. [ 10.724772] asix 2-1:1.0 eth0: register 'asix' at usb-1c1b000.usb-1, ASIX AX88772B USB 2.0 Ethernet, 00:50:b6:1b:2a:b3 [ 11.249196] asix 2-1:1.0 enx0050b61b2ab3: renamed from eth0 root@nanopiair:~# Go figure....
  10. So I just tried to bring up a NanoPi Neo Core w/ minishield using the core/air image 5.37. To board boots but seems to leave ethernet disabled - it doesn't activate the port at all. I tried again with the friendly arm image and this worked fine - connected, picked up an address and I could ssh into the device. Is there a chance that the fast ethernet controller on the core is disabled on the mainline air image? is this controlled somewhere in the dts? Any help, please?
  11. Hi Guys, I have recently been contracted to a new project where I have moved out of my comfort zone (embedded 8-bit/32-bit uC) and have started my work on a H3 based device (currently NanoPi Neo) with Armbian. Over the course of my work I have managed to get up to speed with the basics; configuration, scripting, hardware and interfaces and device trees to a point where I can now work on the device as a proof of concept. The work that has been contributed so-far to the armbian project is impressive as is the active and knowledgeable forum - to which I hope I can contribute. One element which I cannot find an easy solution to is one of remote update. In the embedded world because your whole program/environment is loaded from flash into device ram it is very easy (if you have a device with network connectivity) to have a RPC to download and reflash new firmware - this is very useful for installations where physical access is restricted or unavailable and changes must be made to the firmware. While it is possible to for example remote access (via SSH or some other means) to do system upgrades, I think a "whole-image" approach has some benefits especially when considering critical system deployments. So I have been researching options that may be easily deployed into the Armbian build environment - there are quite a few options I have found (https://wiki.yoctoproject.org/wiki/System_Update), however on looking at all the options the best suited to the Armbian environment is mender.io in my opinion. It is compatible with block devices (uSD/eMMC), compatible with uboot, has a "secure" and robust update mechanism with fallback, is open source and has agreeable licencing for integration with Armbian/Commerical Products etc. The only downside is that it is currently built for integration with the Yocto project and only has a reference hardware of a Beagle Bone Black. There has been some information provided for custom target/build integration: https://mender.io/blog/porting-mender-to-a-non-yocto-build-system. After reading this I have made some notes, but I am obviously still learning and feedback from those more experienced than I would be appreciated. 1) Partition Layout At the moment the RESIZE_FS flag in the armbian build enviroment causes the rootfs partition to expand to the whole size of the available device, this can be overwritten to a fixed size at build time. Presumably with some modification to the script it could partition the device as required: https://docs.mender.io/1.0/devices/partition-layout 2) Go/mender Client libraries These should be possible to be added as user-packages in the build stage? 3)uBoot Patches: 0001-Generic-boot-code-for-Mender.patch 0002-Integration-of-Mender-boot-code-into-U-Boot.patch Should be able to be applied as user uboot patches at build stage? 4)Artifact creation (e.g. update images): Can be completed with an additional post-build script using the mender artifact tool or integrated as an script in Armbian build environment. I suppose my questions are: -is there interest in such an addition of this feature into armbian? -for the people that are well versed in the armbian build environment - is there any potential pinch points for integration?
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines