[opensuse-arm] Re: Extremely slow boot of raspberry pi 4 images

[Matwey V. Kornilov]

30.10.2020 13:06, Tamara Schmitz пишет:
> Hello,
> 
> I just downloaded the image for my Pi as well and I also recently
> watched Peter Chubb's from 2015 talk regarding his experience and with
> SD cards and Linux filesystems. https://www.youtube.com/watch?v=K3zb6p0thQU
> 
> There he notes that most MCUs and firmwares work with a 4M alignment
> size. Hence the general recommendation appears to be to keep the MBR
> table in that first 4M block and align the first partition start to
> address 4096. This seems to be what the official formatting tool of the
> SD Association does.
> 
> When I flashed the current Tumbleweed JeOS image to my SD card with dd I
> noticed that the partition starts at 2048. Other partition start
> addresses do not appear to fit into the physical 4M block size either.
> Swap starts at 133120 (divided by 4098 equals 32.5) and does not align,
> Root at 11571120 (divided by 4098 equals 2823.60...).
> 
> 
> So hence to improve performance the alignment of the partitions on the
> image should be fixed. The question is how.

There is KIWI option  
> 
> Best regards
> 
> Tamara
> 
> 
> On 29/10/2020 09:51, Freek de Kruijf wrote:
>> Op woensdag 28 oktober 2020 16:02:44 CET schreef Freek de Kruijf:
>>>
>>> Once the system is up, it behaves normal/fast. I don't have another
>>> RPi4. I
>>> could try another uSD, but considering it is fast when it is up I
>>> have no
>>> hopes. The uSD i use now is a Sandisk Ultra with 128GB and an
>>> encircled 10.
>>> Also putting the image on it is fast.
>>>
 Cheers,
 Guillaume
>> Another observation is that another uSD with Raspbian is working
>> normally.
>> Boots in less than a minute. So it is NOT the RPi4.
>>
>> openSUSE shows a number of tests on different partitions, before it
>> finds a
>> bootable image and gives an error message that an image has not been
>> found.
>>
>> Will try the uSD with Raspbian with openSUSE.
>>
-- 
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: Re : [opensuse-arm] openQA generalhw backend

[Matwey V. Kornilov]

вс, 23 авг. 2020 г. в 13:34, Matwey V. Kornilov :

>
> Thanks, Guillaume!
>
> Do I understand correctly, that SUT-companion and OpenQA worker may be on
> the same host?
>
> I would like to test BeagleBone Black. In an ideal world, I would like it
> to be tested on openqa.opensuse.org.
> Now I see that I have to learn how to boot the board from USB. The AM335x
> reference documentation says that it is possible to load U-Boot firmware
> via UART and USB, but I have never tried it.
>
>
JFYI,

I've enabled booting the system from USB device for am335x:
https://github.com/u-boot/u-boot/commit/8c444c184c36dfa314a2a500349785f58c8a8d24
It works fine with JeOS written on USB-flash drive.

I've also managed to learn how to supply U-boot via UART, but it works too
slow: 10KBps given U-boot size is about 1MB.


>
> вс, 23 авг. 2020 г. в 10:25, Guillaume GARDET :
>
>>
>> Hi Matwey,
>>
>> Here are some details about the RPi3 case:
>>
>> https://github.com/ggardet/blog/blob/master/HowTo-Add_tests_on_real_hardware_with_openQA-RPi3_case.md
>>
>> It uses an external board with USB OTG to boot the RPi from USB (Firmware
>> is still on uSD due to:
>> https://github.com/raspberrypi/firmware/issues/1322).
>> You could also use some USB SD mux such as:
>> https://shop.linux-automation.com/usb_sd_mux-D02-R01-V02-C00-en
>> But it does not work well with RPi4 atm, whereas it works perfectly fine
>> with the HiKey960.
>>
>> Also, if you want to make it available to openqa.o.o:
>>
>> https://github.com/ggardet/blog/blob/master/HowTo-Install_a_remote_openQA_worker.md
>>
>> May I ask for which board you would like to test?
>>
>> Cheers,
>> Guillaume
>>
>>
>>
>> - Matwey V. Kornilov  a écrit :
>> > Hello,
>> >
>> > I am looking through openQA sources and I am very excited about
>> > generalhw backend. I see that it is currently in use at
>> > openqa.opensuse.org to test Raspberry Pi images. Unfortunately, there
>> is
>> > a little details in the sources, I only see that the backend calls some
>> > preconfigured external commands to manipulate hardware, but I've failed
>> > to find more implementation details.
>> >
>> > Is there a kind of presentation or documentation on how all this works?
>> > I am especially interested in how the flash card image is deployed?
>> >
>> >
>> >
>> >
>> > --
>> > With best regards,
>> > Matwey V. Kornilov
>>
>>
>
> --
> With best regards,
> Matwey V. Kornilov
>


-- 
With best regards,
Matwey V. Kornilov

[opensuse-arm] Re: Very slow zypper dup on Banana Pi M64

[Matwey V. Kornilov]

06.09.2020 13:05, Freek de Kruijf пишет:
> Hi all,
> 
> I have a Banana Pi M64 on which I installed:
> openSUSE-Tumbleweed-ARM-JeOS-pine64.aarch64-2020.07.28-Build8.3.raw.xz
> When performing a "zypper dup" downloading the upgraded packages is as 
> expected, BUT installing the packages is very slow.
> 
> I also have a Raspberry Pi 4B+ which uses the same repository on which 
> upgrading is as to be expected.
> 
> The Banana Pi M64 has 2 GB memory, which is quite enough.
> 
> The only striking difference, to me, is that the image for the Banana Pi uses 
> btrfs, whereas the image for the Raspberry Pi uses ext4 as the file system 
> for 
> the ROOT partition.
> 
> Any ideas?
> 

I would suggest to test I/O performance separately. Maybe something is
wrong with particular SD card, or SD host controller support in kernel
is partially broken (DMA disabled).
-- 
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: Re : [opensuse-arm] openQA generalhw backend

[Matwey V. Kornilov]

Thanks, Guillaume!

Do I understand correctly, that SUT-companion and OpenQA worker may be on
the same host?

I would like to test BeagleBone Black. In an ideal world, I would like it
to be tested on openqa.opensuse.org.
Now I see that I have to learn how to boot the board from USB. The AM335x
reference documentation says that it is possible to load U-Boot firmware
via UART and USB, but I have never tried it.


вс, 23 авг. 2020 г. в 10:25, Guillaume GARDET :

>
> Hi Matwey,
>
> Here are some details about the RPi3 case:
>
> https://github.com/ggardet/blog/blob/master/HowTo-Add_tests_on_real_hardware_with_openQA-RPi3_case.md
>
> It uses an external board with USB OTG to boot the RPi from USB (Firmware
> is still on uSD due to:
> https://github.com/raspberrypi/firmware/issues/1322).
> You could also use some USB SD mux such as:
> https://shop.linux-automation.com/usb_sd_mux-D02-R01-V02-C00-en
> But it does not work well with RPi4 atm, whereas it works perfectly fine
> with the HiKey960.
>
> Also, if you want to make it available to openqa.o.o:
>
> https://github.com/ggardet/blog/blob/master/HowTo-Install_a_remote_openQA_worker.md
>
> May I ask for which board you would like to test?
>
> Cheers,
> Guillaume
>
>
>
> - Matwey V. Kornilov  a écrit :
> > Hello,
> >
> > I am looking through openQA sources and I am very excited about
> > generalhw backend. I see that it is currently in use at
> > openqa.opensuse.org to test Raspberry Pi images. Unfortunately, there is
> > a little details in the sources, I only see that the backend calls some
> > preconfigured external commands to manipulate hardware, but I've failed
> > to find more implementation details.
> >
> > Is there a kind of presentation or documentation on how all this works?
> > I am especially interested in how the flash card image is deployed?
> >
> >
> >
> >
> > --
> > With best regards,
> > Matwey V. Kornilov
>
>

-- 
With best regards,
Matwey V. Kornilov

[opensuse-arm] openQA generalhw backend

[Matwey V. Kornilov]

Hello,

I am looking through openQA sources and I am very excited about
generalhw backend. I see that it is currently in use at
openqa.opensuse.org to test Raspberry Pi images. Unfortunately, there is
a little details in the sources, I only see that the backend calls some
preconfigured external commands to manipulate hardware, but I've failed
to find more implementation details.

Is there a kind of presentation or documentation on how all this works?
I am especially interested in how the flash card image is deployed?




-- 
With best regards,
Matwey V. Kornilov

Re: [opensuse-arm] ARM JeOS for software.opensuse.org

[Matwey V. Kornilov]

пн, 9 мар. 2020 г. в 11:55, Guillaume Gardet :
>
> Hi,
>
>
> > -Original Message-
> > From: Matwey V. Kornilov 
> > Sent: 04 March 2020 18:05
> > To: Matthias Brugger 
> > Cc: opensuse-arm@opensuse.org
> > Subject: Re: [opensuse-arm] ARM JeOS for software.opensuse.org
> >
> > ср, 4 мар. 2020 г. в 19:23, Matthias Brugger :
> > >
> > >
> > >
> > > On 04/03/2020 16:56, Matwey V. Kornilov wrote:
> > > > ср, 4 мар. 2020 г. в 18:52, Matthias Brugger :
> > > >>
> > > >>
> > > >>
> > > >> On 03/03/2020 17:54, Matwey V. Kornilov wrote:
> > > >>> вт, 3 мар. 2020 г. в 19:39, Matthias Brugger :
> > > >>>>
> > > >>>> Hi Matwey,
> > > >>>>
> > > >>>> On 03/03/2020 17:23, Matwey V. Kornilov wrote:
> > > >>>>> Hello,
> > > >>>>>
> > > >>>>> I think it would be great to have something like that
> > > >>>>> https://ubuntu.com/download/raspberry-pi on
> > > >>>>> https://software.opensuse.org/distributions/tumbleweed page. For
> > > >>>>> few boards with good support.
> > > >>>>> Currently, information about RPi support is hidden in the internals 
> > > >>>>> of
> > Wiki.
> > > >>>>>
> > > >>>>> I asked this once in the past, but this idea had no support at
> > > >>>>> that moment. What do you think now?
> > > >>>>>
> > > >>>>
> > > >>>> I think this is a good idea. We should make more noise about the 
> > > >>>> things
> > we do.
> > > >>>> Support for board is too much hidden. We should carefully select
> > > >>>> a few boards (e.g. Leap supported) to announce them more broadly.
> > > >>>>
> > > >>>> Regards,
> > > >>>> Matthias
> > > >>>
> > > >>> From my side, I would say that BeagleBone Black has a good support
> > > >>> level. Almost all hardware are working, except PRUs, and
> > > >>> isochronous USB transfer for MUSB host controller is sometimes buggy.
> > > >>> I am trying to fix the latter in upstream Linux kernel, but no big
> > > >>> success yet. MUSB maintainers just silently ignore my patches for
> > > >>> some reason...
> > > >>>
> > > >>
> > > >> That's not leap supported, right? That's not mandatory. We can also
> > > >> decide to publish some boards people are actually using and happy
> > > >> to test + debug. What we should try to avoid, is to promote boards
> > > >> that then later doesn't get enough love and get stale.
> > > >
> > > > It is currently supported in Leap:
> > > > https://download.opensuse.org/ports/armv7hl/distribution/leap/15.1/a
> > > > ppliances/openSUSE-Leap-15.1-ARM-JeOS-beaglebone.armv7l.raw.xz
> > > >
> > >
> > > My bad, I wasn't aware we still have openSUSE Leap on armv7.
> > >
> > > > I am running Leap 15.0/15.1 on BeagleBones in prod.
> > > > But you are right here, I have never tested graphical interface
> > > > images for this board.
> > > >
> > >
> > > Would be a good time to test 15.2 then :)
> >
> > It boots and still says that it is alpha...
> > PRETTY_NAME="openSUSE Leap 15.2 Alpha"
>
> It should not. The problem atm is Leap 15.2 ARM images are in 2 places:
> * 
> http://download.opensuse.org/ports/aarch64/distribution/leap/15.2/appliances/ 
> which is outdated
> * http://download.opensuse.org/ports/aarch64/distribution/leap/15.2/live/ 
> with latest release.

You are right. The latter is PRETTY_NAME="openSUSE Leap 15.2 Beta"

>
> Adrian is aware.
>
> Cheers,
> Guillaume
>
>
> >
> >
> > --
> > 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
>
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.



-- 
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] ARM JeOS for software.opensuse.org

[Matwey V. Kornilov]

ср, 4 мар. 2020 г. в 19:23, Matthias Brugger :
>
>
>
> On 04/03/2020 16:56, Matwey V. Kornilov wrote:
> > ср, 4 мар. 2020 г. в 18:52, Matthias Brugger :
> >>
> >>
> >>
> >> On 03/03/2020 17:54, Matwey V. Kornilov wrote:
> >>> вт, 3 мар. 2020 г. в 19:39, Matthias Brugger :
> >>>>
> >>>> Hi Matwey,
> >>>>
> >>>> On 03/03/2020 17:23, Matwey V. Kornilov wrote:
> >>>>> Hello,
> >>>>>
> >>>>> I think it would be great to have something like that
> >>>>> https://ubuntu.com/download/raspberry-pi on
> >>>>> https://software.opensuse.org/distributions/tumbleweed page. For few
> >>>>> boards with good support.
> >>>>> Currently, information about RPi support is hidden in the internals of 
> >>>>> Wiki.
> >>>>>
> >>>>> I asked this once in the past, but this idea had no support at that
> >>>>> moment. What do you think now?
> >>>>>
> >>>>
> >>>> I think this is a good idea. We should make more noise about the things 
> >>>> we do.
> >>>> Support for board is too much hidden. We should carefully select a few 
> >>>> boards
> >>>> (e.g. Leap supported) to announce them more broadly.
> >>>>
> >>>> Regards,
> >>>> Matthias
> >>>
> >>> From my side, I would say that BeagleBone Black has a good support
> >>> level. Almost all hardware are working, except PRUs, and isochronous
> >>> USB transfer for MUSB host controller is sometimes buggy.
> >>> I am trying to fix the latter in upstream Linux kernel, but no big
> >>> success yet. MUSB maintainers just silently ignore my patches for some
> >>> reason...
> >>>
> >>
> >> That's not leap supported, right? That's not mandatory. We can also decide 
> >> to
> >> publish some boards people are actually using and happy to test + debug. 
> >> What we
> >> should try to avoid, is to promote boards that then later doesn't get 
> >> enough
> >> love and get stale.
> >
> > It is currently supported in Leap:
> > https://download.opensuse.org/ports/armv7hl/distribution/leap/15.1/appliances/openSUSE-Leap-15.1-ARM-JeOS-beaglebone.armv7l.raw.xz
> >
>
> My bad, I wasn't aware we still have openSUSE Leap on armv7.
>
> > I am running Leap 15.0/15.1 on BeagleBones in prod.
> > But you are right here, I have never tested graphical interface images
> > for this board.
> >
>
> Would be a good time to test 15.2 then :)

It boots and still says that it is alpha...
PRETTY_NAME="openSUSE Leap 15.2 Alpha"


-- 
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] ARM JeOS for software.opensuse.org

[Matwey V. Kornilov]

ср, 4 мар. 2020 г. в 18:52, Matthias Brugger :
>
>
>
> On 03/03/2020 17:54, Matwey V. Kornilov wrote:
> > вт, 3 мар. 2020 г. в 19:39, Matthias Brugger :
> >>
> >> Hi Matwey,
> >>
> >> On 03/03/2020 17:23, Matwey V. Kornilov wrote:
> >>> Hello,
> >>>
> >>> I think it would be great to have something like that
> >>> https://ubuntu.com/download/raspberry-pi on
> >>> https://software.opensuse.org/distributions/tumbleweed page. For few
> >>> boards with good support.
> >>> Currently, information about RPi support is hidden in the internals of 
> >>> Wiki.
> >>>
> >>> I asked this once in the past, but this idea had no support at that
> >>> moment. What do you think now?
> >>>
> >>
> >> I think this is a good idea. We should make more noise about the things we 
> >> do.
> >> Support for board is too much hidden. We should carefully select a few 
> >> boards
> >> (e.g. Leap supported) to announce them more broadly.
> >>
> >> Regards,
> >> Matthias
> >
> > From my side, I would say that BeagleBone Black has a good support
> > level. Almost all hardware are working, except PRUs, and isochronous
> > USB transfer for MUSB host controller is sometimes buggy.
> > I am trying to fix the latter in upstream Linux kernel, but no big
> > success yet. MUSB maintainers just silently ignore my patches for some
> > reason...
> >
>
> That's not leap supported, right? That's not mandatory. We can also decide to
> publish some boards people are actually using and happy to test + debug. What 
> we
> should try to avoid, is to promote boards that then later doesn't get enough
> love and get stale.

It is currently supported in Leap:
https://download.opensuse.org/ports/armv7hl/distribution/leap/15.1/appliances/openSUSE-Leap-15.1-ARM-JeOS-beaglebone.armv7l.raw.xz

I am running Leap 15.0/15.1 on BeagleBones in prod.
But you are right here, I have never tested graphical interface images
for this board.

>
> Regards,
> 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] ARM JeOS for software.opensuse.org

[Matwey V. Kornilov]

вт, 3 мар. 2020 г. в 19:39, Matthias Brugger :
>
> Hi Matwey,
>
> On 03/03/2020 17:23, Matwey V. Kornilov wrote:
> > Hello,
> >
> > I think it would be great to have something like that
> > https://ubuntu.com/download/raspberry-pi on
> > https://software.opensuse.org/distributions/tumbleweed page. For few
> > boards with good support.
> > Currently, information about RPi support is hidden in the internals of Wiki.
> >
> > I asked this once in the past, but this idea had no support at that
> > moment. What do you think now?
> >
>
> I think this is a good idea. We should make more noise about the things we do.
> Support for board is too much hidden. We should carefully select a few boards
> (e.g. Leap supported) to announce them more broadly.
>
> Regards,
> Matthias

>From my side, I would say that BeagleBone Black has a good support
level. Almost all hardware are working, except PRUs, and isochronous
USB transfer for MUSB host controller is sometimes buggy.
I am trying to fix the latter in upstream Linux kernel, but no big
success yet. MUSB maintainers just silently ignore my patches for some
reason...

-- 
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

[opensuse-arm] ARM JeOS for software.opensuse.org

[Matwey V. Kornilov]

Hello,

I think it would be great to have something like that
https://ubuntu.com/download/raspberry-pi on
https://software.opensuse.org/distributions/tumbleweed page. For few
boards with good support.
Currently, information about RPi support is hidden in the internals of Wiki.

I asked this once in the past, but this idea had no support at that
moment. What do you think now?

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

[opensuse-arm] Re: New 32-bit Arm support needed for future OBS builds

[Matwey V. Kornilov]

19.02.2020 12:26, Matthias Brugger пишет:
> 
> 
> On 05/02/2020 17:22, Guillaume Gardet wrote:
>>
>>
>>> -Original Message-
>>> From: Torsten Duwe 
>>> Sent: 05 February 2020 16:41
>>> To: Guillaume Gardet 
>>> Cc: Josua Mayer ; 
>>> opensuse-arm-staj6esoqrxg9huczpv...@public.gmane.org
>>> Subject: Re: [opensuse-arm] Re: New 32-bit Arm support needed for future OBS
>>> builds
>>>
>>> On Wed, Feb 05, 2020 at 03:15:28PM +, Guillaume Gardet wrote:

 No, that is the problem. With newer hardware, this option will be gone as 
 32-bit
>>> mode will not be supported in kernel mode, so qemu/kvm cannot run armv7
>>> kernel.
>>>
>>> Are you sure about this? I mean, those cores will not be able to run 32-bit 
>>> kernels
>>> natively, sure, but my (maybe outdated) information is that kvm always runs
>>> guest code in "user mode" and faults on privileged instructions, which are 
>>> then
>>> emulated anyway.
>>
>> That's what I have been told. I will double check.
>>
> 
> Were you abe to double check? I belive we can run 32-bit VMs on 64-bit 
> machines.
> The thing is that KVM for arm32 will be dropped in the future. I know we are

Why it will be dropped?

> using some arm32 HW to build packages, so we should look for an alternative.
> 
> Regards,
> Matthias
> 


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

[opensuse-arm] Re: Rock64

[Matwey V. Kornilov]

13.02.2020 06:49, ITwrx пишет:
> On 2/12/20 12:07 PM, Matwey V. Kornilov wrote:
>> 12.02.2020 20:58, ITwrx пишет:
>>> On 2/12/20 11:56 AM, Matwey V. Kornilov wrote:
>>>> 12.02.2020 18:37, ITwrx пишет:
>>>>> 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" (substituti

[opensuse-arm] Re: Rock64

[Matwey V. Kornilov]

12.02.2020 20:58, ITwrx пишет:
> On 2/12/20 11:56 AM, Matwey V. Kornilov wrote:
>> 12.02.2020 18:37, ITwrx пишет:
>>> 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. :)
>> It is very first stage of bootloader. Do you see anything else next?
> no. That's where it stops, unfortunately. I guess i could try the ALARM
> install process and see if it stops at the same point, in which case
&

[opensuse-arm] Re: Rock64

[Matwey V. Kornilov]

12.02.2020 18:37, ITwrx пишет:
> 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. :)

It is very first stage of bootloader. Do you see anything else next?

> 
> 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

[Matwey V. Kornilov]

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] armv7l platform is missed for docker registry.opensuse.org/opensuse/tumbleweed:latest

[Matwey V. Kornilov]

чт, 6 февр. 2020 г. в 11:32, Matwey V. Kornilov :
>
> чт, 6 февр. 2020 г. в 11:27, Adrian Schröter :
> >
> > On Donnerstag, 6. Februar 2020, 09:17:49 CET Matwey V. Kornilov wrote:
> > > чт, 6 февр. 2020 г. в 11:15, Adrian Schröter :
> > > >
> > > > On Donnerstag, 6. Februar 2020, 09:13:24 CET Matwey V. Kornilov wrote:
> > > > > чт, 6 февр. 2020 г. в 11:12, Adrian Schröter :
> > > > > >
> > > > > > On Mittwoch, 5. Februar 2020, 18:07:56 CET Matwey V. Kornilov wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > > Here (https://registry.opensuse.org/cgi-bin/cooverview ) I see 
> > > > > > > that
> > > > > > > opensuse/tubmleweed multiplatform docker image supports the 
> > > > > > > following
> > > > > > > platforms:
> > > > > > >
> > > > > > > aarch64
> > > > > > > armv6l
> > > > > > > i586
> > > > > > > ppc64le
> > > > > > > x86_64
> > > > > > >
> > > > > > > However, armv7l is missed for some reason. How could we get it 
> > > > > > > back?
> > > > > >
> > > > > > The docker registry only knows "arm" and "arm64". So armv6l is 
> > > > > > overwriting armv7hl :/
> > > > > >
> > > > > > Guillaume and me decided to unpublish armv6l for now until we found 
> > > > > > a solution.
> > > > > >
> > > > > > Renaming the image is bad for references, so I guess we need to 
> > > > > > publish armv6l in a
> > > > > > different repository.
> > > > > >
> > > > > > Fabian, do you have an opinion here?
> > > > >
> > > > > I remember, that once I saw that correct docker platform names are
> > > > > linux/arm/v6 and linux/arm/v7
> > > >
> > > > you mean having it in a different repository? yes, that was my
> > > > proposal as well.
> > >
> > > No, I mean docker platform names. Look here:
> > >
> > > https://www.docker.com/blog/getting-started-with-docker-for-arm-on-linux/
> > >
> > > Docker people use "Platform: linux/arm64" for aarch64 and "Platform:
> > > linux/arm/v7" for armv7.
> >
> > Hm, can you find a real life example in any registry?
> >
>
> > docker run mplatform/mquery postgres
> Image: postgres
>  * Manifest List: Yes
>  * Supported platforms:
>- linux/amd64
>- linux/arm/v5
>- linux/arm/v7
>- linux/arm64
>- linux/386
>- linux/ppc64le
>- linux/s390x
>
> > docker run mplatform/mquery ubuntu
> Image: ubuntu
>  * Manifest List: Yes
>  * Supported platforms:
>- linux/amd64
>- linux/arm/v7
>- linux/arm64
>- linux/386
>- linux/ppc64le
>- linux/s390x
>

I am sorry. You are right here. It seems that "v7" after "arm" is a
"variant" not "architecture":

 "platform": {
    "architecture": "arm",
"os": "linux",
"variant": "v7"
 }

However, as a user, I anyway have to use the full platform specification string:

docker run --platform=linux/arm/v7

> > I like to look at the manifest, because I have no clue atm how this 
> > platform string
> > is stored there. It should look like
> >
> >  "platform" : {
> > "architecture" : "amd64",
> > "os" : "linux"
> >  }
> >
> > but architecture is limited to "Go" architectures which only knows "arm"...
> >
> > They may (mis)use the version string for this?
> >
> > Maybe an option...
> >
> > --
> >
> > Adrian Schroeter 
> > Build Infrastructure Project Manager
> >
> > SUSE Software Solutions Germany GmbH,  Maxfeldstr. 5, 90409 Nuernberg, 
> > Germany
> > (HRB 247165, AG München), Geschäftsführer: Felix Imendörffer
> >
> >
> >
> >
>
>
> --
> 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] armv7l platform is missed for docker registry.opensuse.org/opensuse/tumbleweed:latest

[Matwey V. Kornilov]

чт, 6 февр. 2020 г. в 11:15, Adrian Schröter :
>
> On Donnerstag, 6. Februar 2020, 09:13:24 CET Matwey V. Kornilov wrote:
> > чт, 6 февр. 2020 г. в 11:12, Adrian Schröter :
> > >
> > > On Mittwoch, 5. Februar 2020, 18:07:56 CET Matwey V. Kornilov wrote:
> > > > Hello,
> > > >
> > > > Here (https://registry.opensuse.org/cgi-bin/cooverview ) I see that
> > > > opensuse/tubmleweed multiplatform docker image supports the following
> > > > platforms:
> > > >
> > > > aarch64
> > > > armv6l
> > > > i586
> > > > ppc64le
> > > > x86_64
> > > >
> > > > However, armv7l is missed for some reason. How could we get it back?
> > >
> > > The docker registry only knows "arm" and "arm64". So armv6l is 
> > > overwriting armv7hl :/
> > >
> > > Guillaume and me decided to unpublish armv6l for now until we found a 
> > > solution.
> > >
> > > Renaming the image is bad for references, so I guess we need to publish 
> > > armv6l in a
> > > different repository.
> > >
> > > Fabian, do you have an opinion here?
> >
> > I remember, that once I saw that correct docker platform names are
> > linux/arm/v6 and linux/arm/v7
>
> you mean having it in a different repository? yes, that was my
> proposal as well.

No, I mean docker platform names. Look here:

https://www.docker.com/blog/getting-started-with-docker-for-arm-on-linux/

Docker people use "Platform: linux/arm64" for aarch64 and "Platform:
linux/arm/v7" for armv7.



>
> The architecture names can not contain these strings 
>
> --
>
> Adrian Schroeter 
> Build Infrastructure Project Manager
>
> SUSE Software Solutions Germany GmbH,  Maxfeldstr. 5, 90409 Nuernberg, Germany
> (HRB 247165, AG München), Geschäftsführer: Felix Imendörffer
>
>
>
>


-- 
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] armv7l platform is missed for docker registry.opensuse.org/opensuse/tumbleweed:latest

[Matwey V. Kornilov]

чт, 6 февр. 2020 г. в 11:12, Adrian Schröter :
>
> On Mittwoch, 5. Februar 2020, 18:07:56 CET Matwey V. Kornilov wrote:
> > Hello,
> >
> > Here (https://registry.opensuse.org/cgi-bin/cooverview ) I see that
> > opensuse/tubmleweed multiplatform docker image supports the following
> > platforms:
> >
> > aarch64
> > armv6l
> > i586
> > ppc64le
> > x86_64
> >
> > However, armv7l is missed for some reason. How could we get it back?
>
> The docker registry only knows "arm" and "arm64". So armv6l is overwriting 
> armv7hl :/
>
> Guillaume and me decided to unpublish armv6l for now until we found a 
> solution.
>
> Renaming the image is bad for references, so I guess we need to publish 
> armv6l in a
> different repository.
>
> Fabian, do you have an opinion here?

I remember, that once I saw that correct docker platform names are
linux/arm/v6 and linux/arm/v7

>
> bye
> adrian
>
> --
>
> Adrian Schroeter 
> Build Infrastructure Project Manager
>
> SUSE Software Solutions Germany GmbH,  Maxfeldstr. 5, 90409 Nuernberg, Germany
> (HRB 247165, AG München), Geschäftsführer: Felix Imendörffer
>
>
>
>


-- 
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

[opensuse-arm] armv7l platform is missed for docker registry.opensuse.org/opensuse/tumbleweed:latest

[Matwey V. Kornilov]

Hello,

Here (https://registry.opensuse.org/cgi-bin/cooverview ) I see that
opensuse/tubmleweed multiplatform docker image supports the following
platforms:

aarch64
armv6l
i586
ppc64le
x86_64

However, armv7l is missed for some reason. How could we get it back?

-- 
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

[opensuse-arm] Re: LEAP 15.1 repos outdated?

[Matwey V. Kornilov]

02.02.2020 10:46, Bernd Nachtigall пишет:
> Hi,
> 
> I play around with a RasPi and run LEAP15.1 since weeks. All things fine :-)
> 
> When I check for updates I get 'Main Update Repository' outdated. URL
> is:
> http://download.opensuse.org/ports/aarch64/distribution/leap/15.1/repo/oss/
> 
> There are repos for 15.2, but it seems that 15.2 is not released yet.
> 
> Any hints?

For some reason, updates for arm platform are not published.

> 
> Bernd
> 


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

Re: [opensuse-arm] arm-trusted-firmware and Factory

[Matwey V. Kornilov]

вт, 12 нояб. 2019 г. в 19:01, Andreas Färber :
>
> Hi Matwey,
>
> Am Freitag, den 08.11.2019, 20:10 +0300 schrieb Matwey V. Kornilov:
> > I've just found that arm-trusted-firmware is missed in Factory. I
> > wonder
> > what is the reason?
>
> In short, build dependencies.
>
> > I am asking because arm-trusted-firmware is required to build rk3328
> > u-boot.itb which is a single supported upstream way to run u-boot.
> > u-boot.itb is currently the last piece of the large puzzle to have
> > JeOS-rock64 fully bootable with the upstream u-boot and kernel out of
> > the box.
>
> Please look at how we handle this in Contrib:Pine64 project, where U-
> Boot is rebuilt with TF-A dependency.
>
> An actual Factory solution will be more time-consuming.

So what should be steps to have arm-trusted-firmware in Factory?

>
> Regards,
> Andreas
>
> --
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer
> HRB 36809 (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

[opensuse-arm] Re: cloud-init for JeOS

[Matwey V. Kornilov]

26.01.2020 14:27, Thorsten Kukuk пишет:
> On Sun, Jan 26, Matwey V. Kornilov wrote:
> 
>> Hi,
>>
>> What do you think about adding cloud-init for ARM JeOS images?
> 
> If it is not public cloud: nothing.
> We tried that in the past, the side effects of cloud-init, if it runs
> but you do not provide a config for every listed module, are really bad.
> For MicroOS we are using ignition for that reason now.

I have never heard about ignition before. But it seems to have the
similar purpose as cloud-init.

> 
>   Thorsten
>  
>> Currently, configuration way after deploying brand-new JeOS image is
>> always similar to the following:
>> login with root:linux requisites by serial console and do `ip addr`
>> (or directyl ssh if it is possible to guess DHCP address),
>> then create users, deploy ssh keys, disable ssh root login, etc.
>>
>> I think cloud-init could be helpful here to configure users and
>> networking. Initial configuration can be deployed to the board by
>> network using kernel command line options.
>>
>>
>> -- 
>> 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
> 


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

[opensuse-arm] cloud-init for JeOS

[Matwey V. Kornilov]

Hi,

What do you think about adding cloud-init for ARM JeOS images?

Currently, configuration way after deploying brand-new JeOS image is
always similar to the following:
login with root:linux requisites by serial console and do `ip addr`
(or directyl ssh if it is possible to guess DHCP address),
then create users, deploy ssh keys, disable ssh root login, etc.

I think cloud-init could be helpful here to configure users and
networking. Initial configuration can be deployed to the board by
network using kernel command line options.


-- 
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] arm-trusted-firmware and Factory

[Matwey V. Kornilov]

вт, 12 нояб. 2019 г. в 19:01, Andreas Färber :
>
> Hi Matwey,
>
> Am Freitag, den 08.11.2019, 20:10 +0300 schrieb Matwey V. Kornilov:
> > I've just found that arm-trusted-firmware is missed in Factory. I
> > wonder
> > what is the reason?
>
> In short, build dependencies.
>
> > I am asking because arm-trusted-firmware is required to build rk3328
> > u-boot.itb which is a single supported upstream way to run u-boot.
> > u-boot.itb is currently the last piece of the large puzzle to have
> > JeOS-rock64 fully bootable with the upstream u-boot and kernel out of
> > the box.
>
> Please look at how we handle this in Contrib:Pine64 project, where U-
> Boot is rebuilt with TF-A dependency.

Thank you.

u-boot is broken in Contrib:Pine64 currently.

>
> An actual Factory solution will be more time-consuming.
>
> Regards,
> Andreas
>
> --
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer
> HRB 36809 (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

[opensuse-arm] arm-trusted-firmware and Factory

[Matwey V. Kornilov]

Hello,

I've just found that arm-trusted-firmware is missed in Factory. I wonder
what is the reason?

I am asking because arm-trusted-firmware is required to build rk3328
u-boot.itb which is a single supported upstream way to run u-boot.
u-boot.itb is currently the last piece of the large puzzle to have
JeOS-rock64 fully bootable with the upstream u-boot and kernel out of
the box.

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

[opensuse-arm] Re: tumbleweed on RPi Zero W

[Matwey V. Kornilov]

07.11.2019 15:48, Guillaume Gardet пишет:
> 
> 
>> -Original Message-----
>> From: Matwey V. Kornilov 
>> Sent: 07 November 2019 13:46
>> To: opensuse-arm@opensuse.org
>> Subject: [opensuse-arm] Re: tumbleweed on RPi Zero W
>>
>>
>> As far as I remember there is a ticket in the bugzilla according generic
>> armv6 faluire.
> 
> If you are referencing https://bugzilla.opensuse.org/show_bug.cgi?id=1145646 
> this is not the problem here since we still use grub 2.02.
> Or is there another bug?

Ah, sorry. You are right.

> 
> Guillaume
> 
> 
>>
>> 07.11.2019 13:20, Guillaume Gardet пишет:
>>> Hi Matthias,
>>>
>>>> -Original Message-
>>>> From: Matthias Brugger 
>>>> Sent: 07 November 2019 10:33
>>>> To: Mailinglist openSUSE ARM 
>>>> Cc: ralph.ga...@bwc-illmensee.de; Michael Ströder
>>>> ; Freek de Kruijf 
>>>> Subject: [opensuse-arm] tumbleweed on RPi Zero W
>>>>
>>>> Hi all,
>>>>
>>>> Yesterday I tried openSUSE Tumbleweed image on my RPi Zero W (v1.1)
>>>> with JeOS image. I was able to boot into grub but didn't see any
>>>> output from the kernel on the serial console. I saw that console was
>>>> set to ttyAMA0, I tried also with
>>>> ttyS0 and ttyS1, as well as with earlycon as described in [1]. But no luck.
>>>>
>>>> Was anyone able to boot the newest [2] RPi tumbleweed image just
>>>> using the serial console, or do I need a monitor on the firstboot?
>>>
>>> No, you should be able to boot it with serial only.
>>>
>>> I tried this image on a RPi1, with serial and HDMI connected and I have 
>>> nothing
>> after grub loaded kernel and initrd.
>>>
>>> Cheers,
>>> Guillaume
>>>
>>>
>>>>
>>>> Regards,
>>>> Matthias
>>>>
>>>> [1] https://en.opensuse.org/HCL:Raspberry_Pi
>>>> [2]
>>>> openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-2019.10.25-
>>>> Snapshot20191101.raw.xz
>>>> --
>>>> To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
>>>> To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
>>>
>>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended 
>> recipient,
>> please notify the sender immediately and do not disclose the contents to any
>> other person, use it for any purpose, or store or copy the information in any
>> medium. Thank you.
>>>
>>
>>
>> --
>> To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
>> To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
> 


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

[opensuse-arm] Re: tumbleweed on RPi Zero W

[Matwey V. Kornilov]

As far as I remember there is a ticket in the bugzilla according generic
armv6 faluire.

07.11.2019 13:20, Guillaume Gardet пишет:
> Hi Matthias,
> 
>> -Original Message-
>> From: Matthias Brugger 
>> Sent: 07 November 2019 10:33
>> To: Mailinglist openSUSE ARM 
>> Cc: ralph.ga...@bwc-illmensee.de; Michael Ströder ;
>> Freek de Kruijf 
>> Subject: [opensuse-arm] tumbleweed on RPi Zero W
>>
>> Hi all,
>>
>> Yesterday I tried openSUSE Tumbleweed image on my RPi Zero W (v1.1) with
>> JeOS image. I was able to boot into grub but didn't see any output from the
>> kernel on the serial console. I saw that console was set to ttyAMA0, I tried 
>> also
>> with
>> ttyS0 and ttyS1, as well as with earlycon as described in [1]. But no luck.
>>
>> Was anyone able to boot the newest [2] RPi tumbleweed image just using the
>> serial console, or do I need a monitor on the firstboot?
> 
> No, you should be able to boot it with serial only.
> 
> I tried this image on a RPi1, with serial and HDMI connected and I have 
> nothing after grub loaded kernel and initrd.
> 
> Cheers,
> Guillaume
> 
> 
>>
>> Regards,
>> Matthias
>>
>> [1] https://en.opensuse.org/HCL:Raspberry_Pi
>> [2]
>> openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-2019.10.25-
>> Snapshot20191101.raw.xz
>> --
>> To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
>> To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
> 


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

[opensuse-arm] Re: u-boot 2019.10 to openSUSE:Factory

[Matwey V. Kornilov]

30.10.2019 20:17, Matwey V. Kornilov пишет:
> 
> Could you please also accept my SR for Rock64 board?

Thanks. :-)

> 
> 30.10.2019 18:10, Guillaume Gardet пишет:
>> Hi,
>>
>> It is in latest Tumbleweed snapshot.
>>
>> Guillaume
>>
>>
>> Le 18/10/2019 à 17:06, Manu Maier a écrit :
>>> Hello,
>>>
>>> can anyone push u-boot 2019.10 from hardware:boot to openSUSE:Factory? 
>>> Please
>>>
>>> Thanks
>>>
>>> Regards,
>>> Manu
>>>
>>> N�r��y隊Z)z{.�櫛맲��r��z�^�ˬz��N�(�֜��^�   ޭ隊Z)z{.�櫛�0�Ǩrg==
> 
> 


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

[opensuse-arm] Re: u-boot 2019.10 to openSUSE:Factory

[Matwey V. Kornilov]

Could you please also accept my SR for Rock64 board?

30.10.2019 18:10, Guillaume Gardet пишет:
> Hi,
> 
> It is in latest Tumbleweed snapshot.
> 
> Guillaume
> 
> 
> Le 18/10/2019 à 17:06, Manu Maier a écrit :
>> Hello,
>>
>> can anyone push u-boot 2019.10 from hardware:boot to openSUSE:Factory? 
>> Please
>>
>> Thanks
>>
>> Regards,
>> Manu
>>
>> N�r��y隊Z)z{.�櫛맲��r��z�^�ˬz��N�(�֜��^�ޭ隊Z)z{.�櫛�0�Ǩrg==


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

Re: [opensuse-arm] openSUSE:Factory:ARM aarch64 publishing

[Matwey V. Kornilov]

вт, 3 сент. 2019 г. в 22:03, Guillaume Gardet :
>
> Hi,
>
> > -Original Message-
> > From: Matwey V. Kornilov 
> > Sent: 03 September 2019 19:17
> > To: opensuse-arm@opensuse.org
> > Subject: [opensuse-arm] openSUSE:Factory:ARM aarch64 publishing
> >
> > Hello,
> >
> > Tumbleweed for aarch64 has not been updated since 20190814. I do `zypper
> > dup` and there are no new packages since then.
>
> Indeed, no new snapshot have been released since this date, but snapshot 
> 20190830 is being published right now.
>
> You can see this page to check the status of each snapshot in openQA: 
> https://openqa.opensuse.org/group_overview/3
>

Thank you.

> Do you have special requirements for a newer snapshot?

I just have been waiting for fixed iscsi and syslog-ng.

>
> Cheers,
> Guillaume
>
>
> >
> > --
> > 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
>
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.



-- 
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

[opensuse-arm] openSUSE:Factory:ARM aarch64 publishing

[Matwey V. Kornilov]

Hello,

Tumbleweed for aarch64 has not been updated since 20190814. I do
`zypper dup` and there are no new packages since then.

-- 
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

[opensuse-arm] TianoCore on EspressoBin

[Matwey V. Kornilov]

Hi,

I've just started TianoCore on EspressoBin from this repo:
https://github.com/MarvellEmbeddedProcessors/uefi-marvell/tree/uefi-2.7-armada-18.12

It works, but it lacks almost all hardware drivers except serial console
one. So, I cannot run something useful.

Shell> drivers
T   D
D   Y C I
R   P F A
V  VERSION  E G G #D #C DRIVER NAME IMAGE NAME
==  = = = == == === ==
2D 000A D - -  1  - Platform Console Management Driver  ConPlatformDxe
2E 000A D - -  1  - Platform Console Management Driver  ConPlatformDxe
2F 000A B - -  1  1 Console Splitter Driver ConSplitterDxe
30 000A ? - -  -  - Console Splitter Driver ConSplitterDxe
31 000A ? - -  -  - Console Splitter Driver ConSplitterDxe
32 000A B - -  1  1 Console Splitter Driver ConSplitterDxe
33 000A B - -  1  1 Console Splitter Driver ConSplitterDxe
37 000A ? - -  -  - Graphics Console Driver
GraphicsConsoleDxe
38 000A B - -  1  1 Serial Terminal Driver  TerminalDxe
39 000A D - -  1  - Generic Disk I/O Driver DiskIoDxe
3A 000B ? - -  -  - Partition Driver(MBR/GPT/El Torito) PartitionDxe
3B 000A D - -  1  - FAT File System Driver  Fat

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

[opensuse-arm] Re: Kernel debugging

[Matwey V. Kornilov]

06.12.2018 22:27, Frank Kunz пишет:
> Hello,
> 
> I want to debug a kernel problem on a armv7 board. For that I want to
> temporary enable the CONFIG_PROVE_LOCKING config. My idea was to branch
> the used kernel (lpae) build in obs, add the config to the cloned
> kernel, and install then the build result on my board.
> 
> I tried to modify the config.tar.bz2 as well as adding the
> CONFIG_PROVE_LOCKING=y to the config.addon.tar.bz2. in both cases the
> build fails with the same error:
> 
> https://build.opensuse.org/package/live_build_log/home:frank_kunz:branches:openSUSE:Factory:ARM/kernel-lpae/standard/armv7l
> 
> Where do I need to put the configuration change in to get a debug build?
> Or is there an other method to prepare that?
> 
> Br,
> Frank
> 


It is a long story...

First, you have to clone appropriate branch of
https://kernel.opensuse.org/cgit/kernel-source/log/?h=master

Then modify config and run ./scripts/tar-up.sh to create tarball and
./scripts/osc_wrapper to create package at OBS.


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

[opensuse-arm] JeOS QA

[Matwey V. Kornilov]

Hello,

I am sorry to say, but currently
openSUSE-Tumbleweed-ARM-JeOS-efi.aarch64-2018.08.13-Build1.1.raw has two
breaking bugs:

https://bugzilla.opensuse.org/show_bug.cgi?id=1104850 (broken GRUB)
https://bugzilla.opensuse.org/show_bug.cgi?id=1092590 (broken 'secure'
random in kernel)

This is not how it should be. We probably need a way to test
JeOS-efi.aarch64 in OpenQA to avoid such unattended issues with JeOSes.

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

[opensuse-arm] Re: Espressobin image not starting

[Matwey V. Kornilov]

On 14.08.2018 12:40, Matwey V. Kornilov wrote:
> On 09.08.2018 19:14, Frank Kunz wrote:
>> Hello,
>>
>> from JeOS revision log I found:
>>
>> Dirk Mueller (dirkmueller) committed 5 months ago (revision 602)
>> - Drop JeOS-espressobin: use JeOS-efi.aarch64 instead
>> - JeOS-rock64: the board now boots, but the image deploying requires
>> manual quircks
>>
>> So I tried
>> openSUSE-Tumbleweed-ARM-JeOS-efi.aarch64-2018.05.11-Build1.1.raw.xz and
>> it cannot find the boot disk/partition:
>>
>> Kiwi output:
>> ...
>> ++ /usr/sbin/hwinfo --disk
>>
>>
>> ++ cut -f2 -d:
>>
>>
>> ++ grep -E 'Device File:|BIOS id'
>>
>>
>> ++ sed '-es@(.*)@@'
>>
>>
>> ++ tr -d ' '
>>
>>
>> + diskDevices='/dev/ram11
>>
>>
>> /dev/ram2
>>
>>
>> /dev/ram0
>>
>>
>> /dev/ram9
>>
>>
>> /dev/ram7
>>
>>
>> /dev/ram14
>>
>>
>> /dev/ram5
>>
>>
>> /dev/ram12
>>
>>
>> /dev/ram3
>>
>>
>> /dev/ram10
>>
>>
>> /dev/ram1
>>
>>
>> /dev/ram8
>>
>>
>> /dev/ram15
>>
>>
>> /dev/ram6
>>
>>
>> /dev/ram13
>>
>>
>> /dev/ram4'
>> + lookupBiosBootDevice
>> ...
>>
>> Maybe a specific mmc driver needs to be loaded, but how to do that for
>> the generic JeOS-efi.aarch64 image?
> 
> I did include required modules for EspressoBin. I think that something
> wrong with dtb files in your case. Probably, u-boot doesn't find dtb
> supplied in the image.
> 

By the way, could you please tell which u-boot do you use at EspressoBin?

> Let me please check how does it work on my EspressoBin. I need some time.
> 
>>
>> Br,
>> Frank
>>
> 
> 


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

[opensuse-arm] Re: Espressobin image not starting

[Matwey V. Kornilov]

On 09.08.2018 19:14, Frank Kunz wrote:
> Hello,
> 
> from JeOS revision log I found:
> 
> Dirk Mueller (dirkmueller) committed 5 months ago (revision 602)
> - Drop JeOS-espressobin: use JeOS-efi.aarch64 instead
> - JeOS-rock64: the board now boots, but the image deploying requires
> manual quircks
> 
> So I tried
> openSUSE-Tumbleweed-ARM-JeOS-efi.aarch64-2018.05.11-Build1.1.raw.xz and
> it cannot find the boot disk/partition:
> 
> Kiwi output:
> ...
> ++ /usr/sbin/hwinfo --disk
> 
> 
> ++ cut -f2 -d:
> 
> 
> ++ grep -E 'Device File:|BIOS id'
> 
> 
> ++ sed '-es@(.*)@@'
> 
> 
> ++ tr -d ' '
> 
> 
> + diskDevices='/dev/ram11
> 
> 
> /dev/ram2
> 
> 
> /dev/ram0
> 
> 
> /dev/ram9
> 
> 
> /dev/ram7
> 
> 
> /dev/ram14
> 
> 
> /dev/ram5
> 
> 
> /dev/ram12
> 
> 
> /dev/ram3
> 
> 
> /dev/ram10
> 
> 
> /dev/ram1
> 
> 
> /dev/ram8
> 
> 
> /dev/ram15
> 
> 
> /dev/ram6
> 
> 
> /dev/ram13
> 
> 
> /dev/ram4'
> + lookupBiosBootDevice
> ...
> 
> Maybe a specific mmc driver needs to be loaded, but how to do that for
> the generic JeOS-efi.aarch64 image?

I did include required modules for EspressoBin. I think that something
wrong with dtb files in your case. Probably, u-boot doesn't find dtb
supplied in the image.

Let me please check how does it work on my EspressoBin. I need some time.

> 
> Br,
> Frank
> 


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

Re: [opensuse-arm] How to debug Grub config

[Matwey V. Kornilov]

2018-07-30 21:47 GMT+03:00 Andreas Färber :
> Am 30.07.2018 um 18:35 schrieb Matwey V. Kornilov:
>> 2018-07-30 14:23 GMT+03:00 Alexander Graf :
>>> On 07/29/2018 01:19 PM, Matwey V. Kornilov wrote:
>>>> I am (stilL) trying to boot openSUSE on Rock64. I use JeOS image from
>>>> Contrib:Rockchip and manually built bootloader (with
>>>> 0001-XXX-openSUSE-XXX-Prepend-partition-.patch).
> [...]>> What U-Boot version are you basing on? There were a few
>>> bugs with the device path exposure in 2018.05 IIRC.
>>
>> I am running downstream u-boot with rock64 support:
>> https://github.com/ayufan-rock64/linux-u-boot
>> It is based on 2017.09
>
> What's missing for Rock64 in upstream? There's some RK3328 EVB code:
> https://git.denx.de/?p=u-boot.git;a=tree;f=board/rockchip/evb_rk3328;h=1d01065444611e4512a57072f97a6f39c30239fa;hb=HEAD

config, dts, and the most important thing is that memory
initialization in TPL should be different for Rock64 than for EVB.
But TPL doesn't work currently even in downstream (I have to use
rockchip proprietary binary), so it can be easy to cherry-pick partial
support (SPL + U-Boot).

>
> 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] How to debug Grub config

[Matwey V. Kornilov]

2018-07-30 14:23 GMT+03:00 Alexander Graf :
> Hi Matwey,
>
> On 07/29/2018 01:19 PM, Matwey V. Kornilov wrote:
>>
>> Hello,
>>
>> I am (stilL) trying to boot openSUSE on Rock64. I use JeOS image from
>> Contrib:Rockchip and manually built bootloader (with
>> 0001-XXX-openSUSE-XXX-Prepend-partition-.patch). And currently I see the
>> following new issue:
>>
>> mmc1 is current device
>> Scanning mmc 1:2...
>> 52462 bytes read in 43 ms (1.2 MiB/s)
>> Failed to mount ext2 filesystem...
>> ** Unrecognized filesystem type **
>> Scanning mmc 1:1...
>> Found EFI removable media binary efi/boot/bootaa64.efi
>> reading efi/boot/bootaa64.efi
>> 1247744 bytes read in 58 ms (20.5 MiB/s)
>> ## Starting EFI application at 0200 ...
>> Card did not respond to voltage select!
>> mmc_init: -95, time 10
>> Scanning disk rksd...@ff52.blk...
>> Scanning disk rksd...@ff50.blk...
>> Found 2 disks
>> Welcome to GRUB!
>>
>> ethernet@ff54 Waiting for PHY auto negotiation to complete.
>> TIMEOUT !
>> Could not initialize PHY ethernet@ff54
>>  GNU GRUB  version 2.02
>>
>>   Minimal BASH-like line editing is supported. For the first word, TAB
>> lists possible command completions. Anywhere else TAB lists possible
>> device or file completions.
>>
>>
>>
>> grub>
>>
>>
>> I see that both dtb file and EFI GRUB executable are loaded. But instead
>> of GRUB menu I see GRUB command line. I suppose it means that grub
>> failed to fetch GRUB configuration. How could I debug further what is
>> wrong?
>
>
> Correct. Grub failed to fetch the configuration because it failed to
> initialize the prefix correctly. If you run "set" on the command line, you
> should be able to see that the prefix is wrong. You can as interim step set
> it manually using the set command and then run "normal". That should get you
> a working grub menu.
>

Indeed, the prefix is (hd0)/efi/boot, instead of (hd0,gpt1)/efi/boot.

> The really important question is why grub could not determine its prefix
> correctly though. What U-Boot version are you basing on? There were a few
> bugs with the device path exposure in 2018.05 IIRC.

I am running downstream u-boot with rock64 support:
https://github.com/ayufan-rock64/linux-u-boot
It is based on 2017.09

>
>
> 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] Re: Z-turn Lite

[Matwey V. Kornilov]

2018-07-25 17:31 GMT+03:00 Alexander Graf :
>
>
>> Am 25.07.2018 um 16:20 schrieb Matwey V. Kornilov 
>> :
>>
>>> On 25.07.2018 17:08, Alexander Graf wrote:
>>>
>>>
>>>> Am 25.07.2018 um 15:42 schrieb Matwey V. Kornilov 
>>>> :
>>>>
>>>>
>>>> Hi,
>>>>
>>>> Does anybody tried Z-turn Lite board with combined CPU/FPGA SoC? It
>>>> seems to be the most inexpensive model based on Xilinx Zynq SoC.
>>>>
>>>> http://www.myirtech.com/list.asp?id=565
>>>
>>> I regularly use the 7020 based Z-Turn. I guess enabling the Lite shouldn't 
>>> bee too hard.
>>>
>>> Alex
>>
>> Cannot find it on openSUSE wiki.
>
> Did I forget to build an image too?

I've found only the following project without built image:
https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:Zynq

>
>> Is FPGA running supported well with
>> upstream kernel? What is overall support?
>
> Depends on what you're trying to do. If all you need is a constant bitstream 
> that is pushed in from FSBL/U-Boot, it works very well.
>
> I have personally not used fpga manager for runtime fpga updates though.
>
> 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

[opensuse-arm] Re: Z-turn Lite

[Matwey V. Kornilov]

On 25.07.2018 17:08, Alexander Graf wrote:
> 
> 
>> Am 25.07.2018 um 15:42 schrieb Matwey V. Kornilov 
>> :
>>
>>
>> Hi,
>>
>> Does anybody tried Z-turn Lite board with combined CPU/FPGA SoC? It
>> seems to be the most inexpensive model based on Xilinx Zynq SoC.
>>
>> http://www.myirtech.com/list.asp?id=565
> 
> I regularly use the 7020 based Z-Turn. I guess enabling the Lite shouldn't 
> bee too hard.
> 
> Alex

Cannot find it on openSUSE wiki. Is FPGA running supported well with
upstream kernel? What is overall support?

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


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

[opensuse-arm] Z-turn Lite

[Matwey V. Kornilov]

Hi,

Does anybody tried Z-turn Lite board with combined CPU/FPGA SoC? It
seems to be the most inexpensive model based on Xilinx Zynq SoC.

http://www.myirtech.com/list.asp?id=565

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

[opensuse-arm] opensuse.org and openSUSE ARM

[Matwey V. Kornilov]

Hi all,

I think it is important that there is no way to figure out that openSUSE
available at ARM architecture reading site www.opensuse.org

Trying to "download" Linux, I end up on
https://software.opensuse.org/distributions/leap?locale=en where only
x86_64 is available.

In my opinion we could highlight presence of ARM port for a few
best-supported SBCs (for instance, Raspberry Pi, BeagleBone, QEMU/EFI).

What do you think?

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

Re: [opensuse-arm] Beagle Board Black boot from µSD

[Matwey V. Kornilov]

On 31.05.2018 14:50, Roger Oberholtzer wrote:
> On Thu, May 31, 2018 at 1:32 PM, Andreas Färber  wrote:
> 
>>> I think Andre[a]s (in Cc) played with PRU already.
>>
>> I had prepared a cross-compiler toolchain, but it was not yet upstream
>> at the time and I haven't updated the packages for some years - SRs welcome.
>>
>> https://build.opensuse.org/project/show/home:a_faerber:pru
> 
> I see that.
> 
>> Matwey and Alex will know more, but at the time there was only a uio
>> driver. The remoteproc driver was still missing upstream, and I still
>> don't see any with pru in the name:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/remoteproc
> 
> I need to see how one should really use the PRU. I kind of assumed
> that one generated code somewhere (using some tool chain - TI's?) that
> one then loaded into the PRU. How you talk to or control it is
> unclear. I want it to do some fast processing of a couple I/O lines,
> and occasionally send out some information. Perhaps just even an
> interrupt that a Linux all or driver could sense and act on.
> 
> We tried having a Raspberry PI 3 monitor these lines (which trigger an
> interrupt), but even in C in a dedicated kernel driver (no context
> switching), it could not keep up. We are hoping that the PRU may do
> better. No idea.
> 

Basically you have to compile your binary code using TI toolchain or GCC
toolchain. And follow TI docs to interact with hardware.

Then there is your user-space application which loads this binary to the
hardware and exchange the data with your firmware.

The application has to use appropriate host kernel interface to upload
binary. The interface implementation for BBB is currently missing part
in upstream linux kernel.

> 
> 
> 
> 


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

[opensuse-arm] Re: Beagle Board Black boot from µSD

[Matwey V. Kornilov]

On 31.05.2018 10:02, Roger Oberholtzer wrote:
> The openSUSE info for the Beagle Board Black
> (https://en.opensuse.org/HCL:BeagleBone_Black) says:
> 
>To boot from µSD card, you must press boot select switch
>button (near µSD slot) on power-on.
>Otherwise, you will boot from internal eMMC.
> 
> Is this still the case? I am guessing that this is a board-related
> thing. Is there no way to get the board to boot from the µSD card
> automatically?

In order to boot from uSD automatically, you have to ensure that there
is no bootloader at eMMC memory. This can be done using zeroing begin of
eMMC. Pressing the button just changes default probing order.

> 
> I do not have a card yet. I want to explore the ARM PRU (programmable
> real-time unit). But booting from the µSD will be a requirement if we
> chose to use this card.

In theory you also can deploy openSUSE image onto eMMC memory if you
manage to boot Linux from somewhere. But as far as I know nobody tried
this yet.

It would be great if you could manage to bring PRU up. There are still
some missing parts.

> 
> 
> 


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

[opensuse-arm] Leap 15.0: beaglebone black

[Matwey V. Kornilov]

Hi,

I've just booted 15.0 image on BeagleBone Black. It works as expected,
surprisingly, nothing crashed yet.

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

Re: [opensuse-arm] Ubuntu:18.04:Ports

[Matwey V. Kornilov]

2018-04-27 15:25 GMT+03:00 Adrian Schröter <adr...@suse.de>:
> On Freitag, 27. April 2018, 13:43:05 CEST wrote Matwey V. Kornilov:
>> 2018-04-27 13:03 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>> > 2018-04-27 12:53 GMT+03:00 Adrian Schröter <adr...@suse.de>:
>> >> On Freitag, 27. April 2018, 11:26:24 CEST wrote Matwey V. Kornilov:
>> >>> Hello,
>> >>>
>> >>> Is it possible to have Ubuntu:18.04:Ports with aarch64?
>> >>> I am trying to make some experiments with GStreamer and RockChip SBC and
>> >>> I need to rebuild specific deb-packages. Everything was ok until I found
>> >>> that only x86_64 is available.
>> >>
>> >> I have created it, but it won't work most likely, since I did not find
>> >> a reliable source for the gpg keys of the repo.
>> >>
>> >
>> > Thanks. Lets see.
>>
>> Well. It is stuck on DoD now. Is it due to missing keys?
>
> yes

Isn't keyserver.ubuntu.com the primary place to import the keys from?

>
> --
>
> Adrian Schroeter
> email: adr...@suse.de
>
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 
> 21284 (AG Nürnberg)
>
> Maxfeldstraße 5
> 90409 Nürnberg
> Germany
>
>
>
>



-- 
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] Ubuntu:18.04:Ports

[Matwey V. Kornilov]

2018-04-27 13:03 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
> 2018-04-27 12:53 GMT+03:00 Adrian Schröter <adr...@suse.de>:
>> On Freitag, 27. April 2018, 11:26:24 CEST wrote Matwey V. Kornilov:
>>> Hello,
>>>
>>> Is it possible to have Ubuntu:18.04:Ports with aarch64?
>>> I am trying to make some experiments with GStreamer and RockChip SBC and
>>> I need to rebuild specific deb-packages. Everything was ok until I found
>>> that only x86_64 is available.
>>
>> I have created it, but it won't work most likely, since I did not find
>> a reliable source for the gpg keys of the repo.
>>
>
> Thanks. Lets see.

Well. It is stuck on DoD now. Is it due to missing keys?

>
>> Can you give me some pointer by chance?
>
> Hm. I wish I knew.
>
>>
>> --
>>
>> Adrian Schroeter
>> email: adr...@suse.de
>>
>> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 
>> 21284 (AG Nürnberg)
>>
>> Maxfeldstraße 5
>> 90409 Nürnberg
>> Germany
>>
>>
>>
>>
>
>
>
> --
> 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] Ubuntu:18.04:Ports

[Matwey V. Kornilov]

2018-04-27 12:53 GMT+03:00 Adrian Schröter <adr...@suse.de>:
> On Freitag, 27. April 2018, 11:26:24 CEST wrote Matwey V. Kornilov:
>> Hello,
>>
>> Is it possible to have Ubuntu:18.04:Ports with aarch64?
>> I am trying to make some experiments with GStreamer and RockChip SBC and
>> I need to rebuild specific deb-packages. Everything was ok until I found
>> that only x86_64 is available.
>
> I have created it, but it won't work most likely, since I did not find
> a reliable source for the gpg keys of the repo.
>

Thanks. Lets see.

> Can you give me some pointer by chance?

Hm. I wish I knew.

>
> --
>
> Adrian Schroeter
> email: adr...@suse.de
>
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 
> 21284 (AG Nürnberg)
>
> Maxfeldstraße 5
> 90409 Nürnberg
> Germany
>
>
>
>



-- 
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

[opensuse-arm] Ubuntu:18.04:Ports

[Matwey V. Kornilov]

Hello,

Is it possible to have Ubuntu:18.04:Ports with aarch64?
I am trying to make some experiments with GStreamer and RockChip SBC and
I need to rebuild specific deb-packages. Everything was ok until I found
that only x86_64 is available.

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

Re: [opensuse-arm] rock64

[Matwey V. Kornilov]

2018-03-10 12:41 GMT+03:00 Alexander Graf <ag...@suse.de>:
>
>
>> Am 10.03.2018 um 10:05 schrieb Matwey V. Kornilov 
>> <matwey.korni...@gmail.com>:
>>
>> 2018-03-10 3:03 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>
>>>
>>>> On 09.03.18 19:22, Matwey V. Kornilov wrote:
>>>> Well, something strange happens at pre-init stage at Rock64:
>>>>
>>>> ===> Calling pre-init stage in system image
>>>> [  130.501368] systemd-udevd[1848]: starting version 234
>>>> [  130.751693] device-mapper: uevent: version 1.0.3
>>>> [  130.752483] device-mapper: ioctl: 4.37.0-ioctl (2017-09-20)
>>>> initialised: dm-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

[Matwey V. Kornilov]

2018-03-10 3:03 GMT+03:00 Alexander Graf <ag...@suse.de>:
>
>
> On 09.03.18 19:22, Matwey V. Kornilov wrote:
>> Well, something strange happens at pre-init stage at Rock64:
>>
>> ===> Calling pre-init stage in system image
>> [  130.501368] systemd-udevd[1848]: starting version 234
>> [  130.751693] device-mapper: uevent: version 1.0.3
>> [  130.752483] device-mapper: ioctl: 4.37.0-ioctl (2017-09-20)
>> initialised: dm-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

[opensuse-arm] initrd.vmx bloated

[Matwey V. Kornilov]

Hi,

initrd.vmx is almost 100MB big in
JeOS-espressobin.aarch64-2018.03.07-Build3.4 (and other images). It is
almost 1GB when uncompressed and the image is not bootable due ot it.
There are 500 MB of /usr/lib/locale files inside initrd. Could somebody
drop them out of initrd?

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

Re: [opensuse-arm] rock64

[Matwey V. Kornilov]

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 <matwey.korni...@gmail.com>:
> I've found that kiwi already can do something similar I need:
>
> https://doc.opensuse.org/projects/kiwi/doc/
>
> [--disk-start-sector number]
>
> The start sector value for virtual disk based images. The default is
> 2048. For newer disks including SSD this is a reasonable default. In
> order to use the old style disk layout the value can be set to 32.
>
>
> 2018-01-02 19:01 GMT+03:00 Andreas Färber <afaer...@suse.de>:
>> Am 02.01.2018 um 16:59 schrieb Matwey V. Kornilov:
>>> 2018-01-02 18:27 GMT+03:00 Andreas Färber <afaer...@suse.de>:
>>>> Am 01.01.2018 um 16:20 schrieb Matwey V. Kornilov:
>>>>> Why didn't we allocate separate GPT partition for each bootloader
>>>>> image? It seems to be generic way to denote that specific place at SD
>>>>> card is allocated and used by something.
>>>>
>>>> Kiwi only supports a few partitioning schemes, it does not allow to add
>>>> random other partitions AFAIK. Every scheme needs to be defined in the
>>>> XML Schema and needs a matching implementation in Kiwi.
>>>>
>>>> Have you checked out Alex' new non-Kiwi approach for RPi3 and Pine64?
>>>
>>> Nope. Where can I find it?
>>>
>>> https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:Pine64
>>>
>>> This one?
>>
>> https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:Pine64/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] Re: JeOS-efi.aarch64-2018.03.07-Build2.1.raw: Invalid FAT entry

[Matwey V. Kornilov]

2018-03-07 22:19 GMT+03:00 Alexander Graf <ag...@suse.de>:
>
>
> On 07.03.18 19:58, Matwey V. Kornilov wrote:
>> 2018-03-07 21:31 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>
>>>
>>>> Am 07.03.2018 um 19:12 schrieb Matwey V. Kornilov 
>>>> <matwey.korni...@gmail.com>:
>>>>
>>>> 07.03.2018 21:01, Matwey V. Kornilov пишет:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I am trying to use
>>>>> openSUSE-Tumbleweed-ARM-JeOS-efi.aarch64-2018.03.07-Build2.1.raw to run
>>>>> Rock64. I use manually compiled u-boot
>>>>> 2018.01-rc2-02249-g19e31fac0d-dirty and see the following:
>>>>>
>>>>> => load mmc 1:1 0x0200 efi/boot/bootaa64.efi
>>>>> reading efi/boot/bootaa64.efi
>>>>> MMC: block number 0x18005 exceeds max(0x1dacc00)
>>>>> MMC: block number 0x18005 exceeds max(0x1dacc00)
>>>>> Invalid FAT entry
>>>>> 6144 bytes read in 11 ms (544.9 KiB/s)
>>>>>
>>>>> This didn't happen when we used kiwi-7 to build JeOS at Factory.
>>>>> Can it be some issue with FAT16/FAT32?
>>>>>
>>>>
>>>> Not sure, that related, but
>>>>
>>>> EFI created by Kiwi-7
>>>>
>>>> System ID "mkfs.fat"
>>>> Media byte 0xf8 (hard disk)
>>>>   512 bytes per logical sector
>>>>  4096 bytes per cluster
>>>> 1 reserved sector
>>>> First FAT starts at byte 512 (sector 1)
>>>> 2 FATs, 16 bit entries
>>>>102400 bytes per FAT (= 200 sectors)
>>>> Root directory starts at byte 205312 (sector 401)
>>>>   512 root directory entries
>>>> Data area starts at byte 221696 (sector 433)
>>>> 51146 data clusters (209494016 bytes)
>>>> 63 sectors/track, 255 heads
>>>> 0 hidden sectors
>>>>409604 sectors total
>>>>
>>>> EFI created by Kiwi-9
>>>>
>>>> System ID "mkfs.fat"
>>>> Media byte 0xf8 (hard disk)
>>>>   512 bytes per logical sector
>>>>  2048 bytes per cluster
>>>> 1 reserved sector
>>>> First FAT starts at byte 512 (sector 1)
>>>> 2 FATs, 12 bit entries
>>>>  2048 bytes per FAT (= 4 sectors)
>>>> Root directory starts at byte 4608 (sector 9)
>>>>   512 root directory entries
>>>> Data area starts at byte 20992 (sector 41)
>>>>  1013 data clusters (2074624 bytes)
>>>> 32 sectors/track, 64 heads
>>>> 0 hidden sectors
>>>>  4096 sectors total
>>>
>>> We reduced the size of the efi partition to 2MB. Maybe that triggered a bug 
>>> in U-Boot?
>>>
>>> Could you try to build an image with a 16mb partition instead?
>>>
>>
>> I've reparted drive manually and created 200mb EFI partition (FAT16).
>> It works well with u-boot.
>> It seems that u-boot doen't like FAT12.
>
> Ok, I've changed the default EFI partition size to 16MB. I guess there's
> a better fix, but this way we should be quite compatible :).

Well, I am agree with you that this should be reported upstream indeed.
At the other hand there a lot of existing downstream u-boot branches,
and it would be quite hard to fix all of them having +14MB space as
reward.

>
>
> 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] Re: JeOS-efi.aarch64-2018.03.07-Build2.1.raw: Invalid FAT entry

[Matwey V. Kornilov]

2018-03-07 21:31 GMT+03:00 Alexander Graf <ag...@suse.de>:
>
>
>> Am 07.03.2018 um 19:12 schrieb Matwey V. Kornilov 
>> <matwey.korni...@gmail.com>:
>>
>> 07.03.2018 21:01, Matwey V. Kornilov пишет:
>>>
>>> Hello,
>>>
>>> I am trying to use
>>> openSUSE-Tumbleweed-ARM-JeOS-efi.aarch64-2018.03.07-Build2.1.raw to run
>>> Rock64. I use manually compiled u-boot
>>> 2018.01-rc2-02249-g19e31fac0d-dirty and see the following:
>>>
>>> => load mmc 1:1 0x0200 efi/boot/bootaa64.efi
>>> reading efi/boot/bootaa64.efi
>>> MMC: block number 0x18005 exceeds max(0x1dacc00)
>>> MMC: block number 0x18005 exceeds max(0x1dacc00)
>>> Invalid FAT entry
>>> 6144 bytes read in 11 ms (544.9 KiB/s)
>>>
>>> This didn't happen when we used kiwi-7 to build JeOS at Factory.
>>> Can it be some issue with FAT16/FAT32?
>>>
>>
>> Not sure, that related, but
>>
>> EFI created by Kiwi-7
>>
>> System ID "mkfs.fat"
>> Media byte 0xf8 (hard disk)
>>   512 bytes per logical sector
>>  4096 bytes per cluster
>> 1 reserved sector
>> First FAT starts at byte 512 (sector 1)
>> 2 FATs, 16 bit entries
>>102400 bytes per FAT (= 200 sectors)
>> Root directory starts at byte 205312 (sector 401)
>>   512 root directory entries
>> Data area starts at byte 221696 (sector 433)
>> 51146 data clusters (209494016 bytes)
>> 63 sectors/track, 255 heads
>> 0 hidden sectors
>>409604 sectors total
>>
>> EFI created by Kiwi-9
>>
>> System ID "mkfs.fat"
>> Media byte 0xf8 (hard disk)
>>   512 bytes per logical sector
>>  2048 bytes per cluster
>> 1 reserved sector
>> First FAT starts at byte 512 (sector 1)
>> 2 FATs, 12 bit entries
>>  2048 bytes per FAT (= 4 sectors)
>> Root directory starts at byte 4608 (sector 9)
>>   512 root directory entries
>> Data area starts at byte 20992 (sector 41)
>>  1013 data clusters (2074624 bytes)
>> 32 sectors/track, 64 heads
>> 0 hidden sectors
>>  4096 sectors total
>
> We reduced the size of the efi partition to 2MB. Maybe that triggered a bug 
> in U-Boot?
>
> Could you try to build an image with a 16mb partition instead?
>

I've reparted drive manually and created 200mb EFI partition (FAT16).
It works well with u-boot.
It seems that u-boot doen't like FAT12.

>
> Alex
>
>>
>> --
>> 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

[opensuse-arm] Re: JeOS-efi.aarch64-2018.03.07-Build2.1.raw: Invalid FAT entry

[Matwey V. Kornilov]

07.03.2018 21:01, Matwey V. Kornilov пишет:
> 
> Hello,
> 
> I am trying to use
> openSUSE-Tumbleweed-ARM-JeOS-efi.aarch64-2018.03.07-Build2.1.raw to run
> Rock64. I use manually compiled u-boot
> 2018.01-rc2-02249-g19e31fac0d-dirty and see the following:
> 
> => load mmc 1:1 0x0200 efi/boot/bootaa64.efi
> reading efi/boot/bootaa64.efi
> MMC: block number 0x18005 exceeds max(0x1dacc00)
> MMC: block number 0x18005 exceeds max(0x1dacc00)
> Invalid FAT entry
> 6144 bytes read in 11 ms (544.9 KiB/s)
> 
> This didn't happen when we used kiwi-7 to build JeOS at Factory.
> Can it be some issue with FAT16/FAT32?
> 

Not sure, that related, but

EFI created by Kiwi-7

System ID "mkfs.fat"
Media byte 0xf8 (hard disk)
   512 bytes per logical sector
  4096 bytes per cluster
 1 reserved sector
First FAT starts at byte 512 (sector 1)
 2 FATs, 16 bit entries
102400 bytes per FAT (= 200 sectors)
Root directory starts at byte 205312 (sector 401)
   512 root directory entries
Data area starts at byte 221696 (sector 433)
 51146 data clusters (209494016 bytes)
63 sectors/track, 255 heads
 0 hidden sectors
409604 sectors total

EFI created by Kiwi-9

System ID "mkfs.fat"
Media byte 0xf8 (hard disk)
   512 bytes per logical sector
  2048 bytes per cluster
 1 reserved sector
First FAT starts at byte 512 (sector 1)
 2 FATs, 12 bit entries
  2048 bytes per FAT (= 4 sectors)
Root directory starts at byte 4608 (sector 9)
   512 root directory entries
Data area starts at byte 20992 (sector 41)
  1013 data clusters (2074624 bytes)
32 sectors/track, 64 heads
 0 hidden sectors
  4096 sectors total

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

[opensuse-arm] JeOS-efi.aarch64-2018.03.07-Build2.1.raw: Invalid FAT entry

[Matwey V. Kornilov]

Hello,

I am trying to use
openSUSE-Tumbleweed-ARM-JeOS-efi.aarch64-2018.03.07-Build2.1.raw to run
Rock64. I use manually compiled u-boot
2018.01-rc2-02249-g19e31fac0d-dirty and see the following:

=> load mmc 1:1 0x0200 efi/boot/bootaa64.efi
reading efi/boot/bootaa64.efi
MMC: block number 0x18005 exceeds max(0x1dacc00)
MMC: block number 0x18005 exceeds max(0x1dacc00)
Invalid FAT entry
6144 bytes read in 11 ms (544.9 KiB/s)

This didn't happen when we used kiwi-7 to build JeOS at Factory.
Can it be some issue with FAT16/FAT32?

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

Re: [opensuse-arm] Re: JeOS-efi.aarch64-2018.02.22: Failed to mount ext2 filesystem

[Matwey V. Kornilov]

2018-02-26 23:18 GMT+03:00 Alexander Graf <ag...@suse.de>:
>
>
> On 26.02.18 20:36, Matwey V. Kornilov wrote:
>> 2018-02-26 22:07 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>
>>>
>>> On 26.02.18 08:19, Matwey V. Kornilov wrote:
>>>> 2018-02-26 0:06 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>>>
>>>>>
>>>>>> Am 25.02.2018 um 16:37 schrieb Matwey V. Kornilov 
>>>>>> <matwey.korni...@gmail.com>:
>>>>>>
>>>>>> 25.02.2018 18:22, Matwey V. Kornilov пишет:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am faced the issue that recent JeOS builds cannot be read by u-boot:
>>>>>>>
>>>>>>> ls mmc 1:2 /
>>>>>>> Failed to mount ext2 filesystem...
>>>>>>> ** Unrecognized filesystem type **
>>>>>>
>>>>>> Hm, Now I see. Why do you use btrfs for having separate /boot partition?
>>>>>> Is there any reason for it?
>>>>>
>>>>> I assume that change came with the seitch to python-kiwi. I assume the 
>>>>> main rationale would be snapshotting of /boot, so you can load old 
>>>>> kernels.
>>>>>
>>>>
>>>> /lib/modules are on the separate partition, so it won't work anyway.
>>>> We could have united / and put dtb files onto separate EFI partition
>>>> for snapshotting kernels.
>>>
>>> Nah, if you go that far, better ensure the built-in device tree from
>>> U-Boot contains a device tree that just covers everything you need. That
>>> way you don't need to load any dtb files. The dtb loading from /boot is
>>> really mostly there for cases where firmware is "broken" and does not
>>> deliver good, upstream compatible device trees.
>>>
>>
>> Well, it would be full of pain way, especially in cases when one
>> bootloader fits multiple dtb-s (i.e. am335x).
>
> It depends. Currently, U-Boot needs to detect the board and find a
> different dtb. Instead, it could easily just pick a different built-in dtb.
>
> Depending on the board you're on, it may even be the easiest way
> forward. As soon as U-Boot 2018.03 is in Factory, I'll move the
> Raspberry Pi to a model where the RPi firmware provided devices tree
> gets propagated all the way to U-Boot as well as Linux. And that makes
> things easier at the end of the day, because we don't need to
> synchronize 3 different DTs throughout the boot process.
>

At least, neither rk3328 nor marvel 3700 espressobin not able to boot
the kernel using bundled u-boot dtb.
I think this should be primarily solved upstream, if they would manage
to merge dts trees between different projects.

>
> 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] Re: JeOS-efi.aarch64-2018.02.22: Failed to mount ext2 filesystem

[Matwey V. Kornilov]

2018-02-26 22:07 GMT+03:00 Alexander Graf <ag...@suse.de>:
>
>
> On 26.02.18 08:19, Matwey V. Kornilov wrote:
>> 2018-02-26 0:06 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>
>>>
>>>> Am 25.02.2018 um 16:37 schrieb Matwey V. Kornilov 
>>>> <matwey.korni...@gmail.com>:
>>>>
>>>> 25.02.2018 18:22, Matwey V. Kornilov пишет:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I am faced the issue that recent JeOS builds cannot be read by u-boot:
>>>>>
>>>>> ls mmc 1:2 /
>>>>> Failed to mount ext2 filesystem...
>>>>> ** Unrecognized filesystem type **
>>>>
>>>> Hm, Now I see. Why do you use btrfs for having separate /boot partition?
>>>> Is there any reason for it?
>>>
>>> I assume that change came with the seitch to python-kiwi. I assume the main 
>>> rationale would be snapshotting of /boot, so you can load old kernels.
>>>
>>
>> /lib/modules are on the separate partition, so it won't work anyway.
>> We could have united / and put dtb files onto separate EFI partition
>> for snapshotting kernels.
>
> Nah, if you go that far, better ensure the built-in device tree from
> U-Boot contains a device tree that just covers everything you need. That
> way you don't need to load any dtb files. The dtb loading from /boot is
> really mostly there for cases where firmware is "broken" and does not
> deliver good, upstream compatible device trees.
>

Well, it would be full of pain way, especially in cases when one
bootloader fits multiple dtb-s (i.e. am335x).

>>> I guess there is an xml tag we can provide to make /boot ext4 again?
>
> I've changed the xml to explicitly have a /boot partition in ext4.
>

Thanks.

>
> 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] Re: JeOS-efi.aarch64-2018.02.22: Failed to mount ext2 filesystem

[Matwey V. Kornilov]

2018-02-26 0:06 GMT+03:00 Alexander Graf <ag...@suse.de>:
>
>
>> Am 25.02.2018 um 16:37 schrieb Matwey V. Kornilov 
>> <matwey.korni...@gmail.com>:
>>
>> 25.02.2018 18:22, Matwey V. Kornilov пишет:
>>>
>>> Hi,
>>>
>>> I am faced the issue that recent JeOS builds cannot be read by u-boot:
>>>
>>> ls mmc 1:2 /
>>> Failed to mount ext2 filesystem...
>>> ** Unrecognized filesystem type **
>>
>> Hm, Now I see. Why do you use btrfs for having separate /boot partition?
>> Is there any reason for it?
>
> I assume that change came with the seitch to python-kiwi. I assume the main 
> rationale would be snapshotting of /boot, so you can load old kernels.
>

/lib/modules are on the separate partition, so it won't work anyway.
We could have united / and put dtb files onto separate EFI partition
for snapshotting kernels.

> I guess there is an xml tag we can provide to make /boot ext4 again?
>
> Alex
>
>>
>>>
>>> And then dtb files cannot be read from /boot partition.
>>>
>>> Even without dtb, EFI application cannot be read correctly here:
>>>
>>> reading efi/boot/bootaa64.efi
>>> MMC: block number 0x18005 exceeds max(0x1dacc00)
>>> MMC: block number 0x18005 exceeds max(0x1dacc00)
>>> Invalid FAT entry
>>> 6144 bytes read in 11 ms (544.9 KiB/s)
>>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>>> ## Starting EFI application at 0200 ...
>>> Unknown Relocation off ffe type f
>>> ## Application terminated, r = 9223372036854775806
>>> EFI LOAD FAILED: continuing...
>>>
>>
>>
>> --
>> 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

[opensuse-arm] Re: JeOS-efi.aarch64-2018.02.22: Failed to mount ext2 filesystem

[Matwey V. Kornilov]

25.02.2018 18:22, Matwey V. Kornilov пишет:
> 
> Hi,
> 
> I am faced the issue that recent JeOS builds cannot be read by u-boot:
> 
> ls mmc 1:2 /
> Failed to mount ext2 filesystem...
> ** Unrecognized filesystem type **

Hm, Now I see. Why do you use btrfs for having separate /boot partition?
Is there any reason for it?

> 
> And then dtb files cannot be read from /boot partition.
> 
> Even without dtb, EFI application cannot be read correctly here:
> 
> reading efi/boot/bootaa64.efi
> MMC: block number 0x18005 exceeds max(0x1dacc00)
> MMC: block number 0x18005 exceeds max(0x1dacc00)
> Invalid FAT entry
> 6144 bytes read in 11 ms (544.9 KiB/s)
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> ## Starting EFI application at 0200 ...
> Unknown Relocation off ffe type f
> ## Application terminated, r = 9223372036854775806
> EFI LOAD FAILED: continuing...
> 


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

[opensuse-arm] JeOS-efi.aarch64-2018.02.22: Failed to mount ext2 filesystem

[Matwey V. Kornilov]

Hi,

I am faced the issue that recent JeOS builds cannot be read by u-boot:

ls mmc 1:2 /
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **

And then dtb files cannot be read from /boot partition.

Even without dtb, EFI application cannot be read correctly here:

reading efi/boot/bootaa64.efi
MMC: block number 0x18005 exceeds max(0x1dacc00)
MMC: block number 0x18005 exceeds max(0x1dacc00)
Invalid FAT entry
6144 bytes read in 11 ms (544.9 KiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
## Starting EFI application at 0200 ...
Unknown Relocation off ffe type f
## Application terminated, r = 9223372036854775806
EFI LOAD FAILED: continuing...

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

Re: [opensuse-arm] openSUSE-Tumbleweed ARM JeOS-efi.armv7

[Matwey V. Kornilov]

Surprisingly it works. Thank you. However, with -m 1024 it stil doesn't work.

2018-02-17 0:41 GMT+03:00 Alexander Graf <ag...@suse.de>:
>
>
> On 25.01.18 22:16, Matwey V. Kornilov wrote:
>> 2018-01-25 11:49 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>>> 2018-01-25 11:11 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>>>> 2018-01-25 0:28 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>>>
>>>>>
>>>>> On 24.01.18 20:29, Matwey V. Kornilov wrote:
>>>>>> 2018-01-24 22:05 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>>>>>
>>>>>>>
>>>>>>> On 24.01.18 18:10, Matwey V. Kornilov wrote:
>>>>>>>> 2018-01-24 19:51 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 24.01.18 17:43, Matwey V. Kornilov wrote:
>>>>>>>>>> 2018-01-24 16:38 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 24.01.18 13:15, Matwey V. Kornilov wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> There is one more thing that is unclear to me now. As far as I
>>>>>>>>>>>> understand there is no other way except FDT to provide hardware 
>>>>>>>>>>>> layout
>>>>>>>>>>>> for armv7l kernel. Then, who is responsible for FDT loading? As 
>>>>>>>>>>>> far as
>>>>>>>>>>>> I understand it is grub2 task to load FDT from the table at
>>>>>>>>>>>> b1b621d5-f19c-41a5- And FDT is completely provided by UEFI
>>>>>>>>>>>> firmware. In case of u-boot, dtb file is loaded from the disk by 
>>>>>>>>>>>> means
>>>>>>>>>>>> of u-boot and placed into memory. What should happen here when 
>>>>>>>>>>>> OVMF is
>>>>>>>>>>>> used? In theory, it has to be configured to generate FDT from QEMU
>>>>>>>>>>>> config somehow, right? Or pass-through entire FDT from Qemu
>>>>>>>>>>>> hypervisor?
>>>>>>>>>>>
>>>>>>>>>>> It basically passes through the device tree that's generated by 
>>>>>>>>>>> QEMU,
>>>>>>>>>>> yes. However, OVMF defaults changed a while back and it only exposes
>>>>>>>>>>> ACPI tables instead of DT in newer versions on AArch64 IIRC.
>>>>>>>>>>>
>>>>>>>>>>> Maybe something went wrong and they changed them for armv7 as well 
>>>>>>>>>>> by
>>>>>>>>>>> accident?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I use latest version of aarch32 OVMF firmware from 
>>>>>>>>>> openSUSE:Factory:ARM.
>>>>>>>>>> Well, then, I suppose, I have to see appropriate EFI driver
>>>>>>>>>> (FdtClientDxe ? ) in the driver list.
>>>>>>>>>
>>>>>>>>> I don't think the fact that the driver is loaded tells you anything.
>>>>>>>>>
>>>>>>>>> I assume you can't boot the VM properly? Does grub see the DT table?
>>>>>>>>> lsefi in grub should show you iirc.
>>>>>>>>>
>>>>>>>>> If it doesn't show it, but instead shows ACPI tables, can you try to
>>>>>>>>> pass -no-acpi to QEMU?
>>>>>>>>>
>>>>>>>>
>>>>>>>> There is nothing FDT-related at GRUB side. This is why I started to
>>>>>>>> search who is responsible for providing FDT.
>>>>>>>> -no-acpi also doesn't change anything.
>>>>>>>>
>>>>>>>> grub> lsefi
>>>>>>>
>>>>>>> Hm, that is the object list. Maybe it was lsefisystab?
>>>>>>>
>>>>>>
>>>>>> Ok, here FDT is present (b1b621d5-...). How can I dump it from grub 
>>>>>> console?
>>>>>> If I do it right, then It has correct magic header 0xd00dfeed.
>>>>>
>>>>> Looks all green to me then. I guess you actually get into the kernel
>>>>> then with a working device tree, but just don't see output?
>>>>>
>>>>
>>>> Sure, I've managed to dump and decomile FDT. As far as I don't see any
>>>> output, something is wrong either with serial port or interrupt
>>>> controller?
>>>>
>>>>
>>>
>>> Hm, with qemu debug and grub debug on, I see the following:
>>>
>>> Jumping to Linux...
>>> Taking exception 4 [Data Abort]
>>> ...from EL1 to EL1
>>> ...with ESR 0x25/0x9637
>>> ...with DFSR 0x37 DFAR 0xfffdd000
>>>
>>
>> When I use -kernel and -initrd instead of -bios in qemu command line,
>> then the kernel boots successfully.
>
> I just ran across a very similar issue and it boiled down to the fact
> that grub puts the DT outside the linear memory map of Linux.
>
> Can you try to boot with -m 768 to ensure we always fit? That should
> make it work.
>
>
> Thanks,
>
> 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

[opensuse-arm] Re: Change to the rebuild behavior of openSUSE:Factory:ARM

[Matwey V. Kornilov]

03.02.2018 11:42, Dirk Müller пишет:
> Hi,
> 
> We had a couple of issues related to getting a new build of Factory
> into openqa recently. This was partially caused
> by ARM not able to catch up with the check in frequency of x86. To
> some extend this was bad luck (the critial long
> running build job hitting the slowest / misconfigured worker taking
> forever to finish) and to some extend we just can't keep
> up I guess.
> 
> Over the last few days Alex and I have reconfigured the workers to be
> less overcommitted and redirecting more resource
> intensive jobs to the better performing variants. hopefully this helps
> with the overall build speed and gets us to catch up.
> 
> In addition, there is a rebuild counter sync endless-loop issue that
> isn't fully understood yet, but apparently either aarch64
> or armv7l were playing ping pong rebuilds with each other. we've
> stabilized that by disabling armv7l build temporarily (it is reenabled
> now).
> 
> Last but not least as an experiment we've changed the source rebuild
> behavior. previously, Factory:ARM was directly using the
> sources from Factory, so whenever there was a source change there it
> immediately propagated to ARM. that contributed to
> rarely be able to finish a ftp tree build (because that one only
> starts when nothing else is building, and it takes a couple of hours
> to
> complete). without a ftp tree build, new DVDs are not entering openqa.
> 
> So as an experiment we've switched to frozen links. this means we're
> linking sources from a particular level (0201 right now) of factory,
> and
> won't get automatic updates. That seems to work fine. unfortunately
> the "updating link" operation crashes the build service with an error
> 500,
> so we can't update anymore, and need an admin to fix that for us.
> 
> The command to update the source state to build against is this:
> 
> osc api -X POST '/source/openSUSE:Factory:ARM?cmd=freezelink'
> 
> It needs to be run by someone who has maintainer rights in that
> project. currently it crashes though.

How often will it be triggered?

> 
> Unfortunately I'll be out for a few days (vacation), so I hope alex or
> Andreas can figure out together with the OBS team on how to get
> that issue fixed.
> 
> The plan is to add that into the totest manager, so that we're only
> taking source changes once when we just have handed off a build  to
> openqa. this
> way we might not try to do every snapshot that x86 publishes, but if
> we were able to finish one, we take the next one from aarch64
> (potentially skipping
> one or two interim ones on x86). this part isn't implemented yet
> though, I'll look at that end of next week.
> 
> 
> TIA,
> Dirk
> 


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

[opensuse-arm] Re: Initrd.vmx too big

[Matwey V. Kornilov]

On 05.02.2018 15:01, Alexander Graf wrote:
> 
> 
> On 05.02.18 11:49, Alexander Graf wrote:
>>
>>
>> On 02.02.18 18:21, Alexander Graf wrote:
>>>
>>>
 Am 02.02.2018 um 14:08 schrieb Guillaume Gardet :



> Le 23/01/2018 à 16:59, Alexander Graf a écrit :
> Howdy,
>
>> On 01/23/2018 04:20 PM, Guillaume Gardet wrote:
>> Hi,
>>
>> I just tested the latest Tumbleweed image for my Beagleboard xM and the 
>> boot fails because the initrd is too big (209M uncompressed) for the RAM.
>
> I'm seeing that pattern slowly emerge across the board. I guess it's 
> about time we start to drop the legacy kiwi initrd. Can you try and see if
>
> #define USE_DRACUT_FIRSTBOOT
>
> in Images.kiwi.in works for you? That should also drastically reduce the 
> initrd size.

 Build fails because jing was not preinstalled. Once preinstalled, I get an 
 error about initrd_system and efipartsize attributes not allowed:
 **
  EXEC [/usr/bin/jing /usr/share/kiwi/modules/KIWISchema.rng 
 /usr/src/packages/SOURCES/config.converted.xml 2>/dev/null]
 [  246s] Feb-02 11:02:02 <3> : 
 /usr/src/packages/SOURCES/config.converted.xml:21:462: error: attribute 
 "initrd_system" not allowed here; expected attribute "bootfilesystem", 
 "bootloader", "bootpartition", "bootpartsize", "bootprofile", 
 "boottimeout", "btrfs_root_is_snapshot", "checkprebuilt", "compressed", 
 "container", "devicepersistency", "editbootconfig", "editbootinstall", 
 "filesystem", "firmware", "flags", "format", "formatoptions", 
 "fsmountoptions", "fsnocheck", "fsreadonly", "fsreadwrite", "gcelicense", 
 "hybrid", "hybridpersistent", "hybridpersistent_filesystem", 
 "installboot", "installiso", "installprovidefailsafe", "installpxe", 
 "installstick", "kernelcmdline", "luks", "luksOS", "mdraid", "primary", 
 "ramonly", "target_blocksize", "vga", "vhdfixedtag", "volid", 
 "wwid_wait_timeou
>  t", "zfsoptions" or "zipl_targettype"
 [  246s] /usr/src/packages/SOURCES/config.converted.xml:21:462: error: 
 attribute "efipartsize" not allowed here; expected attribute 
 "bootfilesystem", "bootpartition", "bootpartsize", "bootprofile", 
 "boottimeout", "btrfs_root_is_snapshot", "checkprebuilt", "compressed", 
 "container", "devicepersistency", "editbootconfig", "editbootinstall", 
 "flags", "format", "formatoptions", "fsnocheck", "fsreadonly", 
 "fsreadwrite", "gcelicense", "hybrid", "hybridpersistent", 
 "hybridpersistent_filesystem", "installboot", "installiso", 
 "installprovidefailsafe", "installpxe", "installstick", "kernelcmdline", 
 "luks", "luksOS", "mdraid", "primary", "ramonly", "target_blocksize", 
 "vga", "vhdfixedtag", "volid", "wwid_wait_timeout", "zfsoptions" or 
 "zipl_targettype"
 [  246s]
 [  246s] Feb-02 11:02:02 <3> : KIWI exited with error(s)
 **

 Am I missing something?
>>>
>>> Let‘s ask Marcus :)
>>
>> I had a quick chat with him and he showed me a few other points where
>> our xml description is doing useless things.
>>
>> However, during that discussion I realized we're not using kiwi-ng, but
>> instead rely on the old code. That's also why you don't get the dracut
>> initrd pieces to work.
>>
>> To build with kiwi-ng, you'll have to modify your prjconf to pull in the
>> right package. Check out the o:F:A one and just do the reverse in your
>> project's :)
> 
> I've created a small test repo where I've enabled the dracut initrd for
> rpi3: https://build.opensuse.org/project/show/home:algraf:arm-kiwi-ng
> 
> Let's see how that works out ...
> 
> Once that's ok, I guess we can switch to kiwi8 in o:F:A and then start
> moving beagle to the dracut initrd.

Will we move Leap:15.0:Ports to kiwi8 as well?

> 
> 
> Alex
> 


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

Re: [opensuse-arm] openSUSE-Tumbleweed ARM JeOS-efi.armv7

[Matwey V. Kornilov]

2018-01-25 11:49 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
> 2018-01-25 11:11 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>> 2018-01-25 0:28 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>
>>>
>>> On 24.01.18 20:29, Matwey V. Kornilov wrote:
>>>> 2018-01-24 22:05 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>>>
>>>>>
>>>>> On 24.01.18 18:10, Matwey V. Kornilov wrote:
>>>>>> 2018-01-24 19:51 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>>>>>
>>>>>>>
>>>>>>> On 24.01.18 17:43, Matwey V. Kornilov wrote:
>>>>>>>> 2018-01-24 16:38 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 24.01.18 13:15, Matwey V. Kornilov wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> There is one more thing that is unclear to me now. As far as I
>>>>>>>>>> understand there is no other way except FDT to provide hardware 
>>>>>>>>>> layout
>>>>>>>>>> for armv7l kernel. Then, who is responsible for FDT loading? As far 
>>>>>>>>>> as
>>>>>>>>>> I understand it is grub2 task to load FDT from the table at
>>>>>>>>>> b1b621d5-f19c-41a5- And FDT is completely provided by UEFI
>>>>>>>>>> firmware. In case of u-boot, dtb file is loaded from the disk by 
>>>>>>>>>> means
>>>>>>>>>> of u-boot and placed into memory. What should happen here when OVMF 
>>>>>>>>>> is
>>>>>>>>>> used? In theory, it has to be configured to generate FDT from QEMU
>>>>>>>>>> config somehow, right? Or pass-through entire FDT from Qemu
>>>>>>>>>> hypervisor?
>>>>>>>>>
>>>>>>>>> It basically passes through the device tree that's generated by QEMU,
>>>>>>>>> yes. However, OVMF defaults changed a while back and it only exposes
>>>>>>>>> ACPI tables instead of DT in newer versions on AArch64 IIRC.
>>>>>>>>>
>>>>>>>>> Maybe something went wrong and they changed them for armv7 as well by
>>>>>>>>> accident?
>>>>>>>>>
>>>>>>>>
>>>>>>>> I use latest version of aarch32 OVMF firmware from 
>>>>>>>> openSUSE:Factory:ARM.
>>>>>>>> Well, then, I suppose, I have to see appropriate EFI driver
>>>>>>>> (FdtClientDxe ? ) in the driver list.
>>>>>>>
>>>>>>> I don't think the fact that the driver is loaded tells you anything.
>>>>>>>
>>>>>>> I assume you can't boot the VM properly? Does grub see the DT table?
>>>>>>> lsefi in grub should show you iirc.
>>>>>>>
>>>>>>> If it doesn't show it, but instead shows ACPI tables, can you try to
>>>>>>> pass -no-acpi to QEMU?
>>>>>>>
>>>>>>
>>>>>> There is nothing FDT-related at GRUB side. This is why I started to
>>>>>> search who is responsible for providing FDT.
>>>>>> -no-acpi also doesn't change anything.
>>>>>>
>>>>>> grub> lsefi
>>>>>
>>>>> Hm, that is the object list. Maybe it was lsefisystab?
>>>>>
>>>>
>>>> Ok, here FDT is present (b1b621d5-...). How can I dump it from grub 
>>>> console?
>>>> If I do it right, then It has correct magic header 0xd00dfeed.
>>>
>>> Looks all green to me then. I guess you actually get into the kernel
>>> then with a working device tree, but just don't see output?
>>>
>>
>> Sure, I've managed to dump and decomile FDT. As far as I don't see any
>> output, something is wrong either with serial port or interrupt
>> controller?
>>
>>
>
> Hm, with qemu debug and grub debug on, I see the following:
>
> Jumping to Linux...
> Taking exception 4 [Data Abort]
> ...from EL1 to EL1
> ...with ESR 0x25/0x9637
> ...with DFSR 0x37 DFAR 0xfffdd000
>

When I use -kernel and -initrd instead of -bios in qemu command line,
then the kernel boots successfully.

>
> --
> 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] openSUSE-Tumbleweed ARM JeOS-efi.armv7

[Matwey V. Kornilov]

2018-01-25 11:11 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
> 2018-01-25 0:28 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>
>>
>> On 24.01.18 20:29, Matwey V. Kornilov wrote:
>>> 2018-01-24 22:05 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>>
>>>>
>>>> On 24.01.18 18:10, Matwey V. Kornilov wrote:
>>>>> 2018-01-24 19:51 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>>>>
>>>>>>
>>>>>> On 24.01.18 17:43, Matwey V. Kornilov wrote:
>>>>>>> 2018-01-24 16:38 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 24.01.18 13:15, Matwey V. Kornilov wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> There is one more thing that is unclear to me now. As far as I
>>>>>>>>> understand there is no other way except FDT to provide hardware layout
>>>>>>>>> for armv7l kernel. Then, who is responsible for FDT loading? As far as
>>>>>>>>> I understand it is grub2 task to load FDT from the table at
>>>>>>>>> b1b621d5-f19c-41a5- And FDT is completely provided by UEFI
>>>>>>>>> firmware. In case of u-boot, dtb file is loaded from the disk by means
>>>>>>>>> of u-boot and placed into memory. What should happen here when OVMF is
>>>>>>>>> used? In theory, it has to be configured to generate FDT from QEMU
>>>>>>>>> config somehow, right? Or pass-through entire FDT from Qemu
>>>>>>>>> hypervisor?
>>>>>>>>
>>>>>>>> It basically passes through the device tree that's generated by QEMU,
>>>>>>>> yes. However, OVMF defaults changed a while back and it only exposes
>>>>>>>> ACPI tables instead of DT in newer versions on AArch64 IIRC.
>>>>>>>>
>>>>>>>> Maybe something went wrong and they changed them for armv7 as well by
>>>>>>>> accident?
>>>>>>>>
>>>>>>>
>>>>>>> I use latest version of aarch32 OVMF firmware from openSUSE:Factory:ARM.
>>>>>>> Well, then, I suppose, I have to see appropriate EFI driver
>>>>>>> (FdtClientDxe ? ) in the driver list.
>>>>>>
>>>>>> I don't think the fact that the driver is loaded tells you anything.
>>>>>>
>>>>>> I assume you can't boot the VM properly? Does grub see the DT table?
>>>>>> lsefi in grub should show you iirc.
>>>>>>
>>>>>> If it doesn't show it, but instead shows ACPI tables, can you try to
>>>>>> pass -no-acpi to QEMU?
>>>>>>
>>>>>
>>>>> There is nothing FDT-related at GRUB side. This is why I started to
>>>>> search who is responsible for providing FDT.
>>>>> -no-acpi also doesn't change anything.
>>>>>
>>>>> grub> lsefi
>>>>
>>>> Hm, that is the object list. Maybe it was lsefisystab?
>>>>
>>>
>>> Ok, here FDT is present (b1b621d5-...). How can I dump it from grub console?
>>> If I do it right, then It has correct magic header 0xd00dfeed.
>>
>> Looks all green to me then. I guess you actually get into the kernel
>> then with a working device tree, but just don't see output?
>>
>
> Sure, I've managed to dump and decomile FDT. As far as I don't see any
> output, something is wrong either with serial port or interrupt
> controller?
>
>

Hm, with qemu debug and grub debug on, I see the following:

Jumping to Linux...
Taking exception 4 [Data Abort]
...from EL1 to EL1
...with ESR 0x25/0x9637
...with DFSR 0x37 DFAR 0xfffdd000


-- 
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] openSUSE-Tumbleweed ARM JeOS-efi.armv7

[Matwey V. Kornilov]

2018-01-25 0:28 GMT+03:00 Alexander Graf <ag...@suse.de>:
>
>
> On 24.01.18 20:29, Matwey V. Kornilov wrote:
>> 2018-01-24 22:05 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>
>>>
>>> On 24.01.18 18:10, Matwey V. Kornilov wrote:
>>>> 2018-01-24 19:51 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>>>
>>>>>
>>>>> On 24.01.18 17:43, Matwey V. Kornilov wrote:
>>>>>> 2018-01-24 16:38 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>>>>>
>>>>>>>
>>>>>>> On 24.01.18 13:15, Matwey V. Kornilov wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> There is one more thing that is unclear to me now. As far as I
>>>>>>>> understand there is no other way except FDT to provide hardware layout
>>>>>>>> for armv7l kernel. Then, who is responsible for FDT loading? As far as
>>>>>>>> I understand it is grub2 task to load FDT from the table at
>>>>>>>> b1b621d5-f19c-41a5- And FDT is completely provided by UEFI
>>>>>>>> firmware. In case of u-boot, dtb file is loaded from the disk by means
>>>>>>>> of u-boot and placed into memory. What should happen here when OVMF is
>>>>>>>> used? In theory, it has to be configured to generate FDT from QEMU
>>>>>>>> config somehow, right? Or pass-through entire FDT from Qemu
>>>>>>>> hypervisor?
>>>>>>>
>>>>>>> It basically passes through the device tree that's generated by QEMU,
>>>>>>> yes. However, OVMF defaults changed a while back and it only exposes
>>>>>>> ACPI tables instead of DT in newer versions on AArch64 IIRC.
>>>>>>>
>>>>>>> Maybe something went wrong and they changed them for armv7 as well by
>>>>>>> accident?
>>>>>>>
>>>>>>
>>>>>> I use latest version of aarch32 OVMF firmware from openSUSE:Factory:ARM.
>>>>>> Well, then, I suppose, I have to see appropriate EFI driver
>>>>>> (FdtClientDxe ? ) in the driver list.
>>>>>
>>>>> I don't think the fact that the driver is loaded tells you anything.
>>>>>
>>>>> I assume you can't boot the VM properly? Does grub see the DT table?
>>>>> lsefi in grub should show you iirc.
>>>>>
>>>>> If it doesn't show it, but instead shows ACPI tables, can you try to
>>>>> pass -no-acpi to QEMU?
>>>>>
>>>>
>>>> There is nothing FDT-related at GRUB side. This is why I started to
>>>> search who is responsible for providing FDT.
>>>> -no-acpi also doesn't change anything.
>>>>
>>>> grub> lsefi
>>>
>>> Hm, that is the object list. Maybe it was lsefisystab?
>>>
>>
>> Ok, here FDT is present (b1b621d5-...). How can I dump it from grub console?
>> If I do it right, then It has correct magic header 0xd00dfeed.
>
> Looks all green to me then. I guess you actually get into the kernel
> then with a working device tree, but just don't see output?
>

Sure, I've managed to dump and decomile FDT. As far as I don't see any
output, something is wrong either with serial port or interrupt
controller?


/dts-v1/;

/ {
interrupt-parent = <0x8001>;
#size-cells = <0x2>;
#address-cells = <0x2>;
compatible = "linux,dummy-virt";

platform@c00 {
interrupt-parent = <0x8001>;
ranges = <0x0 0x0 0xc00 0x200>;
#address-cells = <0x1>;
#size-cells = <0x1>;
compatible = "qemu,platform", "simple-bus";
};

fw-cfg@902 {
dma-coherent;
reg = <0x0 0x902 0x0 0x18>;
compatible = "qemu,fw-cfg-mmio";
};

virtio_mmio@a00 {
dma-coherent;
interrupts = <0x0 0x10 0x1>;
reg = <0x0 0xa00 0x0 0x200>;
compatible = "virtio,mmio";
};

virtio_mmio@a000200 {
dma-coherent;
interrupts = <0x0 0x11 0x1>;
reg = <0x0 0xa000200 0x0 0x200>;
compatible = "virtio,mmio";
};

virtio_mmio@a000400 {
dma-coherent;
interrupts = <0x0 0x12 0x1>;
reg = <0x0 0xa000400 0x0 0x200>;
compatible = "virtio,mmio";
};

virtio_mmio@a000600 {
dma-coherent;
inte

Re: [opensuse-arm] openSUSE-Tumbleweed ARM JeOS-efi.armv7

[Matwey V. Kornilov]

2018-01-24 22:05 GMT+03:00 Alexander Graf <ag...@suse.de>:
>
>
> On 24.01.18 18:10, Matwey V. Kornilov wrote:
>> 2018-01-24 19:51 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>
>>>
>>> On 24.01.18 17:43, Matwey V. Kornilov wrote:
>>>> 2018-01-24 16:38 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>>>
>>>>>
>>>>> On 24.01.18 13:15, Matwey V. Kornilov wrote:
>>>>>> Hi,
>>>>>>
>>>>>> There is one more thing that is unclear to me now. As far as I
>>>>>> understand there is no other way except FDT to provide hardware layout
>>>>>> for armv7l kernel. Then, who is responsible for FDT loading? As far as
>>>>>> I understand it is grub2 task to load FDT from the table at
>>>>>> b1b621d5-f19c-41a5- And FDT is completely provided by UEFI
>>>>>> firmware. In case of u-boot, dtb file is loaded from the disk by means
>>>>>> of u-boot and placed into memory. What should happen here when OVMF is
>>>>>> used? In theory, it has to be configured to generate FDT from QEMU
>>>>>> config somehow, right? Or pass-through entire FDT from Qemu
>>>>>> hypervisor?
>>>>>
>>>>> It basically passes through the device tree that's generated by QEMU,
>>>>> yes. However, OVMF defaults changed a while back and it only exposes
>>>>> ACPI tables instead of DT in newer versions on AArch64 IIRC.
>>>>>
>>>>> Maybe something went wrong and they changed them for armv7 as well by
>>>>> accident?
>>>>>
>>>>
>>>> I use latest version of aarch32 OVMF firmware from openSUSE:Factory:ARM.
>>>> Well, then, I suppose, I have to see appropriate EFI driver
>>>> (FdtClientDxe ? ) in the driver list.
>>>
>>> I don't think the fact that the driver is loaded tells you anything.
>>>
>>> I assume you can't boot the VM properly? Does grub see the DT table?
>>> lsefi in grub should show you iirc.
>>>
>>> If it doesn't show it, but instead shows ACPI tables, can you try to
>>> pass -no-acpi to QEMU?
>>>
>>
>> There is nothing FDT-related at GRUB side. This is why I started to
>> search who is responsible for providing FDT.
>> -no-acpi also doesn't change anything.
>>
>> grub> lsefi
>
> Hm, that is the object list. Maybe it was lsefisystab?
>

Ok, here FDT is present (b1b621d5-...). How can I dump it from grub console?
If I do it right, then It has correct magic header 0xd00dfeed.

grub> dump 0x7ffde000 100
d0 0d fe ed 00 01 10 00 00 00 00 40 00 00 1a 70 00 00 00 30 00 00 00 11 00 00

> lsefisystab
Address: 0x7fc24010
Signature: 5453595320494249 revision: 00020046
Vendor: EDK II, Version=1
11 tables:
0x7f260a10  fc1bcdb0-7d31-49aa-936aa4600d9dd083   CRC32 GUIDED SECTION
EXTRACTION
0x7fc57b58  05ad34ba-6f02-4214-952e4da0398e2bb9   DXE SERVICES
0x7f25e010  7739f24c-93d7-11d4-9a3a0090273fc14d   HOB LIST
0x7fc577e8  4c19049f-4137-4dd3-9c108b97a83ffdfa   MEMORY TYPE INFO
0x7fc58b28  49152e77-1ada-4764-b7a27afefed95e8b   DEBUG IMAGE INFO
0x7fc24f90  a4ee0728-e5d7-4ac5-b21e658ed857e834
0x7ffde000  b1b621d5-f19c-41a5-830bd9152c69aae0
0x7fa86000  eb9d2d31-2d88-11d3-9a160090273fc14d   SMBIOS
0x7fa84000  f2fd1544-9794-4a2c-992ee5bbcf20e394
0x7fa82f90  d719b2cb-3d3a-4596-a3bcdad00e67656f
0x7d773a90  dcfa911d-26eb-469f-a22038b7dc461220

>
> 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] openSUSE-Tumbleweed ARM JeOS-efi.armv7

[Matwey V. Kornilov]

2018-01-24 19:51 GMT+03:00 Alexander Graf <ag...@suse.de>:
>
>
> On 24.01.18 17:43, Matwey V. Kornilov wrote:
>> 2018-01-24 16:38 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>
>>>
>>> On 24.01.18 13:15, Matwey V. Kornilov wrote:
>>>> Hi,
>>>>
>>>> There is one more thing that is unclear to me now. As far as I
>>>> understand there is no other way except FDT to provide hardware layout
>>>> for armv7l kernel. Then, who is responsible for FDT loading? As far as
>>>> I understand it is grub2 task to load FDT from the table at
>>>> b1b621d5-f19c-41a5- And FDT is completely provided by UEFI
>>>> firmware. In case of u-boot, dtb file is loaded from the disk by means
>>>> of u-boot and placed into memory. What should happen here when OVMF is
>>>> used? In theory, it has to be configured to generate FDT from QEMU
>>>> config somehow, right? Or pass-through entire FDT from Qemu
>>>> hypervisor?
>>>
>>> It basically passes through the device tree that's generated by QEMU,
>>> yes. However, OVMF defaults changed a while back and it only exposes
>>> ACPI tables instead of DT in newer versions on AArch64 IIRC.
>>>
>>> Maybe something went wrong and they changed them for armv7 as well by
>>> accident?
>>>
>>
>> I use latest version of aarch32 OVMF firmware from openSUSE:Factory:ARM.
>> Well, then, I suppose, I have to see appropriate EFI driver
>> (FdtClientDxe ? ) in the driver list.
>
> I don't think the fact that the driver is loaded tells you anything.
>
> I assume you can't boot the VM properly? Does grub see the DT table?
> lsefi in grub should show you iirc.
>
> If it doesn't show it, but instead shows ACPI tables, can you try to
> pass -no-acpi to QEMU?
>

There is nothing FDT-related at GRUB side. This is why I started to
search who is responsible for providing FDT.
-no-acpi also doesn't change anything.

grub> lsefi
Handle 0x7f260f90
  loaded image
Handle 0x7f260a90
  decompress
Handle 0x7f25a490
  /MMap(b,1000,1f)/EndEntire
  220e73b6-6bdb-4413-8405-b974b108619a
  device path
  8f644fa9-e850-4db1-9ce2-0b44698e8da4
Handle 0x7f1e9f90
  /UnknownMedia(7)/EndEntire
  220e73b6-6bdb-4413-8405-b974b108619a
  device path
  8f644fa9-e850-4db1-9ce2-0b44698e8da4
Handle 0x7f1e6790
  fc1bcdb0-7d31-49aa-936a-a4600d9dd083
Handle 0x7ef05a10
  bc62157e-3e33-4fec-9920-2d3b36d750df
  loaded image
Handle 0x7ef05590
  fd0f4478-0efd-461d-ba2d-e58c45fd5f5e
  5be40f57-fa68-4610-bbbf-e9c5fcdad365
  13a3f0f6-264a-3ef0-f2e0-dec512342f34
  11b34006-d85b-4d0a-a290-d5a571310ef7
Handle 0x7ef02890
  e11faca0-4710-4c8e-a7a2-01baa2591b4c
  bc62157e-3e33-4fec-9920-2d3b36d750df
  loaded image
Handle 0x7ef02510
  bc62157e-3e33-4fec-9920-2d3b36d750df
  loaded image
Handle 0x7eefab90
  26baccb1-6f42-11d4-bce7-0080c73c8881
Handle 0x7eeffc10
  bc62157e-3e33-4fec-9920-2d3b36d750df
  loaded image
Handle 0x7eeff890
  b7dfb4e1-052f-449f-87be-9818fc91b733
Handle 0x7eeff810
  bc62157e-3e33-4fec-9920-2d3b36d750df
  loaded image
Handle 0x7eeff490
  a46423e3-4617-49f1-b9ff-d1bfa9115839
  94ab2f58-1438-4ef1-9152-18941a3a0e68
Handle 0x7eefcf10
  15853d7c-3ddf-43e0-a1cb-ebf85b8f872c
Handle 0x7eefc990
  bc62157e-3e33-4fec-9920-2d3b36d750df
  loaded image
Handle 0x7eefc410
  /HardwareVendor(f9b94ae2-8ba6-409b-9d56-b9b417f53cb3)[0: ]/EndEntire
  disk
  block
  device path
Handle 0x7eefbe90
  /HardwareVendor(8047db4b-7e9c-4c0c-8ebc-dfbbaacace8f)[0: ]/EndEntire
  disk
  8f644fa9-e850-4db1-9ce2-0b44698e8da4
  block
  device path
Handle 0x7eefb910
  bc62157e-3e33-4fec-9920-2d3b36d750df
  loaded image
Handle 0x7eefb390
  6441f818-6362-4e44-b570-7dba31dd2453
  1e5668e2-8481-11d4-bcf1-0080c73c8881
  af23b340-97b4-4685-8d4f-a3f28169b21d
  cd3d0a05-9e24-437c-a891-1ee053db7638
Handle 0x7eef9a90
  bc62157e-3e33-4fec-9920-2d3b36d750df
  loaded image
Handle 0x7eef9290
  26baccb2-6f42-11d4-bce7-0080c73c8881
Handle 0x7eef9490
  bc62157e-3e33-4fec-9920-2d3b36d750df
  loaded image
Handle 0x7eee6d90
  1a1241e6-8f19-41a9-bc0e-e8ef39e06546
  HII image
  0a8badd5-03b8-4d19-b128-7b8f0edaa596
  HII config routing
  HII database
  HII string
  HII font
Handle 0x7eee6510
  bc62157e-3e33-4fec-9920-2d3b36d750df
  loaded image
Handle 0x7eef3b90
  /HardwareVendor(d3987d4b-971a-435f-8caf-4967eb627241)[0:
]/UART(38400,8,1,1)
/EndEntire
  device path
  serial
Handle 0x7eef3890
  bc62157e-3e33-4fec-9920-2d3b36d750df
  loaded image
Handle 0x7eef3290
  device path from text
  device path to text
  device path utilities
Handle 0x7eef3490
  bc62157e-3e33-4fec-9920-2d3b36d750df
  loaded image
Handle 0x7eef2b10
  480f8ae9-0c46-4aa9-bc89-db9fba619806
Handle 0x7eef2a90
  bc62157e-3e33-4fec-9920-2d3b36d750df
  loaded image
Handle 0x7eef2510
  /HardwareVendor(837dca9e-e874-4d82-b2

Re: [opensuse-arm] openSUSE-Tumbleweed ARM JeOS-efi.armv7

[Matwey V. Kornilov]

2018-01-24 19:43 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
> 2018-01-24 16:38 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>
>>
>> On 24.01.18 13:15, Matwey V. Kornilov wrote:
>>> Hi,
>>>
>>> There is one more thing that is unclear to me now. As far as I
>>> understand there is no other way except FDT to provide hardware layout
>>> for armv7l kernel. Then, who is responsible for FDT loading? As far as
>>> I understand it is grub2 task to load FDT from the table at
>>> b1b621d5-f19c-41a5- And FDT is completely provided by UEFI
>>> firmware. In case of u-boot, dtb file is loaded from the disk by means
>>> of u-boot and placed into memory. What should happen here when OVMF is
>>> used? In theory, it has to be configured to generate FDT from QEMU
>>> config somehow, right? Or pass-through entire FDT from Qemu
>>> hypervisor?
>>
>> It basically passes through the device tree that's generated by QEMU,
>> yes. However, OVMF defaults changed a while back and it only exposes
>> ACPI tables instead of DT in newer versions on AArch64 IIRC.
>>
>> Maybe something went wrong and they changed them for armv7 as well by
>> accident?
>>
>
> I use latest version of aarch32 OVMF firmware from openSUSE:Factory:ARM.
> Well, then, I suppose, I have to see appropriate EFI driver
> (FdtClientDxe ? ) in the driver list.
>
> Shell> drivers
> T   D
> D   Y C I
> R   P F A
> V  VERSION  E G G #D #C DRIVER NAME IMAGE NAME
> ==  = = = == == === ==
> 6B 000A D - -  1  - Platform Console Management Driver
> ConPlatformDxe
> 6C 000A D - -  1  - Platform Console Management Driver
> ConPlatformDxe
> 6D 000A B - -  1  1 Console Splitter Driver
> ConSplitterDxe
> 6E 000A ? - -  -  - Console Splitter Driver
> ConSplitterDxe
> 6F 000A ? - -  -  - Console Splitter Driver
> ConSplitterDxe
> 70 000A B - -  1  1 Console Splitter Driver
> ConSplitterDxe
> 71 000A B - -  1  1 Console Splitter Driver
> ConSplitterDxe
> 75 000A ? - -  -  - Graphics Console Driver
> GraphicsConsoleDxe
> 76 000A B - -  1  1 Serial Terminal Driver
> TerminalDxe
> 77 000A D - -  1  - Generic Disk I/O Driver DiskIoDxe
> 78 000B ? - -  -  - Partition Driver(MBR/GPT/El Torito)
> PartitionDxe
> 79 000A ? - -  -  - FAT File System Driver  Fat
> 7C 0010 ? - -  -  - UDF File System Driver  UdfDxe
> 7D 0010 ? - -  -  - Virtio Block Driver
> VirtioBlkDxe
> 7E 0010 B - -  1  1 Virtio Network Driver
> VirtioNetDxe
> 7F 0010 ? - -  -  - Virtio SCSI Host Driver VirtioScsiDxe
> 80 0010 ? - -  -  - Virtio Random Number Generator Driv VirtioRngDxe
> 81 000A B - -  1  1 ARP Network Service Driver  ArpDxe
> 82 000A B - -  1  1 DHCP Protocol DriverDhcp4Dxe
> 83 000A B - -  2 10 IP4 Network Service Driver  Ip4Dxe
> 84 000A B - -  1  2 MNP Network Service Driver  MnpDxe
> 85 000A B - -  1  1 VLAN Configuration Driver   VlanConfigDxe
> 86 000A B - -  2  2 MTFTP4 Network Service  Mtftp4Dxe
> 87 000A B - -  2  2 Tcp Network Service Driver  Tcp4Dxe
> 88 000A B - -  6 10 UDP Network Service Driver  Udp4Dxe
> 89 000A D - -  6  - UEFI PXE Base Code Driver   UefiPxe4BcDxe
> 8A 000A D - -  1  - iSCSI DriverIScsi4Dxe
> 8C 000A ? - -  -  - SCSI Bus Driver ScsiBus
> 8D 000A ? - -  -  - Scsi Disk DriverScsiDisk
> 8E 000A B - -  1  2 PCI Bus Driver  PciBusDxe
> 90 0010 D - -  1  - Virtio PCI Driver   VirtioPciDeviceDxe
> 91 0010 ? - -  -  - Virtio 1.0 PCI Driver   Virtio10
> 92 0010 ? - -  -  - Virtio GPU Driver   VirtioGpuDxe
> 93 0020 ? - -  -  - Usb Uhci Driver UhciDxe
> 94 0030 ? - -  -  - Usb Ehci Driver EhciDxe
> 95 0030 ? - -  -  - Usb Xhci Driver XhciDxe
> 96 000A ? - -  -  - Usb Bus Driver  UsbBusDxe
> 97 000A ? - -  -  - Usb Keyboard Driver UsbKbDxe
> 98 0011 ? - -  -  - Usb Mass Storage Driver UsbMassStorageDxe
>

Linaro's image has the same behavior.

-- 
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] openSUSE-Tumbleweed ARM JeOS-efi.armv7

[Matwey V. Kornilov]

2018-01-24 16:38 GMT+03:00 Alexander Graf <ag...@suse.de>:
>
>
> On 24.01.18 13:15, Matwey V. Kornilov wrote:
>> Hi,
>>
>> There is one more thing that is unclear to me now. As far as I
>> understand there is no other way except FDT to provide hardware layout
>> for armv7l kernel. Then, who is responsible for FDT loading? As far as
>> I understand it is grub2 task to load FDT from the table at
>> b1b621d5-f19c-41a5- And FDT is completely provided by UEFI
>> firmware. In case of u-boot, dtb file is loaded from the disk by means
>> of u-boot and placed into memory. What should happen here when OVMF is
>> used? In theory, it has to be configured to generate FDT from QEMU
>> config somehow, right? Or pass-through entire FDT from Qemu
>> hypervisor?
>
> It basically passes through the device tree that's generated by QEMU,
> yes. However, OVMF defaults changed a while back and it only exposes
> ACPI tables instead of DT in newer versions on AArch64 IIRC.
>
> Maybe something went wrong and they changed them for armv7 as well by
> accident?
>

I use latest version of aarch32 OVMF firmware from openSUSE:Factory:ARM.
Well, then, I suppose, I have to see appropriate EFI driver
(FdtClientDxe ? ) in the driver list.

Shell> drivers
T   D
D   Y C I
R   P F A
V  VERSION  E G G #D #C DRIVER NAME IMAGE NAME
==  = = = == == === ==
6B 000A D - -  1  - Platform Console Management Driver
ConPlatformDxe
6C 000A D - -  1  - Platform Console Management Driver
ConPlatformDxe
6D 000A B - -  1  1 Console Splitter Driver
ConSplitterDxe
6E 000A ? - -  -  - Console Splitter Driver
ConSplitterDxe
6F 000A ? - -  -  - Console Splitter Driver
ConSplitterDxe
70 000A B - -  1  1 Console Splitter Driver
ConSplitterDxe
71 000A B - -  1  1 Console Splitter Driver
ConSplitterDxe
75 000A ? - -  -  - Graphics Console Driver
GraphicsConsoleDxe
76 000A B - -  1  1 Serial Terminal Driver
TerminalDxe
77 000A D - -  1  - Generic Disk I/O Driver DiskIoDxe
78 000B ? - -  -  - Partition Driver(MBR/GPT/El Torito)
PartitionDxe
79 000A ? - -  -  - FAT File System Driver  Fat
7C 0010 ? - -  -  - UDF File System Driver  UdfDxe
7D 0010 ? - -  -  - Virtio Block Driver
VirtioBlkDxe
7E 0010 B - -  1  1 Virtio Network Driver
VirtioNetDxe
7F 0010 ? - -  -  - Virtio SCSI Host Driver VirtioScsiDxe
80 0010 ? - -  -  - Virtio Random Number Generator Driv VirtioRngDxe
81 000A B - -  1  1 ARP Network Service Driver  ArpDxe
82 000A B - -  1  1 DHCP Protocol DriverDhcp4Dxe
83 000A B - -  2 10 IP4 Network Service Driver  Ip4Dxe
84 000A B - -  1  2 MNP Network Service Driver  MnpDxe
85 000A B - -  1  1 VLAN Configuration Driver   VlanConfigDxe
86 000A B - -  2  2 MTFTP4 Network Service  Mtftp4Dxe
87 000A B - -  2  2 Tcp Network Service Driver  Tcp4Dxe
88 000A B - -  6 10 UDP Network Service Driver  Udp4Dxe
89 000A D - -  6  - UEFI PXE Base Code Driver   UefiPxe4BcDxe
8A 000A D - -  1  - iSCSI DriverIScsi4Dxe
8C 000A ? - -  -  - SCSI Bus Driver ScsiBus
8D 000A ? - -  -  - Scsi Disk DriverScsiDisk
8E 000A B - -  1  2 PCI Bus Driver  PciBusDxe
90 0010 D - -  1  - Virtio PCI Driver   VirtioPciDeviceDxe
91 0010 ? - -  -  - Virtio 1.0 PCI Driver   Virtio10
92 0010 ? - -  -  - Virtio GPU Driver   VirtioGpuDxe
93 0020 ? - -  -  - Usb Uhci Driver UhciDxe
94 0030 ? - -  -  - Usb Ehci Driver EhciDxe
95 0030 ? - -  -  - Usb Xhci Driver XhciDxe
96 000A ? - -  -  - Usb Bus Driver  UsbBusDxe
97 000A ? - -  -  - Usb Keyboard Driver     UsbKbDxe
98 00000011 ? - -  -  - Usb Mass Storage Driver UsbMassStorageDxe

-- 
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] openSUSE-Tumbleweed ARM JeOS-efi.armv7

[Matwey V. Kornilov]

Hi,

There is one more thing that is unclear to me now. As far as I
understand there is no other way except FDT to provide hardware layout
for armv7l kernel. Then, who is responsible for FDT loading? As far as
I understand it is grub2 task to load FDT from the table at
b1b621d5-f19c-41a5- And FDT is completely provided by UEFI
firmware. In case of u-boot, dtb file is loaded from the disk by means
of u-boot and placed into memory. What should happen here when OVMF is
used? In theory, it has to be configured to generate FDT from QEMU
config somehow, right? Or pass-through entire FDT from Qemu
hypervisor?

2017-11-08 23:07 GMT+03:00 Alexander Graf <ag...@suse.de>:
>
>
> On 08.11.17 21:00, Matwey V. Kornilov wrote:
>> Hi,
>>
>> I am trying to run
>> openSUSE-Tumbleweed-ARM-JeOS-efi.armv7l-2017.10.29-Build1.7.raw
>> using qemu.
>>
>> When I use qemu-system-aarch64 with 64-bit UEFI code
>> aavmf-aarch64-code.bin then the only I see is the EFI console:
>>
>> UEFI Interactive Shell v2.287477C2-69C7-11D2-8E39-00A0C969723B B8F1C820
>>
>> EDK IIlProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA B8F1FF18
>>
>> UEFI v2.60 (EDK II, 0x0001)008-7F9B-4F30-87AC-60C9FEF5DA4E B8348710
>>
>> Mapping table
>>   FS0: Alias(s):HD1a0b:;BLK2:
>>
>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004)
>>  BLK5: Alias(s):
>>   VenHw(F9B94AE2-8BA6-409B-9D56-B9B417F53CB3)
>>  BLK0: Alias(s):
>>   VenHw(8047DB4B-7E9C-4C0C-8EBC-DFBBAACACE8F)
>>  BLK1: Alias(s):
>>
>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)
>>  BLK3: Alias(s):
>>
>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(2,GPT,3DF8DD35-94BC-4FF0-B74C-12853D4B1811,0x65000,0x83004)
>>  BLK4: Alias(s):
>>
>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(3,GPT,38C4AA8C-4A7F-49C4-BCFD-6C2C755496BD,0xE8800,0x3DE781)
>>
>> Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
>> FSOpen: Open '\startup.nsh' Success
>> FSOpen: Open '\startup.nsh' Success
>> FSOpen: Open '\startup.nsh' Success
>> Shell> bootarm
>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>> [Security] 3rd party image[0] can be loaded after EndOfDxe:
>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004)/\efi\boot\bootarm.EFI.
>> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B B8EDE440
>> Unloading driver at 0x000
>> Shell> Error Status: Unsupported (line number 1)
>>
>>
>> As far as I understand, 64-bit Qemu UEFI code doesn't expect to see and
>> run 32-bit EFI executable.
>
> Correct, as far as UEFI is concerned, a 32bit ARM binary could as well
> be a MIPS one ;). It's a different, unsupported platform for it.
>
>> When I try to use qemu-uefi-aarch32.bin as firmware, then I see the
>> following:
>>
>> Initialization of device cfi.pflash01 failed: failed to read the initial
>> flash content
>>
>> As far as I understand, qemu-uefi-aarch32.bin is in wrong format, but
>> there are no other files in ovfm rpm package.
>
> Which ovmf package are you looking at? I'm not sure we properly package
> OVMF for AArch32. But you can always try with the Linaro built ones :)
>
> http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/latest/QEMU-ARM/RELEASE_GCC5/
>
>> What is the proper way to run JeOS-efi.armv7? Is it supposed to work in
>> qemu?
>
> It should work, yes. It should also work on any platform that has distro
> boot enabled and runs with recent U-Boot.
>
>
> 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

[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 <afaer...@suse.de>:
> Am 02.01.2018 um 16:59 schrieb Matwey V. Kornilov:
>> 2018-01-02 18:27 GMT+03:00 Andreas Färber <afaer...@suse.de>:
>>> Am 01.01.2018 um 16:20 schrieb Matwey V. Kornilov:
>>>> Why didn't we allocate separate GPT partition for each bootloader
>>>> image? It seems to be generic way to denote that specific place at SD
>>>> card is allocated and used by something.
>>>
>>> Kiwi only supports a few partitioning schemes, it does not allow to add
>>> random other partitions AFAIK. Every scheme needs to be defined in the
>>> XML Schema and needs a matching implementation in Kiwi.
>>>
>>> Have you checked out Alex' new non-Kiwi approach for RPi3 and Pine64?
>>
>> Nope. Where can I find it?
>>
>> https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:Pine64
>>
>> This one?
>
> https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:Pine64/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

[Matwey V. Kornilov]

2018-01-02 18:27 GMT+03:00 Andreas Färber <afaer...@suse.de>:
> Am 01.01.2018 um 16:20 schrieb Matwey V. Kornilov:
>> 2017-09-02 13:25 GMT+03:00 Andreas Färber <afaer...@suse.de>:
>>> Hi,
>>>
>>> Am 02.09.2017 um 12:06 schrieb Matwey V. Kornilov:
>>>> 1. Tools from https://github.com/rockchip-linux/rkbin are required to
>>>> prepare u-boot binary to be deployed into sd-card. The tools are
>>>> permitted to be redistributed, but they are x86_64-only binary blobs.
>>>> I think we could package them in RPM package and wrap them using
>>>> qemu-linux-x86_64 to execute them at JeOS building phase (at aarch64
>>>> architecture).
>>>
>>> Negative. Same topic came up for Amlogic, and I had to develop the
>>> native Open Source meson-tools instead.
>>>
>>> For creating a JeOS image we need to use U-Boot SPL, which as I already
>>> pointed out should avoid all those binary-only x86 tools.
>>>
>>> If that is not working yet (you did not say), then we can just document
>>> the x86-only steps to keep them out of OBS.
>>>
>>>> 2. bootloader are required to be placed at +16MB offset from the
>>>> beginning of SD card. We have to find a way to specify KIWI to place
>>>> EFI partition not at 2048sector as default.
>>>
>>> Yousaf gave a presentation on how to accomplish that for RK3399.
>>>
>>> If this reservation is implemented, then similar to my JeOS-nanopik2
>>> image we could just leave out U-Boot and give users Wiki instructions on
>>> how to place U-Boot there themselves.
>>
>> Why didn't we allocate separate GPT partition for each bootloader
>> image? It seems to be generic way to denote that specific place at SD
>> card is allocated and used by something.
>
> Kiwi only supports a few partitioning schemes, it does not allow to add
> random other partitions AFAIK. Every scheme needs to be defined in the
> XML Schema and needs a matching implementation in Kiwi.
>
> Have you checked out Alex' new non-Kiwi approach for RPi3 and Pine64?

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

[Matwey V. Kornilov]

2018-01-01 18:20 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
> 2017-09-02 13:25 GMT+03:00 Andreas Färber <afaer...@suse.de>:
>> Hi,
>>
>> Am 02.09.2017 um 12:06 schrieb Matwey V. Kornilov:
>>> 1. Tools from https://github.com/rockchip-linux/rkbin are required to
>>> prepare u-boot binary to be deployed into sd-card. The tools are
>>> permitted to be redistributed, but they are x86_64-only binary blobs.
>>> I think we could package them in RPM package and wrap them using
>>> qemu-linux-x86_64 to execute them at JeOS building phase (at aarch64
>>> architecture).
>>
>> Negative. Same topic came up for Amlogic, and I had to develop the
>> native Open Source meson-tools instead.
>>
>> For creating a JeOS image we need to use U-Boot SPL, which as I already
>> pointed out should avoid all those binary-only x86 tools.
>>
>> If that is not working yet (you did not say), then we can just document
>> the x86-only steps to keep them out of OBS.
>>
>>> 2. bootloader are required to be placed at +16MB offset from the
>>> beginning of SD card. We have to find a way to specify KIWI to place
>>> EFI partition not at 2048sector as default.
>>
>> Yousaf gave a presentation on how to accomplish that for RK3399.
>>
>> If this reservation is implemented, then similar to my JeOS-nanopik2
>> image we could just leave out U-Boot and give users Wiki instructions on
>> how to place U-Boot there themselves.
>
> Why didn't we allocate separate GPT partition for each bootloader
> image? It seems to be generic way to denote that specific place at SD
> card is allocated and used by something.

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

[Matwey V. Kornilov]

2017-09-02 13:25 GMT+03:00 Andreas Färber <afaer...@suse.de>:
> Hi,
>
> Am 02.09.2017 um 12:06 schrieb Matwey V. Kornilov:
>> 1. Tools from https://github.com/rockchip-linux/rkbin are required to
>> prepare u-boot binary to be deployed into sd-card. The tools are
>> permitted to be redistributed, but they are x86_64-only binary blobs.
>> I think we could package them in RPM package and wrap them using
>> qemu-linux-x86_64 to execute them at JeOS building phase (at aarch64
>> architecture).
>
> Negative. Same topic came up for Amlogic, and I had to develop the
> native Open Source meson-tools instead.
>
> For creating a JeOS image we need to use U-Boot SPL, which as I already
> pointed out should avoid all those binary-only x86 tools.
>
> If that is not working yet (you did not say), then we can just document
> the x86-only steps to keep them out of OBS.
>
>> 2. bootloader are required to be placed at +16MB offset from the
>> beginning of SD card. We have to find a way to specify KIWI to place
>> EFI partition not at 2048sector as default.
>
> Yousaf gave a presentation on how to accomplish that for RK3399.
>
> If this reservation is implemented, then similar to my JeOS-nanopik2
> image we could just leave out U-Boot and give users Wiki instructions on
> how to place U-Boot there themselves.

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

>
> You had forgotten to create an HCL Wiki page - I stubbed one out:
>
> https://en.opensuse.org/HCL:Rock64
>
> Regards,
> Andreas
>
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)



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

Re: [opensuse-arm] rock64

[Matwey V. Kornilov]

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 <matwey.korni...@gmail.com>:
> Well, I see the patch series for enabling SPL for rk3328.
> Unfortunately, both my Rock64-s are in usage (with Debian ;)) and
> third is broken :(
> So, I cannot give it a try just now :(
>
> https://patchwork.ozlabs.org/cover/830462/
>
> 2017-08-25 22:41 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>> I'll try to figure out how to use SPL u-boot instead.
>>
>> 2017-08-25 22:16 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>>> It seems that the following tools are binary only:
>>> https://github.com/rockchip-linux/rkbin/tree/master/tools
>>> They are required to convert u-boot to proprietary loader known format.
>>> Proprietary loader is required because there is no (yet?) support for
>>> SPL in u-boot for rk3328.
>>> The tools are also x86_64 only, so I wonder how could they be used in
>>> OBS to produce package for u-boot image in deployable format.
>>>
>>>
>>> 2017-08-24 20:49 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>>>> 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 <mbrug...@suse.com>:
>>>>>
>>>>>
>>>>> On 08/12/2017 12:02 PM, Matwey V. Kornilov wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I will receive my rock64 board soon.
>>>>>>
>>>>>> https://www.pine64.org/?page_id=7147
>>>>>>
>>>>>> I would like to run some openSUSE on it. There are no upstream support
>>>>>> but lets see what we could do.
>>>>>>
>>>>>
>>>>> A patch is on it's way. I might show up in v4.14:
>>>>> https://www.spinics.net/lists/arm-kernel/msg599638.html
>>>>>
>>>>> Only missing and blocking bit is the pmic support:
>>>>> http://www.spinics.net/lists/devicetree/msg188756.html
>>>>>
>>>>> Regarding u-boot support it still needs the first stage loader. You might
>>>>> want to check with this hacked up tree:
>>>>> https://github.com/mmind/u-boot-rockchip/commits/netboots/rock64
>>>>>
>>>>> Have fun!
>>>>> Matthias
>>>>
>>>>
>>>>
>>>> --
>>>> With best regards,
>>>> Matwey V. Kornilov
>>>
>>>
>>>
>>> --
>>> With best regards,
>>> Matwey V. Kornilov
>>
>>
>>
>> --
>> With best regards,
>> Matwey V. Kornilov
>
>
>
> --
> With best regards,
> Matwey V. Kornilov



-- 
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

[opensuse-arm] Re: Cloud ARM servers

[Matwey V. Kornilov]

10.12.2017 01:59, Bill Merriam пишет:
> I discovered today that a hosting provider in Europe offers very cheap
> ARMv7 and ARMv8 cloud servers.
> 
> https://www.scaleway.com/
> 
> The following observations are from a few hours of testing and may not
> be correct.
> 
> It appears the ARM servers are NOT virtualized but run on special
> miniature servers.   The ARMv7 uses a Marvell 385 SOC and the ARMv8 uses
> a Cavium SOC.  Marvell is in the process of buying Cavium.
> 
> Opensuse does not generally appear among the offered distributions.  The
> exception to this was opensuse 13.2 on the ARMv7 system.  I was able to
> upgrade it to 42.3 but they don't use the kernel from my image.  I guess
> they need a custom kernel.  Their kernel has many limitations.  It
> doesn't support iptables so you can't have a firewall.
> 
> I am hoping someone can convince them to offer an ARMv8 Leap 42.3 with a
> decent kernel.

It is common issue. IMO openSUSE is not popular for cloud services.

> 
> Bill
> 


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

[opensuse-arm] Re: EspressoBin

[Matwey V. Kornilov]

On 27.11.2017 02:49, Freek de Kruijf wrote:
> Op zondag 26 november 2017 18:52:01 CET schreef Matwey V. Kornilov:
>> Currently, I have two issues. MAC addr are different after each reboot.
>> Link auto-detection either not work or not supposed to work.
> 
> You can edit a file /etc/systemd/system/macspoof@.service with following 
> content:
> [Unit]
> Description=MAC Address Change %I
> Wants=network-pre.target
> Before=network-pre.target
> BindsTo=sys-subsystem-net-devices-%i.device
> After=sys-subsystem-net-devices-%i.device
> 
> [Service]
> Type=oneshot
> ExecStart=/usr/sbin/ip link set dev %i address 
> ExecStart=/usr/sbin/ip link set dev %i up
> 
> [Install]
> WantedBy=multi-user.target
> 
> Where you enter a MAC address at  you saw previously.
> After that you give the command (on one line) in case the device name for the 
> Ethernet device is eth0:
> ln -s /etc/systemd/system/macspoof@.service /mnt/ll/etc/systemd/system/multi-
> user.target.wants/macspoof@eth0.service
> 

It seems that MAC issue is related to u-boot. When I touch network
commands in u-boot console, then MAC addr is set from ${ethaddr}
variable, which is read from EEPROM (where it is a right place to store
MAC actually).

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

[opensuse-arm] Re: EspressoBin

[Matwey V. Kornilov]

Currently, I have two issues. MAC addr are different after each reboot.
Link auto-detection either not work or not supposed to work.

26.11.2017 15:46, Matwey V. Kornilov пишет:
> 
> gpio_regulator has to be included into initrd to make mmc working.
> 
> 25.11.2017 21:27, Matwey V. Kornilov пишет:
>>
>> Hm. It refuses to boot after KIWI deployed. For some reason
>> dracut-generated initrd failed to obtain  /dev/mmcblk? devices.
>>
>> 14.11.2017 15:05, Matwey V. Kornilov пишет:
>>> Now It is booting.
>>>
>>> Now, I cannot figure out how to configure networking:
>>>
>>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
>>> group default qlen 532
>>> link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff
>>> inet6 fe80::251:82ff:fe11:2200/64 scope link
>>>valid_lft forever preferred_lft forever
>>> 3: wan@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
>>> group default qlen 1000
>>> link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff
>>> 4: lan0@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
>>> group default qlen 1000
>>> link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff
>>> 5: lan1@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
>>> group default qlen 1000
>>> link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff
>>>
>>> 2017-11-14 14:48 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>>>> mSD card is enabled in kernel dtb file only in 4.14.
>>>>
>>>> https://github.com/torvalds/linux/commit/9be778f6c6d8f90ff2fad88d1770e2a7843aee43
>>>>
>>>> 2017-11-14 14:09 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>>>>> Well, 4.13.12-1-default has issues with mmc-driver, so KIWI cannot
>>>>> find boot device.
>>>>>
>>>>> [9.651177] sdhci: Secure Digital Host Controller Interface driver
>>>>> [    9.651182] sdhci: Copyright(c) Pierre Ossman
>>>>> [9.652213] sdhci-pltfm: SDHCI platform and OF driver helper
>>>>> [9.655798] xenon-sdhci d00d.sdhci: failed to get IRQ number
>>>>> [9.655809] xenon-sdhci d00d.sdhci: sdhci_pltfm_init failed -6
>>>>>
>>>>> I will see, if different version of dtb file helps.
>>>>>
>>>>> --
>>>>> 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

[opensuse-arm] Re: EspressoBin

[Matwey V. Kornilov]

gpio_regulator has to be included into initrd to make mmc working.

25.11.2017 21:27, Matwey V. Kornilov пишет:
> 
> Hm. It refuses to boot after KIWI deployed. For some reason
> dracut-generated initrd failed to obtain  /dev/mmcblk? devices.
> 
> 14.11.2017 15:05, Matwey V. Kornilov пишет:
>> Now It is booting.
>>
>> Now, I cannot figure out how to configure networking:
>>
>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
>> group default qlen 532
>> link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff
>> inet6 fe80::251:82ff:fe11:2200/64 scope link
>>valid_lft forever preferred_lft forever
>> 3: wan@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
>> group default qlen 1000
>> link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff
>> 4: lan0@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
>> group default qlen 1000
>> link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff
>> 5: lan1@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
>> group default qlen 1000
>> link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff
>>
>> 2017-11-14 14:48 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>>> mSD card is enabled in kernel dtb file only in 4.14.
>>>
>>> https://github.com/torvalds/linux/commit/9be778f6c6d8f90ff2fad88d1770e2a7843aee43
>>>
>>> 2017-11-14 14:09 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>>>> Well, 4.13.12-1-default has issues with mmc-driver, so KIWI cannot
>>>> find boot device.
>>>>
>>>> [9.651177] sdhci: Secure Digital Host Controller Interface driver
>>>> [9.651182] sdhci: Copyright(c) Pierre Ossman
>>>> [9.652213] sdhci-pltfm: SDHCI platform and OF driver helper
>>>> [9.655798] xenon-sdhci d00d.sdhci: failed to get IRQ number
>>>> [9.655809] xenon-sdhci d00d.sdhci: sdhci_pltfm_init failed -6
>>>>
>>>> I will see, if different version of dtb file helps.
>>>>
>>>> --
>>>> 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

[opensuse-arm] Re: EspressoBin

[Matwey V. Kornilov]

Hm. It refuses to boot after KIWI deployed. For some reason
dracut-generated initrd failed to obtain  /dev/mmcblk? devices.

14.11.2017 15:05, Matwey V. Kornilov пишет:
> Now It is booting.
> 
> Now, I cannot figure out how to configure networking:
> 
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
> group default qlen 532
> link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff
> inet6 fe80::251:82ff:fe11:2200/64 scope link
>valid_lft forever preferred_lft forever
> 3: wan@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
> group default qlen 1000
> link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff
> 4: lan0@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
> group default qlen 1000
> link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff
> 5: lan1@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
> group default qlen 1000
> link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff
> 
> 2017-11-14 14:48 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>> mSD card is enabled in kernel dtb file only in 4.14.
>>
>> https://github.com/torvalds/linux/commit/9be778f6c6d8f90ff2fad88d1770e2a7843aee43
>>
>> 2017-11-14 14:09 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>>> Well, 4.13.12-1-default has issues with mmc-driver, so KIWI cannot
>>> find boot device.
>>>
>>> [9.651177] sdhci: Secure Digital Host Controller Interface driver
>>> [9.651182] sdhci: Copyright(c) Pierre Ossman
>>> [9.652213] sdhci-pltfm: SDHCI platform and OF driver helper
>>> [9.655798] xenon-sdhci d00d.sdhci: failed to get IRQ number
>>> [9.655809] xenon-sdhci d00d.sdhci: sdhci_pltfm_init failed -6
>>>
>>> I will see, if different version of dtb file helps.
>>>
>>> --
>>> 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] Re: EspressoBin

[Matwey V. Kornilov]

Now It is booting.

Now, I cannot figure out how to configure networking:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
group default qlen 532
link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff
inet6 fe80::251:82ff:fe11:2200/64 scope link
   valid_lft forever preferred_lft forever
3: wan@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
group default qlen 1000
link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff
4: lan0@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
group default qlen 1000
link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff
5: lan1@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
group default qlen 1000
link/ether 00:51:82:11:22:00 brd ff:ff:ff:ff:ff:ff

2017-11-14 14:48 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
> mSD card is enabled in kernel dtb file only in 4.14.
>
> https://github.com/torvalds/linux/commit/9be778f6c6d8f90ff2fad88d1770e2a7843aee43
>
> 2017-11-14 14:09 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>> Well, 4.13.12-1-default has issues with mmc-driver, so KIWI cannot
>> find boot device.
>>
>> [9.651177] sdhci: Secure Digital Host Controller Interface driver
>> [9.651182] sdhci: Copyright(c) Pierre Ossman
>> [9.652213] sdhci-pltfm: SDHCI platform and OF driver helper
>> [9.655798] xenon-sdhci d00d.sdhci: failed to get IRQ number
>> [9.655809] xenon-sdhci d00d.sdhci: sdhci_pltfm_init failed -6
>>
>> I will see, if different version of dtb file helps.
>>
>> --
>> 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] Re: EspressoBin

[Matwey V. Kornilov]

mSD card is enabled in kernel dtb file only in 4.14.

https://github.com/torvalds/linux/commit/9be778f6c6d8f90ff2fad88d1770e2a7843aee43

2017-11-14 14:09 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
> Well, 4.13.12-1-default has issues with mmc-driver, so KIWI cannot
> find boot device.
>
> [9.651177] sdhci: Secure Digital Host Controller Interface driver
> [9.651182] sdhci: Copyright(c) Pierre Ossman
> [9.652213] sdhci-pltfm: SDHCI platform and OF driver helper
> [9.655798] xenon-sdhci d00d.sdhci: failed to get IRQ number
> [9.655809] xenon-sdhci d00d.sdhci: sdhci_pltfm_init failed -6
>
> I will see, if different version of dtb file helps.
>
> --
> 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

[opensuse-arm] Re: [aarch64] Tumbleweed repositories is outdated

[Matwey V. Kornilov]

13.11.2017 13:52, Manu Maier пишет:
> The last images are from the 17-Jun-2017
> http://download.opensuse.org/ports/aarch64/tumbleweed/images/?C=M;O=D

osc getbinaries openSUSE:Factory:ARM JeOS:JeOS-efi.aarch64 factory aarch64

downloads way newer images.

> 
> and the latest packages from 21-Sep-2017
> http://download.opensuse.org/ports/aarch64/tumbleweed/repo/oss/suse/aarch64/?C=M;O=D
> 
> The repositories should be updated.
> 
> 
> Greetings,
> Manu
> 


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

Re: [opensuse-arm] Re: EspressoBin

[Matwey V. Kornilov]

2017-11-12 19:57 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
> 2017-10-22 10:36 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>> 2017-10-22 9:31 GMT+03:00 Rick Ashford <rick.ashf...@suse.com>:
>>> There is a great thread on the Armbian forum about the EspressoBin, and it
>>> helped me get things up and running with Tumbleweed.
>>>
>>> One of the guys there has a public Dropbox link that includes their images
>>> for flashing the u-boot loader:
>>> https://www.dropbox.com/sh/kmgmo1uubhcczx5/AAAYEvTIFxpBr0dHG2QcapTza?dl=0
>>>
>>> The thread:
>>> https://forum.armbian.com/index.php?/topic/4089-espressobin-support-development-efforts/=4
>>>
>>> With their boot loader I was able to finally use BTRFS images as well as PXE
>>> boot. It also has an EFI load function in the help that I need to get around
>>> to trying.
>>
>> Well, If armian u-boot is able to boot our standard EFI-Grub JeOS,
>> then we can recommend to use it with openSUSE and don't reinvent the
>> wheel.
>
> Well, I've just managed to build marvell u-boot
> 2017.03-armada-17.10.1-g440395a and run it from SATA drive. I also
> started EFI grub using this bootloader.
> Also, it appeared that placing loader to LBA0 is not necessary, the
> loader can be placed to separate partition with 0x4d type.
>
> Unfortunately, marvell u-boot config is only use tftp in bootcmd. So,
> I think the next step is to try upstream u-boot.

In upstream u-boot, sata/scsi doesn't work. And distro boot cmd is not
integrated into upstream config.

>
>>
>>>
>>> Rick Ashford
>>> Sales Engineering Manager - West
>>> SUSE Linux
>>> rick.ashf...@suse.com
>>> Office:  512-782-4318
>>> Mobile: 512-731-3035
>>>
>>> On Oct 21, 2017, at 12:32 PM, Matwey V. Kornilov <matwey.korni...@gmail.com>
>>> wrote:
>>>
>>> 2017-10-21 19:47 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>>>
>>> 2017-10-21 19:35 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>>>
>>> 2017-10-20 18:02 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>>>
>>> 2017-10-20 17:37 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>
>>>
>>>
>>> On 20.10.17 16:21, Matwey V. Kornilov wrote:
>>>
>>> 20.10.2017 17:12, Alexander Graf пишет:
>>>
>>>
>>>
>>> On 20.10.17 13:57, Matwey V. Kornilov wrote:
>>>
>>> Hi,
>>>
>>>
>>> I've just received EspressoBin 1G. Any success stories how to run openSUSE?
>>>
>>>
>>>
>>> I think you'll basically have to somehow flash a working U-Boot with
>>>
>>> distro boot onto it and then just dd the tumbleweed/42.3 iso onto a usb
>>>
>>> stick and cross your fingers that gets you to a point where you can
>>>
>>> install :)
>>>
>>>
>>> It has microsd card, I think it should be able to boot from sd, no?
>>>
>>> I also need to to find serial console pins on the board :)
>>>
>>>
>>> There seems to be a lengthy discussion on the mailing list. I guess you
>>>
>>> can select the boot device using DIP switches though?
>>>
>>>
>>> Yes, I can. I think it is preferred way. Need to find expected layout
>>>
>>> to place u-boot image.
>>>
>>>
>>> Well, at least while booting from SATA, they say that BootRom looks
>>>
>>> for code starting with zero offset, which implies that there can not
>>>
>>> be any GPT partition table.
>>>
>>> Probably, it is similar for SD. If so, we need to flash our EFI-aware
>>>
>>> u-boot instead of upstream one.
>>>
>>>
>>>
>>> Well, SATA flash image from here
>>>
>>>
>>> http://wiki.espressobin.net/tiki-index.php?page=Boot+ESPRESSObin+from+SATA+drive=sata
>>>
>>>
>>> suits for booting from microsd card, when it is flushed from zero
>>>
>>> offset and boot selection switchs are set to 7.
>>>
>>>
>>> At least, there is non-destructive way to check out u-boot image.
>>>
>>>
>>> Double checked. Seems that microsd boot doesn't work and is not
>>> supported. At least for my V5 board.
>>> It just falls back to SPINOR
>>>
>>>
>>>
>>>
>>>  http://espressobin.net/forums/topic/how-to-flash-u-boot/
>>>
>>>
>>>
>>> Alex
>>>
>>>
>>>
>>>
>>> --
>>>
>>> With best regards,
>>>
>>> Matwey V. Kornilov
>>>
>>>
>>>
>>>
>>> --
>>>
>>> With best regards,
>>>
>>> Matwey V. Kornilov
>>>
>>>
>>>
>>>
>>> --
>>>
>>> With best regards,
>>>
>>> Matwey V. Kornilov
>>>
>>>
>>>
>>>
>>> --
>>> With best regards,
>>> Matwey V. Kornilov
>>> --
>>> To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
>>> To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
>>>
>>>
>>
>>
>>
>> --
>> 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

[opensuse-arm] Re: openSUSE-Tumbleweed ARM JeOS-efi.armv7

[Matwey V. Kornilov]

On 10.11.2017 14:38, Andreas Färber wrote:
> Am 09.11.2017 um 08:25 schrieb Matwey V. Kornilov:
>> 2017-11-08 23:57 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>
>>>
>>> On 08.11.17 21:24, Matwey V. Kornilov wrote:
>>>> On 08.11.2017 23:22, Alexander Graf wrote:
>>>>>
>>>>>
>>>>> On 08.11.17 21:17, Matwey V. Kornilov wrote:
>>>>>> On 08.11.2017 23:07, Alexander Graf wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 08.11.17 21:00, Matwey V. Kornilov wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I am trying to run
>>>>>>>> openSUSE-Tumbleweed-ARM-JeOS-efi.armv7l-2017.10.29-Build1.7.raw
>>>>>>>> using qemu.
>>>>>>>>
>>>>>>>> When I use qemu-system-aarch64 with 64-bit UEFI code
>>>>>>>> aavmf-aarch64-code.bin then the only I see is the EFI console:
>>>>>>>>
>>>>>>>> UEFI Interactive Shell v2.287477C2-69C7-11D2-8E39-00A0C969723B B8F1C820
>>>>>>>>
>>>>>>>> EDK IIlProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA B8F1FF18
>>>>>>>>
>>>>>>>> UEFI v2.60 (EDK II, 0x0001)008-7F9B-4F30-87AC-60C9FEF5DA4E B8348710
>>>>>>>>
>>>>>>>> Mapping table
>>>>>>>>   FS0: Alias(s):HD1a0b:;BLK2:
>>>>>>>>
>>>>>>>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004)
>>>>>>>>  BLK5: Alias(s):
>>>>>>>>   VenHw(F9B94AE2-8BA6-409B-9D56-B9B417F53CB3)
>>>>>>>>  BLK0: Alias(s):
>>>>>>>>   VenHw(8047DB4B-7E9C-4C0C-8EBC-DFBBAACACE8F)
>>>>>>>>  BLK1: Alias(s):
>>>>>>>>
>>>>>>>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)
>>>>>>>>  BLK3: Alias(s):
>>>>>>>>
>>>>>>>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(2,GPT,3DF8DD35-94BC-4FF0-B74C-12853D4B1811,0x65000,0x83004)
>>>>>>>>  BLK4: Alias(s):
>>>>>>>>
>>>>>>>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(3,GPT,38C4AA8C-4A7F-49C4-BCFD-6C2C755496BD,0xE8800,0x3DE781)
>>>>>>>>
>>>>>>>> Press ESC in 1 seconds to skip startup.nsh or any other key to 
>>>>>>>> continue.
>>>>>>>> FSOpen: Open '\startup.nsh' Success
>>>>>>>> FSOpen: Open '\startup.nsh' Success
>>>>>>>> FSOpen: Open '\startup.nsh' Success
>>>>>>>> Shell> bootarm
>>>>>>>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>>>>>>>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>>>>>>>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>>>>>>>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>>>>>>>> [Security] 3rd party image[0] can be loaded after EndOfDxe:
>>>>>>>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004)/\efi\boot\bootarm.EFI.
>>>>>>>> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B B8EDE440
>>>>>>>> Unloading driver at 0x000
>>>>>>>> Shell> Error Status: Unsupported (line number 1)
>>>>>>>>
>>>>>>>>
>>>>>>>> As far as I understand, 64-bit Qemu UEFI code doesn't expect to see and
>>>>>>>> run 32-bit EFI executable.
>>>>>>>
>>>>>>> Correct, as far as UEFI is concerned, a 32bit ARM binary could as well
>>>>>>> be a MIPS one ;). It's a different, unsupported platform for it.
>>>>>>>
>>>>>>>> When I try to use qemu-uefi-aarch32.bin as firmware, then I see the
>>>>>>>> following:
>>>>>>>>
>>>>>>>> Initialization of device cfi.pflash01 failed: failed to read the 
>>>>>>>> initial
>>>>>>>> flash cont

Re: [opensuse-arm] Re: openSUSE-Tumbleweed ARM JeOS-efi.armv7

[Matwey V. Kornilov]

2017-11-08 23:57 GMT+03:00 Alexander Graf <ag...@suse.de>:
>
>
> On 08.11.17 21:24, Matwey V. Kornilov wrote:
>> On 08.11.2017 23:22, Alexander Graf wrote:
>>>
>>>
>>> On 08.11.17 21:17, Matwey V. Kornilov wrote:
>>>> On 08.11.2017 23:07, Alexander Graf wrote:
>>>>>
>>>>>
>>>>> On 08.11.17 21:00, Matwey V. Kornilov wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I am trying to run
>>>>>> openSUSE-Tumbleweed-ARM-JeOS-efi.armv7l-2017.10.29-Build1.7.raw
>>>>>> using qemu.
>>>>>>
>>>>>> When I use qemu-system-aarch64 with 64-bit UEFI code
>>>>>> aavmf-aarch64-code.bin then the only I see is the EFI console:
>>>>>>
>>>>>> UEFI Interactive Shell v2.287477C2-69C7-11D2-8E39-00A0C969723B B8F1C820
>>>>>>
>>>>>> EDK IIlProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA B8F1FF18
>>>>>>
>>>>>> UEFI v2.60 (EDK II, 0x0001)008-7F9B-4F30-87AC-60C9FEF5DA4E B8348710
>>>>>>
>>>>>> Mapping table
>>>>>>   FS0: Alias(s):HD1a0b:;BLK2:
>>>>>>
>>>>>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004)
>>>>>>  BLK5: Alias(s):
>>>>>>   VenHw(F9B94AE2-8BA6-409B-9D56-B9B417F53CB3)
>>>>>>  BLK0: Alias(s):
>>>>>>   VenHw(8047DB4B-7E9C-4C0C-8EBC-DFBBAACACE8F)
>>>>>>  BLK1: Alias(s):
>>>>>>
>>>>>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)
>>>>>>  BLK3: Alias(s):
>>>>>>
>>>>>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(2,GPT,3DF8DD35-94BC-4FF0-B74C-12853D4B1811,0x65000,0x83004)
>>>>>>  BLK4: Alias(s):
>>>>>>
>>>>>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(3,GPT,38C4AA8C-4A7F-49C4-BCFD-6C2C755496BD,0xE8800,0x3DE781)
>>>>>>
>>>>>> Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
>>>>>> FSOpen: Open '\startup.nsh' Success
>>>>>> FSOpen: Open '\startup.nsh' Success
>>>>>> FSOpen: Open '\startup.nsh' Success
>>>>>> Shell> bootarm
>>>>>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>>>>>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>>>>>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>>>>>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>>>>>> [Security] 3rd party image[0] can be loaded after EndOfDxe:
>>>>>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004)/\efi\boot\bootarm.EFI.
>>>>>> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B B8EDE440
>>>>>> Unloading driver at 0x000
>>>>>> Shell> Error Status: Unsupported (line number 1)
>>>>>>
>>>>>>
>>>>>> As far as I understand, 64-bit Qemu UEFI code doesn't expect to see and
>>>>>> run 32-bit EFI executable.
>>>>>
>>>>> Correct, as far as UEFI is concerned, a 32bit ARM binary could as well
>>>>> be a MIPS one ;). It's a different, unsupported platform for it.
>>>>>
>>>>>> When I try to use qemu-uefi-aarch32.bin as firmware, then I see the
>>>>>> following:
>>>>>>
>>>>>> Initialization of device cfi.pflash01 failed: failed to read the initial
>>>>>> flash content
>>>>>>
>>>>>> As far as I understand, qemu-uefi-aarch32.bin is in wrong format, but
>>>>>> there are no other files in ovfm rpm package.
>>>>>
>>>>> Which ovmf package are you looking at? I'm not sure we properly package
>>>>> OVMF for AArch32. But you can always try with the Linaro built ones :)
>>>>>
>>>>> http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/latest/QEMU-ARM/RELEASE_GCC5/
>>>>
>>>> Well, the last thing I see using linaro's DEBUG build is the following:
>>>>
>>>> SetUefiImageMemoryAttributes - 0xBBA48000 - 0x00

[opensuse-arm] Re: openSUSE-Tumbleweed ARM JeOS-efi.armv7

[Matwey V. Kornilov]

On 08.11.2017 23:22, Alexander Graf wrote:
> 
> 
> On 08.11.17 21:17, Matwey V. Kornilov wrote:
>> On 08.11.2017 23:07, Alexander Graf wrote:
>>>
>>>
>>> On 08.11.17 21:00, Matwey V. Kornilov wrote:
>>>> Hi,
>>>>
>>>> I am trying to run
>>>> openSUSE-Tumbleweed-ARM-JeOS-efi.armv7l-2017.10.29-Build1.7.raw
>>>> using qemu.
>>>>
>>>> When I use qemu-system-aarch64 with 64-bit UEFI code
>>>> aavmf-aarch64-code.bin then the only I see is the EFI console:
>>>>
>>>> UEFI Interactive Shell v2.287477C2-69C7-11D2-8E39-00A0C969723B B8F1C820
>>>>
>>>> EDK IIlProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA B8F1FF18
>>>>
>>>> UEFI v2.60 (EDK II, 0x0001)008-7F9B-4F30-87AC-60C9FEF5DA4E B8348710
>>>>
>>>> Mapping table
>>>>   FS0: Alias(s):HD1a0b:;BLK2:
>>>>
>>>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004)
>>>>  BLK5: Alias(s):
>>>>   VenHw(F9B94AE2-8BA6-409B-9D56-B9B417F53CB3)
>>>>  BLK0: Alias(s):
>>>>   VenHw(8047DB4B-7E9C-4C0C-8EBC-DFBBAACACE8F)
>>>>  BLK1: Alias(s):
>>>>
>>>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)
>>>>  BLK3: Alias(s):
>>>>
>>>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(2,GPT,3DF8DD35-94BC-4FF0-B74C-12853D4B1811,0x65000,0x83004)
>>>>  BLK4: Alias(s):
>>>>
>>>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(3,GPT,38C4AA8C-4A7F-49C4-BCFD-6C2C755496BD,0xE8800,0x3DE781)
>>>>
>>>> Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
>>>> FSOpen: Open '\startup.nsh' Success
>>>> FSOpen: Open '\startup.nsh' Success
>>>> FSOpen: Open '\startup.nsh' Success
>>>> Shell> bootarm
>>>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>>>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>>>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>>>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>>>> [Security] 3rd party image[0] can be loaded after EndOfDxe:
>>>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004)/\efi\boot\bootarm.EFI.
>>>> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B B8EDE440
>>>> Unloading driver at 0x000
>>>> Shell> Error Status: Unsupported (line number 1)
>>>>
>>>>
>>>> As far as I understand, 64-bit Qemu UEFI code doesn't expect to see and
>>>> run 32-bit EFI executable.
>>>
>>> Correct, as far as UEFI is concerned, a 32bit ARM binary could as well
>>> be a MIPS one ;). It's a different, unsupported platform for it.
>>>
>>>> When I try to use qemu-uefi-aarch32.bin as firmware, then I see the
>>>> following:
>>>>
>>>> Initialization of device cfi.pflash01 failed: failed to read the initial
>>>> flash content
>>>>
>>>> As far as I understand, qemu-uefi-aarch32.bin is in wrong format, but
>>>> there are no other files in ovfm rpm package.
>>>
>>> Which ovmf package are you looking at? I'm not sure we properly package
>>> OVMF for AArch32. But you can always try with the Linaro built ones :)
>>>
>>> http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/latest/QEMU-ARM/RELEASE_GCC5/
>>
>> Well, the last thing I see using linaro's DEBUG build is the following:
>>
>> SetUefiImageMemoryAttributes - 0xBBA48000 - 0x2000
>> (0x4000)
>> Found Timer interrupts 29, 30, 27, 26
>> InstallProtocolInterface: 26BACCB3-6F42-11D4-BCE7-0080C73C8881 BBA48010
>> Loading driver E660EA85-058E-4B55-A54B-F02F83A24707
>> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B BAF790A8
>> add-symbol-file
>> /home/buildslave/workspace/leg-virt-tianocore-edk2-upstream/edk2/Build/ArmVirtQemu-ARM/DEBUG_GCC5/ARM/MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe/DEBUG/DisplayEngine.dll
>> 0xBBA26000
>> Loading driver at 0x000BBA25000 EntryPoint=0x000BBA26031 DisplayEngine.efi
>> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF BAF79990
>> ProtectUefiImageCommon - 0xBAF790A8
>>   - 0xBBA25000 - 0x0001C000
>> SetUefiImageMemoryAttributes - 0xBBA25000 - 0x1000
>> (0x4000)
>> SetUefiImageMemoryAttributes - 0xBBA26000 - 0x00017000
>> (0x0002)
>> SetUefiImageMemoryAttributes - 0xBBA3D000 - 0x4000
>> (0x4000)
>>
>> Then happens nothing but 100% CPU load.
> 
> The file on the link I provided works just fine for me:
> 
>   $ qemu-system-arm -nographic -M virt -cpu cortex-a15 -bios QEMU_EFI.fd
> 

What is your qemu version?
Mine is

> qemu-system-arm --version
QEMU emulator version 2.9.1(openSUSE Leap 42.3)


> 
> Alex
> 


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

[opensuse-arm] Re: openSUSE-Tumbleweed ARM JeOS-efi.armv7

[Matwey V. Kornilov]

On 08.11.2017 23:07, Alexander Graf wrote:
> 
> 
> On 08.11.17 21:00, Matwey V. Kornilov wrote:
>> Hi,
>>
>> I am trying to run
>> openSUSE-Tumbleweed-ARM-JeOS-efi.armv7l-2017.10.29-Build1.7.raw
>> using qemu.
>>
>> When I use qemu-system-aarch64 with 64-bit UEFI code
>> aavmf-aarch64-code.bin then the only I see is the EFI console:
>>
>> UEFI Interactive Shell v2.287477C2-69C7-11D2-8E39-00A0C969723B B8F1C820
>>
>> EDK IIlProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA B8F1FF18
>>
>> UEFI v2.60 (EDK II, 0x0001)008-7F9B-4F30-87AC-60C9FEF5DA4E B8348710
>>
>> Mapping table
>>   FS0: Alias(s):HD1a0b:;BLK2:
>>
>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004)
>>  BLK5: Alias(s):
>>   VenHw(F9B94AE2-8BA6-409B-9D56-B9B417F53CB3)
>>  BLK0: Alias(s):
>>   VenHw(8047DB4B-7E9C-4C0C-8EBC-DFBBAACACE8F)
>>  BLK1: Alias(s):
>>
>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)
>>  BLK3: Alias(s):
>>
>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(2,GPT,3DF8DD35-94BC-4FF0-B74C-12853D4B1811,0x65000,0x83004)
>>  BLK4: Alias(s):
>>
>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(3,GPT,38C4AA8C-4A7F-49C4-BCFD-6C2C755496BD,0xE8800,0x3DE781)
>>
>> Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
>> FSOpen: Open '\startup.nsh' Success
>> FSOpen: Open '\startup.nsh' Success
>> FSOpen: Open '\startup.nsh' Success
>> Shell> bootarm
>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>> FSOpen: Open '\efi\boot\bootarm.EFI' Success
>> [Security] 3rd party image[0] can be loaded after EndOfDxe:
>> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004)/\efi\boot\bootarm.EFI.
>> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B B8EDE440
>> Unloading driver at 0x000
>> Shell> Error Status: Unsupported (line number 1)
>>
>>
>> As far as I understand, 64-bit Qemu UEFI code doesn't expect to see and
>> run 32-bit EFI executable.
> 
> Correct, as far as UEFI is concerned, a 32bit ARM binary could as well
> be a MIPS one ;). It's a different, unsupported platform for it.
> 
>> When I try to use qemu-uefi-aarch32.bin as firmware, then I see the
>> following:
>>
>> Initialization of device cfi.pflash01 failed: failed to read the initial
>> flash content
>>
>> As far as I understand, qemu-uefi-aarch32.bin is in wrong format, but
>> there are no other files in ovfm rpm package.
> 
> Which ovmf package are you looking at? I'm not sure we properly package
> OVMF for AArch32. But you can always try with the Linaro built ones :)
> 
> http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/latest/QEMU-ARM/RELEASE_GCC5/

Well, the last thing I see using linaro's DEBUG build is the following:

SetUefiImageMemoryAttributes - 0xBBA48000 - 0x2000
(0x4000)
Found Timer interrupts 29, 30, 27, 26
InstallProtocolInterface: 26BACCB3-6F42-11D4-BCE7-0080C73C8881 BBA48010
Loading driver E660EA85-058E-4B55-A54B-F02F83A24707
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B BAF790A8
add-symbol-file
/home/buildslave/workspace/leg-virt-tianocore-edk2-upstream/edk2/Build/ArmVirtQemu-ARM/DEBUG_GCC5/ARM/MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe/DEBUG/DisplayEngine.dll
0xBBA26000
Loading driver at 0x000BBA25000 EntryPoint=0x000BBA26031 DisplayEngine.efi
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF BAF79990
ProtectUefiImageCommon - 0xBAF790A8
  - 0xBBA25000 - 0x0001C000
SetUefiImageMemoryAttributes - 0xBBA25000 - 0x1000
(0x4000)
SetUefiImageMemoryAttributes - 0xBBA26000 - 0x00017000
(0x0002)
SetUefiImageMemoryAttributes - 0xBBA3D000 - 0x4000
(0x4000)

Then happens nothing but 100% CPU load.

> 
>> What is the proper way to run JeOS-efi.armv7? Is it supposed to work in
>> qemu?
> 
> It should work, yes. It should also work on any platform that has distro
> boot enabled and runs with recent U-Boot.
> 
> 
> Alex
> 


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

[opensuse-arm] openSUSE-Tumbleweed ARM JeOS-efi.armv7

[Matwey V. Kornilov]

Hi,

I am trying to run
openSUSE-Tumbleweed-ARM-JeOS-efi.armv7l-2017.10.29-Build1.7.raw
using qemu.

When I use qemu-system-aarch64 with 64-bit UEFI code
aavmf-aarch64-code.bin then the only I see is the EFI console:

UEFI Interactive Shell v2.287477C2-69C7-11D2-8E39-00A0C969723B B8F1C820

EDK IIlProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA B8F1FF18

UEFI v2.60 (EDK II, 0x0001)008-7F9B-4F30-87AC-60C9FEF5DA4E B8348710

Mapping table
  FS0: Alias(s):HD1a0b:;BLK2:

VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004)
 BLK5: Alias(s):
  VenHw(F9B94AE2-8BA6-409B-9D56-B9B417F53CB3)
 BLK0: Alias(s):
  VenHw(8047DB4B-7E9C-4C0C-8EBC-DFBBAACACE8F)
 BLK1: Alias(s):

VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)
 BLK3: Alias(s):

VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(2,GPT,3DF8DD35-94BC-4FF0-B74C-12853D4B1811,0x65000,0x83004)
 BLK4: Alias(s):

VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(3,GPT,38C4AA8C-4A7F-49C4-BCFD-6C2C755496BD,0xE8800,0x3DE781)

Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
FSOpen: Open '\startup.nsh' Success
FSOpen: Open '\startup.nsh' Success
FSOpen: Open '\startup.nsh' Success
Shell> bootarm
FSOpen: Open '\efi\boot\bootarm.EFI' Success
FSOpen: Open '\efi\boot\bootarm.EFI' Success
FSOpen: Open '\efi\boot\bootarm.EFI' Success
FSOpen: Open '\efi\boot\bootarm.EFI' Success
[Security] 3rd party image[0] can be loaded after EndOfDxe:
VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004)/\efi\boot\bootarm.EFI.
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B B8EDE440
Unloading driver at 0x000
Shell> Error Status: Unsupported (line number 1)


As far as I understand, 64-bit Qemu UEFI code doesn't expect to see and
run 32-bit EFI executable.

When I try to use qemu-uefi-aarch32.bin as firmware, then I see the
following:

Initialization of device cfi.pflash01 failed: failed to read the initial
flash content

As far as I understand, qemu-uefi-aarch32.bin is in wrong format, but
there are no other files in ovfm rpm package.

What is the proper way to run JeOS-efi.armv7? Is it supposed to work in
qemu?

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

Re: [opensuse-arm] rock64

[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 <matwey.korni...@gmail.com>:
> I'll try to figure out how to use SPL u-boot instead.
>
> 2017-08-25 22:16 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>> It seems that the following tools are binary only:
>> https://github.com/rockchip-linux/rkbin/tree/master/tools
>> They are required to convert u-boot to proprietary loader known format.
>> Proprietary loader is required because there is no (yet?) support for
>> SPL in u-boot for rk3328.
>> The tools are also x86_64 only, so I wonder how could they be used in
>> OBS to produce package for u-boot image in deployable format.
>>
>>
>> 2017-08-24 20:49 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>>> 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 <mbrug...@suse.com>:
>>>>
>>>>
>>>> On 08/12/2017 12:02 PM, Matwey V. Kornilov wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I will receive my rock64 board soon.
>>>>>
>>>>> https://www.pine64.org/?page_id=7147
>>>>>
>>>>> I would like to run some openSUSE on it. There are no upstream support
>>>>> but lets see what we could do.
>>>>>
>>>>
>>>> A patch is on it's way. I might show up in v4.14:
>>>> https://www.spinics.net/lists/arm-kernel/msg599638.html
>>>>
>>>> Only missing and blocking bit is the pmic support:
>>>> http://www.spinics.net/lists/devicetree/msg188756.html
>>>>
>>>> Regarding u-boot support it still needs the first stage loader. You might
>>>> want to check with this hacked up tree:
>>>> https://github.com/mmind/u-boot-rockchip/commits/netboots/rock64
>>>>
>>>> Have fun!
>>>> Matthias
>>>
>>>
>>>
>>> --
>>> With best regards,
>>> Matwey V. Kornilov
>>
>>
>>
>> --
>> With best regards,
>> Matwey V. Kornilov
>
>
>
> --
> With best regards,
> Matwey V. Kornilov



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

Re: [opensuse-arm] Re: EspressoBin

[Matwey V. Kornilov]

2017-10-22 9:31 GMT+03:00 Rick Ashford <rick.ashf...@suse.com>:
> There is a great thread on the Armbian forum about the EspressoBin, and it
> helped me get things up and running with Tumbleweed.
>
> One of the guys there has a public Dropbox link that includes their images
> for flashing the u-boot loader:
> https://www.dropbox.com/sh/kmgmo1uubhcczx5/AAAYEvTIFxpBr0dHG2QcapTza?dl=0
>
> The thread:
> https://forum.armbian.com/index.php?/topic/4089-espressobin-support-development-efforts/=4
>
> With their boot loader I was able to finally use BTRFS images as well as PXE
> boot. It also has an EFI load function in the help that I need to get around
> to trying.

Well, If armian u-boot is able to boot our standard EFI-Grub JeOS,
then we can recommend to use it with openSUSE and don't reinvent the
wheel.

>
> Rick Ashford
> Sales Engineering Manager - West
> SUSE Linux
> rick.ashf...@suse.com
> Office:  512-782-4318
> Mobile: 512-731-3035
>
> On Oct 21, 2017, at 12:32 PM, Matwey V. Kornilov <matwey.korni...@gmail.com>
> wrote:
>
> 2017-10-21 19:47 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>
> 2017-10-21 19:35 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>
> 2017-10-20 18:02 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>
> 2017-10-20 17:37 GMT+03:00 Alexander Graf <ag...@suse.de>:
>
>
>
> On 20.10.17 16:21, Matwey V. Kornilov wrote:
>
> 20.10.2017 17:12, Alexander Graf пишет:
>
>
>
> On 20.10.17 13:57, Matwey V. Kornilov wrote:
>
> Hi,
>
>
> I've just received EspressoBin 1G. Any success stories how to run openSUSE?
>
>
>
> I think you'll basically have to somehow flash a working U-Boot with
>
> distro boot onto it and then just dd the tumbleweed/42.3 iso onto a usb
>
> stick and cross your fingers that gets you to a point where you can
>
> install :)
>
>
> It has microsd card, I think it should be able to boot from sd, no?
>
> I also need to to find serial console pins on the board :)
>
>
> There seems to be a lengthy discussion on the mailing list. I guess you
>
> can select the boot device using DIP switches though?
>
>
> Yes, I can. I think it is preferred way. Need to find expected layout
>
> to place u-boot image.
>
>
> Well, at least while booting from SATA, they say that BootRom looks
>
> for code starting with zero offset, which implies that there can not
>
> be any GPT partition table.
>
> Probably, it is similar for SD. If so, we need to flash our EFI-aware
>
> u-boot instead of upstream one.
>
>
>
> Well, SATA flash image from here
>
>
> http://wiki.espressobin.net/tiki-index.php?page=Boot+ESPRESSObin+from+SATA+drive=sata
>
>
> suits for booting from microsd card, when it is flushed from zero
>
> offset and boot selection switchs are set to 7.
>
>
> At least, there is non-destructive way to check out u-boot image.
>
>
> Double checked. Seems that microsd boot doesn't work and is not
> supported. At least for my V5 board.
> It just falls back to SPINOR
>
>
>
>
>  http://espressobin.net/forums/topic/how-to-flash-u-boot/
>
>
>
> Alex
>
>
>
>
> --
>
> With best regards,
>
> Matwey V. Kornilov
>
>
>
>
> --
>
> With best regards,
>
> Matwey V. Kornilov
>
>
>
>
> --
>
> With best regards,
>
> Matwey V. Kornilov
>
>
>
>
> --
> With best regards,
> Matwey V. Kornilov
> --
> To unsubscribe, e-mail: opensuse-arm+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] Re: EspressoBin

[Matwey V. Kornilov]

2017-10-21 19:47 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
> 2017-10-21 19:35 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>> 2017-10-20 18:02 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>>> 2017-10-20 17:37 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>>
>>>>
>>>> On 20.10.17 16:21, Matwey V. Kornilov wrote:
>>>>> 20.10.2017 17:12, Alexander Graf пишет:
>>>>>>
>>>>>>
>>>>>> On 20.10.17 13:57, Matwey V. Kornilov wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I've just received EspressoBin 1G. Any success stories how to run 
>>>>>>> openSUSE?
>>>>>>>
>>>>>>
>>>>>> I think you'll basically have to somehow flash a working U-Boot with
>>>>>> distro boot onto it and then just dd the tumbleweed/42.3 iso onto a usb
>>>>>> stick and cross your fingers that gets you to a point where you can
>>>>>> install :)
>>>>>
>>>>> It has microsd card, I think it should be able to boot from sd, no?
>>>>> I also need to to find serial console pins on the board :)
>>>>
>>>> There seems to be a lengthy discussion on the mailing list. I guess you
>>>> can select the boot device using DIP switches though?
>>>
>>> Yes, I can. I think it is preferred way. Need to find expected layout
>>> to place u-boot image.
>>
>> Well, at least while booting from SATA, they say that BootRom looks
>> for code starting with zero offset, which implies that there can not
>> be any GPT partition table.
>> Probably, it is similar for SD. If so, we need to flash our EFI-aware
>> u-boot instead of upstream one.
>>
>
> Well, SATA flash image from here
>
> http://wiki.espressobin.net/tiki-index.php?page=Boot+ESPRESSObin+from+SATA+drive=sata
>
> suits for booting from microsd card, when it is flushed from zero
> offset and boot selection switchs are set to 7.
>
> At least, there is non-destructive way to check out u-boot image.

Double checked. Seems that microsd boot doesn't work and is not
supported. At least for my V5 board.
It just falls back to SPINOR

>
>>>
>>>>
>>>>   http://espressobin.net/forums/topic/how-to-flash-u-boot/
>>>>
>>>>
>>>> Alex
>>>
>>>
>>>
>>> --
>>> With best regards,
>>> Matwey V. Kornilov
>>
>>
>>
>> --
>> With best regards,
>> Matwey V. Kornilov
>
>
>
> --
> With best regards,
> Matwey V. Kornilov



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

Re: [opensuse-arm] Re: EspressoBin

[Matwey V. Kornilov]

2017-10-21 19:35 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
> 2017-10-20 18:02 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
>> 2017-10-20 17:37 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>>
>>>
>>> On 20.10.17 16:21, Matwey V. Kornilov wrote:
>>>> 20.10.2017 17:12, Alexander Graf пишет:
>>>>>
>>>>>
>>>>> On 20.10.17 13:57, Matwey V. Kornilov wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I've just received EspressoBin 1G. Any success stories how to run 
>>>>>> openSUSE?
>>>>>>
>>>>>
>>>>> I think you'll basically have to somehow flash a working U-Boot with
>>>>> distro boot onto it and then just dd the tumbleweed/42.3 iso onto a usb
>>>>> stick and cross your fingers that gets you to a point where you can
>>>>> install :)
>>>>
>>>> It has microsd card, I think it should be able to boot from sd, no?
>>>> I also need to to find serial console pins on the board :)
>>>
>>> There seems to be a lengthy discussion on the mailing list. I guess you
>>> can select the boot device using DIP switches though?
>>
>> Yes, I can. I think it is preferred way. Need to find expected layout
>> to place u-boot image.
>
> Well, at least while booting from SATA, they say that BootRom looks
> for code starting with zero offset, which implies that there can not
> be any GPT partition table.
> Probably, it is similar for SD. If so, we need to flash our EFI-aware
> u-boot instead of upstream one.
>

Well, SATA flash image from here

http://wiki.espressobin.net/tiki-index.php?page=Boot+ESPRESSObin+from+SATA+drive=sata

suits for booting from microsd card, when it is flushed from zero
offset and boot selection switchs are set to 7.

At least, there is non-destructive way to check out u-boot image.

>>
>>>
>>>   http://espressobin.net/forums/topic/how-to-flash-u-boot/
>>>
>>>
>>> Alex
>>
>>
>>
>> --
>> With best regards,
>> Matwey V. Kornilov
>
>
>
> --
> With best regards,
> Matwey V. Kornilov



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

Re: [opensuse-arm] Re: EspressoBin

[Matwey V. Kornilov]

2017-10-20 18:02 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:
> 2017-10-20 17:37 GMT+03:00 Alexander Graf <ag...@suse.de>:
>>
>>
>> On 20.10.17 16:21, Matwey V. Kornilov wrote:
>>> 20.10.2017 17:12, Alexander Graf пишет:
>>>>
>>>>
>>>> On 20.10.17 13:57, Matwey V. Kornilov wrote:
>>>>> Hi,
>>>>>
>>>>> I've just received EspressoBin 1G. Any success stories how to run 
>>>>> openSUSE?
>>>>>
>>>>
>>>> I think you'll basically have to somehow flash a working U-Boot with
>>>> distro boot onto it and then just dd the tumbleweed/42.3 iso onto a usb
>>>> stick and cross your fingers that gets you to a point where you can
>>>> install :)
>>>
>>> It has microsd card, I think it should be able to boot from sd, no?
>>> I also need to to find serial console pins on the board :)
>>
>> There seems to be a lengthy discussion on the mailing list. I guess you
>> can select the boot device using DIP switches though?
>
> Yes, I can. I think it is preferred way. Need to find expected layout
> to place u-boot image.

Well, at least while booting from SATA, they say that BootRom looks
for code starting with zero offset, which implies that there can not
be any GPT partition table.
Probably, it is similar for SD. If so, we need to flash our EFI-aware
u-boot instead of upstream one.

>
>>
>>   http://espressobin.net/forums/topic/how-to-flash-u-boot/
>>
>>
>> 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] Re: EspressoBin

[Matwey V. Kornilov]

2017-10-20 17:37 GMT+03:00 Alexander Graf <ag...@suse.de>:
>
>
> On 20.10.17 16:21, Matwey V. Kornilov wrote:
>> 20.10.2017 17:12, Alexander Graf пишет:
>>>
>>>
>>> On 20.10.17 13:57, Matwey V. Kornilov wrote:
>>>> Hi,
>>>>
>>>> I've just received EspressoBin 1G. Any success stories how to run openSUSE?
>>>>
>>>
>>> I think you'll basically have to somehow flash a working U-Boot with
>>> distro boot onto it and then just dd the tumbleweed/42.3 iso onto a usb
>>> stick and cross your fingers that gets you to a point where you can
>>> install :)
>>
>> It has microsd card, I think it should be able to boot from sd, no?
>> I also need to to find serial console pins on the board :)
>
> There seems to be a lengthy discussion on the mailing list. I guess you
> can select the boot device using DIP switches though?

Yes, I can. I think it is preferred way. Need to find expected layout
to place u-boot image.

>
>   http://espressobin.net/forums/topic/how-to-flash-u-boot/
>
>
> 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

[opensuse-arm] Re: EspressoBin

[Matwey V. Kornilov]

20.10.2017 17:12, Alexander Graf пишет:
> 
> 
> On 20.10.17 13:57, Matwey V. Kornilov wrote:
>> Hi,
>>
>> I've just received EspressoBin 1G. Any success stories how to run openSUSE?
>>
> 
> I think you'll basically have to somehow flash a working U-Boot with
> distro boot onto it and then just dd the tumbleweed/42.3 iso onto a usb
> stick and cross your fingers that gets you to a point where you can
> install :)

It has microsd card, I think it should be able to boot from sd, no?
I also need to to find serial console pins on the board :)

> 
> 
> Alex
> 


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

[opensuse-arm] EspressoBin

[Matwey V. Kornilov]

Hi,

I've just received EspressoBin 1G. Any success stories how to run openSUSE?

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