shaddow501 Posted February 20, 2020 Posted February 20, 2020 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?
martinayotte Posted February 20, 2020 Posted February 20, 2020 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.
shaddow501 Posted February 20, 2020 Author Posted February 20, 2020 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
martinayotte Posted February 20, 2020 Posted February 20, 2020 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 ...
shaddow501 Posted February 20, 2020 Author Posted February 20, 2020 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
martinayotte Posted February 20, 2020 Posted February 20, 2020 10 minutes ago, shaddow501 said: version 0.6.3 from: https://github.com/BPI-SINOVOIP/RPi.GPIO 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 ...
shaddow501 Posted February 20, 2020 Author Posted February 20, 2020 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
martinayotte Posted February 20, 2020 Posted February 20, 2020 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.
shaddow501 Posted February 20, 2020 Author Posted February 20, 2020 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
shaddow501 Posted February 20, 2020 Author Posted February 20, 2020 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 ?---+---+------+---------+-----+-----+
martinayotte Posted February 20, 2020 Posted February 20, 2020 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
shaddow501 Posted February 20, 2020 Author Posted February 20, 2020 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.
shaddow501 Posted February 21, 2020 Author Posted February 21, 2020 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!
lanefu Posted February 21, 2020 Posted February 21, 2020 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'
martinayotte Posted February 21, 2020 Posted February 21, 2020 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 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 ...
shaddow501 Posted February 21, 2020 Author Posted February 21, 2020 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?
shaddow501 Posted February 21, 2020 Author Posted February 21, 2020 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?
martinayotte Posted February 21, 2020 Posted February 21, 2020 3 minutes ago, shaddow501 said: 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? It seems like a can of worms ... Why don't you try using Legacy 4.19.y instead ?
shaddow501 Posted February 21, 2020 Author Posted February 21, 2020 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???
martinayotte Posted February 21, 2020 Posted February 21, 2020 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 ...
shaddow501 Posted February 21, 2020 Author Posted February 21, 2020 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 = <®_dcdc2>; +}; + +&cpu1 { + cpu-supply = <®_dcdc2>; +}; + +&cpu2 { + cpu-supply = <®_dcdc2>; +}; + +&cpu3 { + cpu-supply = <®_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>; +};
Werner Posted February 21, 2020 Posted February 21, 2020 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
martinayotte Posted February 21, 2020 Posted February 21, 2020 2 minutes ago, shaddow501 said: This is what I want to add. Maybe you can try to put 5.4.y compiled DTB into the 5.1.15 image and give it a try ...
shaddow501 Posted February 21, 2020 Author Posted February 21, 2020 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.
martinayotte Posted February 21, 2020 Posted February 21, 2020 3 minutes ago, Werner said: The oldest stuff I have in my archive is from July 31th. But none of those are for an A64 SoC ...
shaddow501 Posted February 21, 2020 Author Posted February 21, 2020 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
martinayotte Posted February 21, 2020 Posted February 21, 2020 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.
shaddow501 Posted February 21, 2020 Author Posted February 21, 2020 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.
shaddow501 Posted February 21, 2020 Author Posted February 21, 2020 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?
martinayotte Posted February 21, 2020 Posted February 21, 2020 To try figuring about this crash, you will need to change "verbosity=1" to "verbosity=7" in /boot/armbianEnv.txt ...
Recommended Posts