TRS-80

It has always been my understanding that ssh is enabled 'out of the box' in Armbian. So something must have slipped through the cracks here. I see this post is currently in 'community/unmaintained' section, but as of this writing I am showing Odroid C2 as a Supported device, with a maintainer. Perhaps @teknoid can shed some light? If they do not reply, and/or you find a solution on your own, please submit a patch to the build framework to fix it for everyone else with this board. It's probably a minor configuration issue.

Maybe comms (serial settings) issue, but more likely needs a different device tree would be my guess. At any rate, this is not beginner level hacking IMHO.

Patches would be greatly welcomed.

Good point which probably bears repeating. However, in the first case, I think that 'Digital Restrictions Management' is a more accurate term. You could even say DRM is defective by design.

I have got Armbian working, on SD card and/or eMMC installed images, without needing to open the case. Detailed instructions (and some detailed investigative reasoning along the way) can be found in a new thread I started a few days ago: https://forum.armbian.com/topic/27598-getting-armbian-working-on-second-batch-mid-2022-pinebook-pro/

In the following thread I essentially did all the steps I had mentioned above. Proceeding slowly and carefully, I felt confident to flash the SPI, once I had determined that indeed it was empty. In the end you were right, the key is putting tow-boot on the SPI. I mean, that is certainly the easiest way I think. And the way I did it, I did not even have to open the case (which I was getting very tired of doing by this point, LOL). I have got Armbian working now both via SD card (the other day) and/or eMMC (just tonight). Detailed instructions can be found here: https://forum.armbian.com/topic/27598-getting-armbian-working-on-second-batch-mid-2022-pinebook-pro/

I got it working, including both via SD card and eMMC. See my linked thread in the previous post for all the answers.

Install to eMMC All of the above was with Armbian running on an SD card. Before I went any further with provisioning the new machine, I wanted to try getting Armbian on to the eMMC, which was always my ultimate goal. I am very pleased to announce that, using nand-sata-install tool, I was able to install the OS to the eMMC without any trouble whatsoever. I selected 'boot on eMMC and root on eMMC' (or something like that). After rebooting a couple times to test, it works flawless! It even copied over all my existing settings (so far only things done during initial setup, but still)! A pleasant surprise! So, I have decided to leave my tow-boot installed on the SPI. It seems to be working pretty well and might be helpful in a recovery situation. By default it boots into eMMC anyway, so now I don't even have to press ESC any more to select the SD card (like I had been doing until now). I am so glad to be rid of that Manjaro cancer. As if that wasn't bad enough, it came with KDE as well.

After the better part of a year being unable to use this device, I am pleased to announce my first successful boot into Armbian. I accomplished this by installing tow-boot to the SPI. If you check their instructions for the PineBook Pro, it says to install some 'installer' version first to an SD card, and then boot that, and use it to install to the SPI chip (or other media). I did not want to do that for a few reasons: I don't understand why all the faffing about with an indirect installation method via SD card? I don't seem to be able to boot via SD card anyway. I am really not interested in removing all those $#%^# screws from the back case again, just so I can flip a switch, then put them all back (twice, maybe more).[0] So what I did was dig around a little more until I found this issue from last year where people were saying just to do the following, essentially: dd if=Tow-boot.spi.bin of=/dev/mtd0 So I downloaded latest release of tow-boot, which comes as an xz compressed tar archive. After opening that up the usual way with: tar -xf pine64-pinebookPro-2021.10-005.tar.xz Under the binaries folder I found the Tow-Boot.spi.bin file. I copied that over to PBP and then executed the above mentioned 'dd' command (via sudo). I powered off and then back on, I knew it was successful because I saw the Tow Boot logo. So I powered off and then inserted SD card I had prepared a while back with Armbian on it. And yet it still booted into Manjaro on the eMMC. So once Manjaro finished booting, I powered back down, then back on, this time pressing <ESC> to bring up tow-boot's boot menu. After selecting 'SD card' I was able to boot into Armbian image on the SD card, which did the normal expansion and first run setup (entering passwords, locale, etc.). Now this is interesting, because I had tried to boot this very same SD card before, without any luck. Even turning the (previously mentioned) 'eMMC switch' to both positions[0], I could never get it to work. So maybe there is something to the 'switch is broken on the new batch' theory? Anyway, I guess that's it, as I finally have Armbian running on here. It's a minimal/CLI image, so I still have my work cut out for me getting this all set up, but hopefully I can just install my preferred desktop packages and we will see how it goes. But that's another project for another day. [0] Which involves removing quite a number of tiny little screws and removal of the entire back cover. And then putting them all back. In the meantime you can't really use the keyboard or anything, so you pretty much have to do the whole %&#@%# process every time. After doing this a few times, it starts turning into a hassle.

I decided to continue my investigation in a new thread.

I slowly convinced myself that I wanted a PineBook Pro, some time after the first production run. But then COVID, parts shortages, etc. happened and they were not available again until about mid-2022. But when they were, I decided to snap one up. And since then I have not been able to get it to boot Armbian. It came from the factory with Manjaro, which for me being a Debian guy, might as well be useless. So the PBP sat around collecting dust. Since then I have tried a few times to get it to work. I read many forum posts, tried some things. I won't document all that in detail. In this post, I will continue from where I left off here. However to summarize, that was about comparing DTB/DTS files to Kali, which supposedly works. That may become useful later, but I don't think that's the main problem. I think that the main problem is that this new batch came from the factory with no bootloader flashed to the included SPI flash chip. This is a problem on PineBook Pro because the RK3399 has a kind of weird boot order: SPI, eMMC, SD card. Therefore, if you just put in some SD card you flashed, it still boots from the factory Manjaro from the eMMC. Whatever bootloader they are using also apparently will not recognize an otherwise working Armbian image on an SD card. Now, because of the weird boot situation, there is supposed to be a switch to turn off eMMC. However this did not work for me. Which means one of 2 things: The switch does not work. I read at least one other person saying this. Also on the new revision, it's in a slightly different place than the old revision (may be a clue, maybe not). I simply had a bad Armbian image (which I had burned to sd card) that would not boot for whatever reason.[0] But let's put that aside for a moment. As I still think the main problem is the (empty) SPI. And that will be the easiest/best path forward. I confirmed the 'blank SPI' theory 2 different ways. First, as mentioned in a follow-up to the linked post (4 paragraphs above): As Martijn Braam states here: Of course, I like to beat a horse until it's really dead be thorough in my investigations, so today I wasted a lot of time[1] verifying that this indeed was the case. I did so by dd'ing the /dev/mtd0 block device into a file[2]. When I examined the file, it contained all FF, and also it is about 16 MiB in size. To me this confirms that indeed, the SPI on the new batch comes from the factory empty. So what is next? I keep reading that the only people who had success first had to install something like tow-boot to the SPI. That will be my next step. But before I flashed anything to SPI, I wanted to see what really came from the factory (which I did above). I will continue to document my progress whenever time allows for me to work on this. [0] Once I got the bootloader situation sorted, I later used this same image (on the SD card) to boot and install Armbian, so I do not think this was the case. [1] In the end the solution was simple. But first I wasted a lot of time trying to get rkdeveloptool working in Manjaro on the PBP. Only to realize it's intended to be used from a second machine to read the SPI flash via USB in maskrom mode. Anyway, lesson learned. [2] I tried to attach it but maybe it's too big.

To summarize some discussion from IRC yesterday: A couple people (rpardini and c0rneliuis) looked into the above and said that the Kali DTS seems to be closer to upstream. And also that perhaps a plain vanilla mainline DTS/DTB might work for booting PBP at this point. Today I plan to continue to look into the SPI issue, as I am pretty sure it came empty from the factory on the new batch. I am referring to the following (as well as having read this several other places): https://blog.brixit.nl/why-i-left-pine64/

What did you try already?

I am working on this now. I guess they need to be similar kernel versions to be useful (i.e., both 6.1.y)? EDIT: I am downloading: Armbian_23.02.0-trunk_Pinebook-pro_sid_edge_6.1.11_xfce_desktop.img.xz now to compare with kali-linux-2023.1-pinebook-pro-arm64.img.xz Which appears to be 6.1.0. Close enough? EDIT2: OK, I attached both decompiled DTS files. Hopefully someone who actually knows what they are doing can take a gander at them in their diff tool of choice. EDIT3: It's pure wizardry, I tell you! But here is the diff: EDIT4: I am not sure if above is the problem or not. Many people seem to think the problem is with Manjaro's boot loader. I am also trying to see what came on SPI from factory, I suspect it's empty on this new batch but I want to confirm that. Armbian_rk3399-pinebook-pro.dts Kali_rk3399-pinebook-pro.dts

I would love to try this but I am too scared. lol I been reading a lot of threads about this (here and at PINE64 forum) and this seems to be the consensus, that something funny is going on with Manjaro's boot loader. On the newer batch of PBP, I don't think they shipped a boot loader at all on the SPI (in fact there was a big kerfuffle about that, read Martijn Braam's blog). Anyway, I guess I need to search up how to: See if anything exists on the SPI currently. If so, back it up. Try to flash tow-boot. ??? Profit? In another thread, someone mentioned that the DTB is the problem, but for some reason the one from Kali Linux works. So this morning I will try and decompile and diff them. I don't have much time though, unfortunately.

FWIW, I was able to open the link to video without too much hassle, in my regular Firefox.[0] Reviewing it now. [0] I only had to allow a few permissions; a pleasant surprise, actually.

Interesting regexp. Where did you find that? Or it's your own handiwork?

Usually something like that is a file permission issue or something like that. Also, that is likely purely userspace issue and (I don't think) would have anything to do with Armbian. How did you install it?

I don't know about that hardware specifically, but general advice would be just to re-flash the sd card and start over? Make sure you are testing it, that the card is good (name brand from reputable seller), sufficient power, etc. (essentially all the basic things repeated ad nauseum in documentation; there is a reason for it!).

I guess you could do something as simple as a bash[0] script, really. But something like Kodi would give you a lot more control, I think (among many other niceties). I would also try and figure out how to communicate with the device over the network, if at all possible. Barring that, I guess you could use an IR remote (especially in Kodi). [0] or Python, or whatever language you like

You and me both. After Intel with their IME (and AMD equivalent), x86 is dead to me. Which is why I try and support Armbian as much as I can. 'You're our only hope, Obi Wan!' Only in their marketing approach. Wake me up when they release the 'crown jewels' (Office, Windows, etc.) under a F/LOSS license. Their model now seems to be 'run Office in the cloud' that way surely they can keep control, and now they can charge you a monthly subscription, as well! 'You will own nothing, and you will be happy!' It gets worse, much worse. Now they are trying to claim that the output from that AI is no longer subject to the (typically, F/LOSS) licenses that applied to the original software. Does anyone really think a leopard change their spots?! I don't!

I just saw this. Earlier I had read this, but I don't think those are the same. Therefore, I can try and work on this. Did anyone start anything yet? @rpardini, as you obviously know the work best, could you be so kind as to indulge me a summary of the main features? Not to discount your work, but for the average reader I think a 20 (50? more?) item long commit log does not make for the most interesting article. Maybe we can hash something out in lanefu's HedgeDoc instance again, like that one time? I think that worked pretty well.

Please don't take it personal. It only takes a few people pestering, looking for (free, immediate, personalized) support to get on the nerves of some people around here. There are very few of us, against a sea of them, so that is how we decided to deal with it, to stem the tide. Further, some threads move extremely slow. Maybe not this one, but I have seen many times where someone replies months, maybe even years later. Different people come along, move some issue forward by inches, and on it goes. Such is the way of progress some times. Welcome to the forums.