[J-core] Did the boards arrive ok?

[Patrick Oppenlander]

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.

OK, so what's the setup for bare metal debugging? Is there a JTAG interface?

> (Also, our reset in current bitstreams haven't quite implemented all of software
> reset yet so "reboot" won't re-run the boot rom. It's something simple and
> stupid we haven't bothered to fix yet... I think the FPGA implements the "boot
> rom" as some plumbing clocking data into SRAM on power on, and then that sram
> gets reused by Linux but _not_ reloaded with boot rom contents by software
> reset? (Which says the boot rom is NOT still mapped into the address space,
> instead it gets overwritten...)
>
> It's easy enough to power cycle the thing that we haven't fixed that up yet. The
> hardware reset button also reloads the FPGA from SPI flash which reloads the
> boot rom contents. (ASIC would have an actual ROM, this is just an FPGA hack.)
>
> >>> A zoom howto would be great if we can make the times line up
> >>> (currently AEDT (UTC+11) here, switching to AEST (UTC+10) on April 4).
> >>>
> >>> The biggest thing missing for me is documentation. I did send an email
> >>> to the j-core list but didn't hear anything back.
> >>
> >> Darn it, gmail's spam filter is acting up again. :P
> >>
> >> Ok, fished 3 emails out of spam. Sigh. Thanks gmail. Replied to the first.
> >
> > It's 2021. AI can write entire news articles[1] but I still need to
> > dig mailing list threads out of the spam bucket :(
> >
> > [1] https://www.theguardian.com/commentisfree/2020/sep/08/robot-wrote-this-article-gpt-3
> >
> >>> I'm planning on bringing up my RTOS on it (apexrtos.com). Off the top
> >>> of my head I need at least:
> >>
> >> 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.

That message answers most of my questions. The only things I'd still like are:

* Information on bare metal debugging as I mentioned above.

* 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.

Patrick