Hi all.

In this new time of video conferencing I have tried Jitsi Meet.

Jitsi is an open source decentralised video conferencing software for the browser or apps. Also it is free and several good people offer their Jitsi Server to the public. However the official one also works ok.

On the PBP you previously needed a Chromium  browser oner one of it's siblings to use Jitsi, but just now I noticed that Firefox now recognises the camera as well and it works.

In Firefox when accepting the permissions I have selected the USB Camera from the list, not the pre-selected one.

If you  have chosen a camera from the list that does not work, close the meeting and reopen it, you will be asked for permissions again and then you can choose the USB Camera. If you have saved the permissions you need to delete the permission for the camera in the preferences first.

The CPU load is quite high for both browsers though, but it works. Sometimes there are hick-ups, but overall it works.

How is your experience ?

Hi.

Is there any chance to offer markdown as a format for the forum posts?
Maybe it is possible to add that when the forum migrates to the new RockPro64 cluster ?

Hello everybody,

first of all a HUGE thank you to everybody who works on PostmarketOS! That is an amazing project and I see really stunning things happening.

But one thing I have notices when I compare it to the Debian + Phosh version (which you can find in another forum thread) is that they were able to adjust the form factor for many things almost ideally. Especially in Firefox this is huge, but also in other apps. 

Is there a way to collaborate a bit with them on this issue to just to "borrow" some code from them?

Best,
Thomas

Hi @Luke and Pine64ers,

Please let me share with you my expectations and then please allow me raise some more questions.

"RK3399 OG Pinebook upgrade kit testing and challenges; we’ll likely use graphene for cooling.". 

My expectation on this is that there will be a 11" RK3399-based Pinebook in the pipeline. The size is about the 11" MacBook Air late 2010 model. Is that possible to make it a combination of something like pi-top+pi? That is to say, when combined it is very decent laptop for everyday use. 

When detached, the naked SBC are versatile and flexible enough to let me attach various peripherals to it and serve as a core components of my other projects?

Now for some questions. 

Rockchip has just announced RK3588. Are there any new products and/or upgrade kits under development? What is the time line?

Will there be any accessories such as stack case? 

thanks community.

Hello,

I have been tweaking my Arch Linux setup since I described how to dirty hack Arch over Ayufans images in this forum a while back (https://forum.pine64.org/showthread.php?tid=6333).

There is already a thread on compiling U-Boot for the RockPro64 in this forum by @TaborFife : https://forum.pine64.org/showthread.php?tid=7992, but he did not create a PKGBUILD for easy reproduction and updates under Arch Linux. His build is rather described to be built from any host, but I think if anyone wants to install Arch Linux on their RockPro64, it is likely they also have an Arch Linux x86 machine running somewhere

So, now I have created a PKGBUILD for building U-Boot for the RockPro64 from upstream U-Boot with ARM Trusted Firmware also built from source. The PKGBUILD and install files are based on the uboot PKGBUILD for the Rock64 which is already in the ArchLinuxARM repos.

According to the Rockchip wiki http://opensource.rock-chips.com/wiki_Boot_option, this equals to Boot Flow 2 with the small exception that ATF is also compiled from source.

The PKGBUILD can be both cross compiled from an Arch Linux x86 machine (works out of the box) or directly on your RockPro64.

What is the advantage of doing everything from source: First for the fun of learning, and second, I can do the build without the Rockchiptools. I just find things more beautiful if you do not need special vendor tools for anything.


So, here is the HowTo (to do an initial build to bootstrap your SD card from your Arch Linux x86 PC):

1) Check out the PKGBUILD from my GitHub: https://github.com/matyas1995/u-boot-PKGBUILD.git

2) Make the package - for bootstrapping the SD card, you will need to go into the directory where the package sources have been build my makepkg

3) Partition your SD card as described by @TaborFife https://forum.pine64.org/showthread.php?tid=7992 in his thread in Section 2, steps 0 to 4

4) From the directory where u-boot has been build (makepkg builds packages in the 'BUILDDIR' directory, described in /etc/makepkg.conf) burn the bootloader with dd to the SD card:

Hi

  I would like to know if I the SOC is able to function on slave mode using Android 7

Hello,

I am running vanilla Arch Linux with the stock mainline kernel on my RockPro64 (If you are interested in how to install, just check the other threads).

However, for a while now the ethernet on the RockPro was as good as dead, with network speeds reaching about 50-80Kbit/s!!!

As I am using my RockPro as a home cloud server, you can imagine how frustrating this is for me. This is so slow that even system upgrades fail due to timeouts on downloading the upgrade packages. So I used the free time now to dig into this issue, especially as I have not read anything of this behaviour from the other mainline users in this forum.

The first big difference between me and the other mainline users seem to be that while I am using the mainline Kernel from Arch, others on the Ayufan Images use the kernel compiled from Ayufan's mainline repo, where he also implements some patches specific to the Rockchip devices.

After a while I found a mail from him on the Linux Kernel Mailing Lists,

Thread: https://lkml.org/lkml/2019/4/1/1382

describing my problem as a bug in some rockchip boards where TX checksumming fails for ethernet packets larger than 1498 Bytes due to incorrect buffer utilization. This would also explain why I am still having a connection to my RockPro through SSH and why the DNS server on the RockPro still serves my home network, but updates fail: An ethernet packet can be as big as 65536 Bytes(!), so while SSH and DNS usually stay below a packet size of 1498B due to the small amounts of data they need to transmit, any file download will be split in packets as big as possible, breaking the checksums.

I could nicely verify this behavoiur with Iperf3 on my board: Iperf3 sends 128KB packets as default, reaching the expected 0-50Kbit/s ethernet speed, but when told to send packets of size 1490B only, ethernet throughput suddenly jumps up to gigabit speeds.

So, how to solve this?
It seems that the discussion turns around if this is just a board related issue or something in the SoC, as the problem seems to be in the utilization of the TX FIFO buffers by Linux. As it looks like they are experimenting with the burst lengths and a workaround of using software checksumming instead of offloading the checksumming.

So, I just took the Arch Linux PKGBUILD for the linux-aarch64 stock kernel and tweaked the device tree for the RockPro64 to include the lines

Howdy Folks, 

ZOOM would be a Great app to have on PBP, given the unfortunate Shelters in Place, but so far my attempts to start Zoom from urls in MeetUp.com draw a blank, and attempts to install a Zoom from Synaptics have found no Zoom.  Is there a Zoom app for PBP please, or must I continue to use cell Zoom when away from desk?  

PBP is now my favorite laptop, very easily carried, but it needs a Zoom.  

:-)

I am loving Manjaro 20.04 on Pinebook Pro, really working well for me. I have had very few issues and most have been solved easily.

One issue that I have not figured out and have not been able to find in the forum with a search: I miss the CPU speed indicator/selector widget that was in the Debian install.

Has anyone got that to work under Manjaro?

Thanks, Tim

I’ve ordered a PinePhone and received the checkout URL, but no information about the delivering process.

I sent two email messages to sales@pine64.org, but received no response.

Where is my PinePhone?