I believe it is not compressed or encrypted. Entropy of 0.8 is pretty poor for any decent encryption or compression. These regions are more likely to be code.
With this in mind, let's look at a hexdump in the region of the first area of higher entropy at offset 0x00001000 -
00001000: 76 86 65 77 01 01 00 24 FF FF FF FF 00 10 FF FF v.ew...$........
00001010: 00 00 21 26 00 00 00 00 00 00 00 00 00 00 38 10 ..!&..........8.
00001020: 76 9C 07 9D E5 9F 00 28 EE 01 0F 10 E5 9F D0 24 v......(.......$
00001030: EA 00 00 0B E5 9F 00 20 E5 9F 10 20 E3 A0 20 00 ....... ... .. .
00001040: E5 80 10 00 E5 80 10 04 E5 80 20 08 E5 80 20 0C .......... ... .
00001050: E1 A0 F0 0E 00 00 1F 74 04 00 20 00 90 00 02 00 .......t.. .....
00001060: 00 00 55 55 E2 8F 80 C4 E8 98 00 03 E0 80 00 08 ..UU............
00001070: E0 81 10 08 E2 40 B0 01 E1 50 00 01 0A 00 00 13 [email protected]......
00001080: E8 B0 00 70 E1 54 00 05 0A FF FF FA E3 14 00 01 ...p.T..........
The fact that almost every 4th byte has a high nibble of E is strongly indicative of 32-bit ARM code.
That does leave the question of why areas look garbled. e.g.
000128B0: 47 18 BC 08 65 48 20 3A 6D 20 70 61 72 6F 6D 65 G...eH :m parome
000128C0: 6F 63 20 79 70 75 72 72 00 64 65 74 20 74 75 4F oc ypurr.det tuO
000128D0: 68 20 66 6F 20 70 61 65 6F 6D 65 6D 00 00 79 72 h fo paeomem..yr
What I believe is happening is that there is some endianness mix-up going on, perhaps with how the flash interfaces with the SOC/MCU or maybe with the settings of the program you used to dump the flash.
So, look again at the region at offset 000128B0 but reverse each group of 4 bytes first. This gives you -
000128B0: 08 BC 18 47 3A 20 48 65 61 70 20 6D 65 6D 6F 72 ...G: Heap memor
000128C0: 79 20 63 6F 72 72 75 70 74 65 64 00 4F 75 74 20 y corrupted.Out
000128D0: 6F 66 20 68 65 61 70 20 6D 65 6D 6F 72 79 00 00 of heap memory..
This makes much more sense. Other apparent strings become readable with this transformation too.
I'd suggest you apply this to the whole file and see what that gives you.