This might not be a direct solution to your problem, but I'm sharing my thoughts on it.
SHORT ANSWER
It's not very likely for RAM on embedded systems to get defective. And if it does, solutions might not be readily available, except if someone has already done that specifically for your device.
Modern flash storage devices manage bad blocks on their own, users haven't much to do in this regard.
If any of both problems requires user intervention, usually it's time to replace phone.
- This error appears in the log of TRWP:
E:Invalid block device on /sdcard ext4 [][][]flags=display="Internal SD" ; symlink ', 'flags=display="Internal SD" ; symlink' , 27
- When trying to change partition type or repair 'Internal storage' at TRWP it says
Invalid partition selection (maybe becouse of 7?)
To me these symptoms look like those of a dying eMMC.
BAD BLOCKS ON RAM
I suppose you are talking about a phone or similar device.
Phones have SoCs, the module which includes CPU, GPU, RAM, eMMC, modem, WiFi, Bluetooth and GPS along with other critical components. In addition to that, LPDRAM and eMMC are in most cases manufactured together as a single Multi-Chip Package (MCP).
That said, what you are saying is highly unlikely to occur on phones. On PCs RAM is installed as independent modules which are prone to physical damage and wear and tear e.g. due to moisture, rust, dust, jerky movements, vibration, loose connections, pressure (during installation), heat (because of overclocking or improper ventilation) etc. So there are tools like memtest86 to regularly check for memory faults. All of these factors are ignorable for phones because the RAM is tightly integrated with less than a square inch sized SoC chip, keeping in view all above factors.
Another possible reason is electrical failure of the circuits/components e.g. due to electric shock in a sudden blackout which renders it totally useless. This again doesn't seem very probable for phones as the RAM is part of SoC, so the whole SoC should fail along with other, some kind of, surge protection mechanisms (if any).
Since RAM is volatile memory, its cells never get physically changed while reading/writing data unlike eMMCs. eMMC is persistent storage, so the physical properties of silicon cells change during E/P operations. That's why eMMCs have a limited life but RAMs aren't subject to any such limitation.
So if RAM is defective, the most likely is that it was manufactured with faults. RAM failure because of growing bad blocks isn't a common case, at least no sooner than other components of device, but still can't be utterly rejected. So how to fix it?
Since hardware is handled by kernel, the only way to mark some memory addresses bad is by making kernel not allocate those addresses to any userspace program (as can be done on Linux with BadRAM which modifies kernel source). And that too if the bad memory lets the device boot to kernel stage. Otherwise you'll have to handle the matter at SoC/bootloader stage where RAM is being initialized after power on (as can be done on Linux with GRUB and on Windows with BCD). It's definitely impossible on phones since bootloaders are closed source. If your bootloader is configurable like in case of development boards, that's an exception. But in each case you probably have to go through thousands of lines of code.
BadRAM is no more maintained after kernel version 2.6.28, that was 10+ years back (probably because it wasn't accepted into mainstream kernel tree). You can ask the developer if he can assist you to port the patch to ARM (if it's possible at all). Or may be you can exploit kernel parameters mem and/or memmap somehow to achieve what you want. Again the situation might differ a lot when there is no ACPI and no BIOS. Personally I never came across such situation for mobile phones.
BAD BLOCKS ON STORAGE
Coming to the other point, fixing bad blocks makes sense only with hard drives or at maximum with old raw NAND drives (ref). HDDs have a linear LBA to CHS mapping, which means a filesystem knows to which physical location data is being written. Modern flash memory storage devices (including eMMCs, SD cards and SSDs) have a built-in firmware controller called Flash Translation Layer (FTL). FTL handles LBA to PBA mapping, the filesystem and OS are quite unaware of. As a wear-leveling strategy, FTL doesn't map sequentially and the mapping is dynamic. First LBA could correspond to last PBA and last LBA could point to somewhere in the middle, continuously changing with Garbage Collection.
FTL also scans and keeps track of all bad sectors (more specifically silicon cells) and remaps worn bits from overprovisioned (kind of free) space if required. Filesystems will never identify a sector bad, unless the stage comes when E/P cycles limit of flash memory is reached and it starts behaving funny, becomes read-only and ultimately crashes. Even if a purchased software identifies a sector bad, you can't mark it as not allocatable; refer to dynamic nature of LBA to PBA mapping. You mark a sector bad in filesystem and after few minutes that would be moved to some other partition.
HDDs usually don't die at once. Their built-in firmware maintains a list (G-list) of bad sectors from the day of manufacturing (ref). LBAs corresponding to bad sectors get replaced with spare sectors which every HDD has. Once the pool of spare sectors is depleted, any newly appearing (possibly partially) bad sectors are exposed to OS/filesystem. So when a program like chkdsk, e2fsck or badblocks identifies a bad sector, it can handle that at OS level or make it marked bad by HDD firmware. Quoted from here:
If you give permission to overwrite a bad sector SeaTools will attempt to write a pattern of zeros to that sector. Usually, this action will assist the disk drive firmware in managing the problem by retiring the problem LBA and activating a spare in its place.
That's what hdparm --write-sector does.
Mostly filesystems can also maintain a list of bad sectors to be ignored during read/write operations. For instance on ext4, dumpe2fs -b shows a list of bad blocks reserved in bad block inode.
Mostly HDDs (as well as SSDs) are also built with SMART technology to monitor device health, but not eMMCs. In case of eMMC, the only thing e2fsck does is to identify errors within filesystem (and possibly repair using e.g. information from jornal), not in flash memory. All OS's including Android perform filesystem checks on boot before mounting, so that manual checking is not needed.