Re: Microblaze libgloss and gdb simulator
Mike Frysinger <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <YIOeg7Kr7aCs6lg6@vapier> |
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