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)