sfx2000

I have a dedicated KVM image, as I don't want to introduce changes from the distribution that might impact the build process - it's an old habit of mine.
 
Anyways - root is a major deity on a *nix system, and an errant script could do a fair amount of damage - it doesn't have to be a "bad actor" but even a typo...
 
Started looking at fakeroot as an option, as this does provide the opportunity to do file manipulation as needed to build an image.
 

Here is the Lichee Pi Zero with 4.3inch 800x480, keyboard and Li-Po battery. (also using a ESP8266 ESP-01 for Serial console over wifi)
 
 
 

Couple of things - I used to work for a Wireless Carrier that did 3G and LTE - 7th largest in the US until it was consumed by AT&T...
 
10.0.0.0/8 is private addressing - we used this plus the other ranges internally inside the engineering plant, from core to edge.
 
100.64.0.0/10 - this is carrier grade NAT, we used this extensively on the customer facing network, as it scales nicely
 
We didn't allow public IP's ever - just didn't happen, we didn't want to be hosting private servers on our network.
 

No its the password from the Movie "Wargames" which is WOPR searching for

It's in by default. Now it will be in remaining kernels as well.

Well, Oshpark turned around my order in 5 days, so I was able to build one today:
 

 
So far no problems, 5.16 V open circuit voltage, nominal design intent was 5.20, so within tolerance.

If one is running a DNS server for the LAN/WLAN - probably better to keep it on the wire

the new one has 2, and a big inductor that looks like a small office building.  
 
Yes, all of my components sit on the "top", other than the header to connect to the other board.  
 
 
I've taken to using a hot plate with thick steel "heat diffuser" to keep the surface consistent, I don't get any charring that way, the only tricky part is removing boards to cool them acceptably, but I've more or less worked that out, and the hot plate was $25.  I will admit SMT is new for me (I hand soldered the boards in this thread, for instance), but so far I'm having decent success.

Some feedback from @chwe and some improvements on the protection circuitry:
 

 
And for the record, electrical cleaner can/will dissolve your electrical connectors...   Also, lead-free solder is an angry and terrible thing.  ;-)
 
I'm charging my Pixel off of one of the power ports while I play music over bluetooth on the Tinker...  

If one is running a DNS server for the LAN/WLAN - probably better to keep it on the wire

Stumbled across this while working on something else not ARM related, but it's pretty cool - since Armbian is looking at devices that have eMMC, this might be useful
 
https://github.com/pepe2k/u-boot_mod
 
Short story - it's a uBoot with a micro web server that supports flashing images, including uBoot itself - basically it turns things into a bit of a fail-safe as long as uBoot can execute...
 
(those playing with the fire that is uBoot, keep your UART connections handy)
 
Do I have some security concerns - absolutely yes... but no different than the UEFI that is on many x86 boards these days.
 

PiHole works fine with most boards that are equivalent to a RPi2 for most home networks when wired up...
 
NanoPI NEO would probably be perfect for this application with current Armbian...

PiHole works fine with most boards that are equivalent to a RPi2 for most home networks when wired up...
 
NanoPI NEO would probably be perfect for this application with current Armbian...

I would agree - and there's not a lot of value add for the effort that would be needed to support three different Broadcom SoC architectures - the RPi community has their own rich ecosystem, and there's formal support from Ubuntu (and other distros) if one wants more than what Raspbian has.
 
Where Armbian shines - the project brings mainline support for SoC's (Rockchip, Allwinner, Amlogic are good examples) that do not have the best vendor support (old and outdated BSP's, bootloaders, etc) - RPi doesn't need that level of support. If Armbian wasn't there, many of these boards would be less than useful for many.

35C3 - MicroPython – Python for Microcontrollers  https://www.youtube.com/watch?v=xCPnOxWxHIc 
at min 5:30 you see also Adafruit, haven't seen it completely, but stumbled across it
 

Really depends - the Amlogic S905/S912's are interesting at the moment - some support Android 6, some are Android 7....
 
Rockchip based boards are high performance, but there's some non-technical issues around the Kodi group and Rockchip - so things generally work until they don't...
 
CNX-Software has a good follow-through on TVBoxes...
 
https://www.cnx-software.com/2017/12/26/whats-the-best-android-tv-box-2017-2018-edition/

I use "screen"  instead of  picocom. Have you ever tried this software?

And SBC vendors - they just look for the best solution to fit their needs and business plan for a certain board...
 
The cost and efforts need to verify/validate ISA conformance are extremely high, as they should be - you look at companies like Intel and AMD, qualification of a chip can take years - and same with ARM folks like Apple and Qualcomm, where they take the ARM ISA and do their own designs - the chips you see on the market now were actually done 3-4 years ago in a cadence of development.
 
And that's millions of euro's/dollars...
 
You look at SoC vendors like Allwinner, Rockchip, Amlogic - they're using IP blocks that have been pre-certified by ARM (and others) with the fabs - so each block has tapeouts for a certain geometry node and process.. Grab the ARM core of choice, the Mali GPU block, wrap it around DesignWare blocks for peripherals for UART's, GPIO, Ethernet, etc... It's like lego's or ikea furniture...
 
And to the CN side - this is all dependencies on foreign IP... whether is ARM, Intel, Imagination Tech (GPU's with PowerVR), MIPS, Oracle (ex-SUN), etc...
 
With RISC-V - that's all out the door - which makes this interesting - going back to CN, there's enough government money at the local and national level to make things happen, and enough research in the academic space, along with the industrial resources to get things done...
 
Remember the CN initiative - "Made in China 2025"
 
I'm just an observer on the industry here - not being political...but it is interesting what the mainland is doing, and worth watching...

that's ok, but what I have found is that UnixBench a good equalizer across different SoC's on these cheap little boards - even though UnixBench is still variable based on the compiler...
 
It runs long enough (a full run can be 28 minutes) to show if thermals are a challenge (for TinkerBoard, absolutely with stock config compared to NanoPI NEO, where the Tinker has a much better architecture (A12) vs. NEO with A7, but the Neo can shed heat faster, and outperform the Tinker in the longer run - heck, even Pi3B+ runs UnixBench faster than Tinker...

Good questions, I've added them. Thanks.

How can SoC vendors help here with support for chips, interfaces, GPU/VPU, network, etc...
The Armbian team has done a lot of development, how receptive has upstream been to accepting changes/pull requests?
What's the best approach for SoC/Board Vendors to get Armbian ported to their board/chipset?
Documentation is key for supporting a chip or board - where are the opportunities for the vendors to improve?

I would agree - and there's not a lot of value add for the effort that would be needed to support three different Broadcom SoC architectures - the RPi community has their own rich ecosystem, and there's formal support from Ubuntu (and other distros) if one wants more than what Raspbian has.
 
Where Armbian shines - the project brings mainline support for SoC's (Rockchip, Allwinner, Amlogic are good examples) that do not have the best vendor support (old and outdated BSP's, bootloaders, etc) - RPi doesn't need that level of support. If Armbian wasn't there, many of these boards would be less than useful for many.

Hint - it's a feature mention within the armbian-zram-config script set - it calls armbian-ramlog
 
Look at /etc/default/armbian-ramlog - you can change "enabled" to false, and then things start follow expected rules... and you can mount /var/log where ever you want... remember you need to be root or sudo to do this, and reboot after the change.
 

 
 

easy enough for the script - I just changed shutdown to reboot... which the UI still shows "Shutdown Yes/No" for now, but I'll take care of that later...
# os.system('systemctl poweroff') os.system('systemctl reboot') Anyways - @guidol - here's my updated script, it's based on the V2 script you posted from the DietPI folks... fixed the padding, and the provision for the second logo/splash screen...
 
 
bakebit_nanohat_oled.py

Nice work - must have been a bit of effort to squeeze a liter of code into 250 ml bucket...