Re: Microblaze libgloss and gdb simulator

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