Need technical advice regarding MC68K embedded code. - Page 1
Forum section: electronics / general

author: rfdes
author_rank: Regular Contributor
timestamp: April 11, 2022, 04:43:21 pm
content: Hi -I am hoping someone may be fluent in MC68K embedded architecture that would be willing to toss questions/answers back and forth. I have a piece of HP test gear that uses the MC68030 processor and am attempting to troubleshoot some issues. In particular I am attempting map out the address space used for accessing the flash memory. I have the schematics to share but some of the address logic is in programmable PAL devices. I'm just looking for some tips as to how and approach the problem.Jim

author: pandy
author_rank: Contributor
timestamp: April 11, 2022, 09:42:56 pm
content: They can be more suitable MC68K forums - i strongly recommend to share your problem on Amiga and Atari ST forums, for Amiga you can try to start onhttp://eab.abime.net/- there are active MC68K HW and SW developers there, some of them are active also on Atari ST sites.

author: brucehoult
author_rank: Super Contributor
timestamp: April 11, 2022, 11:21:20 pm
content: What is 68k-specific in this question? 68k is just an instruction set and not really relevant to figuring out hardware around the chip.If you can record the address and data bus values (and R/W line) then you should be able to figure a lot out even without decoding the instructions being executed. But that's not hard either.

author: rfdes
author_rank: Regular Contributor
timestamp: April 12, 2022, 12:52:24 am
content: Quote from: pandy on April 11, 2022, 09:42:56 pmThanks for the advice. I will take you up on that suggestion.Jim

author: rfdes
author_rank: Regular Contributor
timestamp: April 12, 2022, 12:55:29 am
content: Quote from: brucehoult on April 11, 2022, 11:21:20 pmNot sure I agree. I need to better understand the 68K architecture and it has some unusual addressing modes (at least to me). I do agree that what I could do is hook the logic analyzer to everything and work through the address mapping in that manner but I have some specific questions that I would like to ask.Thanks for the response.Jim

author: brucehoult
author_rank: Super Contributor
timestamp: April 12, 2022, 01:30:17 am
content: Quote from: rfdes on April 12, 2022, 12:55:29 amAddressing modes aren't really an issue and aren't visible eternally. It's just how the address that appears on the bus is calculated internally. Addressing modes are nothing more than adding a constant and one or two registers (one register possibly multiplied by 2 or 4). If you are disassembling the code and reading it then sure of course you need to understand the addressing modes to know what the code is doing, but this is easy -- the program could just calculate the address using normal ADD etc instructions and the external result would be the same.If you have specific questions to ask, then why not ask them?

author: pandy
author_rank: Contributor
timestamp: April 12, 2022, 07:48:50 pm
content: MC68K has own unique characteristic - for example interrupt vector table is located from lowest address but usually ROM is located in different place so after start ROM need to overlap RAM to provide correct vector. This is implemented in HW and may be the case. 68030 is substantially more advanced (I/D cache, burst memory access and mmu) than plain 68000.

author: brucehoult
author_rank: Super Contributor
timestamp: April 12, 2022, 10:11:35 pm
content: Quote from: pandy on April 12, 2022, 07:48:50 pmOn the 6502 (for example) there is a specific output pin indicating that a vector table fetch is being made, which makes it easy to overlay a small ROM over RAM (or even another ROM). I don't recall anything like that on the 68k. I guess remapping has to be done via program code writing to a register. Or maybe CPU mode level can be used, I don't recall.QuoteOnly 256 bytes of each. As I recall from the time, even Mac programs that used self-modifying code were seldom troubled by the small caches on the '020 (instruction only) and '030. A *lot* of old stuff failed with the larger 4K caches on the '040.

author: pandy
author_rank: Contributor
timestamp: April 14, 2022, 07:51:47 pm
content: Quote from: brucehoult on April 12, 2022, 10:11:35 pmVBR register was introduced since 68010 so vector table could be relocated in arbitrary address but usually RAM is overlayed by ROM in hardware wayQuote from: brucehoult on April 12, 2022, 10:11:35 pm040 introduced lot of changes and as such some incompatibility - not sure if this was related to cache size only

author: Benta
author_rank: Super Contributor
timestamp: April 14, 2022, 08:25:25 pm
content: The notable thing about the 60000...030 bus interface was the asynchronous timing ('030 will also run synchronously), which necessitated a more complex address decoding scheme.I don't know if your HP machine runs asynchronously or not.

author: brucehoult
author_rank: Super Contributor
timestamp: April 15, 2022, 01:02:02 am
content: Quote from: pandy on April 14, 2022, 07:51:47 pm040 also didn't support some of the ridiculous addressing modes introduced in the 020 -- as with the 486 they were starting to introduce some of the implementation techniques pioneered by RISC such as pipelining, and needed to simplify the ISA.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 15, 2022, 03:12:49 am
content: Quote from: brucehoult on April 15, 2022, 01:02:02 amDo you know anything about the 68060, and how close or far it was to/from that goal?

author: brucehoult
author_rank: Super Contributor
timestamp: April 15, 2022, 09:14:13 am
content: Quote from: SiliconWizard on April 15, 2022, 03:12:49 amNot much, no.Apple moved to PowerPC before the 68060 was out. I believe there were upgrade cards for Amiga and know someone who probably had one, but I didn't look into it closely.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: April 15, 2022, 11:20:49 am
content: OP, what’s the goal? Perhaps there are other approaches, i.e. finding out that flash map by analyzing the ROM dump (quite easy if it’s a program ROM, I can do that for you, just post the dump).

author: DiTBho
author_rank: Super Contributor
timestamp: April 15, 2022, 01:32:34 pm
content: Quote from: brucehoult on April 15, 2022, 09:14:13 amThere were accelerating cards for A1200, A2000, A3000, and A4000.The most famous and used was thePhase5 CyberStorm Mk2-060It cost a fortune, something like 90% of one's month salaryThe board was ready for 68060@66MHz(1), and implemented a memory controller for four 72 pin SIMM sockets, accepting { 4, 8, 16, 32 } MB SIMMs@70ns, thus only able to address 128 MB of total dRAM.The onboard logic mapped any combinations of SIMMs into one contiguous block without the need of jumpers, and there was also an optional Fast SCSI 2 module - CyberSCSI Mk2 - which didn't fit mechanically into a desktop A3000, probably because designed mostly for A4000 Towers.(1) ready for 66Mhz, but since 50Mhz was cheaper it was more commonly used

author: DiTBho
author_rank: Super Contributor
timestamp: April 15, 2022, 01:35:54 pm
content: My personal opinion is:Speaking of software, the best m68k is 010, because it remains simple but solves two big problems with 000:- bus error frame can now be resumed- move sp now has the right superuser privilegeSpeaking of hardware, the best m68k is 020, because it introduces on-chip dynamic bus sizing, which allows you to design 8-bit data buses without too much effort. 030 is similar to 020, but it adds annoyance with cache.

author: rfdes
author_rank: Regular Contributor
timestamp: April 15, 2022, 03:55:52 pm
content: Quote from: abyrvalg on April 15, 2022, 11:20:49 amHi -I have a copy of the firmware divided into 6 images which gets loaded into 3 flash devices. I am attempting to concatenate the images and offset their map location so that I can perform a useful disassembly. I have the schematics and believe I have been successful in mapping most of the IO, in particular there is a Bootrom mapped into the address space at 0x0000_0000. My confusion is how the main flash is mapped into the address space as there are some programmable logic that I cannot resolve. I am not even sure if the bootrom reads the flash into ram and runs from that space. I think my only option is to get a logic analyzer to track the addresses. Most of my issues are that I don't 'speak' MC68K and need to take the time to do more studying. I will post the schematic if anyone wants to take a look. The schematic images are poor but any advice you can offer would be appreciated.ThanksA2 CPU.pdf(3031.12 kB - downloaded 69 times.)Here is a list of the mappings:BOOT 0000_0000 07FF_FFFF <<< The bootrom is only 256K, so does the flash map into the remaing space?NVRAM 0800_0000 0FFF_FFFFIO1 1000_0000 17FF_FFFFIO2 1800_0000 1FFF_FFFFDEVELOP 2000_0000 27FF_FFFFIO3 2800_0000 2FFF_FFFFFLOATP 0002_0000 NOT IN CPU SPACESIMMSZ 1000_0000 1007_FFFFADC_RD 1008_0000 100F_FFFFMISOSTATUS 1010_0000 1017_FFFFCONFIG_STAT 1028_0000 102F_FFFFREAR_STAT 1030_0000 1037_FFFF7SEG 1040_0000 1047_FFFFCTL1 1048_0000 104F_FFFFCTL2 1050_0000 1057_FFFFADC_WR 1058_0000 105F_FFFFVIDEO_CTL 1060_0000 1067_FFFFSND_CTL 1068_0000 106F_FFFFINT_CTL 1070_0000 1077_FFFFBRIGHT 1078_0000 107F_FFFFHPIB 1800_0000 1807_FFFF8742 1808_0000 180F_FFFFTIMER 1810_0000 187F_FFFFDELAY 1818_0000 181F_FFFFSIO 1820_0000 1827_FFFFRTC 1828_0000 182F_FFFFPALLET 2800_0000 2807_FFFFDSP_RAM 2820_0000 2827_FFFFDSP_IO 2828_0000 282F_FFFFDSP 2830_0000 2837_FFFFLAN 2838_0000 283F_FFFFDRAM C000_0000 FFFF_FFFF <<< all volatile ram is at 0xC000_0000.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 15, 2022, 04:36:39 pm
content: Quote from: brucehoult on April 15, 2022, 09:14:13 amYes, the PowerPC was one reason the 68060 was almost born-dead. (But yes, I do remember a few accelerator cards with it.)Out of curiosity, I downloaded the user's manual - it's freely available on NXP's website. =)A small quote:Quote

author: abyrvalg
author_rank: Frequent Contributor
timestamp: April 15, 2022, 06:06:27 pm
content: > I have a copy of the firmware divided into 6 images which gets loaded into 3 flash devices. I am attempting to concatenate the images and offset their map location so that I can perform a useful disassembly.That's typical embedded fw disasm problem - determine load addresses. This can be done by matching offsets/calls to function starts etc. Would you mind sharing the ROM?

author: rfdes
author_rank: Regular Contributor
timestamp: April 15, 2022, 06:32:41 pm
content: Quote from: abyrvalg on April 15, 2022, 06:06:27 pmThanks for the advice. I've attached the uncompressed binary images. I originally said 6 images but it is actually 7 images. Any help you can offer is much appreciated.Take care -

author: brucehoult
author_rank: Super Contributor
timestamp: April 16, 2022, 12:07:04 am
content: Quote from: DiTBho on April 15, 2022, 01:35:54 pmYes, the 68010 was properly virtualisable. The 2-instruction loop cache was also simple but effective.Coldfire is not bad, but maybe too late, and not much used now.It's pretty hard to find any advantage for 68k compared to Thumb2 or RV32IMC.Vince Weaver finds some 68000 code size advantage (and even more 8086, but not '386 or amd64) in his Linux Logo benchmark, and its LZSS decoder subroutine, but that doesn't translate to full applications and I think may be part familiarity and/or the code being designed around x86 from the start.http://www.deater.net/weave/vmwprod/asm/ll/Maybe I should find time to submit a Renesas RX entry.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: April 16, 2022, 09:25:18 am
content: rfdes, you’ve gunzipped Cxxx files from the fw update package and stripped 0x40 bytes headers to produce these ROM_x files? Those headers contain load addresses (0x40000000 in big endian for ROM_0) and they match the disassembly (i.e. bytes at +4 of ROM_0 disassemble to an absolute jump to 4000009C and there is a legit function starting at that addr). So just use addresses from headers (you can even code a simple IDA loader to accept files with headers and load them to correct addresses automatically).

author: rfdes
author_rank: Regular Contributor
timestamp: April 16, 2022, 11:55:13 am
content: Quote from: abyrvalg on April 16, 2022, 09:25:18 amYes, you are correct. I had no knowledge of the header format so I stripped them off. Thanks for that information! Do you have a reference showing the header's structure fields? Is there checksum information embedded also in the headers? The embedded code was generated in HP-Unix, which I have no experience.Your help has been very useful. thanks.Jim

author: abyrvalg
author_rank: Frequent Contributor
timestamp: April 16, 2022, 05:53:39 pm
content: Code:+0x00 magic - 02 0C 01 07+0x0C int32be_data_size+0x14 int32be_unknown - 0 in all roms except ROM_6+0x2C int32be_addr - load address+0x40 data

author: abyrvalg
author_rank: Frequent Contributor
timestamp: April 16, 2022, 06:47:30 pm
content: Update: confirming, 40000000+ looks like flash space. Just concatenate all ROM_x files in sequential order to produce an almost 4MB full image. The entry point is at 40000004, the startup function at 40000164 copies part of flash starting at 402ED5CC to DRAM C00C0000-C01418B4 (this part contains both code and data), clears BSS section C01418B4-C03AED0C.

author: rfdes
author_rank: Regular Contributor
timestamp: April 17, 2022, 12:40:45 pm
content: Quote from: abyrvalg on April 16, 2022, 06:47:30 pmYou've helped me tremendously. I really appreciate you taking the time to work through my images. I believe I can take this forward.Take care -Jim