Unclear about sd-card format

Thank you for your reverse engineering work, great stuff!

I was just looking for options to recover a P5100 from a (likely) eMMC fault and stumbled upon your repository. However, it is not clear to me from the documentation what content the 2nd stage loader expects on the SD. Does it look for the whole boot stage there? Simply a different loader (uboot?) and payload?

Can you elaborate a bit on that? Thank you so much!

Thanks for your message! I know the notes I wrote aren't very clear indeed 😅. I mostly wrote it so that I wouldn't forget what I did. But it's nice to know that other people find it useful as well.

The SBL in this repository expects the same as the original Samsung SBL, but the only difference is that I added some additional commands, and let it load everything that it normally loads from the internal storage from the SD card instead. Essentially this boils down to that the bare minimum it expects are a KERNEL partition with an android boot image flashed to it, and a valid PIT partition right after the GPT.

The easiest way to achieve this is just to flash a backup of the internal mmc to the SD card (or at least the first 52MiB, since the partitions that live here are the most important: KERNEL, PARAM and SBL among others), and after this flash my modified Sbl_uart_external_boot/Sbl.bin or Sbl_uart_external_boot_extra_commands/Sbl.bin to the SBL1 partition. The Sbl_uart_external_boot_extra_commands_default_loadkernelfat/Sbl.bin version is for when instead of a cache partition starting at sector 106496, you create a FAT partition there and put a file called boot.img in it. This loadkernelfat version will then load the kernel from this boot image (useful when using postmarketOS, since updating the kernel there will then automatically cause the tablet to boot from the updated boot.img next time, without having to reflash it to the KERNEL partition.)

But if you use unmodified android, booting entirely from the SD card might not work since the android kernel will try to load the data and system partitions from the internal storage anyway probably regardless of if you load the kernel from the SD card or not. But if you use postmarketOS, you will be able to let the kernel load the root partition from the SD card (so that you don't need the internal storage for anything anymore).

So to clarify: You don't need another bootloader aside from the one you find in this repository (if you don't count the first stage, since it is just the stock Samsung one, and will be copied automatically to the SD card if you write the first 52MiB), so you also don't need to mess with u-boot or a payload. And the bootloader in this repository just looks for a KERNEL partition pointed to by the PIT, or a FAT partition with a file called boot.img, whose contents are the same as the KERNEL partition.

Also I made two GPT partition tables (sdcard-partition-tables.zip), one for android, and one for postmarketOS, which give some more insight into what data is stored where on the SD cards that I have. You can just flash one of these to the first 34 sectors of your SD card before or after you flash the backup of the internal MMC of your device. But this is totally optional.

Oh and one last thing worth mentioning: You will need to execute omapboot (https://github.com/LukasTomek/omapboot) with the -b flag each time you want to boot from the SD card, since the bootrom (baked into the SoC) will load the first stage bootloader from the internal mmc by default, so then you will never even get to the second stage that is written to the SD card. But omapboot -b tells the bootrom to load the first stage bootloader from the SD card, which will then after it is loaded load the second stage bootloader from the SD card as well.

PS: If you don't have a backup of the first 52MiB of your device I can send you a backup image from my GT-P5110, oh and let me know if you get it working!

That makes it a lot clearer, thank you!

Indeed I don't have the first 52MB as I don't have a JTAG rig ready to run nor did I want to attempt a rescue by hand-soldering signal lines to the flash just yet :sweat_smile: There are several 'debrick' image links floating around but I had no luck in finding one that wasn't a dead end. So if you could make that section available I would have a known good starting point which would help me tremendously!

Knowing nothing about the structure of the flash content I tried creating my own from files and offsets I found at various places:

% cat create.sh       
#!/bin/bash

#x-loader (MLO) 0x20000
#u-boot (Sbl.bin) 0x1800000
#boot.img 0x2400000
#recovery.img 0x2C00000

MLO="../../../OMAPFlash/div. models/Targets/Projects/espresso/MLO"
SBL="../../../espresso-sbl/Sbl_uart/Sbl.bin"
REC="../../../OMAPFlash/for_P5113/recovery.img"

OUT="debrick_own.img"
dd if="$MLO" of="$OUT" seek=$((0x20000)) oflag=seek_bytes conv=notrunc
dd if="$SBL" of="$OUT" seek=$((0x1800000)) oflag=seek_bytes conv=notrunc
dd if="$REC" of="$OUT" seek=$((0x2C00000)) oflag=seek_bytes conv=notrunc

# just make sure that every option is the recovery image -> boot img is also recovery img
dd if="$REC" of="$OUT" seek=$((0x2400000)) oflag=seek_bytes conv=notrunc

After writing it to the sdcard (dd if=debrick_own.img of=/dev/sdb oflags=sync) and using omapboot -b nothing happened. From what you wrote I can see two things that are missing: to boot anything from SD I need the Sbl_uart_external_boot loader and I need a partition table where the offsets are properly indexed in. Anything else I'm missing?

My initial goal is to get a recovery image booted and to step up from there (I have no clue yet how to handle postmarketOS or similar, so one step at a time).

Ah yes, booting a recovery image sounds like a good point to get started indeed. And your reconstructed image is indeed almost complete and correct, it only misses the PIT at sector 34 (byte 0x4400) to get the basics working.

There are however also some other partitions, such as PARAM (which contains some boot parameters and boot splash images for Sbl) and GANG (still no clue what this one is for), but those are not required. They will however all be present in the image that I can send (except for KERNEL and RECOVERY, since you already have those, and they are at the end of the image, so that is why it is only 36MiB instead of 52MiB).

But is it okay if I send you this image privately via email or so? Since it does contain an ext4 partition called EFS which contains sensitive data (wifi and bluetooth mac addresses, among other things of which I'm not sure if it would be bad if I share them publicly).

Great to hear that I wasn't completely off the mark, thanks for telling me!

I am currently attempting to find the PIT in one of the firmware dumps so that I can at least document the process of extracting it for people who are not so lucky to have someone handing them a working copy but I was not successful as of yet.

But is it okay if I send you this image privately via email or so? Since it does contain an ext4 partition called EFS which contains sensitive data (wifi and bluetooth mac addresses, among other things of which I'm not sure if it would be bad if I share them publicly).

Oh yeah, sure! You can find an e-mail address in this gist (so I can delete it afterwards :)). Thanks!

Thanks, I sent you an email with the image

I am currently attempting to find the PIT in one of the firmware dumps so that I can at least document the process of extracting it for people who are not so lucky to have someone handing them a working copy but I was not successful as of yet.

Oh you can find a PIT of the GT-P5113 (signed_espresso_20120220_16G.pit.zip) in here: https://sfirmware.com/downloads-file/24603/GT-P5113_XAR_1_20131213093640_j4yd9st9cc_fac

OK, so to summarize (in the sense of this issue).

The layout of the SD card when attempting to run android is (according to your sdcard file) the following:

Number  Start (sector)    End (sector)  Size       Code  Name
   1              34              41   4.0 KiB     8300  PIT
   2              42             255   107.0 KiB   8300  GANG
   3             256             511   128.0 KiB   8300  MLO1
   4             512             767   128.0 KiB   8300  MLO2
   5             768             768   512 bytes   8300  
   6            8192           49151   20.0 MiB    8300  EFS
   7           49152           53247   2.0 MiB     8300  SBL1
   8           53248           57343   2.0 MiB     8300  SBL2
   9           57344           73727   8.0 MiB     8300  PARAM
  10           73728           90111   8.0 MiB     8300  KERNEL
  11           90112          106495   8.0 MiB     8300  RECOVERY
  12          106496         1540095   700.0 MiB   8300  CACHE
  13         1540096         1581055   20.0 MiB    8300  MODEM
  14         1581056         4448255   1.4 GiB     8300  FACTORYFS
  15         4448256        29728733   12.1 GiB    8300  DATAFS
  16        29728734        30777309   512.0 MiB   8300  HIDDEN

where, when running bare minimum, only MLO, PIT, SBL, RECOVERY are needed.

MLO is the first-stage loader and signed by Samsung (?)
PIT is the partition table (what we're looking at right now) so that the loader knows where to look when referencing section names
SBL is the second-stage loader you patched to load from SD card instead of the internal eMMC
RECOVERY is your bog-standard recovery image from somewhere

Anything correct so far?

With that understanding I created two images, one 'from scratch':

MLO="../../OMAPFlash/div. models/Targets/Projects/espresso/MLO"
SBL="../../espresso-sbl/Sbl_uart_external_boot/Sbl.bin"
REC="../../OMAPFlash/for_P5113/recovery.img"
PIT="../../firmware/pit/GTab2 P5100 16G.pit"
BOO="../../firmware/P5100XXDMI1_P5100XSADMI1_XSA/Firmware/unpacked/boot.img"

OUT="debrick_own.img"
dd if="$MLO" of="$OUT" seek=$((0x20000)) oflag=seek_bytes conv=notrunc
dd if="$PIT" of="$OUT" seek=$((0x4400)) oflag=seek_bytes conv=notrunc
dd if="$SBL" of="$OUT" seek=$((0x1800000)) oflag=seek_bytes conv=notrunc
dd if="$REC" of="$OUT" seek=$((0x2C00000)) oflag=seek_bytes conv=notrunc
dd if="$BOO" of="$OUT" seek=$((0x2400000)) oflag=seek_bytes conv=notrunc

and one based on your dump you gave me:

SBL="../../espresso-sbl/Sbl_uart_external_boot/Sbl.bin"
REC="../../OMAPFlash/for_P5113/recovery.img"
BOO="../../firmware/P5100XXDMI1_P5100XSADMI1_XSA/Firmware/unpacked/boot.img"

OUT="debrick_own.img"

# base our image on the dumped 'original'
cp "backup of first 36MiB.img" "$OUT"

dd if="$SBL" of="$OUT" seek=$((0x1800000)) oflag=seek_bytes conv=notrunc
dd if="$REC" of="$OUT" seek=$((0x2C00000)) oflag=seek_bytes conv=notrunc
dd if="$BOO" of="$OUT" seek=$((0x2400000)) oflag=seek_bytes conv=notrunc

My test scenario was:

usb cable unplugged
battery unplugged
sd card inserted
omapboot.py -b started
plug usb cable in
(optionally: press power + volume down)

In both cases the screen stayed black. I would have expected the screen to turn on but apparently something is still wrong. Or is my expectation wrong?

In case I want to debug this further I probably need to connect to the UART - I read that pin 21 on the dock connector is the UART TX pin. There's probably not an easy way to connect to UART without soldering or buying a specific cable?

OK, so to summarize (in the sense of this issue).

The layout of the SD card when attempting to run android is (according to your sdcard file) the following:

Number  Start (sector)    End (sector)  Size       Code  Name
   1              34              41   4.0 KiB     8300  PIT
   2              42             255   107.0 KiB   8300  GANG
   3             256             511   128.0 KiB   8300  MLO1
   4             512             767   128.0 KiB   8300  MLO2
   5             768             768   512 bytes   8300  
   6            8192           49151   20.0 MiB    8300  EFS
   7           49152           53247   2.0 MiB     8300  SBL1
   8           53248           57343   2.0 MiB     8300  SBL2
   9           57344           73727   8.0 MiB     8300  PARAM
  10           73728           90111   8.0 MiB     8300  KERNEL
  11           90112          106495   8.0 MiB     8300  RECOVERY
  12          106496         1540095   700.0 MiB   8300  CACHE
  13         1540096         1581055   20.0 MiB    8300  MODEM
  14         1581056         4448255   1.4 GiB     8300  FACTORYFS
  15         4448256        29728733   12.1 GiB    8300  DATAFS
  16        29728734        30777309   512.0 MiB   8300  HIDDEN

where, when running bare minimum, only MLO, PIT, SBL, RECOVERY are needed.

* `MLO` is the first-stage loader and signed by Samsung (?)

* `PIT` is the partition table (what we're looking at right now) so that the loader knows where to look when referencing section names

* `SBL` is the second-stage loader you patched to load from SD card instead of the internal eMMC

* `RECOVERY` is your bog-standard recovery image from somewhere

Anything correct so far?

Yeah that is mostly correct as far as I understand it, only the PIT is different from the listing you show (made with gdisk -l?), because this listing contains some extra partitions that I added to the GPT (or really overlayed on existing data) to give some insight in data that was previously hidden. These extra partitions (PIT, GANG, MLO1, MLO2 and DDI) aren't present in the PIT. So there is a slight difference there, but that doesn't really matter for your purposes I think.

The debrick_own.img images that you create should be correct indeed, only I don't know if you would additionally need a GPT for the boot rom to find MLO in the image that you create from scratch, but I don't think that is very likely. But I was wondering why you didn't flash a recovery image to the KERNEL partition as well this time, and flashed a (from the path I assumed) stock kernel to it instead. Neither of these things explain why you get a black screen though.

In both cases the screen stayed black. I would have expected the screen to turn on but apparently something is still wrong. Or is my expectation wrong?

Hmm, yeah I also would expect at least a boot splash or a message saying the boot splash JPEG couldn't be loaded. One thing that you can still try is just to keep the battery always plugged in (I never had to even take apart my Tab 2 during my reverse engineering and debricking). Unplugging the battery is only necessary if you want to upload a bootloader via USB with the omapboot -a command.

In case I want to debug this further I probably need to connect to the UART - I read that pin 21 on the dock connector is the UART TX pin. There's probably not an easy way to connect to UART without soldering or buying a specific cable?

That would indeed provide you with answers on what is going on, since both the primary and secondary bootloader print some useful stuff to UART, but I don't know how much effort you are willing to put into this 11 year old tablet haha. What I did to make my UART adapter is just buy a really old iPod/iPad dock connector where all 30 pins are connected (I came across these a lot more than Samsung tablet connectors at thrift stores), and then cut the sides with a sharp knife so that it would fit in upside down, and then connect the wire connected to pin 21 (UART TX as you said indeed) to a USB to serial converter.

Thanks for the explanations! Today was a busy day but I had a partial success yesterday and tried to continue working on that with mixed results.

Yeah that is mostly correct as far as I understand it, only the PIT is different from the listing you show (made with gdisk -l?), because this listing contains some extra partitions that I added to the GPT (or really overlayed on existing data) to give some insight in data that was previously hidden. These extra partitions (PIT, GANG, MLO1, MLO2 and DDI) aren't present in the PIT. So there is a slight difference there, but that doesn't really matter for your purposes I think.

Got it, that makes sense. In my experiments after your comment I resorted to using the partition table from the dump you sent me:

% gdisk -l backup.img
#    1            8192           49151   20.0 MiB    0700  EFS
#    2           49152           53247   2.0 MiB     0700  SBL1
#    3           53248           57343   2.0 MiB     0700  SBL2
#    4           57344           73727   8.0 MiB     0700  PARAM
#    5           73728           90111   8.0 MiB     0700  KERNEL
#    6           90112          106495   8.0 MiB     0700  RECOVERY
#    7          106496         1540095   700.0 MiB   0700  CACHE
#    8         1540096         1581055   20.0 MiB    0700  MODEM
#    9         1581056         4448255   1.4 GiB     0700  FACTORYFS
#   10         4448256        29728733   12.1 GiB    0700  DATAFS
#   11        29728734        30777309   512.0 MiB   0700  HIDDEN

It was a good observation that I didn't flash a recovery image to the KERNEL partition. As soon as I did I was lucky and the screen turned on, showing an empty battery image with a 'waiting' circle which is not moving. The script I used to get that result was:

SBL="../../espresso-sbl/Sbl_uart_external_boot/Sbl.bin"
REC="../../OMAPFlash/for_P5113/recovery.img"
BOO="$REC"

OUT="debrick_own.img"

# base our image on the dumped 'original'
cp "backup of first 36MiB.img" "$OUT"

dd if="$SBL" of="$OUT" seek=$((0x1800000)) oflag=seek_bytes conv=notrunc
dd if="$REC" of="$OUT" seek=$((0x2C00000)) oflag=seek_bytes conv=notrunc
dd if="$BOO" of="$OUT" seek=$((0x2400000)) oflag=seek_bytes conv=notrunc

I could plug the USB cable and the display would remain on and the experiment was reproducible every time. That's when I stopped working on it, happy to have a result I could build up on. Today I tried to replicate this experiment but failed. First I thought that I messed up the images but that no combination worked. I suspect that something else is causing the erratic behavior. That's when I decided that the most productive way forward was to build an UART/USB cable, so I did that from an iPad SD card connector. I don't recommend that, lots of tap welds, but in the end I got it working. Strangely enough, after a few boot attempts with the image that worked yesterday the screen lit up once again.

Log directly before reboot after partition table dump:

loke_init: j4fs_open..success
<start_checksum:310>CHECKSUM_HEADER_SECTOR :42
<start_checksum:313>offset:42, size:1024
Not Need Movinand Checksum
load_lfs_parameters valid magic code and version.
switch_sel_str='1'
switch_sel_int='1'
load_debug_level: read debug level successfully(0x574f4c44)...LOW
init_ddi_data: usable ddi data.
Set charging current USB
omap_max17042_read_temp: FG Temp raw_data : 0x1a58
read_temp_adc:adc_data : 1005
read_temp_adc:adc_data : 1004
read_temp_adc:adc_data : 1004
read_temp_adc:adc_data : 1004
read_temp_adc:adc_data : 1004
check_battery_type: fg temp : 26343, adc_temp : 330
check_battery_type: Set BATTERY_TYPE_SDI
omap_max17042_set_model_data : Fuel gauge init start !!
[MAX17042 Model data] : 0x7df0 0xb500 0xb860 0xb930 0xb980 0xbb70 0xbc00 0xbc70 0xbd20 0xbdb0 0xbef0 0xc140 0xc3c0 0xc6e0 0xcd20 0xd100 0x20 0x340 0x15d0 0x2dd0 0x600 0x18f0 0x25a0 0x1800 0x22a0 0x1670 0x9a0 0x8c0 0xb30 0x4f0 0x870 0x870 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 
[CHARGER] Verify Lock Model Access
omap_max17042_set_model_data: DesignCAP :0x4995
max17042_compensate_soc: vcell(3449), rep_soc(1)
calculate_table_soc: charging status : 2, vcell(3449), table_soc(1)
[SBL] VFOCV MSB : 0xaa, LSB : 0xf7
[SBL_CHARGER] SOC : 1, VCELL : 3449, VFSOC : 1, VFOCV : 3419
Under voltage charing : USB
reading nps status file is successfully!.
g_nRebootReason = 0x40000

Log for 'successful' boot directly after partition table dump:

loke_init: j4fs_open..success
<start_checksum:310>CHECKSUM_HEADER_SECTOR :42
<start_checksum:313>offset:42, size:1024
Not Need Movinand Checksum
load_lfs_parameters valid magic code and version.
switch_sel_str='1'
switch_sel_int='1'
load_debug_level: read debug level successfully(0x574f4c44)...LOW
init_ddi_data: usable ddi data.
Set charging current USB
omap_max17042_read_temp: FG Temp raw_data : 0x1a58
read_temp_adc:adc_data : 1004
read_temp_adc:adc_data : 1004
read_temp_adc:adc_data : 1004
read_temp_adc:adc_data : 1003
read_temp_adc:adc_data : 1003
check_battery_type: fg temp : 26343, adc_temp : 330
check_battery_type: Set BATTERY_TYPE_SDI
omap_max17042_set_model_data : Fuel gauge init start !!
[MAX17042 Model data] : 0x7df0 0xb500 0xb860 0xb930 0xb980 0xbb70 0xbc00 0xbc70 0xbd20 0xbdb0 0xbef0 0xc140 0xc3c0 0xc6e0 0xcd20 0xd100 0x20 0x340 0x15d0 0x2dd0 0x600 0x18f0 0x25a0 0x1800 0x22a0 0x1670 0x9a0 0x8c0 0xb30 0x4f0 0x870 0x870 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 
[CHARGER] Verify Lock Model Access
omap_max17042_set_model_data: DesignCAP :0x4995
max17042_compensate_soc: vcell(3451), rep_soc(1)
calculate_table_soc: charging status : 2, vcell(3451), table_soc(1)
[SBL] VFOCV MSB : 0xaa, LSB : 0xff
[SBL_CHARGER] SOC : 1, VCELL : 3451, VFSOC : 1, VFOCV : 3419
reading nps status file is successfully!.
g_nRebootReason = 0x40000
set_lcd_panel_id: panel_adc=0
*** ltn101al03_power_on ***
lcd_pannel_id=1

Autoboot (1 seconds) in progress, press any key to stop .

boot_kernel: debug level low!
checkbit: find RECOVERY
checkbit (00000000)
Kernel  @ 81808000 (0x3a7498 bytes)
Ramdisk @ 82800000 (0x1e2656 bytes)
[WARNING] Current kernel is NOT official binary!!!

I suspect that 3,45V is a cut-off voltage and the device just won't boot below that. The problem is that apparently the battery is not charging when the device is showing the empty battery (it is probably just stuck looking for files). Do you have, by any chance, an idea if and what files it may need to proceed booting into something useful?

I also tried to move on with building a minimum bootable image from scratch:

MLO="./MLO.img" # extracted from backup, the one I used before doesn't boot at all
SBL="../../espresso-sbl/Sbl_uart_external_boot/Sbl.bin"
REC="../../OMAPFlash/for_P5113/recovery.img"
PIT="../../firmware/pit/GTab2 P5100 16G.pit"
#BOO="../../firmware/P5100XXDMI1_P5100XSADMI1_XSA/Firmware/unpacked/boot.img"
BOO="$REC"

OUT="debrick_own.img"

if [ -e "$OUT" ]; then
    rm "$OUT"
fi

# allocate space sparsely to work on
truncate -s 16GiB "$OUT"

# create partition table
parted "$OUT" mklabel gpt
sgdisk -a 1 \
       -n  1:8192:49151        -t  1:0700 -c  1:EFS  \
       -n  2:49152:53247       -t  2:0700 -c  2:SBL1  \
       -n  3:53248:57343       -t  3:0700 -c  3:SBL2  \
       -n  4:57344:73727       -t  4:0700 -c  4:PARAM  \
       -n  5:73728:90111       -t  5:0700 -c  5:KERNEL  \
       -n  6:90112:106495      -t  6:0700 -c  6:RECOVERY  \
       -n  7:106496:1540095    -t  7:0700 -c  7:CACHE  \
       -n  8:1540096:1581055   -t  8:0700 -c  8:MODEM  \
       -n  9:1581056:4448255   -t  9:0700 -c  9:FACTORYFS  \
       -n 10:4448256:29728733  -t 10:0700 -c 10:DATAFS  \
       -n 11:29728734:30777309 -t 11:0700 -c 11:HIDDEN \
       "$OUT"

# write payloads
dd if="$MLO" of="$OUT" seek=$((0x20000)) oflag=seek_bytes conv=notrunc
dd if="$PIT" of="$OUT" seek=$((0x4400)) oflag=seek_bytes conv=notrunc
dd if="$SBL" of="$OUT" seek=$((0x1800000)) oflag=seek_bytes conv=notrunc
dd if="$REC" of="$OUT" seek=$((0x2C00000)) oflag=seek_bytes conv=notrunc
dd if="$BOO" of="$OUT" seek=$((0x2400000)) oflag=seek_bytes conv=notrunc

# reduce size to initial 50MiB for now
truncate -s 50MiB "$OUT"

However booting fails here with the following message:

loke_init: j4fs_open..fsd_reclaim 1287: MST is not recognized(mst.magic=0x00000000)
fsd_reclaim 1288: MST is not recognized
fsd_reclaim 1603: Error(nErr=0x00000000)
fsd_reclaim 1608: j4fs_rw_start is set to default value(128KB)
j4fs_open 65: Error(nErr=0x40000000)
failed
init_ddi_data: initialize ddi datas.
Set charging current USB
omap_max17042_read_temp: FG Temp raw_data : 0x1bdb
read_temp_adc:adc_data : 1012
read_temp_adc:adc_data : 1011
read_temp_adc:adc_data : 1011
read_temp_adc:adc_data : 1011
read_temp_adc:adc_data : 1010
check_battery_type: fg temp : 27854, adc_temp : 330
check_battery_type: Set BATTERY_TYPE_SDI
omap_max17042_set_model_data : Fuel gauge init start !!
[MAX17042 Model data] : 0x7df0 0xb500 0xb860 0xb930 0xb980 0xbb70 0xbc00 0xbc70 0xbd20 0xbdb0 0xbef0 0xc140 0xc3c0 0xc6e0 0xcd20 0xd100 0x20 0x340 0x15d0 0x2dd0 0x600 0x18f0 0x25a0 0x1800 0x22a0 0x1670 0x9a0 0x8c0 0xb30 0x4f0 0x870 0x870 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 
[CHARGER] Verify Lock Model Access
omap_max17042_set_model_data: DesignCAP :0x4995
max17042_compensate_soc: vcell(3411), rep_soc(1)
calculate_table_soc: charging status : 2, vcell(3411), table_soc(0)
[SBL] VFOCV MSB : 0xa9, LSB : 0x57
[SBL_CHARGER] SOC : 1, VCELL : 3411, VFSOC : 1, VFOCV : 3386
Under voltage charing : USB
j4fs_read_file_bootloader 267: j4fs panic
nps status file does not exist..
nps status is incorrect!! set default status.(completed)
g_nRebootReason = 0x40000

But sometimes it succeeds - probably again the battery level - but is just a green text/black screen message that it can't draw/find the battery charging image. So these assets are probably located in the EFS partition? (Edit: this link says that the PARAM partition contains all the images)

loke_init: j4fs_open..fsd_reclaim 1287: MST is not recognized(mst.magic=0x00000000)
fsd_reclaim 1288: MST is not recognized
fsd_reclaim 1603: Error(nErr=0x00000000)
fsd_reclaim 1608: j4fs_rw_start is set to default value(128KB)
j4fs_open 65: Error(nErr=0x40000000)
failed
init_ddi_data: initialize ddi datas.
Set charging current USB
omap_max17042_read_temp: FG Temp raw_data : 0x1b8f
read_temp_adc:adc_data : 1054
read_temp_adc:adc_data : 1052
read_temp_adc:adc_data : 1052
read_temp_adc:adc_data : 1053
read_temp_adc:adc_data : 1052
check_battery_type: fg temp : 27557, adc_temp : 320
check_battery_type: Set BATTERY_TYPE_SDI
omap_max17042_set_model_data : Fuel gauge init start !!
[MAX17042 Model data] : 0x7df0 0xb500 0xb860 0xb930 0xb980 0xbb70 0xbc00 0xbc70 0xbd20 0xbdb0 0xbef0 0xc140 0xc3c0 0xc6e0 0xcd20 0xd100 0x20 0x340 0x15d0 0x2dd0 0x600 0x18f0 0x25a0 0x1800 0x22a0 0x1670 0x9a0 0x8c0 0xb30 0x4f0 0x870 0x870 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 0x200 
[CHARGER] Verify Lock Model Access
omap_max17042_set_model_data: DesignCAP :0x4995
max17042_compensate_soc: vcell(3473), rep_soc(1)
calculate_table_soc: charging status : 2, vcell(3473), table_soc(1)
[SBL] VFOCV MSB : 0xab, LSB : 0xfb
[SBL_CHARGER] SOC : 1, VCELL : 3473, VFSOC : 1, VFOCV : 3439
j4fs_read_file_bootloader 267: j4fs panic
nps status file does not exist..
nps status is incorrect!! set default status.(completed)
g_nRebootReason = 0x40000
j4fs_read_file_bootloader 267: j4fs panic
lfs_file_draw_image: j4fs draw failed. err=0x40000000
set_lcd_panel_id: panel_adc=0
*** ltn101al03_power_on ***
lcd_pannel_id=1

Autoboot (1 seconds) in progress, press any key to stop .

boot_kernel: debug level low!
checkbit: find RECOVERY
checkbit (00000000)
Kernel  @ 81808000 (0x3a7498 bytes)
Ramdisk @ 82800000 (0x1e2656 bytes)
[WARNING] Current kernel is NOT official binary!!!
j4fs_read_file_bootloader 267: j4fs panic
j4fs_read_file_bootloader 267: j4fs panic

So I guess this is a success in a way. I still wonder if one is able to find things such as the MLO in the officiel firmware (I don't think so, I couldn't find MLO or PRIMAPP strings in any of the firmware dumps I found).

Anyway, next step would probably be to see why the recovery doesn't boot 'properly' and what's still missing.

I suspect that 3,45V is a cut-off voltage and the device just won't boot below that. The problem is that apparently the battery is not charging when the device is showing the empty battery (it is probably just stuck looking for files). Do you have, by any chance, an idea if and what files it may need to proceed booting into something useful?

Oh wow, very nice! That may well be why it isn't booting sometimes indeed, because for me it also didn't boot when the battery was completely empty, but it should charge very slowly even if the device is completely turned off (but if the screen is on, this slow charging might be slower than the drain caused by the screen being turned on). I just now tried booting a recovery image myself from the SD card, to try if that works, but apparantly the TWRP 3.3.0-2 recovery that I have only works from internal storage for some reason. So if you also use TWRP that might be the cause that you don't get further in the booting process, since the log from Sbl implies that starting the kernel was successful (otherwise it wouldn't show the Kernel @ and Ramdisk @ lines).

However booting fails here with the following message:

No I think actually that it is working fine also, because the errors that are shown are only related to not being able to find the assets in the PARAM partition and the DDI data, but it will use sane defaults for the most important stuff that's normally in PARAM anyway, so the PARAM partition isn't really required (except if you want the splash JPEGs). And the thing with the DDI data is that a defaults copy of this is stored in SBL, so when the device sees that the DDI data is empty, it will copy the DDI data from Sbl to sector 768 anyway, so it is also not required.

But sometimes it succeeds - probably again the battery level - but is just a green text/black screen message that it can't draw/find the battery charging image. So these assets are probably located in the EFS partition? (Edit: this link says that the PARAM partition contains all the images)

Your edit is correct indeed! You can even modify the assets in the PARAM partition if you want with https://github.com/ius/j4fs_extract (with these flags: -p 2048 -b 131072) and the scripts found here: https://forum.xda-developers.com/t/how-to-boot-logo-modify-samsung-galaxy-tab-2-boot-logo.1898377/.

So I guess this is a success in a way. I still wonder if one is able to find things such as the MLO in the officiel firmware (I don't think so, I couldn't find MLO or PRIMAPP strings in any of the firmware dumps I found).

Anyway, next step would probably be to see why the recovery doesn't boot 'properly' and what's still missing.

Oh the MLO can be found in the same firmware release as I referenced here (and you can also find param.lfs (for the PARAM partition) here), sorry I wasn't more clear about that before, maybe that would have saved you some effort:

Oh you can find a PIT of the GT-P5113 (signed_espresso_20120220_16G.pit.zip) in here: https://sfirmware.com/downloads-file/24603/GT-P5113_XAR_1_20131213093640_j4yd9st9cc_fac

But to get something booting you can maybe try some other recoveries first (if you were also using TWRP), you can find PhilZ and CWM recoveries for all GT-P51XX devices here: https://andi34.github.io/recoveries_tab2.html, or you could try to boot a postmarketOS boot image, since those get quite far in the booting process without needing a root partition or anything: pmos-boot.zip

Ooh I also found the MLO and param.lfs files (but no PIT sadly) here by the way: https://sfirmware.com/downloads-file/4656/GT-P5110_PHN_1_20131219175220_kduop6lmam

Oh and one other thing that you might also find useful (since you are trying to reconstruct a bootable SD card entirely from official Samsung releases right?) is that the Sbl.bin binaries can also be found in both these official update releases, so instead of taking the Sbl.bin from this repository, you can also take only one of the .patch files from this repository and patch the official Sbl.bin yourself using bspatch. (Although the Sbl.bin I used as a starting point (the one found in the root of this repository) should be the same as the one found in official Samsung update releases.)

Oh the MLO can be found in the same firmware release as I referenced here (and you can also find param.lfs (for the PARAM partition) here), sorry I wasn't more clear about that before, maybe that would have saved you some effort: [...] Ooh I also found the MLO and param.lfs files (but no PIT sadly) here by the way: https://sfirmware.com/downloads-file/4656/GT-P5110_PHN_1_20131219175220_kduop6lmam

Ah, perfect, I must have missed the MLO file before because I'm pretty sure I saw that image haha. Thanks! It's a shame about the PIT file. I really don't want to re-create whatever format that is. Heimdall doesn't seem to support a conversion from GPT to PIT either. Maybe that's OK though - at least the offsets are known and someone more brave than I can implement this :')

But to get something booting you can maybe try some other recoveries first (if you were also using TWRP), you can find PhilZ and CWM recoveries for all GT-P51XX devices here: https://andi34.github.io/recoveries_tab2.html, or you could try to boot a postmarketOS boot image, since those get quite far in the booting process without needing a root partition or anything: pmos-boot.zip

Well I managed to get a CWM recovery image booting (the same one that I was referencing the whole time). The 'trick' is to pull the USB cable in just the right moment (after payload is sent but before the empty battery symbol appears). Then the Samsung logo will appear and shortly after the recovery boots. I have no clue why that is, though. Maybe because the battery calibration data can't be accessed (due to potentially broken eMMC), battery loader engages, tries to access eMMC but nothing happens? Removing the USB cable would interrupt the charging process and normal boot could continue. That's my best guess so far anyway.

I used adb to scroll through the system and noticed that there was only one mmcblk device and parted said it was a SanDisk SD-card. Is this a device enumeration issue by the boot loader (uboot/Sbl)? Or is the eMMC not responding and doesn't get iterated by the kernel? Do you know?

Oh and one other thing that you might also find useful (since you are trying to reconstruct a bootable SD card entirely from official Samsung releases right?) is that the Sbl.bin binaries can also be found in both these official update releases, so instead of taking the Sbl.bin from this repository, you can also take only one of the .patch files from this repository and patch the official Sbl.bin yourself using bspatch. (Although the Sbl.bin I used as a starting point (the one found in the root of this repository) should be the same as the one found in official Samsung update releases.)

Yes, that would be preferable, thanks for the hint :)

Well I managed to get a CWM recovery image booting (the same one that I was referencing the whole time). The 'trick' is to pull the USB cable in just the right moment (after payload is sent but before the empty battery symbol appears). Then the Samsung logo will appear and shortly after the recovery boots. I have no clue why that is, though. Maybe because the battery calibration data can't be accessed (due to potentially broken eMMC), battery loader engages, tries to access eMMC but nothing happens? Removing the USB cable would interrupt the charging process and normal boot could continue. That's my best guess so far anyway.

Hmm I don't think the problem would be that the battery calibration data can't be accessed, since I'm really sure that the patched secondary bootloader doesn't try to access anything from the internal eMMC anymore (it may as well not exist as far as SBL is concerned). (Edit: I also don't know of any calibration data for the battery being stored by the bootloaders, and if it would be stored somewhere it would be either in the DDI data, or PARAM, but I don't know everything about this device ofcourse)

One theory that I have now is that when you boot from charging mode, the secondary bootloader adds some extra command line parameters to indicate that instead of booting into android, the charging animation should be displayed by the kernel. And maybe the recovery doesn't recognize these parameters and stops the booting process, but this isn't very likely I think because you would then expect the recovery also not to work when booting from internal eMMC in charging mode and when flashed to the KERNEL partition, so maybe I'll take a look tomorrow if I can figure out why this is the case (I also wasn't able to boot a recovery image from the KERNEL partition from external storage in charging mode)

I used adb to scroll through the system and noticed that there was only one mmcblk device and parted said it was a SanDisk SD-card. Is this a device enumeration issue by the boot loader (uboot/Sbl)? Or is the eMMC not responding and doesn't get iterated by the kernel? Do you know?

You were doing this from CWM right? Because then it can't really be Sbl or the X-Loader I think, since the recovery will reinitialize all the IO, so even if the eMMC wasn't properly initialized in Sbl or X-Loader, that wouldn't have any effect once booted into CWM. And I can't say for sure, but it sounds like the internal eMMC is not responding indeed, but you could maybe look at the kernel log from the recovery to see if that gives you more clues, or maybe try another recovery to see if that can detect your internal eMMC.

One theory that I have now is that when you boot from charging mode, the secondary bootloader adds some extra command line parameters to indicate that instead of booting into android, the charging animation should be displayed by the kernel. And maybe the recovery doesn't recognize these parameters and stops the booting process, but this isn't very likely I think because you would then expect the recovery also not to work when booting from internal eMMC in charging mode and when flashed to the KERNEL partition, so maybe I'll take a look tomorrow if I can figure out why this is the case (I also wasn't able to boot a recovery image from the KERNEL partition from external storage in charging mode)

Today I tried testing my theory by checking if a recovery boot image would boot properly from the internal eMMC KERNEL partition while charging, and it had the same outcome as I observed when booting from the external storage KERNEL partition (screen black, but with backlight on forever). So it seems that when booting a kernel in charging mode Sbl does indeed do something that prevents a recovery image to boot (regardless of the storage device used).

Could be wrong command line parameters for the recovery kernel, but I now suspect that it actually may be that Sbl doesn't load the ramdisk (which is quite essential for a recovery to work), to save time when booting the kernel in charging animation mode. This makes more sense I think because I don't think a recovery really cares about it's command line parameters that much, but it does care if its ramdisk is not loaded. And a ramdisk is not really needed when the regular android kernel only needs to show a charging animation.

You were doing this from CWM right? Because then it can't really be Sbl or the X-Loader I think, since the recovery will reinitialize all the IO, so even if the eMMC wasn't properly initialized in Sbl or X-Loader, that wouldn't have any effect once booted into CWM. And I can't say for sure, but it sounds like the internal eMMC is not responding indeed, but you could maybe look at the kernel log from the recovery to see if that gives you more clues, or maybe try another recovery to see if that can detect your internal eMMC.

Yes, I was. I assumed that the recovery would initialize all storage on its own anyway, I was merely hoping that it wasn't the case :) Thanks for confirming.

I'm not sure why I didn't check the kernel log at the first attempt but I guess I was just accepting that the eMMC was dead. To confirm I redid the whole process (note: apparently it is necessary for the battery to have ~3.6V to successfully boot the recovery, 3.48V was not enough). Here's the respective mmc0 message:

<6>[    3.856567] mmc0 LDO enable
<4>[    3.869720] omap_hsmmc omap_hsmmc.0: New Card Inserted
<4>[    3.877136] omap_hsmmc omap_hsmmc.1: Status=18000 cmd =52
<4>[    3.882476] omap_hsmmc omap_hsmmc.1: Status=18000 cmd =52
<4>[    3.890930] omap_hsmmc omap_hsmmc.1: Status=18000 cmd =8
<4>[    3.896270] omap_hsmmc omap_hsmmc.1: Status=18000 cmd =5
<4>[    3.901580] omap_hsmmc omap_hsmmc.1: Status=18000 cmd =5
<4>[    3.906890] omap_hsmmc omap_hsmmc.1: Status=18000 cmd =5
<4>[    3.912200] omap_hsmmc omap_hsmmc.1: Status=18000 cmd =5
<4>[    3.917572] omap_hsmmc omap_hsmmc.1: Status=18000 cmd =55
<4>[    3.922912] omap_hsmmc omap_hsmmc.1: Status=18000 cmd =55
<4>[    3.928283] omap_hsmmc omap_hsmmc.1: Status=18000 cmd =55
<4>[    3.933685] omap_hsmmc omap_hsmmc.1: Status=18000 cmd =55
<6>[    6.283538] mmc0 LDO Disable
<3>[    6.392883] mmc0: error -110 whilst initialising MMC card

I think that error -110 is a timeout which is in line of what was suspected anyway (eMMC ded). It is not unlikely that this is just another case of "BGA chip not properly adhered anymore" but I also distinctly remember a series of bugs in the Samsung Galaxy phone line were the eMMC would soft-lockup. Either way, I'm probably not attempting to fix it. I will, however, attempt to create a bootable SD card with Android running on it to see how that feels.

Could be wrong command line parameters for the recovery kernel, but I now suspect that it actually may be that Sbl doesn't load the ramdisk (which is quite essential for a recovery to work), to save time when booting the kernel in charging animation mode. This makes more sense I think because I don't think a recovery really cares about it's command line parameters that much, but it does care if its ramdisk is not loaded. And a ramdisk is not really needed when the regular android kernel only needs to show a charging animation.

Hmm, yes, that would make sense (booting to charging needs to happen as fast as possible to reduce UX problems). What I don't understand is why, with a proper boot image in place on the SD card, charging still doesn't work.

I documented my scripts and "findings" that I made so far in a separate repository (where I dumped some PIT files as well): https://github.com/githubnemo/galaxy-tab-2-debrick-images/ I decided that I can't be bothered to create these from scratch. I documented two ways of how to get into ODIN with custom debrick images (one with UART and one without UART cable). Since this is not a road I will go down (since the eMMC is dead and not reflashable via ODIN, as it seems) I will concentrate on how to get a working Android image on the SD card.

I'm not sure why I didn't check the kernel log at the first attempt but I guess I was just accepting that the eMMC was dead. To confirm I redid the whole process (note: apparently it is necessary for the battery to have ~3.6V to successfully boot the recovery, 3.48V was not enough). Here's the respective mmc0 message:
<6>[    3.856567] mmc0 LDO enable
<4>[    3.869720] omap_hsmmc omap_hsmmc.0: New Card Inserted
<4>[    3.877136] omap_hsmmc omap_hsmmc.1: Status=18000 cmd =52
<4>[    3.882476] omap_hsmmc omap_hsmmc.1: Status=18000 cmd =52
<4>[    3.890930] omap_hsmmc omap_hsmmc.1: Status=18000 cmd =8
<4>[    3.896270] omap_hsmmc omap_hsmmc.1: Status=18000 cmd =5
<4>[    3.901580] omap_hsmmc omap_hsmmc.1: Status=18000 cmd =5
<4>[    3.906890] omap_hsmmc omap_hsmmc.1: Status=18000 cmd =5
<4>[    3.912200] omap_hsmmc omap_hsmmc.1: Status=18000 cmd =5
<4>[    3.917572] omap_hsmmc omap_hsmmc.1: Status=18000 cmd =55
<4>[    3.922912] omap_hsmmc omap_hsmmc.1: Status=18000 cmd =55
<4>[    3.928283] omap_hsmmc omap_hsmmc.1: Status=18000 cmd =55
<4>[    3.933685] omap_hsmmc omap_hsmmc.1: Status=18000 cmd =55
<6>[    6.283538] mmc0 LDO Disable
<3>[    6.392883] mmc0: error -110 whilst initialising MMC card
I think that error -110 is a timeout which is in line of what was suspected anyway (eMMC ded). It is not unlikely that this is just another case of "BGA chip not properly adhered anymore" but I also distinctly remember a series of bugs in the Samsung Galaxy phone line were the eMMC would soft-lockup.

Ah that's too bad, but I think running Android from the SD card wouldn't feel that much slower than from internal eMMC, since the eMMC is also quite slow (max 30MB/s or so while reading I found), so you might have quite an okay experience, and it sounds like a fun challenge!

I documented my scripts and "findings" that I made so far in a separate repository (where I dumped some PIT files as well): https://github.com/githubnemo/galaxy-tab-2-debrick-images/

Looks good! I hope that you get Android running on the SD card, and don't hesitate to ask me a question if you're stuck on something.

Edit:

What I don't understand is why, with a proper boot image in place on the SD card, charging still doesn't work.

I also don't know for sure, what charger are you using? Because from my experience some chargers that are not original samsung chargers don't work properly or only very slowly with this tablet (for me it does charge connected to a PC, but only very slowly).

I also don't know for sure, what charger are you using? Because from my experience some chargers that are not original samsung chargers don't work properly or only very slowly with this tablet (for me it does charge connected to a PC, but only very slowly).

I only charge it connected to the PC since I don't have the original charger anymore, so I'm stuck at slow charging I guess. At least I manage to regularly charge it to ~3.7V which is OK to do stuff with.

Ah that's too bad, but I think running Android from the SD card wouldn't feel that much slower than from internal eMMC, since the eMMC is also quite slow (max 30MB/s or so while reading I found), so you might have quite an okay experience, and it sounds like a fun challenge!

I thought so too but there are some roadblocks that I don't quite know yet how to get over.

First the good bit: I managed to build a Samsung firmware image from the downloaded files (the final 'trick' was that I ignored the fact that the images are actually sparse images and need to be unpacked before writing them with dd). The script is here.

In this endeavor I also attempted to create the EFS partition from scratch. I'm still unclear about certain binary files but I think I have the file system flags down and the general structure as well - all packaged into a script.

For testing I'm using the EFS from your backup file, just to be sure that EFS is not the issue here.

My process is this:

flashing image to the SD card
booting with omapboot
unplugging the USB cable
samsung boot logo appears

When written freshly to the SD card the image boot into the Android firmware recovery screen, the progress bar is loading and then, after a while, the tablet just turns off. After that it only boots into recovery. There are no error messages when it boots into recovery (not the clockwork recovery but the plain stock one - factory menu?).

Maybe that's the case because /EFS/FactoryApp/factorymode is set to ON but I don't know. It could be an error as well. Since the EFS partition comes from you - do you know? :)

I also changed, proactively, the /system/etc/vold.fstab to access every partition from mmc1 instead of the respective USB device (since that is not likely to exist anymore). That's a bit confusing though since I would have expected it to be MMC and not USB in the first place. (edit: I have not tried this modification on a 'fresh' SD card yet, that's something I could still attempt but I feel that doing this blindly is a bit pointless)

{
        supported_exfat = yes
}
dev_mount sda /storage/UsbDriveA auto /devices/platform/omap/omap_hsmmc.0/mmc_host/mmc1

{
        supported_exfat = yes
}
dev_mount sdb /storage/UsbDriveB auto /devices/platform/omap/omap_hsmmc.0/mmc_host/mmc1

{
        supported_exfat = yes
}
dev_mount sdc /storage/UsbDriveC auto /devices/platform/omap/omap_hsmmc.0/mmc_host/mmc1

{
        supported_exfat = yes
}
dev_mount sdd /storage/UsbDriveD auto /devices/platform/omap/omap_hsmmc.0/mmc_host/mmc1

{
        supported_exfat = yes
}
dev_mount sde /storage/UsbDriveE auto /devices/platform/omap/omap_hsmmc.0/mmc_host/mmc1

{
        supported_exfat = yes
}
dev_mount sdf /storage/UsbDriveF auto /devices/platform/omap/omap_hsmmc.0/mmc_host/mmc1

Anyway, I'm a bit blind at the moment. I'd love to have a serial console but changing CMDLINE to something that this thread suggested:

setenv CMDLINE root=/dev/mmcblk0p1 rw rootdelay=2 init=/init vram=15M omapfb.vram=0:8M console=ttySAC4,115200 loglevel=4

didn't change a thing. That's also probably the wrong tty device but since this is the last thing I tried I didn't research into the correct tty device. I also tried changing mmcblk0 to mmcblk1 but I think I remember that mmc0 doesn't get registered and the sdcard is presented as mmcblk0 so that shouldn't cause trouble.

First the good bit: I managed to build a Samsung firmware image from the downloaded files (the final 'trick' was that I ignored the fact that the images are actually sparse images and need to be unpacked before writing them with dd). The script is here.

In this endeavor I also attempted to create the EFS partition from scratch. I'm still unclear about certain binary files but I think I have the file system flags down and the general structure as well - all packaged into a script.

Ooh that looks really good indeed!

Maybe that's the case because /EFS/FactoryApp/factorymode is set to ON but I don't know. It could be an error as well. Since the EFS partition comes from you - do you know? :)

Oh I wouldn't know for sure, but I don't think it would cause the system not to boot normally, since I made two backups of the EFS partition, and on both occasions I made the backup, Android was booting normally, so I think it is normal that this flag is set to ON. But what does the progress bar that you get look like? Does it have any text under it? And did you also try lineage os or some other custom rom by the way?

I also changed, proactively, the /system/etc/vold.fstab to access every partition from mmc1 instead of the respective USB device (since that is not likely to exist anymore). That's a bit confusing though since I would have expected it to be MMC and not USB in the first place. (edit: I have not tried this modification on a 'fresh' SD card yet, that's something I could still attempt but I feel that doing this blindly is a bit pointless)
{
        supported_exfat = yes
}
dev_mount sda /storage/UsbDriveA auto /devices/platform/omap/omap_hsmmc.0/mmc_host/mmc1

{
        supported_exfat = yes
}
dev_mount sdb /storage/UsbDriveB auto /devices/platform/omap/omap_hsmmc.0/mmc_host/mmc1

{
        supported_exfat = yes
}
dev_mount sdc /storage/UsbDriveC auto /devices/platform/omap/omap_hsmmc.0/mmc_host/mmc1

{
        supported_exfat = yes
}
dev_mount sdd /storage/UsbDriveD auto /devices/platform/omap/omap_hsmmc.0/mmc_host/mmc1

{
        supported_exfat = yes
}
dev_mount sde /storage/UsbDriveE auto /devices/platform/omap/omap_hsmmc.0/mmc_host/mmc1

{
        supported_exfat = yes
}
dev_mount sdf /storage/UsbDriveF auto /devices/platform/omap/omap_hsmmc.0/mmc_host/mmc1

Hmm this seems to only be responsible for when a USB stick connected via USB OTG to the tablet or something I think, although it is strange that mmc1 is mentioned here. Are there no other references to mmc1 or mmc0 in files in the system partition? (Also I think the omap_hsmmc.0 part of the path should be different, not sure what though, but you could check that in the CWM recovery, since that is probably almost the same kernel, and see what the path for your mmc device is there under /devices/platform.)

Anyway, I'm a bit blind at the moment. I'd love to have a serial console but changing CMDLINE to something that this thread suggested:
setenv CMDLINE root=/dev/mmcblk0p1 rw rootdelay=2 init=/init vram=15M omapfb.vram=0:8M console=ttySAC4,115200 loglevel=4

Yeah I understand, Android doesn't give off a lot of information while booting. Maybe you could check what /dev/tty* device sends output to the 30 pin UART connection in the CWM recovery also, and use that same name in the kernel command line to at least get some debugging information from the Android kernel. You can probably just do echo "test" > /dev/tty{All available TTYs} in a shell in the CWM recovery (CWM does have one right?), and see which one gives you output on your computer.

But do you really want to get Android working first? Because it might be easier to get postmarketOS to boot first, since that gives you a lot more debugging information. But that probably wouldn't really help you in getting Android to work though.

Hmm this seems to only be responsible for when a USB stick connected via USB OTG to the tablet or something I think, although it is strange that mmc1 is mentioned here. Are there no other references to mmc1 or mmc0 in files in the system partition? (Also I think the omap_hsmmc.0 part of the path should be different, not sure what though, but you could check that in the CWM recovery, since that is probably almost the same kernel, and see what the path for your mmc device is there under /devices/platform.)

Right - that's strange - I wrongly assumed that vold is responsible for system critical mounts as well but it is, apparently, just responsible for handling auto mounting of user appliances. Thanks for clearing that up! The device, though, is correct. I checked it before and it is, indeed, the path to the SD card. There's also mmc0 but it is unresponsive, as expected.

Yeah I understand, Android doesn't give off a lot of information while booting. Maybe you could check what /dev/tty* device sends output to the 30 pin UART connection in the CWM recovery also, and use that same name in the kernel command line to at least get some debugging information from the Android kernel. You can probably just do echo "test" > /dev/tty{All available TTYs} in a shell in the CWM recovery (CWM does have one right?), and see which one gives you output on your computer.

That's a good idea.

# cat /proc/tty/drivers
/dev/tty             /dev/tty        5       0 system:/dev/tty
/dev/console         /dev/console    5       1 system:console
/dev/ptmx            /dev/ptmx       5       2 system
/dev/vc/0            /dev/vc/0       4       0 system:vtmaster
rfcomm               /dev/rfcomm   216 0-255 serial
g_serial             /dev/ttyGS    249 0-3 serial
usbserial            /dev/ttyUSB   188 0-253 serial
acm                  /dev/ttyACM   166 0-31 serial
OMAP-SERIAL          /dev/ttyO     252 0-3 serial
pty_slave            /dev/pts      136 0-1048575 pty:slave
pty_master           /dev/ptm      128 0-1048575 pty:master
unknown              /dev/tty        4 1-63 console

It seems that writing data to /dev/ttyO3 produces some traffic on my serial2usb adapter. However, I cannot set the CMDLINE via the second stage bootloader. Apparently changes to the CMDLINE environment variable are ignored. I tried disasembling Sbl.bin using binutils/objdump to see under what circumstances the serial device in the kernel cmdline is set (there's a format string with console=serial,ttyO%d in Sbl.bin) but I didn't really understand the format. binwalk says the binary includes several images (understandably) and an android boot image. I assume that the first portion of the binary is a bit of fluff to get a small Linux kernel loading? But then I don't understand why an android boot image is needed. Can you shed some light on this? I'd really love to know which environment variables I need to modify to get a 'debug' CMDLINE in Sbl :)

But do you really want to get Android working first? Because it might be easier to get postmarketOS to boot first, since that gives you a lot more debugging information. But that probably wouldn't really help you in getting Android to work though.

Well, as far as I'm concerned Android is already 'running' - it is just not fully booting. I don't think that there's a lot to learn from postmarketOS (although I appreciate the project a lot and I may be going to use it in the end).

It seems that writing data to /dev/ttyO3 produces some traffic on my serial2usb adapter. However, I cannot set the CMDLINE via the second stage bootloader. Apparently changes to the CMDLINE environment variable are ignored. I tried disasembling Sbl.bin using binutils/objdump to see under what circumstances the serial device in the kernel cmdline is set (there's a format string with console=serial,ttyO%d in Sbl.bin) but I didn't really understand the format. binwalk says the binary includes several images (understandably) and an android boot image. I assume that the first portion of the binary is a bit of fluff to get a small Linux kernel loading? But then I don't understand why an android boot image is needed. Can you shed some light on this? I'd really love to know which environment variables I need to modify to get a 'debug' CMDLINE in Sbl :)

For me it is quite a while a go that I worked on reverse engineering Sbl, but you can look at my annotated decompiled code in the ghidra project that is also in this repository (I named quite a lot of functions and variables based on their usage). This might give you some more insight in everything Sbl does. It will at least be a lot more helpful then a simple objdump. The android boot image you saw with binwalk is very likely just the ANDROID! magic string that every android boot image contains as the first eight bytes, which is embedded in Sbl as a constant variable which it itself uses to detect if a valid android boot image is present in the KERNEL or RECOVERY partition. (So no actual boot image should follow after it in Sbl.bin, but binwalk probably only looks at the first few bytes to determine if a binary file contains an embedded file.)

But to answer your question: Sbl takes a file called param.bin or param.blk (not sure anymore which of the two it was) from the param.lfs partition (you can extract the files from it (among which is the param.something file) with j4fs_extract, if you use it as follows:

python2.7 j4fs_extract/j4fs_extract.py ${PARAM_LFS_IMAGE} -p 2048 -b 131072

In this param.something file you should find a binary representation of the environment variables Sbl uses, which also contains the kernel command line, and if I remember correctly you can just edit the param.lfs image with a hex editor, find the kernel command line string and change the TTY device there.

mspitteler / espresso-sbl

Unclear about sd-card format #1