date:20151013

[U-Boot] [PATCH] colibri_vf: Fix bstlen field

2015-10-13 Thread Fabio Estevam

From: Fabio Estevam 

Commit 3f353cecc ("vf610: refactor DDRMC code") changed the original
bstlen field from 3 to 0.

Restore the original value for proper behaviour.

Based on the patch from Anthony Felice 
for the vf610twr board.

Reported-by: Stefan Agner 
Signed-off-by: Fabio Estevam 
---
 board/toradex/colibri_vf/colibri_vf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/toradex/colibri_vf/colibri_vf.c 
b/board/toradex/colibri_vf/colibri_vf.c
index 39bf0ac..a6d1c5b 100644
--- a/board/toradex/colibri_vf/colibri_vf.c
+++ b/board/toradex/colibri_vf/colibri_vf.c
@@ -119,7 +119,7 @@ int dram_init(void)
.trcd_int  = 6,
.tras_lockout  = 0,
.tdal  = 12,
-   .bstlen= 0,
+   .bstlen= 3,
.tdll  = 512,
.trp_ab= 6,
.tref  = 3120,
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] colibri_vf: Fix typo in DRAM init

2015-10-13 Thread Stefan Agner

From: Stefan Agner 

This commit fixes the same typo found in vf610twr DRAM init also for
colibri_vf DRAM init. This typo was introduced in commit 3f353cecc
(vf610: refactor DDRMC code).

Signed-off-by: Stefan Agner 
---
 board/toradex/colibri_vf/colibri_vf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/toradex/colibri_vf/colibri_vf.c 
b/board/toradex/colibri_vf/colibri_vf.c
index 39bf0ac..a6d1c5b 100644
--- a/board/toradex/colibri_vf/colibri_vf.c
+++ b/board/toradex/colibri_vf/colibri_vf.c
@@ -119,7 +119,7 @@ int dram_init(void)
.trcd_int  = 6,
.tras_lockout  = 0,
.tdal  = 12,
-   .bstlen= 0,
+   .bstlen= 3,
.tdll  = 512,
.trp_ab= 6,
.tref  = 3120,
-- 
2.6.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Command to create a partition table?

2015-10-13 Thread Masahiro Yamada

2015-10-02 15:46 GMT+09:00 Masahiro Yamada :
> Hi guys,
>
>
> I am searching for a command to create
> a partition table (like fdisk command).
>
> I can create a partition table by PC
> for removable devics such as SD card,
> but I want U-boot to do that for on-board devices
> such as eMMC.
>
> Does U-boot have one?
>

"No reply" means "No, U-Boot does not support it", right?



-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] vf610twr: Fix typo in DRAM init

2015-10-13 Thread Stefan Agner

Hi Anthony,

Tested on a Tower, works for me.

Can you also fix the Colibri VF board? It seems to suffer the same
issue, introduced by the same commit...

--
Stefan

On 2015-10-09 13:38, Anthony Felice wrote:
> This commit fixes a typo in vf610twr DRAM init that was causing a hang in
> U-Boot for the Vybrid Tower. This typo was introduced in commit 3f353cecc
> (vf610: refactor DDRMC code).
> 
> Signed-off-by: Anthony Felice 
> ---
>  board/freescale/vf610twr/vf610twr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/board/freescale/vf610twr/vf610twr.c
> b/board/freescale/vf610twr/vf610twr.c
> index a78e9e6..fa0075c 100644
> --- a/board/freescale/vf610twr/vf610twr.c
> +++ b/board/freescale/vf610twr/vf610twr.c
> @@ -108,7 +108,7 @@ int dram_init(void)
>   .trcd_int  = 6,
>   .tras_lockout  = 0,
>   .tdal  = 12,
> - .bstlen= 0,
> + .bstlen= 3,
>   .tdll  = 512,
>   .trp_ab= 6,
>   .tref  = 3120,

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] mtd: nand: vf610_nfc: resync with upstream Linux version

2015-10-13 Thread Stefan Agner

This resyncs the driver changes with the Linux version of the
driver. The driver received some feedback in the LKML and got
recently acceppted, the latest version can be found here:
https://lkml.org/lkml/2015/9/2/678

Notable changes are:
- On ECC error, reread OOB and count bit flips in OOB too.
  If flipped bits are below threshold, also return an empty
  OOB buffer.
- Return the amount of bit flips in vf610_nfc_read_page.
- Use endianness aware vf610_nfc_read to read ECC status.
- Do not enable IDLE IRQ (since we do not operate with an
  interrupt service routine).
- Use type safe struct for buffer variants (vf610_nfc_alt_buf).
- Renamed variables in struct vf610_nfc (column and page_sz)
  to reflect better what they really representing.

The U-Boot version currently does not support RAW NAND write
when using the HW ECC engine.

Signed-off-by: Bhuvanchandra DV 
Signed-off-by: Stefan Agner 
---
 drivers/mtd/nand/vf610_nfc.c | 247 ---
 1 file changed, 138 insertions(+), 109 deletions(-)

diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
index 5c11ac9..06266f3 100644
--- a/drivers/mtd/nand/vf610_nfc.c
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -1,5 +1,5 @@
 /*
- * Copyright 2009-2014 Freescale Semiconductor, Inc. and others
+ * Copyright 2009-2015 Freescale Semiconductor, Inc. and others
  *
  * Description: MPC5125, VF610, MCF54418 and Kinetis K70 Nand driver.
  * Ported to U-Boot by Stefan Agner
@@ -19,9 +19,10 @@
  *
  * Limitations:
  * - Untested on MPC5125 and M54418.
- * - DMA not used.
+ * - DMA and pipelining not used.
  * - 2K pages or less.
- * - Only 2K page w. 64+OOB and hardware ECC.
+ * - HW ECC: Only 2K page with 64+ OOB.
+ * - HW ECC: Only 24 and 32-bit error correction implemented.
  */
 
 #include 
@@ -53,6 +54,7 @@
 
 #define PAGE_2K0x0800
 #define OOB_64 0x0040
+#define OOB_MAX0x0100
 
 /*
  * NFC_CMD2[CODE] values. See section:
@@ -127,32 +129,33 @@
 
 #define NFC_TIMEOUT(1000)
 
-/* ECC status placed at end of buffers. */
-#define ECC_SRAM_ADDR  ((PAGE_2K+256-8) >> 3)
-#define ECC_STATUS_MASK0x80
-#define ECC_ERR_COUNT  0x3F
-
 /*
- * ECC status is stored at NFC_CFG[ECCADD] +4 for little-endian
- * and +7 for big-endian SOC.
+ * ECC status - seems to consume 8 bytes (double word). The documented
+ * status byte is located in the lowest byte of the second word (which is
+ * the 4th or 7th byte depending on endianness).
+ * Calculate an offset to store the ECC status at the end of the buffer.
  */
-#ifdef CONFIG_VF610
-#define ECC_OFFSET 4
-#else
-#define ECC_OFFSET 7
-#endif
+#define ECC_SRAM_ADDR  (PAGE_2K + OOB_MAX - 8)
+
+#define ECC_STATUS 0x4
+#define ECC_STATUS_MASK0x80
+#define ECC_STATUS_ERR_COUNT   0x3F
+
+enum vf610_nfc_alt_buf {
+   ALT_BUF_DATA = 0,
+   ALT_BUF_ID = 1,
+   ALT_BUF_STAT = 2,
+   ALT_BUF_ONFI = 3,
+};
 
 struct vf610_nfc {
-   struct mtd_info   *mtd;
-   struct nand_chip   chip;
-   void __iomem  *regs;
-   uint   column;
+   struct mtd_info *mtd;
+   struct nand_chip chip;
+   void __iomem *regs;
+   uint buf_offset;
+   int write_sz;
/* Status and ID are in alternate locations. */
-   intalt_buf;
-#define ALT_BUF_ID   1
-#define ALT_BUF_STAT 2
-#define ALT_BUF_ONFI 3
-   struct clk*clk;
+   enum vf610_nfc_alt_buf alt_buf;
 };
 
 #define mtd_to_nfc(_mtd) \
@@ -170,8 +173,8 @@ static struct nand_ecclayout vf610_nfc_ecc = {
   48, 49, 50, 51, 52, 53, 54, 55,
   56, 57, 58, 59, 60, 61, 62, 63},
.oobfree = {
-   {.offset = 8,
-.length = 11} }
+   {.offset = 2,
+.length = 17} }
 };
 #elif defined(CONFIG_SYS_NAND_VF610_NFC_60_ECC_BYTES)
 #define ECC_HW_MODE ECC_60_BYTE
@@ -226,8 +229,12 @@ static inline void vf610_nfc_set_field(struct mtd_info 
*mtd, u32 reg,
 static inline void vf610_nfc_memcpy(void *dst, const void *src, size_t n)
 {
/*
-* Use this accessor for the interal SRAM buffers. On ARM we can
-* treat the SRAM buffer as if its memory, hence use memcpy
+* Use this accessor for the internal SRAM buffers. On the ARM
+* Freescale Vybrid SoC it's known that the driver can treat
+* the SRAM buffer as if it's memory. Other platform might need
+* to treat the buffers differently.
+*
+* For the time being, use memcpy
 */
memcpy(dst, src, n);
 }
@@ -242,7 +249,7 @@ static inline void vf610_nfc_clear_status(void __iomem 
*regbase)
 }
 
 /* Wait for complete operation */
-static inline void vf610_nfc_done(struct mtd_info *mtd)
+static void vf610_nfc_done(struct mtd_info *mtd)
 {
struct vf610_nfc *nfc = mtd_to_nfc(mtd);

[U-Boot] [PULL] Please pull u-boot-imx

2015-10-13 Thread Stefano Babic

Hi Tom,

please pull from u-boot-imx, thanks !

The following changes since commit 7daaac5281db0788cde895a0add38ad5195b5be1:

  mx6sabre_common: Add DFU support (2015-10-02 10:51:20 +0200)

are available in the git repository at:

  git://www.denx.de/git/u-boot-imx.git master

for you to fetch changes up to 61903b759aa336d798da49d884467219796817ff:

  imximage: fix commands other than write_data (2015-10-07 13:43:15 +0200)


Troy Kisky (2):
  imximage: header.length of 4 is valid
  imximage: fix commands other than write_data

 tools/imximage.c | 81
++---
 tools/imximage.h |  8 ++--
 2 files changed, 64 insertions(+), 25 deletions(-)

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] odroid DTB support

2015-10-13 Thread Guillaume Gardet




Le 12/10/2015 16:24, Tom Rini a écrit :

On Mon, Oct 12, 2015 at 10:54:04AM +0200, Guillaume Gardet wrote:

Hi,


Le 12/10/2015 01:45, Tom Rini a écrit :

On Fri, Oct 09, 2015 at 02:35:24PM +0200, Guillaume Gardet wrote:

Le 09/10/2015 14:23, Przemyslaw Marczak a écrit :

Hello Guillaume,

On 10/09/2015 02:11 PM, Guillaume Gardet wrote:

Hi Przemyslaw,

I would like to add DTB support for odroid board to be able to boot
upstream kernel easily.

I see 2 ways to do it:
* Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support to set 'board_rev'
and 'board_name' env vars. Then, you need a 'findfdt' script to check
'board_rev' and set fdtfile accordingly (as done for OMAP4 panda board)
* Set fdtfile name directly (as done for rpi or igep00x0).

What would you prefer?


Guillaume



Is, that the reason of adding the boot script by your last patches?

No, we need a boot script, because this is the way we boot our
openSUSE images (we boot with an initrd and some special bootargs).

Hang on, exynos stuff uses the generic distro hooks.  Can you take a
look at doc/README.distro and see what openSUSE can hook into / provide
some feedback on what needs doing?  Thanks!

This is true for odroid XU3 (Exynos5 based) but Odroid U3/X2 (Exynos4
based) has no generic distro hooks at the moment.

No, exynos-common pulls in generic distro.  And in the event of boards
that do not the answer is to pull in the generic distro framework.


It seems that exynos-common includes only "config_distro_defaults.h", not 
"config_distro_bootcmd.h".
And "config_distro_bootcmd.h" is needed for generic distro boot flow. Am I 
missing something?

Guillaume

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] ARM: AM335x: mux: change mmc0 cd pinmux from mmc0_sdcd to gpio

2015-10-13 Thread Mugunthan V N

Currently omap_hsmmc driver doesn't use sdcd pin to detect
whether the card is present or not. Instead the same pin is used
as GPIO to detect card presence. So change the pin mux mode from
mmc0_sdcd to gpio0_6.

Signed-off-by: Mugunthan V N 
---
 board/ti/am335x/mux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/ti/am335x/mux.c b/board/ti/am335x/mux.c
index 680f656..e49fa0c 100644
--- a/board/ti/am335x/mux.c
+++ b/board/ti/am335x/mux.c
@@ -65,7 +65,7 @@ static struct module_pin_mux mmc0_pin_mux[] = {
{OFFSET(mmc0_clk), (MODE(0) | RXACTIVE | PULLUP_EN)},   /* MMC0_CLK */
{OFFSET(mmc0_cmd), (MODE(0) | RXACTIVE | PULLUP_EN)},   /* MMC0_CMD */
{OFFSET(mcasp0_aclkr), (MODE(4) | RXACTIVE)},   /* MMC0_WP */
-   {OFFSET(spi0_cs1), (MODE(5) | RXACTIVE | PULLUP_EN)},   /* MMC0_CD */
+   {OFFSET(spi0_cs1), (MODE(7) | RXACTIVE | PULLUP_EN)},   /* GPIO0_6 */
{-1},
 };
 
-- 
2.6.1.133.gf5b6079

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] drivers: gpio: omap: add support for parsing additional gpio parameters

2015-10-13 Thread Mugunthan V N

With DM_GPIO, gpio parameters like ACTIVE_(LOW/HIGH) are to be
parsed in xlate gpio drivers-ops. Since xlate is not implemented
in omap_gpio driver, the driver considers all gpio to be
ACTIVE_HIGH which is the default case and fails to return actual
gpio status for ACTIVE_LOW gpios. So adding .xlate ops to
omap_gpio.

Signed-off-by: Mugunthan V N 
---
 drivers/gpio/omap_gpio.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpio/omap_gpio.c b/drivers/gpio/omap_gpio.c
index cd960dc..93d18e4 100644
--- a/drivers/gpio/omap_gpio.c
+++ b/drivers/gpio/omap_gpio.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -276,12 +277,22 @@ static int omap_gpio_get_function(struct udevice *dev, 
unsigned offset)
return GPIOF_INPUT;
 }
 
+static int omap_gpio_xlate(struct udevice *dev, struct gpio_desc *desc,
+  struct fdtdec_phandle_args *args)
+{
+   desc->offset = args->args[0];
+   desc->flags = args->args[1] & GPIO_ACTIVE_LOW ? GPIOD_ACTIVE_LOW : 0;
+
+   return 0;
+}
+
 static const struct dm_gpio_ops gpio_omap_ops = {
.direction_input= omap_gpio_direction_input,
.direction_output   = omap_gpio_direction_output,
.get_value  = omap_gpio_get_value,
.set_value  = omap_gpio_set_value,
.get_function   = omap_gpio_get_function,
+   .xlate  = omap_gpio_xlate,
 };
 
 static int omap_gpio_probe(struct udevice *dev)
-- 
2.6.1.133.gf5b6079

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] odroid DTB support

2015-10-13 Thread Przemyslaw Marczak

Hi Tom, Guillaume,

On 10/13/2015 09:37 AM, Guillaume Gardet wrote:

Le 12/10/2015 16:24, Tom Rini a écrit :

On Mon, Oct 12, 2015 at 10:54:04AM +0200, Guillaume Gardet wrote:

Hi,

Le 12/10/2015 01:45, Tom Rini a écrit :

On Fri, Oct 09, 2015 at 02:35:24PM +0200, Guillaume Gardet wrote:

Le 09/10/2015 14:23, Przemyslaw Marczak a écrit :

Hello Guillaume,

On 10/09/2015 02:11 PM, Guillaume Gardet wrote:

Hi Przemyslaw,

I would like to add DTB support for odroid board to be able to boot
upstream kernel easily.

I see 2 ways to do it:
* Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support to set
'board_rev'
and 'board_name' env vars. Then, you need a 'findfdt' script to
check
'board_rev' and set fdtfile accordingly (as done for OMAP4 panda
board)
* Set fdtfile name directly (as done for rpi or igep00x0).

What would you prefer?

Guillaume

Is, that the reason of adding the boot script by your last patches?

No, we need a boot script, because this is the way we boot our
openSUSE images (we boot with an initrd and some special bootargs).

Hang on, exynos stuff uses the generic distro hooks. Can you take a
look at doc/README.distro and see what openSUSE can hook into / provide
some feedback on what needs doing? Thanks!

This is true for odroid XU3 (Exynos5 based) but Odroid U3/X2 (Exynos4
based) has no generic distro hooks at the moment.

No, exynos-common pulls in generic distro. And in the event of boards
that do not the answer is to pull in the generic distro framework.

It seems that exynos-common includes only "config_distro_defaults.h",
not "config_distro_bootcmd.h".
And "config_distro_bootcmd.h" is needed for generic distro boot flow. Am
I missing something?

Guillaume

Tom,
it's true that, exynos5-common.h defines the CONFIG_EXTRA_ENV_SETTINGS,
which provides "BOOTENV".
Odroid XU3 redefines CONFIG_EXTRA_ENV_SETTINGS, but in the fact it uses
the same settings, appended by some private env variables.

Guillaume,
You're right, Exynos4 boards doesn't use the generic distro boot
commands. And each board defines CONFIG_EXTRA_ENV_SETTINGS.

All boards works with the mainline kernel by default, so it's not a high
priority for us to switch it to common env, but will do this soon.

You can check the bootscript example in the directory:
board/samsung/common/bootscripts/

As temporary, your patch for Odroid can be applied to support the
boot.scr, but anyway it support mainline kernel and probably can boot
Ubuntu images.

Some mainline release of U-Boot is used for Arch Linux images for Odroid
U3, you can check the changes for ARCH here:

https://github.com/archlinuxarm/PKGBUILDs/blob/master/alarm/uboot-odroid/0001-arch-linux-arm-modifications.patch

So if you need write custom boot.scr, maybe this will help you.

One more thing, if you need append the bootargs for your kernel, then
you can set the $opts variable which is always appended to bootargs.

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] odroid DTB support

2015-10-13 Thread Guillaume Gardet

Hi Przemyslaw, Tom,

Le 13/10/2015 11:11, Przemyslaw Marczak a écrit :

Hi Tom, Guillaume,

On 10/13/2015 09:37 AM, Guillaume Gardet wrote:

Le 12/10/2015 16:24, Tom Rini a écrit :

On Mon, Oct 12, 2015 at 10:54:04AM +0200, Guillaume Gardet wrote:

Hi,

Le 12/10/2015 01:45, Tom Rini a écrit :

On Fri, Oct 09, 2015 at 02:35:24PM +0200, Guillaume Gardet wrote:

Le 09/10/2015 14:23, Przemyslaw Marczak a écrit :

Hello Guillaume,

On 10/09/2015 02:11 PM, Guillaume Gardet wrote:

Hi Przemyslaw,

I would like to add DTB support for odroid board to be able to boot
upstream kernel easily.

What would you prefer?

Guillaume

Is, that the reason of adding the boot script by your last patches?

No, we need a boot script, because this is the way we boot our
openSUSE images (we boot with an initrd and some special bootargs).

Hang on, exynos stuff uses the generic distro hooks. Can you take a
look at doc/README.distro and see what openSUSE can hook into / provide
some feedback on what needs doing? Thanks!

This is true for odroid XU3 (Exynos5 based) but Odroid U3/X2 (Exynos4
based) has no generic distro hooks at the moment.

No, exynos-common pulls in generic distro. And in the event of boards
that do not the answer is to pull in the generic distro framework.

It seems that exynos-common includes only "config_distro_defaults.h",
not "config_distro_bootcmd.h".
And "config_distro_bootcmd.h" is needed for generic distro boot flow. Am
I missing something?

Guillaume

Tom,
it's true that, exynos5-common.h defines the CONFIG_EXTRA_ENV_SETTINGS, which provides
"BOOTENV".
Odroid XU3 redefines CONFIG_EXTRA_ENV_SETTINGS, but in the fact it uses the
same settings, appended by some private env variables.

Guillaume,
You're right, Exynos4 boards doesn't use the generic distro boot commands. And
each board defines CONFIG_EXTRA_ENV_SETTINGS.

Thanks for clarification.

All boards works with the mainline kernel by default, so it's not a high
priority for us to switch it to common env, but will do this soon.

ok.

You can check the bootscript example in the directory:
board/samsung/common/bootscripts/

Here, if $fdtfile is not defined, then it boots without it. This won't work for
us, since we need DTB (kernel multiplatform enabled).

As temporary, your patch for Odroid can be applied to support the boot.scr, but
anyway it support mainline kernel and probably can boot Ubuntu images.

Yes, please apply it to get boot.scr support until odroid switch to generic
boot system.

Some mainline release of U-Boot is used for Arch Linux images for Odroid U3,
you can check the changes for ARCH here:

https://github.com/archlinuxarm/PKGBUILDs/blob/master/alarm/uboot-odroid/0001-arch-linux-arm-modifications.patch

So if you need write custom boot.scr, maybe this will help you.

Big patches! ^^ openSUSE workflow is different. We try to minimize source
patches, upstream our patches and do our custom things in boot scripts which is
much more flexible.
Our boot.scr is (nearly) ready. The only thing missing is the fdtfile
definition (which is board dependent). We hardcoded it to U3 version for now to
make tests but this should be fixed.

Guillaume

One more thing, if you need append the bootargs for your kernel, then you can
set the $opts variable which is always appended to bootargs.

Best regards,

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 0/2] *Enhance Odroid board

2015-10-13 Thread Przemyslaw Marczak


Hello,

On 10/09/2015 02:26 PM, Guillaume GARDET wrote:

Those 2 patches enhances Odroid board support.
* First patch replace 'fatload' command by 'load', to be able to use EXT*
partitions while keeping FAT partition compatibility.
* Second patch adds boot script (boot.scr) support. If no boot script are
found, it boots as usual.

Changes in V3:
* Uses 'elif' version as requested by Przemyslaw Marczak

Changes in V2:
* Expand commit messages
* Better code consistency

Signed-off-by: Guillaume GARDET 
Cc: Przemyslaw Marczak 
Cc: Minkyu Kang 

---

Guillaume GARDET (2):
   odroid: replace 'fatload' with 'load' to be able to use EXT*
 partitions
   odroid: Add boot script (boot.scr) support

  include/configs/odroid.h | 16 
  1 file changed, 12 insertions(+), 4 deletions(-)



For the series:

Tested-by: Przemyslaw Marczak 
Acked-by: Przemyslaw Marczak 

Thanks!
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/8] ARM: hikey: Update README with various corrections

2015-10-13 Thread Peter Griffin

Hi Simon,


> On 17 September 2015 at 21:54, Simon Glass  wrote:
> >
> > Hi Peter,
> >
> > On 9 September 2015 at 15:13, Peter Griffin 
> wrote:
> > > The README had a few mistakes, and one of the URL's
> > > had changed. Also update the boot log with the latest
> > > boot trace from ATF, which now includes the mcuimage.bin.
> > >
> > > Signed-off-by: Peter Griffin 
> > > ---
> > >  board/hisilicon/hikey/README | 197
> ---
> > >  1 file changed, 147 insertions(+), 50 deletions(-)
> > >
> > > diff --git a/board/hisilicon/hikey/README
> b/board/hisilicon/hikey/README
> > > index 25c8143..36adbdb 100644
> > > --- a/board/hisilicon/hikey/README
> > > +++ b/board/hisilicon/hikey/README
> > > @@ -25,8 +25,12 @@ Currently the u-boot port supports: -
> > >  Compile u-boot
> > >  ==
> > >
> > > -make CROSS_COMPILE=aarch64-linux-gnu- hikey_config
> > > -make CROSS_COMPILE=aarch64-linux-gnu-
> > > +  > mkdir -p ./aarch64/bin
> > > +  > cd ./aarch64
> >
> > Do you really want the above? It seems odd that the 'cp' below expects
> > another level of subdir.
> >
> > > +  > git clone http://git.denx.de/u-boot.git
> > > +  > make CROSS_COMPILE=aarch64-linux-gnu- hikey_config
> > > +  > make CROSS_COMPILE=aarch64-linux-gnu-
> > > +  > cp u-boot.bin ./aarch64/bin/u-boot-hikey.bin
> > >
> > >  ARM Trusted Firmware (ATF) & l-loader
> > >  =
> > > @@ -34,27 +38,34 @@ ARM Trusted Firmware (ATF) & l-loader
> > >  This u-boot port has been tested with l-loader, booting ATF, which
> then boots
> > >  u-boot as the bl33.bin executable.
> > >
> > > +Get the BL30 mcu binary.
> > > +  > wget -P aarch64/bin
> https://builds.96boards.org/releases/hikey/linaro/binaries/15.05/mcuimage.bin
> > > +
> > >  1. Get ATF source code
> > > -git clone https://github.com/96boards/arm-trusted-firmware.git
> > > +  > cd ./aarch64
> > > +  > git clone https://github.com/96boards/arm-trusted-firmware.git
> > > +  > cd ./arm-trusted-firmware
> > >
> > > -2. Compile ATF I use the makefile here
> > > -
> http://people.linaro.org/~peter.griffin/hikey/hikey-u-boot-release_r1/build-tf.mak
> > > +2. Compile ATF, I use the build-tf.mak in the directory with this
> README, and copy it to ATF directory
> > > +  > cp ../u-boot/board/hisilicon/hikey/build-tf.mak .
> > > +  > make -f  build-tf.mak build
> > >
> > >  3. Get l-loader
> > > -git clone https://github.com/96boards/l-loader.git
> > > -
> > > -4. Make sym links to ATF bip / fip binaries
> > > -ln -s /home/griffinp/aarch64/bl1-hikey.bin bl1.bin
> > > -ln -s /home/griffinp/aarch64/fip-hikey.bin fip.bin
> > > +  > cd ../
> > > +  > git clone https://github.com/96boards/l-loader.git
> > > +  > cd ./l-loader
> > >
> > > -arm-linux-gnueabihf-gcc -c -o start.o start.S
> > > -arm-linux-gnueabihf-gcc -c -o debug.o debug.S
> > > -arm-linux-gnueabihf-ld -Bstatic -Tl-loader.lds -Ttext 0xf9800800
> start.o debug.o -o loader
> > > -arm-linux-gnueabihf-objcopy -O binary loader temp
> > > +4. Make sym links to ATF bl1 / fip binaries
> > > +  > ln -s ../bin/bl1-hikey.bin bl1.bin
> > > +  > ln -s ../bin/fip-hikey.bin fip.bin
> > >
> > > -python gen_loader.py -o l-loader.bin --img_loader=temp
> --img_bl1=bl1.bin
> > > -sudo bash -x generate_ptable.sh
> > > -python gen_loader.py -o ptable.img --img_prm_ptable=prm_ptable.img
> --img_sec_ptable=sec_ptable.img
> > > +  > arm-linux-gnueabihf-gcc -c -o start.o start.S
> > > +  > arm-linux-gnueabihf-gcc -c -o debug.o debug.S
> > > +  > arm-linux-gnueabihf-ld -Bstatic -Tl-loader.lds -Ttext 0xf9800800
> start.o debug.o -o loader
> > > +  > arm-linux-gnueabihf-objcopy -O binary loader temp
> > > +  > python gen_loader.py -o ../bin/l-loader.bin --img_loader=temp
> --img_bl1=bl1.bin
> > > +  > sudo bash -x generate_ptable.sh
> > > +  > python gen_loader.py -o ../bin/ptable.img
> --img_prm_ptable=./prm_ptable.img --img_sec_ptable=./sec_ptable.img
> > >
> > >  These instructions are adapted from
> > >  https://github.com/96boards/documentation/wiki/HiKeyUEFI
> > > @@ -62,37 +73,49 @@
> https://github.com/96boards/documentation/wiki/HiKeyUEFI
> > >  FLASHING
> > >  
> > >
> > > -1. Connect jumper J2 to go into recovery mode and flash l-loader.bin
> with
> > > -   fastboot using the hisi-idt.py utility
> > > +1. Connect the second jumper on J15 BOOT SEL, to go into recovery
> mode and flash l-loader.bin with
> > > +fastboot using the hisi-idt.py utility.
> > > +
> > > +  > cd ../
> > > +  > git clone https://github.com/96boards/burn-boot.git
> > >
> > > -> git clone https://github.com/96boards/burn-boot.git
> > > -> sudo python /home/griffinp/Software/hikey/burn-boot/hisi-idt.py -d
> /dev/ttyUSB0 --img1=/tmp/l-loader.bin
> > > +The command below assumes HiKey enumerated as the first USB serial
> port
> > > +  > sudo ./burn-boot/hisi-idt.py -d /dev/ttyUSB0
> --img1=./bin/l-loader.bin
> > >
> > > -2. Once LED 0 comes on solid,

Re: [U-Boot] [RFC] odroid DTB support

2015-10-13 Thread Przemyslaw Marczak


Hello,

On 10/13/2015 11:33 AM, Guillaume Gardet wrote:

Hi Przemyslaw, Tom,


Le 13/10/2015 11:11, Przemyslaw Marczak a écrit :

Hi Tom, Guillaume,

On 10/13/2015 09:37 AM, Guillaume Gardet wrote:



Le 12/10/2015 16:24, Tom Rini a écrit :

On Mon, Oct 12, 2015 at 10:54:04AM +0200, Guillaume Gardet wrote:

Hi,


Le 12/10/2015 01:45, Tom Rini a écrit :

On Fri, Oct 09, 2015 at 02:35:24PM +0200, Guillaume Gardet wrote:

Le 09/10/2015 14:23, Przemyslaw Marczak a écrit :

Hello Guillaume,

On 10/09/2015 02:11 PM, Guillaume Gardet wrote:

Hi Przemyslaw,

I would like to add DTB support for odroid board to be able to
boot
upstream kernel easily.

I see 2 ways to do it:
* Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support to set
'board_rev'
and 'board_name' env vars. Then, you need a 'findfdt' script to
check
'board_rev' and set fdtfile accordingly (as done for OMAP4 panda
board)
* Set fdtfile name directly (as done for rpi or igep00x0).

What would you prefer?


Guillaume



Is, that the reason of adding the boot script by your last patches?

No, we need a boot script, because this is the way we boot our
openSUSE images (we boot with an initrd and some special bootargs).

Hang on, exynos stuff uses the generic distro hooks.  Can you take a
look at doc/README.distro and see what openSUSE can hook into /
provide
some feedback on what needs doing?  Thanks!

This is true for odroid XU3 (Exynos5 based) but Odroid U3/X2 (Exynos4
based) has no generic distro hooks at the moment.

No, exynos-common pulls in generic distro.  And in the event of boards
that do not the answer is to pull in the generic distro framework.


It seems that exynos-common includes only "config_distro_defaults.h",
not "config_distro_bootcmd.h".
And "config_distro_bootcmd.h" is needed for generic distro boot flow. Am
I missing something?

Guillaume




Tom,
it's true that, exynos5-common.h defines the
CONFIG_EXTRA_ENV_SETTINGS, which provides "BOOTENV".
Odroid XU3 redefines CONFIG_EXTRA_ENV_SETTINGS, but in the fact it
uses the same settings, appended by some private env variables.

Guillaume,
You're right, Exynos4 boards doesn't use the generic distro boot
commands. And each board defines CONFIG_EXTRA_ENV_SETTINGS.


Thanks for clarification.



All boards works with the mainline kernel by default, so it's not a
high priority for us to switch it to common env, but will do this soon.


ok.



You can check the bootscript example in the directory:
 board/samsung/common/bootscripts/


Here, if $fdtfile is not defined, then it boots without it. This won't
work for us, since we need DTB (kernel multiplatform enabled).



Right, because it supports both fdt and non-fdt kernel images, the 
second one is to support old Hardkernel zImages.


Odroid XU3 defines fdtfile in board config extra envs, but the U3 sets 
it automatically on boot, since it supports both X2 and U3, the name 
depends on the board detection. This part of code is in set_board_info() 
in board/samsung/common/misc.c.


This is working well, if you have a minimum files on the boot partition 
(mmc 0:1):

- zImage
- exynos4412-odroidu3.dtb

then you will see:
---

Hit any key to stop autoboot: 0
reading exynos4412-odroidu3.dtb
46356 bytes read in 415 ms (108.4KiB/s)
reading uInitrd
** Unable to read file uInitrd **
reading zImage
5161952 bytes read in 685 ms (7.2 MiB/s)
Kernel image @ 0x40007fc0 [ 0x00 - 0x4ec3e0]
## Flattened Device Tree blob at 4080
Booting using the fdt blob at 0x4080
Loading Device Tree to 4fff1000, end 4513 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

---

After apply your patches and put the menioned boot.scr I can see this:

---
Hit any key to stop autoboot:0
reading boot.scr
3034 bytes read in 312 ms (8.8 KiB/s)
## Executing script at 4200
Found kernel image: zImage
reading exynos4412-odroidu3.dtb
46356 bytes read in 415 ms (108.4 KiB/s)
Warning! Booting without RAMDISK: uInitrd!
reading zImage
5161952 bytes read in 686 ms (7.2 MiB/s)
Kernel image @ 0x40007fc0 [ 0x00 - 0x4ec3e0 ]
## Flattened Device Tree blob at 4080
 Booting using the fdt blob at 0x4080
 Loading Device Tree to 4fff1000, end 4513 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
---

So this works for my setup. Maybe you have a problem with the filesystem?

Please check it manual if you can load dtb file, if not, maybe you 
should do mkfs.ext4/vfat on your boot partition to clean in, and then 
check again.




As temporary, your patch for Odroid can be applied to support the
boot.scr, but anyway it support mainline kernel and probably can boot
Ubuntu images.


Yes, please apply it to get boot.scr support until odroid switch to
generic boot system.



Yes, I will ack

Re: [U-Boot] [ELCE2015] Question about schedule

2015-10-13 Thread Bin Meng

Hi,

On Fri, Oct 2, 2015 at 6:34 AM, Tom Rini  wrote:
> On Thu, Oct 01, 2015 at 10:38:50AM +0200, Lukasz Majewski wrote:
>
>> Hi Tom,
>>
>> Is there any schedule for our ELCE2015 u-boot mini summit [1]?
>> To be more precise
>> - are know times when we will deliver our presentations?
>>
>>
>>
>> [1] - http://www.denx.de/wiki/U-Boot/SummitELCE2015
>
> So no, we don't have a formal schedule at this time.  My kind of plan at
> this point is to start off with the formal talks.  Then move into a
> "5 minute" status from the custodians present on where they're at in
> their area.  After that, sort out some priorities on Kconfig/DT.
>
> Oh, and I plan to try and have a Google Hangout up so that people that
> can't make it can at least watch and maybe chime in.
>
> --

Are there any slides presented in the summit available somewhere? Or
any video clips?

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

63 matches

Mail list logo