Jump to content

Kernel 5.4.18 to 5.5 GPIO Input Pull up doesnt work


shaddow501

Recommended Posts

Hello

 

It is funny that new kernels going out and  kill what developers have made working on older kernels..

For example I have had no issues with GPIOs pull up in 5.1.15-sunxi64 kernel.

 

On Kernel 5.1.15-sunxi64 I do not get those errors;

 

Python:

GPIO.add_event_detect(31, GPIO.RISING, callback=count1)
RuntimeError: Failed to add edge detection

 

I didnt have any issues with Kernel 5.1.15 but I cannot recreate it anymore.

 

Maybe this will help to give a clue of what is happening:

 

at 5.1.15 kernel:

In ArmbianEnv.text I have enabled the w1-gpio:

param_w1_pin=PC7

(PC7 Is GPIO-71)

 

gives:

cat /sys/kernel/debug/gpio
gpiochip1: GPIOs 0-255, parent: platform/1c20800.pinctrl, 1c20800.pinctrl:
 gpio-66  (                    |spi1.1              ) out hi 
 gpio-71  (                    |onewire@0           ) in  hi 
 gpio-120 (                    |bananapi-m64:red:pwr) out hi 
 gpio-142 (                    |bananapi-m64:green:u) out lo 
 gpio-143 (                    |bananapi-m64:blue:us) out hi 
 gpio-166 (                    |cd                  ) in  hi ACTIVE LOW
 gpio-233 (                    |usb0_id_det         ) in  hi IRQ 
 gpio-234 (                    |ads7846_pendown     ) in  hi IRQ 

gpiochip0: GPIOs 352-383, parent: platform/1f02c00.pinctrl, 1f02c00.pinctrl:
 gpio-354 (                    |reset               ) out hi ACTIVE LOW
 gpio-364 (                    |sysfs               ) in  lo 

 

Same command on 5.5 kernel:

cat /sys/kernel/debug/gpio
gpiochip1: GPIOs 0-255, parent: platform/1c20800.pinctrl, 1c20800.pinctrl:
 gpio-66  (                    |spi1.1              ) out hi 
 gpio-71  (                    |onewire@0           ) out hi 
 gpio-120 (                    |bananapi-m64:red:pwr) out hi 
 gpio-142 (                    |bananapi-m64:green:u) out lo 
 gpio-143 (                    |bananapi-m64:blue:us) out hi 
 gpio-166 (                    |cd                  ) in  hi ACTIVE LOW
 gpio-233 (                    |usb0_id_det         ) in  hi IRQ 
 gpio-234 (                    |ads7846_pendown     ) in  hi IRQ 

gpiochip0: GPIOs 352-383, parent: platform/1f02c00.pinctrl, 1f02c00.pinctrl:
 gpio-354 (                    |reset               ) out hi ACTIVE LOW
 gpio-356 (                    |shutdown            ) out hi 
 gpio-357 (                    |host-wakeup         ) in  lo 
 gpio-358 (                    |device-wakeup       ) out hi 

GPIO-71 >>>> OUT ??

it should be an input.

 

Something is mixed up with this kernel.

 

any recommendations?

1. a way to download and recompile the 5.1.15 version with the additional processor patch (that the board will not have a reset loop)?

2. A way to fix that GPIO issue?

 

 

 

 

 

 

 

 

Link to comment
Share on other sites

1 hour ago, shaddow501 said:

I have enabled the w1-gpio

In fact, OneWire use that GPIO pin as a bi-directional pin, this mean that this driver decide itself if it is a input or output depending of the flow of data.

Looking to all my boards where I've enabled OneWire, they all shows that the GPIO is seen as output.

But the DS18B20 attached to them are working fine by doing "cat /sys/bus/w1/devices/28-000003ebdd28/w1_slave", they are showing the temperature, so it means that the GPIO was turned as input during the feedback of the sensor.

 

Link to comment
Share on other sites

22 minutes ago, martinayotte said:

In fact, OneWire use that GPIO pin as a bi-directional pin, this mean that this driver decide itself if it is a input or output depending of the flow of data.

Looking to all my boards where I've enabled OneWire, they all shows that the GPIO is seen as output.

But the DS18B20 attached to them are working fine by doing "cat /sys/bus/w1/devices/28-000003ebdd28/w1_slave", they are showing the temperature, so it means that the GPIO was turned as input during the feedback of the sensor.

 

 

Well in both of my environments at the moment the DS18B20 is not connected one board with kernel 5.1.15 detect it as an input , and when loading on the same board the image with the 5.5.0 kernel it show as output and the GPIO error happens.

 

GPIO.add_event_detect(31, GPIO.RISING, callback=count1)
RuntimeError: Failed to add edge detection

 

Link to comment
Share on other sites

22 minutes ago, shaddow501 said:

Well in both of my environments at the moment the DS18B20 is not connected one board with kernel 5.1.15 detect it as an input , and when loading on the same board the image with the 5.5.0 kernel it show as output and the GPIO error happens.

This is only showing the "idle" state, and maybe the kernel maintainer decided that is should show "output" from now on ...  But this doesn't matter for the OneWire driver point of view !

22 minutes ago, shaddow501 said:

GPIO.add_event_detect(31, GPIO.RISING, callback=count1)
RuntimeError: Failed to add edge detection

This error is NOT related with the OneWire discussed above !

For this error, you need to investigate more, maybe the library your are using (and you didn't mentioned which one) is broken with newer kernel, I don't know ...

Link to comment
Share on other sites

9 minutes ago, martinayotte said:

This is only showing the "idle" state, and maybe the kernel maintainer decided that is should show "output" from now on ...  But this doesn't matter for the OneWire driver point of view !

This error is NOT related with the OneWire discussed above !

For this error, you need to investigate more, maybe the library your are using (and you didn't mentioned which one) is broken with newer kernel, I don't know ...

 

version  0.6.3

from:

https://github.com/BPI-SINOVOIP/RPi.GPIO

Link to comment
Share on other sites

10 minutes ago, shaddow501 said:

And which board and SoC are you using ?

 

BTW, I've just remember an older case where a person asked why input event wasn't working for him on H6, and we finally discovered that not all the GPIO banks provide interrupts on all GPIOs. He change the pin for another supporting interrupts and it was working fine . So, maybe it is the case here ...

Link to comment
Share on other sites

38 minutes ago, martinayotte said:

And which board and SoC are you using ?

 

BTW, I've just remember an older case where a person asked why input event wasn't working for him on H6, and we finally discovered that not all the GPIO banks provide interrupts on all GPIOs. He change the pin for another supporting interrupts and it was working fine . So, maybe it is the case here ...

I  am using BananaPI M64 board

Link to comment
Share on other sites

43 minutes ago, shaddow501 said:

I  am using BananaPI M64 board

This board is using A64 SoC, so only B/G/H banks are supporting interrupts.

2 hours ago, shaddow501 said:

GPIO.add_event_detect(31, GPIO.RISING, callback=count1)
RuntimeError: Failed to add edge detection

Also, here, you try using GPIO number 31 which is normally doesn't exist on A64. I don't know much about RPi.GPIO library, but maybe you should use defines like BPI_M64_31 which is, according to the source, GPIO_PB05 or GPIO37, then interrupt will work since B bank is on the list.

 

Link to comment
Share on other sites

I have now downloaded and installed again the GPIO lib.

and now it gone worse.

now I cannot operate any GPIO I get segmentation fault (core dumped).

 

Before I have updated the lib at least  GPIO output worked just GPIO.add_event_detect didnt.

 

I have found an old post of RPI but I am not sure that the same answer valid for me as well.

"CONFIG_STRICT_DEVMEM set true"

from this link:

https://stackoverflow.com/questions/30442719/getting-segmentation-fault-when-using-rpi-gpio-setup-on-raspberry-pi-2

 

Link to comment
Share on other sites

GPIO 31 is the pin number.

 

look at this:

 

+-----+-----+---------+------+---+---Pi ?---+---+------+---------+-----+-----+
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
 |     |     |    3.3v |      |   |  1 || 2  |   |      | 5v      |     |     |
 | 227 |   8 |   SDA.1 |  OUT | 0 |  3 || 4  |   |      | 5v      |     |     |
 | 226 |   9 |   SCL.1 |  OUT | 0 |  5 || 6  |   |      | 0v      |     |     |
 | 230 |   7 | GPIO. 7 |  OUT | 0 |  7 || 8  | 1 | OUT  | TxD     | 15  | 32  |
 |     |     |      0v |      |   |  9 || 10 | 1 | OUT  | RxD     | 16  | 33  |
 | 231 |   0 | GPIO. 0 |  OUT | 0 | 11 || 12 | 1 | OUT  | GPIO. 1 | 1   | 35  |
 | 234 |   2 | GPIO. 2 |  OUT | 0 | 13 || 14 |   |      | 0v      |     |     |
 | 235 |   3 | GPIO. 3 |  OUT | 0 | 15 || 16 | 1 | OUT  | GPIO. 4 | 4   | 34  |
 |     |     |    3.3v |      |   | 17 || 18 | 1 | OUT  | GPIO. 5 | 5   | 100 |
 |  98 |  12 |    MOSI |  OUT | 0 | 19 || 20 |   |      | 0v      |     |     |
 |  99 |  13 |    MISO |  OUT | 0 | 21 || 22 | 1 | OUT  | GPIO. 6 | 6   | 64  |
 |  97 |  14 |    SCLK |  OUT | 0 | 23 || 24 | 1 | OUT  | CE0     | 10  | 96  |
 |     |     |      0v |      |   | 25 || 26 | 1 | OUT  | CE1     | 11  | 66  |
 |  68 |  30 |   SDA.0 |  OUT | 1 | 27 || 28 | 1 | OUT  | SCL.0   | 31  | 67  |
 |  71 |  21 | GPIO.21 |   IN | 1 | 29 || 30 |   |      | 0v      |     |     |
 |  37 |  22 | GPIO.22 |   IN | 0 | 31 || 32 | 1 | OUT  | GPIO.26 | 26  | 39  |
 |  36 |  23 | GPIO.23 |   IN | 0 | 33 || 34 |   |      | 0v      |     |     |
 |  38 |  24 | GPIO.24 |   IN | 0 | 35 || 36 | 1 | OUT  | GPIO.27 | 27  | 361 |
 | 364 |  25 | GPIO.25 |   IN | 0 | 37 || 38 | 1 | OUT  | GPIO.28 | 28  | 359 |
 |     |     |      0v |      |   | 39 || 40 | 1 | OUT  | GPIO.29 | 29  | 360 |
 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 +-----+-----+---------+------+---+---Pi ?---+---+------+---------+-----+-----+

 

Link to comment
Share on other sites

4 minutes ago, shaddow501 said:

GPIO 31 is the pin number.

This grid is confusing since this grid says pin31 == GPIO.22, which doesn't exist on A64, but at least the BCM equivalent is 37 like I've said, but you need to use GPIO.setmode(GPIO.BCM) for that numbering.

I personnally relying more on shematics, and here is the one I've looked https://bananapi.gitbooks.io/bpi-m64/content/en/bpi-m64schematicdiagram.html

 

Link to comment
Share on other sites

1 minute ago, martinayotte said:

This grid is confusing since this grid says pin31 == GPIO.22, which doesn't exist on A64, but at least the BCM equivalent is 37 like I've said, but you need to use GPIO.setmode(GPIO.BCM) for that numbering.

I personnally relying more on shematics, and here is the one I've looked https://bananapi.gitbooks.io/bpi-m64/content/en/bpi-m64schematicdiagram.html

 

the name is not relevant i am toggling the 31 pin. 

 

I feel that you do not have much experience with the python GPIO of the BPI-M64,

but I can confirm that on the module with the kernel 5.1.15 all work.

same libs, same installation.

Link to comment
Share on other sites

Going from a problem to a problem

 

first there was an issue with the A64 needs a new patch.

but the only kernel that you can work with is the 5.4 or 5.5, you cannot compile with your previous working environment...

And now you get a whole now issues.

 

We are normal users, not Linux experts, if we were we wouldnt needed to ask questions of things that should work but doenst.

 

Asking for help it doesnt mean to throw us into a deeper hole..

its frustrating that you have to move to a newer kernel and you cannot compile the old one that worked!

Link to comment
Share on other sites

7 minutes ago, shaddow501 said:

I have  added:

KERNELBRANCH='tag:v5.1.21' to build/userpatches/lib.config

 

but I get:

 


 o.k. ] Checking git sources [ linux-mainline 5.1.21 ]
[ .... ] Creating local copy 
[ .... ] Fetching updates 
fatal: Couldn't find remote ref tags/5.1.21
[ .... ] Checking out 
error: pathspec 'FETCH_HEAD' did not match any file(s) known to git.

Where do I find the available working tags??

where does it look the source from?

why cant I build an older kernel?

 

Allwinner use's megous's  repo .  https://github.com/armbian/build/blob/master/config/sources/families/include/sunxi_common.inc#L12

 

you could look at see what he's using

 

also you could add to lib.conf

KERNELSOURCE='git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git'

Link to comment
Share on other sites

10 hours ago, lanefu said:

 

Allwinner use's megous's  repo .  https://github.com/armbian/build/blob/master/config/sources/families/include/sunxi_common.inc#L12

 

you could look at see what he's using

 

also you could add to lib.conf

KERNELSOURCE='git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git'

 

Thanks for the help finally was able to find the correct lib.

 

KERNELBRANCH='branch:orange-pi-5.1'  to build/userpatches/lib.config

 

And now it is downloading the correct lib.

 

I run the compile.sh

doesnt matter about full image or u-boot...

 

select bananapim64

 

and I get this error.

but WTF it stops me on orangepi-win????

why?

It should only compile for the bananapim64...

 

 

scripts/Makefile.lib:311: recipe for target 'arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dtb' failed

scripts/Makefile.build:486: recipe for target 'arch/arm64/boot/dts/allwinner' failed

  HOSTCC  scripts/conmakehash

Makefile:1228: recipe for target 'dtbs' failed

  HOSTCC  scripts/sortextable

  HOSTCC  scripts/asn1_compiler

  HOSTCC  scripts/extract-cert

[ error ] ERROR in function compile_kernel [ compilation.sh:378 ]

[ error ] Kernel was not built [ @host ]

[ o.k. ] Process terminated

 

 

Any suggestions? 

 

 

 

Link to comment
Share on other sites

8 minutes ago, martinayotte said:

Megous still have 5.1 branch, but I doubt it will work easily since Armbian will still try to apply 5.4 patches on top of this 5.1 tree ...

Is it possible to disable the 5.4 patches? that it will not apply it?

maybe it is possible to install the patches of 5.1 manually?

 

Link to comment
Share on other sites

3 minutes ago, martinayotte said:

It seems like a can of worms ...

Why don't you try using Legacy 4.19.y instead ?

 

Ok, I dont think you remember but I have first was on the 4.19.y and I had problem that w1-wire didnt work, wasnt recognized, then you offered me to move on to the 5.1 dev kernel, and there everything worked, so I staid there.

Then I have bought another BPI-M64 board apply it to the image that is working on the other board, then it didnt load and crash,  later on I have found out that there is an issue with the A64 processors that image would not load and crash.

 

Mow there is a patch and with kernel 5.5/5.4 I have some issues:

1. Wireless works very slow  with that kernel.

2. Processor workload is higher than then 5.1 kernel.

3. I have problems with the python GPIO.

 

I just want to get it working

I am not interested with PHD on Linux, just to have 2 boards that work without any problems.

it seems impossible due to the walls that need to go trough.

 

WHY IS IT SO COMPLICATED TO CREATE PREVIOUS KERNEL,UBOOT and so on? WHY??? 

Link to comment
Share on other sites

9 minutes ago, shaddow501 said:

WHY IS IT SO COMPLICATED TO CREATE PREVIOUS KERNEL,UBOOT and so on? WHY???

Because it is a snapshot in time, it hard to revert to builds from 8 months ago.

 

Do you still have that old 5.1.15 images ?

Would it help if I provided one of my old Pine64 images ? Although it is not BananaPi-M4, maybe it will still boot since it is also an A64 ...

Link to comment
Share on other sites

2 minutes ago, martinayotte said:

Because it is a snapshot in time, it hard to revert to builds from 8 months ago.

 

Do you still have that old 5.1.15 images ?

Would it help if I provided one of my old Pine64 images ? Although it is not BananaPi-M4, maybe it will still boot since it is also an A64 ...

 

I have the 5.5.15 images but I cannot add the patch that fix the resets...

 

I cant use old images since they do not contain this patch.

 

This is what I want to add.

 

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
index 7793ebb5d..5be6c0680 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -43,6 +43,7 @@
 /dts-v1/;
 
 #include "sun50i-a64.dtsi"
+#include "sun50i-a64-cpu-opp.dtsi"
 
 #include <dt-bindings/gpio/gpio.h>
 
@@ -108,6 +109,23 @@
 	status = "okay";
 };
 
+&cpu0 {
+	cpu-supply = <&reg_dcdc2>;
+};
+
+&cpu1 {
+	cpu-supply = <&reg_dcdc2>;
+};
+
+&cpu2 {
+	cpu-supply = <&reg_dcdc2>;
+};
+
+&cpu3 {
+	cpu-supply = <&reg_dcdc2>;
+};
+
+
 &dai {
 	status = "okay";
 };
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-cpu-opp.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64-cpu-opp.dtsi
new file mode 100644
index 000000000..578c37490
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-cpu-opp.dtsi
@@ -0,0 +1,75 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Vasily khoruzhick <anarsoul@gmail.com>
+ */
+
+/ {
+	cpu0_opp_table: opp_table0 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp-648000000 {
+			opp-hz = /bits/ 64 <648000000>;
+			opp-microvolt = <1040000>;
+			clock-latency-ns = <244144>; /* 8 32k periods */
+		};
+
+		opp-816000000 {
+			opp-hz = /bits/ 64 <816000000>;
+			opp-microvolt = <1100000>;
+			clock-latency-ns = <244144>; /* 8 32k periods */
+		};
+
+		opp-912000000 {
+			opp-hz = /bits/ 64 <912000000>;
+			opp-microvolt = <1120000>;
+			clock-latency-ns = <244144>; /* 8 32k periods */
+		};
+
+		opp-960000000 {
+			opp-hz = /bits/ 64 <960000000>;
+			opp-microvolt = <1160000>;
+			clock-latency-ns = <244144>; /* 8 32k periods */
+		};
+
+		opp-1008000000 {
+			opp-hz = /bits/ 64 <1008000000>;
+			opp-microvolt = <1200000>;
+			clock-latency-ns = <244144>; /* 8 32k periods */
+		};
+
+		opp-1056000000 {
+			opp-hz = /bits/ 64 <1056000000>;
+			opp-microvolt = <1240000>;
+			clock-latency-ns = <244144>; /* 8 32k periods */
+		};
+
+		opp-1104000000 {
+			opp-hz = /bits/ 64 <1104000000>;
+			opp-microvolt = <1260000>;
+			clock-latency-ns = <244144>; /* 8 32k periods */
+		};
+
+		opp-1152000000 {
+			opp-hz = /bits/ 64 <1152000000>;
+			opp-microvolt = <1300000>;
+			clock-latency-ns = <244144>; /* 8 32k periods */
+		};
+	};
+};
+
+&cpu0 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu1 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu2 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};
+
+&cpu3 {
+	operating-points-v2 = <&cpu0_opp_table>;
+};

 

 

Link to comment
Share on other sites

1 minute ago, Werner said:

The oldest stuff I have in my archive is from July 31th. It comes with kernel 5.2.4 already though. Maybe it helps anyways.

https://laet.pw/index.php/s/M2eXJKll5sdnlBN?path=%2F_archive%2F3107

 

Thanks but it wont work if it has not got that new patch that was only released last month.

Without that patch the board will crash at boot.

Link to comment
Share on other sites

3 minutes ago, martinayotte said:

Maybe you can try to put 5.4.y compiled DTB into the 5.1.15 image and give it a try ...

I cannot since I cannot boot the board in order to put the DTB inside...

but it doesnt crash at the dtb load but when the kernel loads.

 

There must be a way to recompile older kernel source and use it.

even with this armbian forum I have discovered how to to build different branch kernel older one.

but if you provide this option it should work.

I hope that there is a way

 

Link to comment
Share on other sites

1 minute ago, shaddow501 said:

I cannot since I cannot boot the board in order to put the DTB inside...

Don't you have another board that are still running ? If Yes, simply put your SDCard reader/writer into it USB and have access to it after mounting it in /mnt.

Link to comment
Share on other sites

3 minutes ago, martinayotte said:

Don't you have another board that are still running ? If Yes, simply put your SDCard reader/writer into it USB and have access to it after mounting it in /mnt.

 

Sorry, it is not a test that I am interested to waste my time with.

I need  a working solution in order to be able to create an image with the desired kernel.

And i am sure that everything in Linux should fit, if even an a letter not in the place it should be the compilation fails.

 

So I am sure going to this direction is a waste of time.

Link to comment
Share on other sites

My Building experience...

added:

KERNELBRANCH='branch:orange-pi-5.1'

BOOTBRANCH='tag:v2019.04' - (yes also tried with the latest version and came into same result below so wonder if I use the same kernel that runs on the other board)

 to build/userpatches/lib.config

 

 

Run the command...

sudo ./compile.sh  BOARD=bananapim64  RELEASE=bionic BUILD_MINIMAL=no BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no INSTALL_HEADERS=yes INSTALL_PATCHES=yes CREATE_PATCHES=yes

 

at the time it asks me for the mainline-kernel 5.1 to add my patch, I modify the "sun50i-a64-bananapi-m64.dts" file and add the second "sun50i-a64-cpu-opp.dtsi" needed file as well.

it create the patch that I have shown a few messages back.

 

compilation continue...

 

than  a bug...

Building image :

 

pkg-deb: building package 'linux-headers-5.1.21-sunxi64' in '../linux-headers-5.1.21-sunxi64_20.05.0-trunk_arm64.deb'.

dpkg-deb: building package 'linux-libc-dev' in '../linux-libc-dev_20.05.0-trunk_arm64.deb'.

dpkg-deb: building package 'linux-image-5.1.21-sunxi64' in '../linux-image-5.1.21-sunxi64_20.05.0-trunk_arm64.deb'.

dpkg-buildpackage: info: binary-only upload (no source included)

 

 

but after a while it want to install then into the image... but try to install not existent files...

 

[ .... ] Installing [ linux-image-current-sunxi64_20.05.0-trunk_arm64.deb ]

[ .... ] Installing [ linux-u-boot-current-bananapim64_20.05.0-trunk_arm64.deb ]

[ .... ] Installing [ linux-headers-current-sunxi64_20.05.0-trunk_arm64.deb ]

[ .... ] Installing [ armbian-config_20.05.0-trunk_all.deb ]

[ .... ] Installing [ armbian-firmware_20.05.0-trunk_all.deb ]

 

It doesnt install them since they are not exist on that name.

 

So I have changed the files names to current and apply them just after the compiler create the Image file, that the script can find those files and install them…

 

Ok... copy the image to the microSD and....... how lovely... after all the hours invested so far i get this present:

 

U-Boot SPL 2019.04-armbian (Feb 21 2020 - 23:45:31 +0200)
DRAM: 2048 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.2(debug):eda880f
NOTICE:  BL31: Built : 23:45:21, Feb 21 2020
NOTICE:  BL31: Detected Allwinner A64/H64/R18 SoC (1689)
NOTICE:  BL31: Found U-Boot DTB at 0x4097918, model: BananaPi-M64
INFO:    ARM GICv2 driver initialized
INFO:    Configuring SPC Controller
INFO:    PMIC: Probing AXP803 on RSB
INFO:    PMIC: Enabling DRIVEVBUS
INFO:    PMIC: dcdc1 voltage: 3.300V
INFO:    PMIC: dcdc5 voltage: 1.500V
INFO:    PMIC: dcdc6 voltage: 1.100V
INFO:    PMIC: dldo1 voltage: 3.300V
INFO:    PMIC: dldo2 voltage: 3.300V
INFO:    PMIC: Enabling DC SW
INFO:    BL31: Platform setup done
INFO:    BL31: Initializing runtime services
INFO:    BL31: cortex_a53: CPU workaround for 843419 was applied
INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x4a000000
INFO:    SPSR = 0x3c9


U-Boot 2019.04-armbian (Feb 21 2020 - 23:45:31 +0200) Allwinner Technology

CPU:   Allwinner A64 (SUN50I)
Model: BananaPi-M64
DRAM:  2 GiB
MMC:   Device 'mmc@1c11000': seq 1 is in use by 'mmc@1c10000'
mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1
Loading Environment from EXT4... ** File not found /boot/boot.env **

** Unable to read "/boot/boot.env" from mmc0:1 **
In:    serial
Out:   serial
Err:   serial
Allwinner mUSB OTG (Peripheral)
Net:   phy interface7
eth0: ethernet@1c30000
Warning: usb_ether using MAC address from ROM
, eth1: usb_ether
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 2 USB Device(s) found
scanning bus 3 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
3033 bytes read in 2 ms (1.4 MiB/s)
## Executing script at 4fc00000
U-boot loaded from SD
Boot script loaded from mmc
104 bytes read in 1 ms (101.6 KiB/s)
9444540 bytes read in 427 ms (21.1 MiB/s)
## Loading init Ramdisk from Legacy Image at 4fe00000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    9444476 Bytes = 9 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 4fa00000
   Booting using the fdt blob at 0x4fa00000
   Loading Ramdisk to 496fe000, end 49fffc7c ... OK
   Loading Device Tree to 000000004968b000, end 00000000496fdfff ... OK

Starting kernel ...

"Synchronous Abort" handler, esr 0x02000000
elr: ffffffffccee4000 lr : 000000004a002cf0 (reloc)
elr: 0000000040e30000 lr : 00000000bdf4ecf0
x0 : 000000004968b000 x1 : 0000000000000000
x2 : 0000000000000000 x3 : 0000000000000000
x4 : 0000000040080000 x5 : 0000000000000001
x6 : 0000000000000008 x7 : 0000000000000000
x8 : 00000000b9f23a00 x9 : 0000000000000002
x10: 000000000a200023 x11: 0000000000000002
x12: 0000000000000002 x13: 0000000000000160
x14: 00000000b9f23a2c x15: 00000000bdf4e274
x16: 0000000000000020 x17: 0000000000000000
x18: 00000000b9f2bde0 x19: 00000000bdfe43d0
x20: 0000000000000000 x21: 0000000000000400
x22: 0000000000000710 x23: 00000000bdf4ed18
x24: 0000000000000003 x25: 00000000b9f85408
x26: 00000000bdfd3e48 x27: 0000000000000000
x28: 00000000b9f81d20 x29: 00000000b9f23b20

Resetting CPU ...

resetting ...

 

The only thing  I can say now is:

 

WHAT?   WHAT WHAT??  WHAT WHAT WHAT??? WAHHHAHAAT???  WHAT WHAT, WHAT ??  WHAT?

 

Really I have no other words to say. corona virus?

 

 

 

 

 

 

 

 

 

 

 

Link to comment
Share on other sites

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

Important Information

Terms of Use - Privacy Policy - Guidelines