Android Tablets Forum banner
1 - 11 of 11 Posts

·
Registered
Joined
·
353 Posts
If you want to known more about the boot sequence, you can refer the document:

R19UH0036EJ0600.pdf (1 chip, which downloaded from http://www2.renesas.com/mobile/en/emma_mobile/em_ev.html)

-> Appendix C: Boot loader in ROM

I assume you have U-boot source code. If you don't have u-boot source code, you can download here:

http://dl.dropbox.com/u/60117641/u-boot-bspgb-110801.tar.gz

this is Renesas officially released, Livall and Smallart (two of the manufacturers of tablets based on Renesas SoC) both modified it.

I'll explain a "Smallart" firmware update package first:

Sdboot.bin: a pre-loader that used only in sd card boot mode, the source code in board/emxx/emev/mini-boot/, and the lowlevel-init.S is also compiled
Uboot-sd.bin: this is u-boot
uImage: this is the common Linux kernel image, it include a initial RAM disk image, so it can boot without root file system, it is only used in recovery mode
Update.zip: It includes uboot-emmc, uImage and root fs, which will be extracted into eMMC flash during installation

Please understand that your package is not the "Run time" image, it is just used to install Android on the eMMC flash. All the "Run time" files are in "update.zip".

A "Livall" update package is composed of:

Sdboot.bin: this is same as Smallart, it is the pre-loader
Uboot-sd.bin: this is also same, uboot
uImage4: this is the image both for sd card boot and copied to eMMC flash
Cramfs4: this is a cramfs type root fs image, it will be loaded as a ramdisk in Android installation
Uboot4.bin: this is the boot loader for eMMC boot, it will be copied to eMMC flash
android-fs4.tar.gz: this is the Android filesystem
ff4: this is the eMMC partition table
 

·
Registered
Joined
·
353 Posts
Trying a build, in my env where I have the Android NDK (release 6) toolchain installed.

> export CROSS_COMPILE=arm-linux-androideabi-
> tar xzf u-boot-bspgb-110801.tar.gz
> cd u-boot

1) For an eMMC boot

> make distclean
> make emev_emmc_config
> make

This was succesfull. Got these files:

-rwxr-xr-x 1 root root 390296 Feb 2 05:47 u-boot.srec
-rw-r--r-- 1 root root 114797 Feb 2 05:47 u-boot.map
-rwxr-xr-x 1 root root 130068 Feb 2 05:47 u-boot.bin
-rwxr-xr-x 1 root root 453562 Feb 2 05:47 u-boot
-rw-r--r-- 1 root root 19488 Feb 2 05:47 System.map
-rw-r--r-- 1 root root 138260 Feb 2 05:47 u-boot-emmc.bin

2) For an SD boot:

> make distclean
> make emev_sd_line_config
> make

-rwxr-xr-x 1 root root 389442 Feb 2 06:08 u-boot.srec
-rw-r--r-- 1 root root 129784 Feb 2 06:08 uboot-sd.bin
-rw-r--r-- 1 root root 114675 Feb 2 06:08 u-boot.map
-rwxr-xr-x 1 root root 129784 Feb 2 06:08 u-boot.bin
-rwxr-xr-x 1 root root 447246 Feb 2 06:08 u-boot
-rw-r--r-- 1 root root 19523 Feb 2 06:08 System.map
-rwxr-xr-x 1 root root 8312 Feb 2 06:08 sdboot.bin

Note here the "sdboot.bin", which is the "mini-boot" as referred in the datasheet.

--- EDIT ---

Apply the next patch, if your board have 512MB DDR memory.

Code:
<br />
index 707d2d4..2e4a767 100644<br />
<br />
--- a/board/emxx/emev/lowlevel_init_val.h<br />
+++ b/board/emxx/emev/lowlevel_init_val.h<br />
@@ -22,7 +22,7 @@<br />
<br />
<br />
 #define EMXX_PWC_CHANGE_CORE<br />
 #ifndef CONFIG_EMXX_UNUSE_AB<br />
-#define EMXX_READ_VERSION<br />
+/*#define EMXX_READ_VERSION*/<br />
 #endif<br />
<br />
 /*****************************************************<br />
@@ -228,13 +228,13 @@<br />
<br />
 #define MEMC_REQSCH_VAL                0x0000001f<br />
 <br />
<br />
-#define MEMC_DDR_CONFIGF_VAL           0x8e000004<br />
+#define MEMC_DDR_CONFIGF_VAL           0x8e000008<br />
 #define MEMC_DDR_CONFIGA1_VAL          0x5c4a4517<br />
 #define MEMC_DDR_CONFIGA2_ES1          0x8800a840<br />
 #define MEMC_DDR_CONFIGA2_ES2          0x8800aa60<br />
 #define MEMC_DDR_CONFIGA2_ES3          0x8800a840<br />
 <br />
<br />
-#define MEMC_DDR_CONFIGR3_VAL1         0xc11a0000<br />
+#define MEMC_DDR_CONFIGR3_VAL1         0xc12c0000<br />
 <br />
<br />
 #define MEMC_DDR_CONFIGC1_VAL1         0x40400043<br />
 #define MEMC_DDR_CONFIGC2_VAL1         0x0000001d<br />
 

·
Registered
Joined
·
46 Posts
Does this open up the possibilities for custom bootloaders, and even more standard Android filesystem structures etc allowing for easier generic development?
 

·
Registered
Joined
·
353 Posts
Discussion Starter · #4 ·
Yes, I think so... but much study is needed...
 

·
Registered
Joined
·
353 Posts
Let me explain the boot sequence in slight higher detail, u-boot can be compiled with different configuration:

emev_emmc_config
emev_sd_config
emev_sd_line_config

EM/EV ROM boot code exist in 0xFFFF_0000, and it use internal SRAM 0xF000_0000
This ROM boot code will load mini-boot to SRAM and jump to 0xF000_0000
For SD boot mode, miniboot is sdboot.bin in SD card root directory
For eMMC boot: miniboot is the first 8K bytes in mmcblk0p1
Miniboot load the remained part
SD boot:
Load rest of u-boot (uboot-sd.bin to DDR#0x4100_8000)
Load kernel image (uImage to DDR#0x4000_7fc0)
Load ram disk (cramfs to DDR#0x4600_0000), this is optional due to compile option
eMMC boot:
Load rest of u-boot (mmcblk0p1#0x0000_2000-0x0004_0000 to DDR#0x4100_8000)
Load kernel image (mmcblk0p2 to DDR#0x4000_7fc0)
Then jump to u-boot

u-boot load kernel with different parameters.

There will be different boot arguments from u-boot, the definition of which can be found in the u-boot code, in include/configs/emev.h:

Code:
<br />
...<br />
#define CONFIG_CRAMFSCMD	"setenv bootargs root=/dev/null noinitrd init=/linuxrc console=ttyS0,115200n8n SELINUX_INIT=no \$(cfg_ddr) ro video=qfb: ip=none rootflags=physaddr=0x00500000\;bootm 00080000"<br />
#ifdef CONFIG_EMXX_SDBOOT_LINE	/* SD boot linesystem */<br />
#define CONFIG_EXT3CMD		"setenv bootargs root=/dev/null noinitrd init=/linuxrc console=ttyS0,115200n8n SELINUX_INIT=no [email protected] rw video=qfb: ip=none rootflags=physaddr=0x46000000\;bootm 40007fc0"<br />
#else<br />
#define CONFIG_EXT3CMD		"setenv bootargs root=\$(ext3_root) noinitrd init=/linuxrc console=ttyS0,115200n8n SELINUX_INIT=no \$(cfg_ddr) rw video=qfb: ip=none rootfstype=ext3 rootwait\;bootm 40007fc0"<br />
#endif<br />
...<br />
If you mount mount cramfs to your file system, out of a "Livall" typical update package (which includes botha a "cramfs4" file and an "install.sh" script), you can see how the install script is invoked:

Code:
<br />
sudo mkdir /mnt/cramfs<br />
sudo mount -o loop cramfs4 /mnt/cramfs<br />
ls -l /mnt/cramfs/linuxrc<br />
lrwxrwxrwx 1 root root 11 1970-01-01 01:00 /mnt/cramfs/linuxrc -> bin/busybox<br />
cd /mnt/cramfs/etc/init.d/<br />
cat rcS<br />
...<br />
    INSTALL_SH=`ls /tmp/sd/install.sh`<br />
    if [ "$INSTALL_SH" = "/tmp/sd/install.sh" ]; then<br />
        /tmp/sd/install.sh<br />
    fi<br />
...<br />
Note how the boot command inlcudes "init=/linuxrc", which points to a standard busybox executable. This will by default invoke the "::sysinit:/etc/init.d/rcS" action.

I hope this information can help the Renesas community ...
 

·
Registered
Joined
·
353 Posts
Discussion Starter · #6 ·

·
Global Moderator
Joined
·
878 Posts
This thread seems a good place to ask the question about the differences between a vol- and vol+ update and the files that are essential for each process.
 

·
Registered
Joined
·
353 Posts
Discussion Starter · #8 ·
As far as I've understood until now, the "Vol+" bootup sequence is the one which invokes the "install.sh" script and in there you can find all the necessary files for a compelte firmware update. Unfortunately we don't have the Livall complete source code (which is proprietary). They have customized that, at least to introduce the MD5 check (the one based on update.conf), as well as to identify if Vol- is pressed, which starts a "recovery" procedure, which I miss the details about too.
 

·
Registered
Joined
·
1 Posts
What happens if you flash a bad bootloader?
Will the dive be bricked then or will it still be possible to boot from sdcard?

If thats not possible I think it's very risky to develope an bootloader.
 

·
Registered
Joined
·
353 Posts
Discussion Starter · #10 ·
Hi Micha

it's virtually impossible to brick the device, as the core of the boot is hardcoded in the SoC ROM (as described in the doc referred above), so it's impossible the Vol+/Pwr sequence will not access the SD-card looking for the uboot. So, if you put an SD card with a good bootloader sequence you will have your device back.

Fabio
 

·
Registered
Joined
·
353 Posts
Discussion Starter · #11 ·
You can find here:

https://github.com/Renesas-EMEV2/RenesasEV2-bootloader/blob/MyPad/README-Renesas

the descriptions of the procedures to create an SD card for firmware update, or a bootable one, and the scripts to automate them: fwupd/fwupd.sh and testsd/testsd.sh, respectively. These include the build of the bootloaders from source code.

With JB, which has a larger filesystem than GB, the internal NAND needs a re-partitioning as well, which is missing in the script. So, fwupd/fwupd.sh fails with JB, as of now, leaving the NAND flashing incomplete. This script works for GB only.

I'm presently using testsd/testsd.sh for my tests with JB, so that I don't even need to touch the NAND at all and I can leave the stock firmware over there.
 
1 - 11 of 11 Posts
Top