Port BCM43438(WiFi+BLE) to Photon

Hi @mdma, please help me sign the windows driver for our platform. I am not that familiar with the procedure signing a windows driver. The USB PID and descriptor string are shown here:

Thanks in advance!

Hi, @mdma, Does the Macro definition USE_SERIAL_FLASH somewhere seam to act as the role MODULAR_FIRMWARE ? E.g., in thses functions
FLASH_Backup(),
FLASH_Restore(),
HAL_Core_Config(),
FACTORY_Flash_Reset(),
BACKUP_Flash_Reset(),
OTA_Flash_Reset(),
etc.

What if I enable both Macro definitions USE_SERIAL_FLASH and MODULAR_FIRMWARE? I think they are mixed used in some degree.

I ā€˜m not familiar with the other Particle platformsā€™ hardware configuration. But I think thereā€™s no relationship between using serial flash and the modular firmware framework in theory. I think the shared functions for different platforms should be conditionally compiled using the bellowing structure:

#ifdef MODULAR_FIRMWARE

#ifdef USE_SERIAL_FLASH
...
#else
...
#endif

#else

#ifdef USE_SERIAL_FLASH
...
#else
...
#endif

#endif

Thatā€™s so complex, right? :slight_smile: Do you have any ideas?

Good question. They are orthogonal, so all 4 combinations may be valid on some platforms.

Historically there was a link between their functions - very early on during writing firmware for the P1 we were using the same scheme for OTA backups/factory backups as the core - storing everything in external flash because there wasnā€™t room to store full copies of the firmware in internal memory.

With modular firmware, only the application firmware is duplicated so there is room to store this internally.

So thatā€™s the history. Going forward, I would suggest USE_SERIAL_FLASH is a conditional define set in platform_config.h for those platforms that need it. It is set for those platforms that must store the backup firmware in external flash. Furthermore, the behavior will be conditional on whether modular or monolithic firmware is being used, since the size of the backup regions will change.

I hope thatā€™s clear!
Cheers,
mat.

Get it! @mdma, Another question, when should I use the module slot to update flash? In the HAL_Core_Config(), if using serial flash, it wonā€™t add the factory reset module slot, thus when performing FACTORY_Flash_Reset(), using serial flash will directly restore the factory reset image by calling FLASH_Restore(), or it uses the module slot to achieve that. But both of the methods invoke the FLASH_CopyMemory() in the end.

The module slot also supports using external serial flash. Why does it not use module slot if enable the USE_SERIAL_FLASH?

#ifdef USE_SERIAL_FLASH
// Restore the Factory programmed application firmware from External Flash
FLASH_Restore(EXTERNAL_FLASH_FAC_ADDRESS);
success = 1;
#else
// Restore the Factory firmware using flash_modules application dct info
success = FLASH_RestoreFromFactoryResetModuleSlot();
//FLASH_AddToFactoryResetModuleSlot() is now called in HAL_Core_Config() in core_hal.c,
//So FLASH_Restore(INTERNAL_FLASH_FAC_ADDRESS) is not required and hence commented
#endif

So what method should I prefer? Using FLASH_Restore() or module slot?

I suppose that some platforms like Photon can support both of the methods, but the core can only use FLASH_Restore(), right?

Thanks!

@mdma,
Could I please have a copy of the wiced diff file? Iā€™m currently bottlenecked in development as I need the implementations of various different functions (such as dct_read_app_data) to proceed.

Thank you, and pardon me @ielec - I should probably open a new thread.

Never mind. Any questions about BCM43438 are welcomed!

Cheers,
ielec

@mdma, It just appears an idea in my mind that changing the structure module_bounds_t to be:

typedef struct {
    flash_device_t flashDeviceID;
    uint32_t maximum_size;      // the maximum allowable size for the entire module image
    uint32_t start_address;     // the designated start address for the module
    uint32_t end_address;       //
    module_function_t module_function;
    uint8_t module_index;
    module_store_t store;
} image_bounds_t;

So that it can be applied to most of the source code that associated with flash operations, e.g., the function
FLASH_ModuleInfo(uint8_t flashDeviceID, uint32_t startAddress)
can be changed to
FLASH_ModuleInfo(image_bounds_t, image_bound)

This also clearly distinguishes the concept of module and image. To my understand, A module may be system part 1, part 2 and user part, or the monolithic firmware. An image may contain a module and bootloader. We should not call the factory reset image as a module, since it isnā€™t an independent part of the firmware in internal flash, it is the user module actually. As well as the backup image and OTA image.

And it is well supported for serial flash. The difference between those images stored in serial flash and in internal flash is the CRC calculation, the internal flash images can be calculated the CRC before being copyied to the destination address, while the external flash images canā€™t. Others features are the same no matter where they are stored.

What do you think about it?

Thanks,

That sounds fine - including the module_store is a natural extension of the scheme when we have to expand beyond just the internal storage.

It is possible to compute the CRC of modules in external flash by reading successive chunks of data from flash into RAM, and computing the CRC incrementally.

So do you plan to improve the performance of the flash operation? If possible, I would like to have a try and submit a pull request.

Performance of the flash operation is limited by the system. Iā€™m not sure how we can improve it - what do you have in mind?

I mean make the source code more readable, compact and portable. :smile:

Hi! Iā€™m playing with your Redbear Duo! I appreciate it a lot!
Iā€™m trying to develop it from scratch. May I ask about the BCM43438 firmware? I tried multiple ones on github, flashing them to Redbear with dfu-utils, including:
(1) Raspberry Pi: https://github.com/RPi-Distro/firmware-nonfree/tree/master/brcm
(2) brcmfmac driver in the armbian Linux kernel: https://github.com/armbian/build/commit/042c25aaef2ae81b9117201aae0aa0da6c214354
(3) the 43438 firmware in WICED SDK
None of them workedā€¦ Only the original duo-wifi-r1.bin firmware would work.
So for BCM43438, it seems that every firmware and driver is individual.

Do I need to develop the firmware myself if I wanna fully use it, while the firmware is not open-source?

@hhuysqt, you may want to look at the github repos:

Thanks for your reply!
In fact Iā€™ve browsed redbearā€™s github, and Iā€™m trying to port it to another board, to develop bare-metal applications based on AP6212A. Iā€™ve camera etc. on the board, which need large bandwidth. So I want to figure out a clean project, and Iā€™m trying out some open-source AP6212 development boardsā€¦