TonyMac32

Not so far, I stuck the tree for this board in mainline and it will be available with 6.6.  I haven't messed with the USB3 yet, the collabora kernel is my secondary interest for this board, and, since I don't really get anything out of it, the board isn't my first priority either outside of personal interest. 
 
I'll look at lowering the eMMC frequency, but some actual testing for errors will be needed to make sure 150 MHz is truly "good" and not just "tolerably bad" for the driver 

Le Potato
   -boot, hdmi audio, USB, NIC
Tritium H2/3 and H5
    - Boot, NIC, USB
 

Hmm, The odroid-N1 is an RK3399 board, maybe that's what's killing the gpio library.  Or the header may be irrelevant, I honestly don't know. 
 
The GPIO on the Amlogic devices is quite a bit different.  I don't vary from the stock device tree most of the time, so other than the spidev I added it will reflect (assuming I read the schematic correctly, and it in turn was correct)
 

 
I've been meaning to do it for some time, but I'm just starting working on documenting some of the GPIO's and their various functions.  So, in the device tree if you enable UART A, you'd have the port you want.  Unfortunately my wizardry does not include device tree overlays yet, however this may be something that's ok out of the box if the vendor image has it configured.  (clarification:  I can make a static change to the device tree, however for these sorts of things dynamic changes via overlays is better)
 
It's also good to see @adafruit doesn't sleep either.  However, I will be going, back to paid work in 6 hours.

https://github.com/armbian/build/blob/master/config/sources/families/include/meson64_common.inc#L20
This is the default for Meson64.  No one added the actual top speeds for the Vims apparently
 
https://github.com/armbian/build/blob/master/config/sources/families/meson-g12a.conf#L5
 
is the override for the Meson G12A.  G12B needs something similar in here: https://github.com/armbian/build/blob/master/config/sources/families/meson-g12b.conf

Hello cyph84,
 
    Yes, this was working in the past, I can take a look.
 

https://github.com/armbian/build/pull/3957

I've pushed the fix to the build system, this new forum organization stuck my answer at the very top so it was removed from the discussion flow.

So far no luck.  We do have a redundant patch adding the nodes, but that isn't the culprit.  The driver complains it doesn't have the host-drv pin defined, but it's shared with the USB2 (same situation between Renegade and Rock64)
 
EDIT:  A PHY driver was added back in the dark days before USB3 support by the kernel.  It is only used by the Rock64 and Renegade, (and apparently also the RK3328 Station M-whatever).  I've removed the entries and USB3 is working again now that mainline supports it without said special case driver.  I will open a PR tonight with the fixes.

https://github.com/armbian/build/pull/3957

So far no luck.  We do have a redundant patch adding the nodes, but that isn't the culprit.  The driver complains it doesn't have the host-drv pin defined, but it's shared with the USB2 (same situation between Renegade and Rock64)
 
EDIT:  A PHY driver was added back in the dark days before USB3 support by the kernel.  It is only used by the Rock64 and Renegade, (and apparently also the RK3328 Station M-whatever).  I've removed the entries and USB3 is working again now that mainline supports it without said special case driver.  I will open a PR tonight with the fixes.

I'll take a look momentarily, the same patch enabled the usb3 for both the Rock64 and the Renegade, and it looks like mainline has that enabled by default but the patch still exists.  May or may not be a cause, I would hope redundant entries simply got ignored...

I have a Tinkerboard 2, the only thing causing any issue is the use of a variant of the standard buck converters to power the big cores and the GPU.  I have not gotten this converter to operate properly using the (really ugly and hackish) mainline Linux driver.  Since the existing Mainline Linux driver is pretty much crap, it makes it very difficult to add the variant.
 
@JMCC a differentiating factor for the Tinker 2 includes it's power input/management, which is extremely robust (it can power all USB ports per specification, unlike any other SBC I am aware of save the Tinker Edge R) and its use of the newer revision RK3399 which supports 2.0 GHz with no overclock and uses less power overall.  The nanoPC T4 would be my only recommendation for an alternate that is currently supported due to its feature set and design.  Ah, it also has a socket for standard PCIe wifi modules, which makes it possible to upgrade.
 
I will be revisiting the driver code to figure out why I haven't been able to make it happy, the variant is not incredibly different from the normal device.

Nice chart!  So nice, in fact, that I will spare you the rms sermon. 
 

Hello, I can confirm that overlay directory was missing, there is a pull request that is going to be merged soon (https://github.com/armbian/build/pull/3558) to restore it.
 
About the kernel config option, it can be indeed done easily.

Dear all,
 
First post here
 
I just wanted to thank you for the up-to-date image you made for the pcDuino4 Nano (a.k.a the NanoPI M1):
 
https://armbian.hosthatch.com/archive/nanopim1/archive/
 
It's much better than the stock image provided my LinkSprite, based upon Debian 8 "Jessie":
 
https://www.linksprite.com/pcduino4-nano/
 
I only had one issue so far with your image, certainly related to the default overclocking at 1368 MHz, which didn't play well with the CPU intensive, NEON optimized tasks I threw at it (BOINC)
 
I lowered the frequency to 1296 MHz and it's been running stable for a couple of hours now
 
So thanks again and keep up the good work !
 
Best regards,
 
Magic Sam from the Open Pandora / Dragonbox Pyra community
 
https://www.openpandora.org/
https://pyra-handheld.com/boards/pages/pyra/

The "Invalid" tag is cancer.  That needs to be "Off-topic", "Out of scope", "needs clarification" or something else.
 
Honestly we are actively rebranding ourselves as a toxic community at a terrifying rate.

The "Invalid" tag is cancer.  That needs to be "Off-topic", "Out of scope", "needs clarification" or something else.
 
Honestly we are actively rebranding ourselves as a toxic community at a terrifying rate.

I guess I felt like that great discussion in rpardini's PR was sort of shut down prematurely.  Maybe the forum is a better place where we can take the long view over time and build more consensus about some of these bigger changes.
 
Here, everyone have a beer and relax, get into right frame of mind.   

https://drive.google.com/drive/folders/1YWMDbbx0p4dLPO3Mr3921vNay8l-_vHo?usp=sharing
 
This is a topic to discuss CSC Armbian support on the Avnet MicroZed board, and adding a similarly supported SoC family for the Xilinx Zynq. In terms of "interesting boards", the Zynq is a combination ARM/FPGA SoC that pairs a dual core Cortex A9 @ 667 MHz with a Artix-7 family FPGA fabric. In terms of performance, the A9's are nothing to write home about, but the FPGA fabric opens some rather interesting possibilities for those determined enough to use them.
 
For the unfamiliar, an FPGA (Field Programmable Gate Array) is a sort of reconfigurable logic. It allows one to have dynamic hardware components instead of static pieces selected by the board manufacturer. Want 100+ GPIO? Sure. A dozen serial ports? Alright. 37 I2C buses? You might need to share some interrupts, but I'm not aware of a specific reason that shouldn't work. Really, you're limited by pin count, FPGA fabric usage, and what you can express in Xilinx Vivado.
 
Be aware, if editing Device Trees puts you off, this is not the board for you. You will need to do substantially more to get anything significant working. If you do not have a copy of Vivado installed, you will not get far. Interested users should start with Xilinx/Avnet documentation or HERE.
 
Current development status:
MicroZed (7020) booting up, appears to be working fine CPU Frequency Scaling (333 or 667 MHz ) FPGA bitstream loading (See below gotchas) Onboard Gigabit Ethernet USB (See below gotchas) GPIO, including board heartbeat LED Things that aren't working:
DTB Overlays (seems to freeze board when enabled in u-boot config) PMOD connector (Didn't enable it in the Vivado, Design, FSBL, DTB, etc..) Current gotchas:
Zynq u-boot doesn't work like other boards. u-boot and the Zynq FSBL (First Stage Bootloader) get baked together into a file called "boot.bin" via a Xilinx program called "bootgen". This is not currently in the image, so are not able to modify this file on-board. The MicroZed 7010 and 7020 are different boards. The CPU is compatible, but the 7020 has a larger FPGA and access to more pins (eg - Bank 13 on the MicroZed schematics) One of the jobs of the FSBL is to configure the Zynq MIO (Multipurpose I/O). To a limited extent, this re-configures which CPU pins go where on the PMOD connector, sets pull-up or pull-down resistors, and does other things. I think it's possible to skip the FSBL entirely and go directly to u-boot, but am unsure how that's supposed to work in a general sense. The Avnet preset for the MicroZed board specifies the correct reset pin for the USB PHY, but Vivado is not currently using/respecting it. If you make a new design, and do not check that the USB0 reset is enabled on MIO7, and build your own FSBL, the onboard USB port will not be usable.  
 

I have a Tinkerboard 2, the only thing causing any issue is the use of a variant of the standard buck converters to power the big cores and the GPU.  I have not gotten this converter to operate properly using the (really ugly and hackish) mainline Linux driver.  Since the existing Mainline Linux driver is pretty much crap, it makes it very difficult to add the variant.
 
@JMCC a differentiating factor for the Tinker 2 includes it's power input/management, which is extremely robust (it can power all USB ports per specification, unlike any other SBC I am aware of save the Tinker Edge R) and its use of the newer revision RK3399 which supports 2.0 GHz with no overclock and uses less power overall.  The nanoPC T4 would be my only recommendation for an alternate that is currently supported due to its feature set and design.  Ah, it also has a socket for standard PCIe wifi modules, which makes it possible to upgrade.
 
I will be revisiting the driver code to figure out why I haven't been able to make it happy, the variant is not incredibly different from the normal device.

Hmm, The odroid-N1 is an RK3399 board, maybe that's what's killing the gpio library.  Or the header may be irrelevant, I honestly don't know. 
 
The GPIO on the Amlogic devices is quite a bit different.  I don't vary from the stock device tree most of the time, so other than the spidev I added it will reflect (assuming I read the schematic correctly, and it in turn was correct)
 

 
I've been meaning to do it for some time, but I'm just starting working on documenting some of the GPIO's and their various functions.  So, in the device tree if you enable UART A, you'd have the port you want.  Unfortunately my wizardry does not include device tree overlays yet, however this may be something that's ok out of the box if the vendor image has it configured.  (clarification:  I can make a static change to the device tree, however for these sorts of things dynamic changes via overlays is better)
 
It's also good to see @adafruit doesn't sleep either.  However, I will be going, back to paid work in 6 hours.

I have a Tinkerboard 2, the only thing causing any issue is the use of a variant of the standard buck converters to power the big cores and the GPU.  I have not gotten this converter to operate properly using the (really ugly and hackish) mainline Linux driver.  Since the existing Mainline Linux driver is pretty much crap, it makes it very difficult to add the variant.
 
@JMCC a differentiating factor for the Tinker 2 includes it's power input/management, which is extremely robust (it can power all USB ports per specification, unlike any other SBC I am aware of save the Tinker Edge R) and its use of the newer revision RK3399 which supports 2.0 GHz with no overclock and uses less power overall.  The nanoPC T4 would be my only recommendation for an alternate that is currently supported due to its feature set and design.  Ah, it also has a socket for standard PCIe wifi modules, which makes it possible to upgrade.
 
I will be revisiting the driver code to figure out why I haven't been able to make it happy, the variant is not incredibly different from the normal device.

Maybe, maybe not. If their CompaTability nonsense can simply be ignored, and the ARM cores are in control, then yes. If VC6 is running the show, it is the same. :-/

Sent from my Pixel using Tapatalk

An RPi is not

1) reliable
2) the most cost-effective
3) worth $35
4) worth any more discussion.

The position of this project stands, we will not support a failure prone, insecure, underperforming, inefficient, abysmally bandwidth throttled device. If an RPi 4 comes out that uses a sane bootloader and a useful SoC then this can be revisited.

Do not continue your personal argument with Tido; it is not value-added, and your positions add nothing other than conflict. Mostly because you have no facts or reason for your position, and instead of trying to formulate something approaching a case for support resort to ad hominem attacks and downright inaccuracies. This is an unofficial warning to stop harassing the team because you aren't getting your way. The next will be official.

Sent from my Pixel using Tapatalk

I am very impressed by how much feature we are getting... WOWIE
I don't know if anyone has said this to you but you are a legend!