UMDK manufacturing, part 2: Software
Moderators: BigEvilCorporation, prophet36
-
- Very interested
- Posts: 115
- Joined: Fri Sep 18, 2015 2:56 pm
Re: UMDK manufacturing, part 2: Software
edited:continue reading
Last edited by Montserrat on Wed Nov 25, 2015 4:08 am, edited 2 times in total.
Re: UMDK manufacturing, part 2: Software
OK, here are a couple of things to try.
Firstly, let's see how the gdb-bridge integration tests fare. Connect a USB cable between your PC & UMDK, plug it into your MegaDrive, turn it on, then:
Now upload build.log somewhere (e.g dropbox, gdrive etc) and post a link here.
Secondly, let's try resetting the CPU with tracing enabled. Turn your MegaDrive off for a few seconds, then on again, then do this (note: hit ctrl-c after about 20s, by which time you should have received many "."s):
Now upload trace.log somewhere (e.g dropbox, gdrive, etc) and post a link here.
Firstly, let's see how the gdb-bridge integration tests fare. Connect a USB cable between your PC & UMDK, plug it into your MegaDrive, turn it on, then:
Code: Select all
$ cd ${HOME}/20150315/makestuff/hdlmake/apps/makestuff/umdkv2/gdb-bridge
$ (make deps 2>&1) > build.log
Secondly, let's try resetting the CPU with tracing enabled. Turn your MegaDrive off for a few seconds, then on again, then do this (note: hit ctrl-c after about 20s, by which time you should have received many "."s):
Code: Select all
$ cd ${HOME}
$ loader -t trace.bin -x 2
UMDKv2 Loader Copyright (C) 2014 Chris McClelland
Putting MD in reset...
Releasing MD from reset...
Dumping execution trace to trace.bin
................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................^C..............................................................................................................................................................................................................................................................................................................
Caught SIGINT, quitting...
$ dd if=/dev/zero of=fubar.bin bs=1024 count=64
64+0 records in
64+0 records out
65536 bytes (66 kB) copied, 0.000408051 s, 161 MB/s
$ logread fubar.bin trace.bin | head -10000 > trace.log
Re: UMDK manufacturing, part 2: Software
Possibly. I'm no expert with this kind of thing. What I will say is that Minty has successfully tested his UMDK cart on a European MD1, and I've tested my carts with a European MD2. You could try commenting out the "move.l #0x53454741, 0xA14000" line and re-running the build steps to generate firmware.bin, and then use spi-talk.xsvf to write the updated firmware to the flash.Montserrat wrote:um....was looking to TMSS license code...may be its something related to this.
Re: UMDK manufacturing, part 2: Software
Here's my trace: (dns updating atm, should work in 1 hour or so from when I make this post..)
http://dump.ettfyrtatre.se/trace_bin.zip
http://dump.ettfyrtatre.se/trace_bin.zip
Re: UMDK manufacturing, part 2: Software
No, please upload build.log and trace.log, not trace.bin.Burbruee wrote:Here's my trace: (dns updating atm, should work in 1 hour or so from when I make this post..)
http://dump.ettfyrtatre.se/trace_bin.zip
Re: UMDK manufacturing, part 2: Software
It's actually trace.log, I just named it wrong.prophet36 wrote:No, please upload build.log and trace.log, not trace.bin.Burbruee wrote:Here's my trace: (dns updating atm, should work in 1 hour or so from when I make this post..)
http://dump.ettfyrtatre.se/trace_bin.zip
-
- Very interested
- Posts: 115
- Joined: Fri Sep 18, 2015 2:56 pm
Re: UMDK manufacturing, part 2: Software
Sorry i cant upload the logs at this moment, got a problem with lubuntu, im in a login loop, im trying to figure how to fix that...
Re: UMDK manufacturing, part 2: Software
Edit: Never mind. You had a typo in your link. It should have been http://dump.ettfyratre.se/trace_bin.zip. It is the trace.bin though, not the trace.log.
Just use pastebin or similar, and don't zip the file. That way people can view it easily on tablets and smartphones, etc.
Fair enough. Next problem is:Burbruee wrote:It's actually trace.log, I just named it wrong.
Code: Select all
$ ping dump.ettfyrtatre.se
ping: unknown host dump.ettfyrtatre.se
Re: UMDK manufacturing, part 2: Software
OK, here's a comparison between your (dysfunctional) trace and my (functional) trace:Burbruee wrote:Here's my trace
Code: Select all
Prophet36: | Burbruee:
---------------------|---------------------
0 C RD 000000 00FF | 0 C RD 000000 0000
38 C RD 000002 FE00 | 38 C RD 000002 FE00
64 C RD 000004 0042 | 63 C RD 000004 0042
89 C RD 000006 0200 | 88 C RD 000006 0200
114 C RD 420200 46FC | 113 C RD 420200 0200
152 C RD 420202 2700 | 151 C RD 420202 2700
177 C RD 420204 4AB9 | 176 C RD 420204 4AB9
228 C RD 420204 4AB9 | 202 C RD 420206 00A1
253 C RD 420206 00A1 | 227 C RD 420208 00A1
278 C RD 420208 0008 | 252 C RD 42020A 6606
304 C RD 42020A 6606 | 361 C WB 00FDFE 020A
342 C RD A10008 0000 | 387 C WB 00FDFA 2714
367 C RD A1000A 0000 | 412 C WB 00FDFC 0042
379 C RD 42020C 4A79 | 437 C WB 00FDF8 4AB9
430 C RD 42020E 00A1 | 462 C WB 00FDF6 00A1
455 C RD 420210 000C | 488 C WB 00FDF2 4AB5
In the meantime, please try the following. Connect the USB cable and power the MegaDrive off then on again. Now:
Code: Select all
cd ${HOME}
wget -q http://www.swaton.ukfsn.org/old-umdkv2/sonic2.bin
loader -x 0
loader -w sonic2.bin:0 -x 1 -t trace.bin
logread sonic2.bin trace.bin | head -10000 > trace.log
Did the game run correctly?
-
- Very interested
- Posts: 86
- Joined: Fri Sep 25, 2015 4:16 pm
Re: UMDK manufacturing, part 2: Software
I can pull my Sega Genesis out of storage and give it a try. It can run in NTSC or PAL mode, so we can see if any issues lie there.
Re: UMDK manufacturing, part 2: Software
Oh, this is very strange that the clock speed would be different! It's not an NTSC-machine at all, it's a stock PAL MD1. And yes I did the SDRAM test and there was no difference when comparing the two files, I just re-ran all tests and it reads back fine.prophet36 wrote:Notice that the timestamps are similar; your clock speed seems to be slightly faster than mine (remember that these timestamps are taken from the UMDK's 48MHz clock, meaning the time between the first and second reads is 38*1000/48 = 792ns), so I'm guessing you have an NTSC machine. Since the UMDK SDRAM controller is designed to work with the MD's fast DMA cycles, and since you ran through the SDRAM test successfully (you did, right?), it's highly unlikely that this is due to the SDRAM controller not keeping up. So my guess would be the 2nd-stage bootloader is not being read from flash correctly. I'll have a think about how to fix that.
The game did not run with loader. Here's the log.
http://pastebin.com/7LSVRcPX
Re: UMDK manufacturing, part 2: Software
Finally getting a chance to do this. Noticing a bit of a discrepancy in the last step: my firmware.bin is only 1280 bytes.
Nothing mentioning the file in the install log either.
I'll retry step 1 on Ubuntu and see if it is different.
Code: Select all
$ gordon -v 1d50:602b -t indirect:1 -w firmware.bin:0x60000
Device: Micron/Numonyx/ST M25P40
Writing 0x00000500 bytes to address 0x00060000...
.....
$
Code: Select all
$ grep firmware.bin ${HOME}/x64.log
$
Re: UMDK manufacturing, part 2: Software
Yes, if I remember correctly you were also running Arch on your machine? I had the same problem also using arch, then I opened up the x64.txt file and found this line:Grind wrote:Finally getting a chance to do this. Noticing a bit of a discrepancy in the last step: my firmware.bin is only 1280 bytes.
Nothing mentioning the file in the install log either.Code: Select all
$ gordon -v 1d50:602b -t indirect:1 -w firmware.bin:0x60000 Device: Micron/Numonyx/ST M25P40 Writing 0x00000500 bytes to address 0x00060000... ..... $
I'll retry step 1 on Ubuntu and see if it is different.Code: Select all
$ grep firmware.bin ${HOME}/x64.log $
Code: Select all
cd ../../gdb-bridge/monitor/
make
cat monitor.bin ../../m68k/menu/menu.bin > $HOME/umdkv2-bin/firmware.bin
I already had a working toolchain installed in /opt/toolchains/sega/ and tried to build the menu program with that instead (using current sgdk version) and got it to build, re-ran the command to generate the firmware.bin. However this time it was way larger in size, larger than what prophet posted.
----
On my desktop computer I have a debian jessie installation, so I decided to start all over and use debian instead for messing with installing the software (since this is the recommended setup to use..)
Using debian everything built successfully this time and the firmware.bin ended up being C454 bytes this time which is correct.
-
- Very interested
- Posts: 115
- Joined: Fri Sep 18, 2015 2:56 pm
Re: UMDK manufacturing, part 2: Software
mmmHere is my build.log....something has gone terribly wrong for me its full of errors, trace didnt even worked.
https://mega.nz/#!rF8GEZwJ!uV-i50KIAIJk ... 1Ns7DjR1xA
Just in case, to make the build.log jumper config has to be J4 in EXT and the rest populated, cart in megadrive and conected via usb to pc?
Also what is suposed to happen after you plug the console? i put it on, hit enter to start the log, it works but i have shut down the console or it will never ends...
also trace log does not give me any "dots" and is generating an empty file...
I thing someting crashed my user config including paths and messed up all,...so... it is safe to start all over, i mean re-flashing the kit?
https://mega.nz/#!rF8GEZwJ!uV-i50KIAIJk ... 1Ns7DjR1xA
Just in case, to make the build.log jumper config has to be J4 in EXT and the rest populated, cart in megadrive and conected via usb to pc?
Also what is suposed to happen after you plug the console? i put it on, hit enter to start the log, it works but i have shut down the console or it will never ends...
also trace log does not give me any "dots" and is generating an empty file...
I thing someting crashed my user config including paths and messed up all,...so... it is safe to start all over, i mean re-flashing the kit?
Re: UMDK manufacturing, part 2: Software
Don't worry too much about that, I didn't really expect it to work. I'm just gathering information.Montserrat wrote:my build.log...its full of errors
That probably means the CPU is ending up trying to read from a region without auto-DTACK, or it's getting a double bus error, or it's ending up in an infinite loop in a region that does not generate any trace information (e.g the onboard RAM).Montserrat wrote:trace log does not give me any "dots" and is generating an empty file
Again, don't worry too much. I suspect all five carts have probably been built correctly, it's just a matter of tracking down the bad assumptions made by the software and VHDL. It's only to be expected that the bad assumptions will manifest themselves in different behaviour for different carts. I think we're making good progress towards tracking down the problem.
It may be worthwhile checking the file lengths - see comments above from people with failed firmware.bin builds. The firmware.bin file should be 50260 bytes long.
Can you try tracing the sonic2.bin also, please?