[Letux-kernel] [OpenOCD-devel] [PATCH]: d86217d board: add Skytone Alpha 400
H. Nikolaus Schaller
hns at goldelico.com
Wed Nov 18 19:04:01 CET 2020
> Am 18.11.2020 um 18:16 schrieb Lubomir Rintel <lkundrak at v3.sk>:
>
> 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.
Yes, I had to block it a while ago because there were too many spam robots.
> Let me share it here.
> Perhaps you help me with my registration or add it to the wiki.
I have manually enabled your account. Maybe you have to update the password first.
>
> 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.
Oh, cool!
> 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.
Well this is less scary than accidentially overwriting NAND by pressing the
wrong key combination during boot :)
> 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.
Good to know!
>
> 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
So you are making me curious and tempting to play with the L400 (and JTAG).
BR and thanks,
Nikolaus
More information about the Letux-kernel
mailing list