Well, it is interesting that default serial console baudrate is 1500000 which is not supported by screen, my tools of the choice. 2017-08-17 12:52 GMT+03:00 Matthias Brugger <mbrugger@suse.com>:

On 08/12/2017 12:02 PM, Matwey V. Kornilov wrote:

...

Hello,

I will receive my rock64 board soon.

https://www.pine64.org/?page_id=7147

I would like to run some openSUSE on it. There are no upstream support but lets see what we could do.

A patch is on it's way. I might show up in v4.14: https://www.spinics.net/lists/arm-kernel/msg599638.html

Only missing and blocking bit is the pmic support: http://www.spinics.net/lists/devicetree/msg188756.html

Regarding u-boot support it still needs the first stage loader. You might want to check with this hacked up tree: https://github.com/mmind/u-boot-rockchip/commits/netboots/rock64

Have fun! Matthias

-- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

It seems that the following tools are binary only: https://github.com/rockchip-linux/rkbin/tree/master/tools They are required to convert u-boot to proprietary loader known format. Proprietary loader is required because there is no (yet?) support for SPL in u-boot for rk3328. The tools are also x86_64 only, so I wonder how could they be used in OBS to produce package for u-boot image in deployable format. 2017-08-24 20:49 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:

Well, it is interesting that default serial console baudrate is 1500000 which is not supported by screen, my tools of the choice.

2017-08-17 12:52 GMT+03:00 Matthias Brugger <mbrugger@suse.com>:

...

On 08/12/2017 12:02 PM, Matwey V. Kornilov wrote:

...

Hello,

I will receive my rock64 board soon.

https://www.pine64.org/?page_id=7147

I would like to run some openSUSE on it. There are no upstream support but lets see what we could do.

A patch is on it's way. I might show up in v4.14: https://www.spinics.net/lists/arm-kernel/msg599638.html

Only missing and blocking bit is the pmic support: http://www.spinics.net/lists/devicetree/msg188756.html

Regarding u-boot support it still needs the first stage loader. You might want to check with this hacked up tree: https://github.com/mmind/u-boot-rockchip/commits/netboots/rock64

Have fun! Matthias

-- With best regards, Matwey V. Kornilov

-- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Well, I see the patch series for enabling SPL for rk3328. Unfortunately, both my Rock64-s are in usage (with Debian ;)) and third is broken :( So, I cannot give it a try just now :( https://patchwork.ozlabs.org/cover/830462/ 2017-08-25 22:41 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:

I'll try to figure out how to use SPL u-boot instead.

2017-08-25 22:16 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:

...

It seems that the following tools are binary only: https://github.com/rockchip-linux/rkbin/tree/master/tools They are required to convert u-boot to proprietary loader known format. Proprietary loader is required because there is no (yet?) support for SPL in u-boot for rk3328. The tools are also x86_64 only, so I wonder how could they be used in OBS to produce package for u-boot image in deployable format.

2017-08-24 20:49 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:

...

Well, it is interesting that default serial console baudrate is 1500000 which is not supported by screen, my tools of the choice.

2017-08-17 12:52 GMT+03:00 Matthias Brugger <mbrugger@suse.com>:

...

On 08/12/2017 12:02 PM, Matwey V. Kornilov wrote:

...

Hello,

I will receive my rock64 board soon.

https://www.pine64.org/?page_id=7147

I would like to run some openSUSE on it. There are no upstream support but lets see what we could do.

A patch is on it's way. I might show up in v4.14: https://www.spinics.net/lists/arm-kernel/msg599638.html

Only missing and blocking bit is the pmic support: http://www.spinics.net/lists/devicetree/msg188756.html

Regarding u-boot support it still needs the first stage loader. You might want to check with this hacked up tree: https://github.com/mmind/u-boot-rockchip/commits/netboots/rock64

Have fun! Matthias

-- With best regards, Matwey V. Kornilov

-- With best regards, Matwey V. Kornilov

-- With best regards, Matwey V. Kornilov

-- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Hello, On Fri, 25 Aug 2017 22:16:09 +0300 "Matwey V. Kornilov" <matwey.kornilov@gmail.com> wrote:

It seems that the following tools are binary only: https://github.com/rockchip-linux/rkbin/tree/master/tools They are required to convert u-boot to proprietary loader known format. Proprietary loader is required because there is no (yet?) support for SPL in u-boot for rk3328. The tools are also x86_64 only, so I wonder how could they be used in OBS to produce package for u-boot image in deployable format.

There is rkflashtool https://github.com/linux-rockchip/rkflashtool which worked for me with some cheap rk33?? TV box for modifying a boot script on partition that is not accessible from Android. There was one caveat - the partitions were downloaded with some zero padding at the start. If you look for resources for Radxa Rock (rk3188) you can possibly find more about rockchip bootable card layout which may or may not work for you with 3328. HTH Michal -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On Tue, 29 Aug 2017 16:23:44 +0200 Andreas Färber <afaerber@suse.de> wrote:

Am 29.08.2017 um 14:08 schrieb Michal Suchánek:

...

On Fri, 25 Aug 2017 22:16:09 +0300 "Matwey V. Kornilov" <matwey.kornilov@gmail.com> wrote:

...

It seems that the following tools are binary only: https://github.com/rockchip-linux/rkbin/tree/master/tools They are required to convert u-boot to proprietary loader known format. Proprietary loader is required because there is no (yet?) support for SPL in u-boot for rk3328. The tools are also x86_64 only, so I wonder how could they be used in OBS to produce package for u-boot image in deployable format.

There is rkflashtool https://github.com/linux-rockchip/rkflashtool which worked for me with some cheap rk33?? TV box for modifying a boot script on partition that is not accessible from Android. There was one caveat - the partitions were downloaded with some zero padding at the start.

If you look for resources for Radxa Rock (rk3188) you can possibly find more about rockchip bootable card layout which may or may not work for you with 3328.

http://opensource.rock-chips.com/wiki_Main_Page is a good starting point - the workflow for 64-bit is slightly different.

Note that this is not about flashing but about creating the files to be flashed.

If rkflashtool works for your board you can download different partitions, backup them, upload your code into memory and execute it without making changes to storage, replace the content of different partitions on the medium with your own, observe the actual content change of the medium if you have offline access, restore the backups, etc.

Mainline U-Boot circumvents many of those problems by using its own FIT storage format, but it lags in enabling SPL for the various chipsets.

There is some 'magic' part at the start of the medium which you need to preserve for the medium to be bootable. Using rkflashtool this is preserved while you can make changes to the other parts. Getting this 'magic' right is somewhat error-prone so it is easier to start with a bootable image that works and change parts one by one. Thanks Michal -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Hello, Unfortunately, the wiki which had the information on reverse-engineering of the boot sequence is gone. There is an assortment of tools that can possibly accomplish this such as https://github.com/neo-technologies/rockchip-mkbootimg or https://github.com/naobsd/rkutils but I do not have a known working case for at least one board. I would expect the Olimex guide https://www.olimex.com/wiki/RK3188-SOM#How_to_prepare_your_microSD_card_with... gives usable instructions using free tools where possible. I guess I can try resurrecting my rk3188 board using these to test. Unfortunately, the tool supports only 3368 and not 3328. I should be possible to get the chip revision and loader from your original image, though. Thanks Michal On Tue, 29 Aug 2017 18:25:27 +0300 "Matwey V. Kornilov" <matwey.kornilov@gmail.com> wrote:

This all correct, but the issue is that u-boot binary (which is produced by obs) has to be wrapped into special container by rkflashtool before being written onto disk. Otherwise, first stage proprietary loader won't recognize it. Problem here that rkflashtool is available only in binary format for x86_64 architecture, and it is tricky to integrate them into OBS build pipeline (between u-boot and JeOS).

2017-08-29 17:40 GMT+03:00 Michal Suchánek <msuchanek@suse.de>:

...

On Tue, 29 Aug 2017 16:23:44 +0200 Andreas Färber <afaerber@suse.de> wrote:

...

Am 29.08.2017 um 14:08 schrieb Michal Suchánek:

...

On Fri, 25 Aug 2017 22:16:09 +0300 "Matwey V. Kornilov" <matwey.kornilov@gmail.com> wrote:

...

It seems that the following tools are binary only: https://github.com/rockchip-linux/rkbin/tree/master/tools They are required to convert u-boot to proprietary loader known format. Proprietary loader is required because there is no (yet?) support for SPL in u-boot for rk3328. The tools are also x86_64 only, so I wonder how could they be used in OBS to produce package for u-boot image in deployable format.

There is rkflashtool https://github.com/linux-rockchip/rkflashtool which worked for me with some cheap rk33?? TV box for modifying a boot script on partition that is not accessible from Android. There was one caveat - the partitions were downloaded with some zero padding at the start.

If you look for resources for Radxa Rock (rk3188) you can possibly find more about rockchip bootable card layout which may or may not work for you with 3328.

http://opensource.rock-chips.com/wiki_Main_Page is a good starting point - the workflow for 64-bit is slightly different.

Note that this is not about flashing but about creating the files to be flashed.

If rkflashtool works for your board you can download different partitions, backup them, upload your code into memory and execute it without making changes to storage, replace the content of different partitions on the medium with your own, observe the actual content change of the medium if you have offline access, restore the backups, etc.

...

Mainline U-Boot circumvents many of those problems by using its own FIT storage format, but it lags in enabling SPL for the various chipsets.

There is some 'magic' part at the start of the medium which you need to preserve for the medium to be bootable. Using rkflashtool this is preserved while you can make changes to the other parts. Getting this 'magic' right is somewhat error-prone so it is easier to start with a bootable image that works and change parts one by one.

Thanks

Michal

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Here, is how rockchip builds its u-boot: https://github.com/rockchip-linux/build/blob/debian/mk-uboot.sh 2017-08-29 19:02 GMT+03:00 Michal Suchánek <msuchanek@suse.de>:

Hello,

Unfortunately, the wiki which had the information on reverse-engineering of the boot sequence is gone.

There is an assortment of tools that can possibly accomplish this such as https://github.com/neo-technologies/rockchip-mkbootimg or https://github.com/naobsd/rkutils but I do not have a known working case for at least one board.

I would expect the Olimex guide https://www.olimex.com/wiki/RK3188-SOM#How_to_prepare_your_microSD_card_with... gives usable instructions using free tools where possible.

I guess I can try resurrecting my rk3188 board using these to test.

Unfortunately, the tool supports only 3368 and not 3328. I should be possible to get the chip revision and loader from your original image, though.

Thanks

Michal

On Tue, 29 Aug 2017 18:25:27 +0300 "Matwey V. Kornilov" <matwey.kornilov@gmail.com> wrote:

...

This all correct, but the issue is that u-boot binary (which is produced by obs) has to be wrapped into special container by rkflashtool before being written onto disk. Otherwise, first stage proprietary loader won't recognize it. Problem here that rkflashtool is available only in binary format for x86_64 architecture, and it is tricky to integrate them into OBS build pipeline (between u-boot and JeOS).

2017-08-29 17:40 GMT+03:00 Michal Suchánek <msuchanek@suse.de>:

...

On Tue, 29 Aug 2017 16:23:44 +0200 Andreas Färber <afaerber@suse.de> wrote:

...

Am 29.08.2017 um 14:08 schrieb Michal Suchánek:

...

On Fri, 25 Aug 2017 22:16:09 +0300 "Matwey V. Kornilov" <matwey.kornilov@gmail.com> wrote:

...

It seems that the following tools are binary only: https://github.com/rockchip-linux/rkbin/tree/master/tools They are required to convert u-boot to proprietary loader known format. Proprietary loader is required because there is no (yet?) support for SPL in u-boot for rk3328. The tools are also x86_64 only, so I wonder how could they be used in OBS to produce package for u-boot image in deployable format.

There is rkflashtool https://github.com/linux-rockchip/rkflashtool which worked for me with some cheap rk33?? TV box for modifying a boot script on partition that is not accessible from Android. There was one caveat - the partitions were downloaded with some zero padding at the start.

If you look for resources for Radxa Rock (rk3188) you can possibly find more about rockchip bootable card layout which may or may not work for you with 3328.

http://opensource.rock-chips.com/wiki_Main_Page is a good starting point - the workflow for 64-bit is slightly different.

Note that this is not about flashing but about creating the files to be flashed.

If rkflashtool works for your board you can download different partitions, backup them, upload your code into memory and execute it without making changes to storage, replace the content of different partitions on the medium with your own, observe the actual content change of the medium if you have offline access, restore the backups, etc.

...

Mainline U-Boot circumvents many of those problems by using its own FIT storage format, but it lags in enabling SPL for the various chipsets.

There is some 'magic' part at the start of the medium which you need to preserve for the medium to be bootable. Using rkflashtool this is preserved while you can make changes to the other parts. Getting this 'magic' right is somewhat error-prone so it is easier to start with a bootable image that works and change parts one by one.

Thanks

Michal

-- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Required u-boot.bin from rpm package: https://build.opensuse.org/package/show/home:matwey:branches:Base:System:Sta... img files are produced as described here: https://github.com/rockchip-linux/build/blob/debian/mk-uboot.sh dd if=idbloader.img of=sdb seek=64 dd if=uboot.img of=sdb seek=16384 dd if=trust.img of=sdb seek=24576 2017-08-30 13:13 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:

So, I've managed to start our u-boot.

=> version

U-Boot 2017.07 (Aug 22 2017 - 12:51:50 +0000) gcc (SUSE Linux) 7.1.1 20170802 [gcc-7-branch revision 250825] GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.28.0.20170331-2

I will try to deploy filesystem and run EFI grub.

2017-08-29 19:46 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:

...

Here, is how rockchip builds its u-boot: https://github.com/rockchip-linux/build/blob/debian/mk-uboot.sh

2017-08-29 19:02 GMT+03:00 Michal Suchánek <msuchanek@suse.de>:

...

Hello,

Unfortunately, the wiki which had the information on reverse-engineering of the boot sequence is gone.

There is an assortment of tools that can possibly accomplish this such as https://github.com/neo-technologies/rockchip-mkbootimg or https://github.com/naobsd/rkutils but I do not have a known working case for at least one board.

I would expect the Olimex guide https://www.olimex.com/wiki/RK3188-SOM#How_to_prepare_your_microSD_card_with... gives usable instructions using free tools where possible.

I guess I can try resurrecting my rk3188 board using these to test.

Unfortunately, the tool supports only 3368 and not 3328. I should be possible to get the chip revision and loader from your original image, though.

Thanks

Michal

On Tue, 29 Aug 2017 18:25:27 +0300 "Matwey V. Kornilov" <matwey.kornilov@gmail.com> wrote:

...

This all correct, but the issue is that u-boot binary (which is produced by obs) has to be wrapped into special container by rkflashtool before being written onto disk. Otherwise, first stage proprietary loader won't recognize it. Problem here that rkflashtool is available only in binary format for x86_64 architecture, and it is tricky to integrate them into OBS build pipeline (between u-boot and JeOS).

2017-08-29 17:40 GMT+03:00 Michal Suchánek <msuchanek@suse.de>:

...

On Tue, 29 Aug 2017 16:23:44 +0200 Andreas Färber <afaerber@suse.de> wrote:

...

Am 29.08.2017 um 14:08 schrieb Michal Suchánek: > On Fri, 25 Aug 2017 22:16:09 +0300 > "Matwey V. Kornilov" <matwey.kornilov@gmail.com> wrote: > >> It seems that the following tools are binary only: >> https://github.com/rockchip-linux/rkbin/tree/master/tools >> They are required to convert u-boot to proprietary loader known >> format. Proprietary loader is required because there is no >> (yet?) support for SPL in u-boot for rk3328. >> The tools are also x86_64 only, so I wonder how could they be >> used in OBS to produce package for u-boot image in deployable >> format. > > There is rkflashtool > https://github.com/linux-rockchip/rkflashtool which worked for > me with some cheap rk33?? TV box for modifying a boot script on > partition that is not accessible from Android. There was one > caveat - the partitions were downloaded with some zero padding > at the start. > > If you look for resources for Radxa Rock (rk3188) you can > possibly find more about rockchip bootable card layout which may > or may not work for you with 3328.

http://opensource.rock-chips.com/wiki_Main_Page is a good starting point - the workflow for 64-bit is slightly different.

Note that this is not about flashing but about creating the files to be flashed.

If rkflashtool works for your board you can download different partitions, backup them, upload your code into memory and execute it without making changes to storage, replace the content of different partitions on the medium with your own, observe the actual content change of the medium if you have offline access, restore the backups, etc.

...

Mainline U-Boot circumvents many of those problems by using its own FIT storage format, but it lags in enabling SPL for the various chipsets.

There is some 'magic' part at the start of the medium which you need to preserve for the medium to be bootable. Using rkflashtool this is preserved while you can make changes to the other parts. Getting this 'magic' right is somewhat error-prone so it is easier to start with a bootable image that works and change parts one by one.

Thanks

Michal

-- With best regards, Matwey V. Kornilov

-- With best regards, Matwey V. Kornilov

-- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Hi all, Unfortunately, I've left my rock64 at work, so cannot deploy any OS at weekends, but I think when I find appropriate .dtb, it will start with some degree of success. There are currently two issues for preparing JeOS: 1. Tools from https://github.com/rockchip-linux/rkbin are required to prepare u-boot binary to be deployed into sd-card. The tools are permitted to be redistributed, but they are x86_64-only binary blobs. I think we could package them in RPM package and wrap them using qemu-linux-x86_64 to execute them at JeOS building phase (at aarch64 architecture). 2. bootloader are required to be placed at +16MB offset from the beginning of SD card. We have to find a way to specify KIWI to place EFI partition not at 2048sector as default. 2017-08-31 18:46 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:

Ok, grub is running...

2017-08-30 13:17 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:

...

Required u-boot.bin from rpm package: https://build.opensuse.org/package/show/home:matwey:branches:Base:System:Sta...

img files are produced as described here: https://github.com/rockchip-linux/build/blob/debian/mk-uboot.sh

dd if=idbloader.img of=sdb seek=64 dd if=uboot.img of=sdb seek=16384 dd if=trust.img of=sdb seek=24576

2017-08-30 13:13 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:

...

So, I've managed to start our u-boot.

=> version

U-Boot 2017.07 (Aug 22 2017 - 12:51:50 +0000) gcc (SUSE Linux) 7.1.1 20170802 [gcc-7-branch revision 250825] GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.28.0.20170331-2

I will try to deploy filesystem and run EFI grub.

2017-08-29 19:46 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:

...

Here, is how rockchip builds its u-boot: https://github.com/rockchip-linux/build/blob/debian/mk-uboot.sh

2017-08-29 19:02 GMT+03:00 Michal Suchánek <msuchanek@suse.de>:

...

Hello,

Unfortunately, the wiki which had the information on reverse-engineering of the boot sequence is gone.

There is an assortment of tools that can possibly accomplish this such as https://github.com/neo-technologies/rockchip-mkbootimg or https://github.com/naobsd/rkutils but I do not have a known working case for at least one board.

I would expect the Olimex guide https://www.olimex.com/wiki/RK3188-SOM#How_to_prepare_your_microSD_card_with... gives usable instructions using free tools where possible.

I guess I can try resurrecting my rk3188 board using these to test.

Unfortunately, the tool supports only 3368 and not 3328. I should be possible to get the chip revision and loader from your original image, though.

Thanks

Michal

On Tue, 29 Aug 2017 18:25:27 +0300 "Matwey V. Kornilov" <matwey.kornilov@gmail.com> wrote:

...

This all correct, but the issue is that u-boot binary (which is produced by obs) has to be wrapped into special container by rkflashtool before being written onto disk. Otherwise, first stage proprietary loader won't recognize it. Problem here that rkflashtool is available only in binary format for x86_64 architecture, and it is tricky to integrate them into OBS build pipeline (between u-boot and JeOS).

2017-08-29 17:40 GMT+03:00 Michal Suchánek <msuchanek@suse.de>: > On Tue, 29 Aug 2017 16:23:44 +0200 > Andreas Färber <afaerber@suse.de> wrote: > >> Am 29.08.2017 um 14:08 schrieb Michal Suchánek: >> > On Fri, 25 Aug 2017 22:16:09 +0300 >> > "Matwey V. Kornilov" <matwey.kornilov@gmail.com> wrote: >> > >> >> It seems that the following tools are binary only: >> >> https://github.com/rockchip-linux/rkbin/tree/master/tools >> >> They are required to convert u-boot to proprietary loader known >> >> format. Proprietary loader is required because there is no >> >> (yet?) support for SPL in u-boot for rk3328. >> >> The tools are also x86_64 only, so I wonder how could they be >> >> used in OBS to produce package for u-boot image in deployable >> >> format. >> > >> > There is rkflashtool >> > https://github.com/linux-rockchip/rkflashtool which worked for >> > me with some cheap rk33?? TV box for modifying a boot script on >> > partition that is not accessible from Android. There was one >> > caveat - the partitions were downloaded with some zero padding >> > at the start. >> > >> > If you look for resources for Radxa Rock (rk3188) you can >> > possibly find more about rockchip bootable card layout which may >> > or may not work for you with 3328. >> >> http://opensource.rock-chips.com/wiki_Main_Page is a good starting >> point >> - the workflow for 64-bit is slightly different. >> >> Note that this is not about flashing but about creating the files >> to be flashed. > > If rkflashtool works for your board you can download different > partitions, backup them, upload your code into memory and execute it > without making changes to storage, replace the content of different > partitions on the medium with your own, observe the actual content > change of the medium if you have offline access, restore the > backups, etc. > >> >> Mainline U-Boot circumvents many of those problems by using its own >> FIT storage format, but it lags in enabling SPL for the various >> chipsets. > > There is some 'magic' part at the start of the medium which you > need to preserve for the medium to be bootable. Using rkflashtool > this is preserved while you can make changes to the other parts. > Getting this 'magic' right is somewhat error-prone so it is easier > to start with a bootable image that works and change parts one by > one. > > Thanks > > Michal

-- With best regards, Matwey V. Kornilov

-- With best regards, Matwey V. Kornilov

-- With best regards, Matwey V. Kornilov

-- With best regards, Matwey V. Kornilov

-- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

2017-09-02 13:25 GMT+03:00 Andreas Färber <afaerber@suse.de>:

Hi,

Am 02.09.2017 um 12:06 schrieb Matwey V. Kornilov:

...

1. Tools from https://github.com/rockchip-linux/rkbin are required to prepare u-boot binary to be deployed into sd-card. The tools are permitted to be redistributed, but they are x86_64-only binary blobs. I think we could package them in RPM package and wrap them using qemu-linux-x86_64 to execute them at JeOS building phase (at aarch64 architecture).

Negative. Same topic came up for Amlogic, and I had to develop the native Open Source meson-tools instead.

For creating a JeOS image we need to use U-Boot SPL, which as I already pointed out should avoid all those binary-only x86 tools.

If that is not working yet (you did not say), then we can just document the x86-only steps to keep them out of OBS.

Well, I didn't find any U-Boot SPL implementation for RK3328 in any u-boot trees. That is the issue currently.

...

2. bootloader are required to be placed at +16MB offset from the beginning of SD card. We have to find a way to specify KIWI to place EFI partition not at 2048sector as default.

Yousaf gave a presentation on how to accomplish that for RK3399.

If this reservation is implemented, then similar to my JeOS-nanopik2 image we could just leave out U-Boot and give users Wiki instructions on how to place U-Boot there themselves.

You had forgotten to create an HCL Wiki page - I stubbed one out:

https://en.opensuse.org/HCL:Rock64

Regards, Andreas

-- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)

-- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Booting a command list Loading linux.vmx... Loading initrd.vmx... EFI stub: Booting Linux Kernel... EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied EFI stub: ERROR: Could not determine UEFI Secure Boot status. EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... Hm... Seems to be no consoie from the kernel 2017-09-02 13:29 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:

2017-09-02 13:25 GMT+03:00 Andreas Färber <afaerber@suse.de>:

...

Hi,

Am 02.09.2017 um 12:06 schrieb Matwey V. Kornilov:

...

1. Tools from https://github.com/rockchip-linux/rkbin are required to prepare u-boot binary to be deployed into sd-card. The tools are permitted to be redistributed, but they are x86_64-only binary blobs. I think we could package them in RPM package and wrap them using qemu-linux-x86_64 to execute them at JeOS building phase (at aarch64 architecture).

Negative. Same topic came up for Amlogic, and I had to develop the native Open Source meson-tools instead.

For creating a JeOS image we need to use U-Boot SPL, which as I already pointed out should avoid all those binary-only x86 tools.

If that is not working yet (you did not say), then we can just document the x86-only steps to keep them out of OBS.

Well, I didn't find any U-Boot SPL implementation for RK3328 in any u-boot trees. That is the issue currently.

...

...

2. bootloader are required to be placed at +16MB offset from the beginning of SD card. We have to find a way to specify KIWI to place EFI partition not at 2048sector as default.

Yousaf gave a presentation on how to accomplish that for RK3399.

If this reservation is implemented, then similar to my JeOS-nanopik2 image we could just leave out U-Boot and give users Wiki instructions on how to place U-Boot there themselves.

You had forgotten to create an HCL Wiki page - I stubbed one out:

https://en.opensuse.org/HCL:Rock64

Regards, Andreas

-- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)

-- With best regards, Matwey V. Kornilov

-- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

After some time, the ethernet leds begin to blink, but no requests to dhcp. something is alive inside still... 2017-09-04 11:17 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:

Hm, console=ttyS2,1500000 supposed to work, but it doesnt...

2017-09-04 11:00 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:

...

Booting a command list

Loading linux.vmx... Loading initrd.vmx... EFI stub: Booting Linux Kernel... EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied EFI stub: ERROR: Could not determine UEFI Secure Boot status. EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map...

Hm... Seems to be no consoie from the kernel

2017-09-02 13:29 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:

...

2017-09-02 13:25 GMT+03:00 Andreas Färber <afaerber@suse.de>:

...

Hi,

Am 02.09.2017 um 12:06 schrieb Matwey V. Kornilov:

...

1. Tools from https://github.com/rockchip-linux/rkbin are required to prepare u-boot binary to be deployed into sd-card. The tools are permitted to be redistributed, but they are x86_64-only binary blobs. I think we could package them in RPM package and wrap them using qemu-linux-x86_64 to execute them at JeOS building phase (at aarch64 architecture).

Negative. Same topic came up for Amlogic, and I had to develop the native Open Source meson-tools instead.

For creating a JeOS image we need to use U-Boot SPL, which as I already pointed out should avoid all those binary-only x86 tools.

If that is not working yet (you did not say), then we can just document the x86-only steps to keep them out of OBS.

Well, I didn't find any U-Boot SPL implementation for RK3328 in any u-boot trees. That is the issue currently.

...

...

2. bootloader are required to be placed at +16MB offset from the beginning of SD card. We have to find a way to specify KIWI to place EFI partition not at 2048sector as default.

Yousaf gave a presentation on how to accomplish that for RK3399.

If this reservation is implemented, then similar to my JeOS-nanopik2 image we could just leave out U-Boot and give users Wiki instructions on how to place U-Boot there themselves.

You had forgotten to create an HCL Wiki page - I stubbed one out:

https://en.opensuse.org/HCL:Rock64

Regards, Andreas

-- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)

-- With best regards, Matwey V. Kornilov

-- With best regards, Matwey V. Kornilov

-- With best regards, Matwey V. Kornilov

-- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 05.09.17 14:58, Matwey V. Kornilov wrote:

Still no luck. No signal at video, no text in console after EFI stub. Any ideas why?

Can you try to make earlycon work? I'm sure someone has the magic parameters for it somewhere... Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 05.09.17 15:02, Matwey V. Kornilov wrote:

2017-09-05 16:00 GMT+03:00 Alexander Graf <agraf@suse.de>:

...

On 05.09.17 14:58, Matwey V. Kornilov wrote:

...

Still no luck. No signal at video, no text in console after EFI stub. Any ideas why?

Can you try to make earlycon work? I'm sure someone has the magic parameters for it somewhere...

Indeed. But they don't work either. Ones which should is earlycon=uart8250,mmio32,0xff130000

That is very odd. Usually earlycon works. The only case I've found where it was unintuitively broken was when U-Boot ran in EL3, but I assume you do have ATF running somewhere, right? What you can still try is to recover the kernel log from RAM. For that, boot up the system, then reset (don't power cycle, use the reset button if available, otherwise use the reset line on the jtag port if available). After reset, you should get back to U-Boot. There, run "bdinfo" to find out the base offset of RAM. Then do "nm vmlinux | grep log_buf" on the vmlinux file to the kernel you executed. You may have to extract it first, as it comes gzip'ed by default. In there you will find Linux virtual addresses for log_buf locations. IIRC __log_buf is the one you want. Remove the high 1-bits from that address, then add the RAM offset to it. That *should* hopefully be the offset into RAM for the dmesg buffer. With that address, try to "md.b" its contents from the U-Boot command line. With a bit of luck you can spot something. If not we either had kASLR hit or didn't get as far as writing a dmesg buffer... Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 05.09.17 15:23, Matwey V. Kornilov wrote:

2017-09-05 16:12 GMT+03:00 Alexander Graf <agraf@suse.de>:

...

On 05.09.17 15:02, Matwey V. Kornilov wrote:

...

2017-09-05 16:00 GMT+03:00 Alexander Graf <agraf@suse.de>:

...

On 05.09.17 14:58, Matwey V. Kornilov wrote:

...

Still no luck. No signal at video, no text in console after EFI stub. Any ideas why?

Can you try to make earlycon work? I'm sure someone has the magic parameters for it somewhere...

Indeed. But they don't work either. Ones which should is earlycon=uart8250,mmio32,0xff130000

That is very odd. Usually earlycon works. The only case I've found where it was unintuitively broken was when U-Boot ran in EL3, but I assume you do have ATF running somewhere, right?

It is supposed to be so.

...

What you can still try is to recover the kernel log from RAM. For that, boot up the system, then reset (don't power cycle, use the reset button if available, otherwise use the reset line on the jtag port if available). After reset, you should get back to U-Boot. There, run "bdinfo" to find out the base offset of RAM.

What is the offset here?

=> bdinfo arch_number = 0x00000000 boot_params = 0x00000000 DRAM bank = 0x00000000 -> start = 0x00200000

This is the offset. It does sound quite weird though, so don't be surprised if things don't work :). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

2017-09-05 16:28 GMT+03:00 Alexander Graf <agraf@suse.de>:

On 05.09.17 15:23, Matwey V. Kornilov wrote:

...

2017-09-05 16:12 GMT+03:00 Alexander Graf <agraf@suse.de>:

...

On 05.09.17 15:02, Matwey V. Kornilov wrote:

...

2017-09-05 16:00 GMT+03:00 Alexander Graf <agraf@suse.de>:

...

On 05.09.17 14:58, Matwey V. Kornilov wrote:

...

Still no luck. No signal at video, no text in console after EFI stub. Any ideas why?

Can you try to make earlycon work? I'm sure someone has the magic parameters for it somewhere...

Indeed. But they don't work either. Ones which should is earlycon=uart8250,mmio32,0xff130000

That is very odd. Usually earlycon works. The only case I've found where it was unintuitively broken was when U-Boot ran in EL3, but I assume you do have ATF running somewhere, right?

It is supposed to be so.

...

What you can still try is to recover the kernel log from RAM. For that, boot up the system, then reset (don't power cycle, use the reset button if available, otherwise use the reset line on the jtag port if available). After reset, you should get back to U-Boot. There, run "bdinfo" to find out the base offset of RAM.

What is the offset here?

=> bdinfo arch_number = 0x00000000 boot_params = 0x00000000 DRAM bank = 0x00000000 -> start = 0x00200000

This is the offset. It does sound quite weird though, so don't be surprised if things don't work :).

ffff00000951aa68 b __log_buf I see similar random garbage pattern => md.b 0x971aa68 100 0971aa68: 5b bf f7 df 7e bf 7f fe 9b ff bf 6f 6e ff 0f bd [...~......on... 0971aa78: ff ff fe fe df ff bf de 7f fd cf 7d df bd ff ff ...........}.... 0971aa88: b5 fb 73 7b b3 ef e7 ee ff f7 3e fe ff ff ed af ..s{......>..... 0971aa98: fd f7 bf be df df be ef fd ff ff ff bf bf fb bd ................ 0971aaa8: 3e ed ff b7 c7 bf bf ff fe ff ef bf 4e bf ff cd >...........N... 0971aab8: fd f5 fd ff bf ff ff 9f f4 f7 ef ff ff ff fb bf ................ 0971aac8: f6 7e 77 b5 d5 ff ff 7f 7d b9 f7 f7 fd f3 6e df .~w.....}.....n. 0971aad8: f3 f3 eb 5f df ff 5f ff 7c ff bf fe ff fe fe 7f ..._.._.|....... 0971aae8: ee ff fe ff f5 5f ff fd e7 ff df b7 e7 fb ff ff ....._.......... 0971aaf8: ff bf ef e9 ff fb ff ff ff 77 ef 6c d8 f7 f3 ff .........w.l.... 0971ab08: fe f5 ff f7 fe f7 f6 ff ff ff ba f7 df 76 ff cd .............v.. 0971ab18: ff ff fd fe ff 9f fb fb ff ff ff fb ff bf ff fe ................ 0971ab28: d5 7f f6 ff bf 5f fe f1 f7 ff ff fb fb 97 f6 4b ....._.........K 0971ab38: ff ff 7e a7 ff df 60 fd bb f7 df fd ff 7b f7 ef ..~...`......{.. 0971ab48: ef fd fb dd fb f6 fb ff ef ef b7 7f ff db fc cf ................ 0971ab58: 7f ff f6 7b fb 7f fb 7f d7 ef ff ff ff bd e7 7f ...{............ => md.b 0x951aa68 100 0951aa68: 5b bf f5 cf 7e bf 7f ff 9b ff ff 6f 6e ff 0f bd [...~......on... 0951aa78: ff ff fe fe df ff ff de 7f fd cf 7d df fd ff ff ...........}.... 0951aa88: b5 fb 73 7b b7 ef e7 ee ff f7 3e fe ff ff ed af ..s{......>..... 0951aa98: fd f7 3f bf ff df be ef fd ff ff ff bf bf fb bf ..?............. 0951aaa8: 3e ed ff b7 c7 bf bf ff fe ff ef bf 4a bf fb cc >...........J... 0951aab8: ff fd fd ff b7 ff ff 9f f4 f7 ef ff ff ff fb bf ................ 0951aac8: e6 7e 77 b7 d4 ff ff 7f 7d b9 f7 e7 fd f3 6e df .~w.....}.....n. 0951aad8: f3 f3 eb 5f d7 ff 5f ff 7c ff bf fe ff fe fe 7f ..._.._.|....... 0951aae8: ee ff fe ff f5 5b ff fd f7 ff df b7 e7 fb fe ff .....[.......... 0951aaf8: ff bf ef e9 fd fb ff ff ff 77 ef 6c d8 f7 f3 ff .........w.l.... 0951ab08: f6 f4 ff ff fe f7 f6 f7 ff ff ba f5 df f6 ff cd ................ 0951ab18: ff ff fd fe df 3f fb fb ff ff ff fb ff bf ff fe .....?.......... 0951ab28: d5 7f f6 ff bf 5f fe 75 f7 ff ff fb fb 97 f6 4b ....._.u.......K 0951ab38: ff ff 7e a7 ff de 60 fd bb f7 df fd ff 73 f7 ef ..~...`......s.. 0951ab48: ef fd fb dd fb f6 fb ef ef ef b7 7f ff db fc cb ................ 0951ab58: 7f ff f6 7b fb 7f fb 7d d7 ef ff ff ff bd a7 7f ...{...}........

Alex

-- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

pc-s are different every time, the rest persists. 2017-09-19 20:09 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:

This helps

earlycon=uart8250,mmio32,0xff130000 console=ttyS2,1500000

However, something is going wrong.

[ 11.181943] modprobe[93]: undefined instruction: pc=0000ffffb1dccff4 [ 11.182589] Code: d503201f 8a180320 92750001 365ffc20 (d5380001) [ 11.184268] modprobe[94]: undefined instruction: pc=0000ffffa3f7bff4 [ 11.184913] Code: d503201f 8a180320 92750001 365ffc20 (d5380001) [ 11.186988] modprobe[97]: undefined instruction: pc=0000ffffbd2bfff4 [ 11.187632] Code: d503201f 8a180320 92750001 365ffc20 (d5380001) [ 11.189299] modprobe[98]: undefined instruction: pc=0000ffff8cbfeff4 [ 11.189945] Code: d503201f 8a180320 92750001 365ffc20 (d5380001) [ 11.191218] Segment Routing with IPv6 [ 11.192884] registered taskstats version 1 [ 11.193425] zswap: loaded using pool lzo/zbud [ 11.223701] Key type big_key registered [ 11.245149] Key type encrypted registered [ 11.245574] AppArmor: AppArmor sha1 policy hashing enabled [ 11.264592] hctosys: unable to open rtc device (rtc0) [ 11.280592] PM: Hibernation image not present or could not be loaded.

2017-09-06 10:53 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:

...

2017-09-05 16:28 GMT+03:00 Alexander Graf <agraf@suse.de>:

...

On 05.09.17 15:23, Matwey V. Kornilov wrote:

...

2017-09-05 16:12 GMT+03:00 Alexander Graf <agraf@suse.de>:

...

On 05.09.17 15:02, Matwey V. Kornilov wrote:

...

2017-09-05 16:00 GMT+03:00 Alexander Graf <agraf@suse.de>: > > > > On 05.09.17 14:58, Matwey V. Kornilov wrote: >> >> >> >> Still no luck. No signal at video, no text in console after EFI stub. >> Any ideas why? >> > > Can you try to make earlycon work? I'm sure someone has the magic > parameters > for it somewhere...

Indeed. But they don't work either. Ones which should is earlycon=uart8250,mmio32,0xff130000

That is very odd. Usually earlycon works. The only case I've found where it was unintuitively broken was when U-Boot ran in EL3, but I assume you do have ATF running somewhere, right?

It is supposed to be so.

...

What you can still try is to recover the kernel log from RAM. For that, boot up the system, then reset (don't power cycle, use the reset button if available, otherwise use the reset line on the jtag port if available). After reset, you should get back to U-Boot. There, run "bdinfo" to find out the base offset of RAM.

What is the offset here?

=> bdinfo arch_number = 0x00000000 boot_params = 0x00000000 DRAM bank = 0x00000000 -> start = 0x00200000

This is the offset. It does sound quite weird though, so don't be surprised if things don't work :).

ffff00000951aa68 b __log_buf

I see similar random garbage pattern

=> md.b 0x971aa68 100 0971aa68: 5b bf f7 df 7e bf 7f fe 9b ff bf 6f 6e ff 0f bd [...~......on... 0971aa78: ff ff fe fe df ff bf de 7f fd cf 7d df bd ff ff ...........}.... 0971aa88: b5 fb 73 7b b3 ef e7 ee ff f7 3e fe ff ff ed af ..s{......>..... 0971aa98: fd f7 bf be df df be ef fd ff ff ff bf bf fb bd ................ 0971aaa8: 3e ed ff b7 c7 bf bf ff fe ff ef bf 4e bf ff cd >...........N... 0971aab8: fd f5 fd ff bf ff ff 9f f4 f7 ef ff ff ff fb bf ................ 0971aac8: f6 7e 77 b5 d5 ff ff 7f 7d b9 f7 f7 fd f3 6e df .~w.....}.....n. 0971aad8: f3 f3 eb 5f df ff 5f ff 7c ff bf fe ff fe fe 7f ..._.._.|....... 0971aae8: ee ff fe ff f5 5f ff fd e7 ff df b7 e7 fb ff ff ....._.......... 0971aaf8: ff bf ef e9 ff fb ff ff ff 77 ef 6c d8 f7 f3 ff .........w.l.... 0971ab08: fe f5 ff f7 fe f7 f6 ff ff ff ba f7 df 76 ff cd .............v.. 0971ab18: ff ff fd fe ff 9f fb fb ff ff ff fb ff bf ff fe ................ 0971ab28: d5 7f f6 ff bf 5f fe f1 f7 ff ff fb fb 97 f6 4b ....._.........K 0971ab38: ff ff 7e a7 ff df 60 fd bb f7 df fd ff 7b f7 ef ..~...`......{.. 0971ab48: ef fd fb dd fb f6 fb ff ef ef b7 7f ff db fc cf ................ 0971ab58: 7f ff f6 7b fb 7f fb 7f d7 ef ff ff ff bd e7 7f ...{............ => md.b 0x951aa68 100 0951aa68: 5b bf f5 cf 7e bf 7f ff 9b ff ff 6f 6e ff 0f bd [...~......on... 0951aa78: ff ff fe fe df ff ff de 7f fd cf 7d df fd ff ff ...........}.... 0951aa88: b5 fb 73 7b b7 ef e7 ee ff f7 3e fe ff ff ed af ..s{......>..... 0951aa98: fd f7 3f bf ff df be ef fd ff ff ff bf bf fb bf ..?............. 0951aaa8: 3e ed ff b7 c7 bf bf ff fe ff ef bf 4a bf fb cc >...........J... 0951aab8: ff fd fd ff b7 ff ff 9f f4 f7 ef ff ff ff fb bf ................ 0951aac8: e6 7e 77 b7 d4 ff ff 7f 7d b9 f7 e7 fd f3 6e df .~w.....}.....n. 0951aad8: f3 f3 eb 5f d7 ff 5f ff 7c ff bf fe ff fe fe 7f ..._.._.|....... 0951aae8: ee ff fe ff f5 5b ff fd f7 ff df b7 e7 fb fe ff .....[.......... 0951aaf8: ff bf ef e9 fd fb ff ff ff 77 ef 6c d8 f7 f3 ff .........w.l.... 0951ab08: f6 f4 ff ff fe f7 f6 f7 ff ff ba f5 df f6 ff cd ................ 0951ab18: ff ff fd fe df 3f fb fb ff ff ff fb ff bf ff fe .....?.......... 0951ab28: d5 7f f6 ff bf 5f fe 75 f7 ff ff fb fb 97 f6 4b ....._.u.......K 0951ab38: ff ff 7e a7 ff de 60 fd bb f7 df fd ff 73 f7 ef ..~...`......s.. 0951ab48: ef fd fb dd fb f6 fb ef ef ef b7 7f ff db fc cb ................ 0951ab58: 7f ff f6 7b fb 7f fb 7d d7 ef ff ff ff bd a7 7f ...{...}........

...

Alex

-- With best regards, Matwey V. Kornilov

-- With best regards, Matwey V. Kornilov

-- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

20.09.2017 01:00, Stefan Bruens пишет:

On Dienstag, 19. September 2017 21:15:54 CEST Matwey V. Kornilov wrote:

...

d503201f 8a180320 92750001 365ffc20 (d5380001)

Decoded: cat /tmp/code.s .4byte 0xd503201f .4byte 0x8a180320 .4byte 0x92750001 .4byte 0x365ffc20 .4byte 0xd5380001

Hi, There is no such code in modprobe binary itself, not sure where it did come from.

rpi3:~ # as /tmp/code.s -o /tmp/code.o ; strip /tmp/code.o ; objdump -S /tmp/ code.o

/tmp/code.o: file format elf64-littleaarch64

Disassembly of section .text:

0000000000000000 <.text>: 0: d503201f nop 4: 8a180320 and x0, x25, x24 8: 92750001 and x1, x0, #0x800 c: 365ffc20 tbz w0, #11, 0xffffffffffffff90 10: d5380001 mrs x1, midr_el

The last is the faulting instruction. According to: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/ BABGBFBF.html

modprobe tries to read the MIDR register, which is exception level 1 (EL1) only, but I think modprobe is running in EL0.

Kind regards,

Stefan

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

2017-09-21 11:54 GMT+03:00 Andreas Schwab <schwab@suse.de>:

On Sep 21 2017, "Matwey V. Kornilov" <matwey.kornilov@gmail.com> wrote:

...

There is no such code in modprobe binary itself, not sure where it did come from.

The pc is pointing into the library area.

objdump -d ld-2.26.so | grep d5380001 14ff4: d5380001 mrs x1, midr_el1 Why do the other boards work fine here?

Andreas.

-- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."

-- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

2017-09-21 12:49 GMT+03:00 Andreas Schwab <schwab@suse.de>:

On Sep 21 2017, "Matwey V. Kornilov" <matwey.kornilov@gmail.com> wrote:

...

2017-09-21 11:54 GMT+03:00 Andreas Schwab <schwab@suse.de>:

...

On Sep 21 2017, "Matwey V. Kornilov" <matwey.kornilov@gmail.com> wrote:

...

There is no such code in modprobe binary itself, not sure where it did come from.

The pc is pointing into the library area.

objdump -d ld-2.26.so | grep d5380001 14ff4: d5380001 mrs x1, midr_el1

It has been introduced in d2e4346a30683cc42c57bd1bfd457897d78c6d7e ("Add ifunc support for aarch64.")

...

Why do the other boards work fine here?

The kernel is supposed to emulate it.

But then there should be some generic instruction handler, right?

Andreas.

-- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."

-- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

2017-09-21 13:03 GMT+03:00 Andreas Schwab <schwab@suse.de>:

On Sep 21 2017, "Matwey V. Kornilov" <matwey.kornilov@gmail.com> wrote:

...

2017-09-21 12:49 GMT+03:00 Andreas Schwab <schwab@suse.de>:

...

On Sep 21 2017, "Matwey V. Kornilov" <matwey.kornilov@gmail.com> wrote:

...

2017-09-21 11:54 GMT+03:00 Andreas Schwab <schwab@suse.de>:

...

On Sep 21 2017, "Matwey V. Kornilov" <matwey.kornilov@gmail.com> wrote:

...

There is no such code in modprobe binary itself, not sure where it did come from.

The pc is pointing into the library area.

objdump -d ld-2.26.so | grep d5380001 14ff4: d5380001 mrs x1, midr_el1

It has been introduced in d2e4346a30683cc42c57bd1bfd457897d78c6d7e ("Add ifunc support for aarch64.")

...

...

Why do the other boards work fine here?

The kernel is supposed to emulate it.

But then there should be some generic instruction handler, right?

There kernel only emulates some special cases.

Not sure, how does it do it? Where should I put the fix?

Andreas.

-- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."

-- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Can not activate any debug shell. 2017-09-19 22:15 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:

pc-s are different every time, the rest persists.

2017-09-19 20:09 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:

...

This helps

earlycon=uart8250,mmio32,0xff130000 console=ttyS2,1500000

However, something is going wrong.

[ 11.181943] modprobe[93]: undefined instruction: pc=0000ffffb1dccff4 [ 11.182589] Code: d503201f 8a180320 92750001 365ffc20 (d5380001) [ 11.184268] modprobe[94]: undefined instruction: pc=0000ffffa3f7bff4 [ 11.184913] Code: d503201f 8a180320 92750001 365ffc20 (d5380001) [ 11.186988] modprobe[97]: undefined instruction: pc=0000ffffbd2bfff4 [ 11.187632] Code: d503201f 8a180320 92750001 365ffc20 (d5380001) [ 11.189299] modprobe[98]: undefined instruction: pc=0000ffff8cbfeff4 [ 11.189945] Code: d503201f 8a180320 92750001 365ffc20 (d5380001) [ 11.191218] Segment Routing with IPv6 [ 11.192884] registered taskstats version 1 [ 11.193425] zswap: loaded using pool lzo/zbud [ 11.223701] Key type big_key registered [ 11.245149] Key type encrypted registered [ 11.245574] AppArmor: AppArmor sha1 policy hashing enabled [ 11.264592] hctosys: unable to open rtc device (rtc0) [ 11.280592] PM: Hibernation image not present or could not be loaded.

2017-09-06 10:53 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:

...

2017-09-05 16:28 GMT+03:00 Alexander Graf <agraf@suse.de>:

...

On 05.09.17 15:23, Matwey V. Kornilov wrote:

...

2017-09-05 16:12 GMT+03:00 Alexander Graf <agraf@suse.de>:

...

On 05.09.17 15:02, Matwey V. Kornilov wrote: > > > 2017-09-05 16:00 GMT+03:00 Alexander Graf <agraf@suse.de>: >> >> >> >> On 05.09.17 14:58, Matwey V. Kornilov wrote: >>> >>> >>> >>> Still no luck. No signal at video, no text in console after EFI stub. >>> Any ideas why? >>> >> >> Can you try to make earlycon work? I'm sure someone has the magic >> parameters >> for it somewhere... > > > > Indeed. But they don't work either. Ones which should is > earlycon=uart8250,mmio32,0xff130000

That is very odd. Usually earlycon works. The only case I've found where it was unintuitively broken was when U-Boot ran in EL3, but I assume you do have ATF running somewhere, right?

It is supposed to be so.

...

What you can still try is to recover the kernel log from RAM. For that, boot up the system, then reset (don't power cycle, use the reset button if available, otherwise use the reset line on the jtag port if available). After reset, you should get back to U-Boot. There, run "bdinfo" to find out the base offset of RAM.

What is the offset here?

=> bdinfo arch_number = 0x00000000 boot_params = 0x00000000 DRAM bank = 0x00000000 -> start = 0x00200000

This is the offset. It does sound quite weird though, so don't be surprised if things don't work :).

ffff00000951aa68 b __log_buf

I see similar random garbage pattern

=> md.b 0x971aa68 100 0971aa68: 5b bf f7 df 7e bf 7f fe 9b ff bf 6f 6e ff 0f bd [...~......on... 0971aa78: ff ff fe fe df ff bf de 7f fd cf 7d df bd ff ff ...........}.... 0971aa88: b5 fb 73 7b b3 ef e7 ee ff f7 3e fe ff ff ed af ..s{......>..... 0971aa98: fd f7 bf be df df be ef fd ff ff ff bf bf fb bd ................ 0971aaa8: 3e ed ff b7 c7 bf bf ff fe ff ef bf 4e bf ff cd >...........N... 0971aab8: fd f5 fd ff bf ff ff 9f f4 f7 ef ff ff ff fb bf ................ 0971aac8: f6 7e 77 b5 d5 ff ff 7f 7d b9 f7 f7 fd f3 6e df .~w.....}.....n. 0971aad8: f3 f3 eb 5f df ff 5f ff 7c ff bf fe ff fe fe 7f ..._.._.|....... 0971aae8: ee ff fe ff f5 5f ff fd e7 ff df b7 e7 fb ff ff ....._.......... 0971aaf8: ff bf ef e9 ff fb ff ff ff 77 ef 6c d8 f7 f3 ff .........w.l.... 0971ab08: fe f5 ff f7 fe f7 f6 ff ff ff ba f7 df 76 ff cd .............v.. 0971ab18: ff ff fd fe ff 9f fb fb ff ff ff fb ff bf ff fe ................ 0971ab28: d5 7f f6 ff bf 5f fe f1 f7 ff ff fb fb 97 f6 4b ....._.........K 0971ab38: ff ff 7e a7 ff df 60 fd bb f7 df fd ff 7b f7 ef ..~...`......{.. 0971ab48: ef fd fb dd fb f6 fb ff ef ef b7 7f ff db fc cf ................ 0971ab58: 7f ff f6 7b fb 7f fb 7f d7 ef ff ff ff bd e7 7f ...{............ => md.b 0x951aa68 100 0951aa68: 5b bf f5 cf 7e bf 7f ff 9b ff ff 6f 6e ff 0f bd [...~......on... 0951aa78: ff ff fe fe df ff ff de 7f fd cf 7d df fd ff ff ...........}.... 0951aa88: b5 fb 73 7b b7 ef e7 ee ff f7 3e fe ff ff ed af ..s{......>..... 0951aa98: fd f7 3f bf ff df be ef fd ff ff ff bf bf fb bf ..?............. 0951aaa8: 3e ed ff b7 c7 bf bf ff fe ff ef bf 4a bf fb cc >...........J... 0951aab8: ff fd fd ff b7 ff ff 9f f4 f7 ef ff ff ff fb bf ................ 0951aac8: e6 7e 77 b7 d4 ff ff 7f 7d b9 f7 e7 fd f3 6e df .~w.....}.....n. 0951aad8: f3 f3 eb 5f d7 ff 5f ff 7c ff bf fe ff fe fe 7f ..._.._.|....... 0951aae8: ee ff fe ff f5 5b ff fd f7 ff df b7 e7 fb fe ff .....[.......... 0951aaf8: ff bf ef e9 fd fb ff ff ff 77 ef 6c d8 f7 f3 ff .........w.l.... 0951ab08: f6 f4 ff ff fe f7 f6 f7 ff ff ba f5 df f6 ff cd ................ 0951ab18: ff ff fd fe df 3f fb fb ff ff ff fb ff bf ff fe .....?.......... 0951ab28: d5 7f f6 ff bf 5f fe 75 f7 ff ff fb fb 97 f6 4b ....._.u.......K 0951ab38: ff ff 7e a7 ff de 60 fd bb f7 df fd ff 73 f7 ef ..~...`......s.. 0951ab48: ef fd fb dd fb f6 fb ef ef ef b7 7f ff db fc cb ................ 0951ab58: 7f ff f6 7b fb 7f fb 7d d7 ef ff ff ff bd a7 7f ...{...}........

...

Alex

-- With best regards, Matwey V. Kornilov

-- With best regards, Matwey V. Kornilov

-- With best regards, Matwey V. Kornilov

-- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

2017-09-02 13:25 GMT+03:00 Andreas Färber <afaerber@suse.de>:

Hi,

Am 02.09.2017 um 12:06 schrieb Matwey V. Kornilov:

...

1. Tools from https://github.com/rockchip-linux/rkbin are required to prepare u-boot binary to be deployed into sd-card. The tools are permitted to be redistributed, but they are x86_64-only binary blobs. I think we could package them in RPM package and wrap them using qemu-linux-x86_64 to execute them at JeOS building phase (at aarch64 architecture).

Negative. Same topic came up for Amlogic, and I had to develop the native Open Source meson-tools instead.

For creating a JeOS image we need to use U-Boot SPL, which as I already pointed out should avoid all those binary-only x86 tools.

If that is not working yet (you did not say), then we can just document the x86-only steps to keep them out of OBS.

...

2. bootloader are required to be placed at +16MB offset from the beginning of SD card. We have to find a way to specify KIWI to place EFI partition not at 2048sector as default.

Yousaf gave a presentation on how to accomplish that for RK3399.

If this reservation is implemented, then similar to my JeOS-nanopik2 image we could just leave out U-Boot and give users Wiki instructions on how to place U-Boot there themselves.

Why didn't we allocate separate GPT partition for each bootloader image? It seems to be generic way to denote that specific place at SD card is allocated and used by something.

You had forgotten to create an HCL Wiki page - I stubbed one out:

https://en.opensuse.org/HCL:Rock64

Regards, Andreas

-- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)

-- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Am 01.01.2018 um 16:20 schrieb Matwey V. Kornilov:

2017-09-02 13:25 GMT+03:00 Andreas Färber <afaerber@suse.de>:

...

Hi,

Am 02.09.2017 um 12:06 schrieb Matwey V. Kornilov:

...

1. Tools from https://github.com/rockchip-linux/rkbin are required to prepare u-boot binary to be deployed into sd-card. The tools are permitted to be redistributed, but they are x86_64-only binary blobs. I think we could package them in RPM package and wrap them using qemu-linux-x86_64 to execute them at JeOS building phase (at aarch64 architecture).

Negative. Same topic came up for Amlogic, and I had to develop the native Open Source meson-tools instead.

For creating a JeOS image we need to use U-Boot SPL, which as I already pointed out should avoid all those binary-only x86 tools.

If that is not working yet (you did not say), then we can just document the x86-only steps to keep them out of OBS.

...

2. bootloader are required to be placed at +16MB offset from the beginning of SD card. We have to find a way to specify KIWI to place EFI partition not at 2048sector as default.

Yousaf gave a presentation on how to accomplish that for RK3399.

If this reservation is implemented, then similar to my JeOS-nanopik2 image we could just leave out U-Boot and give users Wiki instructions on how to place U-Boot there themselves.

Why didn't we allocate separate GPT partition for each bootloader image? It seems to be generic way to denote that specific place at SD card is allocated and used by something.

Kiwi only supports a few partitioning schemes, it does not allow to add random other partitions AFAIK. Every scheme needs to be defined in the XML Schema and needs a matching implementation in Kiwi. Have you checked out Alex' new non-Kiwi approach for RPi3 and Pine64? That should allow to create custom bootloader partitions. Just keep in mind that U-Boot might check only the first partition if none is flagged as bootable, so you may want to keep EFI first even if physically second. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Am 02.01.2018 um 16:59 schrieb Matwey V. Kornilov:

2018-01-02 18:27 GMT+03:00 Andreas Färber <afaerber@suse.de>:

...

Am 01.01.2018 um 16:20 schrieb Matwey V. Kornilov:

...

Why didn't we allocate separate GPT partition for each bootloader image? It seems to be generic way to denote that specific place at SD card is allocated and used by something.

Kiwi only supports a few partitioning schemes, it does not allow to add random other partitions AFAIK. Every scheme needs to be defined in the XML Schema and needs a matching implementation in Kiwi.

Have you checked out Alex' new non-Kiwi approach for RPi3 and Pine64?

Nope. Where can I find it?

https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:Pine64

This one?

https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:Pine64/pin... Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Well, something strange happens at pre-init stage at Rock64: ===> Calling pre-init stage in system image [ 130.501368] systemd-udevd[1848]: starting version 234 [ 130.751693] device-mapper: uevent: version 1.0.3 [ 130.752483] device-mapper: ioctl: 4.37.0-ioctl (2017-09-20) initialised: dm-devel@redhat.com [ 133.143024] Internal error: Oops - SP/PC alignment exception: 8a000000 [#1] SMP [ 133.143029] Kernel panic - not syncing: corrupted stack end detected inside scheduler [ 133.143029] [ 133.143040] SMP: stopping secondary CPUs [ 133.144886] Modules linked in: dm_mod btrfs xor zstd_compress zlib_deflate raid6_pq fuse squashfs zstd_decompress xxhash loop virtio_blk mmc_block brd rk808_regulator rk808 aes_ce_blk aes_ce_cipher crc32_ce crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce dwc2 ohci_platform ohci_hcd ehci_platform ehci_hcd udc_core usbcore fixed dw_mmc_rockchip dw_mmc_pltfm dw_mmc phy_rockchip_inno_usb2 mmc_core rockchip_thermal i2c_rk3x aes_neon_bs aes_neon_blk crypto_simd cryptd aes_arm64 [ 133.148752] CPU: 2 PID: 1868 Comm: depmod Not tainted 4.15.7-1-default #1 [ 133.149360] Hardware name: rockchip rock64_rk3328/rock64_rk3328, BIOS 2018.01-rc2-02249-g19e31fac0d-dirty 02/01/2018 [ 133.150300] pstate: 20000005 (nzCv daif -PAN -UAO) [ 133.150738] pc : 0x6d6d61675f7465 [ 133.151048] lr : __do_softirq+0x164/0x384 [ 133.151411] sp : ffff000008013ed0 [ 133.151713] x29: ffff000008013ed0 x28: 0000000000000002 [ 133.152197] x27: ffff0000092a61c8 x26: ffff000008ee6010 [ 133.152681] x25: ffff0000092a6180 x24: 0000000000000009 [ 133.153164] x23: 0000000000000100 x22: 0000000000000010 [ 133.153648] x21: ffff0000092a61c0 x20: 0000000000000002 [ 133.154132] x19: 0000000000000009 x18: 0000ffff95442a70 [ 133.154616] x17: 0000ffff953485d0 x16: 0000aaaab0f52c48 [ 133.155100] x15: 0000000000000000 x14: 0000000000000000 [ 133.155585] x13: 7fffffffffffffff x12: 0000000000000000 [ 133.156068] x11: 0000000000000001 x10: ffff000008013e98 [ 133.156551] x9 : 0000000000000000 x8 : 0000000000000013 [ 133.157034] x7 : ffff80007ff7bf28 x6 : ffff80007ff83a10 [ 133.157519] x5 : ffff000008014000 x4 : ffff80004c702080 [ 133.158003] x3 : 000080007708f000 x2 : 0000000000000008 [ 133.158487] x1 : 616d6d61675f7465 x0 : ffff0000092a61c8 [ 133.158975] Process depmod (pid: 1868, stack limit = 0x000000000c1b7bc2) [ 133.159574] Call trace: [ 133.159804] 0x6d6d61675f7465 [ 133.160081] irq_exit+0xd0/0x110 [ 133.160379] __handle_domain_irq+0x6c/0xc0 [ 133.160753] gic_handle_irq+0x60/0xb0 [ 133.161089] el0_irq_naked+0x50/0x5c [ 133.161420] Code: bad PC value [ 133.161705] ---[ end trace d493cbb1fdc63aa0 ]--- [ 134.309714] SMP: failed to stop secondary CPUs 0,2 [ 134.310153] Kernel Offset: disabled [ 134.310473] CPU features: 0x0802004 [ 134.310791] Memory Limit: none [ 134.311079] Rebooting in 90 seconds.. 2018-01-03 22:48 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:

I've found that kiwi already can do something similar I need:

https://doc.opensuse.org/projects/kiwi/doc/

[--disk-start-sector number]

The start sector value for virtual disk based images. The default is 2048. For newer disks including SSD this is a reasonable default. In order to use the old style disk layout the value can be set to 32.

2018-01-02 19:01 GMT+03:00 Andreas Färber <afaerber@suse.de>:

...

Am 02.01.2018 um 16:59 schrieb Matwey V. Kornilov:

...

2018-01-02 18:27 GMT+03:00 Andreas Färber <afaerber@suse.de>:

...

Am 01.01.2018 um 16:20 schrieb Matwey V. Kornilov:

...

Why didn't we allocate separate GPT partition for each bootloader image? It seems to be generic way to denote that specific place at SD card is allocated and used by something.

Kiwi only supports a few partitioning schemes, it does not allow to add random other partitions AFAIK. Every scheme needs to be defined in the XML Schema and needs a matching implementation in Kiwi.

Have you checked out Alex' new non-Kiwi approach for RPi3 and Pine64?

Nope. Where can I find it?

https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:Pine64

This one?

https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:Pine64/pin...

Cheers, Andreas

-- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)

-- With best regards, Matwey V. Kornilov

-- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

2018-03-10 3:03 GMT+03:00 Alexander Graf <agraf@suse.de>:

On 09.03.18 19:22, Matwey V. Kornilov wrote:

...

Well, something strange happens at pre-init stage at Rock64:

===> Calling pre-init stage in system image [ 130.501368] systemd-udevd[1848]: starting version 234 [ 130.751693] device-mapper: uevent: version 1.0.3 [ 130.752483] device-mapper: ioctl: 4.37.0-ioctl (2017-09-20) initialised: dm-devel@redhat.com [ 133.143024] Internal error: Oops - SP/PC alignment exception: 8a000000 [#1] SMP [ 133.143029] Kernel panic - not syncing: corrupted stack end detected inside scheduler [ 133.143029] [ 133.143040] SMP: stopping secondary CPUs [ 133.144886] Modules linked in: dm_mod btrfs xor zstd_compress zlib_deflate raid6_pq fuse squashfs zstd_decompress xxhash loop virtio_blk mmc_block brd rk808_regulator rk808 aes_ce_blk aes_ce_cipher crc32_ce crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce dwc2 ohci_platform ohci_hcd ehci_platform ehci_hcd udc_core usbcore fixed dw_mmc_rockchip dw_mmc_pltfm dw_mmc phy_rockchip_inno_usb2 mmc_core rockchip_thermal i2c_rk3x aes_neon_bs aes_neon_blk crypto_simd cryptd aes_arm64 [ 133.148752] CPU: 2 PID: 1868 Comm: depmod Not tainted 4.15.7-1-default #1 [ 133.149360] Hardware name: rockchip rock64_rk3328/rock64_rk3328, BIOS 2018.01-rc2-02249-g19e31fac0d-dirty 02/01/2018 [ 133.150300] pstate: 20000005 (nzCv daif -PAN -UAO) [ 133.150738] pc : 0x6d6d61675f7465

localhost:~ # echo 6d6d61675f7465 | xxd -ps -r ; echo mmag_te

No idea

Do you have any idea what that string could be? Maybe some memory that really is in use by EL3 isn't declared as such in the EFI memory map?

Well, the issue is gone when I reduced initial initrd size to reasonable value.

Alex

-- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

2018-03-10 12:41 GMT+03:00 Alexander Graf <agraf@suse.de>:

...

Am 10.03.2018 um 10:05 schrieb Matwey V. Kornilov <matwey.kornilov@gmail.com>:

2018-03-10 3:03 GMT+03:00 Alexander Graf <agraf@suse.de>:

...

...

On 09.03.18 19:22, Matwey V. Kornilov wrote: Well, something strange happens at pre-init stage at Rock64:

===> Calling pre-init stage in system image [ 130.501368] systemd-udevd[1848]: starting version 234 [ 130.751693] device-mapper: uevent: version 1.0.3 [ 130.752483] device-mapper: ioctl: 4.37.0-ioctl (2017-09-20) initialised: dm-devel@redhat.com [ 133.143024] Internal error: Oops - SP/PC alignment exception: 8a000000 [#1] SMP [ 133.143029] Kernel panic - not syncing: corrupted stack end detected inside scheduler [ 133.143029] [ 133.143040] SMP: stopping secondary CPUs [ 133.144886] Modules linked in: dm_mod btrfs xor zstd_compress zlib_deflate raid6_pq fuse squashfs zstd_decompress xxhash loop virtio_blk mmc_block brd rk808_regulator rk808 aes_ce_blk aes_ce_cipher crc32_ce crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce dwc2 ohci_platform ohci_hcd ehci_platform ehci_hcd udc_core usbcore fixed dw_mmc_rockchip dw_mmc_pltfm dw_mmc phy_rockchip_inno_usb2 mmc_core rockchip_thermal i2c_rk3x aes_neon_bs aes_neon_blk crypto_simd cryptd aes_arm64 [ 133.148752] CPU: 2 PID: 1868 Comm: depmod Not tainted 4.15.7-1-default #1 [ 133.149360] Hardware name: rockchip rock64_rk3328/rock64_rk3328, BIOS 2018.01-rc2-02249-g19e31fac0d-dirty 02/01/2018 [ 133.150300] pstate: 20000005 (nzCv daif -PAN -UAO) [ 133.150738] pc : 0x6d6d61675f7465

localhost:~ # echo 6d6d61675f7465 | xxd -ps -r ; echo mmag_te

No idea

...

Do you have any idea what that string could be? Maybe some memory that really is in use by EL3 isn't declared as such in the EFI memory map?

Well, the issue is gone when I reduced initial initrd size to reasonable value.

Can you try some memory tester in user space then? I‘m not sure the issue is actually gone, it might just not get exposed on boot anymore.

Indeed. stress-ng --vm 1 --vm-bytes 75% --vm-method all --verify -t 10m -v hungs the system, but unfortunately there is no output on console, even with loglevel=8

Alex

...

...

Alex

-- With best regards, Matwey V. Kornilov

-- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org