[J-core] Did the boards arrive ok?
Rob Landley
rob at landley.net
Fri Mar 26 11:26:58 UTC 2021
On 3/25/21 5:19 PM, Patrick Oppenlander wrote:
> 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?
When the serial interrupt points to the GDB stub plumbing, it responds to
incoming bytes and sends outgoing bytes. Beyond that, I'd have to read the code
in bootrom/gdb/gdb.c and sh2.c to see what' it's doing.
The "gdbserial" protocol is reasonably straightforward, and the first ~150 lines
of gdb.c is a big comment explaining the protocol. (Quite possibly a 20 year old
version of it, but it seems compatible.)
Jeff tends to dig up code from the 1990's to find things that are reasonably
licensed for us to use and extend. :)
>> 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. :)
^^^ I.E. that: gdb.c is 936 lines, sh2.c is 641 lines. It's reasonably
straightforward, but as I said in need of some cleanup and fleshing out.
I have a todo item to rewrite the boot ROM to work with the same compiler Linux
uses (ala the "hello world" kernel) instead of needing Magic Elf Thing the
compile of which is EXPECTED to end with a build break. Jeff objects to me doing
this on cultural grounds, and preemptively refuses to merge the result, so I
haven't done it yet.
The main differences between the boot ROM and the hello world kernel is the boot
rom:
A) has a dram controller initialization function (boot/dev/ddr.c) which has to
run before anything you write to the DRAM physical address range will stay
(until then you can only write to SRAM or keep stuff in registers).
B) can load files from spi or sd card, doing simple FAT filesystem parsing and
ELF relocation of a binary (all that's under boot/files/)
C) it has a device tree blob it sets r4 to point to the start of.
D) the gdb stub, above.
(There's also that very simple C library in boot/libc, and some memory and CPU
test code you can enable as well if you like in boot/memtest.c and boot/tests
respectively, and some drivers for an LCD nobody has. SOMEWHERE there's
tftp/bootp code using the ethernet but we didn't push that to github and I can't
find a copy...)
Anyway, gluing that stuff onto the hello world kernel wouldn't actually be all
that hard. The device tree source is targets/boards/turtle_1v1/board.dts and
then it's converted into an assembly source file via this bit of tools/soc.mk:
dt.dtb: $(BOARD_DIR)/board.dts
$(DTC) -O dtb -o $@ -I dts $<
dt.S: $(BOARD_DIR)/board.dts
$(DTC) -O asm -o $@.tmp -I dts $<
cat $(TOP_DIR)/tools/dt_header.S $@.tmp > $@
Link that in and stick a pointer to the start of it in r4 before calling the kernel.
Then you'd stick the resulting new bootloader into the bitstream build as its
ROM using the logic in targets/boards/turtle_1v1/Makefile with the caveat that
you have to adjust the physical address the segments are mapped to so it's in
the SRAM... um, let's see:
boot/Makefile:LDFLAGS = -T linker/sh32.x
Which has:
MEMORY
{
ram : o = 0x00000000, l = 0x7d00
stack : o = 0x00007d00, l = 0x0300
}
Which looks like the sram is mapped at physical address 0? Um, lemme see, I
think it would be in "targets/boards/turtle_1v1". Let's see... (Grumble: not a
hardware dev.) The I/O device addresses are mapped into to the memory bus by
devices.vhd, but I don't see sram or dram mentioned here. pad_ring.vhd is
mapping stuff to pins sending signals OUTSIDE the chip... Ah, design.edn says:
{:dram [0x10000000 0x8000000]
Start and length, presumably? But no mention of sram.
Sigh, this is probably in components/cpu and I'm a lot more familiar with the j1
in ice40 layout, which hasn't got a cache controller so does this all in a very
simple/direct way.
Either that or the dram init might not be using a stack at all and doing
everything in registers (which is traditional)...
I'll cc: Jeff, he knows.
>>> 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 :)
I borrowed a VHDL book from Zach van Rijn right before the pandemic and really
need to get past chapter 2 at some point...
>> But it is getting worse over the years. :(
>
> In this case I couldn't find the message in my account _anywhere_.
I just had that problem with Brian Bartholomew's message. *shrug* Gmail.
>>> 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
Odd. What kernel (version/config) are you using? (Toybox's mkroot build booted
fine for me, last built... a week ago I think? "CROSS=sh2eb LINUX=~/linux/linux
scripts/mkroot.sh dropbear".) Also, built with what toolchain?
Sorry I didn't have spare sd cards to put in all the boards with known working
stuff. Nobody within walking distance sells them anymore and Fry's went out of
business. I should just mail order a 10-pack from Amazon but that didn't solve
the "I sat down to do thing X and can't find an sd card RIGHT NOW" problem each
time...
> Patrick
Rob
More information about the J-core
mailing list