bouffalo_sdk VS linux

I bought a bunch of the 16Mbit flash variant for an embedded project but sadly it looks like the firmware always gets corrupted on write, and have gotten no reply from Bouffalo

https://github.com/bouffalolab/bouffalo_sdk/issues/92

I tried looking through the source code of the SDK to get somewhat of an understanding, but it's taking too long for me to understand, so I'll leave it in your hands. gpio.h gpio.c gpio_reg.h

BouffaloLab has recently started bringing order to the chaos. They have created a new bouffalo_sdk where they're merging bl_mcu_sdk and bl_iot_sdk, the latter being the one to use for wireless. The README file lists which peripherals are currently supported. There's still work to be done, but it's good news they engaged into this endeavour.

The chip has complete-ish sdk here(https://github.com/bouffalolab/bouffalo_sdk) we use as "documentation". Datasheet and the reference manual are incomplete.

I don't think there is a "common solution". From my point of view, the Bouffalo Labs chipsets are not yet widely in use, at least not outside of china. However - as far as I can see, the USB host example code from the SDK interfaces the USB HID parts of the stack, too: https://github.com/bouffalolab/bl_mcu_sdk/blob/master/examples/peripherals/usbhost/usb_host.c

I just scoured the current main branch of https://github.com/bouffalolab/bl_mcu_sdk and can see the current HAL supports DMA, EMAC, flash, GPIO, MJPEG, PWM, RTC, encryption, timers, UART and USB. DAC and ADC's (audio) are implemented but not tested. I can also see there are BSPs for the LP core if you wanted to take advantage of it, with helloworld examples for all three, and finally there are some examples of using TensorFlowLite in the examples directory that you could build and try too.

Wifi/RF on bl616 is the same state as bl808. We are waiting for bouffalo to release support for it in bl_mcu_sdk: https://github.com/bouffalolab/bl_mcu_sdk/issues/85

Probably the most useful thing you could do would be take any Android device (or iOS device with the bootrom exploit) and rebase the patches for it on mainline, clean them up and get them merged into mainline Linux. Same goes for any other device not supported in mainline really, but Android devices are almost always like this.

Along those lines, look at all the dkms modules in any Linux distro and try to talk to the module authors about mainlining, do the work needed if they agree to it.

Also, I have some ideas for Linux kernel things I noticed are needed in my branches of linux.git: https://github.com/pabs3/linux/branches/all

  cleanups/bluetooth-magic-numbers

Like most open source, a good way is to use it and then find issues and fix them; aka scratch your own itches.

Here are the itches I have scratched and attempted to scratch in the Linux kernel:

I got my first commit into Linux many years ago by noticing the shortname mount option for the vfat filesystem was suboptimal and then sending a patch flipping the default to mixed.

Later when maintaining a simple core dump handler script, a bug reporter noticed that Linux was splitting the core dump handler string after filling in the parameters, instead of before, so I fixed that, with a few broken patches and a lot of help from other Linux devs.

Later I was using SSD+HDD mirrored with lvmraid (not mdadm RAID) and noticed that Linux doesn't allow TRIM/discard on lvmraid when one device supports TRIM but the other doesn't, I wrote a working patch for that but I used the completely wrong approach, so it was rightly rejected. I haven't managed to get back to that project and the HDD died in the meantime.

Later while helping users on the #debian-next IRC channel, after seeing a patch fixing the Bluetooth code by changing a magic number. I looked at the code and noticed a lot more magic numbers. Then I investigated what it would take to eliminate those magic numbers. I encountered a legal barrier and contacted the relevant Linux Foundation and Linux kernel folks, who assured me my approach would be fine. I haven't managed to get back to that project yet though.

While maintaining the Python implementation of iotop (the C implementation is better), I noticed there is no way to look up at runtime from userspace which syscalls a Linux kernel offers and what their names are etc. Haven't started on that yet.

When my monitor had an issue with the EDID going missing (turns out it was just a bent pin on the VGA cable I was using), I had the idea to create /sys/class/storage, which would let you back up all the non-volatile storage on your system that isn't a block device, like monitor EDIDs, BIOS variables, UEFI storage, pstore etc. Haven't started on that yet.

When I was forwarding my USB based webcam from my laptop to my desktop using the usbip tool and Linux kernel module, I noticed some ergonomic issues in the userspace side and started working on them. I haven't managed to get back to that project recently though.

My rejected and unfinished patches and TODO files are here in case anyone wants to pick these up:

https://github.com/pabs3/linux/branches/all

The kernelnewbies resources are often helpful, including the IRC channel:

https://kernelnewbies.org/

I think the best way though is a GSoC/Outreachy Linux kernel internship, that has full-time mentoring and often leads to job opportunities too.

https://github.com/fossjobs/fossjobs/wiki/resources