uart_payload_n7.bin

[jonasschwoebel]

Not exactly an issue but can you please tell me how "uart_payload_n7.bin" was created? Do you still have the Makefile?

We want to find an uart-a port on another Tegra3 device and want to use an infinite uart loop. Coding is easy but i have no idea how to compile it.

Thank you :)

[tofurky]

sorry, i did not include the make targets since it was modified in the fusee-gelee sub repo and i wanted to leave it untouched. and also i am lazy. maybe i can add one to payload/Makefile that does include ../fusee-launcher/Makefile.

but here you go (can apply the .patch below by cd fusee-launcher; patch -p1 < thePatchBelow.patch

diff -uNr fusee-launcher/Makefile fusee-launcher.new/Makefile
--- fusee-launcher/Makefile 2020-05-06 22:40:42.174488282 -0400
+++ fusee-launcher.new/Makefile 2020-10-09 14:00:14.745171322 -0400
@@ -18,12 +18,11 @@
    -Wall \
    -Wno-error=unused-function \
    -fomit-frame-pointer \
-   -g \
-   -Os
+   -O0

 LDFLAGS =

-all: intermezzo.bin dump-sbk-via-usb.bin
+all: intermezzo.bin dump-sbk-via-usb.bin uart_payload.bin

 ENTRY_POINT_ADDRESS := 0x4000A000

@@ -43,6 +42,12 @@
 dump-sbk-via-usb.o: dump-sbk-via-usb.S
    $(CC) $(CFLAGS) $(DEFINES) $< -c -o $@

+uart_payload.elf: uart_payload.o
+   $(LD) -T uart_payload.lds --defsym LOAD_ADDR=$(ENTRY_POINT_ADDRESS) $(LDFLAGS) $^ -o $@
+
+uart_payload.o: uart_payload.c
+   $(CC) $(CFLAGS) $(DEFINES) $< -c -o $@
+
 %.bin: %.elf
    $(OBJCOPY) -v -O binary $< $@

diff -uNr fusee-launcher/uart_payload.lds fusee-launcher.new/uart_payload.lds
--- fusee-launcher/uart_payload.lds 1969-12-31 19:00:00.000000000 -0500
+++ fusee-launcher.new/uart_payload.lds 2020-10-09 13:47:51.858444163 -0400
@@ -0,0 +1,21 @@
+OUTPUT_FORMAT("elf32-littlearm")
+OUTPUT_ARCH(arm)
+ENTRY(main)
+SECTIONS
+{
+   . = LOAD_ADDR;
+
+   .text : {
+       *(.text)
+   }
+
+   /* always end on a word boundary for our copy */
+   . = ALIGN(4);
+
+   /DISCARD/ : { *(.dynstr*) }
+   /DISCARD/ : { *(.dynamic*) }
+   /DISCARD/ : { *(.plt*) }
+   /DISCARD/ : { *(.interp*) }
+   /DISCARD/ : { *(.gnu*) }
+   /DISCARD/ : { *(.data*) }
+}

the -O0 isn't strictly necessary but it was helpful in debugging the produced .elf/.o and is what the .bin in this repo were built with.

change the #define UARTA (for n7) or #define UARTD (for ouya) in uart_payload.c as necessary, and then cp payload/uart_payload.c fusee-launcher, cd fusee-launcher, and make uart_payload.bin.

[jonasschwoebel]

Thank you. Just one more question. What is the default behaviour of n7 uart payload?

I guess from line 153/154: "Jump back into bootloader immediately after ipatches are applied to simulate coldboot as best we can." That the normal operation system should boot?

In my case this didnt happend with the n7 payload. Maybe because secureboot is "disabled" now windows bootmgr refuses to boot? Or does the payload wait until the uart data is send? Can it detect if anything is connected to RX/TX?

[pgwipeout]

Ah @CaptainStone47 I see you are trying to get a Windows RT tablet going. Which one are you doing?

[tofurky]

not clear on what you are trying to use this for.

this is intended to only be used via fusee-gelee on a device already booted into APX mode. once the payload runs, it will "reset" back into APX mode but with the security fuse disabled, allowing communication via the patched nvflash.

if you just want a uart function, check out bootloader/uart_print.c.

[tofurky]

btw, the security fuse is "disabled" only from the context of the APX/RCM itself. the miniloader that nvflash uploads, for example, checks the same fuse. that is why it also had to be patched.

if you are trying to bypass a fuse check in another piece of software (windows bootloader?), you would need to patch that bootloader as well.

to answer your last question, it doesn't matter if uart is actually connected. but if something else has already initialized uart before uart_print() first runs, it could possibly cause a system hang.

[jonasschwoebel]

@pgwipeout Surface RT. fyi: https://discord.gg/tAxvvVC

@tofurky I am trying to find a uart port. I dont know if there is any. But i guess if i have a piece of code that spams the uart port i can find it by probing some pads on the mainboard. Thats why i need an infinite uart loop. If the infinite loop works it should not reset back in APX mode if i understand you correctly(?).

The ACPI table DBG2 told me that UART-A should be available. sRT has ~50 unconnected pads on the mainboard. I guess there is a uart port and some disabled JTAG pads. GRUB 2.05 and UEFI Shell couldn't use any uart port. ??Maybe intialized and protected by winBootMgr??

I am not interested in the security fuses etc. I think best/easiest way is to use windows bootmgr with securebootDebug.efi/Goldenkey to load Grub or an EFI-Stub kernel.

I guess windows bootmgr doesnt care about fuses since it is an efi file which get the security stuff from uefi firmware. I dont think that they have different bootmgr's for different CPUs.

Thanks for your support :)

[tofurky]

just remove everything in main except for while(1) { uart_print("test"); }

if you can't find a schematic, you could make educated guess (unpopulated header) or just go from pin to pin with a logic analyzer.

[jonasschwoebel]

no schematic's available :( But the 2/4 pins groups look promising to me.

I came up with a similar code ;) but i wasn't able to build it since i missed --defsym LOAD_ADDR=$(ENTRY_POINT_ADDRESS)

I think now i have everything i need :) Will update this comment if i find anything interesting

[pgwipeout]

I can't believe I missed that, now I need to get another one to destroy.

[jonasschwoebel]

Took me 5mins to find UART-A. Thank you so much :)

[pgwipeout]

Going to publish your work?

[tofurky]

cool, please feel free to update your progress here or post a link.

[tofurky]

master has a Makefile now, see https://github.com/tofurky/tegra30_debrick/commit/a2f7390e2af29a2ce31f9efebbe9a22332693257

[jonasschwoebel]

As promised here's the update: J14: https://openrt.gitbook.io/open-surfacert/surface-rt/hardware/j14-oem-debug-connector UART-A: https://openrt.gitbook.io/open-surfacert/surface-rt/hardware/uart

Took a while to write it down since we needed a better platform to write all the things down. J14 and UART are almost complete. The rest is still a little messy. Just need to add the fusee gelee part. Will do this later today.

[tofurky]

@CaptainStone47 maybe you'll find this useful, if you have not yet seen it: https://github.com/NekomimiRouter/yahallo

[jonasschwoebel]

Hey,

I wanted to say thank you (again)

Your help started the whole Linux on Surface RT adventure. Right now we have a devicetree upstreamed to grate-driver/linux which already supports a lot of the installed hardware (touch/screen, typeCover, USB, SD, ...). More hardware support is currently WIP. We created a lot of documentation. We hope it will be helpful for other people who will try to port Linux to a new/unsupported device.