RISC-V/HiFive memory limitations

[Denis Obrezkov]

2017-06-20 16:29 GMT+03:00 Joel Sherrill <joel at rtems.org>:

>
>
> On Jun 20, 2017 1:20 AM, "Denis Obrezkov" <denisobrezkov at gmail.com> wrote:
>
> 2017-06-20 4:00 GMT+03:00 Joel Sherrill <joel at rtems.org>:
>
>>
>>
>> On Jun 19, 2017 5:37 PM, "Denis Obrezkov" <denisobrezkov at gmail.com>
>> wrote:
>>
>> 2017-06-20 1:23 GMT+03:00 Hesham Almatary <heshamelmatary at gmail.com>:
>>
>>>
>>>
>>> On Tue, Jun 20, 2017 at 7:33 AM, Denis Obrezkov <denisobrezkov at gmail.com
>>> > wrote:
>>>
>>>> 2017-06-20 0:19 GMT+03:00 Joel Sherrill <joel at rtems.org>:
>>>>
>>>>> Check the value in gdb without loading it on a target.
>>>>>
>>>>> Gdb hello.exe
>>>>>
>>>>> p symbol
>>>>>
>>>>
>>>>> Since it is a constant, it should be as expected. If it is, you have a
>>>>> code loading issue.
>>>>>
>>>> Yes, it is 512 in gdb, as expected. So, is the problem with linkcmd
>>>> file?
>>>>
>>>>>
>>>>> Is that value by any chance an instruction?
>>>>>
>>>> No don't think so.
>>>
>>>
>>>> How to check whether it is an instruction or not?
>>>>
>>>> You can check if this value might match with any riscv32 instruction
>>> encodings (I believe it doesn't). See Chapter 19 (RV32/64G Instruction Set
>>> Listings) user-level riscv-spec 2.3-draft. You can also use
>>> riscv32-rtems4.12-objdump on your binary and search for this value.
>>>
>>> I was also able to run gdb, connect to the target,  change the value of
>>>> the variable to 512,
>>>> reconnect to the target, make loading and read the value equal to 512.
>>>>
>>>>
>>>>
>>>> --
>>>> Regards, Denis Obrezkov
>>>>
>>>
>>>
>>>
>>> --
>>> Hesham
>>>
>>
>> I didn't find this value in objdump
>> I think that .data section wasn't properly initialized, does it look
>> reasonable?
>>
>>
>> I suspect it means that the image is not properly loaded into memory.
>> Download but don't execute. Then check the address.
>>
>> If it correct on download, then binary search with breakpoints and
>> checking​ the memory. Or set a hardware watchpoint on a write to that
>> address.
>>
>> Hesham.. does the crt code have to copy a secondary copy of the .data
>> initial values into place on this bsp?
>>
>>
>>
>> --
>> Regards, Denis Obrezkov
>>
>>
>> The wrong value is present right after loading, before the execution.
>
>
> That sounds like either a memory map problem, a download format problem or
> something more bizarre.
>
> Can you run programs compiled with the bare elf toolset? If so, then there
> is a discrepancy between your linkcmds, download format, etc from the bare
> metal toolset.
>
>
>
> --
> Regards, Denis Obrezkov
>
>
>
Ok, then I will try to adapt the default linkcmd file today.

-- 
Regards, Denis Obrezkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170620/999df2a2/attachment-0001.html>