Paul_V wrote on 2022-12-11, 21:40:

I've been able to track down the software used to flash Vortex86DX internal BIOS through JTAG port.
Also, found another datasheet, which is more comprehensive in terms of register control and functions (including L1\L2 cache control)

May I ask you for details (maybe on email)? I'm trying to figure out how to connect it with OpenOCD, and so far it detects 20 taps with ever changing IDs. Seems like either I fried something, or it didn't reset the board properly.

Also, have you tried SPIFLASH.EXE or XFLASH.EXE? At least last one should be able to upload/download the firmware from even SX.

tl;dr I have sound a few OEMs with useful stuff

http://web.archive.org/web/*/download.fabiatech.com.tw*
http://ftp.emacinc.com/SBC

Based on the documents that Paul_v is gladly shared, DM&P has a tablet computer appliance of sorts running Linux to use with their JTAG. Based on this, I'm not sure it'll be possible to find their official tool. :<

yottatsa wrote on 2022-12-17, 13:51:

Based on the documents that Paul_v is gladly shared, DM&P has a tablet computer appliance of sorts running Linux to use with their JTAG. Based on this, I'm not sure it'll be possible to find their official tool. :<

"I'm gonna go build my own theme park, with blackjack..." (c) Bender

My XILINX Parallel Cable III clone kind of works now all of a sudden (ECP mode) . IDK, maybe it was some faulty solder joint.

After examining more closely, I found out that the program specifically searches for MX25L2005 flash chip (RDID C2 20 12)
But my SoC has MX25L1605 (RDID C2 20 15), which is read sucesfully, but does not match the coded value.
The hardware part of the puzzle is more or less solved.

UPD:
Went the "quick&dirty" way, manually replacing the RDID hex value it wants.
The cable is working fine. The chip is detected, erased and programmed, but verifying fails and SoC is unable to boot the BIOS.
This is not surprising, given the different flash block structure and address range the code just gets corrupted. I'll try to dig deeper in the disassembled code to fix that.
Interestingly, a full 16Mbit chip dump passes the write and verify, but does not boot. I suppose only first 256KB are written\checked
(I do not exclude a chance of bricking device completely, as I also tried changing chip address ranges. Who knows, what could have been erased 0_o)

Anybody familiar with assembler and interested in helping reverse-engineer the code, please PM me 😀

MX25L1605:
16,777,216 x 1 bit structure; (16Mbit)
32 Equal Sectors with 64K byte each

MX25L2005:
2,097,152 x 1 bit structure; (2Mbit)
64 Equal Sectors with 4K byte each or
4 Equal Blocks with 64K byte each

Paul_V wrote on 2022-12-11, 21:40:

I've been able to track down the software used to flash Vortex86DX internal BIOS through JTAG port.
Also, found another datasheet, which is more comprehensive in terms of register control and functions (including L1\L2 cache control)

Finally found the jflash.exe somewhere on DM&P's ftp (PM me with your email/other contacts, since I can't reply in DM yet)!

yottatsa wrote on 2022-12-23, 01:26:

Paul_V wrote on 2022-12-11, 21:40:

I've been able to track down the software used to flash Vortex86DX internal BIOS through JTAG port.
Also, found another datasheet, which is more comprehensive in terms of register control and functions (including L1\L2 cache control)

Finally found the jflash.exe somewhere on DM&P's ftp (PM me with your email/other contacts, since I can't reply in DM yet)!

Well, I'll be... Christmas came early! 😀
This version of jflash did the trick. It still failed to verify the BIOS file it flashed, but the board booted fine and I can always reflash it from DOS just in case.
Much appreciated, yottatsa!

tl;dr I flashed my board, too, with Xilinx DLC7 cable.

Here are the utilities that Paul and I discovered. Please note that VirusTotal thinks that JFLASH.EXE is a virus.

yottatsa wrote on 2022-12-30, 23:23:

tl;dr I flashed my board, too, with Xilinx DLC7 cable.

Hi! Glad this worked out for you. Thanks for the feedback.
---------------------------------------------

Now, back to some more underclocking shenanigans:
After countless benchmarks, BIOS mods and tests I think I got the culprit, which prevents running some speed sensitive games properly.
The results I got over time were so erratic, I could not even tell if the were accurate at all. Below is the example to get the idea how erratic a simple TSC check can be with different utilities.

Combined results from several benchmarks gave me the view, that HWInfo on WinXP by far is the most consistent.
Below is the chart with results I got. The tests were performed on default 800Mhz and hardware strap underclocked 500Mhz SoC.
1) I cannot tell, if the clock frequency measurements are correct, but they are consistent with benchmark results at least. Frequency division in this case looks something like "DIv_Freq=CPU_Freq*(n/32)"
(with n being 3\5\8\11\12\14\16\32) and is not a straightforward division by 3/4/5...etc
2) Disabling L1 cache practically disables any frequency division beyond D/2. This is the reason some speed sensitive games cannot run properly. I get same result under DOS
I cannot explain the reasons behind this, whether it's a bug or hardware peculiarity.
Wonder if DX3 will act the same way.

P.S. I'm planning on editing my previous posts to remove obsolete or misleading info and consolidating it in my first post.

EBOX-3350 with Vortex86DX2 proved to be even more stubborn.
Clock division seem to affect performance even less and disabling L1 Cache throws clock division entirely out of the window.

UPD:
I just remembered, that PCI clock on VDX defaults at 33,3(3) Mhz, but there is a strap to run it at 66,6(6).
I did not check PCI clock on EBOX-3350DX2 and cannot now, since I it has been borrowed from a colleague.

I'm gonna do some testing on the DX3 fairly soon. Hopefully we can get it underclocked too.

Got an answer from ICOP, regarding L1 and divider on DX\DX2 (and probably MX too). Not an encouraging one.
Quote:
"It's the hardware limitation due to internal PLL (Phase-Locked Loops) design mechanism, the L1 cache must enabled in order to make internal variable clock divider work."

Still in the process of clarification about DX3.
Quote:
"The structure of VDX3, VDX2 and VDX is the same, so yes, the L1 cache is required for PLL"

rasteri wrote on 2023-01-08, 15:24:

I'm gonna do some testing on the DX3 fairly soon. Hopefully we can get it underclocked too.

Thank you again for all your efforts.
I have checked all my previous benchmarks and looks like DX3 is able to downclock a little more than DX. (60 for DX3 in Topbench compared to 65 for DX)
DX has DDR power saving feature, lowering it's score down to 48, but it works more like a bottleneck, rather than downclock. Not very stable.