Issue tracking?

[geokon]

Is there some central place where outstanding issues are being tracked?

I received the laptop a few days ago and a few minor things aren't quite working and a few things remain unclear - but I don't know what's a known issue, an unreported issue, an issue with the OS, or an issue with my laptop is particular.

I'm unclear on whether I should be posting things here, on Github issues, or on the wiki

At the moment I'll post what I have here, but please let me know if there is a better place:

- Using a USB-C cable to connect a T3 Samsung SSD to the one USB-C port doesn't work. `dmesg` does show that a USB device is connected but no device shows up in the file browser. If I connect the drive with a USB-A to USB-C cable to a normal type-A port then the drive shows up correctly


- If I record in Audacity the microphones show up as stereo, but the two channels are identical (the dual microphone setup was a very welcome surprise - looking forward to it working)

- If you don't run X11 you can't adjust the screen brightness with the Fn keys from the console

- I've never had a machine with both USB-C and a power plug. If I unintentionally plug in the power cable while charging through USB-C - will this potentially fry the machine? Is this something I need to be watching out for? Or will this even charge my machine faster..? The laptop came with a wallwart, but it'd be nice to just only run off of ubiquitous USB chargers - I don't know if this is advisable

- In the default OS there is a a frequency regulator in the main panel. I've never seen a menu like this before on any other machine, but it seems potentially quite useful. In particular I'd like to do performance benchmarks of some software I'm working on and I'd like to avoid external factors like thermal throttling, "turbo" modes and whatnot, so running slower but consistent would be very useful for getting repeatable results- however there is not a lot of info in the Help menu. The different profiles don't have any explanation and I'm unclear on what will happen if I manually select a high frequency. Will this risk overheating and damaging the computer?

There is also the whole "big-little" architecture and I'm not sure how scheduling happens for that - is there some place I can find more info? Maybe a way to temporarily disable the little cores when running certain jobs?

Thanks for all the help, the great community and the fantastic laptop,
Really looking forward to where this is all going

[fire219]

Is there some central place where outstanding issues are being tracked?

It's something currently being considered, but we need to determine the best way of going about that.

- Using a USB-C cable to connect a T3 Samsung SSD to the one USB-C port doesn't work. `dmesg` does show that a USB device is connected but no device shows up in the file browser. If I connect the drive with a USB-A to USB-C cable to a normal type-A port then the drive shows up correctly

There are known issues with the USB-C port. It's being working on by mrfixit (the person who made the default Debian image)

- If you don't run X11 you can't adjust the screen brightness with the Fn keys from the console

Unfortunately we don't have a module for handling the keyboard Fn keys outside of X11. You should be able to change the backlight brightness manually with: 

Code:

echo <value from 0-255> | sudo tee /sys/class/backlight/edp-backlight/brightness

- I've never had a machine with both USB-C and a power plug. If I unintentionally plug in the power cable while charging through USB-C - will this potentially fry the machine? Is this something I need to be watching out for? Or will this even charge my machine faster..? The laptop came with a wallwart, but it'd be nice to just only run off of ubiquitous USB chargers - I don't know if this is advisable

I'll admit that I don't know if it will damage anything. I wouldn't recommend it though, and it won't charge the battery faster.

- In the default OS there is a a frequency regulator in the main panel. I've never seen a menu like this before on any other machine, but it seems potentially quite useful. In particular I'd like to do performance benchmarks of some software I'm working on and I'd like to avoid external factors like thermal throttling, "turbo" modes and whatnot, so running slower but consistent would be very useful for getting repeatable results- however there is not a lot of info in the Help menu. The different profiles don't have any explanation and I'm unclear on what will happen if I manually select a high frequency. Will this risk overheating and damaging the computer?

The "profiles" in that regulator widget are standard Linux kernel "governors". You could look them up if you want exact details, but basically:

-  "on-demand" is the best all around (performance when its needed, low power when its not)
- "performance" runs all the cores at full clock speed all the time. It won't damage anything, but the PBP will get noticeably hotter.
- "powersave" runs all the cores at their lowest clock speed. The benefits and downsides of this should be obvious.

There is also the whole "big-little" architecture and I'm not sure how scheduling happens for that - is there some place I can find more info? Maybe a way to temporarily disable the little cores when running certain jobs?

I'm not sure how the scheduling happens either. It depends on how the kernel is set up. There should be a way to disable the little cores but I'm not sure how -- and I wouldn't recommend it either. At worst, it messes with benchmarks. But the little cores are there for a reason: they consume a lot less power than the big cores, when you don't need full performance!

[Der Geist der Maschine]

- In the default OS there is a a frequency regulator in the main panel. I've never seen a menu like this before on any other machine, but it seems potentially quite useful. In particular I'd like to do performance benchmarks of some software I'm working on and I'd like to avoid external factors like thermal throttling, "turbo" modes and whatnot, so running slower but consistent would be very useful for getting repeatable results- however there is not a lot of info in the Help menu. The different profiles don't have any explanation and I'm unclear on what will happen if I manually select a high frequency. Will this risk overheating and damaging the computer?

The "profiles" in that regulator widget are standard Linux kernel "governors". You could look them up if you want exact details, but basically:

-  "on-demand" is the best all around (performance when its needed, low power when its not)
- "performance" runs all the cores at full clock speed all the time. It won't damage anything, but the PBP will get noticeably hotter.
- "powersave" runs all the cores at their lowest clock speed. The benefits and downsides of this should be obvious.

There is also the whole "big-little" architecture and I'm not sure how scheduling happens for that - is there some place I can find more info? Maybe a way to temporarily disable the little cores when running certain jobs?

I'm not sure how the scheduling happens either. It depends on how the kernel is set up. There should be a way to disable the little cores but I'm not sure how -- and I wouldn't recommend it either. At worst, it messes with benchmarks. But the little cores are there for a reason: they consume a lot less power than the big cores, when you don't need full performance!

That's not an answer but a remark.



It is the first time I can toy around with big.little CPU architecture. Here is an interesting case-study in parallelization. I was compiling a linux kernel with make -jn allowing n compilations to be dispatched in parallel.

j1 real 63m03.721s user 64m20.015s sys 04m34.679s
j2 real 33m28.409s user 64m12.669s sys 04m50.640s
j3 real 27m14.206s user 73m06.491s sys 05m26.390s
j4 real 23m42.549s user 81m01.083s sys 06m02.435s
j5 real 21m58.216s user 88m57.846s sys 06m34.789s
j6 real 20m49.394s user 94m48.045s sys 06m51.734s

The data is very interesting:

• With one core, we have real < user + sys. Maybe some sys work got dispatched in parallel to user work. dpkg-deb builds the kernel packages after the actual compilation is multi-threaded resulting in utilization of multiple cores.
  
• user and sys time stay the same when the compilation is dispatched on one or on two equally fast cores. Real time halves.
  
• when slower cores join the compilation (j3 - j6), real time continues to drop, but user and sys times increase.
  

PS: you can configure your cpus via sysfs callback under sys/devices/system/cpu/ - look around and cat and echo values.

[geokon]

Thank you for the detailed response fire219. This is a lot of good useful info and I hope others find it

If it were up to me I'd having everything on github. That way it's all hosted for you and most folks will already have an account - so it'll lower the participation barrier. People can open issues for problems they have, the wiki is integrated, easy to clone/edit and there is a project board for things that are being worked on. It's also quite convenient to search so you can find useful details like how to change the brightness from the console

But I understand if you have reservations. It's a bit tricker to split the issues that are OS-related from the ones that are not - especially since mrfixit is working in his own repo in an unofficial capacity

I will definitely look into the linux governors - thanks for that pointer - and I will just stick to one charging method to be on the safe side while that remains an unknown

Are there in fact 2 microphones in the computer? Or are there just two holes for aesthetic reasons?

PS: Thanks for that extra pointer Der Geist der Maschine. I'm gunna poke around when I need to do some ARM benchmarks

[Arwen]

@Der Geist der Maschine,

If I understand it correctly, user time is simply the sum of the separate worker threads.

So it makes perfect sense that 1 thread takes 63 minutes real time, 64 minutes user time.
And 2 threads take 33 minutes real time, 64 minutes user time.

Whence the little cores come in the play, it's less of a change, but of course we WANT the user time to increase. The is where the real work is done. As long as the real time is lower.

---

@geokon,
I've started a Troubleshooting guide on the Wiki. It does not solve the problem of where to report issues, but the intent is to have common problems described, along with common fixes. Here is a link;

Wiki - Pinebook Pro - Troubleshooting guide

For the Pine64 Wiki Troubleshooting guide, I'd suggest we stick to issues that affect more people, happened more than once, or likely to happen in the future to more than one person.

As an example, a new Pinebook Pro owner received his/her Pinebook Pro with the LCD factory protector still on the LCD screen. So far, that's happened to only one person. So my thought is to leave this problem off the Troubleshooting guide.

[zaius]

- Using a USB-C cable to connect a T3 Samsung SSD to the one USB-C port doesn't work. `dmesg` does show that a USB device is connected but no device shows up in the file browser. If I connect the drive with a USB-A to USB-C cable to a normal type-A port then the drive shows up correctly

- If I record in Audacity the microphones show up as stereo, but the two channels are identical (the dual microphone setup was a very welcome surprise - looking forward to it working)

- I've never had a machine with both USB-C and a power plug. If I unintentionally plug in the power cable while charging through USB-C - will this potentially fry the machine? Is this something I need to be watching out for? Or will this even charge my machine faster..? The laptop came with a wallwart, but it'd be nice to just only run off of ubiquitous USB chargers - I don't know if this is advisable

It's a USB 3.0 OTG port. 

The schematics show only one microphone.

Please do not connect it to two different power sources at the same time.

[tophneal]

The laptop came with a wallwart, but it'd be nice to just only run off of ubiquitous USB chargers

Pine currently offers USB-to-barrel jack cables. You could use one of these instead of the supplied wall wart, but you'll need to be careful to match the power output of the USB charger to that of the original wall wart. (If I'm wrong, though, feel free to correct me.)

[geokon]

The schematics show only one microphone.

Please do not connect it to two different power sources at the same time.

That's a shame. The microphone chip seems to support two microphones and there are two holes on the case. I guess I'll stick to an external webcam then

And for the power, it wasn't really something I was looking to do regularly. I was just wondering if there is any kind of internal current protection in case I do happen to connect power over barrel and USB at the same time. It's easy to do by accident esp. if you switch between chargers. Sounds like there isn't.. which seems like a design oversight. I doubt a conventional laptop would get fried in this scenario.

[Arwen]

...
Please do not connect it to two different power sources at the same time.

...
And for the power, it wasn't really something I was looking to do regularly. I was just wondering if there is any kind of internal current protection in case I do happen to connect power over barrel and USB at the same time. It's easy to do by accident esp. if you switch between chargers. Sounds like there isn't.. which seems like a design oversight. I doubt a conventional laptop would get fried in this scenario.

As for the "doubt a conventional laptop would get fried", yep, I agree. Our Pinebook Pros did not have huge engineering teams behind them.

Perhaps a community memember who understands power will review the schematics and request an ECO, (Engineering Change Order), for the "Pinebook Pro II". And maybe even come up with a back ported fix that we can apply, (or have someone else apply), to our existing Pinebook Pros.

My own project for the mythical PBP II, would be a second MMC, (not eMMC). From what I can tell, there is second SD/MMC interface on the RK3399 chip. I'd like that to be internally available for another memory device. Mostly for built in backup or mirror device. But, my research is in the early stages. Lots of reading to do.

[geokon]

I'm likely not aware of some design considerations here, but I assume the next iteration of the device would just skip the barrel jack entirely? It's a very bizarre design that requires either a special wall wart or a esoteric USB to barrel cable. I'm kinda curious why that was selected. The obviously the ideal solution would be a second USB-C port - or at least a USB-C dummy/power-only port that you sometimes see on SBCs (it doesn't need to do anything crazy to negotiate 12V - just need to wire up the 5V pins)

Again.. there is probably a good reason they didn't do that though