On 12 November 2015 at 03:41, Vladimir Olovyannikov
<volov...@broadcom.com> wrote:
>> -----Original Message-----
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Wednesday, November 11, 2015 1:08 AM
>> To: Vladimir Olovyannikov
>> Cc: edk2-devel@lists.01.org
>> Subject: Re: Armv8 64bit: System error booting linux from the UEFI
>>
>> On 11 November 2015 at 01:20, Vladimir Olovyannikov
>> <volov...@broadcom.com> wrote:
>> > Hello,
>> >
>> > I am not sure this is the right forum to ask this question, so I am sorry 
>> > in
>> > advance if this is an offtopic here (please point me to the proper one).
>> >
>> > I brought up UEFI on the device and am trying to load linux from the SD
>> card
>> > (loading from the network using GRUB is a topic for another message).
>> >
>> > Linux kernel starts and shortly after that (as soon as local_async is
>> > enabled which is simple “MSR DAIfclr,4”) there is a kernel crash with
>> >
>> > “Bad mode in Error handler detected, code 0xbf000000 -- SError”
>> > Here is the log:
>> >
>> >
>> >
>> > The default boot selection will start in  10 seconds
>> >
>>
>> Unrelated note: *please* get rid of the ARM BDS and use the Intel BDS
>> instead. The ARM BDS violates the UEFI spec, (i.e., you cannot boot
>> installer images from it without a lot of hassle) and does not allow
>> you to enable UEFI secure boot.
>>
>> Look at the development history of ArmVExpress-FVP-AArch64.dsc for
>> hints how to do this.
> Thank you for the hint. I will follow your advice to get rid of the ARM BDS.
>>
>> > [1] Linux Kernel from SD Card
>> >
>> >         - SD(0x0)/HD(1,MBR,0x00000000,0x89,0x3A9F77)/Image
>> >
>> >         - Arguments: dtb=ns2-svk.dtb initrd=initrd console=ttyS0,115200n8
>> > earlycon=uart8250,mmio32,0x66130000,maxcpus=1
>> >
>> > [2] GRUB
>> >
>> >         - MAC(001019D0B2A4,0x1)/IPv4(10.136.12.136)/grub.efi
>> >
>> >         - Arguments:
>> >
>> > [3] Shell
>> >
>> > [4] Boot Manager
>> >
>> > Start: 1
>> >
>> > InstallProtocolInterface: CE345171-BA0B-11D2-8E4F-00A0C969723B
>> BEDB9DA0
>> >
>> > BlockSize : 512
>> >
>> > LastBlock : 3A9FFF
>> >
>> > InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B
>> BEDB9798
>> >
>> > InstallProtocolInterface: 964E5B21-6459-11D2-8E39-00A0C969723B
>> BEDB9670
>> >
>> > InstallProtocolInterface: CE345171-BA0B-11D2-8E4F-00A0C969723B
>> BEDB95A0
>> >
>> > InstallProtocolInterface: 964E5B22-6459-11D2-8E39-00A0C969723B
>> BEDAF030
>> >
>> > InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B
>> BE2E6040
>> >
>> > Loading driver at 0x000B8C0C000 EntryPoint=0x000B9297440
>> >
>> > Loading driver at 0x000B8C0C000 EntryPoint=0x000B9297440
>> >
>> > InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF
>> BEDB0718
>> >
>> > EFI stub: Booting Linux Kernel...
>> >
>> > ConvertPages: Incompatible memory types
>> >
>> > EFI stub: Using DTB from command line
>> >
>> > EFI stub: Exiting boot services and installing virtual address map...
>> >
>> > MmcHost: ExitBootServicesEvent+
>> >
>> >         Marked card brcm-SDIO1 as removed
>> >
>> >         Resetting Card brcm-SDIO1
>> >
>> >         brcm-SDIO1 Card reset done.
>> >
>> > MmcHost: ExitBootServicesEvent-
>> >
>> > MmcHost: ExitBootServicesEvent+
>> >
>> >         Marked card brcm-SDIO0 as removed
>> >
>> >         Resetting Card brcm-SDIO0
>> >
>> >         brcm-SDIO0 Card reset done.
>> >
>> > MmcHost: ExitBootServicesEvent-
>> >
>> > [    0.000000] Booting Linux on physical CPU 0x0
>> >
>> > [    0.000000] Initializing cgroup subsys cpu
>> >
>> > [    0.000000] Linux version 4.2.0+ (volovyan@LBRMN-LNXUB114) (gcc
>> version
>> > 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - 
>> > Linaro
>> > GCC 4.9-2014.09) ) #1 SMP PREEMPT Tue Oct 13 11:33:09 PDT 2015
>> >
>> > [    0.000000] CPU: AArch64 Processor [411fd073] revision 3
>> >
>> > [    0.000000] Detected PIPT I-cache on CPU0
>> >
>> > [    0.000000] earlycon: Early serial console at MMIO32 0x66130000 (options
>> > 'maxcpus=1')
>> >
>> > [    0.000000] bootconsole [uart0] enabled
>> >
>> > [    0.000000] Bad mode in Error handler detected, code 0xbf000000 -- 
>> > SError
>> >
>> > [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0+ #1
>> >
>> > [    0.000000] Hardware name: SVK proto (DT)
>> >
>> > [    0.000000] task: ffffffc0007584b0 ti: ffffffc00074c000 task.ti:
>> > ffffffc00074c000
>> >
>> > [    0.000000] PC is at setup_arch+0x260/0x5b4
>> >
>> > [    0.000000] LR is at setup_arch+0x25c/0x5b4
>> >
>> > [    0.000000] pc : [<ffffffc000709708>] lr : [<ffffffc000709704>] pstate:
>> > 000002c5
>> >
>> > [    0.000000] sp : ffffffc00074ff20
>> >
>> > [    0.000000] x29: ffffffc00074ff20 x28: 0000000000000000
>> >
>> > [    0.000000] x27: ffffffc000081198 x26: 00000000807cd000
>> >
>> > [    0.000000] x25: 00000000807ca000 x24: 0000000080000000
>> >
>> > [    0.000000] x23: 0000000000000000 x22: ffffffc000752000
>> >
>> > [    0.000000] x21: ffffffc000752610 x20: ffffffbffa800000
>> >
>> > [    0.000000] x19: ffffffc000080000 x18: 0000000000000000
>> >
>> > [    0.000000] x17: 00000000000005e3 x16: 0000000000001000
>> >
>> > [    0.000000] x15: 0000000000001c00 x14: 0ffffffffffffffe
>> >
>> > [    0.000000] x13: 0000000000000020 x12: 0000000000000028
>> >
>> > [    0.000000] x11: 0000000000000007 x10: 0101010101010101
>> >
>> > [    0.000000] x9 : fffffffffffffffb x8 : 0000000000000008
>> >
>> > [    0.000000] x7 : 0000000000000003 x6 : 0000000000800000
>> >
>> > [    0.000000] x5 : 000000000000005f x4 : 0000000000000000
>> >
>> > [    0.000000] x3 : 0000000000000000 x2 : 0000000000000065
>> >
>> > [    0.000000] x1 : 0000000000000000 x0 : 0000000000000001
>> >
>> > [    0.000000]
>> >
>> > [    0.000000] Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP
>> >
>> > [    0.000000] Modules linked in:
>> >
>> > [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0+ #1
>> >
>> > [    0.000000] Hardware name: SVK proto (DT)
>> >
>> > [    0.000000] task: ffffffc0007584b0 ti: ffffffc00074c000 task.ti:
>> > ffffffc00074c000
>> >
>> > [    0.000000] PC is at setup_arch+0x260/0x5b4
>> >
>> > [    0.000000] LR is at setup_arch+0x25c/0x5b4
>> >
>> > [    0.000000] pc : [<ffffffc000709708>] lr : [<ffffffc000709704>] pstate:
>> > 000002c5
>> >
>> > [    0.000000] sp : ffffffc00074ff20
>> >
>> > [    0.000000] x29: ffffffc00074ff20 x28: 0000000000000000
>> >
>> > [    0.000000] x27: ffffffc000081198 x26: 00000000807cd000
>> >
>> > [    0.000000] x25: 00000000807ca000 x24: 0000000080000000
>> >
>> > [    0.000000] x23: 0000000000000000 x22: ffffffc000752000
>> >
>> > [    0.000000] x21: ffffffc000752610 x20: ffffffbffa800000
>> >
>> > [    0.000000] x19: ffffffc000080000 x18: 0000000000000000
>> >
>> > [    0.000000] x17: 00000000000005e3 x16: 0000000000001000
>> >
>> > [    0.000000] x15: 0000000000001c00 x14: 0ffffffffffffffe
>> >
>> > [    0.000000] x13: 0000000000000020 x12: 0000000000000028
>> >
>> > [    0.000000] x11: 0000000000000007 x10: 0101010101010101
>> >
>> > [    0.000000] x9 : fffffffffffffffb x8 : 0000000000000008
>> >
>> > [    0.000000] x7 : 0000000000000003 x6 : 0000000000800000
>> >
>> > [    0.000000] x5 : 000000000000005f x4 : 0000000000000000
>> >
>> > [    0.000000] x3 : 0000000000000000 x2 : 0000000000000065
>> >
>> > [    0.000000] x1 : 0000000000000000 x0 : 0000000000000001
>> >
>> > [    0.000000]
>> >
>> > [    0.000000] Process swapper (pid: 0, stack limit = 0xffffffc00074c020)
>> >
>> > [    0.000000] Stack: (0xffffffc00074ff20 to 0xffffffc000750000)
>> >
>> > [    0.000000] ff20: 0074ffa0 ffffffc0 00707688 ffffffc0 00733fa8 ffffffc0
>> > 0079d000 ffffffc0
>> >
>> > [    0.000000] ff40: 0079d000 ffffffc0 00752000 ffffffc0 00000000 00000000
>> > 80000000 00000000
>> >
>> > [    0.000000] ff60: 807ca000 00000000 807cd000 00000000 00000001 00000000
>> > 9f400000 00000000
>> >
>> > [    0.000000] ff80: ffffffff ffffffff 00000000 00000000 00000080 00000000
>> > fefefefe fefefefe
>> >
>> > [    0.000000] ffa0: 00000000 00000000 8053e000 00000000 befe0018
>> 00000000
>> > 00000e12 00000000
>> >
>> > [    0.000000] ffc0: 9f400000 00000000 00000000 00000000 00000000 00000000
>> > 80000000 00000000
>> >
>> > [    0.000000] ffe0: 00000000 00000000 00733fa8 ffffffc0 00000000 00000000
>> > 00000000 00000000
>> >
>> > [    0.000000] Call trace:
>> >
>> > [    0.000000] [<ffffffc000709708>] setup_arch+0x260/0x5b4
>> >
>> > [    0.000000] [<ffffffc000707684>] start_kernel+0xa4/0x3ac
>> >
>> > [    0.000000] Code: 91316000 94001ac2 97fff7a3 d50344ff (9400069a)
>> >
>> > [    0.000000] ---[ end trace cb88537fdc8fa200 ]---
>> >
>> > [    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
>> >
>> > [    0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the
>> > idle task!
>> >
>> >
>> >
>> > Searching for this issue on the Internet yielded several discussions, but 
>> > it
>> > looks like they do not apply to my case.
>> >
>> > Thus, I have tried to set the EFI_RT_VIRTUAL_BASE to some high value to
>> > catch if anything from the UEFI tries to dereference memory while
>> mapping is
>> > being done,
>> > to no avail – no errors.
>> >
>>
>> If anything like that is going on, I would expect the fault to be
>> reported synchronously.
>>
>> >
>> >
>> > Has anybody faced this issue? Or have any idea on how to catch where it
>> > happens?
>> >
>> > The problem here is that obviously something happens way BEFORE aborts
>> are
>> > enabled, but inspecting GIC distributor etc. does not show any trace of an
>> > abort.
>> >
>>
>> This is a firmware problem, not a kernel problem. The kernel is
>> entered with an pending asynchronous external abort, which may have
>> several causes. You need to instrument the firmware (i.e., unmask the
>> aborts earlier and run in the debugger) to get a feeling for what is
>> going on there. It could be something like speculative accesses to
>> unassigned physical ranges that are mapped cacheable inadvertently,
>> but it could be lots of other things as well.
>
> Thank you for your help Ard. Back to  investigation :)
>

FYI http://article.gmane.org/gmane.comp.bios.edk2.devel/4246

This fixes a bug that could potentially result in speculative reads to
device regions. We have also made some other changes regarding
cacheability and shareability recently (and the patch above will
likely go in today) so it is probably worthwhile to make sure you are
based on the latest upstream.

-- 
Ard.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Reply via email to