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
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?
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.
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?
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
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:
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
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
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)