Since the two last days, I'm working on switching SUNXI-DEV to 5.2.y ...

I'm almost done, tested few of my boards, I will do more boards and probably commit my work tomorrow !

 

@Igor , I've faced again the u-boot issue about fdtfile discrepancy : /boot/dtb/sun50i-h3-orangepi-zero-plus2.dtb vs /boot/dtb/sun50i-h3-orangepi-zeroplus2.dtb

Since no one complained about U-Boot upgrade compatibility, I think we should forget the "upgradable history" and get finally for formal mainline filenaming ...

I had that as a user, very frustrating.

 

How can we make users aware?

Also advise about this heavy change (because breaking the upgrade path)  on the download site.

What else can be done, ideas?

6 hours ago, martinayotte said:

get finally for formal mainline filenaming ...

But kernel upgrade on this board will result in "fdt_file not found" if we don't correct this, right?

5 hours ago, Igor said:

But kernel upgrade on this board will result in "fdt_file not found" if we don't correct this, right?

This is what is already happening even with new image...

Since we never got "end user complains on upgrades" (probably because there is no much end users for that board), I would rather forget about "upgrades" and make sure new images are working.

 

1 hour ago, martinayotte said:

I would rather forget about "upgrades" and make sure new images are working.

It is development, so no worries here.

If the dev branch reaches next at any near or far future time upgrades should (must?) work properly. 

4 hours ago, martinayotte said:

Since we never got "end user complains on upgrades" (probably because there is no much end users for that board),

well, upgrade of Kernel is no longer automatic, so user may not even know that ?   ==  no breaking boards?

 

3 hours ago, Werner said:

If the dev branch reaches next at any near or far future time upgrades should (must?) work properly.  

fine, however, any idea how to fix that when it reaches next ?

 

37 minutes ago, Tido said:

fine, however, any idea how to fix that when it reaches next ?

Maybe with some kind of hack by having DTB copied under both /boot/dtb/sun50i-h3-orangepi-zero-plus2.dtb and /boot/dtb/sun50i-h3-orangepi-zeroplus2.dtb names...

could this also be done with a symlink?

So the file is only there once.

7 minutes ago, Tido said:

could this also be done with a symlink?

Sure !

I won't commit my work today, I still have some boards updates to do !

Maybe tomorrow ...

Commits for the switching to 5.2.y is now done !

(Hoping I didn't forget too much ... Still few patches to fix, such as startup logo, but it is not an hurry ...)

 

I'm probably missing something, but why are lima patches still there? They should not be needed with 5.2 anymore and they even shouldn't apply.

8 minutes ago, jernej said:

why are lima patches still there?

Hi @jernej , I'm not an expert on lima at all, so there are about 35 patches there, they were still applied successfully except one or two.

Maybe you or other can provide help to determine which ones we still want to keep ...

I don't really know which lima patches are strictly needed, but most of them should be in 5.2 (I''m no lima expert either).

If Lima is coming with 5.2.y (is it?) then all those should go out. If they apply correctly its possible that location has been changed. I also don't know without research. In any case this functionality was at the "yes it works, but not usable" level. I doubt that changed in last few months. An alternative closed source variant is worked on. IMO, move those patches away for now.

lima userspace driver is merged to mesa 19.1, and latest develop lima is based on 18.3.0. and the good news is mesa used in debian 10 is 18.3.6. so its very easy to rebuild mesa debs for debian 10.

 

I have done ARM64 debs build, and ARM debs is on going.

 

https://github.com/zhangn1985/lima_gpu_drv

7 hours ago, Igor said:

In any case this functionality was at the "yes it works, but not usable" level. I doubt that changed in last few months.

Well, driver is what it is. More important bit is mesa and there was significant advancement. But you have to use mesa master, 19.1 is not so good.

 

7 hours ago, ning said:

latest develop lima is based on 18.3.0

What do you mean by that? Development is done in mesa master branch now, everything else is deprecated, including lima fork, where initial development was done.

so you are an expert on Mesa to back port Lima from 19.1 to 18.3.6?

why not directly use develop branch? 

12 minutes ago, ning said:

so you are an expert on Mesa to back port Lima from 19.1 to 18.3.6?

No, I'm not. I'm just following Lima PRs in Mesa repo.

 

13 minutes ago, ning said:

why not directly use develop branch?

Because it's missing a lot of fixes and improvements? Why not use mesa master directly? I see backporting as a waste of time (Arch user here :)).

because Debian 10 is using 18.3.6 not master.  if using master branch, there may be a lot of compact issue. 

 

there maybe some additional fixes in master branch, but we don't know whether the fixes are for master or common fixes. 

 

you are Arch Linux user, maybe master branch is better for you. 

Ran into an issue with selinux.

it causes init to hang because it cant find /lib/aarch64-linux-lib/libaudit.so.1

 

the difference appears to be next this configured and dev doesn't

CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0 

Worked fine once i readded config option

 

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

On 7/14/2019 at 1:32 PM, lanefu said:

Ran into an issue with selinux.

it causes init to hang because it cant find /lib/aarch64-linux-lib/libaudit.so.1

 

the difference appears to be next this configured and dev doesn't

CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0 

Worked fine once i readded config option

 

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

any concerns with above @martinayotte?

9 hours ago, lanefu said:

any concerns with above @martinayotte?

I'm not fluent with selinux at all .

All my boards booted without issues ...

Do you have any repro steps ?

build fresh dev image from master or OrangePi PC2, build fresh filesystem.

 

 

I have an OrangePi One running user-built image with 5.2.1 kernel before the mentioned change above and is booting flawless. An OrangePi One Plus also booting Linux 5.2.0 without a problem.

3 hours ago, Werner said:

I have an OrangePi One running user-built image with 5.2.1 kernel before the mentioned change above and is booting flawless. An OrangePi One Plus also booting Linux 5.2.0 without a problem.

OpiOne uses different kernel config tha sunxi64

 

OpiOnePlus uses different patch dir than sunxi64

haha.. I just built another image.. and now I can't reproduce... must have been another quirk with that bad rootfs image

 

thanks for checking @Werner @martinayotte

No worries =)

@martinayotte I have a question, why KERNELSOURCE="https://github.com/megous/linux" in sunxi_common.inc?

 

why not mainline kernel?