[J-core] Did the boards arrive ok?

Thu Mar 25 22:19:52 UTC 2021

On Thu, Mar 25, 2021 at 12:59 PM Rob Landley <rob at landley.net> wrote:
>
>
>
> On 3/24/21 6:37 PM, Patrick Oppenlander wrote:
> > On Thu, Mar 25, 2021 at 9:34 AM Rob Landley <rob at landley.net> wrote:
> >>
> >> On 3/24/21 4:47 PM, Patrick Oppenlander wrote:
> >>> On Wed, Mar 24, 2021 at 8:21 PM Rob Landley <rob at landley.net> wrote:
> >>>>
> >>>> On 3/23/21 5:25 PM, Patrick Oppenlander wrote:
> >>>>>> Feel free to poke the j-core mailing list about any of this, it'd be nice to get
> >>>>>> progress reports there of people doing stuff with Turtle.
> >>>>>>
> >>>>>> Rob
> >>>>>
> >>>>> Hi Rob,
> >>>>>
> >>>>> Mine looks like it arrived in good condition, thanks again for sending
> >>>>> it. I don't know if it works as I haven't actually powered it on yet.
> >>>>>
> >>>>> I must have missed something because I haven't seen a user's guide.
> >>>>> That would be very helpful.
> >>>>
> >>>> Here's the manual we have. It's... not quite a 1.0 release, but hopefully helpful?
> >>>
> >>> Absolutely helpful - now I have a clue how the board works.
> >>>
> >>> GDB stub in the Boot ROM!? What a fantastic idea!! Can that be used
> >>> for Kernel debugging or is it just for early bring-up (register
> >>> poking, loading kernel images, etc)?
> >>
> >> Just for early bringup, once it hands off to the kernel that code's not
> >> listening to the serial port anymore. (It might still be mapped into the address
> >> space somewhere and in theory you could jump to it, but we haven't set up any
> >> sort of interrupt to do that...) It mostly gets used as an alternate bootloader
> >> when you haven't got something useful on the sd card. Faster compile/test cycles
> >> than popping out a physical card, especially since it's USB powered so you can
> >> (in theory, haven't tried it) power down the board and power it back up again
> >> via software control of the USB host.
> >>
> >> However, you can build kgdb into the kernel. I think Rich did that once and it
> >> worked? (We had to send patches upstream to get single stepping to work a couple
> >> years back...) And we use gdbserver on target sometimes.
>
> Update: after asking Jeff it turns out that the gdb stub _can_ keep listening,
> and even has a small bare metal libc you can link against and make system calls
> to. If the program it's running uses those libc calls for stdin and stdout then
> gdb provides the console and it stays listening and runs the program "under" the
> gdb stub the same way gdbserver would.
>
> Linux rips that all out in its setup and takes control of everything and talks
> to the serial port directly, but a bare metal program doesn't have to. So you
> _can_ run your own OS under the gdbsever stub if you write it that way...

Nice, reminds me of gdb semihosting on ARM.

I assume you need to leave some debug interrupts, some RAM, and
probably some other hardware alone for this to work, or do I have the
wrong mental model of how the gdb stub works?

> I should try to do a bare metal hello world program saying hello through gdbserver:
>
> https://github.com/j-core/bootrom/tree/master/libc
> https://github.com/j-core/bootrom/blob/master/gdb/syscalls.h
>
> (Don't ask me why https://github.com/j-core/bootrom/blob/master/gdb/gdb.c#L814
> isn't in libc...)
>
> Hmmm, except:
>
> https://github.com/j-core/bootrom/blob/master/gdb/gdb.c#L422
>
> Looks like it could use some TLC. :)
>
> > OK, so what's the setup for bare metal debugging? Is there a JTAG interface?
>
> There is, but ironically there's a bug in it. Again to do with single stepping
> if I recall? It's a microcoded 5 stage pipeline so "what the CPU read" and "what
> it's currently executing" are a couple clock cycles off at the best of times and
> then the AMOUNT of time an instruction can takes varies, and the first try at
> the jtag stuff counted how many clocks each instruction takes to figure out
> where a breakpoint occurs and such, and there's a couple places we were getting
> the count wrong and showing the wrong instruction.
>
> Presumably not that hard to fix, it just went on the todo heap and never came
> back off because we've perpetually swamped. (I may have slightly garbled that
> explanation because I knew what the issue was accurately in 2017 and haven't
> looked at it since...)
>
> Possibly the kind of thing the open source community would be good at if we got
> enough hardware and explanation in people's hands. :)

Absolutely. It's been at least 15 years since I've looked at VHDL, so
I'm probably not going to be any use there though :)

> >>>> Could we resume the rest on the list?
> >>>
> >>> Sure!
> >>
> >> cc'd for this reply, but you still need to re-ask re-post the rest of the
> >> previous email...
> >
> > Something weird is going on with the mailing list. I just found this
> > https://lists.j-core.org/pipermail/j-core/2021-March/000958.html in
> > the archive which looks like it never hit my gmail account.
>
> Technically it's something weird going on with _gmail_. It's not just this
> mailing list:
>
> http://lists.landley.net/pipermail/toybox-landley.net/2019-March/010314.html
>
> And it's not exactly a new issue:
>
> http://lists.landley.net/pipermail/aboriginal-landley.net/2011-April/000724.html
>
> But it is getting worse over the years. :(

In this case I couldn't find the message in my account _anywhere_.

> > That message answers most of my questions. The only things I'd still like are:
> >
> > * Information on bare metal debugging as I mentioned above.
>
> The bits of the gdbstub we used work, other bits have todo items but it's small
> and simple code.
>
> Jtag isn't enabled in the bitstream but we can enable it, but debugging _that_
> is a lot trickier. :)
>
> > * Documentation on the various J core implementations and SOC
> > peripherals. Something more than the instruction set, e.g. irq
> > entry/exit behaviours, mmu details, interrupt controller, serial port,
> > etc. For example, I found
> > https://lists.j-core.org/pipermail/j-core/2019-October/000863.html
> > which points at
> > https://www.renesas.com/us/en/doc/products/mpumcu/001/rej09b0171_superh.pdf
> > but that's dead.
> >
> > If possible, it would be great to collect this kind of stuff and host
> > it somewhere which won't disappear.
>
> The problem is it's somebody else's copyrighted documented we haven't got a
> license to distribute. We need to write new ones with the appropriate level of
> detail. (It's on the todo list...)
>

OK, so I plugged the board in. It boots, but dies before making it to
a terminal:

corrupted preempt_count: (efault)/0/0x122d41b8
WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:3596
finish_task_switch+0x1e6/0x1f8

CPU: 1 PID: 0 Comm: (efault) Not tainted 5.10.0 #1
PC is at finish_task_switch+0x1e6/0x1f8
PR is at finish_task_switch+0x1e6/0x1f8
PC  : 10026c0a SP  : 125dbee4 SR  : 400000f1
R0  : 0000002e R1  : 10403144 R2  : 10403144 R3  : 125da000
R4  : 000000f0 R5  : fde27373 R6  : 00000000 R7  : 00000000
R8  : 17ff6630 R9  : 17ff6aec R10 : 1203b180 R11 : 00000000
R12 : 10395dcc R13 : 00000000 R14 : 125dbee4
MACH: 0002d976 MACL: 00057fa8 GBR : 00000000 PR  : 10026c0a

Call trace:
 [<10303cfe>] __schedule+0x2a6/0x3f4

Code:
  10026c04:  mov.l     10026c18 <finish_task_switch+0x1f4/0x1f8>, r4
! 1036b128 <0x1036b128>
  10026c06:  jsr       @r1
  10026c08:  nop
->10026c0a:  trapa     #62
  10026c0c:  bra       10026b74
  10026c0e:  nop
  10026c10:  mov.b     @(r0,r3), r3
  10026c12:  mov.b     @(r0,r15), r1
  10026c14:  mov.l     r2, @(60,r0)

---[ end trace 63efafcb158aade5 ]---
random: crng init done

Patrick