[BPI-R2] Kernel Development

Because there reads 4.20-lima. Anyway no single line in 4.20 dmesg that say mali/lima, no /dev/mali. I think 450 chip dosn’t detect. If rgmii fix 5.4.12 net then I use it and try arm mali driver. It is binary but if it works I can get functional wayland (X support is dropped somewhere 2016) Is there any lima debug bootparams to try, maybe find why chip dosn’t detect?

btw 4.20-lima changes wan mac address to 7e:d2:65:22:b7:a6 is that correct?

Edit: next boot: 4.20-lima changed wan mac to 32:e8:59:bd:bb:6a. This randomize every boot?? not good in dhcp enviroment.

Well… No lima in 4.20 so back to 5.4.12 where is not lima but newer kernel. trgmii fix seems to work and brings wan and lanX’s up. But bogus eth1 is missing and it give some startup broblems (4.4.70-bpi is eth0+eth1 only) backwards compatibility is removed when say rc-update del net.eth1 …

5.4.12 get wan mac 0e:04:21:1f:4e:aa. I hope this is permanent or need to hardcode something. Maybe reboot test and now it is 92:76:ca:b9:2f:4f. Random MAC is really bad. Many times worse than hardcoded. My ISP offer only one mac at time, next is ok when previous expire. They offer public ip but only one per house. During board reboots wan mac needs to keep same. So need to hardcode something in udev rules… brr

R2 has no fixed mac…you can set it via dts or in your system (ip link set wan address xx:yy:zz up)

Was change to rgmii successful to fix wan-issue? I had not applied the trgmii-patch because i’ve found missing pause there and left second gmac patch.

your 4.19 have fixed system. Maybe in dts ??

Anyway I have not found functional udev rules yet and need to stop tests until my test enviroment dhcp server run out ips. So I fixed it gentoo way /etc/conf.d/net line mac_wan=“92:76:ca:b9:2f:4f”. It is not so general than udev rules but works temporal solution…

Yes Yes, it works now, but eth1 is missing (minor broblem)

Edit: and no. I started my laptop and tested bridge it dosn’t work. It take long until link indicators rise up and no ping. Indicators blink when pinging but no response… So wan interface works but no br0 (lan0-lan3). Any ideas?

1 Like

Have you put br0 and lan ports up?

I experieced a problem when directly connect clients (without switch). Here remote side does not detect link (ethtool). local on r2 link is detected. if i reset remote side (by setting mdix which is reported as unsupported on setting it) the link goes up. If i put switch on lan-ports there is no problem…i guess it is caused by phylink-conversion and related to link-mode detection

Yes I think they are up. It worked in 4.19. Atleast ifconfig show br0 have static ip and dmesg show lan0-lan3 entered promiscouis mode.

I take laptop wire (lan0) out and replugged but now it dosn’t do link at all. So I plugged laptop to “fresh” lan1 and it thinked long but rise link indicators up. Compiled ethtool and it show link in laptop but R2 “Link detected: no”. I make replug in lan1 until indicators go off then plug in. Indicators rise fast - like normal plug in. R2 ethtool say no link, laptop ethtool say link present. Then plug to lan0 and suprise link indicators on fast. R2 ethtool say no link laptop ethtool say link present. Then plugged lan3, link fast on, laptop ethtool say link on, R2 ethtool say no link. Still no ping.

Edit: ip link set lan3 up

Then R2 ethtool show link on and ping starts to rock. This is new “feature” in 5.4.12 vs. 4.19 so it needs some pre up tweaking in br0. Doable but not good. I tested to replug lan3 and ping still ok. So ip up once is maybe enough.

Edit2: cat: /sys/class/thermal/thermal_zone0/temp: Invalid argument

So no cputemp??

1 Like

strange…maybe mt7622 thermal patches breaking thermal on r2…reverted these 2 and it is working again

git revert ad3c4417bae1721673daaca6f82cb28106660f23 42afb7418745ea5843fe7d98860320499191d67f

for port set up…afair also in lower kernel-versions port have to be set up…have this also in my wiki (define manual in interfaces-file)

have it “fixed” by removing a return-value which causes probe failing

if (mt->conf->extract(mt, buf)) {
        dev_info(dev, "Device not calibrated, using default calibration values\n");
-               ret = -EINVAL;
+ //             ret = -EINVAL;
}

Gentoo fix in /etc/conf.d/net is not functional. For some reason ip link set up needs time before it works. So I put it local.d/ so executed late. Hope it is enough delay. Atleast it seems to work after testboot…

brr… forum max reply count, need to wait 1hr… Put to think if I put new forum online only for R2 talk but maybe later…

Tryed:

commented out crosscompiles but it dosn’t compile:

/home/eros/src/DX910-SW-99002-r10p0-00rel0/driver/src/devicedrv/mali/linux/mali_memory.c:186:11: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] .fault = mali_mem_vma_fault, ^~~~~~~~~~~~~~~~~~ /home/eros/src/DX910-SW-99002-r10p0-00rel0/driver/src/devicedrv/mali/linux/mali_memory.c:186:11: note: (near initialization for ‘mali_kernel_vm_ops.fault’) cc1: some warnings being treated as errors make[2]: *** [scripts/Makefile.build:266: /home/eros/src/DX910-SW-99002-r10p0-00rel0/driver/src/devicedrv/mali/linux/mali_memory.o] Error 1 make[1]: *** [Makefile:1652: /home/eros/src/DX910-SW-99002-r10p0-00rel0/driver/src/devicedrv/mali] Error 2 make[1]: Leaving directory ‘/home/eros/src/frank/BPI-R2-4.14-5.4-main’ make: *** [Makefile:207: all] Error 2

This stuff dosn’t look binary driver. Maybe it compiles against older kernels. Lets try:

KDIR=/home/eros/src/frank/BPI-R2-4.14-4.19-main/ USING_UMP=0 BUILD=release make

And success: modinfo mali.ko filename: /home/eros/src/DX910-SW-99002-r10p0-00rel0/driver/src/devicedrv/mali/mali.ko version: r10p0-00rel0 author: ARM Ltd. license: GPL srcversion: E66DA6AC5CB69B428450DFA depends:
name: mali vermagic: 4.19.92-bpi-r2 SMP mod_unload ARMv7 p2v8 parm: mali_debug_level:Higher number, more dmesg output (int) parm: mali_max_job_runtime:Maximum allowed job runtime in msecs. Jobs will be killed after this no matter what (int) parm: mali_l2_max_reads:Maximum reads for Mali L2 cache (int) parm: mali_dedicated_mem_start:Physical start address of dedicated Mali GPU memory. (uint) parm: mali_dedicated_mem_size:Size of dedicated Mali GPU memory. (uint) parm: mali_shared_mem_size:Size of shared Mali GPU memory. (uint) parm: mali_boot_profiling:Start profiling as a part of Mali driver initialization (int) parm: mali_max_pp_cores_group_1:Limit the number of PP cores to use from first PP group. (int) parm: mali_max_pp_cores_group_2:Limit the number of PP cores to use from second PP group (Mali-450 only). (int) parm: mali_mem_swap_out_threshold_value:Threshold value used to limit how much swappable memory cached in Mali driver. (uint) parm: mali_max_system_fps:Max system fps the same as display VSYNC. (int) parm: mali_desired_fps:A bit lower than max_system_fps which user desired fps (int)

So need to boot back to 4.19 and test… Still 20min to wait freeing comments…

In 4.19 strange thing is that wan dosn’t bring up. I tryed poweroff 5min but it dosn’t help. So if use 5.4.12 once then there is no back to 4.19 tree? ip link set wan up give error: RTNETLINK answers: Network is down

And mali dmesg [ 311.563765] mali: loading out-of-tree module taints kernel. [ 311.577179] Mali: [ 311.577183] Mali device driver loaded

No /dev/mali. So there is something wrong in mt7623 mali450. Maybe some special parameters? Some more to dts?

4.19 has second gmac…so put up eth1 first.

What happens if you add patches from 5.3-lima to 5.4?

I found this in drivers/thermal/mtk_thermal.c . Commented out returnvalue, then recompile modules and cputemps works. Hmm, 5.4.12 run hotter (50C) than 4.19.

Noticed also hdparm -Tt /dev/sda

/dev/sda: Timing cached reads: 1442 MB in 2.00 seconds = 721.12 MB/sec Timing buffered disk reads: 640 MB in 3.00 seconds = 213.19 MB/sec

So cache runs faster than 4.19 cache (~500MB/s).

direct after boot i have:

root@bpi-r2:~# cat /sys/class/thermal/thermal_zone0/temp                        
28442

tried adding lima patches but don’t see anything in dmesg…

dts contains compatibles “mediatek,mt7623-mali” and “arm,mali-450”

the second should be picked up by driver

./drivers/gpu/drm/lima/lima_drv.c:346: { .compatible = "arm,mali-450", .data = (void *)lima_gpu_mali450 },

0004-defconfig-add-lima-driver.patch (710 Bytes) 0003-defconfig-add-CONFIG_VIDEO_MEDIATEK_JPEG.patch (924 Bytes) 0002-arm-dts-drop-larb3.patch (1,5 KB) 0001-arm-dts-mt7623-add-Mali-450-device-nodes.patch (2,5 KB)

Oh, forgot that I say rc-update del net.eth1 because it was incompatible with 5.4.12. I’ll test it now. Yes. It works…!

So I should test 5.3-lima first to see how it works…? Taking patch and putting them in newer kernel is something I not yet have skills to do(…?)

Based 4.19 mali/lima, 4.20-lima, 5.4.12 mali/lima, and Arm mali 450 drivers + 4.19, there is no mali chip found. So I think something is wrong. Maybe mt7623 need some special init before mali starts to work…? I’ll try compile ARM mali driver with debug mode. Maybe it gives some hints… Well it is not very helpful:

[ 1348.097924] mali: loading out-of-tree module taints kernel. [ 1348.148917] Mali<2>: [ 1348.148929] Inserting Mali v900 device driver. [ 1348.148937] Mali<2>: [ 1348.148940] Compiled: Jan 16 2020, time: 22:15:35. [ 1348.148943] Mali<2>: [ 1348.148945] Driver revision: r10p0-00rel0 [ 1348.148947] Mali<2>: [ 1348.148948] mali_module_init() registering driver [ 1348.149234] Mali: [ 1348.149238] Mali device driver loaded

There is these lines in readme: The kernel needs to be provided with a platform_device struct for the Mali GPU device. See the mali_utgard.h header file for how to set up the Mali GPU resources. In that file is so much defines to addresses that I can’t do anything. Need some mt7623 mali manual to check everything is correct…?

That will be a start…if it detects mali-chip you can try patches from my previous post on top of 5.4-main…i only skipped documentation patch because it is incompatible (moved from txt to yaml). I don’t know how to include it the right way

During night it compiles 5.3 and there is something in dmesg:

[    5.279750] lima 13040000.gpu: get core clk failed -517
[    5.285065] lima 13040000.gpu: clk init fail -517
[    5.289776] lima 13040000.gpu: Fatal error during GPU init
[    7.471625] lima 13040000.gpu: get core clk failed -517
[    7.477001] lima 13040000.gpu: clk init fail -517
[    7.481801] lima 13040000.gpu: Fatal error during GPU init
[    7.871798] lima 13040000.gpu: get core clk failed -517
[    7.884729] lima 13040000.gpu: clk init fail -517
[    7.897048] lima 13040000.gpu: Fatal error during GPU init
[    7.943544] lima 13040000.gpu: get core clk failed -517
[    7.956430] lima 13040000.gpu: clk init fail -517
[    7.968647] lima 13040000.gpu: Fatal error during GPU init
[   18.407713] lima 13040000.gpu: get core clk failed -517
[   18.407730] lima 13040000.gpu: clk init fail -517
[   18.407737] lima 13040000.gpu: Fatal error during GPU init
[   18.484041] lima 13040000.gpu: get core clk failed -517
[   18.484056] lima 13040000.gpu: clk init fail -517
[   18.484063] lima 13040000.gpu: Fatal error during GPU init
[   18.611961] lima 13040000.gpu: get core clk failed -517
[   18.611974] lima 13040000.gpu: clk init fail -517
[   19.304542] lima 13040000.gpu: get core clk failed -517
[   19.304556] lima 13040000.gpu: clk init fail -517
[   19.304564] lima 13040000.gpu: Fatal error during GPU init
[   18.611982] lima 13040000.gpu: Fatal error during GPU init

There is also line that like to see in other kernels: [ 6.795336] [drm] forcing HDMI-A-1 connector on

in 5.3-lima build.sh is broken (dpkg not found)

Anyway duckducking error message gives this:

So need to read all and transfer lima talk to correct thread or keep it in frank kernel?? I think it is good to get default kernel support lima??

at least it would be better using separate thread…

build.sh is not broken…only not adjusted for non-debian systems :stuck_out_tongue:

just patch out the checkdeps-function and you should can use it

just leave only “return 0” line inside this function

It works in 4.19 and 5.4. I can do by hand where it don’t work. Ofcourse it is posible to “emerge” dpkg to system or copy newer build.sh from 5.4… I’m quite new with R2 and gentoo. Moustly used dpkg based systems… For R2 gentoo is good to take all optimizations from hardware…

Back to lima, so it seems that @JohnnyWednesday have not shared codes yet…?

ARM offical driver fail to compile in 5.3: driver/src/devicedrv/mali/linux/mali_osk_time.c:57:2: error: implicit declaration of function ‘get_monotonic_boottime’; did you mean ‘getboottime’? [-Werror=implicit-function-declaration] get_monotonic_boottime(&tsval);

Maybe easy to fix but don’t know enough from kernel functions so don’t know is suggested substitution ok…?

Edit: Substitution seems to be ok, but there rises more errors so this driver is for 4.19 etc. kernels only /or someone needs to hack needed fixes. Maybe ARM people in future?

So lima is near to functional only some inits is missing…?

maybe build.sh is broken there…just use 5.4-main with patches i posted above… then you have same state (except doc-patch). and you don’t need to care about build.sh…use 5.3-lima/4.20-mali only as reference. do not spend any additional work to these older branches

and yes, i still did not get any code from johnny…i asked multiple times, but none yet…else i had included it in my repo anyhow.

so start your work on 5.4 and try to get it working there…

I just found that your 4.20-lima dosn’t configure by default CONFIG_DRM_LIMA. When add it to configuration compilation dosn’t work:

drivers/gpu/drm/lima/lima_drv.c: In function ‘lima_ioctl_gem_submit’:
drivers/gpu/drm/lima/lima_drv.c:105:10: error: ‘struct drm_lima_gem_submit_in’ has no member named ‘flags’
  if (args->flags & ~(LIMA_SUBMIT_FLAG_EXPLICIT_FENCE |
          ^~
drivers/gpu/drm/lima/lima_drv.c:105:22: error: ‘LIMA_SUBMIT_FLAG_EXPLICIT_FENCE’ undeclared (first use in this function); did you mean ‘LIMA_SUBMIT_BO_WRITE’?
  if (args->flags & ~(LIMA_SUBMIT_FLAG_EXPLICIT_FENCE |

In 4.19 there is no such option. I just try compile Alex 4.16 and it compile gpu part ok with CONFIG_DRM_LIMA=y. Maybe you can get patches from it on drop then 4.19-main? (or 4.19-lima?)

I have not tested it yet, need compile rest & modules & reboot…

I keep important that there is atleast one lima/mali working kernel that can use comparsion. 5.4 is good direction but need to start from working codebase?
And 2nd I have not yet skills to get patches from github and put in new kernel. Maybe some day…

in 5.3.0-rc1-bpi-r2 there is severe error:

[22176.859874] Buffer I/O error on dev sda2, logical block 0, lost sync page write
[22176.859895] EXT4-fs (sda2): I/O error while writing superblock
[22176.860024] EXT4-fs error (device sda2): __ext4_find_entry:1531: inode #7355111: comm make: reading directory lblock 0
[22176.860078] Buffer I/O error on dev sda2, logical block 0, lost sync page write
[22176.860097] EXT4-fs (sda2): I/O error while writing superblock
[22176.860257] EXT4-fs error (device sda2): __ext4_find_entry:1531: inode #7092414: comm make: reading directory lblock 0
[22176.860316] Buffer I/O error on dev sda2, logical block 0, lost sync page write
[22176.860337] EXT4-fs (sda2): I/O error while writing superblock
[22176.860475] EXT4-fs error (device sda2): __ext4_find_entry:1531: inode #7881299: comm make: reading directory lblock 0
[22176.860529] Buffer I/O error on dev sda2, logical block 0, lost sync page write
[22176.860550] EXT4-fs (sda2): I/O error while writing superblock
[22176.860675] EXT4-fs error (device sda2): __ext4_find_entry:1531: inode #7223390: comm make: reading directory lblock 0
[22176.860730] Buffer I/O error on dev sda2, logical block 0, lost sync page write
[22176.860750] EXT4-fs (sda2): I/O error while writing superblock
[22176.860867] EXT4-fs error (device sda2): __ext4_find_entry:1531: inode #8560318: comm make: reading directory lblock 0
[22176.860921] Buffer I/O error on dev sda2, logical block 0, lost sync page write
[22176.860941] EXT4-fs (sda2): I/O error while writing superblock

Need to boot 4.19 & do fsck

is @DeadMeat s 4.16-lima working? imho no public repo had working lima…but you can test it and report if it’s working and compare to 5.4-lima

It is not working and wlan&BT stuff need to disable because compile error. Lima dosn’t detect, same error than 5.3-lima:

[    1.238006] lima 13040000.gpu: get core clk failed -517
[    1.243301] lima 13040000.gpu: clk init fail -517
[    1.247977] lima 13040000.gpu: Fatal error during GPU init
[    3.415826] lima 13040000.gpu: get core clk failed -517
[    3.421189] lima 13040000.gpu: clk init fail -517
[    3.425974] lima 13040000.gpu: Fatal error during GPU init
[   12.891693] lima 13040000.gpu: get core clk failed -517
[   12.891708] lima 13040000.gpu: clk init fail -517
[   12.891715] lima 13040000.gpu: Fatal error during GPU init
[   12.907644] lima 13040000.gpu: get core clk failed -517
[   12.907658] lima 13040000.gpu: clk init fail -517
[   12.907665] lima 13040000.gpu: Fatal error during GPU init
[   12.975271] lima 13040000.gpu: get core clk failed -517
[   12.975288] lima 13040000.gpu: clk init fail -517
[   12.975294] lima 13040000.gpu: Fatal error during GPU init
[   13.004238] lima 13040000.gpu: get core clk failed -517
[   13.004255] lima 13040000.gpu: clk init fail -517

Were it try to get gpu clock, from dts??

It should give lines like:

[    8.492918] lima 13040000.gpu: bus rate = 500500000
[    8.492930] lima 13040000.gpu: mod rate = 500500000

please make separate lima-thread (maybe any exists already).

where did you get the lines? as i said, there is no working lima-kernel, so you can start with 5.4-main and my above patches and start debugging there…clocks and other setting are selected by dts (read and assigned by driver)