Probably. It's best to fix the linker script and make it clean.
Using the NZW Flash area with a dedicated section is doable - the small hiccup right now is that this area of Flash is *not* mapped right after the normal code area (which is remapped at address 0), so it must be accessed from its base address, which is an offset of 0x0800_0000. No problem, you just need to define the origin appropriately, like this for instance:
FLASH_NZW (rx) : ORIGIN = 0x08000000 + LENGTH(FLASH), LENGTH = 480K - LENGTH(FLASH)
Then add a section like this:
.flash_nzw_data :
{
. = ALIGN(4);
*(.flash_nzw_data)
. = ALIGN(4);
} >FLASH_NZW
And there you go. Almost.
Now, since the code area and this NZW area will be far apart from the perspective of the linker, that will generate a huge .bin file, if you use binary files. With this, you can't. It would be much too large (> 128MB with most of it zero.)
So you'll have to stick to elf or hex. Which is still all fine for the most part. But now you need a programming tool that can Flash different non-consecutive blocks in a smart way rather than as a contiguous block, and there is not much that can do this at the moment. A small issue, but no real tool for flashing, unless you write your own. The wlink tool (written in Rust) that I'm using can't do that, but there is a ticket for this as a feature request. We'll see. Maybe openocd can do this, I'm not sure, haven't tried it yet.
Otherwise, we would have to stick to other approaches, a bit less convenient - the problem is kinda similar to the typical bootloader + user app in a single object file thing.