[J-core] Did the boards arrive ok?

[Rob Landley]

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

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. :)

>>>> 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. :(

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

> Patrick

Rob