<Boulet>
i am still trying to initialize A13's DDR3 :(
<mnemoc>
Laurent Ovaert?
<Boulet>
yup
<mnemoc>
welcome :)
<Boulet>
:)
<mnemoc>
Boulet: hurry and catch hipboi, before he is abducted by his boss
<Boulet>
yeah isn't he working for allwinner ?
<mnemoc>
Boulet: yes
<Boulet>
i have thought to visit them in Zhuhai since I am in Shenzhen
<hipboi>
mnemoc: you need to go to bed now
<mnemoc>
hipboi: indeed
<mnemoc>
good night, for real
<mnemoc>
f* A13
<Boulet>
A13 rocks !
kaspter has quit [Quit: Instantbird 1.1]
<WarheadsSE>
hipboi: can you do me a favor and fix this naming on the A100 page on your aliexpress store? "Arch Linux ARM" not "ARCH arm linux"
<hno>
mnemoc, that pin is just one resistor "R19" away from being used from what i can see in schematics. Would have expected that to be a jumper, not gpio controlled by default
<hipboi>
WarheadsSE: ok
<hipboi>
WarheadsSE: sorry
<Turl>
yay A10 repartitioning works :)
<hipboi>
good
<WarheadsSE>
ty hipboi
<hipboi>
hno: i just confirmed, a13 dram controller is different from a10
<Boulet>
glad to hear that now ;)
<hno>
how different?
<Boulet>
what about the BROMs ?
<hno>
BROM do not know about DRAM.
<hno>
but A13 BROM do differ from A10. Have not looked at details yet
<hipboi>
i will look at the difference
<hipboi>
but now i am assigned to study the linux schedule
<hipboi>
far from these
<hipboi>
sigh
<Boulet>
oh
<hno>
linux scheduler?
<hipboi>
yes
<hipboi>
for the multi core
<Turl>
linux scheduler is good on SMP :) doesn't need allwinerization haha
<hipboi>
i think so
<hipboi>
maybe we can take advantage of cgroup etc..
<Turl>
android uses cgroups
<hno>
cgroups and process groups both do wonders with scheduler.
<Turl>
is the nand layout the same on all devices?
<hno>
hipboi, A13 ddr controller looks marginally different from the sources i have.
<hno>
s/from/based on/
<ibot>
hno meant: hipboi, A13 ddr controller looks marginally different based on the sources i have.
<hipboi>
is marginally different very big different or small
<hipboi>
sorry for my english
<hno>
small
<hipboi>
ok
<hno>
hostport settings, ccm interfacing, zq settings. Maybe some other small detail.
<Turl>
although I'm not a fan of recovery with on screen buttons, it's like a halfway there solution
<Turl>
ZaEarl: btw, I repartitioned my zatab to fit JB better
rsalveti has quit [Remote host closed the connection]
lerc has joined #arm-netbook
MMlosh has quit [Ping timeout: 248 seconds]
MMlosh has joined #arm-netbook
<ZaEarl>
Turl, so put together a LiveSuit img that repartitions and installs JB all in one go.
QingPei has joined #arm-netbook
ZaEarl has quit [Quit: Ex-Chat]
ZaEarl has joined #arm-netbook
rsalveti has joined #arm-netbook
dyoung is now known as dyoung-away
ZaEarl has quit [Quit: Ex-Chat]
ZaEarl has joined #arm-netbook
Quarx has joined #arm-netbook
Gujs_ has joined #arm-netbook
tzafrir_laptop has quit [Ping timeout: 240 seconds]
Boulet has quit [Read error: Connection reset by peer]
Boulet has joined #arm-netbook
RITRedbeard has quit [Read error: Connection reset by peer]
RITRedbeard has joined #arm-netbook
<Mazon>
am I the only one that is unimpressed by the ouya? - quad core tegra, 1 GB ram, 8GB flash etc etc - for 99$, pretty nice! - HOWEVER, with a release date in 2013, early 2014 - thats actually quite shitty specs?
<Mazon>
ok, probably not shitty - but at least not so impressive
<Mazon>
if the ouya was ready soon - then it'd be something entirely different
<Mazon>
btw, anyone know what the expected price area for the cubieboard will be?
<Mazon>
too early in the morning for a rant I guess :)
<hno>
1GB RAM is a little on the low end for such a SoC. And it's Tegra
<Mazon>
my beef is, that these specs are great NOW, but not so great in early 2014
<rz2k>
to have a good production line in China you actally need to inspect everything yourself, every line, every stage, not by some hireable guy that will take money from both sides and say that everything is okay.
nibb has joined #arm-netbook
<rz2k>
I have a friend that runs OEM for testing equipment, cheap multimeters and such stuff, he was cheated by guys from globalsources/alibaba quite often till he realized that he need to control everything.
<Turl>
I could use a cheap multimeter :P
<mnemoc>
Mazon: you can get it from Tom
<rz2k>
meh, buy a Fluke. one multimeter forever, I had one that was ~7 years old, still works at my old job.
<Turl>
rz2k: 100-500USD >.< no thanks :)
<Mazon>
mnemoc, ?
<Mazon>
mnemoc: the above is about the Round Rhino, custom product afaik
<Turl>
from what I know, round rhino is similar to the oval elephant
<Mazon>
+ IR + UART + BCM Wifi/Bluetooth Module
<Turl>
yeah that
<Turl>
I was not sure if it was public info :)
<Mazon>
its in the forum - so I would assume that it is
<rz2k>
bcm...
<Turl>
rz2k: BCM wifi kills realtek's crap chips any day :)
<RaYmAn>
So, anyone tried out the JTAG stuff yet?
sspiff has joined #arm-netbook
sspiff has quit [Changing host]
sspiff has joined #arm-netbook
<mnemoc>
RaYmAn: you :)
<mnemoc>
Mazon: didn't know the difference between both
<Mazon>
the ovalelephant is similar to toms
<Mazon>
but the round rhino was something new
<RaYmAn>
mnemoc: yeah, was more thinking whether someone verified it yet? :)
<mnemoc>
RaYmAn: sure, I was joking ;-)
<RaYmAn>
I know :P
<RaYmAn>
I'm wondering the best way to do proper debugging..Maybe replacing either u-boot or kernel with a binary that has a single entrypoint and just loops forever? So one can jtag in, halt, load e.g. u-boot and debug through it
<RaYmAn>
since we have no way to start cpu in halt
<mnemoc>
`resume` doesn't do it?
<RaYmAn>
well, yeah, but like, when you apply power, it'll just run regularly until you jtag in and halt it
<RaYmAn>
so it's pretty hard to control how far it's gotten in initialization
<RaYmAn>
it mihgt be possible to soft-reset I guess
<mnemoc>
sounds like an important feature
<RaYmAn>
usually you have a hardware signal to reset, but given how we access it, that's not realy possible
<Turl>
RaYmAn: can't you say, stop on the uboot console
<Turl>
then chainload another uboot to debug it?
<RaYmAn>
probably, but doing it that way means uboot initialization code has already run
<RaYmAn>
which may or may not be an issue depending on what you want to debug
Boulet has quit [Remote host closed the connection]
<RaYmAn>
mnemoc: is it possible to access nand from mmcbooted kernel yet?
<Turl>
mnemoc: 512 ram? :P
<Turl>
mnemoc: btw, repartitioning went smoothly yesterday :)
Boulet has joined #arm-netbook
<Boulet>
mnemoc this is the output of uart0 right ?
<Boulet>
does A13 has JTAG pins available ?
<RaYmAn>
we don't really know
<RaYmAn>
I'm kind of thinking that it's identical to a10 in that matter
<CIA-121>
rhombus-tech: marco master * r648ab81b033f /allwinner_a10/ainol_novo_elf_7.mdwn:
<RaYmAn>
e.g. we can get jtag over microsd port by default (e.g. PF00,01,03 and 05 is set to JTAG by default))
<Boulet>
RaYmAn, not sure, there are less pins, they might have left that out
<Boulet>
ah ok
<RaYmAn>
I'll try it later - I'd just kind of like a full backup of my a13 device before I start playing with nand stuff (I don't really have a suitable livesuite image)
nibb has quit [Read error: Connection reset by peer]
nibb has joined #arm-netbook
<Boulet>
yeah would be nice if you could tell us if jtag works there
<Boulet>
UART0 was also not documented on A13 datasheet but it is there at same place as A10
<RaYmAn>
yeah, on PF02 and 04?
<RaYmAn>
so it makes sense they'd make jtag the same way as well
<Boulet>
yes
<RaYmAn>
do we have a fel-pio dump on an 13?
<Boulet>
yeah
<Boulet>
it's on github
<RaYmAn>
any hint on where? :P
<Boulet>
would be nice to make a jtag to SD adapter
<Boulet>
and also have UART0 on that, would be quite convenient
<RaYmAn>
yeah, should be possible
<RaYmAn>
well, that's what the microsd adapter from hipboi has, heh.
<CIA-121>
rhombus-tech: marco master * rd6024050a27f /allwinner_a10/ainol_novo_elf_7.mdwn:
<Boulet>
but what about this JTAG_SEL0/JTAG_SEL1 ?
<CIA-121>
rhombus-tech: marco master * r6a9eeb5cb755 /allwinner_a10/ainol_novo_elf_7.mdwn:
<Boulet>
GOSH
<Boulet>
hahaha
<Boulet>
i want that :-D
<RaYmAn>
I don't think it's generally for sale, but hipboi might be able to hook you up with one
<Boulet>
i hope i can even go see, him i am in shenzhen ;)
<RaYmAn>
heh
<Boulet>
this is smart that they placed uart0 and jtag on the sd-card slot !
<RaYmAn>
yeah
<RaYmAn>
I took that idea and I've successfully used it on ASUS Transformer & Transformer Prime as well (and it should work on all tegra devices) - only UART though.
<Boulet>
you mean they also export it on the SD card ? neat
<RaYmAn>
well, they don't by default
<RaYmAn>
but it so happens to be one the functions those pins can take on through pinmuxing
<Boulet>
ah right
<RaYmAn>
so it won't give you bootloader output unless you are running a custom u-boot
<RaYmAn>
but it'll let you get kernel output
<RaYmAn>
(with a custom kernel as well, of course, but that's easier to get :P)
<Boulet>
you use openocd for jtag ?
<RaYmAn>
mnemoc: got a fel-pio dump of the a13 board? I can't seem to find it anywhere
<RaYmAn>
yeah
<Boulet>
this works well with cortex-a8 ? never tried
<RaYmAn>
it works, but given I've had to try and patch together a config file, it doesn't work perfectly :P
<RaYmAn>
openocd has pretty good a8 support as far as I can tell
<zenitraM>
can we expect a sun6i cubieboard sometime? :P
<RaYmAn>
I'd imagine sun6i has to come out first? ;)
<Boulet>
i bet an FPGA version of it already exists hehe
<RaYmAn>
probably
<rz2k>
interesting, did allwinner actually fix heating issues in sun6i? a10 is pretty hot, guys with mk802 placing heatsinks for heavy loads. I believe sun6i to be MPCore, so different asic layout will be used, but still..
<rz2k>
also, imx6 and tegra3 are in metal housings instead of usuall plastic ones.
<specing>
rz2k: it isn't as hot when running normal linux
<specing>
I guess mali isn't enabled
<rz2k>
cant say that my a10 on lyf1 was cold running linaro, especially when I've tested mplayer for an hour :p
<WarheadsSE>
xxiao_: I dont think that is an A10. I beleive it is supposed to be tegra3
<rm>
mine was uber hot when in Android
<rm>
mk802, that is
<xxiao_>
i was told the new mk802 will have axp209 integrated, due end of this month
<rm>
I now just run it at 300-1000MHz with the ondemand governor
<traeak>
ouya was last said to be tegra3 although i'm not so sure that's the best choice
<traeak>
too bad the t6xxx mali isn't going to be out before then
<traeak>
probably will kick the living crap out of tegra3's gpu
<WarheadsSE>
fair chance
<RaYmAn>
with some luck there'll even be cortex a15 out by then :P
<WarheadsSE>
not like the drivers out now are open enough though
<WarheadsSE>
getting accel working on the Mali is a bitch.
<WarheadsSE>
(in linux, with not-out of date X)
<Triffid_Hunter>
WarheadsSE: possible?
<WarheadsSE>
possible, yeah
<WarheadsSE>
just a PITA
<WarheadsSE>
Cedar would be nice too.
dfenwick has joined #arm-netbook
<RaYmAn>
mnemoc: did you play around with any custom kernels? :)
cubieboard has quit [Quit: Leaving]
<mnemoc>
RaYmAn: trying to get wip/lichee3-sunxi/import-sun5i compiling
<RaYmAn>
okay
<mnemoc>
updated drivers need int sw_get_chip_id(struct sw_chip_id *); implemented
<RaYmAn>
annoying
<mnemoc>
I'll just fake it for now
<RaYmAn>
are the drivers significantly different? Or well, is the hardware really any different? (Other than lacking some stuff)=
<mnemoc>
mostly all the same stuff
<RaYmAn>
'k
<mnemoc>
the goal should really be to merge sun4i and sun5i
<RaYmAn>
yeah
<mnemoc>
I've done some merging in 3.4
<RaYmAn>
We really need a way to dump full nand from fel :> hehe
Vayu has quit [Ping timeout: 265 seconds]
<mnemoc>
probably the best way is to push an small installer/recovery system to ram
<RaYmAn>
yeah
<specing>
Can't you use uboot for that?
<RaYmAn>
hm
<specing>
first load and then hexdump to console?
<RaYmAn>
over uart? :S
<RaYmAn>
won't that take...forever?
<specing>
no
<specing>
10kb/s
<specing>
I've booted Linux over serial before
<RaYmAn>
I suppose you only need to dump the first 10-20MB/s
<specing>
yep
<specing>
and uboot supports loady
<specing>
maybe it supports sendy too?
<RaYmAn>
can uboot access the full nand?
<mnemoc>
in theory...
<RaYmAn>
though,my issue is that I want a full dump before changing e.g. script.bin since I have no livesuite image :S
<Boulet>
i think the best is just to do a small program that will dump the nand to DDR3, then use fel to retrieve
<RaYmAn>
yeah, that's what I was thinking, but the question is how much is required to writ ethat :P
<RaYmAn>
presumably some pinmux setup, some nand setup, then talking to nand?
<mnemoc>
writing the full 4GB when you only need a couple of MB instead very nice
<Boulet>
RaYmAn basically yes
<Boulet>
fel is a good interface actually
<hno>
mnemoc, you should be able to hut uSD connector pins on the PCB using a needle
<Boulet>
you could pass some parameters to some functions via fel and ask fel to execute the function you want
<mnemoc>
hno: pushing up the front or the back?
<mnemoc>
don't want to break it
<hno>
usually the pcb connections are exposed at the back. But i have not seen what connector they are using.
<mnemoc>
ah, sorry... I thought you said I can open the slot
<mnemoc>
damn migrane :>
<mnemoc>
:<
<mnemoc>
can't think
<hno>
the slot shield is soldered for stability, no opening without desoldering.
<RaYmAn>
hno: does bootrom do different things wrt initialization when booting e.g. sd and fel? (Other than presumably setting up usb)
<mnemoc>
i would assume it's fel who sets up usb
<RaYmAn>
well, fel is in bootrom, sin't it?: P
Quarx|2 has joined #arm-netbook
sspiff has quit [*.net *.split]
Quarx has quit [*.net *.split]
lundman has quit [*.net *.split]
specing has quit [*.net *.split]
termleech has quit [*.net *.split]
arete74 has quit [*.net *.split]
robws has quit [*.net *.split]
<RaYmAn>
I'm mostly thinking about the idea about loading u-boot spl from fel
<mnemoc>
RaYmAn: not a new idea :p
* RaYmAn
doesn't know enough about a10/13 initialization sequence
<RaYmAn>
mnemoc: I know , I read it here! :P
sspiff has joined #arm-netbook
Quarx has joined #arm-netbook
lundman has joined #arm-netbook
specing has joined #arm-netbook
termleech has joined #arm-netbook
arete74 has joined #arm-netbook
robws has joined #arm-netbook
<mnemoc>
from Boulet we have a toy that initializes the A13 dram
<mnemoc>
so we are very near to the sun5i-mmc uboot
Quarx has quit [Ping timeout: 255 seconds]
tzafrir_laptop has quit [Ping timeout: 248 seconds]
<Boulet>
the watchdog code i found on git does not work well
<Boulet>
it does reset the chip once, but not more ;)
<Boulet>
i modified the sequence and now it works all the time
<Boulet>
it's useful to nicely come back to fel mode after your program as finished executed (or on demand)
<RaYmAn>
In reality I'm more thinking about manually loading uboot spl from jtag..Either from fel mode, or from a specially crafted sd binary that sets up jtag port on sd. i'm assuming bootrom loads the full "spl" binary to memory, then executes, so there's no dependency on sd as soon as it runs
<RaYmAn>
does that make sense? :P
<Boulet>
i don't know ;)
sspiff has quit [*.net *.split]
lundman has quit [*.net *.split]
specing has quit [*.net *.split]
termleech has quit [*.net *.split]
arete74 has quit [*.net *.split]
robws has quit [*.net *.split]
sspiff has joined #arm-netbook
termleech has joined #arm-netbook
lundman has joined #arm-netbook
specing has joined #arm-netbook
arete74 has joined #arm-netbook
robws has joined #arm-netbook
<Boulet>
on git there is a very small program that you can write on the SD-CARD so that the board boot into fel-mode at power-up
<Boulet>
i think for u-boot development, DDR3 initialization must be added to that program
<Boulet>
so upon reset, you go to fel mode, and DDR3 is also initialized
<Boulet>
from there, you can upload ever code you want anywhere, and execute whatever you want
<Boulet>
then if you want JTAG, it is up to you, but i think it is not even necessary
<RaYmAn>
probably not necessary, but fun! :)
<Boulet>
i admit it would be great to have
<hno>
For u-boot development the SPL works fine. The problem is SPL development.
<RaYmAn>
well, I do already have jtag on a10, and I'm fairly certain it'll work on a13 as well
<RaYmAn>
the hard part is just booting from sd and then suddenly changing to jtag over same pins :S
<hno>
Yes, everything indicates A13 have JTAG on PF just as A10 does.
<hno>
Booting from SD and then change to JTAG is not difficult.
<RaYmAn>
no, but it requires the SPL doing it presumably :)
<RaYmAn>
given they use same pins
<Boulet>
someone needs to write the code that read and write from NAND ;)
<RaYmAn>
well, does nand even work when booted from sd atm? :P
<RaYmAn>
Cause in my experience, it doesn't :P So that might be a good start
<mnemoc>
sure
<hno>
If adding the NAND driver to u-boot yes.
<hno>
it adds cleanly.
<Boulet>
hno, how big is the SPL ?
<RaYmAn>
it has to fit in sram doesn't it? Or am I misundertsanding the boot process?
<hno>
~15 KB with MMC driver.
<hno>
yes, SPL have to fit in SRAM.
<Boulet>
it seems NAND driver would be quite bigger than MMC driver, is that correct ?
<hno>
The full NAND driver with logical layer is way too big. Need to be isolated down to simple physical layer.
<Boulet>
right
<hno>
and need to figure out why almost any change breaks SPL..
<Boulet>
when u-boot loads the linux image from nand, it uses the full logical layer ?
<Boulet>
it already has a filesystem actually ?
<mnemoc>
by default it: nand read 40007800 boot;boota 40007800
<Boulet>
the nand blocks are 128KB if i remember correctly ?
<Boulet>
what is uboot's binary size ?
<Boulet>
if uboot fits in 1 nand block that will makes things quite easier :D
<mnemoc>
132336
<mnemoc>
mmc-only
<Boulet>
ah
<mnemoc>
an nanda's is.....
<mnemoc>
and*
<mnemoc>
245736
<hno>
Boulet, yes u-boot by default uses logical layer with partition table, filesystem driver etc.
<Boulet>
yeah so i wonder how it is supposed to be done
<Boulet>
reserve a few blocks for u-boot at the beginning of the flash ?
<Boulet>
and do custom nand-block chaining
<mnemoc>
u-boot.bin is a file in nanda
<mnemoc>
the kernel itself is written raw on a nand partition
<mnemoc>
nanda = vfat
Quarx|2 has quit []
Quarx has joined #arm-netbook
<Boulet>
ok
<Boulet>
there is no mystery, the BROM looks for a magic string
<Boulet>
to load boot0, so our custom boot0 will probably have to do something similar to locate u-boot and load it into SDRAM
<Boulet>
and if uboot takes several nand blocks, they will have to be linked, using the physical block index should be fine
<RaYmAn>
hno: am I right that you discovered there was some extra, possibly important stuff in the nand before nanda? Or is it safe to dump everything you can from regular booted kernel and then livesuit an a13 image for another (a13) device? Or Did I read stuff wrong? :P
<hno>
boot0 and boot1 resides in the first NAND erase blocks outside the logical layer
<RaYmAn>
that's the only thing?
<RaYmAn>
I'm mostly trying to figure out if I can whip up a livesuit image using the dumped nand* partitions and an a13 livesuite image :P So trying to figure out if those boot0/boot1 are fully generic across a10 or a13 or if there can be device specific stuff encoded in them
<hno>
it should be the only pieces in raw nand blocks.
<hno>
boot0 & boot1 are cpu specifc
<mnemoc>
hipboi's friend confirmed it's all in the first raw block
<RaYmAn>
ok
<hno>
it's more than one block.
<hno>
see src/format/nand_frmat.c
<Boulet>
ah cool
<Boulet>
that one is easy then
<Boulet>
but uboot cannot simply follow boot0/boot1
<Boulet>
ah yeah i remember the first block of a NAND is guaranteed to never be a bad block out of the factory
<Boulet>
probably for boot reasons
<Boulet>
maybe a megabyte or so should be reserved at the beginning of the nand flash
<RaYmAn>
on eMMC, it's even encoded in the eMMC protocol as seperate "emmc" boot partitions (not regular partitions)
<Boulet>
yeah here, some custom logic has to be done :(
<Boulet>
i think using a magic string followed by the number of the next physical nand block
DEAT has quit [Read error: Connection reset by peer]
DEAT has joined #arm-netbook
<hno>
RaYmAn, A10 is not using SD boot protocol as far as I know.
<RaYmAn>
hno: yeah, it's not using eMMC afaik (and I believe it only applies to eMMC)
<hno>
It applies to SD as well.
<RaYmAn>
oh
<hno>
And A1x can boot from eMMC. A13 even have 8-bit MMC bus capability. A10 only 4 bit bus width.
<RaYmAn>
fwiw, there is some work being done on using Android drivers (in particular opengles and friends) on plain GNU/Linux. Working on gingerbread roms so far, but ics and jb drivers are coming.
<RaYmAn>
Combined with wayland, it could work well =P
<traeak>
hno that's cool, thanfully documented. it's a pet peeve of mine, peopel give us spec docs and they tend to not tell you what the units are
<hno>
and get in touch with others hacking on devices with the same SoC. xda-developers is a good place to look.
<RaYmAn>
and perhaps check cyanogenmod github.. I'm fairly certain there are at least a couple of 8260 devices in there and kernel sources for those devices
<RaYmAn>
if you have fastboot boot, you should be able to get pretty far with dmesg output, /sys/ dumps and ramconsole (Assuming ramconsole is enabled in stock kernel)
<hno>
Quarx, pick the closest match to your device and work from there. Make sure you have full recovery available. UART access to bootloader & kernel is also preferred.
<RaYmAn>
hno: what compiler are you using for that a13 test1? codesourcery?
<mnemoc>
is it fear to destroy a mSD/SD adapter to get a "break out" :p
<mnemoc>
fair*
<hno>
OK. GPIO-2 PIN numbers are numbered lengthwise, not the normal pair numbering. Schematics have both.
<hno>
mnemoc, you have one of those strange SD card to uSD socket adapters?
<mnemoc>
at least a dozen
<hno>
how come?
<hno>
Most people only have uSD card to SD socket adapters.
<mnemoc>
sorry. uSD goes into SD
<mnemoc>
but inside they have a plastic thing with paths
<mnemoc>
which goes from uSD pins to fat SD pads
<hno>
Yes, but you can't fit that in the uSD socket.
<RaYmAn>
OK, JTAG works on A13 too (through same pins)
<hno>
RaYmAn, excellent! script.fex comments seemed to indicate pins was rearranged a bit, but may be just a silent error (no one notices unless using the comments as note on which pin goes where)
<RaYmAn>
hno: the pins in the script.fex I've seen are wrong for some reason (checked both A10 and A13) - the pins are swapped around in practice
<hno>
mnemoc, if BROM boot from SD works but Linux not then maybe one of the data pins is not working. I think BROM uses one-bit SD mode, maybe even SPI mode.
<hno>
i.e. one of pins 1,2,8 maybe isn't working in your board.
<hno>
RaYmAn, you should be able to JTAG the UART PIO settings
<hno>
but right.. you'll loose JTAG capability if SD gets enabled.
<RaYmAn>
indeed
<RaYmAn>
and given there's no jtag reset pin to hold it ready so I can jtag halt it early, it's hard to control
<hno>
Maybe Pin #99 is JTAG port select pin on A13. It's NC in datasheets which I do not beleive.