062621AM

@062621AM Hello, I have been an Ob3pi user for a few months. The problem that I have seen is that there are 3 types of models v1, v1.1.1, v2.1, it is in the latter where the Wi-Fi and Bluetooth chip changes and also the size of the NVME (2280). For these changes to work correctly in the official distribution, they add a dts (orangepi3b-v2.1.dts). The latter is not integrated into any old distribution, since the manufacturer just distributed this board a few months ago. If you use the hardware as a server, you may not notice errors in the GPU, VPU, BLUETOOH or WIFI. Until the moment I write this comment, the only distro that I have been able to use is the Ubuntu - Rockchip project. But even this has problems with the hardware already mentioned.

I read about this on this forum or chat. Try this way https://forum.armbian.com/search/

Actually no, you do not have to. Though the performance seems slightly better with kernel >=5.6.x

As we know, the PCIe on H6 is buggy, which doesn't offer linear address, and Linux cannot support such kind of configuration.
 
However, the Cortex-A53 cores used by H6 supports virtualization, which can be used to change the order of the address space.
 
Recently, I tried to make use of virtualization to provide linear mapping of PCIe, and I succeed in making an Intel 6205 wireless card working.
 
The hypervisor code is at https://github.com/Icenowy/aw-el2-barebone . It's intended to start before U-Boot, and located at 0x40010000.
 
A U-Boot fork that is patched to load the hypervisor is at https://github.com/Icenowy/u-boot/tree/h6-load-hyp , and a kernel that utilizes the wrapped PCIe (and patched to reserve memory for the hypervisor) is at https://github.com/Icenowy/linux/tree/h6-pcie-wrapped .
 
In order to let the hypervisor start before U-Boot, BL31 needs to be built with `PRELOADED_BL33_BASE=0x40010000` in make parameter -- this will change the EL2 entrypoint to the hypervisor. Mainline ATF from ARM works.
 
Contributions to the hypervisor is welcomed.
 
(In addition, abusing virtualization in such way will prevent us from using KVM. But I think more people will want PCIe instead of KVM, right?)

Seems also be the same issue on 5.6. As soon as you log in and start doing stuff it freezes the board
[ +33,408356] panfrost 1800000.gpu: gpu sched timeout, js=0, config=0x3700, status=0x8, head=0x3d07800, tail=0x3d07800, sched_job=000000001ec47767 [Apr 7 16:54] panfrost 1800000.gpu: gpu sched timeout, js=1, config=0x3700, status=0x8, head=0x4993680, tail=0x4997c80, sched_job=00000000f643e8d9  

I think that this is faster way
sudo apt-get install software-properties-common -y
sudo add-apt-repository ppa:oibaf/graphics-drivers 
sudo apt-get update
sudo apt-get upgrade
but oibaf provide only arm64 packages!
 

Still, RDP and VNC are not secure enough to open a port directly to Internet.

I rather suggest x2go, which is much more secure (works over ssh), and also a lot faster. Plus, it allows forwarding of sound, local folders and printers.

http://wiki.x2go.org

Enviado desde mi Aquaris M mediante Tapatalk
 

Hello megi,
i cannot access the link(https://megous.com/git/linux/commit/?h=opi3-5.2&id=9c296799c4d3dd90986833cfded392098c1979bd) , described in the task.
 
I have found it somewhere else, it is working now!
Simply the setting the bt mac was needed.
 
btmgmt --index 1 public-addr 00:11:22:33:44:55
 
Thank you!

Hello and thanks for all the effort.
 
I just wanted to inform you that today with kernel 5.5.0-rc6-sunxi64 I've got sound through hdmi  out of my OPi3 for first time ever.
Youtube seems to be working fine out of the box. VLC still doesn't work - system hunged with a mkv file I tried (I didn't have time to check with other files).
 
That's a huge step forward for me!
Kudos to the developers.
 

Yes, reading the bin is part of the commit f328584f7bff86858249bb358f1adcecde48388a
It's store in SID memory, as a part of ChipID bytes.
https://patchwork.kernel.org/patch/10903381/
How to set values is docummented in the dt-bindings patch.

Hi all.
I've made a new video about how to build your own Armbian image with the Armbian build script.
I also show how to set up virtualbox with a Ubuntu 18.04 image.
Here's the video.
Greetings, NicoD

Good luck....awaiting update!

You need to change the DTB file to version 5.88.190601 - 5.1.5
Located on the SD card: /boot/dtb-5.1.7-sunxi64/allwinner/sun50i-h6-orangepi-3.dtb
That fixed it for me on 5.88 dev 5.17.
 
Version linux-dtb-dev-sunxi64 version 5.90.190630 should work too, but I've not tested it.
 
Check post: 
 
 
 
 

Hello everyone!
I'm sorry for the time to my last post.
 
One week ago I decided to install the legacy version of Armbian debian based servers of Cubiebord v1 on my hackberry.
 
@Igor: I'll report what i'd do so you can choose if include an image for hackberry into your distributions.
 
0. download Armbian_5.20_Cubieboard_Debian_jessie_3.4.112.7z
1. write the image on SD
2. mount filesystem (need a Unix OS i.e. virtual machine with Ubuntu)
3. replace /boot/script.bin with my script.bin generated from hackberry.fex (see attachments and remove '.txt' extension from filename)
4. change boot.cmd to avoid frequency error and regenerate boot.scr (optionally - i do this step because i use an hdmi to vga converter)
 
Hackberry at this point is ready. (YEAH) .
 
The only problem that i have is with ethernet because dhcp not work (maybe for the driver?).
A workaround that i use is to setup a static ip.
 
For the main line distribution i don't know how to proceed because i'm not understand some step.
 
However this is a point to start for you (if you want) and for other people in community that like me have an Hackberry.
 
Happy new year to all!
Best regards,
Andrea
hackberry.fex.txt
script.bin.txt

./h3fakeoff 

No, I use  apkpure package manager. To much effort needs to be put in, to get google working

The OPi-H6 boards are WIP (aka "Work in Progress"), this means you need to build the images yourself.
It is pretty straight forward : https://docs.armbian.com/Developer-Guide_Build-Preparation/

here you find the overview:  https://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix

It is the same SoC so yes, it may suffer from all these issues as well.

Sorry, no link, it was direct contact with the German distributor by phone (and some luck, talking about my specfifc requirements).

I have seen many tutorials about connecting real time clock hardware on Orange Pi and Raspberry Pi.
What i didn't like was removing of fake-hwclock service, because I want that RTC works when it is connected, and fake-hwclock when RTC is not connected.
Therefore, I changed /sbin/fake-hwclock script to work in this way.
 
So, here is how to do this, tested on OrangePi+2E, Armbian Ubuntu legacy kernel:
Purchase cheap DS3231 module on eBay (cca. $1) like this one:
http://www.ebay.com/itm/DS3231-AT24C32-IIC-Modul-High-Precision-Real-Time-Clock-Module-Arduino-New-/292041844936?hash=item43ff0ce8c8:g:d80AAOSwdGFYtsFP
Put battery in module.
Shutdown and powerof OPi and connect module:
Orange (i2c0 bus) RTC module (DS3231 RTC + 24C32 eeprom) 1 3.3V 2 VCC 3 PA12 (TWI0_SDA/DI_RX/PA_EINT12) 3 SDA 5 PA11 (TWI0_SCK/DI_TX/PA_EINT11) 4 SCL 9 GND 1 GND Power up OPi
Install i2c-tools.
sudo apt install i2c-tools Type command:
i2cdetect -y 0 You should see:
0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- 57 -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- This means that module is connected properly and that we have DS3231 on address 0x68 and eeprom 24C32 on address 0x57.
Type:
sudo echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-0/new_device i2cdetect -y 0 You should see:
0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- 57 -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- This means that system is now using our RTC. Also, now should exist new device /dev/rtc1
Be sure that your system time is right, and type:
sudo hwclock -w -f /dev/rtc1 Now our RTC must have right time. Check with:
sudo hwclock -r -f /dev/rtc1 If everithing was ok, copy /sbin/fake-hwclock to bacup (just in case)
sudo cp ~/programming/sh/fake_hwclock/sbin/fake-hwclock /sbin/fake-hwclock Edit /sbin/fake-hwclock and place this code in it:
Reboot.
Now you should have right system time backed up by RTC.
 

We stopped to deal with this kernel (3.4.y) a long time ago and you will not find many people around that still do something about it. We fixed a ton of issues but it's impossible to fix them all with resources that are around. Fixes that were discovered are usually implemented. That's what our project essentially do.
 
Virtually all devs are working only on a modern kernel, (4.17.y ->), which will soon cover most of the functionality. Actually, when video/3D acceleration is working, these old kernel images are going to be trashed. We keep them solo for multimedia capabilities.
 
This is an old issue which is gone from my head so rather try to do some search for a possible solution.