Enabling Cache in SPL - how to speed up booting from SPL

Hi,

because we are fast able to boot the kernel directly from SPL, I am
experimenting now how we can speed up the process. Mainly my focus is
how to make copy from storage (=NAND) to RAM faster.

There are two approaches I can see: using DMA in NAND driver, or/and
enabling cache. I have not yet patches (I hacked the code dirtly), but I
have some results I cannot understand.

First of all, DMA. DMA for OMAP is mainlined now with Simon's patches,
enabling DMA in nand_spl_simple.c as sent by Simon does not work for me,
but I have adapted the patch to my platform (twister board, mainlined,
with TI AM3517). Here the results measuring between start of the copy
and before giving the control to the kernel (kernel size is 2188100):

                                   Seconds
-----------------------------------------------------------------
No cache, no DMA                    1.700
DMA in NAND driver                  1.190
Enabling Cache                      2.120

With enabled DMA I won on my platform ~600mSec. However, enabling cache
is worse than disabling, and this let me really confused.

I have not done any special things to enable cache, and I reused code
already provided. I have only set to an arbitrary address in RAM (but
64KB aligned) gd->tbl, and then I called enable_caches(). I can see that
mmu_setup() is called, and at the end icache_status() and
dcache_status() return both that cache is enabled.

[PATCH][v3]powerpc/8xxx:Add MPH controller support in USB device-tree fixup

Add support for fixing usb mode and phy type for
MPH(Multi Port Host) USB controllers in device-tree nodes.
Required for socs like P3060, P5020, etc having MPH USB controller

Signed-off-by: Ramneek Mehresh <ramneek.mehresh <at> freescale.com>
---
Changes for v3:
	- removed const* type cast for node_type
	- used CONFIG_HAS_FSL_MPH_USB in condition for including
	  fdt_fixup_dr_usb()

 arch/powerpc/cpu/mpc8xxx/fdt.c |   29 +++++++++++++++++++----------
 include/fdt_support.h          |    4 ++--
 2 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/cpu/mpc8xxx/fdt.c b/arch/powerpc/cpu/mpc8xxx/fdt.c
index bc1c30e..09810be 100644
--- a/arch/powerpc/cpu/mpc8xxx/fdt.c
+++ b/arch/powerpc/cpu/mpc8xxx/fdt.c
@@ -86,30 +86,39 @@ void ft_fixup_num_cores(void *blob) {
 }
 #endif /* defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx) */

-#ifdef CONFIG_HAS_FSL_DR_USB
+#if defined(CONFIG_HAS_FSL_DR_USB) || defined(CONFIG_HAS_FSL_MPH_USB)
 static int fdt_fixup_usb_mode_phy_type(void *blob, const char *mode,
 				const char *phy_type, int start_offset)
 {
-	const char *compat = "fsl-usb2-dr";
+	const char *compat_dr = "fsl-usb2-dr";

Re: Does U-boot support ASLR?

Dear Jason,

please keep the ML on Cc:

In message <4F33E93E.5070804 <at> ggsg.cisco.com> you wrote:
> 
>     Do you happen to have a reference to that presentation?  I'm very
> interested, as i thought ASLR was in place to make it harder.  I've done
> a weak google search but haven't turned up anything.

I'm sorry - I already searched when I wrote my first reply, but I
didn't save the link when I read this.  I am pretty much sure that it
was in an article posted on  http://www.heise.de/newsticker/ (and that
it was in German language), but then it's likely that a similar
article has been posted to  http://www.h-online.com/ .

I can find a few articles that talk about ways to outsmart ASLR, for
example
http://www.h-online.com/security/features/Return-of-the-sprayer-exploits-to-beat-DEP-and-ASLR-1171463.html
but none of the ones I checked contained the statement I quoted (that
ASLR actually makes it easier for crackers), or I didn't find it.

Yes, the ideas behind ASLR was to make breaking into systems harder,
and it does so for conventional attack methods.  But breaking into
systems is an art, and each new protection mechanism will attract
forces to break them.  In the end, you have to ask yourself if the
efforts for a protection mechanism is worth the increaseof security it
gives you.

As others have pointed out, U-Boot (while running in interactive mode)

Problem in loading rootfs

Hi,

I am facing problem in loading my image on Netgear GSM7353S switch. Let me
give you some context

   1. I started with following link
   http://www.openflowhub.org/display/Indigo/Upgrading+the+Flash+of+the+Netgear+73xx+for+OpenFlow
   .
   2. Link said to copy the image using command *flashcp -v
   gsm73xxso-of-1.1.0.2.image /dev/mtd0*
   3. Then it sets the bootargs using following command. *setenv ofboot
   'setenv bootargs console=ttyS0,115200 init=/etc/preinit rw; bootm fe000000
   fe180000'*
   4. All things went fine and I get the appropriate prompt.
   5. Then I prepared my own image and tried to burn it using the same
   above command and reboot the switch.
   6. It shows me following message

Data Size: 1039259 Bytes = 1014.9 KB
Load Adress: 00400000
Entry point: 004005b0
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Wrong Ramdisk image format
...
VFS: Cannot open root device "<NULL>" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available
partitions:
1f00 28416 mtdblock0 (driver?)
1f01 256 mtdblock1 (driver?)

[PATCH v2 0/2] da850evm: add board specific functions

There are two da850 SOC based EVMs, one from Spectrum digital
and other from Logic PD. Boards from Spectrum digital have mac
address stored in I2C EEPROM and they have spi flash manufactured
by WINBOND. Boards from Logic PD store mac address in ST
Microelectronics SPI flash. This patch series adds support to
read mac address from the appropriate device.

Changes for v2:
1: Fixed a comment from Wolfgang, comparing MAC address if present in
   different locations and raising a warning on mismatch.
2: Fixed a comment from Mike, removed return -EINVAL statement,
   just issuing a warning in case of error in misc_init_r() function
   while reading MAC address.

Manjunath Hadli (2):
  da850evm: add support to read mac address from SPI flash
  da850evm: read mac address from I2C EEPROM on AM18x EVM

 board/davinci/da8xxevm/da850evm.c |  103 +++++++++++++++++++++++++++++++++++++
 boards.cfg                        |    4 +-
 2 files changed, 105 insertions(+), 2 deletions(-)

[PATCH v3] davinci: cleanup davinci_sync_env_enetaddr() fucntion

check for the return status for eth_getenv_enetaddr_by_index()
and eth_setenv_enetaddr() functions and print appropriate message
on failure.

Signed-off-by: Manjunath Hadli <manjunath.hadli <at> ti.com>
Cc: Tom Rini <trini <at> ti.com>
Cc: Mike Frysinger <vapier <at> gentoo.org>
Cc: Wolfgang Denk <wd <at> denx.de>
---
 Changes for v3:
 undo conversion of debug statement to printf().

 Changes for v2:
 Removed additional check of comparing ethernet address is all
 zeros, As the core code already calls is_valid_ether_addr()
 and one of the checks in there is for all zeros.

 arch/arm/cpu/arm926ejs/davinci/misc.c |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/davinci/misc.c b/arch/arm/cpu/arm926ejs/davinci/misc.c
index 5f510b6..c310c69 100644
--- a/arch/arm/cpu/arm926ejs/davinci/misc.c
+++ b/arch/arm/cpu/arm926ejs/davinci/misc.c
@@ -101,9 +101,10 @@ void davinci_emac_mii_mode_sel(int mode_sel)
 void davinci_sync_env_enetaddr(uint8_t *rom_enetaddr)
 {
 	uint8_t env_enetaddr[6];
+	int ret;

please pull u-boot-samsung/master

Dear Albert,

The following changes since commit ca849aa4b86b282f837c58a0b129460ebfad2239:

  ARM: activate DISPLAY_CPUINFO for VCMA9 + SMDK2410 board (2012-02-06 22:47:25 +0100)

are available in the git repository at:
  git://git.denx.de/u-boot-samsung master

Chander Kashyap (8):
      Exynos: PWM: Add TCMPB3 field in pwm structure
      Exynos: Fix ARM Clock frequency calculation
      Origen: Select SCLKMPLL as FIMD0 parent clock
      Exynos: Clock.c: Use CONFIG_SYS_CLK_FREQ macro
      ARM: EXYNOS: Add support for Exynos5 based SoCs
      EXYNOS: Add SMDK5250 board support
      EXYNOS: SMDK5250: Add MMC SPL support
      SMDK5250: Add ethernet support

HeungJun, Kim (3):
      ARMV7: Exynos4: Add watchdog.h for Exynos4
      ARMV7: Exynos4: Add supoort power for Exynos4
      ARMV7: Exynos4: Add support for TRATS board

Minkyu Kang (4):
      ORIGEN: remove duplicated MACH_TYPE define
      S5P: support generic watchdog timer
      TRATS: use the generic watchdog timer
      TRATS: set gpio of UART correctly

Formatting bootable SD, freescale platform

Hello,

Does anybody happen to know a reference with _details_ of how to format and
mkfs an SD card to be bootable for freescale platform?

Background:  I'm using a freescale utility (
https://github.com/kergoth/boot-format), but it fails at runtime, unhappy
with my SD MBR.  Console output is shown below.

I've run fdisk/mkfs with various tweaks, getting FAT16+ext2 partitions per
the references I've found (
http://www.freescalewiki.com/index.php?title=Getting_started_Guide_for_P1010/P1014,
http://cache.freescale.com/files/32bit/doc/app_note/AN3659.pdf).  But
boot_format still bails out.

Thanks in advance, Joe K.
----
> sudo ./boot_format config_ddr3_1gb_p1010rdb_800M.dat uboot.bin -sd
/dev/sdb1
...
Read MBR from SDCard:

0x0000: eb 00 90 20 20 20 20 20 20 20 20 00 02 40 01 00
0x0010: 02 00 02 00 00 f8 eb 00 3f 00 40 00 89 00 00 00
0x0020: 77 9f 3a 00 80 00 29 a5 7b f7 7b 00 00 00 00 00
0x0030: 00 00 00 00 00 00 46 41 54 31 36 20 20 20 00 00
0x0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...
================== MBR ==================
boot_ind        = 0x0

Password protection of U-Boot command line

Hi All,

As an adjunct to a recent discussion, I wonder if there would be much
point in password protecting access to the U-Boot command line. The
password could be saved in an environment variable as an MD-5 or SHA-256
hash.

But I wonder if:

 a) It's worth it, and;
 b) If it would be secure anyway...

When U-Boot environment editing tools available in the host OS, it would
be fairly trivial to overwrite the password variable - Unless, of course,
the host OS did not support that functionality.

This feature may be usefull for devices where every part of the system
must be tightly controlled (medical devices, voting machines etc)

Regards,

Graeme

[PATCH 1/5] mx31pdk: Fix CONFIG_SYS_MEMTEST_END

CONFIG_SYS_MEMTEST_END should be higher than CONFIG_SYS_MEMTEST_START.

Signed-off-by: Fabio Estevam <fabio.estevam <at> freescale.com>
---
 include/configs/mx31pdk.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/configs/mx31pdk.h b/include/configs/mx31pdk.h
index 4da6020..49d440b 100644
--- a/include/configs/mx31pdk.h
+++ b/include/configs/mx31pdk.h
@@ -141,7 +141,7 @@

 /* memtest works on */
 #define CONFIG_SYS_MEMTEST_START	0x80000000
-#define CONFIG_SYS_MEMTEST_END		0x10000
+#define CONFIG_SYS_MEMTEST_END		0x80010000

 /* default load address */
 #define CONFIG_SYS_LOAD_ADDR		0x81000000
--

-- 
1.7.1

Configuration settings for Freescale i.MX53x demo boards

Hello Jason Liu,

Is there a glossary for the defines used in the
/include/configs/≤board_name.h> files?

Regards,

Bud Miljkovic 

_______________________________________________
U-Boot mailing list
U-Boot <at> lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot