Re: [opensuse-arm] Rock64
On 2/12/20 12:18 PM, Brüns, Stefan wrote: > On Mittwoch, 12. Februar 2020 16:37:28 CET ITwrx wrote: >> On 2/12/20 8:59 AM, ITwrx wrote: >>> On 2/12/20 1:49 AM, Matwey V. Kornilov wrote: >> Ok, i misspoke earlier. The first time i didn't extract, then run >> dd_rescue per your instructions. i ran "xzcat [image].raw.xz | dd bs=4M >> of=/dev/sdX iflag=fullblock oflag=direct; sync" (substituting relevant >> info) per the wiki. This time i did use your commands. I got the same >> result and output in the serial console as before. >> >>> U-Boot TPL 2020.01 (Jan 30 2020 - 10:43:44) >>> data training error >>> col error >>> data training error >>> LPDDR3, 800MHz >>> BW=16 Col=12 Bk=8 CS0 Row=16 CS=1 Die BW=8 Size=4096MB >> I don't know much about Arm, so i don't know what that output means. :) > This is the automatic delay adjustments to balance the trace lengths. > > Three possible reasons it fails: > > 1. bad board > 2. initial timing settings too much off for the training to lock > 3. unknown/new/different RAM chips which require a different setting > > Obviously, your RAM configuration is different from Matweys: > >> U-Boot TPL 2020.01 (Jan 30 2020 - 10:43:44) >> LPDDR3, 800MHz >> BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB > Kind regards, > > Stefan Interesting. Thanks for your input. -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Rock64
On Mittwoch, 12. Februar 2020 16:37:28 CET ITwrx wrote: > On 2/12/20 8:59 AM, ITwrx wrote: > > On 2/12/20 1:49 AM, Matwey V. Kornilov wrote: > > Ok, i misspoke earlier. The first time i didn't extract, then run > dd_rescue per your instructions. i ran "xzcat [image].raw.xz | dd bs=4M > of=/dev/sdX iflag=fullblock oflag=direct; sync" (substituting relevant > info) per the wiki. This time i did use your commands. I got the same > result and output in the serial console as before. > > > U-Boot TPL 2020.01 (Jan 30 2020 - 10:43:44) > > data training error > > col error > > data training error > > LPDDR3, 800MHz > > BW=16 Col=12 Bk=8 CS0 Row=16 CS=1 Die BW=8 Size=4096MB > > I don't know much about Arm, so i don't know what that output means. :) This is the automatic delay adjustments to balance the trace lengths. Three possible reasons it fails: 1. bad board 2. initial timing settings too much off for the training to lock 3. unknown/new/different RAM chips which require a different setting Obviously, your RAM configuration is different from Matweys: > U-Boot TPL 2020.01 (Jan 30 2020 - 10:43:44) > LPDDR3, 800MHz > BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Kind regards, Stefan -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Rock64
On 2/12/20 8:59 AM, ITwrx wrote: > On 2/12/20 1:49 AM, Matwey V. Kornilov wrote: >> Hi, >> >> It is very strange to hear that. I deployed this image to couple of >> Rock64-s week ago. >> So, could you please be more specific? What are you trying to do exactly? >> >> You are supposed to download >> openSUSE-Tumbleweed-ARM-JeOS-rock64.aarch64-2020.01.30-Build5.29.raw.xz >> uncompress it with `xz -d >> openSUSE-Tumbleweed-ARM-JeOS-rock64.aarch64-2020.01.30-Build5.29.raw.xz` >> and write .raw file to microsd card as the following `dd_rescue >> openSUSE-Tumbleweed-ARM-JeOS-rock64.aarch64-2020.01.30-Build5.29.raw >> /dev/your_sd_card_here`. > That's what i did, but i'll try it again. I didn't get any errors when > writing the image. This time, i'll wipe the sd card and create one fat > partition, just to be on the safe side. >> Do you have usb rs232 ttl converter to attach the Rock64 console? What >> does it say? > i did, but i don't remember. It didn't get very far. If it fails this > time, i'll copy and paste the output. > > Thanks > >> ср, 12 февр. 2020 г. в 10:17, Guillaume Gardet : >>> Hi, >>> -Original Message- From: ITwrx Sent: 12 February 2020 03:49 To: opensuse-arm@opensuse.org Subject: [opensuse-arm] Rock64 Thorston/All, i just wanted to report that there are not Rock64 microOS images, only images for the older pine64. Also, the instructions on the Rock64 openSUSE wiki don't work (exactly as they are), using the below linked image file. I don't know what the corresponding "packages" file is for or how to use it, so it was not used in any way. The Rock64 >>> The "packages" file is just the list of installed packages in this *.raw.xz >>> image. >>> openSUSE wiki page didn't mention anything about it. Probably why the board won't boot... :) http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Roc kchip/images/openSUSE-Tumbleweed-ARM-JeOS-rock64.aarch64-2020.01.30- Build5.29.raw.xz Any tips appreciated. >>> Added Matwey in Cc who may help. >>> >>> Cheers, >>> Guillaume >>> Thanks, ITwrx -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org Ok, i misspoke earlier. The first time i didn't extract, then run dd_rescue per your instructions. i ran "xzcat [image].raw.xz | dd bs=4M of=/dev/sdX iflag=fullblock oflag=direct; sync" (substituting relevant info) per the wiki. This time i did use your commands. I got the same result and output in the serial console as before. > U-Boot TPL 2020.01 (Jan 30 2020 - 10:43:44) > data training error > col error > data training error > LPDDR3, 800MHz > BW=16 Col=12 Bk=8 CS0 Row=16 CS=1 Die BW=8 Size=4096MB I don't know much about Arm, so i don't know what that output means. :) Thanks -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Rock64
On 2/12/20 1:49 AM, Matwey V. Kornilov wrote: > Hi, > > It is very strange to hear that. I deployed this image to couple of > Rock64-s week ago. > So, could you please be more specific? What are you trying to do exactly? > > You are supposed to download > openSUSE-Tumbleweed-ARM-JeOS-rock64.aarch64-2020.01.30-Build5.29.raw.xz > uncompress it with `xz -d > openSUSE-Tumbleweed-ARM-JeOS-rock64.aarch64-2020.01.30-Build5.29.raw.xz` > and write .raw file to microsd card as the following `dd_rescue > openSUSE-Tumbleweed-ARM-JeOS-rock64.aarch64-2020.01.30-Build5.29.raw > /dev/your_sd_card_here`. That's what i did, but i'll try it again. I didn't get any errors when writing the image. This time, i'll wipe the sd card and create one fat partition, just to be on the safe side. > Do you have usb rs232 ttl converter to attach the Rock64 console? What > does it say? i did, but i don't remember. It didn't get very far. If it fails this time, i'll copy and paste the output. Thanks > > ср, 12 февр. 2020 г. в 10:17, Guillaume Gardet : >> Hi, >> >>> -Original Message- >>> From: ITwrx >>> Sent: 12 February 2020 03:49 >>> To: opensuse-arm@opensuse.org >>> Subject: [opensuse-arm] Rock64 >>> >>> Thorston/All, >>> >>> i just wanted to report that there are not Rock64 microOS images, only >>> images for >>> the older pine64. >>> >>> Also, the instructions on the Rock64 openSUSE wiki don't work (exactly as >>> they >>> are), using the below linked image file. I don't know what the corresponding >>> "packages" file is for or how to use it, so it was not used in any way. The >>> Rock64 >> The "packages" file is just the list of installed packages in this *.raw.xz >> image. >> >>> openSUSE wiki page didn't mention anything about it. Probably why the board >>> won't boot... :) >>> >>> http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Roc >>> kchip/images/openSUSE-Tumbleweed-ARM-JeOS-rock64.aarch64-2020.01.30- >>> Build5.29.raw.xz >>> >>> Any tips appreciated. >> Added Matwey in Cc who may help. >> >> Cheers, >> Guillaume >> >>> Thanks, >>> >>> ITwrx >>> >>> >>> -- >>> To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org >>> To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org > -- --- Information Technology Works on the net: https://ITwrx.org on the fediverse: @it...@blurts.net -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] Rock64
Hi, It is very strange to hear that. I deployed this image to couple of Rock64-s week ago. So, could you please be more specific? What are you trying to do exactly? You are supposed to download openSUSE-Tumbleweed-ARM-JeOS-rock64.aarch64-2020.01.30-Build5.29.raw.xz uncompress it with `xz -d openSUSE-Tumbleweed-ARM-JeOS-rock64.aarch64-2020.01.30-Build5.29.raw.xz` and write .raw file to microsd card as the following `dd_rescue openSUSE-Tumbleweed-ARM-JeOS-rock64.aarch64-2020.01.30-Build5.29.raw /dev/your_sd_card_here`. Do you have usb rs232 ttl converter to attach the Rock64 console? What does it say? ср, 12 февр. 2020 г. в 10:17, Guillaume Gardet : > > Hi, > > > -Original Message- > > From: ITwrx > > Sent: 12 February 2020 03:49 > > To: opensuse-arm@opensuse.org > > Subject: [opensuse-arm] Rock64 > > > > Thorston/All, > > > > i just wanted to report that there are not Rock64 microOS images, only > > images for > > the older pine64. > > > > Also, the instructions on the Rock64 openSUSE wiki don't work (exactly as > > they > > are), using the below linked image file. I don't know what the corresponding > > "packages" file is for or how to use it, so it was not used in any way. The > > Rock64 > > The "packages" file is just the list of installed packages in this *.raw.xz > image. > > > openSUSE wiki page didn't mention anything about it. Probably why the board > > won't boot... :) > > > > http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Roc > > kchip/images/openSUSE-Tumbleweed-ARM-JeOS-rock64.aarch64-2020.01.30- > > Build5.29.raw.xz > > > > Any tips appreciated. > > Added Matwey in Cc who may help. > > Cheers, > Guillaume > > > > > Thanks, > > > > ITwrx > > > > > > -- > > To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org > > To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org > -- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
RE: [opensuse-arm] Rock64
Hi,
> -Original Message-
> From: ITwrx
> Sent: 12 February 2020 03:49
> To: opensuse-arm@opensuse.org
> Subject: [opensuse-arm] Rock64
>
> Thorston/All,
>
> i just wanted to report that there are not Rock64 microOS images, only images
> for
> the older pine64.
>
> Also, the instructions on the Rock64 openSUSE wiki don't work (exactly as they
> are), using the below linked image file. I don't know what the corresponding
> "packages" file is for or how to use it, so it was not used in any way. The
> Rock64
The "packages" file is just the list of installed packages in this *.raw.xz
image.
> openSUSE wiki page didn't mention anything about it. Probably why the board
> won't boot... :)
>
> http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Roc
> kchip/images/openSUSE-Tumbleweed-ARM-JeOS-rock64.aarch64-2020.01.30-
> Build5.29.raw.xz
>
> Any tips appreciated.
Added Matwey in Cc who may help.
Cheers,
Guillaume
>
> Thanks,
>
> ITwrx
>
>
> --
> To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
> To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
N�r��y隊Z)z{.�櫛맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.�櫛�0�Ǩ�
Re: [opensuse-arm] rock64
On Wednesday, June 6, 2018 3:17:35 AM CDT Andreas Schwab wrote: > On Jun 06 2018, Matthias Brugger wrote: > >> I'm not very good at compiling. - Building u-boot is probably beyond my > >> abilities. - I tried briefly, but things like this bog me down & I lose > >> interest. > >> update-alternatives: using /usr/bin/aarch64-suse-linux-gcc-7 to provide > >> /usr/ bin/aarch64-suse-linux-gcc (aarch64-suse-linux-gcc) in auto mode > >> > >> make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- > >> make: aarch64-linux-gnu-gcc: Command not found > >> > >> - Do I make a symlink? or edit a file? Oh well. > > > > You need to have your cross compiler toolchain in your $PATH. > > That won't help if you use the wrong name. > > Andreas. Andreas, Thanks for the hint. I was following the generic build instruction from rock- chip here: http://opensource.rock-chips.com/wiki_U-Boot . openSUSE calls the cross-compiler by it's own name. That got my a little farther. Now I have this error: aarch64-suse-linux-ld.bfd: cannot find -lgcc Bill Merriam replied off-list suggesting using github.com/ayufan-rock64 u- boot. I've been using his Ubuntu Xenial & Bionic images. - They have been very stable. I used ayufan's sd card image to flash u-boot to SPI, but I only got a few lines of gibberish on the serial console when trying to boot the openSUSE Jeos image. - I don't know what parts of the bootloader ayufan installs, nor do I know what the openSUSE Jeos image needs to boot. Mark -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
> > > > A search for u-boot-rock64 still comes up empty on OBS, and upstream > > U-Boot doesn't seem to have it either, so I can't package u-boot-rock64 > > myself yet either. > > There is a working u-boot for rock64 on github. https://github.com/ayufan-rock64/linux-u-boot Ayufan also has a docker image that will compile u-boot plus other things for rock64. https://github.com/ayufan-rock64/linux-build He publishes images for debian and ubuntu that work pretty well. Some months ago I grabbed one of his images and replaced the debian root filesystem with an opensuse tumbleweed root filesystem. I obviously should have made careful notes about how I did that, but I didn't. Anyway that gave me an image with all the various boot loaders and our filesystem. His kernel was too old for what I needed so I somehow got a kernel source with both opensuse patches and ayufan's patches on it. That gave me a 4.16 kernel that works. Those patches are supposed to be moving toward mainline. I don't know if they got there. Ayufan has repos at gitlab. I don't know if he is moving there or just mirroring there. I will now try to replace my tumbleweed filesystem with leap 15.0 and use my existing kernel. For extra credit I will look at packaging the rock64 firmware, boot loaders and uboot for obs and kiwi. Bill -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
On Jun 06 2018, Matthias Brugger wrote: >> I'm not very good at compiling. - Building u-boot is probably beyond my >> abilities. - I tried briefly, but things like this bog me down & I lose >> interest. >> update-alternatives: using /usr/bin/aarch64-suse-linux-gcc-7 to provide /usr/ >> bin/aarch64-suse-linux-gcc (aarch64-suse-linux-gcc) in auto mode >> >> make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- >> make: aarch64-linux-gnu-gcc: Command not found >> - Do I make a symlink? or edit a file? Oh well. > > You need to have your cross compiler toolchain in your $PATH. That won't help if you use the wrong name. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
On 06/06/18 01:55, Mark Petersen wrote: > On Tuesday, June 5, 2018 1:36:48 PM CDT Andreas Färber wrote: >> Hello Mark, >> >> Am 05.06.2018 um 18:40 schrieb Mark Petersen: >>> I'm trying to get openSUSE running on my rock64 2GB SBC. >>> >>> I've tried to follow the HCL guide from here: https://en.opensuse.org/ >>> HCL:Rock64 but things must have changed in the github repo. There are no >>> rpm's in the repo so the rest of the process doesn't work. >> >> You're misreading Matwey's instructions: He is suggesting to extract two >> RPMs (listed as prerequisites) _into_ the git repo, not from it. >> >> A search for u-boot-rock64 still comes up empty on OBS, and upstream >> U-Boot doesn't seem to have it either, so I can't package u-boot-rock64 >> myself yet either. >> >> There is an evb-rk3328 upstream though that could serve as starting >> point, if you want to contribute to upstream U-Boot and openSUSE. >> >> Wherever from, you need a suitable u-boot.bin. >> >> No need to extract mkimage that way, just run: zypper in u-boot-tools >> >> Cheers, >> Andreas > > Andreas, > > Thanks for the reply. > > I missed the part about the prerequisites. > > I'm not very good at compiling. - Building u-boot is probably beyond my > abilities. - I tried briefly, but things like this bog me down & I lose > interest. > update-alternatives: using /usr/bin/aarch64-suse-linux-gcc-7 to provide /usr/ > bin/aarch64-suse-linux-gcc (aarch64-suse-linux-gcc) in auto mode > > make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- > make: aarch64-linux-gnu-gcc: Command not found > - Do I make a symlink? or edit a file? Oh well. You need to have your cross compiler toolchain in your $PATH. Regards, Matthias > > If someone needs it, I'd be happy to do some testing with my rock64. > > Mark > > > > > > -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
On Tuesday, June 5, 2018 1:36:48 PM CDT Andreas Färber wrote: > Hello Mark, > > Am 05.06.2018 um 18:40 schrieb Mark Petersen: > > I'm trying to get openSUSE running on my rock64 2GB SBC. > > > > I've tried to follow the HCL guide from here: https://en.opensuse.org/ > > HCL:Rock64 but things must have changed in the github repo. There are no > > rpm's in the repo so the rest of the process doesn't work. > > You're misreading Matwey's instructions: He is suggesting to extract two > RPMs (listed as prerequisites) _into_ the git repo, not from it. > > A search for u-boot-rock64 still comes up empty on OBS, and upstream > U-Boot doesn't seem to have it either, so I can't package u-boot-rock64 > myself yet either. > > There is an evb-rk3328 upstream though that could serve as starting > point, if you want to contribute to upstream U-Boot and openSUSE. > > Wherever from, you need a suitable u-boot.bin. > > No need to extract mkimage that way, just run: zypper in u-boot-tools > > Cheers, > Andreas Andreas, Thanks for the reply. I missed the part about the prerequisites. I'm not very good at compiling. - Building u-boot is probably beyond my abilities. - I tried briefly, but things like this bog me down & I lose interest. update-alternatives: using /usr/bin/aarch64-suse-linux-gcc-7 to provide /usr/ bin/aarch64-suse-linux-gcc (aarch64-suse-linux-gcc) in auto mode make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- make: aarch64-linux-gnu-gcc: Command not found - Do I make a symlink? or edit a file? Oh well. If someone needs it, I'd be happy to do some testing with my rock64. Mark -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
Hello Mark, Am 05.06.2018 um 18:40 schrieb Mark Petersen: > I'm trying to get openSUSE running on my rock64 2GB SBC. > > I've tried to follow the HCL guide from here: https://en.opensuse.org/ > HCL:Rock64 but things must have changed in the github repo. There are no > rpm's > in the repo so the rest of the process doesn't work. You're misreading Matwey's instructions: He is suggesting to extract two RPMs (listed as prerequisites) _into_ the git repo, not from it. A search for u-boot-rock64 still comes up empty on OBS, and upstream U-Boot doesn't seem to have it either, so I can't package u-boot-rock64 myself yet either. There is an evb-rk3328 upstream though that could serve as starting point, if you want to contribute to upstream U-Boot and openSUSE. Wherever from, you need a suitable u-boot.bin. No need to extract mkimage that way, just run: zypper in u-boot-tools 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
2018-03-10 12:41 GMT+03:00 Alexander Graf : > > >> Am 10.03.2018 um 10:05 schrieb Matwey V. Kornilov >> : >> >> 2018-03-10 3:03 GMT+03:00 Alexander Graf : >>> >>> 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-de...@redhat.com [ 133.143024] Internal error: Oops - SP/PC alignment exception: 8a00 [#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: 2005 (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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
> Am 10.03.2018 um 10:05 schrieb Matwey V. Kornilov : > > 2018-03-10 3:03 GMT+03:00 Alexander Graf : >> >> >>> 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-de...@redhat.com >>> [ 133.143024] Internal error: Oops - SP/PC alignment exception: >>> 8a00 [#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: 2005 (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. Alex > >> >> >> Alex > > > > -- > With best regards, > Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
2018-03-10 3:03 GMT+03:00 Alexander Graf : > > > 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-de...@redhat.com >> [ 133.143024] Internal error: Oops - SP/PC alignment exception: >> 8a00 [#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: 2005 (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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
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-de...@redhat.com > [ 133.143024] Internal error: Oops - SP/PC alignment exception: > 8a00 [#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: 2005 (nzCv daif -PAN -UAO) > [ 133.150738] pc : 0x6d6d61675f7465 localhost:~ # echo 6d6d61675f7465 | xxd -ps -r ; echo mmag_te 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? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
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-de...@redhat.com [ 133.143024] Internal error: Oops - SP/PC alignment exception: 8a00 [#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: 2005 (nzCv daif -PAN -UAO) [ 133.150738] pc : 0x6d6d61675f7465 [ 133.151048] lr : __do_softirq+0x164/0x384 [ 133.151411] sp : 08013ed0 [ 133.151713] x29: 08013ed0 x28: 0002 [ 133.152197] x27: 092a61c8 x26: 08ee6010 [ 133.152681] x25: 092a6180 x24: 0009 [ 133.153164] x23: 0100 x22: 0010 [ 133.153648] x21: 092a61c0 x20: 0002 [ 133.154132] x19: 0009 x18: 95442a70 [ 133.154616] x17: 953485d0 x16: b0f52c48 [ 133.155100] x15: x14: [ 133.155585] x13: 7fff x12: [ 133.156068] x11: 0001 x10: 08013e98 [ 133.156551] x9 : x8 : 0013 [ 133.157034] x7 : 80007ff7bf28 x6 : 80007ff83a10 [ 133.157519] x5 : 08014000 x4 : 80004c702080 [ 133.158003] x3 : 80007708f000 x2 : 0008 [ 133.158487] x1 : 616d6d61675f7465 x0 : 092a61c8 [ 133.158975] Process depmod (pid: 1868, stack limit = 0x0c1b7bc2) [ 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 : > 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 : >> Am 02.01.2018 um 16:59 schrieb Matwey V. Kornilov: >>> 2018-01-02 18:27 GMT+03:00 Andreas Färber : 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/pine64-instsd >> >> 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
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 : > Am 02.01.2018 um 16:59 schrieb Matwey V. Kornilov: >> 2018-01-02 18:27 GMT+03:00 Andreas Färber : >>> 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/pine64-instsd > > 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 -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
Am 02.01.2018 um 16:59 schrieb Matwey V. Kornilov: > 2018-01-02 18:27 GMT+03:00 Andreas Färber : >> 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/pine64-instsd 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
2018-01-02 18:27 GMT+03:00 Andreas Färber : > Am 01.01.2018 um 16:20 schrieb Matwey V. Kornilov: >> 2017-09-02 13:25 GMT+03:00 Andreas Färber : >>> 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? Nope. Where can I find it? https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:Pine64 This one? > 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) -- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
Am 01.01.2018 um 16:20 schrieb Matwey V. Kornilov: > 2017-09-02 13:25 GMT+03:00 Andreas Färber : >> 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
2018-01-01 18:20 GMT+03:00 Matwey V. Kornilov : > 2017-09-02 13:25 GMT+03:00 Andreas Färber : >> 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. And there is one thing which I can't understand. Currently, u-boot based TPL/SPL located at 0x40 sector for rk3328. Why SPL u-boot loader can't read u-boot.itb from the filesystem? As far as I understand there is no "return to bootrom" step after SPL. So there should be no reason to find u-boot.itb at specific place at SD card. Could somebody explain me how this is supposed to work? > >> >> 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
2017-09-02 13:25 GMT+03:00 Andreas Färber : > 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
I've just booted u-boot 2018 with TPL/SPL on Rock64. However, I still need bl31.elf from arm-trusted-firmware to produce u-boot.itb 2017-10-28 18:21 GMT+03:00 Matwey V. Kornilov : > 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 : >> I'll try to figure out how to use SPL u-boot instead. >> >> 2017-08-25 22:16 GMT+03:00 Matwey V. Kornilov : >>> 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 : Well, it is interesting that default serial console baudrate is 150 which is not supported by screen, my tools of the choice. 2017-08-17 12:52 GMT+03:00 Matthias Brugger : > > > 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 -- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
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 : > I'll try to figure out how to use SPL u-boot instead. > > 2017-08-25 22:16 GMT+03:00 Matwey V. Kornilov : >> 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 : >>> Well, it is interesting that default serial console baudrate is >>> 150 which is not supported by screen, my tools of the choice. >>> >>> 2017-08-17 12:52 GMT+03:00 Matthias Brugger : 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
d5380001 is mrs x1, midr_el1
What could be wrong here? AFAIU, it is just CPU identification read.
Not sure, why modprobe needs it at all.
2017-09-19 20:09 GMT+03:00 Matwey V. Kornilov :
> This helps
>
> earlycon=uart8250,mmio32,0xff13 console=ttyS2,150
>
> However, something is going wrong.
>
> [ 11.181943] modprobe[93]: undefined instruction: pc=b1dccff4
> [ 11.182589] Code: d503201f 8a180320 92750001 365ffc20 (d5380001)
> [ 11.184268] modprobe[94]: undefined instruction: pc=a3f7bff4
> [ 11.184913] Code: d503201f 8a180320 92750001 365ffc20 (d5380001)
> [ 11.186988] modprobe[97]: undefined instruction: pc=bd2bfff4
> [ 11.187632] Code: d503201f 8a180320 92750001 365ffc20 (d5380001)
> [ 11.189299] modprobe[98]: undefined instruction: pc=8cbfeff4
> [ 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 :
>> 2017-09-05 16:28 GMT+03:00 Alexander Graf :
>>>
>>>
>>> On 05.09.17 15:23, Matwey V. Kornilov wrote:
2017-09-05 16:12 GMT+03:00 Alexander Graf :
>
>
>
> On 05.09.17 15:02, Matwey V. Kornilov wrote:
>>
>>
>> 2017-09-05 16:00 GMT+03:00 Alexander Graf :
>>>
>>>
>>>
>>> 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,0xff13
>
>
>
> 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 = 0x
boot_params = 0x
DRAM bank = 0x
-> start= 0x0020
>>>
>>>
>>> This is the offset. It does sound quite weird though, so don't be surprised
>>> if things don't work :).
>>
>> 0951aa68 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 b
Re: [opensuse-arm] rock64
Can not activate any debug shell.
2017-09-19 22:15 GMT+03:00 Matwey V. Kornilov :
> pc-s are different every time, the rest persists.
>
> 2017-09-19 20:09 GMT+03:00 Matwey V. Kornilov :
>> This helps
>>
>> earlycon=uart8250,mmio32,0xff13 console=ttyS2,150
>>
>> However, something is going wrong.
>>
>> [ 11.181943] modprobe[93]: undefined instruction: pc=b1dccff4
>> [ 11.182589] Code: d503201f 8a180320 92750001 365ffc20 (d5380001)
>> [ 11.184268] modprobe[94]: undefined instruction: pc=a3f7bff4
>> [ 11.184913] Code: d503201f 8a180320 92750001 365ffc20 (d5380001)
>> [ 11.186988] modprobe[97]: undefined instruction: pc=bd2bfff4
>> [ 11.187632] Code: d503201f 8a180320 92750001 365ffc20 (d5380001)
>> [ 11.189299] modprobe[98]: undefined instruction: pc=8cbfeff4
>> [ 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 :
>>> 2017-09-05 16:28 GMT+03:00 Alexander Graf :
On 05.09.17 15:23, Matwey V. Kornilov wrote:
>
> 2017-09-05 16:12 GMT+03:00 Alexander Graf :
>>
>>
>>
>> On 05.09.17 15:02, Matwey V. Kornilov wrote:
>>>
>>>
>>> 2017-09-05 16:00 GMT+03:00 Alexander Graf :
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,0xff13
>>
>>
>>
>> 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 = 0x
> boot_params = 0x
> DRAM bank = 0x
> -> start= 0x0020
This is the offset. It does sound quite weird though, so don't be surprised
if things don't work :).
>>>
>>> 0951aa68 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 f
Re: [opensuse-arm] rock64
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 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: <.text>: 0: d503201fnop 4: 8a180320and x0, x25, x24 8: 92750001and x1, x0, #0x800 c: 365ffc20tbz w0, #11, 0xff90 10: d5380001mrs 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 -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
pc-s are different every time, the rest persists.
2017-09-19 20:09 GMT+03:00 Matwey V. Kornilov :
> This helps
>
> earlycon=uart8250,mmio32,0xff13 console=ttyS2,150
>
> However, something is going wrong.
>
> [ 11.181943] modprobe[93]: undefined instruction: pc=b1dccff4
> [ 11.182589] Code: d503201f 8a180320 92750001 365ffc20 (d5380001)
> [ 11.184268] modprobe[94]: undefined instruction: pc=a3f7bff4
> [ 11.184913] Code: d503201f 8a180320 92750001 365ffc20 (d5380001)
> [ 11.186988] modprobe[97]: undefined instruction: pc=bd2bfff4
> [ 11.187632] Code: d503201f 8a180320 92750001 365ffc20 (d5380001)
> [ 11.189299] modprobe[98]: undefined instruction: pc=8cbfeff4
> [ 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 :
>> 2017-09-05 16:28 GMT+03:00 Alexander Graf :
>>>
>>>
>>> On 05.09.17 15:23, Matwey V. Kornilov wrote:
2017-09-05 16:12 GMT+03:00 Alexander Graf :
>
>
>
> On 05.09.17 15:02, Matwey V. Kornilov wrote:
>>
>>
>> 2017-09-05 16:00 GMT+03:00 Alexander Graf :
>>>
>>>
>>>
>>> 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,0xff13
>
>
>
> 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 = 0x
boot_params = 0x
DRAM bank = 0x
-> start= 0x0020
>>>
>>>
>>> This is the offset. It does sound quite weird though, so don't be surprised
>>> if things don't work :).
>>
>> 0951aa68 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
Re: [opensuse-arm] rock64
This helps
earlycon=uart8250,mmio32,0xff13 console=ttyS2,150
However, something is going wrong.
[ 11.181943] modprobe[93]: undefined instruction: pc=b1dccff4
[ 11.182589] Code: d503201f 8a180320 92750001 365ffc20 (d5380001)
[ 11.184268] modprobe[94]: undefined instruction: pc=a3f7bff4
[ 11.184913] Code: d503201f 8a180320 92750001 365ffc20 (d5380001)
[ 11.186988] modprobe[97]: undefined instruction: pc=bd2bfff4
[ 11.187632] Code: d503201f 8a180320 92750001 365ffc20 (d5380001)
[ 11.189299] modprobe[98]: undefined instruction: pc=8cbfeff4
[ 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 :
> 2017-09-05 16:28 GMT+03:00 Alexander Graf :
>>
>>
>> On 05.09.17 15:23, Matwey V. Kornilov wrote:
>>>
>>> 2017-09-05 16:12 GMT+03:00 Alexander Graf :
On 05.09.17 15:02, Matwey V. Kornilov wrote:
>
>
> 2017-09-05 16:00 GMT+03:00 Alexander Graf :
>>
>>
>>
>> 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,0xff13
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 = 0x
>>> boot_params = 0x
>>> DRAM bank = 0x
>>> -> start= 0x0020
>>
>>
>> This is the offset. It does sound quite weird though, so don't be surprised
>> if things don't work :).
>
> 0951aa68 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
Re: [opensuse-arm] rock64
2017-09-05 16:28 GMT+03:00 Alexander Graf :
>
>
> On 05.09.17 15:23, Matwey V. Kornilov wrote:
>>
>> 2017-09-05 16:12 GMT+03:00 Alexander Graf :
>>>
>>>
>>>
>>> On 05.09.17 15:02, Matwey V. Kornilov wrote:
2017-09-05 16:00 GMT+03:00 Alexander Graf :
>
>
>
> 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,0xff13
>>>
>>>
>>>
>>> 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 = 0x
>> boot_params = 0x
>> DRAM bank = 0x
>> -> start= 0x0020
>
>
> This is the offset. It does sound quite weird though, so don't be surprised
> if things don't work :).
0951aa68 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+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
Am 05.09.2017 um 15:28 schrieb Alexander Graf: > > > On 05.09.17 15:23, Matwey V. Kornilov wrote: >> 2017-09-05 16:12 GMT+03:00 Alexander Graf : >>> >>> >>> On 05.09.17 15:02, Matwey V. Kornilov wrote: 2017-09-05 16:00 GMT+03:00 Alexander Graf : > > > 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,0xff13 >>> >>> >>> 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 = 0x >> boot_params = 0x >> DRAM bank = 0x >> -> start = 0x0020 > > This is the offset. It does sound quite weird though, so don't be > surprised if things don't work :). This means the offset is actually zero, but 0x20 bytes are reserved for ATF or something. 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
On 05.09.17 15:23, Matwey V. Kornilov wrote: 2017-09-05 16:12 GMT+03:00 Alexander Graf : On 05.09.17 15:02, Matwey V. Kornilov wrote: 2017-09-05 16:00 GMT+03:00 Alexander Graf : 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,0xff13 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 = 0x boot_params = 0x DRAM bank = 0x -> start= 0x0020 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
2017-09-05 16:12 GMT+03:00 Alexander Graf : > > > On 05.09.17 15:02, Matwey V. Kornilov wrote: >> >> 2017-09-05 16:00 GMT+03:00 Alexander Graf : >>> >>> >>> 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,0xff13 > > > 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 = 0x boot_params = 0x DRAM bank = 0x -> start= 0x0020 -> size = 0x7FE0 current eth = unknown ip_addr = baudrate= 150 bps TLB addr= 0x7FFF relocaddr = 0x7FF41000 reloc off = 0x7FD41000 irq_sp = 0x7DF37660 sp start= 0x7DF37660 Early malloc usage: 460 / 800 fdt_blob = 7df37670 > > 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 -- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
On 05.09.17 15:02, Matwey V. Kornilov wrote: 2017-09-05 16:00 GMT+03:00 Alexander Graf : 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,0xff13 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
2017-09-05 16:00 GMT+03:00 Alexander Graf : > > 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,0xff13 > > > > Alex -- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
Still no luck. No signal at video, no text in console after EFI stub. Any ideas why? 2017-09-04 14:25 GMT+03:00 Matwey V. Kornilov : > 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 : >> Hm, console=ttyS2,150 supposed to work, but it doesnt... >> >> 2017-09-04 11:00 GMT+03:00 Matwey V. Kornilov : >>> 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 : 2017-09-02 13:25 GMT+03:00 Andreas Färber : > 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 -- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
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 : > Hm, console=ttyS2,150 supposed to work, but it doesnt... > > 2017-09-04 11:00 GMT+03:00 Matwey V. Kornilov : >> 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 : >>> 2017-09-02 13:25 GMT+03:00 Andreas Färber : 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
Hm, console=ttyS2,150 supposed to work, but it doesnt... 2017-09-04 11:00 GMT+03:00 Matwey V. Kornilov : > 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 : >> 2017-09-02 13:25 GMT+03:00 Andreas Färber : >>> 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 -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
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 : > 2017-09-02 13:25 GMT+03:00 Andreas Färber : >> 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
Hi everybody, Am 02.09.2017 um 12:29 schrieb Matwey V. Kornilov: 2017-09-02 13:25 GMT+03:00 Andreas Färber : 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. More long-term rock64 comes with SPI flash that is meant to store a bootloader. So at some point that will be available, and present independent of the OS. I think we could safely assume that the user takes care of putting a bootloader , and just rely on distro_boot for loading grub.efi and a devicetree. 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) -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
2017-09-02 13:25 GMT+03:00 Andreas Färber : > 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
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. 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) -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
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 : > Ok, grub is running... > > 2017-08-30 13:17 GMT+03:00 Matwey V. Kornilov : >> Required u-boot.bin from rpm package: >> https://build.opensuse.org/package/show/home:matwey:branches:Base:System:Staging/u-boot-rock64 >> >> 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 : >>> So, I've managed to start our u-boot. >>> >>> => version >>> >>> U-Boot 2017.07 (Aug 22 2017 - 12:51:50 +) >>> 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 : 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 : > 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_the_suitable_official_Debian_image.3F > 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" 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 : >> > On Tue, 29 Aug 2017 16:23:44 +0200 >> > Andreas Färber wrote: >> > >> >> Am 29.08.2017 um 14:08 schrieb Michal Suchánek: >> >> > On Fri, 25 Aug 2017 22:16:09 +0300 >> >> > "Matwey V. Kornilov" 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 rkflasht
Re: [opensuse-arm] rock64
Ok, grub is running... 2017-08-30 13:17 GMT+03:00 Matwey V. Kornilov : > Required u-boot.bin from rpm package: > https://build.opensuse.org/package/show/home:matwey:branches:Base:System:Staging/u-boot-rock64 > > 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 : >> So, I've managed to start our u-boot. >> >> => version >> >> U-Boot 2017.07 (Aug 22 2017 - 12:51:50 +) >> 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 : >>> 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 : 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_the_suitable_official_Debian_image.3F 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" 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 : > > On Tue, 29 Aug 2017 16:23:44 +0200 > > Andreas Färber wrote: > > > >> Am 29.08.2017 um 14:08 schrieb Michal Suchánek: > >> > On Fri, 25 Aug 2017 22:16:09 +0300 > >> > "Matwey V. Kornilov" 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 c
Re: [opensuse-arm] rock64
Required u-boot.bin from rpm package: https://build.opensuse.org/package/show/home:matwey:branches:Base:System:Staging/u-boot-rock64 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 : > So, I've managed to start our u-boot. > > => version > > U-Boot 2017.07 (Aug 22 2017 - 12:51:50 +) > 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 : >> 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 : >>> 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_the_suitable_official_Debian_image.3F >>> 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" 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 : > On Tue, 29 Aug 2017 16:23:44 +0200 > Andreas Färber wrote: > >> Am 29.08.2017 um 14:08 schrieb Michal Suchánek: >> > On Fri, 25 Aug 2017 22:16:09 +0300 >> > "Matwey V. Kornilov" 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.
Re: [opensuse-arm] rock64
So, I've managed to start our u-boot. => version U-Boot 2017.07 (Aug 22 2017 - 12:51:50 +) 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 : > 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 : >> 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_the_suitable_official_Debian_image.3F >> 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" 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 : >>> > On Tue, 29 Aug 2017 16:23:44 +0200 >>> > Andreas Färber wrote: >>> > >>> >> Am 29.08.2017 um 14:08 schrieb Michal Suchánek: >>> >> > On Fri, 25 Aug 2017 22:16:09 +0300 >>> >> > "Matwey V. Kornilov" 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 -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
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 : > 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_the_suitable_official_Debian_image.3F > 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" 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 : >> > On Tue, 29 Aug 2017 16:23:44 +0200 >> > Andreas Färber wrote: >> > >> >> Am 29.08.2017 um 14:08 schrieb Michal Suchánek: >> >> > On Fri, 25 Aug 2017 22:16:09 +0300 >> >> > "Matwey V. Kornilov" 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
Michal, Am 29.08.2017 um 18:02 schrieb Michal Suchánek: > Unfortunately, the wiki which had the information on > reverse-engineering of the boot sequence is gone. The boot sequence is documented by Rockchip on the link I just gave! http://opensource.rock-chips.com/wiki_Boot_option No need to reverse engineer it. The purpose of the U-Boot SPL work is merely to get rid of binary blobs and the tools to create them. 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
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_the_suitable_official_Debian_image.3F 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" 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 : > > On Tue, 29 Aug 2017 16:23:44 +0200 > > Andreas Färber wrote: > > > >> Am 29.08.2017 um 14:08 schrieb Michal Suchánek: > >> > On Fri, 25 Aug 2017 22:16:09 +0300 > >> > "Matwey V. Kornilov" 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
Am 29.08.2017 um 16:40 schrieb Michal Suchánek:
> On Tue, 29 Aug 2017 16:23:44 +0200
> Andreas Färber wrote:
>> Am 29.08.2017 um 14:08 schrieb Michal Suchánek:
>>> On Fri, 25 Aug 2017 22:16:09 +0300
>>> "Matwey V. Kornilov" 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.
Please see rkdeveloptool:
https://build.opensuse.org/package/show/hardware/rkdeveloptool
>> 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.
Like Matwey and I said, it's not that easy on arm64. Some parts can't be
flashed into individual partitions because the ARM Trusted Firmware
fip.bin and other Rockchip-specific formats are used, with several
binaries glued together ("the files to be flashed").
At oSC17 I spoke about an RK3328 TV box, where I did not succeed in
interrupting U-Boot, so the various "magic" pieces need to be replaced
with their latest versions according to the Rockchip instructions.
There's so many loader pieces that you can't just load one to memory;
you need to flash a compatible combination, reset and see if it works.
Matwey, see https://en.opensuse.org/HCL:Firefly-RK3399#U-Boot for how to
do it on RK3399 without SPL using Open Source tools apart from binary
"loaderimage". The same "armv8 with miniloader" instructions from
http://opensource.rock-chips.com/wiki_Boot_option should apply, just
with different files from the rkbin repo that you already know.
If you've meanwhile succeeded with SPL please let us know.
I barely just received a Rock64 and haven't played with it yet.
Guillaume has updated and submitted U-Boot - we'll need to check on
which additional boards can be enabled already and where/how to combine
that with my ATF builds - no progress there yet.
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+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
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 : > On Tue, 29 Aug 2017 16:23:44 +0200 > Andreas Färber wrote: > >> Am 29.08.2017 um 14:08 schrieb Michal Suchánek: >> > On Fri, 25 Aug 2017 22:16:09 +0300 >> > "Matwey V. Kornilov" 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
On Tue, 29 Aug 2017 16:23:44 +0200 Andreas Färber wrote: > Am 29.08.2017 um 14:08 schrieb Michal Suchánek: > > On Fri, 25 Aug 2017 22:16:09 +0300 > > "Matwey V. Kornilov" 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
Am 29.08.2017 um 14:08 schrieb Michal Suchánek: > On Fri, 25 Aug 2017 22:16:09 +0300 > "Matwey V. Kornilov" 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. 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. 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
Hello, On Fri, 25 Aug 2017 22:16:09 +0300 "Matwey V. Kornilov" 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
I'll try to figure out how to use SPL u-boot instead. 2017-08-25 22:16 GMT+03:00 Matwey V. Kornilov : > 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 : >> Well, it is interesting that default serial console baudrate is >> 150 which is not supported by screen, my tools of the choice. >> >> 2017-08-17 12:52 GMT+03:00 Matthias Brugger : >>> >>> >>> 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 -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
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 : > Well, it is interesting that default serial console baudrate is > 150 which is not supported by screen, my tools of the choice. > > 2017-08-17 12:52 GMT+03:00 Matthias Brugger : >> >> >> 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
Am 24.08.2017 um 19:49 schrieb Matwey V. Kornilov: > Well, it is interesting that default serial console baudrate is > 150 which is not supported by screen, my tools of the choice. Compare Firefly-RK3399, Orange PI 2G-IoT and other HCL pages - you can use minicom -D /dev/ttyUSBx -b 150 instead (quit: Ctrl+A, Q). If you have any additional insights about screen please share them here: http://bugzilla.opensuse.org/show_bug.cgi?id=1015392 Note it may also depend on your UART adapter. 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
Well, it is interesting that default serial console baudrate is 150 which is not supported by screen, my tools of the choice. 2017-08-17 12:52 GMT+03:00 Matthias Brugger : > > > 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+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
2017-08-17 12:52 GMT+03:00 Matthias Brugger : > > > 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 > Just build one in https://build.opensuse.org/project/show/home:matwey:branches:Base:System:Staging > Have fun! > Matthias -- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
Re: [opensuse-arm] rock64
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 -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
