Can Any help me with my F7

That is a lot better than I expected.
The arrow indicator that I use in the emu is not properly mapped in the F7. I'll fix that next
The listbox is not supported which is why you can't load any models. Generally there is a lot of work still to do to get the code working fully. Listboxes are next on my list though.
Don't get your hopes up too much though. As soon as I have the basic GUI code working, I'm going to switch my effort to the F12E.

FYI. I think I figured out why Walkera firmware can't write to your flash chip. the 64kB chip that comes with the F7 uses byte-accessible write (AAI) which is command 0xAF. But the 4MB flash you replaced it with uses word-accessible write (AAI) which is 0xAD. So Walkera can't write the the 4MB chip, and Deviation can't write to the 64kB chip (though we could fix that). I don't know if there are any flash memories that support both access methods (or at least a larger one that supports 0xAF)

Looks like the SST25VF020 (256kB) is available with the 0xAF AAI command (not to be confused with the SST25VF020B which uses 0xAD). It looks like there was an 040 and 080 (note these are not the 040B or 080B!) butthey aren't available any more. I didn't check as to whether the 040 is frequency compatible, just that the command-set was the same. So for the F7, the SST25VF020 is probably what I'd recommend in the future. 256kB is not a lot, but it should be enough for 26 protocols + other needed files + 10 or more models.

Maybe we could do even better if I worked to get 512byte sectors working which requires a virtual sector overlay.

or just live with a 'deviation only' F7

another option would be to hack the official f7 firmware. that would be challenging but not impossible. seelcting between spi chips is non trivial as you'd need a 2nd control line. I guess you could hack in a manual switch, but I doubt most users would be interested in that approach.
I actually had another idea that is more outlandish.
you could use a bluetooth module to upload models (and even protocols) to the f7 from a smartphone. effectively use bluetooth as the filesystem. you'd need a bt module, but it would be easier to install than replacing the flash. or if it works, we could even use the bt module on the universaltx module for that.

I checked in an update that enables the keyboard display.
It also should properly give you the arrow characters instead of 'O'

I'll look at the listbox next

make sure you have errors.txt on the filesystem and that it has at least 1 byte in it (open it and add some text if it is empty)
then after the reboot, send it to me along with the devof7.elf file (that is in the build directory) Make sure the devof7.elf came from the same build as your dfu

Also. I just added fixes for the load/save menu

then flash back a previous build.
save your devof7.elf file somewhere, then install 0af95bee8f97 (or earlier) so you can get tothe menu.

Since my f7 doesn't have the larger Flash, I can't duplicate the issue.

the crash is happening within the protocol code. My guess is it is related to the display caused by the dialog box, but I really don't know. can you do the following:
install the busted dfu
hold 'ENT' while booting
wait for boot loop (keep holding 'ENT')
switch off tx (while still holding 'ENT')
once it is off, put the 'good' dfu back on and send me the errors.txt

That should get me a stack dump that has nothing to do with the protocol code (which is really hard to debug on the f7/7e)

1st grab the latest code I just uploaded. It won't fix the crash, but it should fix the screen color.
now try removing all of the .mod files from your tx and try again.
if it reboots, you can just hold 'ENT' to get to the usb menu and grab the errors.txt (no need to put the 'good' dfu on
I will need your devof7.elf though since you need to rebuild with the latest code.
I do not need any of the files currently on the dropbox so you can remove/replace those.

I just pulled out my F7 and I can get to the USB page via 'ENT' so the issue isn't with the font mapping. that implies it may be the dialog box. After creating the errors.txt as above, you could try each revision in the commit history and find the last one that works for you.

try the latest checked in code.
same procedure if it fails.

the problem appears to be related to module loading and not to any changes I've made. Another thing you can do is to make sure you copy the latest mod files to the protocol dir every time you upgrade the dfu

lastly, you can edit target/devof7/target_defs.h and set:
#define HAS_MULTIMOD_SUPPORT 0

the reboot shouldn't happen. That is definitely a bug (but it'll likely also be an issue on the 7e too).
The process is always:
upgrade dfu
power on with ENT pressed
copy filesystem
power off
power on as normal