Picon

Mixing C and fortran in RTEMS/LEON environment

Hi,

I am investigating the possibility of calling Fortran subroutines from a 
C program for a LEON3 target using the RTEMS4.10-RCC-1.1.99.16 
toolchain. However, it seems that Fortran is not supported in this 
distribution. Is it possible to compile this mixture? Is perhaps a 
rebuild of the sparc-rtems tools needed?

Thank you,
Jose

------------------------------------
Posted by: =?UTF-8?Q?Jos=c3=a9_A._Pulido?= <jose-antonio.pulido@...>
------------------------------------

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/LEON_SPARC/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/LEON_SPARC/join
    (Yahoo! ID required)

<*> To change settings via email:
(Continue reading)

Picon

Digest Number 4884



3 Messages

Digest #4884
1a
2
3a
Re: XSIM simulation question by "Jan Andersson" jan_at_gaisler

Messages

Mon Feb 1, 2016 6:05 am (PST) . Posted by:

"Rehab Hosni" rehab.massoud

 When I use the prom.out generated by MKPROM2 with -ramcs 2 option I get a similar Tsim results. But in the vhdl simulation the results are always the same whether I used this -ramcs 2 option or left it to be 1 as the default. Why the vhdl simulation output is not sensitive to the -ramcs option while the simulator is? 
ranb24# /home/massoud/grlib/tsim-eval/tsim/linux-x64/tsim-leon3 -dcsize 1 -dlsize 4 -dsets 1 -icsize 1
switch -dcsize is not supported by the evaluation version
switch -dlsize is not supported by the evaluation version
-dsets not supported in demo version
switch -icsize is not supported by the evaluation version
 This TSIM evaluation version will expire 2016-04-14
 TSIM/LEON3 SPARC simulator, version 2.0.41 (evaluation version)

 Copyright (C) 2015, Cobham Gaisler - all rights reserved.
 This software may only be used with a valid license.
 For latest updates, go to http://www.gaisler.com/
 Comments or bug-reports to support <at> gaisler.com

serial port A on stdin/stdout
allocated 4096 KiB SRAM memory, in 1 bank
allocated 32 MiB SDRAM memory, in 1 bank
allocated 2048 KiB ROM memory
icache: 1 * 4 KiB, 16 bytes/line (4 KiB total)
dcache: 1 * 4 KiB, 16 bytes/line (4 KiB total)
tsim> load prom.srec
section: prom.srec at 0x0, size 16032 bytes
entry point: 0x0
tsim> run          

  MkProm2 boot loader v2.0
  Copyright Gaisler Research - all rights reserved

  system clock   : 50.0 MHz
  baud rate      : 19171 baud
  prom           : 512 K, (2/2) ws (r/w)
  sram           : 2048 K, 2 bank(s), 2/2 ws (r/w)

  decompressing .text to 0x
  decompression failed (00000002)
  decompressing .data to 0x40004070
  decompression failed (00000002)

  starting simple.exe

IU in error mode (tt=0x80, trap instruction)
(In trap table for tt=0x02, illegal instruction)
 10938350  00000020  91d02000   ta    0x0
tsim>

----------------------------------------------------------


On Friday, January 29, 2016 11:32 AM, "waves_eng <at> yahoo.com [LEON_SPARC]" <LEON_SPARC <at> yahoogroups.com> wrote:


  Hi all,

I'm trying to generate new prom.srec and ram.srec files for the simulation of leon3-digilent-nexys3 design template. I want to put the whole program in rom with MKPROM from where it should be late decompressed to external ram. So I'll need an empty ram to be in ram.srec and my prom.out generated by MKPROM to be made as srec file with objcopy as
sparc-elf-objcopy -O srec prom.out prom.srec
And the generated prom.srec seems working fine with tsim.  But when running it in simulation it starts decompressing to a strange address as:

#   MkProm2 boot loader v2.0
#   Copyright Gaisler Research - all rights reserved
#   system clock   : 50.0 MHz
#   baud rate      : 19171 baud
#   prom           : 16 K, (2/2) ws (r/w)
#   sram           : 32 K, 1 bank(s), 0/0 ws (r/w)
#
#   decompressing .text to 0x40ÿÿ00ÿÿ   => Here I have no clue why the prom was not decompressed to 0x40000000 as it was done before by this prom file residing in the on-chip ahbrom!
#   decompression failed (00ÿÿ00ÿÿ)
#   decompressing .data to 0x40004070
#   decompression failed (00000002)
#
#   starting simple.exe

And of course the program does not execute correctly. So any idea why the decompression of the .text segment was not done to 0x40000000 as it should have been?
I used the below command to generate an empty ram, could this be the reason why the decompression failed? srec_cat -generate 0x40000000 0x40008000 -constant 0 -o ram.srec        =>(here I was trying to create a 32K ram initialized to 0)

Best regards,
--Rehab
#yiv9208188771 #yiv9208188771 -- #yiv9208188771ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9208188771 #yiv9208188771ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9208188771 #yiv9208188771ygrp-mkp #yiv9208188771hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv9208188771 #yiv9208188771ygrp-mkp #yiv9208188771ads {margin-bottom:10px;}#yiv9208188771 #yiv9208188771ygrp-mkp .yiv9208188771ad {padding:0 0;}#yiv9208188771 #yiv9208188771ygrp-mkp .yiv9208188771ad p {margin:0;}#yiv9208188771 #yiv9208188771ygrp-mkp .yiv9208188771ad a {color:#0000ff;text-decoration:none;}#yiv9208188771 #yiv9208188771ygrp-sponsor #yiv9208188771ygrp-lc {font-family:Arial;}#yiv9208188771 #yiv9208188771ygrp-sponsor #yiv9208188771ygrp-lc #yiv9208188771hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9208188771 #yiv9208188771ygrp-sponsor #yiv9208188771ygrp-lc .yiv9208188771ad {margin-bottom:10px;padding:0 0;}#yiv9208188771 #yiv9208188771actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9208188771 #yiv9208188771activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9208188771 #yiv9208188771activity span {font-weight:700;}#yiv9208188771 #yiv9208188771activity span:first-child {text-transform:uppercase;}#yiv9208188771 #yiv9208188771activity span a {color:#5085b6;text-decoration:none;}#yiv9208188771 #yiv9208188771activity span span {color:#ff7900;}#yiv9208188771 #yiv9208188771activity span .yiv9208188771underline {text-decoration:underline;}#yiv9208188771 .yiv9208188771attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv9208188771 .yiv9208188771attach div a {text-decoration:none;}#yiv9208188771 .yiv9208188771attach img {border:none;padding-right:5px;}#yiv9208188771 .yiv9208188771attach label {display:block;margin-bottom:5px;}#yiv9208188771 .yiv9208188771attach label a {text-decoration:none;}#yiv9208188771 blockquote {margin:0 0 0 4px;}#yiv9208188771 .yiv9208188771bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv9208188771 .yiv9208188771bold a {text-decoration:none;}#yiv9208188771 dd.yiv9208188771last p a {font-family:Verdana;font-weight:700;}#yiv9208188771 dd.yiv9208188771last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv9208188771 dd.yiv9208188771last p span.yiv9208188771yshortcuts {margin-right:0;}#yiv9208188771 div.yiv9208188771attach-table div div a {text-decoration:none;}#yiv9208188771 div.yiv9208188771attach-table {width:400px;}#yiv9208188771 div.yiv9208188771file-title a, #yiv9208188771 div.yiv9208188771file-title a:active, #yiv9208188771 div.yiv9208188771file-title a:hover, #yiv9208188771 div.yiv9208188771file-title a:visited {text-decoration:none;}#yiv9208188771 div.yiv9208188771photo-title a, #yiv9208188771 div.yiv9208188771photo-title a:active, #yiv9208188771 div.yiv9208188771photo-title a:hover, #yiv9208188771 div.yiv9208188771photo-title a:visited {text-decoration:none;}#yiv9208188771 div#yiv9208188771ygrp-mlmsg #yiv9208188771ygrp-msg p a span.yiv9208188771yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv9208188771 .yiv9208188771green {color:#628c2a;}#yiv9208188771 .yiv9208188771MsoNormal {margin:0 0 0 0;}#yiv9208188771 o {font-size:0;}#yiv9208188771 #yiv9208188771photos div {float:left;width:72px;}#yiv9208188771 #yiv9208188771photos div div {border:1px solid #666666;height:62px;overflow:hidden;width:62px;}#yiv9208188771 #yiv9208188771photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv9208188771 #yiv9208188771reco-category {font-size:77%;}#yiv9208188771 #yiv9208188771reco-desc {font-size:77%;}#yiv9208188771 .yiv9208188771replbq {margin:4px;}#yiv9208188771 #yiv9208188771ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv9208188771 #yiv9208188771ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv9208188771 #yiv9208188771ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv9208188771 #yiv9208188771ygrp-mlmsg select, #yiv9208188771 input, #yiv9208188771 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv9208188771 #yiv9208188771ygrp-mlmsg pre, #yiv9208188771 code {font:115% monospace;}#yiv9208188771 #yiv9208188771ygrp-mlmsg * {line-height:1.22em;}#yiv9208188771 #yiv9208188771ygrp-mlmsg #yiv9208188771logo {padding-bottom:10px;}#yiv9208188771 #yiv9208188771ygrp-msg p a {font-family:Verdana;}#yiv9208188771 #yiv9208188771ygrp-msg p#yiv9208188771attach-count span {color:#1E66AE;font-weight:700;}#yiv9208188771 #yiv9208188771ygrp-reco #yiv9208188771reco-head {color:#ff7900;font-weight:700;}#yiv9208188771 #yiv9208188771ygrp-reco {margin-bottom:20px;padding:0px;}#yiv9208188771 #yiv9208188771ygrp-sponsor #yiv9208188771ov li a {font-size:130%;text-decoration:none;}#yiv9208188771 #yiv9208188771ygrp-sponsor #yiv9208188771ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv9208188771 #yiv9208188771ygrp-sponsor #yiv9208188771ov ul {margin:0;padding:0 0 0 8px;}#yiv9208188771 #yiv9208188771ygrp-text {font-family:Georgia;}#yiv9208188771 #yiv9208188771ygrp-text p {margin:0 0 1em 0;}#yiv9208188771 #yiv9208188771ygrp-text tt {font-size:120%;}#yiv9208188771 #yiv9208188771ygrp-vital ul li:last-child {border-right:none !important;}#yiv9208188771

Mon Feb 1, 2016 7:04 am (PST) . Posted by:

mrrachidi90

Hi all,
I configure my eCos and run the ping test it runs well, but when i try tu run the tcp or the udp test my program stuck in the init_all_network_interfaces(). I see that I have a lots of underflow and overflow traps and the asynchronous level 8 also. do you have an idea what is the cause of this problem please.


Best regards.
Mohammed.

Mon Feb 1, 2016 1:53 pm (PST) . Posted by:

"Jan Andersson" jan_at_gaisler

Hello,

The Xsim elaboration crash is scheduled to be fixed in 2016.1. No
workaround available at this time.

Best regards,
Jan

On 1/27/16/w4 01:34, Jan Andersson jan <at> gaisler.com [LEON_SPARC] wrote:
> Hi,
>
> It may be that the project gets built incorrectly for simulation in
> older versions now that the file list generation was changed for 2015.4.
> Also the included MIG project files are probably too new.
>
> A bit more information about the changes:
>
> The previous flow added simulation files to simset sim_1. This led
> to build failures because vivado reordered the files and tried to
> build testbench.vhd early.
>
> Adding source_mgmt_mode DisplayOnly partially solved this but the
> simset files were still built after the synthesis files.
>
> Script has now been changed to use read_vhdl and read_verilog for all
> files and changing the use_for_synthesis attribute for the
> similation-only
> files. This maintains the correct file order. The change of
> source_mgmt_mode
> has not been included since changing this mode again led to
> testbench.vhd
> being built too early! That is - preventing Vivado from reordering
> files led
> to Vivado reordering files when using the new way of only using
> read_* - but
> not when using the previous simset approach.
>
>
> (it may be that I am just missing the correct way to build the project).
>
> In any case, we will post an update once we have additional feedback
> from Xilinx support.
>
> Best regards,
> Jan
>
>
> On 1/27/16/w4 00:46, Shi Lei Han shileihan <at> yahoo.com [LEON_SPARC] wrote:
>>
>>
>>
>> Jan,
>>
>> Thank you for the reply. I guess missed that from the change log. I am
>> using the latest 2015.4. I will install the older version of Vivado.
>>
>> Shi Lei
>>
>>
>>
>
>
> ------------------------------------
> Posted by: Jan Andersson <jan <at> gaisler.com>
> ------------------------------------
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>



__._,_.___
Posted by: "Gaillard, Thibaud" <thibaud.gaillard <at> atmel.com>



__,_._,___
Picon

Digest Number 4882



1 Message

Digest #4882

Message

Thu Jan 28, 2016 5:47 am (PST) . Posted by:

"Rehab Hosni" rehab.massoud

Thanks Jan for your helpful reply, it clarified my issue.

Now for my experiments I want to compare the behavior from the program execution in simulation to that on the board. So I need to ensure that any initializations executed by GRMON are the same as those done by the prom.srec file that I shall use in simulation, is there such a ready prom.srec file that resembles what GRMON is doing exactly? (even if it is taking long time)
The other option I have, is to create my prom.srec file from the prom.out file -I assume objcopy would recognize the prom.out format- and wait for the long simulation time (I'm OK with that); but I will still need then in the simulation a ram.srec file that resembles an empty external ram. I hope that generating a zero initialized srec file would do the job for this purpose; so if anyone thinks this is wrong I'd appreciate letting me know. But for this solution I do I still can use here GRMON's run command for executing my new prom flashed code at the boot phase or then I should only use the external reset button on the board? I'd assume the latter is correct unless anyone points otherwise... So here GRMON will be only used to flash the PROM.

    -going through that latter option I used the srec_cat command below to generate the new empty ram.srec (trying to simulate an empty 32 K ram) & objcopy to generate prom.srec. I just used the same prom.out I used successfully before in an on-chip rom and on tsim.  but the files were not decompressed correctly as in the simulation output below:
srec_cat -generate 0x40000000 0x40008000 -constant 0 -o ram.srec        =>(here I was trying to create a 32K ram initialized to 0)
sparc-elf-objcopy -O srec /home/massoud/grlib/grlib-gpl-1.4.1-b4156/software/leon3/prom.out prom.srec

#   MkProm2 boot loader v2.0
#   Copyright Gaisler Research - all rights reserved
#   system clock   : 50.0 MHz
#   baud rate      : 19171 baud
#   prom           : 16 K, (2/2) ws (r/w)
#   sram           : 32 K, 1 bank(s), 0/0 ws (r/w)
#
#   decompressing .text to 0x40ÿÿ00ÿÿ   => Here I have no clue why the prom was not decompressed to 0x40000000 as it was done before by this prom file residing in the on-chip ahbrom!
#   decompression failed (00ÿÿ00ÿÿ)
#   decompressing .data to 0x40004070
#   decompression failed (00000002)
#
#   starting simple.exe

--so any hint regarding what mistake I might have done would be highly appreciated!

Thanks in advance & regards,--Rehab 


On Thursday, January 21, 2016 10:08 AM, "Jan Andersson jan <at> gaisler.com [LEON_SPARC]" <LEON_SPARC <at> yahoogroups.com> wrote:


  Hello,

No, the load command does not work for address 0. The memory controller
area at address 0 is mapped to a external Flash. To write to a Flash
device you need to issue special commands. GRMON2 can do this. The
commands you need to perform are:

flash unlock all
flash erase all
flash load prom.srec

Then you should be able to verify prom.srec.

The prom.srec and ram.srec files are intended for simulation. prom.srec
takes some shortcuts in initialization and the application contained in
ram.srec make use of a special module only present in simulation to
print messages etc. This is done to save time in simulation.

To create a PROM image for real HW you should use the MKPROM2 software
available from gaisler.com.

GRMON2 replaces the bootloader so you can also load your applications
directly to RAM and then do "run" in GRMON2, without programming the Flash.

Best regards,
Jan

On 1/20/16/w3 20:09, Rehab Hosni waves_eng <at> yahoo.com [LEON_SPARC] wrote:
>
>
> Hi,
>
> When trying to load and the run the ram.srec & prom.srec files to the
> FPGA, the prom.srec file verfication always fails, although I ask grmon
> to start verification from the 0x00000000 address in which the file
> prom.srec was loaded by the load command. Does the load comman really
> work when I try to load to address 0?
>
> Executing the run command afterwards (with only ram.srec) runs the
> processor, but I get different results from those on simulation, so
> probably the program didn't run correctly.
>
> So is the evaluation version of GRMON works only for loading data to the
> ram? I'm working on leon3-digilent-nexys3 design on a nexys 3 board. And
> from the testbench there, the prom is external, right? and hence a prom
> file should be loaded at 0, right? So why the prom.srec file can' be
> loaded?
>
> Note:I was trying to load the exact prom.srec and ram.srec provided in
> the template design, as I wanted to see whether I will counter the exact
> behavior as in the simulation.
>
> Best regards,
> --Rehab
>
>
>
> //
>
>
>
#yiv4659287048 -- #yiv4659287048ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv4659287048 #yiv4659287048ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv4659287048 #yiv4659287048ygrp-mkp #yiv4659287048hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv4659287048 #yiv4659287048ygrp-mkp #yiv4659287048ads {margin-bottom:10px;}#yiv4659287048 #yiv4659287048ygrp-mkp .yiv4659287048ad {padding:0 0;}#yiv4659287048 #yiv4659287048ygrp-mkp .yiv4659287048ad p {margin:0;}#yiv4659287048 #yiv4659287048ygrp-mkp .yiv4659287048ad a {color:#0000ff;text-decoration:none;}#yiv4659287048 #yiv4659287048ygrp-sponsor #yiv4659287048ygrp-lc {font-family:Arial;}#yiv4659287048 #yiv4659287048ygrp-sponsor #yiv4659287048ygrp-lc #yiv4659287048hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv4659287048 #yiv4659287048ygrp-sponsor #yiv4659287048ygrp-lc .yiv4659287048ad {margin-bottom:10px;padding:0 0;}#yiv4659287048 #yiv4659287048actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv4659287048 #yiv4659287048activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv4659287048 #yiv4659287048activity span {font-weight:700;}#yiv4659287048 #yiv4659287048activity span:first-child {text-transform:uppercase;}#yiv4659287048 #yiv4659287048activity span a {color:#5085b6;text-decoration:none;}#yiv4659287048 #yiv4659287048activity span span {color:#ff7900;}#yiv4659287048 #yiv4659287048activity span .yiv4659287048underline {text-decoration:underline;}#yiv4659287048 .yiv4659287048attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv4659287048 .yiv4659287048attach div a {text-decoration:none;}#yiv4659287048 .yiv4659287048attach img {border:none;padding-right:5px;}#yiv4659287048 .yiv4659287048attach label {display:block;margin-bottom:5px;}#yiv4659287048 .yiv4659287048attach label a {text-decoration:none;}#yiv4659287048 blockquote {margin:0 0 0 4px;}#yiv4659287048 .yiv4659287048bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv4659287048 .yiv4659287048bold a {text-decoration:none;}#yiv4659287048 dd.yiv4659287048last p a {font-family:Verdana;font-weight:700;}#yiv4659287048 dd.yiv4659287048last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv4659287048 dd.yiv4659287048last p span.yiv4659287048yshortcuts {margin-right:0;}#yiv4659287048 div.yiv4659287048attach-table div div a {text-decoration:none;}#yiv4659287048 div.yiv4659287048attach-table {width:400px;}#yiv4659287048 div.yiv4659287048file-title a, #yiv4659287048 div.yiv4659287048file-title a:active, #yiv4659287048 div.yiv4659287048file-title a:hover, #yiv4659287048 div.yiv4659287048file-title a:visited {text-decoration:none;}#yiv4659287048 div.yiv4659287048photo-title a, #yiv4659287048 div.yiv4659287048photo-title a:active, #yiv4659287048 div.yiv4659287048photo-title a:hover, #yiv4659287048 div.yiv4659287048photo-title a:visited {text-decoration:none;}#yiv4659287048 div#yiv4659287048ygrp-mlmsg #yiv4659287048ygrp-msg p a span.yiv4659287048yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv4659287048 .yiv4659287048green {color:#628c2a;}#yiv4659287048 .yiv4659287048MsoNormal {margin:0 0 0 0;}#yiv4659287048 o {font-size:0;}#yiv4659287048 #yiv4659287048photos div {float:left;width:72px;}#yiv4659287048 #yiv4659287048photos div div {border:1px solid #666666;height:62px;overflow:hidden;width:62px;}#yiv4659287048 #yiv4659287048photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv4659287048 #yiv4659287048reco-category {font-size:77%;}#yiv4659287048 #yiv4659287048reco-desc {font-size:77%;}#yiv4659287048 .yiv4659287048replbq {margin:4px;}#yiv4659287048 #yiv4659287048ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv4659287048 #yiv4659287048ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv4659287048 #yiv4659287048ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv4659287048 #yiv4659287048ygrp-mlmsg select, #yiv4659287048 input, #yiv4659287048 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv4659287048 #yiv4659287048ygrp-mlmsg pre, #yiv4659287048 code {font:115% monospace;}#yiv4659287048 #yiv4659287048ygrp-mlmsg * {line-height:1.22em;}#yiv4659287048 #yiv4659287048ygrp-mlmsg #yiv4659287048logo {padding-bottom:10px;}#yiv4659287048 #yiv4659287048ygrp-msg p a {font-family:Verdana;}#yiv4659287048 #yiv4659287048ygrp-msg p#yiv4659287048attach-count span {color:#1E66AE;font-weight:700;}#yiv4659287048 #yiv4659287048ygrp-reco #yiv4659287048reco-head {color:#ff7900;font-weight:700;}#yiv4659287048 #yiv4659287048ygrp-reco {margin-bottom:20px;padding:0px;}#yiv4659287048 #yiv4659287048ygrp-sponsor #yiv4659287048ov li a {font-size:130%;text-decoration:none;}#yiv4659287048 #yiv4659287048ygrp-sponsor #yiv4659287048ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv4659287048 #yiv4659287048ygrp-sponsor #yiv4659287048ov ul {margin:0;padding:0 0 0 8px;}#yiv4659287048 #yiv4659287048ygrp-text {font-family:Georgia;}#yiv4659287048 #yiv4659287048ygrp-text p {margin:0 0 1em 0;}#yiv4659287048 #yiv4659287048ygrp-text tt {font-size:120%;}#yiv4659287048 #yiv4659287048ygrp-vital ul li:last-child {border-right:none !important;}#yiv4659287048



__._,_.___
Posted by: "Gaillard, Thibaud" <thibaud.gaillard <at> atmel.com>



__,_._,___
Picon

Digest Number 4883



1 Message

Digest #4883

Message

Fri Jan 29, 2016 2:32 am (PST) . Posted by:

rehab.massoud

Hi all,

I'm trying to generate new prom.srec and ram.srec files for the simulation of leon3-digilent-nexys3 design template. I want to put the whole program in rom with MKPROM from where it should be late decompressed to external ram. So I'll need an empty ram to be in ram.srec and my prom.out generated by MKPROM to be made as srec file with objcopy as
sparc-elf-objcopy -O srec prom.out prom.srec
And the generated prom.srec seems working fine with tsim. But when running it in simulation it starts decompressing to a strange address as:

# MkProm2 boot loader v2.0
# Copyright Gaisler Research - all rights reserved
# system clock : 50.0 MHz
# baud rate : 19171 baud
# prom : 16 K, (2/2) ws (r/w)
# sram : 32 K, 1 bank(s), 0/0 ws (r/w)
#
# decompressing .text to 0x40ÿÿ00ÿÿ => Here I have no clue why the prom was not decompressed to 0x40000000 as it was done before by this prom file residing in the on-chip ahbrom!
# decompression failed (00ÿÿ00ÿÿ)
# decompressing .data to 0x40004070
# decompression failed (00000002)
#
# starting simple.exe



And of course the program does not execute correctly. So any idea why the decompression of the .text segment was not done to 0x40000000 as it should have been?


I used the below command to generate an empty ram, could this be the reason why the decompression failed?
srec_cat -generate 0x40000000 0x40008000 -constant 0 -o ram.srec =>(here I was trying to create a 32K ram initialized to 0)


Best regards,


--Rehab



__._,_.___
Posted by: "Gaillard, Thibaud" <thibaud.gaillard <at> atmel.com>



__,_._,___
Picon

Digest Number 4881



3 Messages

Digest #4881
1a
Re: XSIM simulation question by "Jan Andersson" jan_at_gaisler
1b
Re: XSIM simulation question by "Shi Lei Han" shileihan
1c
Re: XSIM simulation question by "Jan Andersson" jan_at_gaisler

Messages

Tue Jan 26, 2016 1:23 am (PST) . Posted by:

"Jan Andersson" jan_at_gaisler

Hello,

Which version of Vivado are you trying to use? 2015.4 gives an error for
a component in techmap/unisim/pads_unisim.vhd. If that one is resolved
then the following remains (from doc/Changelog.txt, also mentioned in
doc/grlib.pdf):

2016-01-08 Change script generation for Xilinx Vivado so that recent
versions of Vivado use and generate a simulation file list
with files in the correct order. Vivado 2014.1 reorders
files
incorrectly while later versions incorrectly re-orders files
if source_mgmt_mode is set to prevent reordering(!). Current
script leaves source_mgmt_mode at default (All) and produces
correct file order with 2015.4. Vivado 2015.4 SIGSEVs during
elaboration when using XSim. Latest working version for
simulation with XSim (Vivado's built-in simulator) is
2013.4.

The crash has been reported and confirmed as a bug from Xilinx. They are
working on a fix.

Best regards,
Jan

On 1/26/16/w4 02:57, shileihan <at> yahoo.com [LEON_SPARC] wrote:
>
>
> Hi,
>
> Does anyone have a guide or any pointers for getting XSIM working for
> the template demo bard designs for GRLIB? I tried to run XSIM with the
> Digilent NEXYS4DDR board template design and I am getting varies errors...
>
> Thank you,
>
> Shi Lei
>
>
>
>
>

Tue Jan 26, 2016 3:49 pm (PST) . Posted by:

"Shi Lei Han" shileihan


Jan,
Thank you for the reply. I guess missed that from the change log. I am using the latest 2015.4. I will install the older version of Vivado.
Shi Lei

Tue Jan 26, 2016 4:35 pm (PST) . Posted by:

"Jan Andersson" jan_at_gaisler

Hi,

It may be that the project gets built incorrectly for simulation in
older versions now that the file list generation was changed for 2015.4.
Also the included MIG project files are probably too new.

A bit more information about the changes:

The previous flow added simulation files to simset sim_1. This led
to build failures because vivado reordered the files and tried to
build testbench.vhd early.

Adding source_mgmt_mode DisplayOnly partially solved this but the
simset files were still built after the synthesis files.

Script has now been changed to use read_vhdl and read_verilog for all
files and changing the use_for_synthesis attribute for the
similation-only
files. This maintains the correct file order. The change of
source_mgmt_mode
has not been included since changing this mode again led to
testbench.vhd
being built too early! That is - preventing Vivado from reordering
files led
to Vivado reordering files when using the new way of only using
read_* - but
not when using the previous simset approach.

(it may be that I am just missing the correct way to build the project).

In any case, we will post an update once we have additional feedback
from Xilinx support.

Best regards,
Jan

On 1/27/16/w4 00:46, Shi Lei Han shileihan <at> yahoo.com [LEON_SPARC] wrote:
>
>
>
> Jan,
>
> Thank you for the reply. I guess missed that from the change log. I am
> using the latest 2015.4. I will install the older version of Vivado.
>
> Shi Lei
>
>
>



__._,_.___
Posted by: "Gaillard, Thibaud" <thibaud.gaillard <at> atmel.com>



__,_._,___
Picon

Problem with tcp_lo_test



Hi all,

    I configure my eCos and run the ping test it runs well, but when i try tu run the tcp or the udp test my program stuck in the init_all_network_interfaces(). I see that I have a lots of underflow and overflow traps and the asynchronous level 8 also. do you have an idea what is the cause of this problem please.


Best regards.

Mohammed.



__._,_.___
Posted by: mrrachidi90-/E1597aS9LQAvxtiuMwx3w@public.gmane.org



__,_._,___
Picon

generating new srec files for vhdl simulation



Hi all,

I'm trying to generate new prom.srec and ram.srec files for the simulation of leon3-digilent-nexys3 design template. I want to put the whole program in rom with MKPROM from where it should be late decompressed to external ram. So I'll need an empty ram to be in ram.srec and my prom.out generated by MKPROM to be made as srec file with objcopy as
sparc-elf-objcopy -O srec prom.out prom.srec
And the generated prom.srec seems working fine with tsim.  But when running it in simulation it starts decompressing to a strange address as:

#   MkProm2 boot loader v2.0
#   Copyright Gaisler Research - all rights reserved
#   system clock   : 50.0 MHz
#   baud rate      : 19171 baud
#   prom           : 16 K, (2/2) ws (r/w)
#   sram           : 32 K, 1 bank(s), 0/0 ws (r/w)
#
#   decompressing .text to 0x40ÿÿ00ÿÿ   => Here I have no clue why the prom was not decompressed to 0x40000000 as it was done before by this prom file residing in the on-chip ahbrom!
#   decompression failed (00ÿÿ00ÿÿ)
#   decompressing .data to 0x40004070
#   decompression failed (00000002)
#
#   starting simple.exe


And of course the program does not execute correctly. So any idea why the decompression of the .text segment was not done to 0x40000000 as it should have been?


I used the below command to generate an empty ram, could this be the reason why the decompression failed?

srec_cat -generate 0x40000000 0x40008000 -constant 0 -o ram.srec        =>(here I was trying to create a 32K ram initialized to 0)

Best regards,


--Rehab



__._,_.___
Posted by: waves_eng <at> yahoo.com



__,_._,___
Picon

Re: GRMON: which ROM code it executes when running template designs?



Thanks Jan for your helpful reply, it clarified my issue.

Now for my experiments I want to compare the behavior from the program execution in simulation to that on the board. So I need to ensure that any initializations executed by GRMON are the same as those done by the prom.srec file that I shall use in simulation, is there such a ready prom.srec file that resembles what GRMON is doing exactly? (even if it is taking long time)

The other option I have, is to create my prom.srec file from the prom.out file -I assume objcopy would recognize the prom.out format- and wait for the long simulation time (I'm OK with that); but I will still need then in the simulation a ram.srec file that resembles an empty external ram. I hope that generating a zero initialized srec file would do the job for this purpose; so if anyone thinks this is wrong I'd appreciate letting me know. But for this solution I do I still can use here GRMON's run command for executing my new prom flashed code at the boot phase or then I should only use the external reset button on the board? I'd assume the latter is correct unless anyone points otherwise... So here GRMON will be only used to flash the PROM.

    -going through that latter option I used the srec_cat command below to generate the new empty ram.srec (trying to simulate an empty 32 K ram) & objcopy to generate prom.srec. I just used the same prom.out I used successfully before in an on-chip rom and on tsim.  but the files were not decompressed correctly as in the simulation output below:

srec_cat -generate 0x40000000 0x40008000 -constant 0 -o ram.srec        =>(here I was trying to create a 32K ram initialized to 0)
sparc-elf-objcopy -O srec /home/massoud/grlib/grlib-gpl-1.4.1-b4156/software/leon3/prom.out prom.srec

#   MkProm2 boot loader v2.0
#   Copyright Gaisler Research - all rights reserved
#   system clock   : 50.0 MHz
#   baud rate      : 19171 baud
#   prom           : 16 K, (2/2) ws (r/w)
#   sram           : 32 K, 1 bank(s), 0/0 ws (r/w)
#
#   decompressing .text to 0x40ÿÿ00ÿÿ   => Here I have no clue why the prom was not decompressed to 0x40000000 as it was done before by this prom file residing in the on-chip ahbrom!
#   decompression failed (00ÿÿ00ÿÿ)
#   decompressing .data to 0x40004070
#   decompression failed (00000002)
#
#   starting simple.exe

--so any hint regarding what mistake I might have done would be highly appreciated!

Thanks in advance & regards,
--Rehab
 



On Thursday, January 21, 2016 10:08 AM, "Jan Andersson jan-FkzTOoA/JUlBDgjK7y7TUQ@public.gmane.org [LEON_SPARC]" <LEON_SPARC-hHKSG33TihhbjbujkaE4pw@public.gmane.org> wrote:


 
Hello,

No, the load command does not work for address 0. The memory controller
area at address 0 is mapped to a external Flash. To write to a Flash
device you need to issue special commands. GRMON2 can do this. The
commands you need to perform are:

flash unlock all
flash erase all
flash load prom.srec

Then you should be able to verify prom.srec.

The prom.srec and ram.srec files are intended for simulation. prom.srec
takes some shortcuts in initialization and the application contained in
ram.srec make use of a special module only present in simulation to
print messages etc. This is done to save time in simulation.

To create a PROM image for real HW you should use the MKPROM2 software
available from gaisler.com.

GRMON2 replaces the bootloader so you can also load your applications
directly to RAM and then do "run" in GRMON2, without programming the Flash.

Best regards,
Jan

On 1/20/16/w3 20:09, Rehab Hosni waves_eng-/E1597aS9LQAvxtiuMwx3w@public.gmane.org [LEON_SPARC] wrote:
>
>
> Hi,
>
> When trying to load and the run the ram.srec & prom.srec files to the
> FPGA, the prom.srec file verfication always fails, although I ask grmon
> to start verification from the 0x00000000 address in which the file
> prom.srec was loaded by the load command. Does the load comman really
> work when I try to load to address 0?
>
> Executing the run command afterwards (with only ram.srec) runs the
> processor, but I get different results from those on simulation, so
> probably the program didn't run correctly.
>
> So is the evaluation version of GRMON works only for loading data to the
> ram? I'm working on leon3-digilent-nexys3 design on a nexys 3 board. And
> from the testbench there, the prom is external, right? and hence a prom
> file should be loaded at 0, right? So why the prom.srec file can' be
> loaded?
>
> Note:I was trying to load the exact prom.srec and ram.srec provided in
> the template design, as I wanted to see whether I will counter the exact
> behavior as in the simulation.
>
> Best regards,
> --Rehab
>
>
>
> //
>
>
>
#yiv4659287048 -- #yiv4659287048ygrp-mkp { border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;} #yiv4659287048 #yiv4659287048ygrp-mkp hr { border:1px solid #d8d8d8;} #yiv4659287048 #yiv4659287048ygrp-mkp #yiv4659287048hd { color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;} #yiv4659287048 #yiv4659287048ygrp-mkp #yiv4659287048ads { margin-bottom:10px;} #yiv4659287048 #yiv4659287048ygrp-mkp .yiv4659287048ad { padding:0 0;} #yiv4659287048 #yiv4659287048ygrp-mkp .yiv4659287048ad p { margin:0;} #yiv4659287048 #yiv4659287048ygrp-mkp .yiv4659287048ad a { color:#0000ff;text-decoration:none;} #yiv4659287048 #yiv4659287048ygrp-sponsor #yiv4659287048ygrp-lc { font-family:Arial;} #yiv4659287048 #yiv4659287048ygrp-sponsor #yiv4659287048ygrp-lc #yiv4659287048hd { margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;} #yiv4659287048 #yiv4659287048ygrp-sponsor #yiv4659287048ygrp-lc .yiv4659287048ad { margin-bottom:10px;padding:0 0;} #yiv4659287048 #yiv4659287048actions { font-family:Verdana;font-size:11px;padding:10px 0;} #yiv4659287048 #yiv4659287048activity { background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;} #yiv4659287048 #yiv4659287048activity span { font-weight:700;} #yiv4659287048 #yiv4659287048activity span:first-child { text-transform:uppercase;} #yiv4659287048 #yiv4659287048activity span a { color:#5085b6;text-decoration:none;} #yiv4659287048 #yiv4659287048activity span span { color:#ff7900;} #yiv4659287048 #yiv4659287048activity span .yiv4659287048underline { text-decoration:underline;} #yiv4659287048 .yiv4659287048attach { clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;} #yiv4659287048 .yiv4659287048attach div a { text-decoration:none;} #yiv4659287048 .yiv4659287048attach img { border:none;padding-right:5px;} #yiv4659287048 .yiv4659287048attach label { display:block;margin-bottom:5px;} #yiv4659287048 .yiv4659287048attach label a { text-decoration:none;} #yiv4659287048 blockquote { margin:0 0 0 4px;} #yiv4659287048 .yiv4659287048bold { font-family:Arial;font-size:13px;font-weight:700;} #yiv4659287048 .yiv4659287048bold a { text-decoration:none;} #yiv4659287048 dd.yiv4659287048last p a { font-family:Verdana;font-weight:700;} #yiv4659287048 dd.yiv4659287048last p span { margin-right:10px;font-family:Verdana;font-weight:700;} #yiv4659287048 dd.yiv4659287048last p span.yiv4659287048yshortcuts { margin-right:0;} #yiv4659287048 div.yiv4659287048attach-table div div a { text-decoration:none;} #yiv4659287048 div.yiv4659287048attach-table { width:400px;} #yiv4659287048 div.yiv4659287048file-title a, #yiv4659287048 div.yiv4659287048file-title a:active, #yiv4659287048 div.yiv4659287048file-title a:hover, #yiv4659287048 div.yiv4659287048file-title a:visited { text-decoration:none;} #yiv4659287048 div.yiv4659287048photo-title a, #yiv4659287048 div.yiv4659287048photo-title a:active, #yiv4659287048 div.yiv4659287048photo-title a:hover, #yiv4659287048 div.yiv4659287048photo-title a:visited { text-decoration:none;} #yiv4659287048 div#yiv4659287048ygrp-mlmsg #yiv4659287048ygrp-msg p a span.yiv4659287048yshortcuts { font-family:Verdana;font-size:10px;font-weight:normal;} #yiv4659287048 .yiv4659287048green { color:#628c2a;} #yiv4659287048 .yiv4659287048MsoNormal { margin:0 0 0 0;} #yiv4659287048 o { font-size:0;} #yiv4659287048 #yiv4659287048photos div { float:left;width:72px;} #yiv4659287048 #yiv4659287048photos div div { border:1px solid #666666;height:62px;overflow:hidden;width:62px;} #yiv4659287048 #yiv4659287048photos div label { color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;} #yiv4659287048 #yiv4659287048reco-category { font-size:77%;} #yiv4659287048 #yiv4659287048reco-desc { font-size:77%;} #yiv4659287048 .yiv4659287048replbq { margin:4px;} #yiv4659287048 #yiv4659287048ygrp-actbar div a:first-child { margin-right:2px;padding-right:5px;} #yiv4659287048 #yiv4659287048ygrp-mlmsg { font-size:13px;font-family:Arial, helvetica, clean, sans-serif;} #yiv4659287048 #yiv4659287048ygrp-mlmsg table { font-size:inherit;font:100%;} #yiv4659287048 #yiv4659287048ygrp-mlmsg select, #yiv4659287048 input, #yiv4659287048 textarea { font:99% Arial, Helvetica, clean, sans-serif;} #yiv4659287048 #yiv4659287048ygrp-mlmsg pre, #yiv4659287048 code { font:115% monospace;} #yiv4659287048 #yiv4659287048ygrp-mlmsg * { line-height:1.22em;} #yiv4659287048 #yiv4659287048ygrp-mlmsg #yiv4659287048logo { padding-bottom:10px;} #yiv4659287048 #yiv4659287048ygrp-msg p a { font-family:Verdana;} #yiv4659287048 #yiv4659287048ygrp-msg p#yiv4659287048attach-count span { color:#1E66AE;font-weight:700;} #yiv4659287048 #yiv4659287048ygrp-reco #yiv4659287048reco-head { color:#ff7900;font-weight:700;} #yiv4659287048 #yiv4659287048ygrp-reco { margin-bottom:20px;padding:0px;} #yiv4659287048 #yiv4659287048ygrp-sponsor #yiv4659287048ov li a { font-size:130%;text-decoration:none;} #yiv4659287048 #yiv4659287048ygrp-sponsor #yiv4659287048ov li { font-size:77%;list-style-type:square;padding:6px 0;} #yiv4659287048 #yiv4659287048ygrp-sponsor #yiv4659287048ov ul { margin:0;padding:0 0 0 8px;} #yiv4659287048 #yiv4659287048ygrp-text { font-family:Georgia;} #yiv4659287048 #yiv4659287048ygrp-text p { margin:0 0 1em 0;} #yiv4659287048 #yiv4659287048ygrp-text tt { font-size:120%;} #yiv4659287048 #yiv4659287048ygrp-vital ul li:last-child { border-right:none !important;} #yiv4659287048






__._,_.___
Posted by: Rehab Hosni <waves_eng-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>



__,_._,___
Picon

Re: XSIM simulation question




Jan,

Thank you for the reply. I guess missed that from the change log. I am using the latest 2015.4. I will install the older version of Vivado.

div>
Shi Lei


__._,_.___
Posted by: Shi Lei Han <shileihan-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>



__,_._,___
Picon

XSIM simulation question



Hi,

Does anyone have a guide or any pointers for getting XSIM working for the template demo bard designs for GRLIB? I tried to run XSIM with the Digilent NEXYS4DDR board template design and I am getting varies errors...

Thank you,

Shi Lei




__._,_.___
Posted by: shileihan-/E1597aS9LQAvxtiuMwx3w@public.gmane.org



__,_._,___
Picon

SPIMCTRL Module Access



Hi,

I am currently using the template design without any modifications for the Digilent NEXYS4DDR board (grilib-gpl-1.5.0-b4164\design\leon3-digilent-nexys4ddr). The demo board is running correctly and I am able to boot ELF files from the DDR memory at adddress 0x40000000 using the GRMON2 load and run commands.

However, I am not able to boot using the SPI flash. I flashed my bootloader using the GRMON2 spim flash load command and then verify the contents are correct using the spim flash dump command. When i try to boot the board from the spimctrl "ROM" address <at> 0x00000000, it fails. Doing a GRMON disassemble at address 0x00000000, it appears the contents at the location is not correct and does not match my bootloader binary. The GRMON2 mem 0x00000000 comma nd shows the same garbage data.

I assume the GRMON2 spim flash dump command is using the I/O space registers to dump the file and not AMBA AHB reads at address 0x00000000. Therefore, there must be something wrong with the "ROM" area. I verified the VHDL configuration against the GRLIB IP reference document and was not able to find anything obvious. Am I missing a step to configure the AMBA AHB reads to the spimctrl "ROM" address space in GRMON2? Or maybe something else is going on?

I probably should take a closer look at the memory contents of the spimctrl I/O registers. At this point, I appropriate any help or pointers because I am stuck... Please feel free to ask if I should provide any additional information.

Thank you,

Shi Lei

GR MON information:

  GRMON2 LEON debug monitor v2.0.70 32-bit eval version
 
  Copyright (C) 2015 Cobham Gaisler - All rights reserved.
  For latest updates, go to http://www.gaisler.com/
  Comments or bug-reports to support-FkzTOoA/JUlBDgjK7y7TUQ@public.gmane.org
 
  This eval version will expire on 22/06/2016

 JTAG chain (1): xc7a100t
  GRLIB build version: 4164
  Detected frequency:  70 MHz
 
  Component                            Vendor
  LEON3 SPARC V8 Processor             Cobham Gaisler
  AHB Debug UART                       Cobham Gaisler
  JTAG Debug Link                      Cobham Gaisler
  GR Ethernet MAC                      Cobham Gaisler
  AHB/APB Bridge                       Cobham Gaisler
  LEON3 Debug Support Unit             Cobham Gaisler
  S ingle-port DDR2 controller          Cobham Gaisler
  SPI Memory Controller                Cobham Gaisler
  Generic UART                         Cobham Gaisler
  Multi-processor Interrupt Ctrl.      Cobham Gaisler
  Modular Timer Unit                   Cobham Gaisler
  Generic UART                    &n bsp;    Cobham Gaisler
 
  Use command 'info sys' to print a detailed report of attached cores

grmon2> info sys
  cpu0      Cobham Gaisler  LEON3 SPARC V8 Processor   
            AHB Master 0
  ahbuart0  Cobham Gaisler  AHB Debug UART   
            AHB Master 1
  ahbjtag0  Cobham Gaisler  JTAG Debug Link   
            AHB Master 2
  greth0    Cobham Gaisler  GR Ethernet MAC   
   &nbs p;        AHB Master 3
            APB: 80000F00 - 80001000
            IRQ: 12
            edcl ip 192.168.0.48, buffer 2 kbyte
  apbmst0   Cobham Gaisler  AHB/APB Bridge   
            AHB: 80000000 - 80100000
  dsu0      Cobham Gaisler  LEON3 Debug Support Unit   
            AHB: 90000000 - A0000000
            AHB t race: 64 lines, 32-bit bus
            CPU0:  win 8, hwbp 2, itrace 64, V8 mul/div, lddel 1
                   stack pointer 0x47fffff0
                   icache 4 * 4 kB, 32 B/line, rnd
                   dcache 4 * 4 kB, 32 B/line, rnd
  ddr2spa0  Cobham Gaisler  Single-port DDR2 controller   
            AHB: 40000000 - 48000000
    &nb sp;       AHB: FFF00100 - FFF00200
            16-bit DDR2 : 1 * 128 MB <at> 0x40000000, 8 internal banks
            140 MHz, col 10, ref 7.8 us, trfc 135 ns
  spim0     Cobham Gaisler  SPI Memory Controller   
            AHB: FFF70000 - FFF70100
            AHB: 00000000 - 01000000
            IRQ: 7
            SPI memory device read command: 0x0b
  uart0&nbsp ;    Cobham Gaisler  Generic UART   
            APB: 80000100 - 80000200
            IRQ: 2
            Baudrate 38377, FIFO debug mode
  irqmp0    Cobham Gaisler  Multi-processor Interrupt Ctrl.   
            APB: 80000200 - 80000300
  gptimer0  Cobham Gaisler  Modular Timer Unit   
            APB: 80000300 - 80000400
            IRQ: 8
            8-bit scalar, 2 * 32-bit timers, divisor 70

SPIMCTRL flash dump's first 100 bytes

0000000 8010 0004 0001 0000 8010 0404 108e 0800
0000010 d091 0020 0001 0000 0001 0000 0001 0000
*
0000050 48a1 0000 1029 1000 c581 6023 0001 0000
*
0000064
hist
GRMON2 mem 0x00000000, disassembly and hist.

grmon2> disassemble 0x0
       0x00000000: ff108004  unknown opcode: 0xFF108004
       0x00000004: 00000000  unimp                    
       0x00000008: 00010000  unimp                     
       0x0000000c: 00000000  unimp                    
       0x00000010: 00108004  unimp                    
       0x00000014: 00000000  unimp                    
       0x00000018: 008e1000  bn  0x00384018 &n bsp;         
       0x0000001c: 00000000  unimp                    
       0x00000020: 0091d020  bn  0x004740A0           
   0=> 0x00000024: 00000000  unimp                    
       0x00000028: 00010000  unimp                    
  &nbs p;    0x0000002c: 00000000  unimp                    
       0x00000030: 00010000  unimp                    
       0x00000034: 00000000  unimp                    
       0x00000038: 00010000  unimp                    
       0 x0000003c: 00000000  unimp

grmon2> mem 0x0
  0x00000000  ff108004  00000000  00010000  00000000    ................
  0x00000010  00108004  00000000  008e1000  00000000    ................
  0x00000020  0091d020  00000000  00010000  00000000    ... ............
  0x00000030  00010000  00000000  00010000  00000000    ................

grmon2> hist 20
      TIME     ADDRESS   INSTRUCTIONS/AHB SIGNALS      RESULT/DATA
            0  00000000  AHB rea d   mst=0  size=0      [00000000]
          264  00000000  AHB read   mst=0  size=2      [FF108004]
          397  00000004  AHB read   mst=0  size=2      [00010000]
          530  00000008  AHB read   mst=0  size=2      [00108004]
          816  00000004  AHB read   mst=0  size=2      [00010000]
          949  00000008  AHB read   mst=0  size=2      [00108004]
         1082  0000000C  AHB read   mst=0  size=2      [048E1000]
         1215  00000010  AHB read   mst=0  size=2      [0891D020]
         1216  00000000  unknown opcode: 0xFF108004    [  TRAP  ]
         1348  00000014  AHB read   mst=0  size=2      [00010000]
         1481  00000018  AHB read   mst=0  size=2      [00010000]
         1614  0000001C  AHB read   mst=0  size=2      [00010000]
         1900  00000020  AHB read   mst=0  size=2      [0091D020]
         2033  00000024  AHB read   mst=0  size=2      [00010000]
         2166  00000028  AHB read   mst=0  size=2      [00010000]
         2299  0000002C  AHB re ad   mst=0  size=2      [00010000]
         2432  00000030  AHB read   mst=0  size=2      [0091D020]
         2433  00000020  bn  0x004740A0                [00000000]
         2565  00000034  AHB read   mst=0  size=2      [00010000]
         2566  00000024  unimp                    &nb sp;    [  TRAP  ]

SPIM status <=== I need to spend more time and look into the values...
grmon2> spim status
  SPI Memory Controller status information

  Control register setting:
    Chip select (CSN)                High
    Enable Alternate Scaler (EAS)    Not set
    Interrupt Enable (IEN)           Not set
    User control (USRC)              Not set
  Status register:
    Error (ERR)       & nbsp;              Not set
    Initalized (INIT)                Set
    Core busy (BUSY)                 Not set
    Operation done (DONE)            Set
 
grmon2> spim flash status
  Value of Status register: 0x00
    SRWD             : not set
    P_FAIL           : not set
    E _FAIL           : not set
    BP2              : not set
    BP1              : not set
    BP0              : not set
    WEL              : not set
    WIP              : not set

grmon2> mem 0xFFF70000
  0xfff70000  0000000b  00000008  00000005  00000000    ................
  0xfff70010  00000000  00000000  00000000  00000000    ................
  0xfff70020  00000000  00000000  00000000  00000000    ................
  0xfff70030  00000000  00000000  00000000  00000000    ................

__._,_.___
Posted by: shileihan-/E1597aS9LQAvxtiuMwx3w@public.gmane.org



__,_._,___

Gmane