umiddelb

Download Armbian with HA
Then boot the image, wait few minutes and login via http://ip_address_of_armbian_running_ha:8123 (official onboarding manual)
 
Home Assistant Supervised is, more or less, a full blown Home assistant.
 


Main difference between HA OS and Armbian with HA is that underlying OS here is clean Armbian Debian Bookworm and there is custom dedicated buildroot OS that is provided for a few single board computers, primarily for Raspberry Pi. We provide HA on a small selection of single board computers, but in theory, its possible to run this on (almost) all that are possible to build.
 

I am running HA on Odroid N2+ and it works without any problems. I have z-wave network with sensors and switches, air humidifier, Android TV, Android phones, dishwasher, ... Things works flawlessly, much better then few years back when I started with home automation for a first time, with OpenHab. This time it was setup from scratch and in a matter of days, most of devices are in function, playing with automation.
 
Tested on:
Odroid N2/N2+ Odroid M1 Nanopi R4S Uefi-x86 Khadas VIM1S Khadas VIM4 (Amlogic vendor kernel trouble, failing / need inspection) Bananapi M2 Pro  
Provided for but untested (images you find on board downloads locations, seek them here https://www.armbian.com/download/😞

 
 
DIY

Contribute
 
Support:
single board computer hardware https://www.armbian.com/bugs home assistant functions https://community.home-assistant.io/

You'd better go with a fresh Armbian install. The Cubox-I image works for the Utilite Pro as well.
Just write the Cubox-i image onto USB or µSD card and modify the u-boot environment in a way mentioned above.
If you are afraid to render the Utilite Pro unusable, you can omit the saveenv command and try out the modified environment before you make the change permanent.
Before issuing the nand-sata-install command you should modify this shell-script in a way that u-boot can access the filesystem contents during boot.
 
Cheers
Uli

yes, mostly the nodes in the device tree are available but deactivated with status = "disabled";
And you simply can active them by saying status = "okay"; in an overlay. Furhermore you can override the standard values.
What you did in the past with module parameters you nowdays do it in the device tree.
 
check this: https://elinux.org/images/f/f9/Petazzoni-device-tree-dummies_0.pdf It helped me to get an overview what DTS is and how it interacts with the linux kernel drivers. Oh yes, its not easy to understand. It will take some time (at least for me it took years) but playing around is good for practise and step by step you will get familiar with it.
 
Next version 22.05 will have the regulators enabled by default so you do not need the overlay anymore.
 
 
 

The u-boot feature set is defined during build-time. IIRC there has been a reason for disabling this feature in the past for certain platforms.  

This board might meet your requirements, except of the price tag ... you may regard it as an upper bound.
 
https://www.solid-run.com/arm-servers-networking-platforms/honeycomb-workstation/

The Utilite Pro has 2GB of RAM only, the Cubox-i has a variant (4x4) with 4 GB. Both share the same imx6 SoC, which is way slower than the Exynos 5422 from the XU4.
The Utilite Pro uses an internal msata ssd (which can be replaced), the Cubox-i has an esata connector (both with 3.0 Gbps).
 

I'd consider this one ... https://www.hardkernel.com/shop/odroid-xu4-special-price/ 

Some elements can be found here: http://armbian.systemonachip.net/archive/espressobin/

Hi,
 
actually don't wanted to argue anymore about this but have to leave some comment.
I fully understand the feedback from Werner and actually many thanks to do the patch! Unfortunatly I don't have the capability to do all the tests with all the different setups (otherwise I would really like to do).
 
What I can provide is the clear view about the root cause of the issue (acutally I have some strong Linux background and I just wanted to share this here because I really appreciate the job you guys doing).
Hope this helps with merging the patch from Werner.
 
1. The issue depends on the shell used via symlink /bin/sh. In all my systems (even non armbian) this seams to be nowerdays dash instead of bash.
2. the change raising the issue (aka root cause) is the change done in /etc/default/armbian-ramlog using arrays (commit https://github.com/armbian/build/commit/2606d17ec7e8cc28c298bbac31549f3597253121#diff-2d82f72c778209a339df3f1d9b3b300c795161a8572719b7ee9e589ef5724dc9) introduced Jun 12 2021 so it's more a regression then the issue reported is a bug.
3. the change introduce leads to the general failure that running /usr/lib/armbian/armbian-truncate-logs with /bin/sh (so actuall dash) will always fail when trying to source the configuration file /etc/default/armbian-ramlog because dash cannot handle the arrays
4. Solution to this is (you can choose)
revert the change done from above (not using arrays in configuration) -> I assume there is a good reason not to revert so I was not proposing this. change the link /bin/sh in general to /bin/bash -> seams to be not compatible with all the different debian/ubuntu releases so even bigger risk, so also not a good proposal just change #!/bin/sh in armbian-truncate-logs -> should not have any other negative impact -> therefor the proposal I guess anyway (even if this costs time): if you run the armbian-truncate-logs on any of your system, this will fail as well if you did not change either the /bin/sh link or you still use older /etc/default/armbian-ramlog from before Jun 12th.
On the other hand the change should not break anything because bash should be installed on every debian/ubuntu. If you try to uninstall it, you will get a big fat warning and there are related dependencies.
 
Last thing again: I really have to thank you to do the work on armbian and can totally understand the problem with all the different bugs and the work behind and the reason asking for logs. Maybe the explanation above is sufficient to merge the patch from Werner and I believe everybody can be happy 
You don't have to spend a lot of time reading error logs (I'm quite sure you will not find a problem in there) any many still upcoming problem reports will be solved already (the number will increase as soon as the change above will spread over all the different systems).
 
Cheers

Are you mainly going to participate live, listen later to recordings or not at all? Any topics that are related, close to single board computer world to recommend?

I am still working on my "shopping list", but this is some initial draft from https://fosdem.org/2021/schedule/
 
QA
About the joy and tears of testing Embedded Devices
https://fosdem.org/2021/schedule/event/testing_embedded_devices/
Interactive debugging inside CI systems
https://fosdem.org/2021/schedule/event/debugging_inside_ci/
QAOps - The Latest Trend in QA & Software Delivery
https://fosdem.org/2021/schedule/event/qaops/

Software Composition devroom
Overview Software Bill of Materials (SBOM)
https://fosdem.org/2021/schedule/event/sca_overview/
 
Legal
Protecting against proprietary re-licensing with a community contract
https://fosdem.org/2021/schedule/event/qtproprietaryrelicensing/
 
CI
ARM your continuous integration system with fruits! by @gounthar
https://fosdem.org/2021/schedule/event/arm_your_continuous_integration_system_with_fruits/
 
Community
Mental health and free software
https://fosdem.org/2021/schedule/event/community_devroom_mental_health_free_software/
 
And one fine Belgian beer for each day of the conference also just arrived  
 
 

The spi flash memory (with the u-boot environment stored inside) is accessible from the command line. Please check if the corresponding driver is loaded via dmesg. It should look like:
[ 1.878826] spi-nor spi0.0: w25q32dw (4096 Kbytes) [ 1.878850] 2 cmdlinepart partitions found on MTD device spi0.0 [ 1.878854] Creating 2 MTD partitions on "spi0.0": [ 1.878870] 0x000000000000-0x0000003f0000 : "uboot" [ 1.888884] 0x0000003f0000-0x000000400000 : "uboot-environment" The partitioning information is passed as a command line parameter to the kernel (last parameter in this case):
console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=UUID=c2bdee11-6a88-46c1-8630-b70864d535bb rootfstype=ext4 rootwait loglevel=1 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u mtdparts=spi0.0:4032k(uboot),64k(uboot-environment)  You need to install the package u-boot-tools containing the userland tools and you need to configure the correct offsets:
uli@ebin:~$ cat /etc/fw_env.config # device name device offset env. size flash sector size number of sectors /dev/mtd1 0x00000000 0x00010000 0x1000 0x10 Then fw_printenv / fw_setenv will help you to modify the u-boot environment:
uli@ebin:~$ sudo fw_printenv arch=arm baudrate=115200 board=mvebu_armada-37xx board_name=mvebu_armada-37xx boot_a_script=ext4load ${boot_interface} ${devnum}:1 ${scriptaddr} ${prefix}boot.scr;source ${scriptaddr}; boot_prefixes=/ /boot/ boot_targets=usb sata mmc1 mmc0 bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done bootcmd_mmc0=setenv devnum 0; setenv boot_interface mmc; run scan_dev_for_boot; bootcmd_mmc1=setenv devnum 1; setenv boot_interface mmc; run scan_dev_for_boot; bootcmd_sata=setenv devnum 0; scsi scan; scsi dev 0; setenv boot_interface scsi; run scan_dev_for_boot; bootcmd_usb=setenv devnum 0; usb start;setenv boot_interface usb; run scan_dev_for_boot; bootdelay=2 console=console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 cpu=armv8 eth1addr=00:51:82:11:22:01 eth2addr=00:51:82:11:22:02 eth3addr=00:51:82:11:22:03 ethaddr=00:51:82:11:22:00 ethprime=eth0 extra_params=pci=pcie_bus_safe fdt_addr=0x6000000 fdt_addr_r=0x6f00000 fdt_high=0xffffffffffffffff fdt_name=fdt.dtb gatewayip=10.4.50.254 get_images=tftpboot $kernel_addr_r $image_name; tftpboot $fdt_addr_r $fdt_name; run get_ramfs get_ramfs=if test "${ramfs_name}" != "-"; then setenv ramdisk_addr_r 0x8000000; tftpboot $ramdisk_addr_r $ramfs_name; else setenv ramdisk_addr_r -;fi hostname=marvell image_name=Image initrd_addr=0x1100000 initrd_image=uInitrd initrd_size=0x2000000 ipaddr=0.0.0.0 kernel_addr=0x7000000 kernel_addr_r=0x7000000 loadaddr=0x8000000 netdev=eth0 netmask=255.255.255.0 ramdisk_addr_r=0x8000000 ramfs_name=- root=root=/dev/nfs rw rootpath=/srv/nfs/ scan_dev_for_boot=for prefix in ${boot_prefixes}; do echo ${prefix};run boot_a_script; done scriptaddr=0x6d00000 serverip=0.0.0.0 set_bootargs=setenv bootargs $console $root ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none nfsroot=$serverip:$rootpath,tcp,v3 $extra_params $cpuidle soc=mvebu vendor=Marvell Unfortunately the offsets vary between the different u-boot versions, so you have to find out the correct one for your board.
fw_printenv will tell you if the CRC check fails meaning that the chosen offsets do not fit. 

This discussion is interesting because I can relate to both sides.
As an end user - having multiple filesystems to choose from is great, choosing the right one is where I need to spend my time choosing the right tool for the task. Having a ZFS DKMS is great, but if after an update my compiler is missing a kernel header, I won't be able to reach my data. Shipping a KMOD (with the OS release) might give me access to my data after each reboot/upgrade. The ECC/8GB RAM myth is getting old but it has garnered enough attention that most newbies won't read or search beyond the posts with most views.
 
Armbian as a whole is always improving - a few weeks ago iSCSI was introduced for most boards (and helped me replace two x86_64 servers with one Helios64) - and an implementation of ZFS that works out of the box will be added soon enough. That being said, this is a community project - if a user wants 24x7 incident support, then maybe the ARM based SBCs + Armbian are not the right choice for them. Having a polite discussion with good arguments (like this thread) is what gets things moving forward - We don't have to agree with all the points, but we all want to have stable and reliable systems as our end goal.

I don't know if you have already read an article which I've written for ODROID Magazine a couple of years ago (https://github.com/umiddelb/armhf/wiki/Get-more-out-of-"Das-U-Boot") .

https://oversun.jp/?p=55

https://oversun.jp/?p=55

well that one escalated quickly.. and due to all the notifications popping up I had to follow most of the crap happened here.. And first before I even try to sum this up. I suppose you change your nick immediately to something else.
 
You started with a thread about a dirt cheap TV box which you already bought and then tried to convince others to buy it as well cause it's cheap and somehow in the hope armbian will run on it.. This one got deleted by @TRS-80 . Which might be an overreaction. Depending on how you read the rules he had the right to do it.. I would probably just moved it to TV boxes so that it get read by the right persons namely @balbes150 who more or less maintains 'armbian on TV boxes' on his own. Most others doing development are for good reasons not interested in TV boxes (even with schematics it's mostly a pain if things like a proper DT don't exist from the vendor.. But instead of trying to get this in a better shape you tried to find every possible sub-forum to tell everyone that you're pissed-off that he deleted your first post here and there.. since he set you back that everything must be approved it just bloated my messegeboard more with stuff I actually have no passion to deal with.. After seeing that you bloat around everywhere, it was probably the right decision to revoke your post right upon approval by a moderator.. I'm not a fan of such actions cause it's just more work for me to approve x posts more per day..
 
A small hint the few bucks you spend for an SBC or for TV box is nothing compared to the $ you spend for support. If balbes thinks it's not even worth to have a briefer look at a box he will have likely good reasons for that (I don't even waste my time for TV boxes anymore.. you don't know what you get, things can change cause the vendor runs out of something and replaces it with something else e.g. another wifi chip other ram other whatever he runs out... and then he has to deal with the fall out of that cause people show up here that their similar looking TV box doesn't work as expected). Who will then dive into it to fix it? Will you be around and fixing all this stuff? Or is it then up to him to explain the new users that "this batch works" and this batch doesn't cause component x changed and there's no support for it? It's mostly the second.. And why should he do that for a TV box he's not interested in at all? He answered quite polite that it's a boring TV box he's not interested in.. After that you tried to convince that this is somehow valuable for armbian for whatever reason. I don't think it is.. people here around know that the W905 variants are mostly well supported in the kernel a well supported SoC doesn't give you a well supported TV box/SBC.. As you both figured out the only network connection on this board is crap and due to limited other options (only 2 USB2 every other possibility e.g. attaching network over USB will limit a limited TV box even more making it a wasted 18$ for everyone who buys this box based on that thread in the hope that enough pressure on balbes will convince him to look at it). And that around a time you didn't even tried to get your research done if and how this thing can be re-flashed, that might be your starting point https://lmgtfy.com/?q=amlogic+s905+firmware+update+over+USB ) and then from the picture:

you see on the right side VCC RX TX GND? that's likely your debug UART and 'most likely' it's 3V or 3v3 so setting up your debug UART see what comes out use google or bing or whatever searchengine you prefer. so that you get a clue what is there if people already did something with the bootloader there or a similar one (if it's u-boot and you can interrupt it printenv gives you some nice hints) post your finding and your guesses and maybe someone will give you a hint here and there how you should progress. That would show @balbes150 that you're actually interested in doing something not just soak up his time, maybe not cause I think he has enough valid points to declare this box as a waste of time.. And the TV box subforum is still a forum about armbian on TV boxes not elec"something" on TV boxes.. If you want that ask the guys there to support your new paperweight maybe they're willing maybe they're not - that's then their decision. But except the confirmation that there's a crap wifi IMO your thread provided nothing of value to armbian. Well at least those involved in the whole TV boxes stuff now can honestly say that you shouldn't buy this one if someone asks for advice which TV box he should buy (and if you want something which works without much pain it's a good idea to do your research first and then buy).
 
Why should it get deleted? Maybe cause it's not about censorship here? If this would be about censorship we would have deleted your account all your posts and it would look like you were never here. That's censorship.. Locking a discussion where everything is said and all needed persons made clear that support for it wont happen isn't. It's just keeping the forum somehow readable. Tagging randomly people to waste their time as well is just bad taste. If Igor thinks that someone acted not the way it is acceptable he would already made this clear. Moderator rights already got revoked if someone didn't had a common sense how he should act like.. Was everything perfect ofc not -  or at least I would maybe solved things different, but mistakes happen and from what I saw no major mistake happened.. You got your thread back after things clarified even the restrictions got revoked. The only stuff which is 'censored' from you is where you entered a thread which was used by proved spammers to get the first mod approval just to bloat the forum after its with spam IMO that whole thread can go to trash cause it doesn't add any value to armbian but let others decide that. And your answers there honestly were just a try to make people angry so that you get a reaction nothing of value for ambian as well.. just another thread which wastes peoples time.
 
So if you really wanna do some research (this here got the research tag removed by myself cause it's ranting not research) you could spend some time to get something out of your paperweight and see how far you get. likely this time is better spent as starting another discussion about random claims and insults to people here. Even when I think balbes is right and this box is a waste of time, it might be a good one to learn things on your own instead of pushing other people to do the work for you. And even when not.. at least you only wasted your time and not everyone else' time.
 
 

dude forreal you kinda fly off the handle pretty quick. 
 
Balbes is the loneTV boxes person.... and the tv boxes is his project... so if he's not interested.. he's not interested... 
 
I'm sure if you wanted to add support to the TV boxes branch he'd accept the PR.

You might want to watch this talk here, Andre is explaining his ideas how to create a single generic firmware image.

I can get in touch with the odroid guys to change this situation if you want.

Well that one went into personal insults of each other which is for sure not what both of you want... Let's try to figure out where and why this went wrong.  Starting from here:
 
Well the answer was more or less there:
 
understandable, it's frustrating. when 'your board' gets dropped.. But you must also understand that we can't support every board for years, especially if it's not sold anymore.. It's work to adjust the related patches everytime, to test it before we provide a new image and the support over forum. This thread was meant as a 'board support - general discussion / project aims' not a how to I get *random board supported*. For such a topic you should open your own thread.. E.g. here: https://forum.armbian.com/forum/25-peer-to-peer-technical-support/ (Armbian support ended or never existed - 3rd party boards and external hardware). Hint (since the SoC is still supported you basically need an ubuntu image, a device tree (or fex file in case you deal with the old kernel which I don't recommend) for your board, a defconfig for uboot, the buildscirpt and some time to build your images and see if and what's working (so you get also a clue what it means to support a board... and we support a few more than one)..
Such questions show up constantly.. This can be frustrating.. Sometimes you get then a less polite answer.. that's human.. your first post maybe wasn't a rant.. the follow up here clearly were.. From there you can answer (as @Igor did) or as I do quite often... Just ignore it.. I'm mostly not in a mood to answer to stuff which just annoys me, why should I? As others, I donate my time for free and it's not worth to deal with annoying stuff. There's enough funny stuff to do on a project like Armbian. Even helping other people to get familiar with the buildscript can be fun, but clearly not if someone drops partly into the wrong thread, complaining multiple time why his question isn't the most important one we should answer to.. and then complaining about bullying... In case you still want to bring back your board working:
 
Here's one where I implemented a whole new SoC family into armbian:
 
And in this thread I tried to basically show *my workflow* to patch a kernel and u-boot to bring in a feature into an existing board:
 
with those two, and enough time, you should be able to bring back your board into the buildscript.. And if there are still open questions, you can open a thread in P2P and maybe someone is willing to give you some guidance who knows.. I hope we can keep this thread now as for what it was for, in case not I'll either close it for a cool down phase or just delete the off-topic part, depending if I've a good day or not..

Here's a reference for an open source project using jira ...

Atlassian offers free-of-charge licenses for Open Source projects ...

Any 3.3 V level UART USB dongle will do the job (for the C0/C1/C1+/C2), you can even use standard breadboard female cables to connect to the Odroid serial console pins:

I plan to attend FOSDEM 2019, anyone else too?

You can disable logging to ram by setting `ENABLED=false´ in  `/etc/default/armbian-ramlog´.