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 "x
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
>
>> ср, 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]
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-
>>>
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,
> &
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
>
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 h
I finally have had some time to try to get opensuse Tumbleweed to boot on my
2Gb rock64.
The image I used was downloaded from:
https://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/
Rockchip/images/
After dd'ing the image to the emmc, I installed the Arch u-boot using this
Has anyone been using a rock64, interested in your thoughts. Can you
run the opensuse arm distribution on it? Do you have to do anything
special to get the hdmi 2.0 port to fully exploit uhd?
-Steve
--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: o
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-alternativ
> >
> > 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
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/aar
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
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
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
Hello,
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.
I used xzcat/dd to write the
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:
===> Call
> 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] s
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
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-map
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...
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 st
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
>>>
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
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
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 ar
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
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 Debia
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
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
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
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 ;
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.1
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:
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.1
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, Matw
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 E
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 ide
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 par
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...
Indee
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...@open
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
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 :
>> Booti
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 supplie
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: Ex
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 too
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
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
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
pr
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/bl
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
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:
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
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 re
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 k
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:
>>>
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
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/maste
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 know
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 becaus
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.
> Proprie
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
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 ins
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.
>>
>> http
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
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:
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.
--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow.
67 matches
Mail list logo
