gounthar reacted to NicoD in A SBC for computing - your thoughts
I just want 32 N1 cores. No need for any other I/O than a Gbit ethernet port.
More would be nice. My M4V2/N2+ do everything I need. Just for rendering and building I can use more performance. Being able to do these jobs on a dedicated device would be nice.
Tho a workstation with 32 N1 cores is more awesome.
gounthar reacted to Werner in [Invalid] - nodejs 14 under Armbian 21.02.3 Buster installieren
Your issue report is not a valid bug report per the Armbian bug reporting instructions (https://www.armbian.com/bugs). With limited resources the Armbian project is only able to spend time on issues where all the requested information has been provided and for only the boards/images/software that are supported. Your report is invalid for one or more of the following reasons (non-exhaustive list):
it is for an unsupported board or image (CSC/EOS/WIP/edge) it is for software that is not supported (such as userspace modules installed on top of the core operating system) it has been logged in the wrong forum (for example requests for help that are not actual bug reports) it lacks requested data (armbianmonitor output) it could have been easily solved by a quick search and/or reading documentation
Please review what you have submitted and the bug logging instructions (https://www.armbian.com/bugs) and either add the required information or open a new topic in the correct forum (such as Common issues / peer to peer technical support or General chit chat)
gounthar reacted to kampff in NanoPC-T4 + EdgeTPU (PCIe M.2)
Hi Armbian Community,
I am trying to get the Coral/Google NPU (M.2 PCIe key) to work with the NanoPC-T4. Without success.
I built Armbian with linux headers (5.4.48) and was able to apt install the gasket-dkms package. (The EdgeTPU requires Google's Gasket and Apex drivers to be built as modules with DKMS, and thus requires the linux headers to be installed at /usr/src). Also, there was no conflicting Gasket or Apex module in the Armbian release prior to install (an issue found by other EdgeTPU systems on other distros).
My problem, I believe, has to do with the NanoPC-T4's PCIe. I have tried many different kernels (FriendlyElec's Core/Desktop/Buildroot releases using Rockchip's 4.4.179 kernel as well as various Armbian), and every time PCIe link training times out as follows:
[ 3.161132] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout!
[ 3.161214] rockchip-pcie: probe of f8000000.pcie failed with error -110
I am currently at a loss for what to try next. If anyone has any ideas, then I would be forever grateful and enthusiastic to help debug and test.
Here is the full u-boot debug and kernel dmesg output for the Armbian build with Gasket/Apex modules installed (albeit never probed):
gounthar reacted to SteeMan in A SBC for computing - your thoughts
When designing a good sbc for general compute/server tasks I think you need a set of features that enable both a 'desktop' as well as 'server rack' deployment. The reason for this is the evaluation process someone will likely undertake in order to buy into the boards features. No one is going to buy 32 boards for a 'server rack' deployment as the first purchase. Instead they are likely to purchase one or a few to evaluate first. That evaluation is not going to happen in a rack mount, but instead will happen on a desktop. Once someone is comfortable that the base board works for their basic needs (i.e. the software and general hardware works), then they will explore the 'server rack' deployment options as they plan to scale a use of the board.
In my opinion therefore you need to make sure you have the features necessary to have a good evaluation experience on the desktop for the board ultimately to be successfully purchased in larger quantities for server work. One example of this is an hdmi port. While an hdmi port is completely useless in a server deployment, it can be quite useful during board evaluation on a desktop. Another example is cooling as mentioned in the above posts. I think you need to have good thermal design for both deployment scenarios (both as a desktop board and in a server rack mount), which might require different heat dissipation strategies for the different environments. Finally POE while likely unnecessary for a desktop evaluation is critical for a server deployment.
My ideal feature list would be:
1gbit POE ethernet port
32GB emmc (or more optional)
good external storage options (m.2 or other)
2 or more usb ports (at least one being usb3)
power port for non POE usage
optional case for desktop use with good thermals
optional rack mount with good thermals
The two things I think it shouldn't have:
- no wifi/bluetooth
The reason I say these are not desired is that good wireless (good antenna's, good software support) is difficult to design into a board, it isn't needed in the server rack case and can be accomplished better with a usb addon for the desktop case without incurring the added cost to the base board.
- no SD card
The reason I wouldn't include an sd card slot is if emmc is standard, that will be the preferred deployment storage media. You only need another option to install/update the internal emmc and usb should be sufficient for that. The sd support then just becomes an added cost with no real long term need. It does require that booting from usb be well supported by the firmware.
Such a board would span a lot of use cases from general purpose single desktop use case to hundreds of boards deployed in dense rack configurations.
My personal experience is that I try things out first by evaluating one of something, then scale up to a few, and ultimately more as each step of the evaluation process shows the product is capable of the next deployment step.
Finally I'll mention price. In my opinion you likely need the above described board at a price point no more than a RaspPi. Given the large ecosystem and mind share built around that platform, and it is already capable of doing the above (although not well in many respects), you can't have something like this be at a 'high end' premium price point and expect it to be successful. Price will to an extent drive the evaluation process. If the price is considered too high, then people won't even start the evaluating, they will just stick with what the everyone else uses.
gounthar got a reaction from Werner in A SBC for computing - your thoughts
No WiFi, no SDCard, M.2 socket, eMMC, SPI Flash, USB-C (power plus host), 4GB RAM, big low profile heatsink, RTC, and GPIO with I2C, SPI, and pins with USB. As small and low height as possible.
Options would be NPU, more RAM, CSI and of course a SOM instead of the whole SBC.
gounthar reacted to arox in A SBC for computing - your thoughts
Many seems to think that theirs has to be very long and powerful (if you understand what I mean). In fact, a well designed enclosure can assume this function. And in any case the quality of the thermal interface is more important than anything else.
gounthar reacted to lucky62 in Device tree translation
I am thinking about automatic conversion of DTB extracted from Android firmware to DTB usable by Armbian (linux).
I am reading the docs about the DT but still I have no clear picture what is required to do this.
From the definition, the DT should be OS independent, so why the Android DTB cannot be used directly by Armbian/linux?
Currently I have in my mind only two things:
DTB can be older and not fit to the current standards Device names/types (used in compatible=) may be different in linux and thus not recognized Or am I wrong?...
This is new area for me, so any comments are welcome..
gounthar reacted to XFer012 in OrangePi Zero2 - Allwinner H616
Ok, so let's see the steps I followed.
1. Installed Armbian Unstable for OrangePi Zero2:
2. Forced ethernet at 100 mbit/s, otherwise it did not work: added in /etc/rc.local
ethtool -s eth0 speed 100 duplex full autoneg off
3. Downloaded hexdump's precompiled kernel (derived from jernej's 5.11.0rc1 kernel):
4. Extracted the various parts and fixed the symlinks:
Image -> Image-5.11.0-rc1-stb-616+
uInitrd -> uInitrd-5.11.0-rc1-stb-616+
dtb -> dtb-5.11.0-rc1-stb-616+
5. Inside dtb-5.11.0-rc1-stb-616+, created a new folder "allwinner" and moved the 3 .dtb there; otherwise, initramfs would not find them
6. Rebooted. Voilà, we now have a working mainline-ish kernel (patched 5.11.0rc1) with USB support!
[ 57.289791] usb 2-1: new high-speed USB device number 2 using ehci-platform [ 57.454110] usb-storage 2-1:1.0: USB Mass Storage device detected [ 57.454976] scsi host0: usb-storage 2-1:1.0 [ 59.122397] scsi 0:0:0:0: Direct-Access Lexar USB Flash Drive 1100 PQ: 0 ANSI: 6 [ 59.124408] sd 0:0:0:0: [sda] 125038592 512-byte logical blocks: (64.0 GB/59.6 GiB) [ 59.125522] sd 0:0:0:0: [sda] Write Protect is off [ 59.125549] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00 [ 59.126563] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 59.163290] sda: sda1 sda2 [ 59.168389] sd 0:0:0:0: [sda] Attached SCSI removable disk
gounthar reacted to NicoD in OrangePi Zero2 - Allwinner H616
You've been brave, but surrender, never
A bit a pity there's not more interest in this board. And I've not seen any other H616 SBCs coming.
Their Orange(Armbian) images do seem ok. I wonder if we could not learn anything from their script/builds.
They've copied Armbian, maybe Armbian should copy them now
I don't know. Maybe this one should be a pass. Is the effort supporting it worth it? Tho the board is good for some use cases.
gounthar reacted to NicoD in Video : Running Debian Buster on the Odroid Go Super and review of the hardware
I recently bought the Odroid Go Super. It is a great handheld for emulation gaming. But that isn't the main reason why I bought it.
It can also run Linux, tho not Armbian.
In this video I show how I use Debian Buster from Meveric on the Odroid Go Super and I also review the hardware. Greetings.
gounthar reacted to hexdump in Jetson Nano
just a little update: i got the open source nouveau gpu driver working with the mainline kernel finally by using a self compiled xorg server from the latest sources (required - see: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3505), a self compiled mesa 21.0.1 (not sure if this is really required) and the "nouveau.modeset=1" kernel cmdline parameter - what is nice is that it is opengl 4.3
so far the good part, the bad part is that it is extremely slow (glmark2 score of 68) as it is clocked at the lowest gpu frequency by default and trying to increase the gpu frequency via /sys/kernel/debug/dri/128/pstate seems to make the system quite unstable or quickly hangs it (maybe my power supply - 5.1v/3a - is not powerful enough?)
i'm also able to run a wayfire wayland session using the nouveau gpu driver, but it shows quite a few graphical artifacts when scrolling in a terminal or doing other activities - glmark2 score here is 83, but its also for lima or panfrost higher in wayland/wayfire than in xorg/xfce
all in all it looks like the quality of the open source nouveau driver on the jetson nano (maybe even in general?) is not really the best and as it looks to me far behind the quality of the lima and panfrost open source drivers for the mali gpus in other socs
gounthar reacted to Werner in OrangePi Zero2 - Allwinner H616
Before complaining about an issue read this!
tl;dr: Put your Zero2 and/or any other H616 based device on the shelf and WAIT for proper support to come. And no. There is no ETA. Assuming usable state end 2021/beginning 2022.
Software support is still work in progress and under heavy development. Provided preview images can break any time. Do not report this, we are aware of that and can/will not help you with that if you are not willing to investigate and research by yourself.
Feel free to join fellow developers to their efforts to create proper software support. But don't waste our time with complains. Thank you!
I started to play with this board and obviously failed miserably creating a basic Armbian integration.
Anyway. These are the information I collected so far:
dtb extraction from Xulong image: https://pastebin.com/raw/Uni2JzBF
orangepimonitor 🙄 http://ix.io/2FM0
root@orangepizero2:/etc/apt# lsmod Module Size Used by zram 36864 2 sprdwl_ng 438272 0 sprdbt_tty 36864 2 uwe5622_bsp_sdio 294912 2 sprdbt_tty,sprdwl_ng
kernel config: https://pastebin.com/raw/e2jTTZ7A
gounthar reacted to NicoD in Station P2 looking good
Here a YT video about the new Station P2.
I love the design. SATA and NVMe now fit in the case. A bit more usb is great. Dual Gbit ethernet, wifi 6 and up to 8GB ram. RK3568.
I hope they'll also make an rk3588 model.I like their metal cases a lot.
gounthar reacted to balbes150 in Board Bring Up Station P1 rk3399, M1 rk3328
Update to version 20210319. Using kernel 5.10.24. Added support for Firefly-rk3399 in station-p1 images (for proper operation, you need to configure DTB in extlinux.conf). With the correct DTB setup, the HDMI audio LAN WiFi BT works in kernel 5.10. In kernel 4.4 worck remote control and analog sound.
gounthar reacted to PatM in First Panfrost enabled desktop builds
I am running the latest Armbian 21.02.3 on two NanoPCT4s.
Thanks to everyone for this. I didnt think I would see this performance on this device.
But here it is and I see Armbian is getting good notice for this.
I dont know how they did it but these devices are running very well.
I am a little tired this week so I dont have any technical details.
I want to just ramble (opinionate) on how nice this is and what I like about it.
I am running standard Focal Gnome Desktop from Armbian Download.
I just disable the pwm-fan module and run hot.
As long as I dont make -j6 I can avoid meltdowns.
I run Firefox and Microsoft VSCode. I run a complex desktop and my
standard install involves a day of burnin compilation.
I can run Firefox videos and Microsoft Code.
By the way Code can now be downloaded direct from Microsoft.
but really I dont have much time considering I do more and more C/C++]
and use Python as scripting language for C. I compile Sage Math 9.2
and that will halt this machine at make -j6 and no fan.
with fan, no problem. but make -j3 works OK with no fan.
After compiling these little ARM devices run SageManifolds doing complex
Jupyter Lab interactions. Pretty slick.
So I think this is a wonderful desktop.
I know the Gnome people own GItHub and Microsoft
TypeScript backended on GitHub integrated with the wonderful
Microsoft Code is a great desktop that Armbian is Smart to invest in.
gounthar reacted to rdeyes in OV5640 device tree overlay for OrangePi One H3
I think, there are two possibilities:
1. Your overlay is compiled, but not loaded. This may happen, because it tries to access nodes, that are not described. Neither within itself, nor within the device tree.
To check, whether it is loaded, you should inspect '/proc/device-tree'. The best way to start is
$ ls /proc/device-tree/__symbols__/ And there must be an 'i2c2' file, containing a string path to dt-node (in my case '/soc/i2c@1c2b400').
So now, you need to check out this node. Like I do on my system (+ rreigner's overlay with my completion)
$ ls /proc/device-tree/soc/i2c@1c2b400/ '#address-cells' camera@3c clocks compatible interrupts name phandle pinctrl-0 pinctrl-names reg resets '#size-cells' status $ cat /proc/device-tree/soc/i2c@1c2b400/status okay $ cat /proc/device-tree/soc/i2c@1c2b400/reg | xxd 00000000: 01c2 b400 0000 0400 ........ $ ls /proc/device-tree/soc/i2c@1c2b400/camera@3c/ AVDD-supply clock-names clocks compatible DOVDD-supply DVDD-supply name phandle pinctrl-0 pinctrl-names port powerdown-gpios reg reset-gpios Some files may contain gibberish, that may be resolved by piping them to xxd.
2. If the previous test is fine (status contains "okay" and camera@3c child node present), your i2c2 bus may just not end up as /dev/i2c-2! (I have this situation on my OrangePi-PC.)
So it is present and works fine, but it's adapter has a different number and a different name. You just need to know it and pass it's "nickname" to i2c-detect.
So you can list all i2c adapters on your system like this:
$ ls /dev/i2c-* /dev/i2c-0 /dev/i2c-1 /dev/i2c-2
And you can access their system interface via '/sys/class/':
$ ls /sys/class/i2c-adapter/ i2c-0 i2c-1 i2c-2 $ ls -l /sys/class/i2c-adapter/i2c-*/of_node lrwxrwxrwx 1 root root 0 Mar 17 14:08 /sys/class/i2c-adapter/i2c-1/of_node -> ../../../../../firmware/devicetree/base/soc/i2c@1c2b400 lrwxrwxrwx 1 root root 0 Mar 17 14:09 /sys/class/i2c-adapter/i2c-2/of_node -> ../../../../../firmware/devicetree/base/soc/i2c@1f02400 So, most of i2c adapters have of_node within their system interface, which is a symlink to their dt-node. Remember, how my i2c2 dt-node was called? '/soc/i2c@1c2b400'. And this is an of_node of i2c-1 adapter!
So to probe my i2c2 I need to tell i2cdetect to check '/dev/i2c-1':
# i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- And see camera activity on address 3c, as expected.
Hope, this helps
Upd. Now since @srinath edited comment, mine looks not related.