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

2018-02-16 Thread 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 :
>
>
> On 25.01.18 22:16, Matwey V. Kornilov wrote:
>> 2018-01-25 11:49 GMT+03:00 Matwey V. Kornilov :
>>> 2018-01-25 11:11 GMT+03:00 Matwey V. Kornilov :
 2018-01-25 0:28 GMT+03:00 Alexander Graf :
>
>
> On 24.01.18 20:29, Matwey V. Kornilov wrote:
>> 2018-01-24 22:05 GMT+03:00 Alexander Graf :
>>>
>>>
>>> On 24.01.18 18:10, Matwey V. Kornilov wrote:
 2018-01-24 19:51 GMT+03:00 Alexander Graf :
>
>
> On 24.01.18 17:43, Matwey V. Kornilov wrote:
>> 2018-01-24 16:38 GMT+03:00 Alexander Graf :
>>>
>>>
>>> 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

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

2018-02-16 Thread Alexander Graf 


On 25.01.18 22:16, Matwey V. Kornilov wrote:
> 2018-01-25 11:49 GMT+03:00 Matwey V. Kornilov :
>> 2018-01-25 11:11 GMT+03:00 Matwey V. Kornilov :
>>> 2018-01-25 0:28 GMT+03:00 Alexander Graf :


 On 24.01.18 20:29, Matwey V. Kornilov wrote:
> 2018-01-24 22:05 GMT+03:00 Alexander Graf :
>>
>>
>> On 24.01.18 18:10, Matwey V. Kornilov wrote:
>>> 2018-01-24 19:51 GMT+03:00 Alexander Graf :


 On 24.01.18 17:43, Matwey V. Kornilov wrote:
> 2018-01-24 16:38 GMT+03:00 Alexander Graf :
>>
>>
>> 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
-- 
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org