Am 05.09.2017 um 15:28 schrieb Alexander Graf:
> 
> 
> On 05.09.17 15:23, Matwey V. Kornilov wrote:
>> 2017-09-05 16:12 GMT+03:00 Alexander Graf <[email protected]>:
>>>
>>>
>>> On 05.09.17 15:02, Matwey V. Kornilov wrote:
>>>>
>>>> 2017-09-05 16:00 GMT+03:00 Alexander Graf <[email protected]>:
>>>>>
>>>>>
>>>>> On 05.09.17 14:58, Matwey V. Kornilov wrote:
>>>>>>
>>>>>>
>>>>>> Still no luck. No signal at video, no text in console after EFI stub.
>>>>>> Any ideas why?
>>>>>>
>>>>>
>>>>> Can you try to make earlycon work? I'm sure someone has the magic
>>>>> parameters
>>>>> for it somewhere...
>>>>
>>>>
>>>> Indeed. But they don't work either. Ones which should is
>>>> earlycon=uart8250,mmio32,0xff130000
>>>
>>>
>>> That is very odd. Usually earlycon works. The only case I've found
>>> where it
>>> was unintuitively broken was when U-Boot ran in EL3, but I assume you do
>>> have ATF running somewhere, right?
>>
>> It is supposed to be so.
>>
>>>
>>> What you can still try is to recover the kernel log from RAM. For
>>> that, boot
>>> up the system, then reset (don't power cycle, use the reset button if
>>> available, otherwise use the reset line on the jtag port if available).
>>> After reset, you should get back to U-Boot. There, run "bdinfo" to
>>> find out
>>> the base offset of RAM.
>>
>> What is the offset here?
>>
>> => bdinfo
>> arch_number = 0x00000000
>> boot_params = 0x00000000
>> DRAM bank   = 0x00000000
>> -> start    = 0x00200000
> 
> This is the offset. It does sound quite weird though, so don't be
> surprised if things don't work :).

This means the offset is actually zero, but 0x200000 bytes are reserved
for ATF or something.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
-- 
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]

Reply via email to