Jump to content

Armbian 20.02 (Chiru) Release Thread

lanefu

By lanefu
in Armbian build framework

 Share

Recommended Posts

chwe

chwe

Posted
Posted
2 hours ago, Igor said:

@chwe I meant Orangepi 4 :)

right that one is on my todo list as well.. :D

 

I got fooled by their documentation which mentioned a way to reset clock of eMMC to enter maskroom but then I couldn't erase it.. @piter75 wrote how he did it with the buttons so that I'm soon ready to test it.

 

I've the patches for integrating it into rockchip64 family (u-boot and 4v4 kenel) laying around since days.. (if we will base it on nanopi m4v2 we would have to change them a bit cause different bsp kernel and u-boot) but not tested cause the stock firmware didn't try do boot SD card for me. Will be tested once pinebooks display doesn't fool me anymore.. btw @TonyMac32 I might switch to upstram 2020 u-boot with the pinebook if you don't mind.

orangepi4_uboot.patch orangepi4_kernel.patch

TonyMac32

TonyMac32

Posted
Posted

No complaints from me, once I get kernel hell straightened out on renegade and friends I want to circle around and u-boot 2020 the tinker as well, and I might see if the MiQi will survive it, it seemed to dislike 2018+ last time ...

Sent from my Pixel using Tapatalk

chwe

chwe

Posted
Posted
9 minutes ago, TonyMac32 said:

No complaints from me,

well you've no chance I already set up the pinebook in rk3399 with u-boot 2020:

  

U-Boot 2020.01-armbian (Jan 21 2020 - 23:08:47 +0100)

Model: Pine64 Pinebook Pro
DRAM:  3.9 GiB
PMIC:  RK808 
MMC:   dwmmc@fe320000: 1, sdhci@fe330000: 0
In:    serial@ff1a0000
Out:   serial@ff1a0000
Err:   serial@ff1a0000
Model: Pine64 Pinebook Pro
## Error: Can't overwrite "serial#"
## Error inserting "serial#" variable, errno=1
rockchip_dnl_key_pressed: adc_channel_single_shot fail!
Net:   No ethernet found.
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found U-Boot script /boot/boot.scr
2940 bytes read in 6 ms (478.5 KiB/s)
## Executing script at 00500000
Boot script loaded from mmc 1
143 bytes read in 6 ms (22.5 KiB/s)
7118384 bytes read in 752 ms (9 MiB/s)
20722176 bytes read in 2178 ms (9.1 MiB/s)
72693 bytes read in 17 ms (4.1 MiB/s)
2698 bytes read in 9 ms (292 KiB/s)
Applying kernel provided DT fixup script (rockchip-fixup.scr)
## Executing script at 39000000
## Loading init Ramdisk from Legacy Image at 06000000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    7118320 Bytes = 6.8 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 01f00000
   Booting using the fdt blob at 0x1f00000
   Loading Ramdisk to f5853000, end f5f1cdf0 ... OK
   Loading Device Tree to 00000000f57d8000, end 00000000f5852fff ... OK

Starting kernel ...

[    2.647157] Internal error: Oops: 96000004 [#1] PREEMPT SMP

 

it seems it doesn't like my new DT.. :rolleyes: but u-boot works fine and blobfree.. :)

2
martinayotte

martinayotte

Posted
Posted

BTW, about PinebookPro display issue, to make sure it is not a u-boot related issue, I've took the working 4.4.198 image, and I've copied the 5.4.13 into same SDCard, and switched the symbolic links in /boot back and forth between 4.4.198 and 5.4.13, and the issue is present only in latest one, confirming that it is not u-boot related ...

chwe

chwe

Posted
Posted

https://github.com/armbian/build/pull/1759

 

go out and mess with it.. :P

 

it could still be u-boot related.. I'm not sure how pwm works in mainline.. :P Could be that there's a difference between mainline and BSP kernel. Well I guess I've to dive into Tobias mainline kernel deeper to figure out what goes wrong here.. A diff off his defconfig compared to a defconfig based on our .config didnd't show any obvious oddity. 

 

martinayotte

martinayotte

Posted
Posted
47 minutes ago, chwe said:

A diff off his defconfig compared to a defconfig based on our .config didnd't show any obvious oddity.

Right ! I've done that several times since 3 days, but my eyes didn't found something obvious, only few things I added in new builds but without success ...

chwe

chwe

Posted
Posted

well I'll fire up the pinebook now with the rk3399 4.4 kernel (e.g. integrate it into friendly arms fork) and see if this works. If that works we would at least have 4.4 and likely @JMCC multimedia stuff working. :) I don't get why the driver doesn't even try to probe the display.. so something must be fishy here.. Someone would then need to test if this works with stock image on eMMC cause I removed eMMC and I don't want to open and close the pinebook for a 100 times during development (I don't see a reason for not, but I didn't expect the display fooling me that hard either).

 

But hey we have a new rk3399 SBC with it's own UPS working.. :lol:

chwe

chwe

Posted
Posted
13 minutes ago, TonyMac32 said:

...is the legacy kernel not working with display right now? My last build did...

well having it in rk3399 means we swap to friendly elecs 4.4 kernelfork.. First attempt display backlight fired up but no display output (well I know the reason I just forgot to patch panel-simple).. and a few bits here and there might be needed as well (at least I found out about one).

TonyMac32

TonyMac32

Posted
Posted

I saw this on my RK3328 boards, but it's now been reported on Allwinner as well, the recent libdrm updates are killing our display manager.  As soon as I update my image the menus and things are no longer displaying properly, things are missing, invisible, etc.  lima related perhaps?

 

 

Igor

Igor

Posted
Posted
1 hour ago, TonyMac32 said:

Lima more or less needs shut off on Bionic


I propose to upload known to work packages to apt.armbian.com bionic-desktop and change their version. It's an ugly hack, but patch the problem.

TonyMac32

TonyMac32

Posted
Posted
You can, but the conversation around Lima/Mesa maturity was quite clear, that the performance will be terrible/buggy without using a much newer Mesa library (19.3.x minimum)

Sent from my Pixel using Tapatalk

JMCC

JMCC

Posted
Posted
4 hours ago, TonyMac32 said:

performance will be terrible/buggy without using a much newer Mesa library (19.3.x minimum)

Well, they have backported mesa to bionic-updates, up until 19.2 so far. So it is very likely that in the near future they will backport 19.3 too.

 

Maintaining our own package for mesa 19.3 would be a source for trouble, IMO.

I propose to disable glamor in /etc/X11/xorg.conf.d/01-armbian-defaults.conf, by adding something like this: 

Section "Device"
    Identifier  "Default Device"
    Driver      "modesetting"
    Option      "AccelMethod"    "none"     ### "glamor" to enable 3D acceleration, "none" to disable.
EndSection

This will do the trick for the time being, and will make it very easy to enable acceleration when the necessary libs are available.

1
lanefu

lanefu

Posted
  • Author
Posted
2 hours ago, JMCC said:

Well, they have backported mesa to bionic-updates, up until 19.2 so far. So it is very likely that in the near future they will backport 19.3 too.

 

Maintaining our own package for mesa 19.3 would be a source for trouble, IMO.

I propose to disable glamor in /etc/X11/xorg.conf.d/01-armbian-defaults.conf, by adding something like this: 


Section "Device"
    Identifier  "Default Device"
    Driver      "modesetting"
    Option      "AccelMethod"    "none"     ### "glamor" to enable 3D acceleration, "none" to disable.
EndSection

This will do the trick for the time being, and will make it very easy to enable acceleration when the necessary libs are available.

 

 

I also suggested app pinning in irc

 

Quote

re lima / mwsa issue with ubuntu... I think a slightly more elegant alternative would be apt pinning... then its just a config file which could easily be updated if a fix comes out etc... https://www.howtoforge.com/a-short-introduction-to-apt-pinning-p2#-holding-a-package
 the ubuntu mirrors will keep the old revisions, so we should be fine

 

chwe

chwe

Posted
Posted
2 hours ago, JMCC said:

Well, they have backported mesa to bionic-updates, up until 19.2 so far. So it is very likely that in the near future they will backport 19.3 too.

at least for x86-64 mesa 19.3 works like a charm on bionic... :P 

  

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.3.2 - kisak-mesa PPA

but I don't think he provides armhf/arm64 packages for it.. :D

 

22 hours ago, TonyMac32 said:

...is the legacy kernel not working with display right now? My last build did...

and yes, it doesn't work with friendly arms kernel fork, and I honestly don't understand why it works with ayufans kernel.. :lol:

e.g. the supposed bits needed to get it working are missing in panel-simple (e.g. no timings nor clockspeed for the display we use)

 

https://github.com/ayufan-rock64/linux-kernel/blob/d3f1be0ed310d118ccf04cf9b691c92a914a97a9/drivers/gpu/drm/panel/panel-simple.c#L1295-L1321

 

vs. mrfixit (that's a different panel)

https://github.com/mrfixit2001/rockchip-kernel/blob/1440cd8cfcd029eb4f97c97c11f607e49d1986a3/drivers/gpu/drm/panel/panel-simple.c#L1330-L1353

 

I guess I need to understand how ayufan got the display working.. :ph34r: or why it works on his kernel even when he didn't touch panel-simple.. :D

martinayotte

martinayotte

Posted
Posted
2 hours ago, piter75 said:

Do we want to squeeze OrangePi 4 as WIP in this release?

I've done the merge, I've done a DEV build image, now I will test in few minutes ...

 

EDIT : This image was done using 5.4.0-rc1-ayufan, but it crashed :

 

 


[   52.970929] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000040
[   52.971085] mmc0: new ultra high speed SDR104 SDIO card at address 0001
[   52.971693] Mem abort info:
[   52.971695]   ESR = 0x96000004
[   52.972802]   EC = 0x25: DABT (current EL), IL = 32 bits
[   52.973273]   SET = 0, FnV = 0
[   52.973541]   EA = 0, S1PTW = 0
[   52.973825] Data abort info:
[   52.974077]   ISV = 0, ISS = 0x00000004
[   52.974448]   CM = 0, WnR = 0
[   52.974710] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000eeeba000
[   52.975278] [0000000000000040] pgd=0000000000000000
[   52.975718] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[   52.975959] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
[   52.976204] Modules linked in:
[   52.977113] mmc1: new high speed SDHC card at address 0007
[   52.977318] CPU: 5 PID: 46 Comm: kworker/5:1 Not tainted 5.4.0-rc1-rockchip64 #19.11.9
[   52.978237] mmcblk1: mmc1:0007 SD8GB 7.47 GiB
[   52.978478] Hardware name: OrangePi 4 (DT)
[   52.978490] Workqueue: events deferred_probe_work_func
[   52.979669] pstate: 60000005 (nZCv daif -PAN -UAO)
[   52.980090] pc : rt5651_set_jack+0x19c/0x2a8
[   52.980464] lr : rt5651_set_jack+0x198/0x2a8
[   52.980836] sp : ffff800011723970
[   52.981126] x29: ffff800011723970 x28: ffff8000111f3c50
[   52.981589] x27: 00000000ffffffed x26: ffff0000eef62a80
[   52.982053] x25: ffff0000eeea6080 x24: ffff0000eeea6210
[   52.982516] x23: ffff0000eeea6800 x22: 0000000000000000
[   52.982979] x21: ffff0000eeea6e88 x20: ffff0000eee97e80
[   52.983441] x19: ffff0000eee97a80 x18: 0000000000000004
[   52.983904] x17: 000000001607c088 x16: 00000000a05ad60e
[   52.984346]  mmcblk1: p1
[   52.984367] x15: ffff0000f1195e10 x14: ffff0000f0fec468
[   52.985050] x13: 0000000000000000 x12: ffff0000f1195e10
[   52.985513] x11: ffff0000f0fec248 x10: 0000000000000040
[   52.985976] x9 : ffff80001139ef58 x8 : ffff80001139ef50
[   52.986439] x7 : 0000000000000001 x6 : 0000000000000000
[   52.986902] x5 : 0000000000000fff x4 : 0000000000000002
[   52.987365] x3 : 0000000000000000 x2 : 3232882b279da800
[   52.987828] x1 : 0000000000000000 x0 : 0000000000000000
[   52.988291] Call trace:
[   52.988508]  rt5651_set_jack+0x19c/0x2a8
[   52.988852]  snd_soc_component_set_jack+0x18/0x28
[   52.989263]  soc_cleanup_component+0x1c/0x68
[   52.989636]  soc_remove_link_components+0x7c/0xc0
[   52.990046]  soc_cleanup_card_resources+0xb8/0x2e8
[   52.990464]  snd_soc_instantiate_card+0x288/0xb80
[   52.990874]  snd_soc_register_card+0xf8/0x120
[   52.991255]  devm_snd_soc_register_card+0x40/0x90
[   52.991666]  asoc_simple_probe+0x19c/0x3c8
[   52.992025]  platform_drv_probe+0x50/0xa0
[   52.992376]  really_probe+0xd8/0x2f0
[   52.992688]  driver_probe_device+0x54/0xe8
[   52.993047]  __device_attach_driver+0x80/0xb8
[   52.993427]  bus_for_each_drv+0x78/0xc8
[   52.993762]  __device_attach+0xd4/0x130
[   52.994098]  device_initial_probe+0x10/0x18
[   52.994463]  bus_probe_device+0x90/0x98
[   52.994799]  deferred_probe_work_func+0x6c/0xa0
[   52.995197]  process_one_work+0x1e0/0x338
[   52.995547]  worker_thread+0x240/0x440
[   52.995877]  kthread+0x120/0x128
[   52.996160]  ret_from_fork+0x10/0x18
[   52.996475] Code: 97d6448d 91010260 97d64491 f9400a60 (b9404000)
[   52.997007] ---[ end trace 95a88f66eaf64513 ]---
 

 

 

I will now try building an 5.5.0-rc7 and try again, but for now maybe I should also try to disable the "snd_soc" ...

 

EDIT: Disabling the "rt5651" node in DT bypassed the crash, it reach the "Welcome to Debian GNU/Linux 10 (buster)!", but no login prompt ! Rebooting again, it didn't reach the same place : I think it is thermal issue, because my board doesn't have heatsink, and RK3399 is barely touchable ... Let's cool it and I will try the 5.5.0-rc7 build when finished ...

piter75

piter75

Posted
Posted
1 hour ago, martinayotte said:

image was done using 5.4.0-rc1-ayufan, but it crashed

I almost deliberately omitted testing with "dev" ;-)

The codec crash should be fixed with this commit: https://github.com/armbian/build/commit/720959e43e46584107b6b28b8c3b7edeb7513d58

Nonetheless I cannot get "dev" to connect to WiFi as there is another crash coming from nl80211.

 

"current" boots reliably for me and WiFi works. Here you can find the output from armbianmonitor: http://ix.io/28fb

 

TonyMac32

TonyMac32

Posted
Posted

I verified the 1.5 GHz operating point for rk3328, had forgotten where the max frequency variable was set. The default is 1.3 GHz max, can be set by the user to 1.5. we are missing a 1.4 GHz operating point though.

Sent from my Pixel using Tapatalk

martinayotte

martinayotte

Posted
Posted

@piter75 , Is your OPi4 boot fine with CURRENT ?

What ever I try to boot, either CURRENT, DEV, or preview 5.5.0-rc7, I get the "Welcome to Debian GNU/Linux 10 (buster)!", but always end up with a freeze with "[   56.562910] systemd[1]: Failed to bump fs.file-max, ignoring: Invalid argument"... :angry:

 

Also, is there someone who find the schematic for OPi4 ?

 

Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept