This is a set of patches for the Linux kernel that enable changing the battery charge thresholds. This is useful for example to limit the charge to 80% to prolong the life of your battery if you leave the charger connected all the time.
This is a 4-in-3 hard drive cage with cooling fan. It fits four 3.5″ drives in to three 5.25″ slots. It can be used inside a standard PC case or on its own with no case.
I often need portable drive cages for moving drives around with built-in cooling so I designed this. It’s a compact rigid structure. I recommend printing it “face down” with infill for the first 7mm then no infill for the rest of it. I usually use a fast “draft” mode (0.3mm) for printing the cage faster since it doesn’t need to look nice.
The drives are held in place with small tool-less rails for easy drive swapping.
The drive rails can be tricky to print depending on your printer. I recommend printing them in “normal” orientation with the pins sticking out to the side. This requires a tiny amount of support material for the pins but will make them very strong. The Z axis accuracy of the printer and first layer is very important for the rails to fit the cage. They are suppose to be exactly 6.2mm wide (or “tall” on the print bed). This is critical for getting a good fit.
I know the fan is a bit of a pain to mount, requiring screws on the inside. I tried designing retainers that could be inserted from the front but they’re too small and thin to be printed on a FDM printer reliably.
Some notable points about this design:
This is a rigid structure that does not flex much and when a fan is mounted it’s even stronger.
The weight is distributed to the sides to prevent flexing.
The drive rails distribute the weight to the sides across a wide cross-section in the strongest direction of the plastic. Less chance of the plastic layers separating over time.
It is tool-less. No screws unless your PC case requires them. Not using screws also helps prevent the plastic from separating over time.
This will fit in PC cases that use shelves for the 5.25″ slots.
Active cooling directly attached via 120mm fan.
Note: This cage only works with drives that have 3 mounting holes on the sides.
Recently had to repair a bricked Fiet security camera. If too long of a WPA password is used it will cause a buffer overflow and the camera will crash which results in an endless boot-loop. There doesn’t appear to be a way to recover from this condition without getting serial access or access to the flash memory itself.
Fortunately on the main PCB there are serial connection points. A regular TTY-to-USB converter at 3.3V works. Beware when taking it apart. There is a plastic ring around the PIR sensor that needs to be removed first to get to some screws. It’s just snapped on and I used a spudger to free it. Only the two screws near the main body of the light need to be removed and the PIR sensors can be left in place if you want.
Once you have serial access then the boot process can be stopped to get to the U-Boot menu which will allow you to flash a custom root-fs that has a root password you know.
Warning: r8168#0 failed to set MAC address
set ethaddr = <NULL>
set ipaddr = <NULL>
set netmask = <NULL>
LIN003:Hit any key to stop autoboot:
I used the uboot commands to extract the entire flash memory over the serial port (took about 2 hours). This can be done with sf read 80000000 0 1000000 followed by md 80000000 400000. Note the memory display command is real flaky and may hang if you use a size it doesn’t like. It also displays hex with the endianess reversed so every 4 bytes have to be flipped around. Then the root-fs can be sliced out and extracted with unsquashfs. The root password can be created with mkpasswd -m md5crypt. Then recreate the squashfs, patch the filesystem binary with rootfs_tool.py, put the binary on the SD card, then use the fatload command to load it in to memory, then write it to flash with sf write.
During boot there is a second option to stop the boot process. Press q then you can log in as root.
mmcblk0: mmc0:59b4 USD00 118 GiB
If you want to run app by yourself, please input q
=======================Press q -> Entry
The problem lies within the /mnt/mtd/aoni_ipc daemon that runs on the camera. This is a large master binary that handles all sorts of activities. I couldn’t find source code for it so I had to hack the binary itself. The problem lies in the Config_Read_String_Params function. When the WiFi configuration is read it uses two buffers. The first buffer is 300 bytes but the second one is only 68 bytes. The first buffer is copied to the second during processing. The configuration is base64 encoded so a standard 63-character WPA password will overflow the 68-byte buffer and cause a SEGFAULT.
To fix this issue I modified the binary so that WIFI_PWD is not base64 encoded. This way it will fit within the 68-byte buffer and WPA passwords are text anyway. Near the end of the binary is the WIFI_PWD string surrounded by a bunch of nulls. This is the table that determines which parameters are base64 encoded. I simply changed the string to WIFY_PWD so that when the camera checks to see if it needs to do base64 encoding it does not find WIFI_PWD.
I have been meaning to try the open-source Intergenic bootloader for years and only just got around to it. This bootloader allows 1080p mode when using Dafang-Hacks. When messing with the bootloader it’s a good idea to have the serial connection ready for debugging or recovery so I added a header that is easy to plug on to. Also make sure to use the correct bootloader image.
In my case the first attempt didn’t work. I successfully flashed the bootloader but when the camera booted it hung looking for the root filesystem on the SD card.
[ 1.663096] TCP: cubic registered
[ 1.666583] NET: Registered protocol family 17
[ 1.671298] Key type dns_resolver registered
[ 1.676844] input: gpio-keys as /devices/platform/gpio-keys/input/input0
[ 1.684078] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[ 1.692649] Waiting for root device /dev/mmcblk0p2...
[ 1.815134] dwc2 dwc2: ++OTG Interrupt: A-Device Timeout Change++
... Hang Forever ...
This was due to my uEnv.txt configuration which was set to boot off the SD card instead of NAND. I switched to the NAND uEnv.txt and the camera started fine.
Was getting BSOD trying to pass through a 280X to Windows guest. Using an added PCIe root seems to fix it. Using the i440fx machine in QEMU also seems to fix the BSOD. I need to benchmark that against the PCIe with Q35.
Standard options for the various modes using Q35 QEMU machine:
Generate a fake random IMEI based on your real IMEI. This allows you to give your random IMEI to anyone without exposing your real IMEI. Useful for websites that decode the IMEI and display phone model information.
No information is sent to this site for this calculation. It’s all done in your browser locally. You only need to enter the first 8 digits.