Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nothing appears on the UART3 on Exynos 4412 (Samsung Galaxy SIII, i9300) #21

Open
GNUtoo opened this issue Sep 14, 2019 · 10 comments
Open

Nothing appears on the UART3 on Exynos 4412 (Samsung Galaxy SIII, i9300) #21

GNUtoo opened this issue Sep 14, 2019 · 10 comments

Comments

@GNUtoo
Copy link

@GNUtoo GNUtoo commented Sep 14, 2019

Hi,

I've compiled the code and followed the instructions on the installation documentation for the Exynos 4142.

I've also configured the device I have (a Galaxy SIII (i9300) to boot on the microSD by erasing /dev/mmcblk0boot0).

I've burned output/xboot.bin to the SD card with

sudo dd if=xboot.bin of=/dev/sdb bs=512 seek=1 conv=sync

However at boot, I only have random characters the serial port.

But if I put u-boot on the SD card, I get u-boot logs on the serial port.

Do you have any idea of why it is not working?
Did you manage to get it working on devices with an Exynos 4412?
If so which devices did you manage to get it working on?

Denis.

@jerryjianjun

This comment has been minimized.

Copy link
Member

@jerryjianjun jerryjianjun commented Sep 18, 2019

may be a dram initial fail, you can put some code sys_uart_putc at start.S for debugging

@herbsmn

This comment has been minimized.

Copy link

@herbsmn herbsmn commented Sep 19, 2019

What is the device that you got this Exynos 4412 bootloader running on?

@GNUtoo

This comment has been minimized.

Copy link
Author

@GNUtoo GNUtoo commented Sep 20, 2019

Thanks for the pointers. I've done some investigations and here's what I found so far:
First I was using the wrong UART. I've now modified the code to use UART2.

I've verified that this code works by loading xboot.bin in u-boot:

 guess_board: i9300-1 i9305-0 n7100-1


U-Boot 2018.07-midas-g148a7b1436 (Sep 06 2019 - 15:42:16 +0200)

CPU:   Exynos4412 @ 800 MHz
Model: Samsung GT-I9300 based on Exynos4412
Board: Samsung GT-I9300 based on Exynos4412
DRAM:  1 GiB
an30259a_led_bind: bound red
an30259a_led_bind: bound green
an30259a_led_bind: bound blue
Key combo: 0xff
MMC:   SAMSUNG SDHCI: 1, EXYNOS DWMMC: 0
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
inform3: 0x00000000: invalid
midas_check_battery: Battery soc is OK - 81
guess_board: i9300-1 i9305-0 n7100-1
Booting normally...
Probe parent
(OK)
Probe red
Probe green
Net:   Not using network
No ethernet found.
Hit any key to stop autoboot:  0 
=> 
=> 
=> 
=> 
=> 
=> 
=> 
=> fatload mmc 1:1 0x40000000 /xboot.bin
3859184 bytes read in 615 ms (6 MiB/s)
=> go 0x40041a2c
## Starting application at 0x40041A2C ...
UUUUUUUUUUUUUUUUUUUUU

Here the print comes from the following modification:

--- a/src/init/main.c
+++ b/src/init/main.c
@@ -31,6 +31,10 @@
 
 int xboot_main(int argc, char * argv[])
 {
+       while(1) {
+               sys_uart_putc('U');
+       }
+
        /* Do initial memory */
        do_init_mem();

However if I look in mach-exynos4412/xboot.ld, there is the following:

ram : org = 0x40000000, len = 128M 

and:

	.text :
	{
		PROVIDE(__image_start = .);
		PROVIDE(__text_start = .);
		.obj/arch/arm32/mach-exynos4412/start.o (.text*)
		.obj/arch/arm32/lib/memcpy.o (.text*)
		.obj/arch/arm32/lib/memset.o (.text*)
		.obj/arch/arm32/mach-exynos4412/uart.o (.text*)
		.obj/arch/arm32/mach-exynos4412/sys-clock.o (.text*)
		.obj/arch/arm32/mach-exynos4412/sys-dram.o (.text*)
		.obj/arch/arm32/mach-exynos4412/sys-uart.o (.text*)
		.obj/arch/arm32/mach-exynos4412/sys-copyself.o (.text*)
		*(.text*)
		*(.init.text)
		*(.exit.text)
		*(.glue*)
		*(.note.gnu.build-id)
		PROVIDE(__text_end = .);
	} > ram

Is that the RAM area? If so how could it work if the RAM is not initialized?
If it's not the RAM area, how is it supposed to work? Is the BL1 header that is in start.S telling the bootrom to load the code at another address? Or is that done by mk4412.c ?

Denis.

@herbsmn

This comment has been minimized.

Copy link

@herbsmn herbsmn commented Sep 20, 2019

Not sure if this helps, but I used an online translation tool to read some of the headers here: https://github.com/xboot/xboot/blob/0c4e3049450d48b196d972bc476c05c89d7bfdc7/documents/xboot-system-development-guide-en-US.md

Here's a few snippets: "The xboot.ld file is the link script used by the linker to generate the final target file. It controls the generation of the entire target code, such as how the entry point is specified, the code segment, the data segment, the heap, the stack, and the embedded root file system. How to ensure that the system bootstrapping code is linked to the first 32K space and so on. This involves a lot of technical details, it is difficult to write on its own, it is recommended to copy a link script of other platforms directly, and simply make some modifications to meet the requirements."

"The start.S file is the entry file for the program and is usually written in assembly code. Including initialization vector table, stack pointer, initialization system clock, DDR controller, as well as bootstrapping, preparing environment for C language, finally jumping to RAM and executing xboot_main function. This part of the code is difficult to write and requires a deep programming skill. You can refer to other implementations in the system to simulate and write and test the code in steps."

@herbsmn

This comment has been minimized.

Copy link

@herbsmn herbsmn commented Sep 21, 2019

It looks like the dram is initialized using this: https://github.com/xboot/xboot/blob/b71fe8174882277897649bfe2177bf3ca300af69/src/arch/arm32/mach-exynos4412/sys-dram.S

Also, 0x40000000 is mentioned here:

machine_mmap(mach, "ram", 0x40000000, 0x40000000, SZ_128M, MAP_TYPE_CB);

@herbsmn

This comment has been minimized.

Copy link

@herbsmn herbsmn commented Sep 21, 2019

0x40000000 is where DRAM controller 0 memory starts based on this: http://linux-exynos.org/wiki/Samsung_Exynos_4412

@GNUtoo

This comment has been minimized.

Copy link
Author

@GNUtoo GNUtoo commented Sep 24, 2019

The compiled assembly code from start.S seem to be position independent, so I'll try to output to serial find a GPIO that I can use from assembly instead.

@GNUtoo

This comment has been minimized.

Copy link
Author

@GNUtoo GNUtoo commented Sep 26, 2019

Hi again,

I investigated a bit more in the code and found that my setup didn't correspond to the code assumption:
in src/arch/arm32/mach-exynos4412/sys-copyself.c in the sys_copyself function there is the following code that is executed after reading the OM register:

        /* SDMMC CH2 */
        if(om == 0x2)
        {
                mem = (u32_t *)&__image_start;
                size = (&__image_end - &__image_start + 0x00040000) >> 18;
                size = size << 9;
                irom_sdmmc_to_mem(1, size, mem);
        }
        /* eMMC43 CH0 */
        else if(om == 0x3)
        {
        }
        /* eMMC44 CH4 */
        else if(om == 0x4)
        {
        }

Here's my testing setup: On the Galaxy SIII (I9300) that I use, the OM register content is 0x4 (I've retrieved it from u-boot). So it boots by default on the eMMC. However to make testing faster and easier, I've blanked the eMMC boot partition with dd if=/dev/zero of=/dev/mmblk2boot0, after enabling write to it. With that it boots fine on a microSD that has the following software:

  • BL1
  • u-boot-spl
  • u-boot.

After finding about that issue, I've modified the code:

-	if(om == 0x2)
+	/* Hack: the OM pins are setup to boot on the eMMC CH4
+	 * but as I blanked the mmcblk0boot0 it then switch to the
+	 * uSD next in the boot source
+	 */
+	if(om == 0x2 || om == 0x4)
 	{
 		mem = (u32_t *)&__image_start;
 		size = (&__image_end - &__image_start + 0x00040000) >> 18;

However I still get nothing on the serial port, and I didn't see any examples on how to print from assembly.

If I understand well, the first code to execute is the branch to reset and then the code in reset in src/arch/arm32/mach-exynos4412/start.S.

I'll try to look at various options for debugging (using the watchdog, GPIOs, fixing and printing to serial in assembly before the RAM init, etc).

So far:

  • I validated that the code from xboot_main after, as if I load it from u-boot and jump to the location of that function, it prints to the serial port.
  • I've not yet validated any of the code before that nor that some code executes.

Denis.

@xc-racer99

This comment has been minimized.

Copy link

@xc-racer99 xc-racer99 commented Sep 27, 2019

I'll try to look at various options for debugging (using the watchdog, GPIOs, fixing and printing to serial in assembly before the RAM init, etc).

One thing you could look into/try would be making sure that the UART_SEL gpio(s?) is set properly. I'm not really familiar with any Exynos4412 devices, but it appears that the i9300 has a similar GPIO to the s5pv210 devices I've used where the UART_SEL gpio is either an output high or low for switching between the CP and the AP serial port. If you're using the internal serial as opposed to the multiplexed USB output then this may not have any effect, I don't know.

@herbsmn

This comment has been minimized.

Copy link

@herbsmn herbsmn commented Nov 27, 2019

@jerryjianjun can you please take a look at the posts in this issue and the pending pull request related to the posts? we are all very curious to learn more about this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.