Jump to content

Some discovery while trying 5.20 builds

martinayotte

By martinayotte
in Advanced users - Development

 Share

Recommended Posts

martinayotte

martinayotte

Posted
Posted

Hi folks,

 

I've done a Armbian build for my OrangePi-Plus2e this morning, and discovered that U-Boot "fdtfile" is now set to sun8i-h3-orangepi-plus2e.dtb instead of sun8i-h3-orangepi-pc.dtb as previously.

Unfortunately, the sun8i-h3-orangepi-plus2e.dtb doesn't exist, I had to copy the sun8i-h3-orangepi-pc.dtb under the sun8i-h3-orangepi-plus2e.dtb name to make it boot.

 

Where in the build process we manage to set "fdtfile" during u-boot build ?

Is that done using mix of manipulations of configs found in config/boards/orangepiplus2e.conf (Zador recently changed it)

 

Also, on separate issue, I've discovered that /usr/lib/linux-u-boot-dev-orangepiplus2e_5.20_armhf/u-boot-sunxi-with-spl.bin wasn't written during the nand-sata-install, I had to manually do the "dd" to make it work. (But this isn't the first time I faced that, I had to do that in previous 5.17 too. Probably I will have to redo a new nand-sata-install with some traces it to figure out)

Link to comment
Share on other sites
martinayotte

martinayotte

Posted
  • Author
Posted

Ok ! Doing an upgrade of my OrangePi-PCPlus, I've narrowed the "nand-sata-install" issue ...

It try to write the u-boot-sunxi-with-spl.bin from the wrong path !

 

The trace has given me this wrong path :

 

/usr/lib/linux-u-boot-orangepipcplus_5.20_armhf/u-boot-sunxi-with-spl.bin

 

while the actual file is in this location (notice the missing "dev-" in the wrong one) :

 

/usr/lib/linux-u-boot-dev-orangepipcplus_5.20_armhf/u-boot-sunxi-with-spl.bin

2
Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted

Maybe we should add DT files as patches for all boards since they already exist here: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts

 

But I fear they won't work -- I just had a look into that for OPi Plus 2E and there are no device node for the external GbE PHY exists and cpufreq /dvfs scaling won't work also. In the past I simply used the DT stuff for BPi M2+ (adding the one missing led and the 3rd USB host port to it) for OPi Plus 2E but currently when testing montjoie's Ethernet driver this doesn't work either. So currently I simply rely on OPi Plus settings on OPi Plus 2E ignoring wrong USB config.

 

On a related note these are my current 'bleeding edge' settings regarding H3 GbE and A64 (there more performance and USB, but IIRC this needs a few fixes and cpufreq scaling is still not working there):

 

 

diff --git a/config/bootscripts/boot-pine64.cmd b/config/bootscripts/boot-pine64.cmd

index 54de2f4..9efed7d 100644

--- a/config/bootscripts/boot-pine64.cmd

+++ b/config/bootscripts/boot-pine64.cmd

@@ -1,3 +1,5 @@

+mw.l 0x1c20000 0x80001110

+mw.l 0x1c2005c 1

 

 if ext4load mmc 0 0x00000000 /boot/.next || fatload mmc 0 0x00000000 .next || ext4load mmc 0 0x00000000 .next; then

        setenv bootargs "console=ttyS0,115200 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 panic=10 consoleblank=0 enforcing=0 loglevel=1"

diff --git a/config/sources/pine64.conf b/config/sources/pine64.conf

index b3fdaf7..2d9d958 100644

--- a/config/sources/pine64.conf

+++ b/config/sources/pine64.conf

@@ -16,10 +16,12 @@ case $BRANCH in

 

        dev)

        BOOTBRANCH='branch:next'

-       KERNELSOURCE='https://github.com/apritzel/linux.git'

-       KERNELBRANCH='branch:a64-v5'

+       # KERNELSOURCE='https://github.com/apritzel/linux.git'

+       # KERNELBRANCH='branch:a64-v5'

+       KERNELSOURCE='https://github.com/Icenowy/linux-sunxi'

+       KERNELBRANCH='branch:a64/test/pine64'

        KERNELDIR='linux-pine64-dev'

-       GOVERNOR=ondemand

+       GOVERNOR=schedutil

        UBOOT_FILES="u-boot-with-spl.bin"

        ;;

 esac

diff --git a/config/sources/sun8i.conf b/config/sources/sun8i.conf

index 8b8bffe..d138484 100644

--- a/config/sources/sun8i.conf

+++ b/config/sources/sun8i.conf

@@ -9,9 +9,11 @@ case $BRANCH in

        ;;

 

        dev)

-       KERNELSOURCE='https://github.com/megous/linux'

-       KERNELBRANCH='branch:orange-pi-4.7'

-       KERNELDIR='linux-sun8i-mainline'

+       #KERNELSOURCE='https://github.com/megous/linux'

+       #KERNELBRANCH='branch:orange-pi-4.7'

+       KERNELSOURCE='https://github.com/montjoie/linux'

+       KERNELBRANCH='branch:sun8i-emac-wip-v4'

+       KERNELDIR='linux-sun8i-montjoie'

        ;;

 esac

 

 

 

Link to comment
Share on other sites
martinayotte

martinayotte

Posted
  • Author
Posted

I'm facing some other issues with 5.20 builds ...

 

U-Boot 2016.09-armbian seems to be unstable. I getting memory crashes once in awhile during boot. The kernel itself seems to be Ok since I've try it out with a previous 5.17 image.

[    9.085019] Unable to handle kernel paging request at virtual address 40ddb5a3
[    9.085024] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM

I've tried to overwrite u-boot with the old U-Boot 2016.07-armbian, but it didn't help :

[    9.007689] Unable to handle kernel paging request at virtual address ffffffef
[    9.007855] Unable to handlE kernel NULL pointer dereference at virtual address 00000048

What is strange, is that all this is under OrangePiLite, but it got is booted properly one time out of 10, and I didn't got such issue under OrangePiPlus2e neither OrangePiPC+.

Maybe question of luck ? I will see if multiple reboot on those last one will still be stable.

Link to comment
Share on other sites
martinayotte

martinayotte

Posted
  • Author
Posted

I'm start running out of ideas ...

I've done fresh 5.20 build with 4.7.4. This kernel works fine under a 5.17 image, but have the above problem with the fresh 5.20 image. Replacing u-boot on new 5.20 image with the old 2016.07 didn't work.

Next thing to test are the DTS themselves, placing back old ones to see.

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted

I'm start running out of ideas ...

I've done fresh 5.20 build with 4.7.4. This kernel works fine under a 5.17 image, but have the above problem with the fresh 5.20 image. Replacing u-boot on new 5.20 image with the old 2016.07 didn't work.

Next thing to test are the DTS themselves, placing back old ones to see.

How old was your v2016.07? We had some patches from v2016.09 like DRAM calibration patch for a while, so maybe you should try to build clean v2016.07 without any patches.

Link to comment
Share on other sites
martinayotte

martinayotte

Posted
  • Author
Posted

Not so old ... last time I've built an armbian with u-boot 2016.07 was on Sept 7, without any patches other the armbian build process.

Resulting build was Armbian_5.17_Orangepiplus2e_Debian_jessie_4.7.3.raw

 

The issue describe above always appear when systemd is starting a bunch of stuff, so maybe there is something in 5.20 rootfs itself that screwup something.

Link to comment
Share on other sites
martinayotte

martinayotte

Posted
  • Author
Posted

Some updates : updating my whole park of Oranges, I faced the same issue also on 1 orangepipc in my park of 4x PC, 1x One, 1x Plus2E, 1x PC+, 1x Lite.

So, the Lite and one PC had the same behaviour... I don't know how I did the u-boot replacement on the Lite last week, maybe I screwed up, but the guilty is really u-boot 2016.09, since debugging on the Pc reveal that reaplcing it with u-boot 2016.07 from previous 5.17 build fixed the issue.

Probably it is a DRAM issue as Zador suggested. What is strange is that 3 out of for 4 PC didn't get the issue : probably the DRAM isn't from the same batch ...

Link to comment
Share on other sites
martinayotte

martinayotte

Posted
  • Author
Posted

TKaiser, nope, I wasn't aware of this patch. Thanks ! I will gave it a try during next few days.

 

For the marking, with quick look, I don't see much differences between the guilty boards compare to others, but I will check more carefully with a magnifier.

Link to comment
Share on other sites
martinayotte

martinayotte

Posted
  • Author
Posted

Unfortunately, even with that H3 Rev A patch, my OPiLite refuse to boot 5.20.

Strangely, with this OPiLite, copying the old U-Boot 2016.07 doesn't fix the issue, like at the first try done last week.

 

EDIT : Doing the same new fresh build with H3 Rev A patch didn't work either on the guilty OPiPC.

So, for those 2 boards, I definitively need to stick with 2016.07... :-(

Link to comment
Share on other sites
martinayotte

martinayotte

Posted
  • Author
Posted

Ok ! Doing an upgrade of my OrangePi-PCPlus, I've narrowed the "nand-sata-install" issue ...

It try to write the u-boot-sunxi-with-spl.bin from the wrong path !

 

The trace has given me this wrong path :

 

/usr/lib/linux-u-boot-orangepipcplus_5.20_armhf/u-boot-sunxi-with-spl.bin

 

while the actual file is in this location (notice the missing "dev-" in the wrong one) :

 

/usr/lib/linux-u-boot-dev-orangepipcplus_5.20_armhf/u-boot-sunxi-with-spl.bin

 

About this bad path for u-boot-sunxi-with-spl.bin, I think the following patch should do the work.

 

But I would like someone testing it under the default branch before I do any commit :

diff --git a/scripts/nand-sata-install/usr/lib/nand-sata-install/nand-sata-install.sh b/scripts/nand-sata-install/usr/lib/nand-sata-install/nand-sata-install.sh
index bab4960..f49e1e9 100644
--- a/scripts/nand-sata-install/usr/lib/nand-sata-install/nand-sata-install.sh
+++ b/scripts/nand-sata-install/usr/lib/nand-sata-install/nand-sata-install.sh
@@ -124,9 +124,10 @@ EOF
                
                # determine u-boot and write it
                name_of_ubootpackage=$(aptitude versions '~i linux-u-boot*'| head -1 | awk '{print $2}' | sed 's/linux-u-boot-//g' | cut -f1 -d"-")
+               name_of_ubootbranch=$(aptitude versions '~i linux-u-boot*'| head -1 | awk '{print $2}' | sed 's/linux-u-boot-.*-//g' | cut -f1 -d":")
                version_of_ubootpkg=$(aptitude versions '~i linux-u-boot*'| tail -1 |  awk '{print $2}')
                architecture=$(dpkg --print-architecture)
-               uboot="/usr/lib/linux-u-boot-"$name_of_ubootpackage"_"$version_of_ubootpkg"_"$architecture""/u-boot-sunxi-with-spl.bin
+               uboot="/usr/lib/linux-u-boot-"$name_of_ubootbranch"-"$name_of_ubootpackage"_"$version_of_ubootpkg"_"$architecture""/u-boot-sunxi-with-spl.bin
                dd if=$uboot of=$emmccheck bs=1024 seek=8  >/dev/null 2>&1 || (echo "Error"; exit 0)
                
        elif [[ -f /boot/boot.cmd ]]; then
1
Link to comment
Share on other sites
tpm8

tpm8

Posted
Posted

Martin, folks,

 

I can confirm the

Unable to handlE kernel NULL pointer dereference at virtual address 000000

errors after a clean install from scratch of the current jessie 5.20 images (both vanilla or legacy) and updating all packages (apt-get upgrade) on my cubietruck.

 

Sometimes I saw crashes during boot but mostly with some load. Lima memtester and cpufreq-ljt-stress-test both crash the cubie after few seconds.

 

Downgrading uboot from 5.23 to 5.17 ( linux-u-boot-cubietruck_5.17_armhf.deb ) fixes this problem.

 

With uboot 5.17 both Lima memtester and cpufreq-ljt-stress-test run without any errors or crahes.

 

Any chance, this can be fixed? For the moment, I put the uboot package on hold for apt-get upgrade.

 

Thx

Tobias

Link to comment
Share on other sites
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