yashsingh1/xdaforums huggingface dataset:
[Hardware Hacking General] Dron_Gus:
hello

I'm looking for any information about the iROM bootloader of s5pv210 (similar to s5pc110). Currently I have a a PDA based on s5pv210. Initially, it started from built-in NAND memory (with old u-boot on it). However, I found all six OM signals and now I can switch the boot mode. My first task - to make the processor start from SD-card. However, I have not yet succeeded in doing so. I figured out the format of card and where should BL1 lie. Now I have two questions:

1) how to determine whether the secure boot mode used and whether or not my binary to be signed? As i understand, some CPU have zeroed eFUSE, so it can run unsigned binary. I have some signed binaries (from similar devices and demo-boards) that should only start unsigned binary. But i have no success with them.

2) What is the format of 16-byte header. As long as I understood the first 4 bytes is the size of the image, then 4 bytes of unknown purpose, then the 4-byte checksum (the byte sum of all binary), then another 4 bytes of unknown function. Maybe someone has more information?

Thank you and apologize for my english.

P.S. may be someone have tried to disassemble iROM binary to determine its logic?
[Hardware Hacking General] roeebloch:
same S5PC110 test B/D for 5 seconds

I have the same situation,

I didn't understand can this be solved without openning the device?

With DWN tool? and how?

Thanks,

R
[Hardware Hacking General] E:V:A:
+1 Close the thread! (It's long enough and have served its purpose.)
[Hardware Hacking General] jerdog:
Purpose served - thread closed after n00b questions derailing the thread's purposed.
[Hardware Hacking General] AdamOutler:
^^ Yes we've tried.

Thanks. No, You see, I've got a few i897 which is pretty much the same hardware and software, but they made the jtag connection about 1/5 the size of the i9000. The pins are .2mm wide (.4 pitch, dual-inline, 12 pins in 2.5mm space) and nearly impossible to solder by mere mortals. Compression connections are not available either. I'm betting that this lack of attention to detail represents a uselessness in that port all-together and there must be an easier-to-access method rather then traditional solder-on jtag. Seeing those jtag ports above made me rather over-joyous. I'll try to keep on track here.
[Hardware Hacking General] js22:
The FSA9480 has a couple more connections that we haven't discuussed here. There is an interrupt line, and also an i2c data bus.

Under normal linux kernel operation the interrupt is enabled. When the R value (and perhaps the level on the power pin? ) changes, the kernel gets an interrupt. It can then read the value of the resistor via i2c and decide what to do. For example, begin sending analog audio to the USB connector instead of the speaker or earphone (car dock, home dock).

I don't know anything about the SBL, but one obvious possibility is that it might just check the R value via i2c and branch to download mode if appropriate. That would be sensible as it is a one-time decision. Don't even need the interrupt.

I'm pretty sure that the iROM code ignores the interrupt and i2c lines. IIRC,the only interrupts are reset, USB and a timer. And we know it does check the OM5 pin, so I doubt it bothers setting up i2c.
[Hardware Hacking General] midas5:
I don't think the resistor value is read via i2c. There is the usb id pin there right on the fsa chip. Or does it read it via an internal i2c bus?
[Hardware Hacking General] midas5:
Another possible trigger for om5 might be a combination of resistors on both the usb id pin and the headphone socket. Also, reading the fsa driver code, it can also detect length of time a resistor is attached for as "short" "long" "very long".
[Hardware Hacking General] midas5:
The arm chip manual also lists other boot sources, one being SD/MMC via om1,2,3. Could we use that to boot via the external micro sd card?
[Hardware Hacking General] TheBeano:
We know that the SBL is reading the keys that are pressed and deciding to go into download or recovery mode from these boot logs so I think it's a good bet that the SBL reads the 301k resistor value via I2C.

I have tried a few things like RXD shorted to ground, pullup and pulldown on Vin, and various keys pressed with the 301K resistor but it still boots to download mode.
[Hardware Hacking General] TheBeano:
Yes, from the ROM boot mode disassembly it will try that if the primary bootloader fails to load (it actually tries that before UART/USB) but you can't force it to load from sdmmc without boot_mode set.
[Hardware Hacking General] midas5:
Are we able to read the OM register on a running system?

In this way, we could at least find out which external resistor value sets which OM bits.

We could then happily play with various inputs/resistors/shorts and see what affect this has on OM.

I can see from dmesg that various resistors are recognised on a running system.

Is there a viewmem location for reading the OM, if so, what is it?

We could then build a table of OM value and external stimulus to cause it.

For example,

OM=0x9, device=OnenandMux(Audi) (Normal Boot)

OM=0xd, device=SD/MMC

OM=0x28 or 0x29, device=UART, then USB, then OnenandMux(Audi)

All the effort in this thread has been to get to 0x28 or 0x29.

Getting to 0xd might be just as useful if SD/MMC refers to the external SD card slot on the I9000.
[Hardware Hacking General] androcheck:
Yes, as TheBeano posted already here.

./viewmem 0xe010e100 0x32 | busybox hexdump -C

The first byte displayed is the OM value, which normally is "09".

You can get the viewmem binary and source from here.
[Hardware Hacking General] AdamOutler:
How can we test the boot mode? I noticed when apply battery, then remove in certain combinations, it puts it into a continuous boot "primitive booloader" no secondary. It may be trying to boot the phone but cannot find a USB drive? I don't know... I keep seeing the first part of the Samsung Primitive Bootloader. It is trying to boot but it won't. This is the same LED pattern on my TX/RX I was seeing earlier which was dismissed as static. It only occurs with the battery removed and USB power hooked up.
[Hardware Hacking General] midas5:
Thank you.

I have tried it, and it does not seem to change from the value of 0x09 no matter what I try.

Has anyone managed to get the OM value to change to anything apart from 0x09?
[Hardware Hacking General] midas5:
This might be what we are looking for.

If the phone is powered via a cable, and has no battery. This might be the boot mode we are looking for. What resistor value are you using?
[Hardware Hacking General] AdamOutler:
150k or grounded produces the same output. Boot the phone, remove the battery during boot and sometimes it goes into this cyclic boot cycle. ..

-----------------------------------------------------------
Samsung Primitive Bootloader (PBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010
-----------------------------------------------------------

+n1stVPN 2688
+nPgsPerBlk 64
+n1stVPN 3008
+nPgsPerBlk 64
PBL found bootable SBL: Partition(4).
1
-----------------------------------------------------------
Samsung Primitive Bootloader (PBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010
-----------------------------------------------------------

+n1stVPN 2688
+nPgsPerBlk 64
+n1stVPN 3008
+nPgsPerBlk 64
PBL found bootable SBL: Partition(4).
1
-----------------------------------------------------------
Samsung Primitive Bootloader (PBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010
-----------------------------------------------------------

It does not set an OM but just resets. This could be either an unqualified boot, or it could be lack of power... I will attempt to feed power from a 1A source.
[Hardware Hacking General] AdamOutler:
^^No dice... same bootloop. it may be something else though.

Here is the datasheet on the FSA9280A which TheBeeno posted earler

http://www.fairchildsemi.com/ds/FS/FSA9280A.pdf

I was looking at this and wondering if it would be possible to communicate with the I2C. Maybe 0x9 is the fixed boot address on the i2c bus? I dunno. Think I'll play with it. Anyone seen any documentation about SDA or SDC on this? (Serial data or serial data clock)
[Hardware Hacking General] AdamOutler:
I would like to say that I've thoroughly tested the following.... No new information here.

RID_USB_OTG_MODE,	/* 0 0 0 0 0	GND	USB OTG Mode */
RID_FM_BOOT_OFF_USB,	/* 1 1 0 0 0	255K	Factory Mode Boot OFF-USB */
RID_FM_BOOT_ON_USB,	/* 1 1 0 0 1	301K	Factory Mode Boot ON-USB */
RID_FM_BOOT_OFF_UART,	/* 1 1 1 0 0	523K	Factory Mode Boot OFF-UART */
RID_FM_BOOT_ON_UART,	/* 1 1 1 0 1	619K	Factory Mode Boot ON-UART */

I've found the following of the above to to be the only two which are needed

RID_UART_CABLE,	/* 1 0 1 1 0	150K	UART Cable */
RID_FM_BOOT_ON_USB,	/* 1 1 0 0 1	301K	Factory Mode Boot ON-USB */

150K puts the phone into UART mode and will release serial data over D+ and D-

301K puts the phone into download mode and should be included on any basic jig.

I would like to focus other's attentions on the following:

RID_TTY_CONVERTER,	/* 1 0 1 0 1	121K	TTY Converter */
RID_CEA936A_TY_1,	/* 1 0 1 1 1	200K	CEA936A Type-1 Charger(1) */
RID_CEA936A_TY_2,	/* 1 1 0 1 1	442K	CEA936A Type-2 Charger(1) */
RID_PHONE_PWD_DEV,	/* 1 0 1 0 0	102K	Phone Powered Device */

TTYs are used for printing STDOUT on Linux based system. This is a Linux based system. These are the most interesting ones left. TTYs are typewriter devices. They tell you stuff and sometimes let you tell the computer stuff.

CEA-936-A is a specification for communication while charging

Phone Powered devices may be able to load the phone with data or even boot it... like a memory stick

If you have a device which handles SDA and SLC, then you should try to communicate with that method as well as serial. The chip we are talking to has a I2C output on it. If you look at the datasheet posted above, you'll see that there are several modes.. We've explored all of them except "Factory Test". I believe factory test is the I2C output.
[Hardware Hacking General] midas5:
I2C is a very simple protocol. In order to see if you are seeing I2C on the port, both d+ and d- should be connected to an rx on your computer and should be changing. I2C is a one wire, multi endpoint, bus.
[Hardware Hacking General] ntfreak:
I2C has two wires - clock and data and both requiring pullup to Vdd.
[Hardware Hacking General] TheBeano:
The 619K turns the serial output on earlier, so you get the full bootlog. With 150K and 80K it only turns the serial output on at some point in the SBL. If you look down your second log you will see the same output from the SBL as your first log.

It could be useful to work out how it does that, as it must be reading the FSA state in the PBL somewhere to know that it has to switch serial output on. I've disassembled a bit of the PBL but it's much harder than the ROM code.
[Hardware Hacking General] AdamOutler:
Do we have any idea what the IBL does? What is it responsible for?

I'm sure that the jig is interperated by the U301 mux and the proper IO is applied right at the USB connection. The question is what can we do with ONLY the IBL in tact.

Eventually I'm going to use odin to flash a bad PIT and nothing else on my phone to test.... basically reformat the thing with no primative or secondary bootloader to use. I need more information before I do something like that.
[Hardware Hacking General] TheBeano:
The IBL is part of the same partition and binary (boot.bin) as the PBL. According to the CPU manual (p464) the first bootloader is supposed to be platform-independent code that jumps through some security hoops and loads the second bootloader, which is platform-dependent. Samsung have called the first bootloader "IBL+PBL", so they seem to have stuck in an extra "Initial" stage. But if the PBL partition is nuked then the IBL will be too.
[Hardware Hacking General] AdamOutler:
^^ Thanks.... So what do we have when the primary bootloader is destroyed?

Here is a general purpose video describing what we have so far.

[youtube]GGrFAU1sig8[/youtube]
[Hardware Hacking General] TheBeano:
If the ROM can't load the PBL because the partition isn't there or there's a checksum error in it, it will try to load from SDMMC, then UART, then USB. This is the code starting at 5AD0 in the boot rom. If none of this works it gives up and locks up.

My guess is that this is what's happening for people who have a "black-screen" brick. There is some code in the ROM (at offset 8164) to display an error message on a screen as well as the UART when this happens, but I think that will only work on a S5PC110 development board, not the SGS. That's why it would be interesting to look at the serial output of a bricked phone.

You could trigger this by destroying or corrupting the IBL+PBL partition, but you would have to be real confident that you could recover using ROM download mode, as Odin download mode (which is part of the SBL) would be dead. If you know the SBL partition is still intact then you should be able to just send a copy of boot.bin through the UART using the ROM download protocol. This copy would launch the SBL from NAND, then you could get back to Odin download mode and write a new PBL from there. But if the SBL is destroyed too you need to be able to load an SBL through the UART as well, and I doubt that the Samsung PBL has the code for this.
[Hardware Hacking General] AdamOutler:
Ill test it. I have a spare phone. What should be on the mmc? I have an two 8 gig sdcards. How should I format it? What should i put on it? Any precautions I should take to reduce risk?

I have several .4mm pitch connectors for jtag, but I have no jtag code for my arduono. I don't know the protocol well enough to write a jtag protocol interface. I have not done much searching but im pretty sure it is out there. So jtag is my backup.

I contacted connexion and asked if he would be willing to help me if I get in too far over my head. Like I said.. this is a dev phone... its not going to put me out of commission, but it is an expensive piece of hardware.

What should I do before I flash a Justin Beiber mp3 as a primary bootloader and a lolcat jpg as a secondary?
[Hardware Hacking General] midas5:
Hi,

I am interested in what the phone was doing while without the battery plugged in, but with USB power connected.

Now, when without the battery, this might provide us with this "boot-mode".

The device just boots in a loop without the battery.

Looking at a USB to Serial board specs, I noticed some interesting options.

1) Change the polarity of signals.

The IROM might be changing the polarity of the data transmitted which is why we cannot see anything useful.

I think that if we connected the TX from the phone to a GPIO input on the test board you have (or a storage oscilloscope), and then measure each transition of the line from 0 to 1 etc, we could graph it and find out what it looks like. We could then get a better idea as to what type of signal is being output between the normal PBL boot messages.

Some sort of output like:

1 for X clock ticks.

0 for Y clock ticks.

1 for Z clock ticks etc.

We could also use this to diagnose what baud rate it is at.

Unfortunately, I do not have any test board like you, so maybe you could try the measurements.
[Hardware Hacking General] TheBeano:
Well you're braver than I am. :) I would concentrate on the UART route as we aren't even sure that the Galaxy S external MMC is the one that the ROM looks at. According to my disassembly it is SDMMC2 on the CPU, but I don't know if that matches the Galaxy S external card, or whether it would be able to read an 8GB card, etc. etc. There was a "moviNAND fusing tool" linked to earlier in the thread if you still want to try, which should make a card in the right format.

I would definitely only trash the PBL to start with, preferably just by writing a couple of bytes to a string in it from a C program, which should invalidate the checksum. That way you only have to get the PBL loaded to recover, as loading the SBL into RAM is trickier.

Also you would need a program to upload through the serial port using the ROM protocol that I documented earlier, via an Arduino, could be tricky! I could probably write it but not till next weekend.
[Hardware Hacking General] midas5:
Maybe useful.

As well as a serial rate of 115200 that we are all seeing, the UART on this device can also work at 921600.

I found this rate by doing:

*#197328640#

6 - common

4 - diag config

Does anyone have a serial port that can work at 921600. Maybe the IROM is using this rate.

Is it possible from the IROM disassembly to discover the rate used for the serial port while in IROM?
[Hardware Hacking General] AdamOutler:
^^That's likely for the modem device which is present after boot is complete.

I did notice that it is transmitting when the UART device does not exist on the phone. Being that the UART device must exist on the phone in order to make UART work, the phone must be loading it's /dev filesystem quite early in it's boot, before primary bootloader.

Unless I'm wrong and you do not need the UART device on the filesystem to communicate and I was just experiencing comms errors earlier.

Regardless, I will try deleting my UART device and inverting the binary transmitted.

Alright. that protocol sounded easy enough... Could you give me a bit more detail as to how to initiate this protocol? is that 0xAA the random single byte of garbage I see when the phone first turns on? You seemed to pull the protocol out of nowhere. I'd like to know what comes before that protocol and what comes after... You were very light on the details.

I'll definately try the MoviNAND tool first.
[Hardware Hacking General] AdamOutler:
Yes I do... Apparently the 16mhz clock can handle up to 2,000,000bps. I'll try that tonight when I get home. From what some people say, the UART should be able to handle everything without directly communicating with IROM.. What is the IROM anyways?

when the phone is first plugged in, and battery is removed, it sends out a 1 second transmission.... it may be static, it may be a pull-up resistor during U301's self test.... Either way, the phone 1/2 illuminates my TX LED when it is plugged in, suggesting 2.5V or 1/2duty cycle. it's worth testing
[Hardware Hacking General] midas5:
Hi,

Fun with resistors ...

I have taken the resistor values contained in the source code.

I then tried to graph them in order to reach a straight line.

Summary, using the current list of resistors does not create a straight line.

What I tried was this:

Assume the component inside the U301 is a fixed resistor.

Call the internal resistor R1, and the external ID resistor R2.

Voltage detected by the ADC is R1/(R1+R2).

Conclusion:

There are un-documented resistor values.

Previous threads have already suggested as much with 1k and 330R resistors doing something.

My graphing suggests there might be extra values between 4k and 300K, and also extra values above 619K. Extra values should be between 121k and 200k because the graph looks like values are missing there.

(Extra values in addition to the values already in the table.)
[Hardware Hacking General] TheBeano:
Yes the IROM code is talking directly to the UART hardware so it doesn't need or use Linux devices.

If it was downloading from the UART because the BOOT_MODE bit was set it would start sending 0xAA immediately, but if it's downloading because the NAND is corrupt you should see a couple of text error messages on the UART first, probably "Nand check sum error" and "SD Init Error" (if no SD card is loaded), then 0xAA.

After the 0xbb0xbb0xbb at the end it chains to whatever it managed to load and you should see the serial output from that. If it fails there should be a text error message on the serial port.

But, to complicate things still further, the (approx) 87KB that the ROM loads this way is not big enough for Samsung's 256KB boot.bin, so presumably this is where the IBL+PBL comes in, the IBL has to load the rest of the PBL to main RAM, because the ROM doesn't load it all and it wouldn't fit into the 128KB of IRAM anyway. So really we have to dig into the IBL code to work out where it loads to, and possibly mod it to load over serial.
[Hardware Hacking General] midas5:
The IBL in boot.bin is 0x4000 or 16k long.

The PBL runs from offset 0x4000 in boot.bin onwards.

I know this because when I flash boot.bin, nothing changes between 0 and 0x3ffff, only bytes from 0x4000 onwards change.

In any case, I think we are getting ahead of ourselves. We need to see the 0xAA on the UART first before we can even try to load our own boot loader.

Hopefully, we might see that at a different baud rate.

Which baud rates have already been tested?

I think 921600 is worth a shot.
[Hardware Hacking General] AdamOutler:
Please post the graph. I'd like to see that. Does everything look linear? is it possible to extrapolate exact values?

Great information...

this xAA.... would it show up as a funny 1/2hex 1/2japaneese looking character directly before the primary bootloader?

this '1' in the log was actually a funny looking character

1
-----------------------------------------------------------
Samsung Primitive Bootloader (PBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010
-----------------------------------------------------------

+n1stVPN 2688
+nPgsPerBlk 64
+n1stVPN 3008
+nPgsPerBlk 64
PBL found bootable SBL: Partition(4).

Set cpu clk. from 400MHz to 800MHz.
OM=0x9, device=OnenandMux(Audi)
IROM e-fused - Non Secure Boot Version.

when i copied and pasted, it turned into a 1.

This can be observed when you plug the phone into a 150k UART cable, and then disconnect the battery.... At this point, the phone goes into cyclic booting.
[Hardware Hacking General] AdamOutler:
judging by the pattern we have seen thus far...

150k = uart

301k = download

619k = factory mode uart

I'd expect to see something at the 75k and 12-1300k ranges. However, once you start getting into megohms, that could cause false values with a bit of moisture and would cause eratic readings. So, I'm likely to put my finger on 75ish Kohms.
[Hardware Hacking General] js22:
wow, missed a couple o days and there is a lot here.

The idea of running without a battery is nice. Very well *could* have been the answer, but I hooked up a +5 V to the USB VCC pin, pulled my battery and don't see any change. It does, however, make testing _much_ faster. No need to wait for the kernel to boot before hitting power down from the menu.

Anyway, I ran at a bunch of different baud rates, and tried lots of button combinations, but don't see anything different. At 115200 baud, there is some arbitrary data, then 0x10, 0x31, then the PBL output. The arbitrary data changes from one repetition to the next at the same setting, so I'm assuming its just start-up glitches.

[EDIT : BTW, the 0x31 is an ASCII '1' character]

About the names IBL, iROM, etc. I used to think IBL (initial boot loader) was synonymous with the code running from the internal ROM memory (iROM, in Samsung's terminology). I was confused when I saw the contents of a flash partition described as "IBL+PBL". Sounds like Sammy wasn't content with just 3 bootloaders, so they split the PBL into two parts, and couldn't think of a new name for the first part. To avoid confusion (???) I guess we should keep referring to the non-eraseable code inside the CPU as the iROM code or iROM bootloader.

Adam, did you say that you had the Tx and Rx lines of your Arduino connected to the phone's USB port, but not the Ground ? You really do need the ground connected (esp. on a battery-powered device) or you will run into noise problems. That could explain some of what you were seeing.