Igor

Negative. Users don't need and should not change build script internals. When you do, also your script will not update anymore. Try to find reasoning for current situation, not adjusting documentation to the use case that will not be supported. At least not this way.

No. "rockchip.txt" defaults are automatically used if you build Orangepi 4. Defaults were not meant to be user changeable, but you can change them this generic way while building image or manually on the board. This is the same. Just u-boot, which is not Armbian - we only use it for our needs, you will not learn just in one year ... you will find many different approaches and implementations, many versions and hacks to the u-boot in the wild. Which leads to - not simple to answer. Isn't FAT something related to Windows?!?! No, there is no need for a FAT filesystem.

I think i read somewhere that this problem was fixed ... try with nightly builds (if they exists) or build image on your own. Worth trying.

Which are all unsupported. We take support a bit more serious. Most recent images there were updated in 2018, ours few months ago: https://mirrors.netix.net/armbian/dl/renegade/archive/ We just don't have this board in automated testing facility and there are no dedicated persons to have spare time & this board around to check in case of some board specific low-level troubles. Which do come around from time to time - which is for Linux normal MO.

Xunlong / Orangepi forked our build system and adjusted upon their needs & ideas. Documentations for their fork is different in several areas - that's all I know about.

If u-boot package is installed on the system -> nand-sata-install -> update bootloader + reboot.

It happens that I was fixing some other problem regarding A20 boards (our common problems) and I have checked if wireless is working ... bananapi:~:# iwconfig lo no wireless extensions. eth0 no wireless extensions. wlan0 IEEE 802.11 ESSID:"XXXXXXXXXXXXXXXXXXXX" Mode:Managed Frequency:2.437 GHz Access Point: XX:XX:XX:XX:XX:XX Bit Rate=65 Mb/s Tx-Power=31 dBm Retry short limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:on Link Quality=56/70 Signal level=-54 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 Full logs: http://ix.io/3rRp Hint: read information written for users at the download pages of Bananapi M1+.

@tgillett We will implement this workaround for now.

I just build Gnome image for N2 - except mouse cursor is changing to strange forms, otherwise ... works. Hirsute with 5.12.y kernel.

Just retry - from here everything looks ok: Another possible source of problem is that your system date and time is not set / set wrong.

This means some regression was introduced upstream. Nothing unusual in this world. Also possible that our patches are clashing with upstream changes ... If you seek images without support, you can just use images from our archive (below) and don't upgrade. That's the main reason why we have it.

I looked again, aptly is signing, but repository is unsigned. Just Bionic. Others are signed. No idea why ... Another workaround is upgrading to Focal.

ok. reverted https://github.com/armbian/build/commit/692717102be3d97cb6f783ad23586c44acaa7cb3

I would claim that its almost impossible ... but well, bugs are always possible even there where its "impossible" What would be possible is that patch was somehow present at the time kernel was built ... but history doesn't reveal that. Strange. We also were changing CI in past six months a lot (which indeed has signing keys and was not very well tested yet), where strange things could happen. If you move to latest nightly kernel (made with CI tooling) or manually kernel build, bug from this topic should not be present.

But our code base doesn't have this patch ?! Where did you find it?

Yes, this is our regular MO (if we want to provide features months ahead or fix bugs in ad-hoc manner) and we need to adjust code constantly. Sometimes this pull is well known / documented, clean or with our authored patches. Sometimes they are pulled from some 3rd party project such as Librelec or similar. Mainly for multimedia patches since we don't deal with this area much on our own. Sometimes our code works well, but got broken by upstream code change or just that implementation is done a little bit different. We are seeing that too. For this specific problem, can't tell without moving away from what I am doing and research. Which is not going to happen just like that. - you are saying Greg Kroah-Hartman team checks and tests every patch that lands into the Linux codebase? - our project is obviously not a professional venture, Linux kernel is Impossible to know for all chip variants. We can't test hardware we don't have. And even we would had hardware, our test system is too primitive. It lack few millions to get on the professional level. Testing on all possible wireless devices that are on the market on code change? Nice to have, but we are far away. Manual testing? Bad joke.

Telling you that asking us to work on your problems is waste of your time is real help. We don't have this issue - you do. I will help you, but I will not solve this problem for you. If you solve it for you, you solve it for others. This is what we do every day. We would accept your problem and solve it for everyone, but we have no resources. First, I don't work for you. Second, answering brainless facts consumes way less time, money and energy then spending days on debugging. In your interest. Third, 1000 other people that also have some issue are in the line before you. Will that prevent me to communicate on forums and will I move to work on (your) bugs instead? That would be a very nice joke. Isn't it clear that our project is 1/1000 too small and we are totally overloaded? After my response to you? Or is this a fact you ignore since you only care about solving your problem? But since we are not jumping from happiness that should be clear? Or not? What about things that works well? How much do you support that part? We have actually a problem that contribute way way way too much into the public code. Not the other way around. I wouldn't be so sure that this problem is that trivial as you think it is, but its on you to find out. I am highly concerned hw we (try to) support - onboard wireless - might have issues. This is Linux and you are saying what - Realtek? OMG Waiting for your merge requests. If you can't test on devices that are using this driver, ask on forum for help. Use this infrastructure.

Probably our repository has to be reindexed properly. Then it has to be distributed to the CDN. 24-48h is needed after its fixed. But ... I am currently too busy to check and fix this problem and we have no backup for this particular task. If 3rd party tooling is the cause of this problem, then I might need several days just to dig in and fix. I have no knowledge of Aptly which we use for repository management. And TBH no interest to learn its internals.

By who? Why would that be our problem? It's on you to research the topic (or hire someone to do that for you) and provide merge request, which needs to be tested on hardware that is equipped with the same chip: https://docs.armbian.com/Process_Contribute/ Since you don't support our project seriously, such support requests sounds more like a joke - its not personal - all similar sounds the same. We can't afford to hire help (your donations doesn't even pay for the servers you download from) while volunteers are full for several years in advance. So tell me how? Linux and surrounding tooling needs serious maintenance, development is constantly moving on and we - in common public code which we are not authors - find way more bugs that is possible to handle. We also developed a tool for finding them faster, which also added to maintaining expenses, ... but solving what is found - with what? When? Hardware we are dealing with (3rd party usb stuff was never a part of this) is far away from perfect functioning. For me, for people on the project, time is totally critical - i / we also have a family, two kids and a job that pays the bills - why fixing bugs for you and all Linux distributions on request and 100% on our private expense? Also there are 1000 people before you reported "something is wrong with their system". We are donating 50-80h every day, more we can't. Even you asked politely and do a part of the needed work. Most of people just demand ...

You will probably need to access u-boot via serial console if that doesn't work.

By hitting CTRL C or spacebar ? Via serial console or HDMI and usb keyboard?

Most likely reason: Edit: I tested manually on beta repository by changing nothing - and index is signed.

Boot delay is controlled by framework.

Congratulations You won't believe - I have two small kids, a wife, a cat (ok, this one is on low maintenance), a full time job and a full time project to maintain, I don't have time to test this even we are providing this software for you and I had this hardware. Alternative is to hire you help, but since you are not interested, this is not going to happen.

Users and developers perception can be far apart which is one source of communication troubles. We could explain politely on each request, how things are, but that is just far more expensive. Coaching and teaching is yet another big chunk of pure waste of our time which we have to avoid just to survive. (Sadly) Cold answer is saving us a lot of time and in most of cases stops river of additional questions I have absolutely no wish to deal with, certainly not on my private time expense. The problem is, time lost on that is extreme and it can easily cost more time than my daily job. A few days / weeks later, question is repeated. From time to time a psycho user emerges and problem of time waste is escalated. All this generate pressure on people that generate value, people that needs to be protected from constant abuse of attention from people that have zero perception on how much work, time and cache expense, some problem needs. We have an early design of solution for forum reorganisation (making distance based on users experience, so users will have certain areas read only access unless proven) on certain user experience levels, to minimize clashes, but its yet again a job that waits a dedicated person to coordinate that change. A project manager(s) and HR personality would be also nice to have around. But we don't have. We only have a few people that move this project forward and I cry for help. For them and for you. And at the end - it is you / users who need help. As most of the time is eaten on helping users. Still. Perhaps we need to scale down this whole project before accepting new help. But this again can only be done on users expense. Yes, we can only expect seniors involvement in this field. If newbie is willing to help, there is almost nothing we can do about. We don't have any person that would have enough time to work with that person and bring it up to the levels we need help. I am a bit younger than you, having a full time job and small kids. I am already having a feeling to neglect them. Other people are in similar situation. RK3399 boards are pretty matured from today's perspective. There are many vendors that are using it and chip can't be wired in many ways. You were spared most of the suffering. Testing features - we must be focused on automated testings. So we can save some time for spending time with our families - our free time is usually a constant - and also to have an option to answer users questions. We - not just me - are deeply involved in making those boards usable for quite some time now (official since 2013, while many people are deeply involved since early days of Linux). It eats a lot of precious spare time which I simply won't allow to exchange for some bullshitting or demanding extra free services, which can be found daily on forums.