A (slight) shipping delay - an explenation + details
#1
Hi Everyone,

I know that you're all eagerly awaiting your Pinebook Pros. Now that I have a little bit of free time I figured that I should update you all on what's been going on behind the scenes.

TL : DR : we hit two roadblocks that delayed the shipping process by a few weeks (2-3) - but it should be all sorted now. The first batch ought to go out (hopefully early) next week. October batches may or may not be affected; we'll likely make up some of the lost time

Here are the details:

The first problem was related to the Pinebook Pro not powering on in the event that the battery was disconnected from the main board. While this will likely not affect the grand majority of users, a suitable work-around had to be put in place in the event Pinebook Pro has to be ran without a battery. There are now two jumper cables on the PCB that can be bridged to power up the Pinebook Pro without the battery plugged in. Here is the engineering notice.

The second problem we ran into is an incompatibility between factory workflow and the RK3399 SOC boot-sequence. Prior to flashing the Debian MATE image, the factory preloads a testing build on the eMMC to determine if a Pinebook Pro unit is functional. This is after the unit is screwed together and 'completed'. Unfortunately, the inherent RK3399 boot sequence priorities eMMC over SD card, so flashing from SD / USB 2.0 is literally impossible using the build that the factory uses (NB. the custom Debian build permits SD booting prior to eMMC; this described scenario relates only the the factory OS build). In result, all units had to be unscrewed and re-flashed with the shipping build by hand and put back together. As you can surely appreciate, this takes time.

This isn't the factory's fault per se, they are just accustomed to working with SOCs which have a boot sequence hierarchy akin to the original Pinebook, which uses the Allwinner A64; this SOC priorities SD over eMMC in the boot hierarchy. In the future, the default Debian MATE build will be flashed onto the eMMC while all testing will be done from SD.

We expect that we'll make up much of the lost time in future batches, but the deadlines may shift a week or two forward in time.

So, the first batch should now be going out in just a few days, while the October pre-orders (forum member + public) may be suffer a slight delay. I'll keep you posted.

Sorry for the delay!
You can find me on IRC, Discord and Twitter


  Reply
#2
Thanks for the update, Luke!

I really appreciate it!
de KL7JKC
  Reply
#3
Good to know. Thanks for the update. I will now dry my eye's. And get back to work.
  Reply
#4
Thanks for the update! It's great to have such transparency
  Reply
#5
Appreciate the heads up Luke. Thanks!
  Reply
#6
Thanks for the update! Looking forward to delivery!
-Happy Testing
(Posted from my Pinebook  PRO Mate)
Getting Paid to break your product (and make it better) since 2005
  Reply
#7
Thank you for this information.
And thank you to the whole team for their hard work.
  Reply
#8
Thanks for the update Luke!!
For me, it makes the "community" feel all that much more connected!
Many Thanks for all the HARD work you and the team have done!! :-)
  Reply
#9
(09-20-2019, 05:04 AM)Luke Wrote: Hi Everyone,

I know that you're all eagerly awaiting your Pinebook Pros. Now that I have a little bit of free time I figured that I should update you all on what's been going on behind the scenes.

TL : DR : we hit two roadblocks that delayed the shipping process by a few weeks (2-3) - but it should be all sorted now. The first batch ought to go out (hopefully early) next week. October batches may or may not be affected; we'll likely make up some of the lost time

Here are the details:

The first problem was related to the Pinebook Pro not powering on in the event that the battery was disconnected from the main board. While this will likely not affect the grand majority of users, a suitable work-around had to be put in place in the event Pinebook Pro has to be ran without a battery. There are now two jumper cables on the PCB that can be bridged to power up the Pinebook Pro without the battery plugged in. Here is the engineering notice.

The second problem we ran into is an incompatibility between factory workflow and the RK3399 SOC boot-sequence. Prior to flashing the Debian MATE image, the factory preloads a testing build on the eMMC to determine if a Pinebook Pro unit is functional. This is after the unit is screwed together and 'completed'. Unfortunately, the inherent RK3399 boot sequence priorities eMMC over SD card, so flashing from SD / USB 2.0 is literally impossible using the build that the factory uses (NB. the custom Debian build permits SD booting prior to eMMC; this described scenario relates only the the factory OS build). In result, all units had to be unscrewed and re-flashed with the shipping build by hand and put back together. As you can surely appreciate, this takes time.

This isn't the factory's fault per se, they are just accustomed to working with SOCs which have a boot sequence hierarchy akin to the original Pinebook, which uses the Allwinner A64; this SOC priorities SD over eMMC in the boot hierarchy. In the future, the default Debian MATE build will be flashed onto the eMMC while all testing will be done from SD.

We expect that we'll make up much of the lost time in future batches, but the deadlines may shift a week or two forward in time.

So, the first batch should now be going out in just a few days, while the October pre-orders (forum member + public) may be suffer a slight delay. I'll keep you posted.

Sorry for the delay!
Thanks for taking care of these matters on the front end AND formally documenting it, AND keeping us up to date!  I appreciate it!
  Reply
#10
Thanks for the feedback. Yea, solving the second issue took quite some time because of the time offset between me/ some developers, as well as @tllim AND the factory; In example, if we come up with an idea (usually my night time, right before I go to sleep / TL's afternoon / morning the following day at factory [from my point of view]), it will take an entire workday to get feedback if an implementation worked (I wake up, TL goes to sleep, factory closes...). On top of this, it then  will take a workday to, e.g. fix or alter that implementation to get feedback on a fix ... you see how this goes and why a lot of time gets wasted.

Anyways, as things stand, the China offices will have to deal with the burden of actually flashing the OS images to the eMMC modules (long and boring story - related to how factory flashes OS images / their workflow) and deliver the pre-flashed modules to the factory so they can install them in the PBPs. This is a bit of a pain in the behind - usually the factory does this for their client... But at least now there is a viable, simple, and hopefully sustainable solution to the problem.
You can find me on IRC, Discord and Twitter


  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Screen refresh delay with kernel errors shawnanastasio 29 4,197 09-16-2020, 09:38 PM
Last Post: bchenlee609
  For Sale, ANSI 64GB, shipping to US rossk 0 239 08-25-2020, 07:33 AM
Last Post: rossk
  trouble with shipping methods harakirisekaini 0 170 08-21-2020, 08:17 AM
Last Post: harakirisekaini
  PBP running shipping Manjaro won't wake from suspend fornio 2 466 07-21-2020, 07:04 AM
Last Post: vancheese
  Shipping time and cost estimates request janat08 1 403 05-16-2020, 01:03 PM
Last Post: janat08
  Looking to sell PBP ISO 128 eMMC for $150 + shipping luchtcm 1 515 05-11-2020, 07:19 AM
Last Post: luchtcm
  Shipping and virus concerns nabeel 3 627 03-21-2020, 02:34 PM
Last Post: craftkiller
  Is it possible to use another shipping method? rekesz 5 835 01-28-2020, 03:21 PM
Last Post: rekesz
  PBP Coupon and Shipping Timeline fire219 123 29,853 10-29-2019, 04:08 PM
Last Post: Luke
  Pinebook Pro Shipping Dimensions gdpoc 1 562 08-22-2019, 05:19 PM
Last Post: Arwen

Forum Jump:


Users browsing this thread: 1 Guest(s)