TonyMac32

Just saw this one, honestly just throw away the vendor kernel and roll it into Meson64, it has extremely active upstream support and should soon have vdec support in mainline with Le Potato and K2.  Then we've eliminated a kernel and uncluttered.  The C1 is strangely also getting mainline support, but I have no idea the maturity, someone with one or Bay Libre would need to speak to that.  I don't see too much logic behind throwing it away when it shares 95% of its self with 2 other boards we support (the C2 anyway).

@TonyMac32 OK, I get /dev/spidev0.0 now! I'll do a SPI loopback test tomorrow since I have to take it out of the server rack It's full now, but this gives you an idea:
 

@sgjava the mainline device tree doesn't have the spi nodes the 3.14 had:  https://github.com/hardkernel/linux/blob/odroidc2-3.14.y/arch/arm64/boot/dts/meson64_odroidc2.dts#L802
 
That looks like generic GPIO SPI, and I haven't found, in the last 20 minutes or so, where the spicc and spifc pops out of the processor GPIO wise.  It does not appear to be GPIOX, so I think on the C2 the setup has to be a software SPI.  NanoPi K2 appears to be in the same position, just plain not having SPI.  I will investigate adding it to K2, then someone with a C2 can try it.

The armbianmonitor -m output demonstrated this wasn't a proper Armbian image, his cpufreq was dropping down to 200-ish MHz.  We are set to minimum 600, as otherwise there is too much latency for no power savings

It doesn't power via USB-C, so should not be an issue.

My 4x4 v8 truck doesnt have giant tires.....but oem is pretty big so... true statement


'Merica.

Sent from my SM-G950U using Tapatalk

There isn't a waiting list on bus accidents I hope?? 
 
We don't use busses, every American has a 4WD V8 truck with giant tires and American flags flying in the bed.  :lol:.  I could get hit by one of those...
 
 

https://lkml.org/lkml/2018/9/23/212

That's amazing. Now I want to Cascade login to as many as possible. #SBCeption

Sent from my Pixel using Tapatalk

Anyone catching the irony to keep Micro USB for powering? Guess it all depends on your target audience...

Yes, but the Tinker moves it from 2 to 3 to keep common with what ASUS is doing.  I think the UART 2 might be blocking an IO range that periogerals could use, but pure speculation.  
 
 

@TonyMac32 Here is a fix : https://lore.kernel.org/patchwork/patch/949665/

Now FriendlyARM has a wiki page for NEO4.

Yes, it is a reflex that a hobbyist has, "to collect all the things".  Especially when one looks like it should be shinier than the others.  BSP's, true performance, driver catastrophes, kernel defilement doesn't show up in the advertisements for these devices.  It is not helped that the "flagship" SBC in most people's minds out there is the Pi 3, a micro-usb powered usb-hub throttled VPU-constrained machine with very poor resources.  Compared to that, anything with high clock numbers or extra "RAM Chips" looks like an amazing deal, people tend to take the community support over there for granted.
 
I do like the Wiki idea, however in a less ambitious sense:  We should list, with no "rose-colored glasses", exactly what the pros and cons are of each board supported, discrepancies between hardware specification and advertised capability, and recommended use cases for each board.  For those use cases, I would personally require a definition of minimum requirements and recommended requirements per use case, and those would live on their own pages.
 
 

I think it's more like the dentist, always complaining that I'm not flossing enough...  I don't want to hear it, but the dentist is right.  
 
 
4.9 kernel, ok, 2015 u-boot, .  Looks like an interesting board, but I worry about drivers and any hope of mainline support. 

https://www.newegg.com/Product/Product.aspx?Item=N82E16812200061
 

Here is one of the recipes where it using ham rock that I've eat recently :
https://en.wikipedia.org/wiki/Baeckeoffe

I completely agree. I think, if a desire to be more minimalist exists, that we create those images specifically labelled as such, for devices that fit the case (OPi IoT, nanopi NEO, Duo, etc).  Otherwise I don't see the value.
 
My honest reaction to the discussion is that it fits perfectly with the "What is Armbian?" discussion.  I don't think playing games to save a few megabytes fits something we really care about, it isn't really our problem if an extreme subset of users wants to pull the 512 MB SD card out of their 10 year old Sandisk Sansa MP3 player and want to put Linux on it...
 
There are 2 main deliverables that I see:  A build system for people to make their flavor of Debian for their needs, and our pre-packaged images.  IMHO, if we want to make it more "lean", this can be an option available in the build system deliverable, and if we want to make questionably valuable tiny images, then we can do that in parallel with the current desktop and server images.

https://dl.khadas.com/Hardware/VIM1/Datasheet/S905X_Datasheet V0.3 20170314publicversion-Wesion.pdf
and
https://drive.google.com/file/d/0B1Rq7NcD_39QYnltdGtWWEFvS0U/view?usp=sharing
Page 26, you can see that UART B and C live on I2C_A (The RPI's "ID" pins) and "PCM_DOUT/DIN" (Pins 19 and 21 on Le Potato)
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi#L764
Shows the definition of the UART's in question in the GXL dtsi,
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-libretech-cc.dts#L266
shows where the A0 UART is enabled, it should be very similar for UART B and C
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi#L425
There are the pins that need referenced in the same manner as the AO one does.
 
If you're up for some "fun with device tree", or are quite creative that should do the job.  I haven't tried it personally, but you have access to the pins and they have those alternate functions.
 
As to power management, I haven't used the 4.18 kernel to any real effect yet, so I can't speak to it's consumption, but I would guess some more "fun with device tree" in both u-boot and linux could disable all the stuff you're not using.    Also make sure you're using "conservative" or similar for your CPU governor.
 
If you can't get as low as you want, there are "SoM-style" H3 or H2+ boards that could also fit your needs like the NanoPi Neo/Core/Duo, or even the Libre Computer Tritium H2/3, if you want to keep the flexibility of maintaining the ports.  If you search the forums you'll find a ton of "minimize consumption on H3" information.

challenge accepted
 
Todays special:
 
Schweinshaxe mit Knöpfli
Knöpfli is Switzerlands pendant to 'Spätzle'.  Schweinshaxe (Ham hock), and for those not knowing them:
 here we go..
 
user: ~$ time meal.sh real ~2h30min user ~40min sys ~2h First we start with the Haxe. We rost them of both sides for around 2-3mins in a metal bowl on the hotplate.

First on the side where the bones are smaller, then on the other side. We add 2 roughly cutted onions and carrots and let them rost for around 5mins before adding a glass of vine.

We let the vine now reduce a little bit before adding bouillon (as much as needed so that they are not completely covered). They're no cooked for around 1h30mins at 150°C and the last 30mins at 200°C in the oven (use the liquid to 'moisten' them every 15min). 
Knöpfli:
We mix 500g flour with 300mL milk (or 150 milk 150 water), 3 eggs a bit of salt (one teaspoon) and if you like a bit of nutmeg. As soon as it is well mixed we let it rest for 30mins.
 
A big pan is filled with water and heated up until it boils. The knöpfli dough is then pressed through a 'perforated sieve' (there are special ones for 'Knöpfli' but mine comes from a steam cooking set and works also well ).

as soon as they swimm (normally immediately), they can be skimmed wit a normal sieve and collected. If you want you can roast them now in butter and add some roasted onions on top but it also works well without, or as I do add cheese on top. Similar you can add some honey on top of the 'haxen' for the last 5-10minutes for a nice crust (I guess the germans adding Soda in the end for the crust, maybe the Bavarians here knowing it? ).  
In the end, it should look somehow like that:

 
Things you need (for ~4 persons):
2 onions 2 carrots 4 haxen 500g flour 3 eggs 300mL milk a glass vine, a bit of bouillon, salt, oil (butter)  

Sorry, 'recipes are just an inspiration'   I only follow them when it's about making dough. And then I totally lack English kitchen vocabulary (only fluent in German, Italian and a bit French in this area) and it won't get better than http://kaiser-edv.de/tmp/senigallia/Sabato.html anyway...

I feel left out but it’s 2:30am and the fanciest action in my kitchen is a Molotov cocktail 
 

*** This is educational material only concerning current limits and their effects on things like rise and fall times, and how they can theoretically impact SD cards.  The correlation with reality is purely theoretical and has not been empirically proven, the concept is correct but any specific values may be/ probably are off by some factor***
 
A lot of boards from various vendors inevitably have some difficulties with electrical signalling.  You see it in delay values, phase correction in software, etc.  The general prevailing theory is almost always "get it close and fix it in software".  But, the software team is not always clued in, or the physical reality is simply not able to be fixed that way.  Today I'll go into SD cards and the need for proper signal paths, limited capacitance along the way, and proper drive levels at the SoC.
 
This came to my attention while reviewing failures to boot on RK3328 devices, and while this particular issue may still be independent (no root cause confirmed as yet), I have a suspicion it is at least a contributing factor.
 
GPIO's on SoC's have, typically, current limiting on each pin or bank of pins.  For Rockchip, this limit defaults to 4mA, with 8 and 12 being available as optional settings.  This includes the SD card bus, clock, output, etc.  These current limits are exactly that, limits.  If the interface only needs 1 mA, it will only pull 1 mA, regardless of the GPIO drive setting.  if it needs more, however, it will only get what the drive setting allows.
 
SD card interface standards have 3 voltage signalling modes, SBC's only make use of 1 or 2 of them.  Many boards supply only 3.3V to the card, limiting to frequencies of 25 or 50 MHz.  Those that support UHS-I modes allow 1.8V signalling, and the range of speeds there include the original 25 and 50 MHz, but add higher speeds as well (100 and 208).  The higher speeds absolutely require the lower voltage, though the 25 and 50 Mhz speeds benefit from it as well due to improvements in rise/fall time with the smaller voltage transitions.
 
The SD standard requires a total line capacitance of 40 pF or less on each line, including the internals of the card.  I will simply assume 40 pF for the simulations, as it's likely few if any of these boards are "optimal" in that regard.
 
I'll be using LTSpice as an aid to show the effects of the current limitations, measuring voltage across the capacitance.  In reality there would be a complex impedance with the resistance I'm not modelling and the capacitance distributed throughout the system, which would cause some slightly different behavior.  This is mostly an educational introduction to the scary universe of high-frequency switching, so I'll skip the really gory details for the sake of readability.  In this circuit the LimiterDiode does exactly that, it limits current.
 

 
With a 4 mA limit into a 40 pF load at 3.3 Volts, 50 MHz, the signal is unusable.  Top in blue is the current sourced by the supply, stuck at the 4 mA limit at all times, below in red is the desired waveform, in green the result.
 

 
The board will crash if it attempts this.  Now, you might say, what if the board is extremely well made and the capacitance is lower?
 
Well, it looks like this (assuming 20 pF, which may not really be possible):
 

 
Still, no hope of operating properly.  Dropping to 25 MHz has roughly the same effect.  As I said, this is worst case, so don't jump down my throat about your board with the limits working at 4mA.  I am also assuming 4 mA source and sink limits, it may not be symmetrical, in which case the shape goes from triangle to shark fin.  Cutting the voltage almost in half by going to UHS-I signalling levels has the same effect (ratio wise vs the V_High value) as cutting the capacitance down.
 
On the ASUS tinker board this was discovered at some point, and the current limits increased to 8 mA.  I have not tried a card with no UHS support at 50 MHz (at least to my knowledge), the results at 3.3V/50MHz still look bad in my oversimplification, much like cutting voltage in half or capacitance or frequency, again, they all play into the same charge rate/time constant
 

 
At 25 MHz, however, 8 mA is far more reasonable:

 
Now to the big reason for 1.8 V signalling:

 
50 MHz, 1.8V, 40 pF, 8 mA drive.
 
Assumptions:  source/sink values both controlled.  It's possible this is not the case.  If there is no "sink" limit, or if you assume 20 mA sink limit:
 
 
3.3V signalling, 50 MHz, 40 pF load, 8 mA source, 20 mA sink:

 
Now, as a final bit, assume there were no current limits of any kind, and let's measure what the system would need to supply at 50 MHz 3.3V:

 
So 120 mA or so to create the exact waveform, assuming some sort of simulated resistance somewhere in the system (in reality there would be a measurable resistance and therefor a current lower than 120, but also a longer rise and fall time)  Needless to say, a lot more than 4.
 
This is mostly important for boards that do not implement the 1.8V signalling modes, but do have aggressive current limiting on the SD card I/O's.  50 MHz is a bad place to live at 3.3 volts given a mechanical connector with wide flat terminals, and routing that doesn't always get as much care as maybe it deserves.  RPI, a board with these issues, seems able to source/sink 16 mA, most likely accounting for it's ability (when not starving itself for power, cooking itself, etc) to be "overclocked" in highspeed 3.3V mode.  Rockchip can only push 12 mA, I haven't read up on Amlogic yet, so you can't expect to have the same performance if you're not willing to add the necessary support for 1.8V signalling.
 

Okay couldn't resist sharing my insanity.   My goto build server is my frankendell, which was pretty much motivated for building armbian stuff.
 
A while back I noticed that dell enterprise desktop motherboards on ebay were really cheap.  That inspired me to google to see what older optiplex models had i7s.    So I started cobblin together a stupid server made from a dell desktop motherboard, an i7-2600, some fancy gamer ram from a co-worker, a 1U server case, a dual port nic, and an nvidia quadro card.    Then I cut the case down to size with an angle grinder, put it on a comm shelf that conveniently screwed into some 1x4's i hung from my rafters.   For extra credit, the bios is set to always power-on, and I spliced a Sonoff Basic into a powercord so that I can control from HomeAssistant.
 
My build VM is actually running on NFS storage over 2x1GB LACP.   IO's been good enough to keep me happy.
 
I ended up buying real dell fans and a the front panel nonsense because it so hard to make the bios not freak out.   Generally I advise just getting a whole optiplex 790/990 from ebay and spare yourself the excitement.

*** This is educational material only concerning current limits and their effects on things like rise and fall times, and how they can theoretically impact SD cards.  The correlation with reality is purely theoretical and has not been empirically proven, the concept is correct but any specific values may be/ probably are off by some factor***
 
A lot of boards from various vendors inevitably have some difficulties with electrical signalling.  You see it in delay values, phase correction in software, etc.  The general prevailing theory is almost always "get it close and fix it in software".  But, the software team is not always clued in, or the physical reality is simply not able to be fixed that way.  Today I'll go into SD cards and the need for proper signal paths, limited capacitance along the way, and proper drive levels at the SoC.
 
This came to my attention while reviewing failures to boot on RK3328 devices, and while this particular issue may still be independent (no root cause confirmed as yet), I have a suspicion it is at least a contributing factor.
 
GPIO's on SoC's have, typically, current limiting on each pin or bank of pins.  For Rockchip, this limit defaults to 4mA, with 8 and 12 being available as optional settings.  This includes the SD card bus, clock, output, etc.  These current limits are exactly that, limits.  If the interface only needs 1 mA, it will only pull 1 mA, regardless of the GPIO drive setting.  if it needs more, however, it will only get what the drive setting allows.
 
SD card interface standards have 3 voltage signalling modes, SBC's only make use of 1 or 2 of them.  Many boards supply only 3.3V to the card, limiting to frequencies of 25 or 50 MHz.  Those that support UHS-I modes allow 1.8V signalling, and the range of speeds there include the original 25 and 50 MHz, but add higher speeds as well (100 and 208).  The higher speeds absolutely require the lower voltage, though the 25 and 50 Mhz speeds benefit from it as well due to improvements in rise/fall time with the smaller voltage transitions.
 
The SD standard requires a total line capacitance of 40 pF or less on each line, including the internals of the card.  I will simply assume 40 pF for the simulations, as it's likely few if any of these boards are "optimal" in that regard.
 
I'll be using LTSpice as an aid to show the effects of the current limitations, measuring voltage across the capacitance.  In reality there would be a complex impedance with the resistance I'm not modelling and the capacitance distributed throughout the system, which would cause some slightly different behavior.  This is mostly an educational introduction to the scary universe of high-frequency switching, so I'll skip the really gory details for the sake of readability.  In this circuit the LimiterDiode does exactly that, it limits current.
 

 
With a 4 mA limit into a 40 pF load at 3.3 Volts, 50 MHz, the signal is unusable.  Top in blue is the current sourced by the supply, stuck at the 4 mA limit at all times, below in red is the desired waveform, in green the result.
 

 
The board will crash if it attempts this.  Now, you might say, what if the board is extremely well made and the capacitance is lower?
 
Well, it looks like this (assuming 20 pF, which may not really be possible):
 

 
Still, no hope of operating properly.  Dropping to 25 MHz has roughly the same effect.  As I said, this is worst case, so don't jump down my throat about your board with the limits working at 4mA.  I am also assuming 4 mA source and sink limits, it may not be symmetrical, in which case the shape goes from triangle to shark fin.  Cutting the voltage almost in half by going to UHS-I signalling levels has the same effect (ratio wise vs the V_High value) as cutting the capacitance down.
 
On the ASUS tinker board this was discovered at some point, and the current limits increased to 8 mA.  I have not tried a card with no UHS support at 50 MHz (at least to my knowledge), the results at 3.3V/50MHz still look bad in my oversimplification, much like cutting voltage in half or capacitance or frequency, again, they all play into the same charge rate/time constant
 

 
At 25 MHz, however, 8 mA is far more reasonable:

 
Now to the big reason for 1.8 V signalling:

 
50 MHz, 1.8V, 40 pF, 8 mA drive.
 
Assumptions:  source/sink values both controlled.  It's possible this is not the case.  If there is no "sink" limit, or if you assume 20 mA sink limit:
 
 
3.3V signalling, 50 MHz, 40 pF load, 8 mA source, 20 mA sink:

 
Now, as a final bit, assume there were no current limits of any kind, and let's measure what the system would need to supply at 50 MHz 3.3V:

 
So 120 mA or so to create the exact waveform, assuming some sort of simulated resistance somewhere in the system (in reality there would be a measurable resistance and therefor a current lower than 120, but also a longer rise and fall time)  Needless to say, a lot more than 4.
 
This is mostly important for boards that do not implement the 1.8V signalling modes, but do have aggressive current limiting on the SD card I/O's.  50 MHz is a bad place to live at 3.3 volts given a mechanical connector with wide flat terminals, and routing that doesn't always get as much care as maybe it deserves.  RPI, a board with these issues, seems able to source/sink 16 mA, most likely accounting for it's ability (when not starving itself for power, cooking itself, etc) to be "overclocked" in highspeed 3.3V mode.  Rockchip can only push 12 mA, I haven't read up on Amlogic yet, so you can't expect to have the same performance if you're not willing to add the necessary support for 1.8V signalling.