Jump to content

Miles Raymond

Validating
  • Posts

    1
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Miles Raymond reacted to TRS-80 in Getting Armbian working on second batch (Mid 2022) PineBook Pro   
    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.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines