(07-16-2020, 11:29 PM)as400 Wrote: Thanks for testing.
How much success rate did you have booting ?

(07-16-2020, 05:36 PM)belfastraven Wrote: Re testing:
@as400 ,  I am booting to where I get output on the PBP screen post u-boot,  occasionally.  U-boot output seems to work fine,  and I can use, e.g.  the return key, to interrupt it on the PBP,  but with the menu-version, ctrl-c is not bringing up the menu on the pbp.  It does however bring up the menu on my picocom serial session.  

  I always do get the green light that indicates manjaro is booting,  but often see no output either on the pbp or the serial console.  Often I'll see either nothing or a multicolored "plaid" flash pattern on the entire screen ...   

I'm only testing booting the nvme from spiflash,  since  that's the only device I have in the pbp right now--I never use the emmc  and use the SD card only to test various builds.  

I attached serial logs  (with my comments interspersed) for several tries.

I reinstalled the pcm720   version of spiflash for now,  since that boots for me with no problems.  Once again,  this is on a Manjaro system with 5.7 kernel using  unstable

(07-18-2020, 07:32 AM)freerk Wrote: Hello,

I have probably bricked my Pinebook pro.
I flashed the SPI device.
Without the desired result; booting from the builtin M.2 drive
When I put it on I only see the red power LED flash for half a second and then nothing.
The system-board is consuming power because its getting warm.
After a long pres of 15 seconds the board is off again; the board is getting cooler again.
I tried to clear the SPI chip with rkdeveloptool
But I get an error:
./rkdeveloptool db rk3399_loader_spinor_v1.15.114.bin  >>
The device does not support this operation!

Is there someone who knows how to repair this?

Freerk Jongsma

Quote:My machine does not boot after installing to SPI and is not in maskrom mode

Oof, first of all, sorry. In testing I have never had a flashing render my device unbootable.

Rescuing your device is not specific to this project. You can follow the instructions from the Pine64 forums to recover from a broken SPI flash.

(07-17-2020, 06:21 PM)belfastraven Wrote: @as400  I noticed that two days ago additional doc was posted here:  https://github.com/samueldr/wip-pinebook-pro/commit/fad3d88578acfbf6da878681afad9d830e725b4b,  in which he states  in the issues section that kernels above 5.5 are not booting, and mentions a couple of other issues (problematic input, possible interference between screen and serial output)

(07-18-2020, 01:15 PM)samueldr Wrote: @freerk I'll preface that I have not done any testing that includes any patches or build systems outside of my Nix derivations in the repository. I do not have the hardware to setup NVMe drives, thus I can't test, thus I don't provide such builds.

Now, from the linked repository, in the FAQ:

Quote:My machine does not boot after installing to SPI and is not in maskrom mode

Oof, first of all, sorry. In testing I have never had a flashing render my device unbootable.

Rescuing your device is not specific to this project. You can follow the instructions from the Pine64 forums to recover from a broken SPI flash.

Your machine is unlikely to be fully bricked, but might require some love and care to bypass the SPI boot. Follow the link. I haven't personally had to use this method, but it is rooted in well-known knowledge about the RK3399 boot flow, so it looks totally sane.

You can use the firmware installer image, if you have used that to install, to zero out the SPI. Alternatively you can fish out the proper sf command to do the equivalent.

Any builds other than those produced by my unmodified Nix derivation stand squarely in YMMV territory as far as I'm personally concerned.

---

(07-17-2020, 06:21 PM)belfastraven Wrote: @as400  I noticed that two days ago additional doc was posted here:  https://github.com/samueldr/wip-pinebook-pro/commit/fad3d88578acfbf6da878681afad9d830e725b4b,  in which he states  in the issues section that kernels above 5.5 are not booting, and mentions a couple of other issues (problematic input, possible interference between screen and serial output)

This particular document was present in the PR from day one. I also made sure to say (on IRC) that there was some caveats and to fully read the added docs to understand possible issues.

Though, some community members (@as400) have had better success with booting a 5.5+ kernel with that U-Boot, while I haven't been able to reproduce consistent or even 75%-successful boot rates.

Now, those caveats are a good chunk of the reason this wasn't simply made the new gold standard . Hopefully soon we'll have had people that deeply know more about the subjects look into the issues and figure out what is actually happening.