TRS-80

I think a lot of us are in this boat.  I am even in that boat.
 
I can't speak for Igor and the other guys, but my sense is that, for people who step up and try to help out, I think they do try and make a little time.  I would not expect a lot, they are still very busy, etc.  However, the needle may move from 'no time for anything' to 'maybe I can make a few minutes here and there.'
 
I would encourage everyone who is around the periphery like this to hang around on the forums and/or IRC.  Come say hello and just idle when you are at your battle station.    There are also a few guys who are active on IRC in particular.  You can ask questions in there and some times get answers.  And some times not, but don't take it to heart.  And it may take time, some times people answer hours later in IRC.  There are also the forums, where you may have better luck.
 
Even at my low level of knowledge, I have been able to answer some people's questions some times.  So please, do not be afraid to try and help out.
 
I would encourage more experienced members of the community to also help in answering questions, on the forums as well as IRC.  Every single question answered takes a little bit of burden off developers.
 
Ideally we foster a community where power users and other interested parties can help each other learn and figure things out.  I do have some more resources I would like to add to the docs as well about a few things.
 
 
It's never too late, newfriend.    Welcome aboard, and thanks!  I will add you to the list.  Some of above can apply to you, too it sounds like (and many others). 
 
---
 
@everyone,
 
I have been thinking, just because new names are on the list does not necessarily mean that everything will be OK.  Several people are new to the project, I have not seen them in IRC (in fairness, I'm not always on lately), who knows if things work out or not in the end.  So please, if you are considering it, please throw your hat in the ring.  Worst case is we have 2-3 maintainers for a given board.  In which case the work can be done in a collaborative manner.  If someone disappears due to life for some weeks, it would not be the end of the world.  You get the picture. 
 
Thanks again to everyone who is stepping up, it is greatly appreciated!
 
 
                                 
 
 
 

https://github.com/armbian/build/pull/3504
this is my first pull request ever, please check.

No, because I don't care about Apple products.

sorry, no. I can't really say or fix anything about 21.08.x at this time. It's just too old of a codebase, and using vendor uboot, so with no future.
Personally I boot the N2+ from SPI to USB3 pendrive (not cabled!) and have decent experience with 22.02, but can't say much about the eMMC + SD combo. 
22.02 includes mainline uboot and kernel fixes for N2 which are essential to any sanity, but might still have some rough edges. Try the RC's!
If you had working 21.08 at any point you're just lucky: I never had a stable N2 on 21.08, literally problems everywhere.
Good luck!
 
 

I forgot to get back here sooner.
 
It turns out, I didn't need to mess with kernels at all.
 
I just needed to edit boot.ini, and change the variable cs2enable from false to true. This causes a few overlay files to be loaded and from there, the display and fan work fine.

Hello :-)
Tried to update my cubietruck to new version and got same fault.
Last working versions for my Cubietruck are:
 
Armbian_20.11_Cubietruck_bullseye_current_5.8.16
or
Armbian_20.11_Cubietruck_buster_current_5.8.16
 
NOT working are:
Armbian_20.11.3_Cubietruck_buster_current_5.9.14
Armbian_20.11.6_Cubietruck_buster_current_5.10.4
Armbian_21.08.1_Cubietruck_bullseye_current_5.10.60
Armbian_21.08.1_Cubietruck_focal_current_5.10.60_xfce_desktop
Armbian_21.08.1_Cubietruck_hirsute_edge_5.13.12
 
Hangs for long time and no login possible. Searched for the boot messages in log files on SD-card but wasn't... guess they was in RAM only.
So I made a video from boot log and then picked some frames ...
 
20.11.3 : After message
 [FAILED] Failed to start Create System Users.
[ 12.5...] Internal error: Oops: 5 [#1] SMP THUMB2
[ 12.6...] Modules linked in: .... realtek[E]    <<< Don't know if that [E] shows the problem?
 
20.11.6 : After message
[ OK ] Started Load/Save RF Kill Switch Status.
[  12.5...] Internal error... <<< message like in 20.11.3 above
 
21.08.1 :
[ 12.6... ] Unable to handle kernel NULL pointer dereference at virtual address 00000194
[ 12.6...] pgd = 97233e30
[ 12.6...] [00000194] *pgd=00000000
followed by Internal error: Oops ...
 
Could not attach screenshots so I uploaded to a website. Here links to bootlog-screenshots...
 
https://bockmuehle.lima-city.de/cubietruck/armbian-20.11.3_buster-cubietruck-crash-1.png
https://bockmuehle.lima-city.de/cubietruck/armbian-20.11.3_buster-cubietruck-crash-2.png
https://bockmuehle.lima-city.de/cubietruck/armbian-20.11.3_buster-cubietruck-crash-3.png
 
https://bockmuehle.lima-city.de/cubietruck/armbian-20.11.6_buster-cubietruck-crash-1.png
https://bockmuehle.lima-city.de/cubietruck/armbian-20.11.6_buster-cubietruck-crash-2.png
https://bockmuehle.lima-city.de/cubietruck/armbian-20.11.6_buster-cubietruck-crash-3.png
https://bockmuehle.lima-city.de/cubietruck/armbian-20.11.6_buster-cubietruck-crash-4.png
 
https://bockmuehle.lima-city.de/cubietruck/armbian-21.08.1_buster-cubietruck-crash-3.png

Necroposting, I know, but just in case someone else googles up this thread as I did.
The MPI3508 3.5" screen is cheap and sold a ton apparently.
 
So the problem is, the display is actually 480x320 but identifies itself as 1024x768 (!), which is not correct as size and not even as aspect ratio (4:3 vs. actual 3:2)
 
Trying to force 480x320 in armbianEnv.txt does not work, the display shows nothing; probably there are no proper timings in the kernel/DTB/whatever for such low an HDMI resolution.
 
So the trick is using 720x480, which is 1.5x the actual resolution. The aspect ratio is correct, the timings are there, and after all it's even quite readable.
 
So in /boot/armbianEnv.txt add:
    extraargs=video=HDMI-A-1:720x480@60
    disp_mode=720x480
 
and then recompile boot.scr:
mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr
 
Display should run fine.
 
fbset reports:
 
mode "720x480"
    geometry 720 480 720 480 32
    timings 0 0 0 0 0 0 0
    accel true
    rgba 8/16,8/8,8/0,0/0
endmode
 
which may be added to /etc/fb.modes
 
Hope this helps, despite not being optimal.

Instead of manipulating the main device tree, enabling i2s@1c22000 should be possible via overlay as well, like:
    fragment@0 {         target-path = "/soc/i2s@1c22000";         __overlay__ {             status = "okay";         };     };  
Hence the whole overlay:
/dts-v1/; /plugin/; / {     compatible = "allwinner,sun8i-h3";     fragment@0 {         target-path = "/soc/i2s@1c22000";         __overlay__ {             status = "okay";         };     };     fragment@1 {          target-path = "/";          __overlay__ {              pcm5102a: pcm5102a {                 #sound-dai-cells = <0>;                 compatible = "ti,pcm5102a";                 pcm510x,format = "i2s";             };         };      };     fragment@2 {         target = <&i2s0>;         __overlay__ {             status = "okay";             pinctrl-0 = <&i2s0_pins>;             sound-dai = <&pcm5102a>;             pinctrl-names = "default";         };     };     fragment@3 {         target-path = "/";         __overlay__ {             sound_i2s {                 compatible = "simple-audio-card";                 simple-audio-card,name = "I2S-master";                 simple-audio-card,mclk-fs = <256>;                 simple-audio-card,format = "i2s";                 status = "okay";                 simple-audio-card,cpu {                     sound-dai = <&i2s0>;                 };                 simple-audio-card,codec {                     sound-dai = <&pcm5102a>;                 };             };         };     }; };
I will verify that the path /soc/i2s@1c22000 is correct, I guess there is a symbol for this as well, but obviously it is not <&i2s0>.

Besides freedom reasons, there are user/support and practical (limited) resource ones, too.  But there are 5 pages in this thread about that already (but see first page for some interesting historical perspective however).  We are after all just few guys and RPi have tons of resources already.  There are 100+ other (often more interesting) boards out there not seeing anywhere near that attention.  So we try to give attention to those otherwise orphaned ones.  Maybe we should rename the project to SBC orphanage, or use that as a subtitle.  
 
Competition and diversity are good for keeping corporations on their toes and innovating.
 
In fact, a lot of early criticisms of RPi 2/3 hardware have been fixed by now in newer versions.  Would that have happened if no one else were making and developing other SBC?  I think probably not.  Look at current web browser situation which is a nightmare due to no real competition.  Or places which have only one ISP (cough Comcast cough).  Many examples.
 
 
I guess it's like the debate between Free Software and 'Open Source' approaches.  I am in favor of the former but some times I wonder.  Hard line stance or 'swim with the flow'?  In fact Debian themselves are somewhere in between (allowing non-free and contrib repos, just not by default).
 
Also as you said above:
 
 
Some times I wonder, too.  I guess we will never know?
 
Allwinner is a sort of similar example, those devices became well supported in Linux not because of Allwinner (who were (are still?) famously hostile towards GPL) but they were sold so inexpensively they got into hands of a lot of hackers and ended up with good support in spite of them.  I see a sort of similar thing going on with PinePhone lately (as compared to Librem 5).[0]
 
Anyway, it's Friday afternoon, let's grab a beer. 
 
[0] PINE64 are no where near flaunting GPL like Allwinner, I was just contrasting their 'sell many cheap units but hire no devs' approach to that of Purism's, the latter who more explicitly promote freedom and mainlining as a feature (but at higher cost).

I received at least one PM so far that I did not know the answer to.
 
So, rather than all of us spend a lot of effort duplicating info, I thought maybe good idea to compile these in one place.  Especially as we have an influx of new Board Maintainers at the moment.
 
I also encourage people to stop by IRC and say hello.  I shall also endeavor to copy the most useful bits from IRC into this thread as they come up.  Maybe later can be distilled even further into some docs page or ...?  Anyway...
 
So, first up:
 
Q: How /what checks/tests to run?
 
A: OK, I guess I thought armbian/autotests was more about that (long in development hardware), however looking again now it seems it's actually just a script which can be run on its own, just directly on SBC (even without that test rig).  Amirite?

I had started to remove the automatic generation of PDF from documentation, but now I am starting to wonder if that was actually a good idea. 
 
In case you did not know, in addition to https://docs.armbian.com/ you can also download a PDF copy of same from here.
 
Maybe this is helpful for people who are offline while working on their SBC?
 
Anyway, please speak up if you are using this!
 
Related Issue: 96 and PRs: 176, 177.

@halfpipe @pista,
 
Please share whatever you learn publicly in the forum for the benefit of all (as opposed to PM).  This makes it easier for other people who come along after you searching for answers, too.
 
Thanks.

I wonder if this may help from a u-boot cheat sheet I found at http://nerveware.org/u-boot-cheat-sheet/1.html
 
Boot into single user mode Single user mode is mostly used to reset forgotten passwords, but the command below might be usefull for debug purposes as well (omit init). U-Boot > setenv bootargs "${bootargs} reboot=cold,hard emergency init=/bin/sh" For embedded devices, the root partition is frequently mounted read only. $ mount -t proc none /proc $ mount -o remount,rw / $ passwd root Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully $ sync  
I am guessing that to do this you will need to connect a RS232 to TTL UART board to the debug serial port on the board to get to the U-Boot command prompt. I've yet tried this method on my board, but I have got myself to the U-Boot>_ prompt.

That's what I would do. If I found something then I certainly would contribute back to Armbian. The more I learn and remember (and getting helped along the way) then I can return the favour and help others with what I've learned.  I think I'll try get involved more with the Forums as so far, at least for me, the Armbian Distro on the BananaPi Pro is rock-solid reliable.
 
I now brave applying the compiled 22.02.0 version to the BPi Pro and, yes, I've performed a sector-by-sector backup of the present stable installation.  (Wish me luck....)
 
ADDITION: YAY! Kernel 5.10.95-sunix installed and working.  :-)

Hi Pascal,
 
welcome to this forum.
 
Do you still have problems finding some access points?
 
Best,
benjamin

Sorry for short notice, but if any of you guys see this in time please join release meeting in a few hours:
You are welcome to come and just see how things work.
 
Besides that, I would encourage to idle in IRC and help each other out, ask questions, solve problems together, etc.  And/or on the forums.

QUICK UPDATE:  I am NOW looking for ONLY one Helios64 (either full system or just the board).

The reason is, that I got an explanation from Igor, that hardware donations do NOT make sense (they are deprecated)  since they are not needed - hardware is the cheapest part of the dev-process, and the devs have enough hardware.
So the ONLY thing what would help the Armbian project would be
a.) person-power, i.e., help for keeping the project going (development, infrastructure, build-server) OR
b.) money donations.
 
That's why I am NOW looking for ONLY for a single Helios64 (full system or just the board) -  when it is located in Europe. It's for my personal use and as a backup.
@planned donation; Since I have neither the time nor the expertise to participate in development - I will make a single donation of 300€ (done) - which was the worth of the hardware.
I will consider a subscription if it is possible to donate anonymously

BUT STILL - if you are located in Europe and have a helio64 you want to sell - please contact me.
 
Thank you.
 

I'll start by saying I don't own the board, but as this has come up and seems to be a problem across many boards using the same SoC and bits, it would appear on its face that the fix is probably generally the same across them all. Give or take a few differences?
 
My github reference to the issue: https://github.com/armbian/build/issues/1352#issuecomment-952077351
 
I've included two patches you could test that I made for 5.10.y as that appears to be the kernel ur using.
 
One thing I do not mention in the github issue is I also include the following to /etc/modules
# /etc/modules: kernel modules to load at boot time. # # This file contains the names of kernel modules that should be loaded # at boot time, one per line. Lines beginning with "#" are ignored. bluetooth hidp rfcomm bnep hci_uart  
 
002-sun50i-h5-orangepi-zero-plus2-rfkill-gpio.patch 001-sun50i-h5-orangepi-zero-plus2-bluetooth-support.patch

HI! @SteeMan
 
I work with development for ARM-based products 
 
The Armbian community helped me a lot with my beginning in this area. That's why I want to help others as well 
 
So, I'm waiting for my order to arrive. It's two boxes with both Allwinner processors (H3 and H6)
 
And yeah! I accept the challenge
I'll have more material to share soon 
thank you!

@Clonazepunk Welcome to armbian.  I was just reading your recent posts and it sounds like you have some good technical skills and a desire to help others.  A combination that is in limited supply.  As you are new to armbian, if there is anything I can do to help your learning curve please reach out to me.  The TV Box community needs people like you willing to help others.  It seems that you have an interest in both rockchip and allwinner TV boxes.  While Jock and other provide great support for rockchip there really isn't anyone currently supporting allwinner.  So if you are looking for a challenge...
Again if you have any questions for me please reach out to me either in the forums or through PM.

Hi thanks for the excellent job with armbian. I don't have much experience but I want to learn and colaborate as board maintainer.
 
My board is an orangepipc.
github: https://github.com/lbmendes

I can't be 100% sure, but I believe I saw a pull request for this some time ago where some one removed some things related to the reboot issue. I haven't scanned through the patch set as of late, but in my testing the following is needed.
 
Need to revert:
drivers/gpu/drm/meson/meson_drv.c
https://github.com/pyavitz/debian-image-builder/blob/feature/patches/amlogic/odroid/002-linux-odroid-patch-set.patch#L524
https://github.com/pyavitz/debian-image-builder/blob/feature/patches/amlogic/odroid/002-linux-odroid-patch-set.patch#L542
 
Add Odroid reboot:
https://github.com/pyavitz/debian-image-builder/blob/feature/patches/amlogic/odroid/002-linux-odroid-patch-set.patch#L2323
https://github.com/pyavitz/debian-image-builder/blob/feature/patches/amlogic/odroid/002-linux-odroid-patch-set.patch#L2533
 
If you review the pull request, you can see where the revert and odroid power reset patch was removed: https://github.com/armbian/build/pull/3154/files
 
As for mainline u-boot the only thing of real importance is the following revert: https://github.com/armbian/build/pull/3154/files#diff-65100acf19e202ac3f3980da554c205752ea3c67d08fc4a3b445d4397189d12fR36
 
With out it, the boards "especially the N2/+ will kernel panic, as the reserved memory "CMA pool won't be set correctly".  So the patch forces the boards to be marked nomap, hence populated after uboot hands off to the kernel.
 

The -c was there before. It's yelling about the extra file on the end which isn't a .sha file ...
 
https://github.com/armbian/documentation/pull/160

Some Helios64 had issues with CPU freezes or other instabilities. If you buy one you should make sure that you can give it back if it is one of those.
 
Cheers
ebin-dev
 

The issue is fixed. ixgbe driver is added to armbian since commit 29415e0a417222ad533814b12283cbf9c0387562.
To get ixgbe on Armbian Focal (kernel 5.10.y), a user must install updated linux-image and linux-dtb packages. Grab updates here: https://github.com/armbian/build/suites/4422190367/artifacts/116973215