QL flash programming

[Dave]

Hi all,

Does anyone know of any JEDEC compliant programs or utilities that can erase and programme flash in a QL? If so, would they be willing to share? I normally use socketed parts but I'm now using an SMD part on this almost finished board. I don't want to put a huge header on it and would like to program it in system in the QL using the QL

If such a thing doesn't exist, it could be the first bounty!?

For bounds, if it were a BASIC instruction it would have a way of reading the flash capabilities block using the JEDEC standard knock. With that data presented it could offer menu options to erase or write sectors. During the write cycles, multitasking needs to be disabled or the QL needs to be running off an OS image that isn't stored in the flash. In erase/program mode all cycles to the flash must be only abut programming. Other accesses elsewhere are ok, just not on the flash chip.

FLASH is taken *doh!* so I'll just give an example like so:

Code: Select all

JEDEC_R $E00000        [read datablock of flash starting at 14MB boundary]
JEDEC_EA $E00000       [erase ALL sectors of flash at 14MB]
JEDEC_E $E00000, N     [erase sector N of flash at 14MB]
JEDEC_W $E00000, N, flp1_myrom.img  
                       [write sector N of flash starting at 14MB with the image in file given]

The JEDEC_EA erase all command could have a flag and "Are you SURE?" for force erase of the boot block (brick's card). Otherwise, the boot block should never be erased.

Anyone wishing to know more about the JEDEC standard for flash can read:

https://web.archive.org/web/20090306191 ... d68-01.pdf

[Pr0f]

I don't know if you are aware of retrobrew - but there's a chap there - Will Sowerbutts - who wrote a flashing utility for Z80 - I think source is available - but I understand it runs standalone - so doesn't need the OS - in fact, flashing the ROM on a QL would need it to be 'out of the OS' when running anyway. Conveniently some Flash devices allow part updates and offer protected blocks or the abilty to flash some parts from code running in a protected part.

I seem to remember a mention of flashing on the forum here - possibly MK?

[Dave]

Exactly.

I'm using a flash that has a boot block with extra protection as that is just what I already have. It's a bit of a PITA sometimes. On the final boards I might use an evenly sectored flash with no boot sectors set aside.

I think it might be easier to port from C than Z80 assembly. The JEDEC door knock access cycles would be much more clearly documented.

I do see how multitasking does need to be disabled, with this being a single-threaded task with exclusive control of the machine during the erase and write cycles. Verifying and reading it can multitask. I don't know how hard it is to stop the scheduler for a mo. Can it even be stopped and restarted? Or does this require the QL to have an "out of OS experience!?!?!?"

Without this code, it's going to be a PITA to maintain, upgrade or install alternate OS and utilities. It would require a flash programmer, another whole computer, etc. I do anticipate that during the first year or two there would be many community updates to add new features or extend existing capabilities.

If that doesn't happen, I'll end up having to include an ESP32 or Pico on the board as a self-contained parallel flash programmer. Open source code probably already exists. I think being able to manage it from the QL would be a much more useful solution. A MCU and putting the flash in its own little power domain is technically easier but much less well integrated. It also still requires the same software, and the added complexity of supporting multiple external OS' for flashing and flash management.

An open source QL flash management tool available to all flash-using boards (Peter, Lion, Tetroid, etc) would be perfect. It is a challenge that shipping boards with alpha or beta code when it is problematic to update them without physically sending them to someone with the right equipment... No, this should be under the control of the owner, and open. Anyone should be able to participate in system development and be able to quickly distribute their neat new things out to the world.

I like the idea of a website with previous and current versions of ROM images. New Minerva releases. SMSQ/E pushes. Program images optimized for newer hardware and ready to run direct from flash. Arrange them into a layout plan on your flash, then download a global image or separate files and jump into your Flash Manager. Show it the files. It checks version numbers, asks you if you're sure you want to overwrite X with Y, verifies the image before erasing and writing it, verifies the new flash contents against the original and if it's good, goes up a menu or to the next file.

Aside from this I need a programming interface that's easy to use for upgrading CPLD and/or FPGA programming. That is much easier than a parallel flash. Especially when the flash is 16 or 32 bits wide.

The utility isn't just for me. It opens up the doors on so many potential project advancements for so many devs.

If the forum adds a "Bounty Programme" I'd put money down. (See my post in the Quanta Members area)

[tofro]

Writing a Flash update program isn't really rocket science - you write some magic byte sequences to some magic addresses with proper timing. Writing a generic flash updater, however, is. You not only need to detect the exact ID of the part (that information can be queried from the chip), you also need to know the width of the data bus, which is obviously system-specific. As you need to be in supervisor mode (to switch off multitasking) with interrupts disabled (to prevent an ISR from accidentally accessing the flash while you fiddle with it), there is no way to use the system-internal timers, so you need to use tight loops to implement the timing. You also obviously need to know where in the address space the flash actually lives.
Different flash chips will also have varying support for single-byte, multi-byte, and block write/erase. That basically means that a flash routine needs to be adapted to each and every system and its specific characteristics.

Whether it makes sense to implement flash update as a BASIC command (possible in theory) is probably opinion-based: A system developer might find it handy to simply use BASIC, but for a "normal user" it's probably a waste of ROM space for something he does once in a blue moon. I'd rather vote for a specific executable per system, maybe using publicly shared routines.

What you need in any case is some sort of binary exchange format that checksums the contents and allows its verification.

In the end, you'll always have some sort of chicken-and-egg problem for new devices anyways.

[Pr0f]

I favour a utility to do flash programming.

The timing loops can be avoided by using a facility that most flash vendors provide - which is a 'busy' bit that can be read - if it's still set, you loop around until it's cleared - then move onto the next bit/byte/block and so on.

[tofro]

I favour a utility to do flash programming.

The timing loops can be avoided by using a facility that most flash vendors provide - which is a 'busy' bit that can be read - if it's still set, you loop around until it's cleared - then move onto the next bit/byte/block and so on.

That's called data poll mode by most vendors. But, well, avoided? No. You'll still need some sort of time-out when the bits just don't want to flip (because the page wasn't properly erased or the-likes)

[Dave]

Hi all,

I've used flash a lot, but mostly from the hardware side or using ready made tools to flash newly assembled boards for testing or firmware updates.

I love seeing you talking about finer details of flash programming. I'm aware of the timing requirements and flash's feedback mechanism when it's ready to take some more data. That always seems to be handled in the software realm by polling.

I think the big thing to sort out is the mechanism for loading and executing code that either stops the OS task scheduler and disables interrupts, or both? Also, I'm not clear, though I am sure many here are, if it is possible to return to the operating system after this step or if a restart is 'required'...

As a random aside (woohoo for those paying attention!) today I fired up a new proto board with 8MB RAM and 2MB flash, using equations that ignore the flash and read the QL's OS instead. It'll be like that until there is some way to do in system flashing. It's the first flash that's the challenge. I could pre-program the flash, but it's TFBGA. Adapters are VERY expensive. Aaaanyhow, 7.5 MHz <-> 30 MHz clock switching is working perfectly on two boards now. Runtless (absolutely critical) switching is down. There is a switch to force 7.5 MHz only for those that want it. It's still much faster than a BBQL due to the 16-bit bus. This board exists to give me easy JTAG access to reprogram the CPLD and test points to measure timing of CPU cycles with 68020 or 68030 on daughter cards. The 68SEC000 takes the bus from the 68008 on start-up. Then it can take the 2nd 2nd CPU out of reset, which requests and is granted the bus. That lets me check and work on equations to optimize timing of the RAM subsystem for every CPU. One quirk of the RAM is that it has 512x16-bit pages. Accesses within pages take 45-47 ns. Crossing a page boundary the next access takes an additional 24 ns. This makes no difference for any 68SEC000 up to 86 MHz. However, on the 68020 and 030 it can start providing improvements from 40 or 45 MHz on. The logic checks A9..21 against a stored copy of A9..21. If they match it asserts /DTACK immediately. If the number changes (a page boundary has been crossed) it stores that number. It adds one to the /DTACK countdown counter, which exists because I need a cycle and /DTACK counter for the finite state machine for handling byte swapping with the BBQL. That logic also allows the CPU to continue, unless it tries to access the QL again before the state machine has concluded its cycles. At that point it just holds /DTACK from the 68SEC000, which isn't connected to the QL until the FSM finishes there. This QL-facing logic allows me to run the CPU at 7.5 MHz during the QL cycles only, but will allow 30 MHz cycles on the QL bus. Now, I can feel Nasta's back tensing up. I have used resistor-capacitor-inductor filters to slow the transitions to a QL-friendly slew rate. In practice, the CPU latches the data in a write cycle and goes about its business. Read is a work in progress. I'm delaying /DTACK but currently the counter is clocked at the CPU's running speed instead of the /4 speed. I plan to make that a jumpered setting.

As another random aside, A subset of this board could be used as an upgrade to Gold Cards. 8MB or 15.5MB of RAM and dual speed 32 MHz and 16 MHz. I haven't tried it, but removing the DRAM and preventing the refresh signal reaching the CPLD should be the only changes needed. Maybe. Either way, the DRAM can be shadowed so no matter.

[tofro]

Dave,

no, "owning" the machine (disabling multi-tasking and interrupts) is really a piece of cake - some machine code instructions and it's yours. "Coming back" from that state is similarly simple.

Code: Select all

; go to supervisor mode and switch off the scheduler
        move.w sr,-(sp)     ; save status register somewhere
        trap #0.            ; enter supervisor mode
        or.w #7000,sr       ; disable interrupts 
       
; code here can run entirely undisturbed
        
; ... and come back
        move.w (usp)+,sr    ; restore status register

[Martin_Head]

I think the big thing to sort out is the mechanism for loading and executing code that either stops the OS task scheduler and disables interrupts, or both? Also, I'm not clear, though I am sure many here are, if it is possible to return to the operating system after this step or if a restart is 'required'...

I would have thought that after flashing a ROM, trying to return to a running operating system would be fraught with danger. The operating system code may have moved about, so any return addresses on the stack into the ROM may no longer be valid.

Also I could see open channels that use ROM based open/io/close routines, suddenly having their routines moved.

[tofro]

I think the big thing to sort out is the mechanism for loading and executing code that either stops the OS task scheduler and disables interrupts, or both? Also, I'm not clear, though I am sure many here are, if it is possible to return to the operating system after this step or if a restart is 'required'...

I would have thought that after flashing a ROM, trying to return to a running operating system would be fraught with danger. The operating system code may have moved about, so any return addresses on the stack into the ROM may no longer be valid.

Well, that depends: Minerva runs on the code in ROM, while SMSQ/E simply loads itself from ROM on many platforms. For the former, you're obviously right, the latter doesn't care what's in ROM once its running.