[J-core] Did the boards arrive ok?

Rob Landley rob at landley.net
Wed Mar 24 22:49:15 UTC 2021


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.

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

Rob


More information about the J-core mailing list