[J-core] Did the boards arrive ok?
Patrick Oppenlander
patrick.oppenlander at gmail.com
Wed Mar 31 00:39:58 UTC 2021
On Fri, Mar 26, 2021 at 10:12 PM Rob Landley <rob at landley.net> wrote:
>
>
>
> 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.
I would like the boot ROM to be buildable without requiring a special
toolchain too.
> 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.
Thanks.
> >>> 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.
And it happened to me with this one. Which is why it took me so long
to respond. Sorry.
> >>> 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...
The board you sent me came with a 16GB Sandisk SD card. That's what
happens if I power it on with what you sent. I can capture a full log,
but the answer is probably "rebuild everything and try again".
Unfortunately I'm deep in dayjob work at the moment so I won't be able
to look at this for a while.
Thanks for all your help so far, I really appreciate it.
Patrick
More information about the J-core
mailing list