> No BSP, no kernel source, no vendor documentation — just a DTB extracted from the stock Android firmware and rebuilt from there.
Judging from the build.sh, it looks like this is just using unmodified upstream u-boot and tools from the rockchip-linux repository, so "from scratch" is really just analyzing the DTB to see what drivers need to be loaded?
> The TL-SG108 uses a 4Mbit (512KiB) SPI flash chip from Cfeon, which is too small to contain any assets for a web management interface
The https://github.com/logicog/RTLPlayground alternative firmware for RTL8372/RTL8373 based 2.5GBit Switches does fit into 512KiB, including web management interface.
I've been mounting my 3.5" hard drives on those "fad" rubber band 5.25" drive bay adapters for decades and have not noticed any increased failure rate at all. Sure, seek time may be worse, but the reduced noise has been worth it for me.
Not OP, but I installed a "Balcony solar" 1.4kWp panels 2.4kWh battery system on my parents garage. The only subsidy was the tax free purchase of the components (we did file for an additional tax break with the city, but they had already run out of funds for that because it is so popular). You also save a lot of money on installation costs.
Cost breakdown:
- 400 EUR 2.4kWh 48V battery
- 320 EUR 4x 360W solar panels
- 200 EUR 800W microinverter
- ~200 EUR for helping hands when getting the panels onto the flat roof
- 160 EUR flat roof mounting equipment
- 153 EUR solar cable, connectors and crimping tool
- 115 EUR MPPT charge controller and cables
- 95 EUR electrics (e.g. fuses, dc/dc converter for OpenDTU)
- 50 EUR other assorted costs
So about 1693 EUR in total.
Total yield after 1.3 years: 1715 kWh (including power fed back into the grid)
Of that, discharged from battery: 488 kWh (battery already paid back ~146 EUR)
At the current energy costs, 1715 kWh would be ~514 EUR imported from grid
> you are recommended to get the shingles vaccine instead of the chickenpox vaccine since the way the disease presents and how the body reacts to it changes with age (technically shingles can happen at any age but generally herpes zoster presents as shingles instead of chickenpox the older you get).
If the underlying virus is the same, what is different between the vaccines? How it presents shouldn't matter as much?
BTW looking at the 8051 patch bytes, they look like 8051 code to me. 0x02 is the ljmp opcode, so this is a jump table: 0x02, 0x40, 0x58, 0x02, 0x40, 0x4e, 0x02, 0x44, 0x00, 0x02, 0x42, 0x2b, 0x02, 0x41, 0x82
I poked at a vsc73xx-based switch in the past and wrote my own test firmware, but had problems with packet loss since I didn't do all the necessary phy initializations I guess, in case this might be of interest:
https://github.com/ranma/openvsc73xx/blob/master/example/pay...
Also on the device I had the EEPROM was tiny and the code is loaded from EEPROM into RAM, you were pretty much stuck with 8051 assembly that had to fit into the 8KiB of onchip RAM :)
I have the ST one (X-NUCLEO-LPM01A), but its range is actually not enough for something like an ESP32, it goes into "overload" as the max current is 50mA for dynamic (100kHz bandwith) and 200mA for "static" measurements.
The partition table listing from the microSD card shown in the video (before installing a custom u-boot/Linux) shows partitions marked as the Linux partition type at least.
The amount of power you can dump for balancing is just a fraction of the charge/discharge power (because it only needs to offset differences in self-discharge rate). So you still need a proper dummy load when you want to dump more.
Similarly, the heatsinking capacity of the battery is designed for charging/discharging losses (say 5% of charge/discharge power).
> Since there's no point in generating keys for a device which will not be used in Japan, non-Japan SKUs don't have Osaifu-Keitai functionality. So even if you rooted your phone and had full access to the secure element, if your phone's secure element doesn't have the key, you can't use it as an IC card.
At least in some cases it is sufficient to change the phone SKU id (which requires temporary rooting) to the Japan SKU id to unlock the Osaifu-Keitai functionality on a non-Japan phone. I'm not sure if this means that the secure element had the necessary keys provisioned all along, or just that the Osaifu-Keitai app then provisions it on first use.
I do actually see the problem that the ESP32 doesn't automatically reconnect to the stronger AP. I think this gets triggered when then stronger AP is briefly unavailable (reboot or radar scan or whatever) and it switches to the weaker AP, but then once the stronger AP is back it stays connected to the weak AP. (This is with multiple APs in a mesh configuration)
> I also upgraded OpenWrt Routers by soldering bigger RAM and bigger flash chips in the past
Sadly this is harder than it used to be because with devicetree the flash size is hardcoded, where before it was auto-detected (so previously you could swap the flash and continue to use stock firmware, not you need to compile custom firmware).
Unfortunately I could not get Suica to work on my Pixel 7a, while a fellow traveller with an iPhone had no issue. So AFAICT for Pixels you sadly still need a Japanese device to use Suica in Google Wallet.
Vodafone in Germany was happy to give me an eSIM for a prepaid plan, not even a store visit required (but it did require taking a photo of my ID and a identity verification video call where someone checks your video against the ID).
I guess with AI-based video manipulation, a store visit may be required in the future...
Athereos wireless cards (ath10k) have also used Xtensa.
And the audio DSP in newer intel chipsets (e.g. Apollo Lake) is also Xtensa-based, but unfortunately quite locked down (signed firmware only). See https://thesofproject.github.io/latest/platforms/index.html
Also ISTR that older Radeon graphics cards used Xtensa (e.g. in the Unified Video Decoder).