yashsingh1/xdaforums huggingface dataset:
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4782500]pbarrette[/MENTION], thanks, that's interesting.

Concerning kernel references - there should not (normally) be a need to decompile it, because source should be available due to GPL (at least for the kernel image binary). So a 'git grep oemandroidboot.babe' shows this (used 47.1.A.8.49 source):

drivers/leds/leds-qpnp.c:__setup("oemandroidboot.babe137e=", rgb_current_setup);
drivers/soc/qcom/console_setup.c:early_param("oemandroidboot.babe09a9", setup_serial_console);

The babe09a9 enables serial console during early setup of kernel boot - that may actually be useful if we were able to connect serial cable to right pins on the board (if those pins were accessible).

The babe137e seems to setup an index to a table for setup of LED current - maybe we could change boot up color with it? Or it might define some limits for the LED current control, did not check it too deep...

Being able to influence /sys/fs/selinux/checkreqprot seems tempting, but most likely any value is not significant enough to make a big difference (the description in security/selinux/Kconfig of it is a bit confusing).

The duplication in BA-BE construct - I have no idea - it might be there as an magic or an alignment?

I did not have time to go into 0x84F deeper unfortunately, but your findings confirm, that reversing it's parsing may be useful.

Currently I am struggling with another problem: I am testing something with android boot, but for unknown reason, the boot somehow crashes (or is forced to reboot) after few seconds on that static white background SONY logo and ends in fastboot if it had been connected on usb.

Unfortunately there is nothing under /sys/fs/pstore/, so I cannot check for a kernel oops dmesg log there.

It rather seems that the system (or init) forced reboot into fastboot, because the bootloader log from previous boot in 0x803 ta unit says this:

Vendor(0x00000003)->Sony(0x77665500)
2, 2, Setting existing handle
Startup flags: [USB INSERTED] [HARD RESET]
Warmboot reason: [FASTBOOT]
[ERROR @ sony_boot_config_parser.c:732]:
None or incorrect vbus_pulse configuration!
2, 2, Reset keys pressed but released before shutdown timer expired. Booting normally.
Service mode detected: [NONE]
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] pbarrette:
[MENTION=4418980]j4nn[/MENTION]

That "vbus_pulse" message is almost certainly related to the parsing of the 0x84F TA unit in the ABL.

I'm sure you saw the ABL references for setup of VBUS_PULSE in the decomp of the boot config parser.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4782500]pbarrette[/MENTION], yes, all the logs are from ABL. That vbus pulse message - it seems to me that is just signalling that the phone is connected on usb. What seems to be important is that it looks like not a crash, rather as a fw intended reboot into fastboot: that 'Sony(0x77665500)' magic and the 'Warmboot reason: [FASTBOOT]'.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4782500]pbarrette[/MENTION], looking for something else in 'init' binary, I have observed the oemandroidboot.babe09a9 parsing too.

You are probably right about the 'checkreqprot', but could it be, that only a bit flag from that TA unit sets it (the 0x04 bit mask)?

While other bits could be used for something else?

Particularly right bellow finding the babe string in command line, there is a call to write something into

"%s/enforce", where it seems the ptr used with %s is set to "/sys/fs/selinux", so there is most likely setup of

/sys/fs/selinux/enforce

that would be very interesting, if it could be influenced by a TA unit. But (with only a quick check) I did not find a code path influencing it from that babe command line string.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] pbarrette:
[MENTION=4418980]j4nn[/MENTION]

Yes, I don't know how I missed that. There is an almost direct code path from babe09a9 to "enforce".

It looks like a read of babe09a9 is followed followed by a pair of comparisons to 0x1. That is then followed in most code paths by a call to a sub_ which opens a read/write file handle to /sys/fs/selinux/enforce. Finally, we hit the call to write checkreqprot.

It almost looks like the value at 0x9A9 is being used to set both "enforce" and "checkreqprot", but being toggled for "enforce" and used as is for "checkreqprot".

That would make sense, since "enforce=0" means don't enforce and "checkreqprot=1" means check protection is requested by the application instead of being enforced by the kernel.

On Edit:

I wonder about that 0x84F formatting.

Is it possible that the left hand is used to determine the name of the config option and the right hand is used to determine the TA unit that is actually read?

A9 09 BE BA A9 09 00 00

If so, and if that actually disables SELinux, that would allow us to use a writable TA value to direct the read to a TA unit of our choice.

If it's a toggle, we could write something like the following in 0x8F4:

A9 09 BE BA A1 08 00 00

0x8A1 on my device is a 1 byte TA unit with a value of 0x01.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
Probably you don't need to connect directly to the mainboard(I also tried to ask to SONY if they could give me some pinout like the XA2,but the linked me the page of openDevices), probably the Serial port and possibly other interfaces are accessible through Type-C connector;

From Wikipedia:

Debug Accessory Mode
The external device test system signals to the target system to enter debug accessory mode via CC1 and CC2 both being pulled down with an Rn resistor value or pulled up as Rp resistor value from the test plug (Rp and Rn specified in Type-C spec).

After entering debug accessory mode, optional orientation detection via the CC1 and CC2 is done via setting CC1 as a pullup of Rd resistance and CC2 pulled to ground via Ra resistance (From the test system type-c plug). While optional, orientation detection is required if USB Power Delivery communication is to remain functional.

In this mode, all digital circuits are disconnected from the connector, and 14 underlined pins can be used to expose debug related signals (e.g. JTAG interface). USB IF requires for certification that security and privacy consideration and precaution has been taken and that the user has actually requested that debug test mode be performed.

GND	TX1+	TX1−	VBUS	CC1	D+	D−	SBU1	VBUS	RX2−	RX2+	GND
GND	RX1+	RX1−	VBUS	SBU2	D−	D+	CC2	VBUS	TX2−	TX2+	GND
If a reversible Type-C cable is required but Power Delivery support is not, the test plug will need to be arranged as below, with CC1 and CC2 both being pulled down with an Rn resistor value or pulled up as Rp resistor value from the test plug:

GND	TS1	TS2	VBUS	CC1	TS6	TS7	TS5	VBUS	TS4	TS3	GND
GND	TS3	TS4	VBUS	TS5	TS7	TS6	CC2	VBUS	TS2	TS1	GND
This mirroring of test signals will only provide 7 test signals for debug usage instead of 14, but with the benefit of minimizing extra parts count for orientation detection.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4782500]pbarrette[/MENTION], it seems selinux-enforce is not depending on that babe construct - there seems to be read of that sysfs var in the code before parsing the cmdline babe string, changing the enforce flag temporarily and after set of 'checkreqprot' probably setting it back unfortunately.

[MENTION=7543898]Blu-eyes[/MENTION], thank you for that info about the debug/serial connection - if that really can work like that, it would be great. I cannot imagine that even jtag could be supported. But at least serial console would be just great.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=3816568]Myself5[/MENTION], just wondering, did you have the debug cable as described by [MENTION=7543898]Blu-eyes[/MENTION] in post#1106?

As we have found out with [MENTION=4782500]pbarrette[/MENTION], serial console is disabled by default in yoshino fw kernels, but it may be enabled possibly by changing some TA units or simply by patching the defaults in the built kernel if working with unlocked device.

By a chance you already having the debug usb cable, could you try to patch

drivers/soc/qcom/console_setup.c:early_param("oemandroidboot.babe09a9", setup_serial_console);

in a kernel to check if serial console could be working over that special usb cable as described above?

Thank you.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Myself5:
as far as I know serial access is only possible via the UART pins on the mainboard after enabling UART in the defconfig and by adding a cmdline parameter (would need to look that up if needed). However, I only had access to an UARTed Xperia XZ Premium through [MENTION=359497]jerpelea[/MENTION], I don't have one myself.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
You are right,the XZ1 doesn't support Debug Accessory Mode, today I tried to build that cable,I opened a spare type C cable and as USB C spec (Release 1.3 July 14, 2017) I added a resistor of value Rd(5.1K +/- 10%) between CC1 and gnd and CC2 and gnd; and probed all pin;I found that almost all pins are left probably in Hi-Z state,(they are pulled high by the weak 100k resistor of my logic analizer ) , except one/two;that are pulled low for some time after the vibration and then also this pin are put in Hi-Z state, also the VBUS is disabled, the only thing that I got is a "white Triangle with a wrench and a screewdriver" :confused: on a couple of boot;
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=7543898]Blu-eyes[/MENTION], did you test with a patched kernel where serial console is enabled by default with 'debug' instead of 'quiet' boot log?

I cannot judge measurements results, but I can imagine there may be nothing on an uart maybe except txd if it is not used.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=7543898]Blu-eyes[/MENTION], do you mean that the bootlog has been obtained from serial console from from XZ2 with the described usb C debug cable?

Such bootloader log can be obtained by reading 0x802 TA unit after boot (or from shifted to 0x803 with next boot) - just wanted to confirm, that it has been obtained from that uart and not from TA partition.

There also may be some TA unit to actually force/enable bootloader logging to that uart.

Also ABL contains some detection for "VBUS pulse" whatever that means, but seems to be related to usb cable connection.

If you like, I can build a test kernel for you, just let me know which fw version.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] maverick6664:
Maybe a lame question. I'm a newbie about newflasher. I usually use linux. newflasher always scolds me "No usb device with vid:0x0fce pid:0xb00b !"

So I want to use flashtool which I get used to, but it cannot handle .rar file.

Can I use flashtool by extracting the whole .rar file and make a zip and rename the extension to ftf?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=8489563]maverick6664[/MENTION], see flash mode here - hold Vol- while connecting powered off phone to usb cable. Newflasher would work then, just extract fw to see .sin files in the same dir as newflasher.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
This log has been extracted from uart but I don't know if, by USB C cable or by test point(here the source.

https://talk.sonymobile.com/t5/Kern...ter-bootloader-EFI-UdonStop-Stop/td-p/1373499 )

I'll try soon to apply some power to VBUS.

Can you tell me where the ABL check for "VBUS pulse"

I'm still on locked bootloader, for this reason, I hoped to view such bootloader messages.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=7543898]Blu-eyes[/MENTION], there are messages like

VBUS not detected

None or incorrect vbus_pulse configuration!

- see the function at 0x26484 address of the abl.pe I've posted.

I am not sure what they mean by "vbus_pulse configuration" - they allocate some array for it apparently: "Failed to allocate VBUS pulse array!".

But it seems that the vbus pulse configuration is also specified in the discussed bootconfig 0x84f TA unit - it seems to get parsed in the big bootconfig parser function which starts at 0x26DD0 address.

You've mentioned some strange screens when testing the cable with your locked phone?

Can you take a picture - has it been before the SONY logo on the white background or after it during boot?

Strangely I cannot find a picture that would fit that description in xbl bootloader.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
I also wondered if that vbus thing is some special cable - it may be - but similarly I've thought that "Sony Service Mode" is something special. But it seems that the service mode is just the flash mode green led light used with newflasher flashing and vbus is passed by ordinary usb cable connection:

UsbConfigPortsQueryConnectionChange: USB Type-C Device Mode(UFP mode)
cc_out_sts 0x1 dfp_curr_adv 0x3 ufp_conn_type 0x7 vbus_sts 0x1 vbus_err_sts 0x0 debounce_done_sts 0x1 vconn_oc_sts 0x0 ccout_out_hiz_sts 0x1
HandlePortPartnerXtach: Cable Attach
...
Vendor(0x00000000)->Sony(0x00000000)
2, 2, Setting existing handle
Startup flags: [USB INSERTED]
Warmboot reason: [COLDBOOT]
[ERROR @ sony_boot_config_parser.c:732]:
None or incorrect vbus_pulse configuration!
2, 2, FactoryMode is set
2, Service mode detected: [SONY - USB]
[ERROR @ ta_interface.c:289]:
Unable to delete TA unit 2301
Collect command line additions
Obtain backlight config
Verify Reset FRP and OEM unlock flag Request
Booting Into Xperia Service
...

It ended with that idVendor=0fce, idProduct=b00b usb device with working newflasher.

Please note, in the log above, I've also tested yet another thing: "FactoryMode is set".

This makes the phone to always boot into flash mode, without any keys combo.

It can be enabled by setting 0x07D2 TA unit to 0x01.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
I'll look in these funtion

I got this image two times, one after the SONY logo for about 10/20 sec and then the boot has continued normally, showing up the boot animation etc..

The second one happened when my phone full discharged (between test) and I connected to the charger, this time this appeared when I connected the USB cable and disappeared only when I remove the USB cable, the strange thing is that after disconnecting the cable the logo disappeared and for around 5 sec, it believed that was charging showing the charging battery animation.

I'm on 47.2.A.10.80
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
But this is interesting.

Right next to "[SONY - USB]" string that is logged for ordinary usb when entering flash mode, there is "[SONY - UART]" string - maybe that one is used under special condition?

See the main function for xboot_make_decisions starting at 0x025B84 - it's the switch case 1.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=7543898]Blu-eyes[/MENTION], concerning the triangle icon with screwdriver - I've found it.

It seems that the phone has been doing some filesystem check/repairs, as the filename suggests: fsckwait.png.

(from xz1c-pie-10.80/system/etc/res/images/bootstrap/)
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
Interesting, but I think that an fsck during charging is quite strange, but I can be wrong
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=7543898]Blu-eyes[/MENTION], I would say quite opposite, the charging mode - entered from powered off phone by connecting changer, booting only to the charging animation - it's very good possibility to do filesystem checks/repair.

In the charging mode, Android is only half booted, only basic services are started, most likely there are no processes that would require writing to data or cache partitions. Most likely only such writeable partitions may need some checks/repairs eventually.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] maverick6664:
Thank you!! In the case of flashtool, while holding volume-, connect the phone. So I didn't notice that way!!
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
As discussed in previous posts, the TA unit 0x09a9 converted to babe09a9 kernel command line option seems to enable serial console in kernel early setup. Checking the drivers/soc/qcom/console_setup.c source leads to serial@0c1b0000 device tree object, which is defined in msm8998-yoshino-common.dtsi along with /* BLSP2 UART2 */ comment. The msm8998.dtsi names it as uartblsp2dm1 with .compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm". That seems to be similar as the xz2 case linked by [MENTION=7543898]Blu-eyes[/MENTION] - there is 'msm_serial_dm' string mentioned as a command line option there. It seems to be by default enabled in device tree, but unless the TA unit enables it as kernel console, it get's disabled in device three in that console_setup on early boot phase.

The driver for that uart is drivers/tty/serial/msm_serial.c and it is enabled by default in sony stock kernel, including pie 10.80 fw:

CONFIG_SERIAL_MSM_CONSOLE=y

That may mean that the console can be enabled for stock kernel boot log via TA 0x09a9 unit:

/*

* The S1 Boot configuration TA unit can specify that the serial console

* enable flag will be passed as Kernel boot arg with tag babe09A9.

*/

early_param("oemandroidboot.babe09a9", setup_serial_console);

The 0x09a9 TA unit contains 0x00 by default. We may test to set it to 0x01 to see if kernel would output bootlog to the uart, by flashing following .ta as the only file with newflasher:

//===========================================================
// Yoshino
// Product: Lilac
// Specification document: 8/159 35-LXE 108 010, Rev PA13
// Format:
// [TAPartition<HEX8>]{1}
// [UnitID<HEX32> UnitSize<HEX16> Data<HEX8>{UnitSize}]{n}
//===========================================================
02

000009A9 0001 01

and to revert it back to zero after done with testing:

02

000009A9 0001 00

That unit should be freely changeable with newflasher, so it may be tested even with locked bootloader - not asking you to do so, just saying my opinion - I believe I can manage even without the serial console, by a kernel patch, that forces panic with a warmboot instead of reboot.

But it would still be awesome if serial console could be enabled just with special usb cable.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
Just tested the above, with following results:

-Shutting Down UEFI Boot Services: 3471 ms
-EFI_SobaStop Stop DebugPort for anti-corroding
+Shutting Down UEFI Boot Services: 3449 ms

^^ note the missing line about stopping the debug port when compared the default bootloader log with log when the TA unit had been set - in case of enabled in the TA, the debug port does not get stopped at the end of bootloader log.

Relevant differences in kernel bootlog:

-Kernel command line: ... oemandroidboot.babe09a9=00 ...
+Kernel command line: ... oemandroidboot.babe09a9=01 ...

-disabling /soc/serial@0c1b0000 node
+Adding ttyMSM0 as preferred console

-console [pstore0] enabled
+console [pstore-1] enabled

+msm_serial c1b0000.serial: msm_serial: detected port #0
+msm_serial c1b0000.serial: uartclk = 0
+c1b0000.serial: ttyMSM0 at MMIO 0xc1b0000 (irq = 34, base_baud = 0) is a MSM
+msm_serial: console setup on port #0
+IPC_RTR: msm_ipc_router_smd_driver_register Already driver registered IPCRTR
+IPC_RTR: msm_ipc_router_smd_driver_register Already driver registered IPCRTR
+console [ttyMSM0] enabled

-c171000.uart: ttyHS0 at MMIO 0xc171000 (irq = 364, base_baud = 460800) is a MSM HS UART
+c171000.uart: ttyHS0 at MMIO 0xc171000 (irq = 365, base_baud = 460800) is a MSM HS UART

Most likely the not working serial console in XZ2 case linked above could have been caused by not set of the 0x9a9 TA unit too.

Tested also flashing the .ta with the zero value, it went ok as expected.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Hey, good progress!
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
I tried to solder all wire to the type C connector for further test, I ended with only one side(top) properly wired, from my test I discovered that Connecting a USB type C with CC1 and CC2 grounded via a 5.1K resistor(DAM Mode):

I need to press longer for boot starting, and sometimes it refuses to boot, and I need to disconnect This cable

Applying 5V to VBUS, cause the phone to output reset message(D+ and D- Held low for 10ms, repeatedly) over USB(D+/D-), even without powering on the phone;

Shorting TX1+ to GND, Cause the phone to never boot completely, it Hang on Sony Logo and probably the WatchDog Timer reset the phone

Connecting a resistor to 2 pins (I don't remember which) causes the phone to boot immediately after connecting the connector

After Connecting the "cable", also with the phone turned off, a (presumably ) clock of 49.64Hz(around 3% duty cycle) appear on a pin, when the phone started completely, the pattern and the frequency change (around 16Hz);

Some data appear on some pin, only during the bootloader stage, but not hold any valid serial communication

For the last two points, I will Investigate further, to discover if these are some useful data, or are only USB "discovery mode" packet.

for the VBUS pulses, It could be probably a pattern applied to Vbus, to enable some feature, but I have no idea if this is possible.

In the next day, I'll go to the local shop and I'll search for a Type C to Type C, so I can "sacrifice" it for further test, on all the 14 pins exposed by Type C
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=7543898]Blu-eyes[/MENTION], that is good testing, thank you. Wish you a good luck, to eventually find a working wiring.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=7543898]Blu-eyes[/MENTION], you may use attached patch for newflasher in order to get feedback with your serial/debug cable testing - I've modified the optional ta dump step with dumping just the units containing bootloader logs in raw (readable as a txt file) form.

If you go straight into flash mode (holding Vol- while connecting the cable), use the newflasher in empty directory and select 'y' for the optional ta dump step, you will get 0x802, 0x803, 0x804, 0x808, 0x809, 0x80a, 0x80b, 0x80c, 0x80d, 0x80e units .txt files with their content - bootloader logs.

They shift with each boot, the very recent (the one with which you entered flash mode) is in 0x802. Previous boot has been shifted to 0x803 and so on.

You may test just using flash mode, because even XFL kernel supports the serial console (if enabled in 0x09a9 ta unit).

This way you can recognize (even with a locked phone), if Sony Service Mode (aka flash mode, green led) recognized the cable as "[SONY - UART]" or as a normal usb cable, logged as "[SONY - USB]" - see the post#1120 with details from ABL.

Possibly you can also get feedback for VBUS pulse trials this way.

Please let me know, if you need me to build an executable.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
I tried to build with the applied patch, but executing it give me:

--------------------------------------------------------
newflasher v18 by Munjeni @ 2017/2019
--------------------------------------------------------

Determining available free space:

Available space to caller = 14630 MB
Total space on current drive = 60347 MB
Free space on drive = 17718 MB
found device with vid:0x0fce pid:0xb00b.

Optional step! Type 'y' and press ENTER if you want dump trim area, or type 'n' and press ENTER to skip.
Do in mind this doesn't dump drm key since sake authentifiction is need for that!
y
- Writing log to tadump.log
- Writing trim area dump to 02.tadump
Segmentation Fault

All the file created are empty

Edit:

I found that the problem was the -O2 flags, (I'm using gcc 9.2.1 on debian)