Jump to content

TRS-80

Moderators
  • Posts

    760
  • Joined

  • Last visited

Everything posted by TRS-80

  1. 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.
  2. I decided to continue my investigation in a new thread.
  3. 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.
  4. 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/
  5. 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
  6. 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.
  7. 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.
  8. until

    Shouldn't there be a Zoom link or something in the OP? If it's there, I don't see it. I'm going to try and join via browser, hopefully I can hear/see what's being said that way.
  9. Interesting regexp. Where did you find that? Or it's your own handiwork?
  10. 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?
  11. 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!).
  12. 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
  13. until

    I should be able to attend (in IRC!).
  14. 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!
  15. 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.
  16. 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.
  17. I can only imagine how happy @rpardini will be not needing to re-base any more. Jokes aside, kudos to you, you must be thrilled all your hard work will be seeing the light of day, finally. Thanks for sticking with it all that time.
  18. until

    The time shown is our local time? Or GMT? I will plan on attending, so I don't want to make a mistake on the time.
  19. Thanks for the feedback. Just to confirm, you have one of the more recent batch?
  20. This is a (somewhat) long standing and well known issue, check PineBook Pro subforum here, there are a number of threads about various booting issues (including eMMC specifically). I think the problem (with the latest batch of PBP which were shipped, anyway) is that those came with Manjaro on the eMMC and no universal bootloader (tow boot) flashed on the SPI chip. Well thinking about that now, I guess burning to eMMC should still work, but it doesn't for some reason. Have you tried using armbian-config (and/or (the unfortunately named) nand-sata-install which can also be reached from there) to try and write the image to the eMMC? If you already overwrote the eMMC previously I guess there is nothing left to lose. I have this hardware but I just acquired an old headphone cable which I still need to fashion into a serial cable before I can proceed further. And I have yet to collect enough 'tuits' of the round variety.
  21. TRS-80

    Backup

    This thread sounds oddly familiar (but I'm not going to bother searching). Anyway, I encourage you to consider configuration management as a separate concept to 'imaging the entire OS as a backup' as there are a couple problems with the latter approach: It wastes a lot of space. Upgrading in-place between major OS versions is not (and has never been) supported in Armbian, so sooner or later you will probably have to re-install everything anyway. In the configuration management space there are things like Ansible (and many, many others) in fact just searching up that term should give you plenty of ideas.
  22. I think you should read his reply(ies) again (and some others in this thread), perhaps more carefully this time, as I came away with a different interpretation.
  23. Yes, we (ab?)use the 'spoiler' functionality for that. I edited your post already.
  24. I am surely no expert, but starting to wonder if something Manjaro put in their bootloader is not compatible with Armbian. This is not directly related to what NicoD was saying above, but I did want to report my experience. I have tried burning both the following images to SD card, in both cases I just get a blinking green power light: Armbian_22.08.1_Pinebook-pro_bullseye_current_5.15.63.img Armbian_22.11.1_Pinebook-pro_jammy_edge_6.0.10_xfce_desktop.img As a reminder, I have one of the newer (2022-06) production run of PineBook Pro, which comes with Manjaro pre-installed on the eMMC from PINE64. I have been unable to get Armbian working on it in any way, shape, or form ever since I bought it. So I don't use it at all (as I can't stand Manjaro nor KDE, personally). Anyway, I took a look at the eMMC (had to boot into Manjaro to do so) and it seems there are 2 partitions, one for /boot and one for /. Oh yes and BTW there is a switch by the eMMC which is supposed to bypass it (otherwise on RK3399 the boot order is SPI, eMMC, SD card), when I do that I get a steady orange light. But still no boot.[0] Even though I never use the pre-installed Manjaro image, I am still too afraid to flash anything directly to the eMMC (especially after reading many reports it doesn't work). I am going to order the special 'headphone to serial' cable that is required for the PineBook Pro, in hopes that I might be able to contribute further useful information. [0] OK, truth be told, I only tried this with the 22.08.1 image, as I didn't want to take out all those damn screws again just to get to that switch. ¯\_(ツ)_/¯
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines