ranma42

How do you distinguish between input (Keyboard/USB) and output (Browser/Graphics stack) delays in this test?

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.

IIRC ReactOs forbids you from contributing if you had access to the windows source code in some way shape or form.

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?

It does say "Certain cough medicines and illicit hallucinogenic substances are also known to trigger it"

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.

Looks like the PPKII can do up to 1A.

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.

In a similar vein, there is https://aminet.net/package/mus/misc/AlgoMusic2_4u.lha, from ~96 or so.

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).

Pixel (4 or later), or Pixel Watch,

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.

Also OpenWRT udev itself is tiny:

  20.0K Oct 13  2022 /usr/lib/libudev.so.1
   8.0K Dec 15  2022 /sbin/udevtrigger

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).

Now you might ask, why does the webcam have an endpoint with a 0 byte MaxPacketSize on its first interface? Who knows!

This one has a simple answer:

USB is a shared bus and limited in bandwidth. Isochronous endpoints transmit continously and thus require a fixed part of that bandwidth.

The OS has to allocate the available bus bandwidth to all plugged in devices.

If no more bandwidth is available, it will refuse to configure the device that you just plugged in!

Thus the alternate setting with the isochronous packet size set to 0 serves multiple purposes:

1) It lets the OS configure the device and let the driver discover it even when not enough free bandwith is available on the bus

2) The driver can release the unused bandwith while the device is not in use

3) Not sending iso packets while the device is not actively used also means less power draw

RK3568 / RK3588 have 3 SATA controllers and for example the Rock Pi 3A seems to have the SATA routed to the bottom m.2 connector, as well as the possibility to switch the USB3 port over to SATA

https://linuxgizmos.com/pi-like-rk3568-sbc-grows-sata-out-of...

"The Rock 3 Model A exploits the RK3568’s ability to multiplex SERDES lanes to enable SATA support on the dual USB 3.0 ports (OTG and host) via a SATA breakout cable."

I think the article in question actually is for older BIOSes that don't have flashback or similar. Instead this relies on the "BIOS Boot Block" still being intact in the flash, so you do need a partially working BIOS flash, CPU and memory for this method.

DisplayPort is the more surprising one. DDC came from VGA and DVI and uses the I2C lines that also connect the EDID EEPROM, but Displayport doesn't even have I2C pins if you look at the pinout, so it has to be tunneled: "DisplayPort does not have the I2C SLA/SLC pins. Instead, the logical I2C signals are converted at each end into messages on the AUX channel. Put another way, DDC is implemented using the AUX channel, but the AUX channel itself is not DDC. The "multiplexing" of I2C over the AUX channel is transparent to all but the lowest level of I2C software at each end."

64 registers with 3 registers per instruction would require 21 bits

Actually only 18. With 21 bits you can get 128 registers.

x64_32 never really took off and there was some discussion of removing the support in the past: https://lwn.net/Articles/774734/

For coreboot there are actually some interesting low-level emulation options: The PCH has "I/O Trap" settings, where you can set about 4 ISA I/O ranges to be trapped (generates an SMI, so the SMM code can handle it), so it should be possible to emulate the Sound Blaster I/O port behavior.

I don't know if the trap mechanism allows you to also trap the ISA DMA ports, which you'd need to do for DMA emulation.

Slightly higher level you could use classic VMM or more modern hypervisor functionality to do the emulation.

Its just the reference implementation of the EL3 "Secure world" monitor, and this is where some of the power management stuff is implemented according to ARM standards (e.g. PSCI). Technically I'm pretty sure you could do without it, but then you'd need to amend the devicetree and drivers to handle power state transitions.

On the Rockchip SoC in question, boot security is disabled by default, so you can compile it yourself from source and run your own modified version if you want to.

I know of at least one GDDR5 memory chip that should have chip art of a snake on the die.

That requires a hefty overclock though (252MHz instead of 133MHz).