RISC-V/HiFive memory limitations

[Joel Sherrill]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170619/60774ce4/attachment.html>