BL808 Support

[Pavlos1]

Currently only supports the IOT single-download mode. Write mode would require some refactoring, especially if we want to support multi-group flashing.

Also I don't own any other BLxxx hardware, so I highly recommend testing to make sure I haven't broken support for the other chips.

[robertlipe]

It's pretty unbelievable that they push all this into uploaders.

Please think more about the error codes and whether Bouffalo takes the blame for typos, but it's otherwise OK with me.

I'll leave final approval/acceptance to Gaimee.

[Pavlos1]

Update: turns out the structs are slightly different; two of the fields differ (qpiJedecIdCmd and qpiJedecIdCmdDmyClk are replaced by enter32BitsAddrCmd and exit32BitsAddrCmd in the BL808 version, respectively.) Unifying the structs may still be possible, but is out of scope for this PR.

I have noticed that the flash configuration struct is duplicated in blisp_struct.h (including typos in the comments) as a result of this PR. This is because, while the BL808 bootheader is different to the bootheader used by the other BLxxx chips, it does use the same format for the flash configuration data.

I am debating whether to try to combine them. It might make some definitions look a bit weird, i.e.

struct __attribute__((packed, aligned(4))) bl808_bootheader_t {
    uint32_t magiccode; /* 4 */
    uint32_t rivison;   /* 4 */

    struct boot_flash_cfg_t flash_cfg; /* NOTE: BL808 uses the same flash configuration */ /* 4 + 84 + 4 */
    struct bl808_boot_clk_cfg_t clk_cfg; /* 4 + 20 + 4 */

    struct bl808_boot_basic_cfg_t basic_cfg; /* 4 + 4 + 4 + 4 + 4*8 */

    struct bl808_boot_cpu_cfg_t cpu_cfg[3]; /*24*3 */

    uint32_t boot2_pt_table_0_rsvd; /* address of partition table 0 */ /* 4 */
    uint32_t boot2_pt_table_1_rsvd; /* address of partition table 1 */ /* 4 */

    uint32_t flash_cfg_table_addr; /* address of flashcfg table list */ /* 4 */
    uint32_t flash_cfg_table_len; /* flashcfg table list len */         /* 4 */

    uint32_t rsvd0[8]; /* rsvd */
    uint32_t rsvd1[8]; /* rsvd */

    uint32_t rsvd3[5]; /* 20 */

    uint32_t crc32; /* 4 */
};

Thoughts?

[Pavlos1]

I have some additional changes (baud rate, chip erase command line arguments) on another branch.

I was initially planning on opening a separate PR if/when this one was merged. Let me know if it would be easier to just combine them into this PR instead.

[Ralim]

@Pavlos1 Sorry for the delay, Im back on getting trying to get these PR's cleaned up.
Would you prefer to do an all-in-one PR or this as is ?

[Pavlos1]

Probably easier to do an all-in-one PR. I'll add the commits from the other branch shortly.

[Ralim]

@Pavlos1 I would also like to #38 Merged in soon as well, is it ok with you if I do that one first which might reduce some of the delta in this PR; making it more 808 specific?

Otherwise I see no issues with the code at all, (I can't test it though)

[Ralim]

@Pavlos1 If you can rebase/merge/resolve-conflicts would be amazing and then I think this is g2g 🙇🏼

[Pavlos1]

Conflicts resolved. That last merge commit also fixes a bug (mine) that was revealed by the warning cleanup.

[Pavlos1]

Hi @Ralim, the CI is passing but GitHub's UI says that merging is blocked due to a review requesting changes.

@robertlipe reviewed a previous version of this PR. IIRC we ended up implementing/resolving all the recommendations from that review, but since the review state is still "changes requested" it might be blocking the merge.

[Ralim]

Naah its waiting on someone with write access (probably mostly me at this point 😓 )
Sorry, been on/off being sick so havent gotten back to this. Will re-skim review and merge today/tomorrow 🤞🏼