[Letux-kernel] [OpenOCD-devel] [PATCH]: d86217d board: add Skytone Alpha 400
Lubomir Rintel
lkundrak at v3.sk
Wed Nov 18 18:16:37 CET 2020
On Wed, Nov 18, 2020 at 10:40:12AM +0100, H. Nikolaus Schaller wrote:
>
> > Am 17.11.2020 um 23:12 schrieb Lubomir Rintel <lkundrak at v3.sk>:
> >
> > On Sat, Oct 24, 2020 at 04:26:43PM +0200, H. Nikolaus Schaller wrote:
> >> Hi Lubomir,
> >>
> >> We try to do our best...
> >>
> >>> I've had to fix up
> >>> quite some issues to get the thing to build so I suspect they probably
> >>> don't run it?
> >>
> >> Well, it is unfortunately on really low priority for me. I just would have
> >> to open my Letux 400 and solder a connector for the serial console and close the
> >> device again :) So that I can see what is happening during hand-over from
> >> U-Boot to the kernel or if the kernel isn't booting to at least some login: prompt.
> >
> > Yes. My machine (that's an Elonex Onet+ I think) actually had a connector
> > (a 4-pin molex picoblade or something similar), accessible from the battery
> > compartment soldered from factory, though not the JTAG one.
>
> I have searched and finally found my Letux 400 devices... Two are early samples
> and they have a 4 pin connector. Yes, Molex picoblade fits. And interestingly
> I must have built a Max232 adapter years ago and did forget.
>
> Unfortunately the machines with connector don't boot. And the one which boots
> has no connector.
>
> >
> > In any case, I've got a setup with both UART and the JTAG hooked on at
> > this point.
>
> How did you set up JTAG?
I though it would be a good idea to add this to the
projects.goldelico.com wiki, but after I drafted an article locally, I
ended up unable to confirm my registration. Let me share it here.
Perhaps you help me with my registration or add it to the wiki.
Apologies for a long message, hopefully it's useful:
---8<---
=== Introduction ===
This short write-up will describe how do I connect to a Skytone Alpha 400
board (like the one in Letux 400) via JTAG and recover from botched flash.
I do use a OpenOCD's GPIO driver to bit-bang JTAG with a Raspberry Pi.
Please note that it is probably not the smartest way to do this and
certainly not the only one but works well enough using hardware you may
already have handy.
=== Wiring the hardware ===
The JTAG is either accessible from the fine pitch 24-pin flat cable
connector J500 on the bottom of the board (the cable can be connected via
the battery compartment) or from a set of test pads no the top of the
board.
The test pads are quite large and easy to solder to. I've chosen to do that
because I don't have a correct cable or a breakout.
See the details in schematics:
https://projects.goldelico.com/p/letux400/downloads/39/
https://projects.goldelico.com/p/letux400/downloads/38/
I've wired the JTAG pins to a rather arbitrarily chosen GPIO pins on a
Raspberry Pi like this:
__________
_ |
^ edge of the RPi ^ (_) |
|
3v3 Power 1 o o 2 5v Power
(I2C1 SDA) GPIO 2 3 o o 4 5v Power
(I2C1 SCL) GPIO 3 5 o o 6 Ground
(GPCLK0) GPIO 4 7 o o 8 GPIO 14 (UART TX)
Ground 9 o o 10 GPIO 15 (UART RX)
GPIO 17 11 o o 12 GPIO 18 (PCM CLK)
GPIO 27 13 o o 14 Ground
GPIO 22 15 o o 16 GPIO 23
3v3 Power 17 o o 18 GPIO 24
J500/9 or TP516 <--[TCK]-- (SPI0 MOSI) GPIO 10 19 o o 20 Ground -----------> Well, some ground somewhere
J500/7 or TP514 <--[TMS]-- (SPI0 MISO) GPIO 9 21 o o 22 GPIO 25 -------------[TDO]---> TP517 or J500/10
J500/8 or TP515 <--[TDI]-- (SPI0 SCLK) GPIO 11 23 o o 24 GPIO 8 (SPI0 CE0) --[TRST]--> TP513 or J500/6
Ground 25 o o 26 GPIO 7 (SPI0 CE1)
(EEPROM SDA) GPIO 0 27 o o 28 GPIO 1 (EEPROM SCL)
GPIO 5 29 o o 30 Ground
GPIO 6 31 o o 32 GPIO 12 (PWM0)
(PWM1) GPIO 13 33 o o 34 Ground
(PCM FS) GPIO 19 35 o o 36 GPIO 16
GPIO 26 37 o o 38 GPIO 20 (PCM DIN)
Ground 39 o o 40 GPIO 21 (PCM DOUT)
_ |
v ethernet/usb ports v (_) |
|
|
Pin names courtesy of https://pinout.xyz/.
Make sure to also connect the ground. None of the test pads is ground, so I
chose to connect the pin from the UART port.
=== Build OpenOCD ===
Get the OpenOCD fork with JZ4730 support. Effort is underway to merge this
into mainline, but we're not there yet.
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/lkundrak/openocd-jz4730.git
$ cd openocd-jz4730
$ git checkout lr/jz4730
$
Configure and build OpenOCD. Unfortuntately, I lost track of which
dependencies and configure options are needed. If someone finds out, please
add it here. I suppose you need to enable linux-gpiod support at the very
least:
$ ./configure --enable-linuxgpiod
$ make
$ sudo make install
$
Once it's installed you also need a configuration file. Here's what I use
for the wiring above:
$ cat >openocd.cfg <<EOF
adapter driver linuxgpiod
transport select jtag
linuxgpiod_gpiochip 0
linuxgpiod_tck_num 10
linuxgpiod_tms_num 9
linuxgpiod_tdo_num 25
linuxgpiod_tdi_num 11
linuxgpiod_trst_num 8
source [find board/skytone_alpha400.cfg]
EOF
If you wish to telnet to the Raspberry Pi remotely, like I do, add a
"bindto 0.0.0.0" line.
At this point it is a good idea that your setup works. Power on the board,
start OpenOCD and leave it running. You can either start it as root, or add
yourself to the gpio group.
$ openocd -f openocd.cfg
Open On-Chip Debugger 0.10.0+dev-01412-gbb09a0eb2-dirty (2020-09-26-12:54)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : Linux GPIOD JTAG/SWD bitbang driver
Info : This adapter doesn't support configurable speed
Info : JTAG tap: jz4730.cpu tap/device found: 0x0000024f (mfg: 0x127 (MIPS Technologies), part: 0x0000, ver: 0x0)
Info : starting gdb server for jz4730.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'telnet' connection on tcp/4444
Connect to OpenOCD from another terminal and check that things work:
$ telnet localhost 4444
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> reset
JTAG tap: jz4730.cpu tap/device found: 0x0000024f (mfg: 0x127 (MIPS Technologies), part: 0x0000, ver: 0x0)
> halt
Failed to enter Debug Mode!
MIPS32 only implemented
target halted in MIPS32 mode due to debug-request, pc: 0x800191dc
> nand probe 0
NAND flash device 'NAND 1GiB 3.3V 8-bit (Samsung)' found
>
If they don't then tough luck I guess.
=== Build U-Boot ===
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/lkundrak/u-boot.git u-boot-jz4740
$ git checkout lr/alpha400
$ make alpha400_nand_defconfig
$ make CROSS_COMPILE=mips64-linux-gnu-
CAT u-boot-with-spl.bin
CFGCHK u-boot.cfg
$
=== Recovering the NAND boot loader ===
One thing that you need to realize first: things are super-slow especially
if you're dicking around with Raspberry Pi GPIO bit-banging. They may be
faster if you use a reasonable JTAG dongle instead, like a grown-up man.
Please let me know if you try being one.
This means that you won't be recovering the whole NAND via JTAG, merely the
boot loader so that you can boot from the SD card.
A typical image with U-Boot and SPL (and quite some useless padding which
is convenient to ignore) will weight a little over 600K and will take a
little under 2 and a half our to copy.
Erase the first meg where the boot loader would go:
> nand erase 0 0 0x100000
erased blocks 0 to 7 on NAND flash device #0 'NAND 1GiB 3.3V 8-bit'
The erase block size is 128K (0x20000), so you need to erase in the
multiplies of 128K. The first erase block is the 4K of NAND SPL followed by
padding (the other 124K). Then goes the U-Boot proper.
The u-boot-with-spl.bin image contains just that: SPL, padding and U-Boot:
> nand write 0 u-boot-with-spl.bin 0
wrote file u-boot-with-spl.bin to NAND flash 0 up to offset 0x00099200 in 141.710613s (0.072 KiB/s)
>
=== Recovering the rest ===
TODO: Write this up.
Generally you'll want to spin put the Letux 400 Debian image and use
mtd-utils to erase and write the kernel and main partition.
=== Some random notes ===
It is possible to render JTAG inaccessible with software; e.g. by powering
down the processor, changing the JTAG pin function or perhaps crashing the
processor in some peculiar way. If you ruin your boot block in a way that
ends up disabling JTAG you can still recover with a bit of efrort.
When the machine powers up, it executes the internal boot ROM that fetches
the first 4K of NAND into the L1 caches. This is hardwired in the processor
and you can't ruin it. The NAND read takes some short time and you can
attach JTAG during this time.
Just power-on the machine and run "reset; halt" about a second or so
afterwards. If you're lucky the CPU will manage to halt running
instructions in the 0xbfc00000 range (where the ROM is mapped). This
requires some luck, but if you try hard enough you'll eventually succeed.
Or not.
---8<---
> Many years ago I developed an adapter to connect
> through a ribbon cable (after disassembling the '400) and use an OpenMoko
> Debug Board. But at that time there was no OpenOCD software for such a
> setup so I had to stop experiments.
>
> > I intend to get the thing booting as time permits. In the
> > other message I shot your way today [1] I shared what the situation
> > looks like at this point.
> >
> > [1] https://lists.goldelico.com/pipermail/letux-kernel/2020-November/005856.html
>
> Yes, great! I have pulled you patches to the letux repo (and renamed them a little):
>
> https://git.goldelico.com/?p=letux-kernel.git;a=heads
>
> What I have not yet done is rearranging and squashing anything.
>
> Anyways the key question for me is what to do next to help testing...
>
> BR and thanks,
> Nikolaus
>
More information about the Letux-kernel
mailing list