kjn260

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?
 
 

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.

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?
 
 
 
 

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?