Microblaze libgloss and gdb simulator

Microblaze libgloss and gdb simulator

[Joel Sherrill]

Hi

Sorry to post to both newlib and gdb but I hope someone in one of the
communities will have the answer.

Does anyone know how to build and run a hello world on the microblaze
simulator in gdb using the microblaze-elf target and the code in libgloss?

I don't see a configuration in DejaGNU which would have given me a hint.  I
didn't see any microblaze GCC test results on that list either so that
appears to line up.

Thanks.

--joel

Re: Microblaze libgloss and gdb simulator

[Mike Frysinger]

On 22 Apr 2021 17:25, Joel Sherrill wrote:
> Sorry to post to both newlib and gdb but I hope someone in one of the
> communities will have the answer.
> 
> Does anyone know how to build and run a hello world on the microblaze
> simulator in gdb using the microblaze-elf target and the code in libgloss?
> 
> I don't see a configuration in DejaGNU which would have given me a hint. I
> didn't see any microblaze GCC test results on that list either so that
> appears to line up.

i think the answer is you can't with only released open source projects.

the microblaze gcc config specs refer to a libxil.a that doesn't appear in gcc
or newlib or libgloss, so i assume it's a bsp thing you get from xilinx.

ignoring that, the microblaze sim doesn't have syscall support hooked up.  so
it's only a CPU simulator atm.
-mike

Re: Microblaze libgloss and gdb simulator

[Joel Sherrill]

On Thu, Apr 22, 2021, 7:27 PM Mike Frysinger <vapier@gentoo.org> wrote:

> On 22 Apr 2021 17:25, Joel Sherrill wrote:
> > Sorry to post to both newlib and gdb but I hope someone in one of the
> > communities will have the answer.
> >
> > Does anyone know how to build and run a hello world on the microblaze
> > simulator in gdb using the microblaze-elf target and the code in
> libgloss?
> >
> > I don't see a configuration in DejaGNU which would have given me a hint.
> I
> > didn't see any microblaze GCC test results on that list either so that
> > appears to line up.
>
> i think the answer is you can't with only released open source projects.
>
> the microblaze gcc config specs refer to a libxil.a that doesn't appear in
> gcc
> or newlib or libgloss, so i assume it's a bsp thing you get from xilinx.
>

I assumed that as well. At least their code on GitHub is now mostly
permissive licenses. I just haven't figured out what precisely that library
would be. I found a directory named xil which I assume is promising.


> ignoring that, the microblaze sim doesn't have syscall support hooked up.
> so
> it's only a CPU simulator atm.
>

So it has no output whatsoever? Does it get used for anything?

We are resurrecting some old work that I did for a Microblaze port. I did
write an inbyte() and outbyte() which would normally come from the xil
library. But I don't have any idea how I figured out there was a uart at a
particular address. I swear I had it working to print then but now it
faults after the first instruction.

Is there any known good executable for it? Even just seeing it operate with
a linked executable that had a crt0 and did something would be helpful at
this point.

--joel

-mike
>

Re: Microblaze libgloss and gdb simulator

[Mike Frysinger]

On 22 Apr 2021 19:55, Joel Sherrill wrote:
> On Thu, Apr 22, 2021, 7:27 PM Mike Frysinger wrote:
> > ignoring that, the microblaze sim doesn't have syscall support hooked up.
> > so it's only a CPU simulator atm.
> 
> So it has no output whatsoever? Does it get used for anything?

afaict, correct.  the most basic sims just do CPU level stuff and then have
their state inspected, or communicate pass/fail via exit status or abort.
this behavior actually isn't that rare ... it's where most sims start.

> We are resurrecting some old work that I did for a Microblaze port. I did
> write an inbyte() and outbyte() which would normally come from the xil
> library. But I don't have any idea how I figured out there was a uart at a
> particular address. I swear I had it working to print then but now it
> faults after the first instruction.
> 
> Is there any known good executable for it? Even just seeing it operate with
> a linked executable that had a crt0 and did something would be helpful at
> this point.

ftr, i've never worked on microblaze.  i'm just reading the code and poking
the toolchain :).

getting i/o (or maybe just o) support into the sim shouldn't be terribly hard.
we could even do the normal libgloss syscalls.  the important things we need to
know are:
* how does outbyte work ?  is it writing to MMIO UARTs, or something else ?
* is there an interrupt or exception or specific insn that microblaze uses to
  trigger the hypervisor/monitor/whatever ?  if so, should be possible to wire
  that up in the microblaze port.  my reading of libgloss/microblaze/ isn't
  picking out anything interesting, but i'm by no means an expert here.

if you can figure out those bits, happy to help on the sim side.
-mike

Re: Microblaze libgloss and gdb simulator

[Mike Frysinger]

On 22 Apr 2021 21:19, Mike Frysinger via Gdb wrote:
> On 22 Apr 2021 19:55, Joel Sherrill wrote:
> > On Thu, Apr 22, 2021, 7:27 PM Mike Frysinger wrote:
> > > ignoring that, the microblaze sim doesn't have syscall support hooked up.
> > > so it's only a CPU simulator atm.
> > 
> > So it has no output whatsoever? Does it get used for anything?
> 
> afaict, correct.  the most basic sims just do CPU level stuff and then have
> their state inspected, or communicate pass/fail via exit status or abort.
> this behavior actually isn't that rare ... it's where most sims start.
> 
> > We are resurrecting some old work that I did for a Microblaze port. I did
> > write an inbyte() and outbyte() which would normally come from the xil
> > library. But I don't have any idea how I figured out there was a uart at a
> > particular address. I swear I had it working to print then but now it
> > faults after the first instruction.
> > 
> > Is there any known good executable for it? Even just seeing it operate with
> > a linked executable that had a crt0 and did something would be helpful at
> > this point.
> 
> ftr, i've never worked on microblaze.  i'm just reading the code and poking
> the toolchain :).
> 
> getting i/o (or maybe just o) support into the sim shouldn't be terribly hard.
> we could even do the normal libgloss syscalls.  the important things we need to
> know are:
> * how does outbyte work ?  is it writing to MMIO UARTs, or something else ?
> * is there an interrupt or exception or specific insn that microblaze uses to
>   trigger the hypervisor/monitor/whatever ?  if so, should be possible to wire
>   that up in the microblaze port.  my reading of libgloss/microblaze/ isn't
>   picking out anything interesting, but i'm by no means an expert here.
> 
> if you can figure out those bits, happy to help on the sim side.

here's wiring up the syscall path, but it's unclear whether we should do this
without changes landing in libgloss first.
-mike

--- a/sim/common/gennltvals.py
+++ b/sim/common/gennltvals.py
@@ -66,6 +66,7 @@ TARGETS = {
     'm32c',
     'm32r',
     'mcore',
+    'microblaze',
     'mn10200',
     'mn10300',
     'moxie',
--- a/sim/common/nltvals.def
+++ b/sim/common/nltvals.def
@@ -484,6 +484,37 @@
 /* end mcore sys target macros */
 #endif
 #endif
+#ifdef NL_TARGET_microblaze
+#ifdef sys_defs
+/* from syscall.h */
+/* begin microblaze sys target macros */
+ { "SYS_argc", 22 },
+ { "SYS_argn", 24 },
+ { "SYS_argnlen", 23 },
+ { "SYS_argv", 13 },
+ { "SYS_argvlen", 12 },
+ { "SYS_chdir", 14 },
+ { "SYS_chmod", 16 },
+ { "SYS_close", 3 },
+ { "SYS_exit", 1 },
+ { "SYS_fstat", 10 },
+ { "SYS_getpid", 8 },
+ { "SYS_gettimeofday", 19 },
+ { "SYS_kill", 9 },
+ { "SYS_link", 21 },
+ { "SYS_lseek", 6 },
+ { "SYS_open", 2 },
+ { "SYS_read", 4 },
+ { "SYS_reconfig", 25 },
+ { "SYS_stat", 15 },
+ { "SYS_time", 18 },
+ { "SYS_times", 20 },
+ { "SYS_unlink", 7 },
+ { "SYS_utime", 17 },
+ { "SYS_write", 5 },
+/* end microblaze sys target macros */
+#endif
+#endif
 #ifdef NL_TARGET_mn10200
 #ifdef sys_defs
 /* from syscall.h */
--- a/sim/microblaze/Makefile.in
+++ b/sim/microblaze/Makefile.in
@@ -15,6 +15,9 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
+# This selects the bfin newlib/libgloss syscall definitions.
+NL_TARGET = -DNL_TARGET_microblaze
+
 ## COMMON_PRE_CONFIG_FRAG
 
 SIM_OBJS = \
diff --git a/sim/microblaze/interp.c b/sim/microblaze/interp.c
index 2bd067c6dc51..ed29d020efbc 100644
--- a/sim/microblaze/interp.c
+++ b/sim/microblaze/interp.c
@@ -28,6 +28,7 @@
 
 #include "sim-main.h"
 #include "sim-options.h"
+#include "sim-syscall.h"
 
 #include "microblaze-dis.h"
 
@@ -162,11 +163,14 @@ sim_engine_run (SIM_DESC sd,
       delay_slot_enable = 0;
       branch_taken = 0;
       if (op == microblaze_brk)
-	sim_engine_halt (sd, NULL, NULL, NULL_CIA, sim_stopped, SIM_SIGTRAP);
+	{
+	  sim_engine_halt (sd, NULL, NULL, NULL_CIA, sim_stopped, SIM_SIGTRAP);
+	}
       else if (inst == MICROBLAZE_HALT_INST)
 	{
 	  insts += 1;
 	  bonus_cycles++;
+	  TRACE_INSN (cpu, "HALT (%i)", RETREG);
 	  sim_engine_halt (sd, NULL, NULL, NULL_CIA, sim_exited, RETREG);
 	}
       else
@@ -175,6 +179,7 @@ sim_engine_run (SIM_DESC sd,
 	    {
 #define INSTRUCTION(NAME, OPCODE, TYPE, ACTION)		\
 	    case NAME:					\
+	      TRACE_INSN (cpu, #NAME);			\
 	      ACTION;					\
 	      break;
 #include "microblaze.isa"
@@ -284,8 +289,18 @@ sim_engine_run (SIM_DESC sd,
 		    IMM_ENABLE = 0;
 	        }
 	      else
-		/* no delay slot: increment cycle count */
-		bonus_cycles++;
+		{
+		  if (op == brki)
+		    {
+		      RETREG = sim_syscall (cpu, CPU.regs[12], CPU.regs[5],
+					    CPU.regs[6], CPU.regs[7],
+					    CPU.regs[8]);
+		      PC = RD + INST_SIZE;
+		    }
+
+		  /* no delay slot: increment cycle count */
+		  bonus_cycles++;
+		}
 	    }
 	}
 
--- a/sim/microblaze/microblaze.isa
+++ b/sim/microblaze/microblaze.isa
@@ -110,6 +110,7 @@ INSTRUCTION(addi,
 	    INST_TYPE_RD_RA_IMM,
             CARRY = C_calc(RA, IMM, 0);
 	    RD = RA + IMM;
+	    TRACE_REGISTER (cpu, "r%i = r%i + %i", rd, ra, IMM);
 	    C_wr(CARRY);
 	    PC += INST_SIZE)
 
--- a/sim/testsuite/microblaze/pass.s
+++ b/sim/testsuite/microblaze/pass.s
@@ -1,6 +1,5 @@
 # check that the sim doesn't die immediately.
 # mach: microblaze
-# output:
 
 .include "testutils.inc"
 
--- a/sim/testsuite/microblaze/testutils.inc
+++ b/sim/testsuite/microblaze/testutils.inc
@@ -1,5 +1,12 @@
+# MACRO: system_call
+# Make a libgloss/Linux system call
+	.macro system_call nr:req
+	addi r12, r0, \nr;
+	brki r14, 8;
+	.endm
+
 # MACRO: exit
-	.macro exit nr
+	.macro exit nr:req
 	addi r3, r0, \nr;
 	bri 0;
 	.endm
@@ -7,6 +14,7 @@
 # MACRO: pass
 # Write 'pass' to stdout and quit
 	.macro pass
+	write 1, 1f, 5
 	exit 0
 	.data
 	1: .asciz "pass\n"
@@ -15,6 +23,7 @@
 # MACRO: fail
 # Write 'fail' to stdout and quit
 	.macro fail
+	write 1, 1f, 5
 	exit 1
 	.data
 	1: .asciz "fail\n"
@@ -27,3 +36,12 @@
 .global _start
 _start:
 	.endm
+
+# MACRO: write
+# Just like the write() C function; uses system calls
+	.macro write fd:req, buf:req, count:req
+	addi r5, r0, \fd;
+	addi r6, r0, \buf;
+	addi r7, r0, \count;
+	system_call 5
+	.endm

Re: Microblaze libgloss and gdb simulator

[Mike Frysinger]

On 24 Apr 2021 01:02, Mike Frysinger via Gdb wrote:
> On 22 Apr 2021 21:19, Mike Frysinger via Gdb wrote:
> > On 22 Apr 2021 19:55, Joel Sherrill wrote:
> > > On Thu, Apr 22, 2021, 7:27 PM Mike Frysinger wrote:
> > > > ignoring that, the microblaze sim doesn't have syscall support hooked up.
> > > > so it's only a CPU simulator atm.
> > > 
> > > So it has no output whatsoever? Does it get used for anything?
> > 
> > afaict, correct.  the most basic sims just do CPU level stuff and then have
> > their state inspected, or communicate pass/fail via exit status or abort.
> > this behavior actually isn't that rare ... it's where most sims start.
> > 
> > > We are resurrecting some old work that I did for a Microblaze port. I did
> > > write an inbyte() and outbyte() which would normally come from the xil
> > > library. But I don't have any idea how I figured out there was a uart at a
> > > particular address. I swear I had it working to print then but now it
> > > faults after the first instruction.
> > > 
> > > Is there any known good executable for it? Even just seeing it operate with
> > > a linked executable that had a crt0 and did something would be helpful at
> > > this point.
> > 
> > ftr, i've never worked on microblaze.  i'm just reading the code and poking
> > the toolchain :).
> > 
> > getting i/o (or maybe just o) support into the sim shouldn't be terribly hard.
> > we could even do the normal libgloss syscalls.  the important things we need to
> > know are:
> > * how does outbyte work ?  is it writing to MMIO UARTs, or something else ?
> > * is there an interrupt or exception or specific insn that microblaze uses to
> >   trigger the hypervisor/monitor/whatever ?  if so, should be possible to wire
> >   that up in the microblaze port.  my reading of libgloss/microblaze/ isn't
> >   picking out anything interesting, but i'm by no means an expert here.
> > 
> > if you can figure out those bits, happy to help on the sim side.
> 
> here's wiring up the syscall path, but it's unclear whether we should do this
> without changes landing in libgloss first.

Michael: what do you think of wiring up the libgloss syscalls for microblaze
via the brki insn ?  is there any prior art in this space for microblaze ?
i wouldn't want to try an allocate syscall space that's already used.
-mike

> --- a/sim/common/gennltvals.py
> +++ b/sim/common/gennltvals.py
> @@ -66,6 +66,7 @@ TARGETS = {
>      'm32c',
>      'm32r',
>      'mcore',
> +    'microblaze',
>      'mn10200',
>      'mn10300',
>      'moxie',
> --- a/sim/common/nltvals.def
> +++ b/sim/common/nltvals.def
> @@ -484,6 +484,37 @@
>  /* end mcore sys target macros */
>  #endif
>  #endif
> +#ifdef NL_TARGET_microblaze
> +#ifdef sys_defs
> +/* from syscall.h */
> +/* begin microblaze sys target macros */
> + { "SYS_argc", 22 },
> + { "SYS_argn", 24 },
> + { "SYS_argnlen", 23 },
> + { "SYS_argv", 13 },
> + { "SYS_argvlen", 12 },
> + { "SYS_chdir", 14 },
> + { "SYS_chmod", 16 },
> + { "SYS_close", 3 },
> + { "SYS_exit", 1 },
> + { "SYS_fstat", 10 },
> + { "SYS_getpid", 8 },
> + { "SYS_gettimeofday", 19 },
> + { "SYS_kill", 9 },
> + { "SYS_link", 21 },
> + { "SYS_lseek", 6 },
> + { "SYS_open", 2 },
> + { "SYS_read", 4 },
> + { "SYS_reconfig", 25 },
> + { "SYS_stat", 15 },
> + { "SYS_time", 18 },
> + { "SYS_times", 20 },
> + { "SYS_unlink", 7 },
> + { "SYS_utime", 17 },
> + { "SYS_write", 5 },
> +/* end microblaze sys target macros */
> +#endif
> +#endif
>  #ifdef NL_TARGET_mn10200
>  #ifdef sys_defs
>  /* from syscall.h */
> --- a/sim/microblaze/Makefile.in
> +++ b/sim/microblaze/Makefile.in
> @@ -15,6 +15,9 @@
>  # You should have received a copy of the GNU General Public License
>  # along with this program.  If not, see <http://www.gnu.org/licenses/>.
>  
> +# This selects the bfin newlib/libgloss syscall definitions.
> +NL_TARGET = -DNL_TARGET_microblaze
> +
>  ## COMMON_PRE_CONFIG_FRAG
>  
>  SIM_OBJS = \
> diff --git a/sim/microblaze/interp.c b/sim/microblaze/interp.c
> index 2bd067c6dc51..ed29d020efbc 100644
> --- a/sim/microblaze/interp.c
> +++ b/sim/microblaze/interp.c
> @@ -28,6 +28,7 @@
>  
>  #include "sim-main.h"
>  #include "sim-options.h"
> +#include "sim-syscall.h"
>  
>  #include "microblaze-dis.h"
>  
> @@ -162,11 +163,14 @@ sim_engine_run (SIM_DESC sd,
>        delay_slot_enable = 0;
>        branch_taken = 0;
>        if (op == microblaze_brk)
> -	sim_engine_halt (sd, NULL, NULL, NULL_CIA, sim_stopped, SIM_SIGTRAP);
> +	{
> +	  sim_engine_halt (sd, NULL, NULL, NULL_CIA, sim_stopped, SIM_SIGTRAP);
> +	}
>        else if (inst == MICROBLAZE_HALT_INST)
>  	{
>  	  insts += 1;
>  	  bonus_cycles++;
> +	  TRACE_INSN (cpu, "HALT (%i)", RETREG);
>  	  sim_engine_halt (sd, NULL, NULL, NULL_CIA, sim_exited, RETREG);
>  	}
>        else
> @@ -175,6 +179,7 @@ sim_engine_run (SIM_DESC sd,
>  	    {
>  #define INSTRUCTION(NAME, OPCODE, TYPE, ACTION)		\
>  	    case NAME:					\
> +	      TRACE_INSN (cpu, #NAME);			\
>  	      ACTION;					\
>  	      break;
>  #include "microblaze.isa"
> @@ -284,8 +289,18 @@ sim_engine_run (SIM_DESC sd,
>  		    IMM_ENABLE = 0;
>  	        }
>  	      else
> -		/* no delay slot: increment cycle count */
> -		bonus_cycles++;
> +		{
> +		  if (op == brki)
> +		    {
> +		      RETREG = sim_syscall (cpu, CPU.regs[12], CPU.regs[5],
> +					    CPU.regs[6], CPU.regs[7],
> +					    CPU.regs[8]);
> +		      PC = RD + INST_SIZE;
> +		    }
> +
> +		  /* no delay slot: increment cycle count */
> +		  bonus_cycles++;
> +		}
>  	    }
>  	}
>  
> --- a/sim/microblaze/microblaze.isa
> +++ b/sim/microblaze/microblaze.isa
> @@ -110,6 +110,7 @@ INSTRUCTION(addi,
>  	    INST_TYPE_RD_RA_IMM,
>              CARRY = C_calc(RA, IMM, 0);
>  	    RD = RA + IMM;
> +	    TRACE_REGISTER (cpu, "r%i = r%i + %i", rd, ra, IMM);
>  	    C_wr(CARRY);
>  	    PC += INST_SIZE)
>  
> --- a/sim/testsuite/microblaze/pass.s
> +++ b/sim/testsuite/microblaze/pass.s
> @@ -1,6 +1,5 @@
>  # check that the sim doesn't die immediately.
>  # mach: microblaze
> -# output:
>  
>  .include "testutils.inc"
>  
> --- a/sim/testsuite/microblaze/testutils.inc
> +++ b/sim/testsuite/microblaze/testutils.inc
> @@ -1,5 +1,12 @@
> +# MACRO: system_call
> +# Make a libgloss/Linux system call
> +	.macro system_call nr:req
> +	addi r12, r0, \nr;
> +	brki r14, 8;
> +	.endm
> +
>  # MACRO: exit
> -	.macro exit nr
> +	.macro exit nr:req
>  	addi r3, r0, \nr;
>  	bri 0;
>  	.endm
> @@ -7,6 +14,7 @@
>  # MACRO: pass
>  # Write 'pass' to stdout and quit
>  	.macro pass
> +	write 1, 1f, 5
>  	exit 0
>  	.data
>  	1: .asciz "pass\n"
> @@ -15,6 +23,7 @@
>  # MACRO: fail
>  # Write 'fail' to stdout and quit
>  	.macro fail
> +	write 1, 1f, 5
>  	exit 1
>  	.data
>  	1: .asciz "fail\n"
> @@ -27,3 +36,12 @@
>  .global _start
>  _start:
>  	.endm
> +
> +# MACRO: write
> +# Just like the write() C function; uses system calls
> +	.macro write fd:req, buf:req, count:req
> +	addi r5, r0, \fd;
> +	addi r6, r0, \buf;
> +	addi r7, r0, \count;
> +	system_call 5
> +	.endm

Re: Microblaze libgloss and gdb simulator

[Michael Eager]

On 4/25/21 10:21 AM, Mike Frysinger wrote:
> On 24 Apr 2021 01:02, Mike Frysinger via Gdb wrote:
>> On 22 Apr 2021 21:19, Mike Frysinger via Gdb wrote:
>>> On 22 Apr 2021 19:55, Joel Sherrill wrote:
>>>> On Thu, Apr 22, 2021, 7:27 PM Mike Frysinger wrote:
>>>>> ignoring that, the microblaze sim doesn't have syscall support hooked up.
>>>>> so it's only a CPU simulator atm.
>>>>
>>>> So it has no output whatsoever? Does it get used for anything?
>>>
>>> afaict, correct.  the most basic sims just do CPU level stuff and then have
>>> their state inspected, or communicate pass/fail via exit status or abort.
>>> this behavior actually isn't that rare ... it's where most sims start.
>>>
>>>> We are resurrecting some old work that I did for a Microblaze port. I did
>>>> write an inbyte() and outbyte() which would normally come from the xil
>>>> library. But I don't have any idea how I figured out there was a uart at a
>>>> particular address. I swear I had it working to print then but now it
>>>> faults after the first instruction.
>>>>
>>>> Is there any known good executable for it? Even just seeing it operate with
>>>> a linked executable that had a crt0 and did something would be helpful at
>>>> this point.
>>>
>>> ftr, i've never worked on microblaze.  i'm just reading the code and poking
>>> the toolchain :).
>>>
>>> getting i/o (or maybe just o) support into the sim shouldn't be terribly hard.
>>> we could even do the normal libgloss syscalls.  the important things we need to
>>> know are:
>>> * how does outbyte work ?  is it writing to MMIO UARTs, or something else ?
>>> * is there an interrupt or exception or specific insn that microblaze uses to
>>>    trigger the hypervisor/monitor/whatever ?  if so, should be possible to wire
>>>    that up in the microblaze port.  my reading of libgloss/microblaze/ isn't
>>>    picking out anything interesting, but i'm by no means an expert here.
>>>
>>> if you can figure out those bits, happy to help on the sim side.
>>
>> here's wiring up the syscall path, but it's unclear whether we should do this
>> without changes landing in libgloss first.
> 
> Michael: what do you think of wiring up the libgloss syscalls for microblaze
> via the brki insn ?  is there any prior art in this space for microblaze ?
> i wouldn't want to try an allocate syscall space that's already used.
> -mike

I never did anything with the SIM code for Microblaze.  I always used a
proprietary instruction set simulator provided by Xilinx.

I would not use a BRKI instruction, since the ABI has documented
its behavior.  Someone might write code which depends on this.

Microblaze doesn't have a system call instruction.  I would pick an
undefined op code and treat this as a SYS instruction, interpreting
it as call to libC or other system functionality.

This may (or may not) be helpful:  I implemented something similar to
this in QEMU for Qualcomm/Ubicom, where a SYSCALL (or some such)
instruction was translated into read, write, and other system calls.  It
was modeled on similar semihosting support in ARM, if I recall
correctly.  IIRC, functions in libgloss were thin wrappers around
the SYSCALL instruction.

-- 
Michael Eager

Re: Microblaze libgloss and gdb simulator

[Mike Frysinger]

On 25 Apr 2021 11:37, Michael Eager wrote:
> On 4/25/21 10:21 AM, Mike Frysinger wrote:
> > On 24 Apr 2021 01:02, Mike Frysinger via Gdb wrote:
> >> On 22 Apr 2021 21:19, Mike Frysinger via Gdb wrote:
> >>> On 22 Apr 2021 19:55, Joel Sherrill wrote:
> >>>> On Thu, Apr 22, 2021, 7:27 PM Mike Frysinger wrote:
> >>>>> ignoring that, the microblaze sim doesn't have syscall support hooked up.
> >>>>> so it's only a CPU simulator atm.
> >>>>
> >>>> So it has no output whatsoever? Does it get used for anything?
> >>>
> >>> afaict, correct.  the most basic sims just do CPU level stuff and then have
> >>> their state inspected, or communicate pass/fail via exit status or abort.
> >>> this behavior actually isn't that rare ... it's where most sims start.
> >>>
> >>>> We are resurrecting some old work that I did for a Microblaze port. I did
> >>>> write an inbyte() and outbyte() which would normally come from the xil
> >>>> library. But I don't have any idea how I figured out there was a uart at a
> >>>> particular address. I swear I had it working to print then but now it
> >>>> faults after the first instruction.
> >>>>
> >>>> Is there any known good executable for it? Even just seeing it operate with
> >>>> a linked executable that had a crt0 and did something would be helpful at
> >>>> this point.
> >>>
> >>> ftr, i've never worked on microblaze.  i'm just reading the code and poking
> >>> the toolchain :).
> >>>
> >>> getting i/o (or maybe just o) support into the sim shouldn't be terribly hard.
> >>> we could even do the normal libgloss syscalls.  the important things we need to
> >>> know are:
> >>> * how does outbyte work ?  is it writing to MMIO UARTs, or something else ?
> >>> * is there an interrupt or exception or specific insn that microblaze uses to
> >>>    trigger the hypervisor/monitor/whatever ?  if so, should be possible to wire
> >>>    that up in the microblaze port.  my reading of libgloss/microblaze/ isn't
> >>>    picking out anything interesting, but i'm by no means an expert here.
> >>>
> >>> if you can figure out those bits, happy to help on the sim side.
> >>
> >> here's wiring up the syscall path, but it's unclear whether we should do this
> >> without changes landing in libgloss first.
> > 
> > Michael: what do you think of wiring up the libgloss syscalls for microblaze
> > via the brki insn ?  is there any prior art in this space for microblaze ?
> > i wouldn't want to try an allocate syscall space that's already used.
> 
> I never did anything with the SIM code for Microblaze.  I always used a
> proprietary instruction set simulator provided by Xilinx.

the git history says it came from you :)
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=bd30e45a3430ce30c63146aa8cad0796754581b6

> I would not use a BRKI instruction, since the ABI has documented
> its behavior.  Someone might write code which depends on this.
> 
> Microblaze doesn't have a system call instruction.  I would pick an
> undefined op code and treat this as a SYS instruction, interpreting
> it as call to libC or other system functionality.
> 
> This may (or may not) be helpful:  I implemented something similar to
> this in QEMU for Qualcomm/Ubicom, where a SYSCALL (or some such)
> instruction was translated into read, write, and other system calls.  It
> was modeled on similar semihosting support in ARM, if I recall
> correctly.  IIRC, functions in libgloss were thin wrappers around
> the SYSCALL instruction.

the manual says for BRKI:
Application (user-mode) programs transfer control to system-service routines
(privileged mode programs) using the BRALID or BRKI instruction, jumping to
physical address 0x8. Executing this instruction causes a system-call exception
to occur. The exception handler determines which system-service routine to call
and whether the calling application has permission to call that service.
If permission is granted, the exception handler performs the actual procedure
call to the systemservice routine on behalf of the application program.
...
When MicroBlaze is configured to use an MMU (C_USE_MMU >= 1) this instruction
is privileged, except as a special case when "brki rD, 0x8" or "brki rD, 0x18"
is used to perform a Software Break. This means that, apart from the special
case, if the instruction is attempted in User Mode (MSR[UM] = 1) a Privileged
Instruction exception occurs.

isn't this a syscall handler ?  this is how Linux implements things too.
https://man7.org/linux/man-pages/man2/syscall.2.html#NOTES
       microblaze  brki r14,8            r12     r3   -    -

libgloss has:
# define SYSCALL_BODY(name)     \
    addik   r12, r0, SYS_ ## name;  \
    brki    r14, 8;         \
    rtsd    r15, 8;         \
    nop;
-mike

Re: Microblaze libgloss and gdb simulator

[Michael Eager]

On 4/25/21 1:27 PM, Mike Frysinger wrote:
> On 25 Apr 2021 11:37, Michael Eager wrote:
>> On 4/25/21 10:21 AM, Mike Frysinger wrote:
>>> On 24 Apr 2021 01:02, Mike Frysinger via Gdb wrote:
>>>> On 22 Apr 2021 21:19, Mike Frysinger via Gdb wrote:
>>>>> On 22 Apr 2021 19:55, Joel Sherrill wrote:
>>>>>> On Thu, Apr 22, 2021, 7:27 PM Mike Frysinger wrote:
>>>>>>> ignoring that, the microblaze sim doesn't have syscall support hooked up.
>>>>>>> so it's only a CPU simulator atm.
>>>>>>
>>>>>> So it has no output whatsoever? Does it get used for anything?
>>>>>
>>>>> afaict, correct.  the most basic sims just do CPU level stuff and then have
>>>>> their state inspected, or communicate pass/fail via exit status or abort.
>>>>> this behavior actually isn't that rare ... it's where most sims start.
>>>>>
>>>>>> We are resurrecting some old work that I did for a Microblaze port. I did
>>>>>> write an inbyte() and outbyte() which would normally come from the xil
>>>>>> library. But I don't have any idea how I figured out there was a uart at a
>>>>>> particular address. I swear I had it working to print then but now it
>>>>>> faults after the first instruction.
>>>>>>
>>>>>> Is there any known good executable for it? Even just seeing it operate with
>>>>>> a linked executable that had a crt0 and did something would be helpful at
>>>>>> this point.
>>>>>
>>>>> ftr, i've never worked on microblaze.  i'm just reading the code and poking
>>>>> the toolchain :).
>>>>>
>>>>> getting i/o (or maybe just o) support into the sim shouldn't be terribly hard.
>>>>> we could even do the normal libgloss syscalls.  the important things we need to
>>>>> know are:
>>>>> * how does outbyte work ?  is it writing to MMIO UARTs, or something else ?
>>>>> * is there an interrupt or exception or specific insn that microblaze uses to
>>>>>     trigger the hypervisor/monitor/whatever ?  if so, should be possible to wire
>>>>>     that up in the microblaze port.  my reading of libgloss/microblaze/ isn't
>>>>>     picking out anything interesting, but i'm by no means an expert here.
>>>>>
>>>>> if you can figure out those bits, happy to help on the sim side.
>>>>
>>>> here's wiring up the syscall path, but it's unclear whether we should do this
>>>> without changes landing in libgloss first.
>>>
>>> Michael: what do you think of wiring up the libgloss syscalls for microblaze
>>> via the brki insn ?  is there any prior art in this space for microblaze ?
>>> i wouldn't want to try an allocate syscall space that's already used.
>>
>> I never did anything with the SIM code for Microblaze.  I always used a
>> proprietary instruction set simulator provided by Xilinx.
> 
> the git history says it came from you :)
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=bd30e45a3430ce30c63146aa8cad0796754581b6

Yeah.  Other than submitting it upsteam, I don't think I
did anything with the simulator.

>> I would not use a BRKI instruction, since the ABI has documented
>> its behavior.  Someone might write code which depends on this.
>>
>> Microblaze doesn't have a system call instruction.  I would pick an
>> undefined op code and treat this as a SYS instruction, interpreting
>> it as call to libC or other system functionality.
>>
>> This may (or may not) be helpful:  I implemented something similar to
>> this in QEMU for Qualcomm/Ubicom, where a SYSCALL (or some such)
>> instruction was translated into read, write, and other system calls.  It
>> was modeled on similar semihosting support in ARM, if I recall
>> correctly.  IIRC, functions in libgloss were thin wrappers around
>> the SYSCALL instruction.
> 
> the manual says for BRKI:
> Application (user-mode) programs transfer control to system-service routines
> (privileged mode programs) using the BRALID or BRKI instruction, jumping to
> physical address 0x8. Executing this instruction causes a system-call exception
> to occur. The exception handler determines which system-service routine to call
> and whether the calling application has permission to call that service.
> If permission is granted, the exception handler performs the actual procedure
> call to the systemservice routine on behalf of the application program.
> ...
> When MicroBlaze is configured to use an MMU (C_USE_MMU >= 1) this instruction
> is privileged, except as a special case when "brki rD, 0x8" or "brki rD, 0x18"
> is used to perform a Software Break. This means that, apart from the special
> case, if the instruction is attempted in User Mode (MSR[UM] = 1) a Privileged
> Instruction exception occurs.
> 
> isn't this a syscall handler ?  this is how Linux implements things too.
> https://man7.org/linux/man-pages/man2/syscall.2.html#NOTES
>         microblaze  brki r14,8            r12     r3   -    -
> 
> libgloss has:
> # define SYSCALL_BODY(name)     \
>      addik   r12, r0, SYS_ ## name;  \
>      brki    r14, 8;         \
>      rtsd    r15, 8;         \
>      nop;
> -mike

It depends on what code you are simulating.

If you are simulating a program which uses libgloss and you expect the
behavior of brki to be a syscall, then this is a very reasonable way
to implement system calls.  Instead of taking the branch to the handler,
the simulator does whatever host system call it is supposed to do, then
returns, just as if there was an OS handling the system call.  (This is
what QEMU calls "semihosting".)

I was thinking about the more general case, where you might be
simulating an image which includes an exception handler.  In this
case, the behavior you want is to take the exception and jump to the
excption handler address, instead of the simlator interpreting the
brki as a syscall.



-- 
Michael Eager

Re: Microblaze libgloss and gdb simulator

[Mike Frysinger]

On 25 Apr 2021 15:29, Michael Eager wrote:
> On 4/25/21 1:27 PM, Mike Frysinger wrote:
> > On 25 Apr 2021 11:37, Michael Eager wrote:
> >> On 4/25/21 10:21 AM, Mike Frysinger wrote:
> >>> On 24 Apr 2021 01:02, Mike Frysinger via Gdb wrote:
> >>>> On 22 Apr 2021 21:19, Mike Frysinger via Gdb wrote:
> >>>>> On 22 Apr 2021 19:55, Joel Sherrill wrote:
> >>>>>> On Thu, Apr 22, 2021, 7:27 PM Mike Frysinger wrote:
> >>>>>>> ignoring that, the microblaze sim doesn't have syscall support hooked up.
> >>>>>>> so it's only a CPU simulator atm.
> >>>>>>
> >>>>>> So it has no output whatsoever? Does it get used for anything?
> >>>>>
> >>>>> afaict, correct.  the most basic sims just do CPU level stuff and then have
> >>>>> their state inspected, or communicate pass/fail via exit status or abort.
> >>>>> this behavior actually isn't that rare ... it's where most sims start.
> >>>>>
> >>>>>> We are resurrecting some old work that I did for a Microblaze port. I did
> >>>>>> write an inbyte() and outbyte() which would normally come from the xil
> >>>>>> library. But I don't have any idea how I figured out there was a uart at a
> >>>>>> particular address. I swear I had it working to print then but now it
> >>>>>> faults after the first instruction.
> >>>>>>
> >>>>>> Is there any known good executable for it? Even just seeing it operate with
> >>>>>> a linked executable that had a crt0 and did something would be helpful at
> >>>>>> this point.
> >>>>>
> >>>>> ftr, i've never worked on microblaze.  i'm just reading the code and poking
> >>>>> the toolchain :).
> >>>>>
> >>>>> getting i/o (or maybe just o) support into the sim shouldn't be terribly hard.
> >>>>> we could even do the normal libgloss syscalls.  the important things we need to
> >>>>> know are:
> >>>>> * how does outbyte work ?  is it writing to MMIO UARTs, or something else ?
> >>>>> * is there an interrupt or exception or specific insn that microblaze uses to
> >>>>>     trigger the hypervisor/monitor/whatever ?  if so, should be possible to wire
> >>>>>     that up in the microblaze port.  my reading of libgloss/microblaze/ isn't
> >>>>>     picking out anything interesting, but i'm by no means an expert here.
> >>>>>
> >>>>> if you can figure out those bits, happy to help on the sim side.
> >>>>
> >>>> here's wiring up the syscall path, but it's unclear whether we should do this
> >>>> without changes landing in libgloss first.
> >>>
> >>> Michael: what do you think of wiring up the libgloss syscalls for microblaze
> >>> via the brki insn ?  is there any prior art in this space for microblaze ?
> >>> i wouldn't want to try an allocate syscall space that's already used.
> >>
> >> I never did anything with the SIM code for Microblaze.  I always used a
> >> proprietary instruction set simulator provided by Xilinx.
> > 
> > the git history says it came from you :)
> > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=bd30e45a3430ce30c63146aa8cad0796754581b6
> 
> Yeah.  Other than submitting it upsteam, I don't think I
> did anything with the simulator.
> 
> >> I would not use a BRKI instruction, since the ABI has documented
> >> its behavior.  Someone might write code which depends on this.
> >>
> >> Microblaze doesn't have a system call instruction.  I would pick an
> >> undefined op code and treat this as a SYS instruction, interpreting
> >> it as call to libC or other system functionality.
> >>
> >> This may (or may not) be helpful:  I implemented something similar to
> >> this in QEMU for Qualcomm/Ubicom, where a SYSCALL (or some such)
> >> instruction was translated into read, write, and other system calls.  It
> >> was modeled on similar semihosting support in ARM, if I recall
> >> correctly.  IIRC, functions in libgloss were thin wrappers around
> >> the SYSCALL instruction.
> > 
> > the manual says for BRKI:
> > Application (user-mode) programs transfer control to system-service routines
> > (privileged mode programs) using the BRALID or BRKI instruction, jumping to
> > physical address 0x8. Executing this instruction causes a system-call exception
> > to occur. The exception handler determines which system-service routine to call
> > and whether the calling application has permission to call that service.
> > If permission is granted, the exception handler performs the actual procedure
> > call to the systemservice routine on behalf of the application program.
> > ...
> > When MicroBlaze is configured to use an MMU (C_USE_MMU >= 1) this instruction
> > is privileged, except as a special case when "brki rD, 0x8" or "brki rD, 0x18"
> > is used to perform a Software Break. This means that, apart from the special
> > case, if the instruction is attempted in User Mode (MSR[UM] = 1) a Privileged
> > Instruction exception occurs.
> > 
> > isn't this a syscall handler ?  this is how Linux implements things too.
> > https://man7.org/linux/man-pages/man2/syscall.2.html#NOTES
> >         microblaze  brki r14,8            r12     r3   -    -
> > 
> > libgloss has:
> > # define SYSCALL_BODY(name)     \
> >      addik   r12, r0, SYS_ ## name;  \
> >      brki    r14, 8;         \
> >      rtsd    r15, 8;         \
> >      nop;
> 
> It depends on what code you are simulating.
> 
> If you are simulating a program which uses libgloss and you expect the
> behavior of brki to be a syscall, then this is a very reasonable way
> to implement system calls.  Instead of taking the branch to the handler,
> the simulator does whatever host system call it is supposed to do, then
> returns, just as if there was an OS handling the system call.  (This is
> what QEMU calls "semihosting".)

yes, this is exactly what we were thinking.  i wasn't aware of the QEMU
terminology, thanks.  in the GNU sim, we call them "environments".  the
default is the virtual environment which behaves this way: there is only
one privilege level, and any exception processing is handled entirely in
the sim itself.

> I was thinking about the more general case, where you might be
> simulating an image which includes an exception handler.  In this
> case, the behavior you want is to take the exception and jump to the
> excption handler address, instead of the simlator interpreting the
> brki as a syscall.

absolutely this makes sense.  this would be the "operating" environment
where the sim wouldn't hijack anything, and it would be responsible for
emulating the various privilege levels such as setting mode bits and
transferring control to any registered exception handlers.  this would
be useful for e.g. fully simulating the Linux kernel & userland.

it sounds like we're in agreement.  if there's anyone you think we could
or should consult before moving forward, please loop them in.
-mike

Re: Microblaze libgloss and gdb simulator

[Michael Eager]

On 4/25/21 4:34 PM, Mike Frysinger wrote:
>> If you are simulating a program which uses libgloss and you expect the
>> behavior of brki to be a syscall, then this is a very reasonable way
>> to implement system calls.  Instead of taking the branch to the handler,
>> the simulator does whatever host system call it is supposed to do, then
>> returns, just as if there was an OS handling the system call.  (This is
>> what QEMU calls "semihosting".)
> 
> yes, this is exactly what we were thinking.  i wasn't aware of the QEMU
> terminology, thanks.  in the GNU sim, we call them "environments".  the
> default is the virtual environment which behaves this way: there is only
> one privilege level, and any exception processing is handled entirely in
> the sim itself.

The "semihosting" terminology may be an ARM-ism, rather than a QEMU-ism,
although that's where I saw it first mentioned.
https://www.keil.com/support/man/docs/armcc/armcc_pge1358787046598.htm
https://community.nxp.com/t5/LPCXpresso-IDE-FAQs/What-are-none-nohost-and-semihost-libraries/m-p/475327
The debugger (or debugger agent on the target) uses a side channel to
perform I/O on the host.

I wasn't aware of sim environments.  I haven't looked at gdb/sim in
a long time. :-)

>> I was thinking about the more general case, where you might be
>> simulating an image which includes an exception handler.  In this
>> case, the behavior you want is to take the exception and jump to the
>> excption handler address, instead of the simlator interpreting the
>> brki as a syscall.
> 
> absolutely this makes sense.  this would be the "operating" environment
> where the sim wouldn't hijack anything, and it would be responsible for
> emulating the various privilege levels such as setting mode bits and
> transferring control to any registered exception handlers.  this would
> be useful for e.g. fully simulating the Linux kernel & userland.
> 
> it sounds like we're in agreement.  if there's anyone you think we could
> or should consult before moving forward, please loop them in.

Go for it!

-- 
Michael Eager

Re: Microblaze libgloss and gdb simulator

[R. Diez]

> [...]
> Does anyone know how to build and run a hello world on the microblaze
> simulator in gdb using the microblaze-elf target and the code in libgloss?

Does it have to be the GDB simulator? QEMU seems to support the MicroBlaze too.

I am using QEMU to simulate a Cortex-M3 board, and writing to a particular memory address where a UART is supposed to be outputs the byte on the host 
console.

-- 
rdiez

Re: Microblaze libgloss and gdb simulator

[Joel Sherrill]

On Fri, Apr 23, 2021 at 1:17 AM R. Diez <rdiezmail-newlib@yahoo.de> wrote:

>
> > [...]
> > Does anyone know how to build and run a hello world on the microblaze
> > simulator in gdb using the microblaze-elf target and the code in
> libgloss?
>
> Does it have to be the GDB simulator? QEMU seems to support the MicroBlaze
> too.
>
> I am using QEMU to simulate a Cortex-M3 board, and writing to a particular
> memory address where a UART is supposed to be outputs the byte on the host
> console.
>

No it doesn't. We use Qemu on at least arm, aarch64, x86, and sparc. Even
though they tend to be just CPU simulators, the gdb simulators just tend to
be
easier to work with and can run a high percentage of RTEMS tests. When first
starting a port, you are focused primarily on startup and context switches,
and
the gdb simulators work great for that. The devices are so simple, that the
BSP
is trivial.

For interrupt and real device support, you do have to move to something
like qemu or real hardware. We likely will just have to move to it.

--joel


> --
> rdiez
>

Re: Microblaze libgloss and gdb simulator

[Mike Frysinger]

On 23 Apr 2021 07:48, Joel Sherrill wrote:
> On Fri, Apr 23, 2021 at 1:17 AM R. Diez <rdiezmail-newlib@yahoo.de> wrote:
> > > [...]
> > > Does anyone know how to build and run a hello world on the microblaze
> > > simulator in gdb using the microblaze-elf target and the code in
> > libgloss?
> >
> > Does it have to be the GDB simulator? QEMU seems to support the MicroBlaze
> > too.
> >
> > I am using QEMU to simulate a Cortex-M3 board, and writing to a particular
> > memory address where a UART is supposed to be outputs the byte on the host
> > console.
> >
> 
> No it doesn't. We use Qemu on at least arm, aarch64, x86, and sparc. Even
> though they tend to be just CPU simulators, the gdb simulators just tend to
> be
> easier to work with and can run a high percentage of RTEMS tests. When first
> starting a port, you are focused primarily on startup and context switches,
> and
> the gdb simulators work great for that. The devices are so simple, that the
> BSP
> is trivial.
> 
> For interrupt and real device support, you do have to move to something
> like qemu or real hardware. We likely will just have to move to it.

GNU sim can do these too ;), but i can see it being easier when most people
are contributing to QEMU already to make it just work.

newlib/libgloss missing bsp code wouldn't be addressed by sim selection
though :).
-mike

Re: Microblaze libgloss and gdb simulator

[Joel Sherrill]

On Fri, Apr 23, 2021 at 10:05 AM Mike Frysinger <vapier@gentoo.org> wrote:

> On 23 Apr 2021 07:48, Joel Sherrill wrote:
> > On Fri, Apr 23, 2021 at 1:17 AM R. Diez <rdiezmail-newlib@yahoo.de>
> wrote:
> > > > [...]
> > > > Does anyone know how to build and run a hello world on the microblaze
> > > > simulator in gdb using the microblaze-elf target and the code in
> > > libgloss?
> > >
> > > Does it have to be the GDB simulator? QEMU seems to support the
> MicroBlaze
> > > too.
> > >
> > > I am using QEMU to simulate a Cortex-M3 board, and writing to a
> particular
> > > memory address where a UART is supposed to be outputs the byte on the
> host
> > > console.
> > >
> >
> > No it doesn't. We use Qemu on at least arm, aarch64, x86, and sparc. Even
> > though they tend to be just CPU simulators, the gdb simulators just tend
> to
> > be
> > easier to work with and can run a high percentage of RTEMS tests. When
> first
> > starting a port, you are focused primarily on startup and context
> switches,
> > and
> > the gdb simulators work great for that. The devices are so simple, that
> the
> > BSP
> > is trivial.
> >
> > For interrupt and real device support, you do have to move to something
> > like qemu or real hardware. We likely will just have to move to it.
>
> GNU sim can do these too ;), but i can see it being easier when most people
> are contributing to QEMU already to make it just work.
>

We use the gdb sim on a number of targets. I love psim and the
mips/jmr3904.
We used sparc/sis embedded in gdb until Jiri Gaisler did a massive update
to it.
It is now a separate simulator for SPARC and RISC-V and does multicore.

>
> newlib/libgloss missing bsp code wouldn't be addressed by sim selection
> though :).
>

+1

My old outbyte() method writes to a very specific address which appears
to be a UART. But I see no reference to that in any gdb source of any
vintage.I wonder if I added something locally to gdb to have a UART on
the Microblaze and lost it over the years. Does this look like it would work
now to you?

https://github.com/heshamelmatary/rtems-microblaze/blob/master/c/src/lib/libbsp/microblaze/gdbmbsim/console/console-io.c#L47

I started a port a LONG time ago and apparently remember things fuzzy. :(

THanks.

--joel


> -mike
>

Re: Microblaze libgloss and gdb simulator

[Mike Frysinger]

On 23 Apr 2021 11:17, Joel Sherrill wrote:
> On Fri, Apr 23, 2021 at 10:05 AM Mike Frysinger wrote:
> It is now a separate simulator for SPARC and RISC-V and does multicore.

i recently merged my simple riscv sim port :)

> > newlib/libgloss missing bsp code wouldn't be addressed by sim selection
> > though :).
> 
> +1
> 
> My old outbyte() method writes to a very specific address which appears
> to be a UART. But I see no reference to that in any gdb source of any
> vintage.I wonder if I added something locally to gdb to have a UART on
> the Microblaze and lost it over the years. Does this look like it would work
> now to you?
> 
> https://github.com/heshamelmatary/rtems-microblaze/blob/master/c/src/lib/libbsp/microblaze/gdbmbsim/console/console-io.c#L47
> 
> I started a port a LONG time ago and apparently remember things fuzzy. :(

i looked through the committed history of the sim (which only goes back to
2009 for microblaze) and couldn't find any relevant references to this addr.

let me see how hard it is to enable SIM_AC_OPTION_HARDWARE for microblaze.
then we could connect dv-pal's tty output to that addr and it'd just work.
-mike

Re: Microblaze libgloss and gdb simulator

[Mike Frysinger]

On 23 Apr 2021 12:40, Mike Frysinger wrote:
> On 23 Apr 2021 11:17, Joel Sherrill wrote:
> > On Fri, Apr 23, 2021 at 10:05 AM Mike Frysinger wrote:
> > > newlib/libgloss missing bsp code wouldn't be addressed by sim selection
> > > though :).
> > 
> > +1
> > 
> > My old outbyte() method writes to a very specific address which appears
> > to be a UART. But I see no reference to that in any gdb source of any
> > vintage.I wonder if I added something locally to gdb to have a UART on
> > the Microblaze and lost it over the years. Does this look like it would work
> > now to you?
> > 
> > https://github.com/heshamelmatary/rtems-microblaze/blob/master/c/src/lib/libbsp/microblaze/gdbmbsim/console/console-io.c#L47
> > 
> > I started a port a LONG time ago and apparently remember things fuzzy. :(
> 
> i looked through the committed history of the sim (which only goes back to
> 2009 for microblaze) and couldn't find any relevant references to this addr.
> 
> let me see how hard it is to enable SIM_AC_OPTION_HARDWARE for microblaze.
> then we could connect dv-pal's tty output to that addr and it'd just work.

i sent you a patch.  with it, microblaze sim can now use the pal model to get
a very basic UART.  for example:

$ microblaze-elf-objdump -d pass

pass:     file format elf32-microblaze

Disassembly of section .text:

00000050 <_ftext>:
  50:	20600070 	addi	r3, r0, 112
  54:	b0004060 	imm	16480
  58:	f0600018 	sbi	r3, r0, 24
  5c:	20600061 	addi	r3, r0, 97
  60:	b0004060 	imm	16480
  64:	f0600018 	sbi	r3, r0, 24
  68:	20600073 	addi	r3, r0, 115
  6c:	b0004060 	imm	16480
  70:	f0600018 	sbi	r3, r0, 24
  74:	20600073 	addi	r3, r0, 115
  78:	b0004060 	imm	16480
  7c:	f0600018 	sbi	r3, r0, 24
  80:	2060000a 	addi	r3, r0, 10
  84:	b0004060 	imm	16480
  88:	f0600018 	sbi	r3, r0, 24
  8c:	20600000 	addi	r3, r0, 0
  90:	b8000000 	bri	0		// 90

$ ./run --hw-device '/pal@0x40600000/reg 0x40600000 64' ./pass
pass

basically writes to 0x40600018 will go to stdout.

ideally there would be a way to handle syscalls for microblaze.
i guess we should handle bri 0x8 here ?  hmm let me try that.
-mike