date:20130218

Dear Simon,

In message CAPnjgZ089gS0gLHBVBVARpX=awcyruumslgnir4hfkwzzls...@mail.gmail.com 
you wrote:
 
  I have started on it - I've ported over the Kbuild infrastructure into a
  dedicated 'kbuild' makefile which is called from the main makefile. This
  make modifications to the existing makefile very minimal
 
  Now it's just a case of building all the Kconfig files which is, to say the
  least, a massive task. I have a lot of other things going on, so
  unfortunately progress is slow
 
 I wonder how you got on with that? Any work-in-progress that could be
 used as a base? Want some help? It seems like a useful feature.

I also wonder if this has to be a one-step change-it-all-at-once
operation?  Maybe we can add the infrastructure in a neutral way, and
then start moving code to the Kconfig files step by step - similar to
what we did with moving Makefile rules out into boards.cfg ?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I have made mistakes, but have never made the mistake of  claiming  I
never made one. - James G. Bennet
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers.

2013-02-18 Thread Lukasz Majewski

Hi Tom,

 On Fri, Nov 30, 2012 at 08:01:12PM +0200, Pantelis Antoniou wrote:
 
  We didn't support upload/download larger than available memory.
  This is pretty bad when you have to update your root filesystem for
  example.
  
  This patch removes the limitation (and the crashes when you
  transfered any file larger than 4MB).
  On top of that reduces the huge dfu buffer from 4MB to just 64K,
  which was over the top.
  
  The sequence number is a 16 bit counter; make sure we
  handle rollover correctly. This fixes the wrong transfers for
  large ( 256MB) images.
  
  Also utilize a variable to handle initialization, so that we
  don't rely on just the counter sent by the host.
  
  Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
 
 To be clear, patches 1-8 are good and we should take, but this one
 means we can't use FAT/EXT* partitions without more work.  I would
 suggest that we set this part aside for a moment and perhaps limit
 transfers that are larget than RAM to RAW only where we can write in
 chunks today.
 

As fair as I remember, some additional work needs to be done with
composite.c file (to remove nasty #ifdefs). There was a problem with
newer version of dfu-utils (new handling of descriptors). 

It is on top of my queue, but I'm currently buried with other work and
need to postpone this.

However it is still on the back of my head and I push myself to fix
this.

-- 
Best regards,

Lukasz Majewski

Samsung RD Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3] Allow AM33xx boards to setup GPMC chipselects.

Expose the enable_gpmc_cs_config() function so AM33xx based boards can register 
GPMC chip selects.

Changes in V3:
- Fix line wrapping

Changes in V2:
- Indicate this is for AM33xx (not OMAP2)

Signed-off-by: Mark Jackson m...@newflow.co.uk
---
 arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h 
b/arch/arm/include/asm/arch-am33xx/sys_proto.h
index 588d8de..97ab60d 100644
--- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
+++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h
@@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M);
  void sdelay(unsigned long);
 void gpmc_init(void);
+void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 
base,
+u32 size);
 void omap_nand_switch_ecc(int);
 #endif
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH v2] Allow AM33xx boards to setup GPMC chipselects.

On 17/02/13 20:11, Peter Korsgaard wrote:
 Mark == Mark Jackson mpfj-l...@mimc.co.uk writes:
 
  Mark Expose the enable_gpmc_cs_config() function so AM33xx based boards can
  Mark register GPMC chip selects.
 
  Mark Changes in V2:
  Mark - Indicate this is for AM33xx (not OMAP2)
 
  Mark Signed-off-by: Mark Jackson m...@newflow.co.uk
  Mark ---
  Mark  arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++
  Mark  1 file changed, 2 insertions(+)
 
  Mark diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h
  Mark b/arch/arm/include/asm/arch-am33xx/sys_proto.h
  Mark index 588d8de..97ab60d 100644
  Mark --- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
  Mark +++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h
  Mark @@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M);
  Mark   void sdelay(unsigned long);
  Mark  void gpmc_init(void);
  Mark +void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs
  Mark *cs, u32 base,
  Mark +  u32 size);
 
 Seems like your mailer line wrapped the patch.

Oops ... resent.

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

Re: [U-Boot] [PATCH v1] Refactor linker-generated arrays

2013-02-18 Thread Andreas Bießmann

Hi Albert,

On 02/16/2013 07:20 PM, Albert ARIBAUD wrote:
 Hi Andreas,
 
 On Mon, 04 Feb 2013 13:41:09 +0100, Andreas Bießmann
 andreas.de...@googlemail.com wrote:
 
 Hi Albert,

 On 02.02.2013 18:02, Albert ARIBAUD wrote:

snip strict aliasing error on gcc-4.4

 I have dug into it and found a way to avoid GCC 4.4 or below to warn
 about aliasing, by replacing 'struct {}' with 'char[0]' as the
 0-byte-size type.
 
 I still have some warnings through, regarding some regions not being
 declared:
 
 avr32-ld:built in linker script:15: warning: memory region `FLASH' not
 declared
 avr32-ld:built in linker script:69: warning: memory region
 `CPUSRAM' not declared

I assume you use Mike Frysingers precompiled avr32 toolchain. I know
about that warnings and beware, these toolchain produce defective
binaries! The u-boot does not relocate itself properly with these newlib
toolchains (also the atmel provided one).

 It appears 'normal' in that without my patch, the same error occurs;
 but I'd prefer that you confirm whether you have the same warnings on
 your side.

It's ok so far, the arm-linux toolchain I have do not produce these
warnings. Kan you provide the patch so I will do a runtime test.

Best regards

Andreas Bießmann

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

Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12

2013-02-18 Thread Graeme Russ

Hi Wolfgang,

On Mon, Feb 18, 2013 at 8:59 PM, Wolfgang Denk w...@denx.de wrote:
 Dear Simon,

 In message 
 CAPnjgZ089gS0gLHBVBVARpX=awcyruumslgnir4hfkwzzls...@mail.gmail.com you 
 wrote:

  I have started on it - I've ported over the Kbuild infrastructure into a
  dedicated 'kbuild' makefile which is called from the main makefile. This
  make modifications to the existing makefile very minimal
 
  Now it's just a case of building all the Kconfig files which is, to say the
  least, a massive task. I have a lot of other things going on, so
  unfortunately progress is slow

 I wonder how you got on with that? Any work-in-progress that could be
 used as a base? Want some help? It seems like a useful feature.

 I also wonder if this has to be a one-step change-it-all-at-once
 operation?  Maybe we can add the infrastructure in a neutral way, and
 then start moving code to the Kconfig files step by step - similar to
 what we did with moving Makefile rules out into boards.cfg ?

Alas I do not have access to the code I was working on (study is
buried in stuff) and I really didn't get that far anyway. But, I got
as far as knowing it is possible to run both the current Makefile
infrastructure and the KConfig infrastructure in parallel. The trick
is to create additional Makefiles (Makefile.kc for example). You just
need to add stubs for the KConfig targets (menuconfig, xconfig, etc).

Once the core KConfig Make infrastructure is in place, it's simply (?)
a case of building all the KConfig files

Regards,

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

Re: [U-Boot] [PATCH v1] Refactor linker-generated arrays

2013-02-18 Thread Andreas Bießmann

On 02/18/2013 11:39 AM, Andreas Bießmann wrote:
 Hi Albert,
 
 On 02/16/2013 07:20 PM, Albert ARIBAUD wrote:

snip

 It's ok so far, the arm-linux toolchain I have do not produce these

I mean avr32-linux ... damn weekend ...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/3] arm:goni: Adjustment of configuration for goni target

2013-02-18 Thread a . wlodarczyk

From: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com

Signed-off-by: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Tested-by: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
---
Changes
This change encompasses set of adjustments in the configuration
of the u-boot in the include/configs/s5p_goni.h, particularly
change of rootfs type, change in kernel booting method and added DFU
support. All those changes are connected with adjusting of existing
goni configuration to latest changes in kernel.
---
 board/samsung/goni/goni.c  |7 +++
 include/configs/s5p_goni.h |   37 -
 2 files changed, 39 insertions(+), 5 deletions(-)

diff --git a/board/samsung/goni/goni.c b/board/samsung/goni/goni.c
index ff76963..3c53106 100644
--- a/board/samsung/goni/goni.c
+++ b/board/samsung/goni/goni.c
@@ -155,4 +155,11 @@ struct s3c_plat_otg_data s5pc110_otg_data = {
.regs_otg = S5PC110_OTG_BASE,
.usb_phy_ctrl = S5PC110_USB_PHY_CONTROL,
 };
+
+void board_usb_init(void)
+{
+   debug(USB_udc_probe\n);
+   s3c_udc_probe(s5pc110_otg_data);
+}
+
 #endif
diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h
index 56e8347..8a824c7 100644
--- a/include/configs/s5p_goni.h
+++ b/include/configs/s5p_goni.h
@@ -86,6 +86,17 @@
 #define CONFIG_CMD_ONENAND
 #define CONFIG_CMD_MTDPARTS
 #define CONFIG_CMD_MMC
+#define CONFIG_CMD_DFU
+
+/* USB Composite download gadget - g_dnl */
+#define CONFIG_USBDOWNLOAD_GADGET
+#define CONFIG_DFU_FUNCTION
+#define CONFIG_DFU_MMC
+
+/* USB Samsung's IDs */
+#define CONFIG_G_DNL_VENDOR_NUM 0x04E8
+#define CONFIG_G_DNL_PRODUCT_NUM 0x6601
+#define CONFIG_G_DNL_MANUFACTURER Samsung
 
 #define CONFIG_BOOTDELAY   1
 #define CONFIG_ZERO_BOOTDELAY_CHECK
@@ -105,9 +116,13 @@
,60m(qboot)\
,-(UBI)\0
 
+#define CONFIG_DFU_ALT \
+   u-boot mmc 80 400; \
+   uImage fat 0 2\0 \
+
 #define NORMAL_MTDPARTS_DEFAULT MTDPARTS_DEFAULT
 
-#define CONFIG_BOOTCOMMAND run ubifsboot
+#define CONFIG_BOOTCOMMAND run mmcboot
 
 #define CONFIG_DEFAULT_CONSOLE console=ttySAC2,115200n8\0
 
@@ -137,7 +152,7 @@
onenand erase 0x0156 0x1eaa; \
onenand write 0x3200 0x126 0x8C\0 \
bootk= \
-   onenand read 0x30007FC0 0xc0 0x60; \
+   run loaduimage; \
bootm 0x30007FC0\0 \
flashboot= \
set bootargs root=/dev/mtdblock${bootblock}  \
@@ -156,21 +171,28 @@
set bootargs  CONFIG_RAMDISK_BOOT \
 initrd=0x3300,8M ramdisk=8192\0 \
mmcboot= \
-   set bootargs root=${mmcblk} rootfstype=${rootfstype} \
+   set bootargs root=/dev/mmcblk${mmcdev}p${mmcrootpart}  \
+   rootfstype=${rootfstype} \
CONFIG_UBI_MTD  ${opts} ${lcdinfo}  \
CONFIG_COMMON_BOOT ; run bootk\0 \
boottrace=setenv opts initcall_debug; run bootcmd\0 \
bootchart=set opts init=/sbin/bootchartd; run bootcmd\0 \
verify=n\0 \
-   rootfstype=cramfs\0 \
+   rootfstype=ext4\0 \
console= CONFIG_DEFAULT_CONSOLE \
mtdparts= MTDPARTS_DEFAULT \
meminfo=mem=80M mem=256M@0x4000 mem=128M@0x5000\0 \
+   loaduimage=fatload mmc ${mmcdev}:${mmcbootpart} 0x30007FC0 uImage\0 \
+   mmcdev=0\0 \
+   mmcbootpart=2\0 \
+   mmcrootpart=5\0 \
mmcblk=/dev/mmcblk1p1\0 \
bootblock=9\0 \
ubiblock=8\0 \
ubi=enabled\0 \
-   opts=always_resume=1
+   opts=always_resume=1\0 \
+   dfu_alt_info= CONFIG_DFU_ALT
+
 
 /* Miscellaneous configurable options */
 #define CONFIG_SYS_LONGHELP/* undef to save memory */
@@ -211,6 +233,10 @@
 
 #define CONFIG_DOS_PARTITION   1
 
+/* FAT */
+#define CONFIG_CMD_FAT
+#define CONFIG_FAT_WRITE
+
 #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_LOAD_ADDR - 0x100)
 
 #define CONFIG_SYS_CACHELINE_SIZE   64
@@ -233,5 +259,6 @@
 #define CONFIG_USB_GADGET
 #define CONFIG_USB_GADGET_S3C_UDC_OTG
 #define CONFIG_USB_GADGET_DUALSPEED
+#define CONFIG_USB_GADGET_VBUS_DRAW 2
 
 #endif /* __CONFIG_H */
-- 
1.7.1

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

[U-Boot] [PATCH 2/3] arm:goni:Change in mmc memory partitioning

2013-02-18 Thread a . wlodarczyk

From: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com

Signed-off-by: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Tested-by: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
---
Changes
This item includes the following changes for goni target:
Add GPT command
Add definition of partitions for GPT
Remove MTD command
---
 include/configs/s5p_goni.h |   44 ++--
 1 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h
index 8a824c7..e8f2639 100644
--- a/include/configs/s5p_goni.h
+++ b/include/configs/s5p_goni.h
@@ -84,9 +84,9 @@
 #define CONFIG_CMD_CACHE
 #define CONFIG_CMD_REGINFO
 #define CONFIG_CMD_ONENAND
-#define CONFIG_CMD_MTDPARTS
 #define CONFIG_CMD_MMC
 #define CONFIG_CMD_DFU
+#define CONFIG_CMD_GPT
 
 /* USB Composite download gadget - g_dnl */
 #define CONFIG_USBDOWNLOAD_GADGET
@@ -101,26 +101,30 @@
 #define CONFIG_BOOTDELAY   1
 #define CONFIG_ZERO_BOOTDELAY_CHECK
 
-#define CONFIG_MTD_DEVICE
-#define CONFIG_MTD_PARTITIONS
-
-/* Actual modem binary size is 16MiB. Add 2MiB for bad block handling */
-#define MTDIDS_DEFAULT onenand0=samsung-onenand
-#define MTDPARTS_DEFAULT   mtdparts=samsung-onenand:1m(bootloader)\
-   ,256k(params)\
-   ,2816k(config)\
-   ,8m(csa)\
-   ,7m(kernel)\
-   ,1m(log)\
-   ,12m(modem)\
-   ,60m(qboot)\
-   ,-(UBI)\0
-
 #define CONFIG_DFU_ALT \
u-boot mmc 80 400; \
uImage fat 0 2\0 \
 
-#define NORMAL_MTDPARTS_DEFAULT MTDPARTS_DEFAULT
+/* partitions definitions */
+#define PARTS_CSA  csa-mmc
+#define PARTS_BOOTLOADER   u-boot
+#define PARTS_BOOT boot
+#define PARTS_ROOT platform
+#define PARTS_DATA data
+#define PARTS_CSC  csc
+#define PARTS_UMS  ums
+
+#define PARTS_DEFAULT \
+   uuid_disk=${uuid_gpt_disk}; \
+   name=PARTS_CSA,size=8MiB,uuid=${uuid_gpt_PARTS_CSA}; \
+   name=PARTS_BOOTLOADER,size=60MiB, \
+   uuid=${uuid_gpt_PARTS_BOOTLOADER}; \
+   name=PARTS_BOOT,size=100MiB,uuid=${uuid_gpt_PARTS_BOOT}; \
+   name=PARTS_ROOT,size=1GiB,uuid=${uuid_gpt_PARTS_ROOT}; \
+   name=PARTS_DATA,size=3GiB,uuid=${uuid_gpt_PARTS_DATA}; \
+   name=PARTS_CSC,size=150MiB,uuid=${uuid_gpt_PARTS_CSC}; \
+   name=PARTS_UMS,size=-,uuid=${uuid_gpt_PARTS_UMS}\0 \
+
 
 #define CONFIG_BOOTCOMMAND run mmcboot
 
@@ -180,12 +184,12 @@
verify=n\0 \
rootfstype=ext4\0 \
console= CONFIG_DEFAULT_CONSOLE \
-   mtdparts= MTDPARTS_DEFAULT \
meminfo=mem=80M mem=256M@0x4000 mem=128M@0x5000\0 \
loaduimage=fatload mmc ${mmcdev}:${mmcbootpart} 0x30007FC0 uImage\0 \
mmcdev=0\0 \
mmcbootpart=2\0 \
mmcrootpart=5\0 \
+   partitions= PARTS_DEFAULT \
mmcblk=/dev/mmcblk1p1\0 \
bootblock=9\0 \
ubiblock=8\0 \
@@ -237,6 +241,10 @@
 #define CONFIG_CMD_FAT
 #define CONFIG_FAT_WRITE
 
+/* GPT */
+#define CONFIG_EFI_PARTITION
+#define CONFIG_PARTITION_UUIDS
+
 #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_LOAD_ADDR - 0x100)
 
 #define CONFIG_SYS_CACHELINE_SIZE   64
-- 
1.7.1

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

[U-Boot] [PATCH 3/3] arm:goni: Add support for USB mass storage

2013-02-18 Thread a . wlodarczyk

From: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com

Signed-off-by: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Tested-by: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
---
Changes
Switch on USB gadget mass storage and ums command in
configuration for goni target; Add code supporting USB gadget
mass storage in board/samsung/goni/goni.c
---
Depends on implementation of USB mass storage
for Samsung.
http://patchwork.ozlabs.org/patch/219744/
http://patchwork.ozlabs.org/patch/219746/
http://patchwork.ozlabs.org/patch/219745/
---
 board/samsung/goni/goni.c  |   68 
 include/configs/s5p_goni.h |5 +++
 2 files changed, 73 insertions(+), 0 deletions(-)

diff --git a/board/samsung/goni/goni.c b/board/samsung/goni/goni.c
index 3c53106..a09daca 100644
--- a/board/samsung/goni/goni.c
+++ b/board/samsung/goni/goni.c
@@ -29,6 +29,7 @@
 #include usb/s3c_udc.h
 #include asm/arch/cpu.h
 #include power/max8998_pmic.h
+#include usb_mass_storage.h
 DECLARE_GLOBAL_DATA_PTR;
 
 static struct s5pc110_gpio *s5pc110_gpio;
@@ -163,3 +164,70 @@ void board_usb_init(void)
 }
 
 #endif
+
+#ifdef CONFIG_USB_GADGET_MASS_STORAGE
+static int ums_read_sector(struct ums_device *ums_dev,
+   ulong start, lbaint_t blkcnt, void *buf)
+{
+   if (ums_dev-mmc-block_dev.block_read(ums_dev-dev_num,
+   start + ums_dev-offset, blkcnt, buf) != blkcnt)
+   return -1;
+
+   return 0;
+}
+
+static int ums_write_sector(struct ums_device *ums_dev,
+   ulong start, lbaint_t blkcnt, const void *buf)
+{
+   if (ums_dev-mmc-block_dev.block_write(ums_dev-dev_num,
+   start + ums_dev-offset, blkcnt, buf) != blkcnt)
+   return -1;
+
+   return 0;
+}
+
+static void ums_get_capacity(struct ums_device *ums_dev,
+   long long int *capacity)
+{
+   long long int tmp_capacity;
+
+   tmp_capacity = (long long int) ((ums_dev-offset + ums_dev-part_size)
+   * SECTOR_SIZE);
+   *capacity = ums_dev-mmc-capacity - tmp_capacity;
+}
+
+static struct ums_board_info ums_board = {
+   .read_sector = ums_read_sector,
+   .write_sector = ums_write_sector,
+   .get_capacity = ums_get_capacity,
+   .name = GONI UMS disk,
+   .ums_dev = {
+   .mmc = NULL,
+   .dev_num = 0,
+   .offset = 0,
+   .part_size = 0.
+   },
+};
+
+struct ums_board_info *board_ums_init(unsigned int dev_num, unsigned int 
offset,
+   unsigned int part_size)
+{
+   struct mmc *mmc;
+
+   mmc = find_mmc_device(dev_num);
+   /* mmc initialization is necessary prior to the ums command usage
+* due to fact that on goni target environment is read from oneNand
+* memory, so the mmc remains uninitialized whenu-boot prompt appears
+* */
+   if (!mmc || mmc_init(mmc))
+   return NULL;
+
+   ums_board.ums_dev.mmc = mmc;
+   ums_board.ums_dev.dev_num = dev_num;
+   ums_board.ums_dev.offset = offset;
+   ums_board.ums_dev.part_size = part_size;
+
+   return ums_board;
+}
+
+#endif
diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h
index e8f2639..1cfbb88 100644
--- a/include/configs/s5p_goni.h
+++ b/include/configs/s5p_goni.h
@@ -269,4 +269,9 @@
 #define CONFIG_USB_GADGET_DUALSPEED
 #define CONFIG_USB_GADGET_VBUS_DRAW 2
 
+#define CONFIG_CMD_USB_MASS_STORAGE
+#if defined(CONFIG_CMD_USB_MASS_STORAGE)
+#define CONFIG_USB_GADGET_MASS_STORAGE
+#endif
+
 #endif /* __CONFIG_H */
-- 
1.7.1

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

Re: [U-Boot] [PATCH v3] Allow AM33xx boards to setup GPMC chipselects.

2013-02-18 Thread Peter Korsgaard

 Mark == Mark Jackson mpfj-l...@mimc.co.uk writes:

 Mark Expose the enable_gpmc_cs_config() function so AM33xx based boards can 
register GPMC chip selects.
 Mark Changes in V3:
 Mark - Fix line wrapping

 Mark Changes in V2:
 Mark - Indicate this is for AM33xx (not OMAP2)

 Mark Signed-off-by: Mark Jackson m...@newflow.co.uk
 Mark ---
 Mark  arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++
 Mark  1 file changed, 2 insertions(+)

 Mark diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h 
b/arch/arm/include/asm/arch-am33xx/sys_proto.h
 Mark index 588d8de..97ab60d 100644
 Mark --- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
 Mark +++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h
 Mark @@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M);
 Mark   void sdelay(unsigned long);
 Mark  void gpmc_init(void);
 Mark +void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, 
u32 base,
 Mark +u32 size);

Checkpatch still complains. How about wrapping after *cs, and properly
aligning the next line?

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

[U-Boot] [PATCH v4] Allow AM33xx boards to setup GPMC chipselects.

Expose the enable_gpmc_cs_config() function so AM33xx based boards can register 
GPMC chip selects.

Changes in V4:
- Fix checkpatch errors (TAB - space mangling)

Changes in V3:
- Fix line wrapping

Changes in V2:
- Indicate this is for AM33xx (not OMAP2)

Signed-off-by: Mark Jackson m...@newflow.co.uk
---
 arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h 
b/arch/arm/include/asm/arch-am33xx/sys_proto.h
index 588d8de..97ab60d 100644
--- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
+++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h
@@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M);
 
 void sdelay(unsigned long);
 void gpmc_init(void);
+void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 
base,
+   u32 size);
 void omap_nand_switch_ecc(int);
 #endif
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH v3] Allow AM33xx boards to setup GPMC chipselects.

On 18/02/13 11:01, Peter Korsgaard wrote:
 Mark == Mark Jackson mpfj-l...@mimc.co.uk writes:
 
  Mark Expose the enable_gpmc_cs_config() function so AM33xx based boards can 
 register GPMC chip selects.
  Mark Changes in V3:
  Mark - Fix line wrapping
 
  Mark Changes in V2:
  Mark - Indicate this is for AM33xx (not OMAP2)
 
  Mark Signed-off-by: Mark Jackson m...@newflow.co.uk
  Mark ---
  Mark  arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++
  Mark  1 file changed, 2 insertions(+)
 
  Mark diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h 
 b/arch/arm/include/asm/arch-am33xx/sys_proto.h
  Mark index 588d8de..97ab60d 100644
  Mark --- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
  Mark +++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h
  Mark @@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M);
  Mark   void sdelay(unsigned long);
  Mark  void gpmc_init(void);
  Mark +void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs 
 *cs, u32 base,
  Mark +u32 size);
 
 Checkpatch still complains. How about wrapping after *cs, and properly
 aligning the next line?
 

G ... stupid mailer programs !!

Hopefully v4 is now correct ...

Mark J.

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

Re: [U-Boot] [PATCH 16/20] Roll crc32 into hash infrastructure

Dear Tom,

In message 51216721.1010...@ti.com you wrote:

 There's another thread I don't have yet (and I don't have this one in
 gmail yet even).  But, I am OK with custodians using their repos, but
 not the master branch, for unrelated but otherwise good patches. I'm
 also fine with patchwork bundles.  I suppose we could use the staging
 repository for these changes instead.

What I mostly object about there is that these patches would go into
mainline basicly unreviewed, as patch submission and pull request is
all done from a single person, with no other feedback on the patches
at all.  And this affects a lot of common code...

Actually, I see this change when pulling u-boot-x86.git/master:

- bloat-o-meter u-boot-before u-boot
add/remove: 9/0 grow/shrink: 3/14 up/down: 1006/-560 (446)
function old new   delta
hash_command   - 424+424
strncasecmp- 156+156
simple_itoa- 104+104
crc32_wd_buf   -  76 +76
setenv_hex -  68 +68
setenv_ulong   -  52 +52
strcasecmp -  36 +36
do_mem_loopw 304 328 +24
static.local   -  22 +22
do_mem_loop  268 288 +20
hash_algo  -  16 +16
do_mem_cmp   332 340  +8
do_mem_mw224 220  -4
set_working_fdt_addr  72  52 -20
load_serial_ymodem   300 280 -20
load_serial  512 492 -20
index_partitions 200 180 -20
do_load_serial_bin  18441824 -20
do_load  468 448 -20
do_jffs2_fsload  320 300 -20
do_imgextract636 592 -44
NetLoop  832 788 -44
do_mem_cp312 252 -60
do_bootm12441180 -64
do_mem_crc   188  88-100
do_mem_mtest14361332-104


So there are changes all over the place, including a growth of the
memory footprint.  I think this needs at least minimal review.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Time is an illusion perpetrated by the manufacturers of space.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4] Allow AM33xx boards to setup GPMC chipselects.

2013-02-18 Thread Peter Korsgaard

 Mark == Mark Jackson mpfj-l...@mimc.co.uk writes:

 Mark Expose the enable_gpmc_cs_config() function so AM33xx based boards can 
register GPMC chip selects.

Acked-by: Peter Korsgaard jac...@sunsite.dk

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

Re: [U-Boot] [PATCH 2/4 V3] EXYNOS5: Add gpio pin numbering feature

2013-02-18 Thread Rajeshwari Birje

Hi Simon,

Thank you for comments.

On Sun, Feb 17, 2013 at 11:51 AM, Simon Glass s...@chromium.org wrote:
 Hi Rajeshwari,

 On Thu, Feb 7, 2013 at 4:00 AM, Rajeshwari Shinde
 rajeshwar...@samsung.com wrote:
 This patch adds support for gpio pin numbering support on EXYNOS5
 pinmux.

 Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
 Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com

 If we are going to have GPIO numbering it needs to be continuous. The
 scheme in the Chrome OS tree does this.
-Okay

 It's great to have gpio_cfg_pin() but I can't see the actual definition.
The definition for same is in S5P: GPIO: Add generic pin numbering API's
patch of same patch set.

 Also please carefully check that the GPIO numbers are all correct - it
 doesn't look right to me.
I had verified for each value. Will recheck the same.

 Also for the benefit of people using FDT who still don't have symbols
 and who don't yet have proper GPIO support in U-Boot (phandle to bank
 + number within bank, as in the kernel), can you please annotate the
 first enum value of each GPIO group (A, B, C) with its hex value? That
 will also provide a check that things are correct.
So you want me to assign each bank GPIO group with its Base adress in hex?

One more doubt as per Minkyu comment to support the same for EXYNOS4
and avoid error do we have to append EXYNOS5_ at the start of enum
values? Or anyother solution you would suggest?
 Regards,
 Simon

 ---
 Changes in V2:
 - none.
 Changes in V3:
 - none.
  arch/arm/cpu/armv7/exynos/pinmux.c  |  148 +
  arch/arm/include/asm/arch-exynos/gpio.h |  360 
 ++-
  2 files changed, 413 insertions(+), 95 deletions(-)

 diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c 
 b/arch/arm/cpu/armv7/exynos/pinmux.c
 index bd499b4..c79d58e 100644
 --- a/arch/arm/cpu/armv7/exynos/pinmux.c
 +++ b/arch/arm/cpu/armv7/exynos/pinmux.c
 @@ -29,89 +29,77 @@

  static void exynos5_uart_config(int peripheral)
  {
 -   struct exynos5_gpio_part1 *gpio1 =
 -   (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1();
 -   struct s5p_gpio_bank *bank;
 int i, start, count;

 switch (peripheral) {
 case PERIPH_ID_UART0:
 -   bank = gpio1-a0;
 -   start = 0;
 +   start = GPIO_A00;
 count = 4;
 break;
 case PERIPH_ID_UART1:
 -   bank = gpio1-d0;
 -   start = 0;
 +   start = GPIO_D00;
 count = 4;
 break;
 case PERIPH_ID_UART2:
 -   bank = gpio1-a1;
 -   start = 0;
 +   start = GPIO_A10;
 count = 4;
 break;
 case PERIPH_ID_UART3:
 -   bank = gpio1-a1;
 -   start = 4;
 +   start = GPIO_A14;
 count = 2;
 break;
 }
 for (i = start; i  start + count; i++) {
 -   s5p_gpio_set_pull(bank, i, GPIO_PULL_NONE);
 -   s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2));
 +   gpio_set_pull(i, GPIO_PULL_NONE);
 +   gpio_cfg_pin(i, GPIO_FUNC(0x2));
 }
  }

  static int exynos5_mmc_config(int peripheral, int flags)
  {
 -   struct exynos5_gpio_part1 *gpio1 =
 -   (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1();
 -   struct s5p_gpio_bank *bank, *bank_ext;
 -   int i, start = 0, gpio_func = 0;
 +   int i, start, start_ext, gpio_func = 0;

 switch (peripheral) {
 case PERIPH_ID_SDMMC0:
 -   bank = gpio1-c0;
 -   bank_ext = gpio1-c1;
 -   start = 0;
 +   start = GPIO_C00;
 +   start_ext = GPIO_C10;
 gpio_func = GPIO_FUNC(0x2);
 break;
 case PERIPH_ID_SDMMC1:
 -   bank = gpio1-c2;
 -   bank_ext = NULL;
 +   start = GPIO_C20;
 +   start_ext = 0;
 break;
 case PERIPH_ID_SDMMC2:
 -   bank = gpio1-c3;
 -   bank_ext = gpio1-c4;
 -   start = 3;
 +   start = GPIO_C30;
 +   start_ext = GPIO_C43;
 gpio_func = GPIO_FUNC(0x3);
 break;
 case PERIPH_ID_SDMMC3:
 -   bank = gpio1-c4;
 -   bank_ext = NULL;
 +   start = GPIO_C40;
 +   start_ext = 0;
 break;
 }
 -   if ((flags  PINMUX_FLAG_8BIT_MODE)  !bank_ext) {
 +   if ((flags  PINMUX_FLAG_8BIT_MODE)  !start_ext) {
 debug(SDMMC device %d does not support 8bit mode,
 peripheral);
 return -1;
 }
 if (flags  PINMUX_FLAG_8BIT_MODE) {
 -   for (i = start; i = (start + 3); i++) {
 -   s5p_gpio_cfg_pin(bank_ext, i, gpio_func);
 -

Re: [U-Boot] [PATCH v7 16/19] arm926ejs: Remove deprecated and now unused NAND SPL

On Sunday, February 17, 2013 5:25:33 PM, Benoît Thébaudeau wrote:
 On Sunday, February 17, 2013 5:08:00 PM, Albert ARIBAUD wrote:
  Hi Albert,
  
  On Sun, 17 Feb 2013 17:04:54 +0100, Albert ARIBAUD
  albert.u.b...@aribaud.net wrote:
  
   Hi Benoît,
   
   On Sun, 17 Feb 2013 16:51:37 +0100 (CET), Benoît Thébaudeau
   benoit.thebaud...@advansee.com wrote:
   
Hi Albert, Tom, Zhong,

On Friday, February 15, 2013 9:54:22 PM, Benoît Thébaudeau wrote:
 Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
 ---
 Changes in v7: None
 Changes in v6:
  - New patch.
 
 Changes in v5: None
 Changes in v4: None
 Changes in v3: None
 Changes in v2: None
 
  arch/arm/cpu/arm926ejs/start.S |   10 --
  1 file changed, 10 deletions(-)

I would like to get your feedback regarding the status of the Samsung
SMDK6400
board:
 - It is not in boards.cfg, so, according to commit 1285a28, support
 for
 it
   should already have been removed a long time ago. It also seems to
   be
   the
   only board remaining in the main Makefile.
 - It uses the deprecated NAND SPL.
 - MAKEALL does not test its build, which has been broken for a while.
 - If it were removed or fixed, ARM1176's start.S' relocate_code()
 could
 be made
   identical to all the other implementations of this function, so all
   this
   duplicated code could be moved to a common location like crt0.S.
   Besides
   that, it would be possible to completely get rid of the legacy NAND
   SPL on
   ARM.

I have no intention of fixing this board, but dropping it and cleaning
up
ARM
after that would be easy.
   
   Cc:ing the board maintainers, as they should be the first ones to be
   asked whether they intend to bring the board into boards.cfg and fix
   it, or whether it should be dropped.
  
  Scratch this: correct maintainer CC:ed now
 
 Yes, I had already Cc'ed Zhong.

Adding Mike to Cc as he had been assigned the board migration job to boards.cfg,
due for v2012.03. Perhaps he got some information from the SMDK6400 maintainer.

Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding

On Sunday, February 17, 2013 5:16:49 PM, Benoît Thébaudeau wrote:
 Hi Poonam, Andy,
 
 On Friday, February 15, 2013 9:54:19 PM, Benoît Thébaudeau wrote:
  PAD_TO is not a generic SPL configuration option, so use
  CONFIG_SPL_MAX_SIZE
  instead.
  
  We want to use --pad-to with a size, but this option expects an address, so
  use
  u-boot-spl.bin instead of u-boot-spl as the input file in order to get
  addresses
  starting at 0.
  
  Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
  ---
  Changes in v7:
   - Use u-boot-spl.bin instead of u-boot-spl in order to avoid having to use
 --change-addresses.
  
  Changes in v6:
   - Fix size passed to --pad-to thanks to --change-addresses.
  
  Changes in v5: None
  Changes in v4:
   - New patch.
  
  Changes in v3: None
  Changes in v2: None
  
   Makefile |3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)
  
  diff --git a/Makefile b/Makefile
  index a8c7b7b..317dffc 100644
  --- a/Makefile
  +++ b/Makefile
  @@ -486,7 +486,8 @@ $(obj)u-boot.dis:   $(obj)u-boot
  $(OBJDUMP) -d $  $@
   
   $(obj)u-boot-with-spl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
  -   $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary
  $(obj)spl/u-boot-spl
  $(obj)spl/u-boot-spl-pad.bin
  +   $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(CONFIG_SPL_MAX_SIZE) \
  +   -I binary -O binary $ $(obj)spl/u-boot-spl-pad.bin
  cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin  $@
  rm $(obj)spl/u-boot-spl-pad.bin
 
 I would like to let you know what is going on, and to get your feedback for
 this
 patch.
 
 include/configs/p1_p2_rdb_pc.h seems to be the only current user of
 u-boot-with-spl.bin, triggered for example by the P2020RDB-PC_NAND config.
 
 Before this patch, PAD_TO was used, but there is no such definition for this
 board for generic SPL, so this board seems broken, all the more none of the
 various values defined for CONFIG_SYS_TEXT_BASE relatively to
 CONFIG_SPL_TEXT_BASE would be compatible with an image built by appending
 U-Boot
 to the generic SPL. Can you confirm?
 
 This patch won't fix this board, but I want to make sure that it won't be an
 issue for you now or later.

I'm also wondering why there is both generic SPL for NAND and legacy NAND SPL
for p1_p2_rdb, all the more the NAND SPL version does not seem to be used in
boards.cfg.

Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] How to generate an interrupt from u-boot

2013-02-18 Thread VISWANADHULA BALAJI

Hi,

Iam working on the samsung smdkv310 based soc. I want to generate an
interrupt from the timer. Is it possible to service an interrupts at u-boot
level. Smdkv310 board is having the GIC controller. Is there any patches to
initialise the GIC(Generic interrupt controller).

Please do needful.

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

Re: [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers.

2013-02-18 Thread Marek Vasut

Dear Lukasz Majewski,

 Hi Tom,
 
  On Fri, Nov 30, 2012 at 08:01:12PM +0200, Pantelis Antoniou wrote:
   We didn't support upload/download larger than available memory.
   This is pretty bad when you have to update your root filesystem for
   example.
   
   This patch removes the limitation (and the crashes when you
   transfered any file larger than 4MB).
   On top of that reduces the huge dfu buffer from 4MB to just 64K,
   which was over the top.
   
   The sequence number is a 16 bit counter; make sure we
   handle rollover correctly. This fixes the wrong transfers for
   large ( 256MB) images.
   
   Also utilize a variable to handle initialization, so that we
   don't rely on just the counter sent by the host.
   
   Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
  
  To be clear, patches 1-8 are good and we should take, but this one
  means we can't use FAT/EXT* partitions without more work.  I would
  suggest that we set this part aside for a moment and perhaps limit
  transfers that are larget than RAM to RAW only where we can write in
  chunks today.
 
 As fair as I remember, some additional work needs to be done with
 composite.c file (to remove nasty #ifdefs). There was a problem with
 newer version of dfu-utils (new handling of descriptors).
 
 It is on top of my queue, but I'm currently buried with other work and
 need to postpone this.
 
 However it is still on the back of my head and I push myself to fix
 this.

Guys, can you just tell me what I should drop from u-boot-usb to submit a 
pullRQ 
with the rest ? Otherwise I'll drop the whole DFU stuff and be done with it.

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12

2013-02-18 Thread Marek Vasut

Dear Graeme Russ,

 Hi Wolfgang,
 
 On Mon, Feb 18, 2013 at 8:59 PM, Wolfgang Denk w...@denx.de wrote:
  Dear Simon,
  
  In message CAPnjgZ089gS0gLHBVBVARpX=awcyRUUmSLGNiR4HFkwZZLsL-
g...@mail.gmail.com you wrote:
   I have started on it - I've ported over the Kbuild infrastructure into
   a dedicated 'kbuild' makefile which is called from the main makefile.
   This make modifications to the existing makefile very minimal
   
   Now it's just a case of building all the Kconfig files which is, to
   say the least, a massive task. I have a lot of other things going on,
   so unfortunately progress is slow
  
  I wonder how you got on with that? Any work-in-progress that could be
  used as a base? Want some help? It seems like a useful feature.
  
  I also wonder if this has to be a one-step change-it-all-at-once
  operation?  Maybe we can add the infrastructure in a neutral way, and
  then start moving code to the Kconfig files step by step - similar to
  what we did with moving Makefile rules out into boards.cfg ?
 
 Alas I do not have access to the code I was working on (study is
 buried in stuff) and I really didn't get that far anyway. But, I got
 as far as knowing it is possible to run both the current Makefile
 infrastructure and the KConfig infrastructure in parallel. The trick
 is to create additional Makefiles (Makefile.kc for example). You just
 need to add stubs for the KConfig targets (menuconfig, xconfig, etc).
 
 Once the core KConfig Make infrastructure is in place, it's simply (?)
 a case of building all the KConfig files

True, we can add Kconfig first and Kbuild afterwards.

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] SMDK5250: FDT: Retrieve board model via DT

2013-02-18 Thread Rajeshwari Shinde

Print out the board model by parsing the device tree file.

Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
 board/samsung/smdk5250/smdk5250.c |   11 ++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/board/samsung/smdk5250/smdk5250.c 
b/board/samsung/smdk5250/smdk5250.c
index 6f6f2c2..0097b3f 100644
--- a/board/samsung/smdk5250/smdk5250.c
+++ b/board/samsung/smdk5250/smdk5250.c
@@ -336,8 +336,17 @@ int board_eth_init(bd_t *bis)
 #ifdef CONFIG_DISPLAY_BOARDINFO
 int checkboard(void)
 {
-   printf(\nBoard: SMDK5250\n);
+#ifdef CONFIG_OF_CONTROL
+   const char *board_name;
 
+   board_name = fdt_getprop(gd-fdt_blob, 0, model, NULL);
+   if (board_name == NULL)
+   printf(\nUnknown Board\n);
+   else
+   printf(\nBoard: %s\n, board_name);
+#else
+   printf(\nBoard: SMDK5250\n);
+#endif
return 0;
 }
 #endif
-- 
1.7.4.4

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

Re: [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers.

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/18/2013 05:01 AM, Lukasz Majewski wrote:
 Hi Tom,
 
 On Fri, Nov 30, 2012 at 08:01:12PM +0200, Pantelis Antoniou
 wrote:
 
 We didn't support upload/download larger than available
 memory. This is pretty bad when you have to update your root
 filesystem for example.
 
 This patch removes the limitation (and the crashes when you 
 transfered any file larger than 4MB). On top of that reduces
 the huge dfu buffer from 4MB to just 64K, which was over the
 top.
 
 The sequence number is a 16 bit counter; make sure we handle
 rollover correctly. This fixes the wrong transfers for large (
 256MB) images.
 
 Also utilize a variable to handle initialization, so that we 
 don't rely on just the counter sent by the host.
 
 Signed-off-by: Pantelis Antoniou
 pa...@antoniou-consulting.com
 
 To be clear, patches 1-8 are good and we should take, but this
 one means we can't use FAT/EXT* partitions without more work.  I
 would suggest that we set this part aside for a moment and
 perhaps limit transfers that are larget than RAM to RAW only
 where we can write in chunks today.
 
 
 As fair as I remember, some additional work needs to be done with 
 composite.c file (to remove nasty #ifdefs). There was a problem
 with newer version of dfu-utils (new handling of descriptors).

I thought it ended up being resolved.  I'll have to re-read the thread
again I guess.

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRIjHWAAoJENk4IS6UOR1WEs0P/07uTOJRh+8hBgnpcXwBZ8zD
keEtN8vHs3JYOjW1k6styAFNGXy+PBhOJNOIx6ClsdTvCRU8FtGh09SZUAYBrZEj
5WbfqGaeFWY9bpgAhwsNRMXD3mcHq3EGvRm0Ga+ep/EDFd+lgswvfx9EtgxkOjy5
MM0G4BnjwJxWM4DW2Wkk/rXI7Xy8jpVn3abUPLva4iY8X5L6ez9GXp/VNv6nCoNI
i+LuGXEnv7BsO9g+x5pvYlnQeMC5BPC7vKNMq9dj8o6MZ/Q7jCQkqz85GIqyDTta
UByzr24G4xK5m7V0iFSlV7fnRHjcg7q+uAB6u2YSibssyibIuLoJA2VdiGZqp8oH
OUBQ3L2v84QHhcKTQm/yqcQ4FWHaHQ369v4QwnON29yFqtb7Z/M3GEKCqPbPIlge
eg+Bb8fymdjELQT4Bo0+EkydlvaQOhkSjxBlVa9GTkRyoPxpE7RNY5lgciseVZO4
hKG/Xfnce7fpQNoE8fJCWRslQp3sOiDE65gFRzNJN/15i+my+xYmN5HiNPWhcgmI
2EVJGx9/LXqZ6yGZh8bQCC3yvNnshG+cm4qAj58ytkLjVSVnsd7yxFYbexUTEJ0q
YwOmE/72cgL/3IzpRUmh4o5G+uFJqhFx7zndMQyItdTN09mhZu7dCUtgud66A1Qg
wUiQkeF4sWubUMIpYUvz
=L9X2
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 6/6] i.MX6: Add DDR controller registers

2013-02-18 Thread Eric Nelson


Thanks for the review Jason,

On 02/17/2013 10:16 PM, Liu Hui-R64343 wrote:

-Original Message-
From: Eric Nelson [mailto:eric.nel...@boundarydevices.com]
Sent: Monday, February 18, 2013 3:24 AM
To: u-boot@lists.denx.de
Cc: sba...@denx.de; Liu Hui-R64343; Estevam Fabio-R49496;
troy.ki...@boundarydevices.com; Eric Nelson
Subject: [PATCH 6/6] i.MX6: Add DDR controller registers

Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
arch/arm/include/asm/arch-mx6/mx6-ddr.h   |   85
+
arch/arm/include/asm/arch-mx6/mx6dl-ddr.h |   71

arch/arm/include/asm/arch-mx6/mx6q-ddr.h  |   69
+++
3 files changed, 225 insertions(+)
create mode 100644 arch/arm/include/asm/arch-mx6/mx6-ddr.h
create mode 100644 arch/arm/include/asm/arch-mx6/mx6dl-ddr.h
create mode 100644 arch/arm/include/asm/arch-mx6/mx6q-ddr.h


I did not see any user of these files, what the purpose of this?


These will be used in the memory configuration for nitrogen6x,
that will build for dual/quad or dual-lite/solo as discussed here:
http://lists.denx.de/pipermail/u-boot/2013-January/145562.html

I'm holding that off waiting for commentary on these to
avoid thrashing.



diff --git a/arch/arm/include/asm/arch-mx6/mx6-ddr.h
b/arch/arm/include/asm/arch-mx6/mx6-ddr.h
new file mode 100644
index 000..4d18ede
--- /dev/null
+++ b/arch/arm/include/asm/arch-mx6/mx6-ddr.h
@@ -0,0 +1,85 @@
+/*
+ * Copyright (C) 2012 Boundary Devices Inc.


Either 2013 or 2012 - 2013?



Can you tell this patch has been lingering?


+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+
+ * You should have received a copy of the GNU General Public License
+along
+ * with this program; if not, write to the Free Software Foundation,
+Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+#ifndef __ASM_ARCH_MX6_DDR_H__
+#define __ASM_ARCH_MX6_DDR_H__
+
+#ifdef CONFIG_MX6Q
+#include mx6q-ddr.h
+#else
+#if defined(CONFIG_MX6DL) || defined(CONFIG_MX6S) #include
+mx6dl-ddr.h
+#else
+#error Please select cpu
+#endif /* CONFIG_MX6DL or CONFIG_MX6S */
+#endif /* CONFIG_MX6Q */
+
+#define MMDC_P0_MDCTL  0x021b


I also prefer to add MX6_ prefix,



Will fix in V2 along with your Ditto comments.

...

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

Re: [U-Boot] [PATCH 2/6] i.MX6: consolidate pad names for multi-CPU boards

2013-02-18 Thread Eric Nelson


Thanks again Jason,

On 02/17/2013 10:31 PM, Liu Hui-R64343 wrote:

-Original Message-
From: Eric Nelson [mailto:eric.nel...@boundarydevices.com]
Sent: Monday, February 18, 2013 3:24 AM
To: u-boot@lists.denx.de
Cc: sba...@denx.de; Liu Hui-R64343; Estevam Fabio-R49496;
troy.ki...@boundarydevices.com; Eric Nelson
Subject: [PATCH 2/6] i.MX6: consolidate pad names for multi-CPU boards

Rename all i.MX6 pad declarations to MX6_PAD_x, so a board
may support either i.MX6Quad/Dual (MX6Q) or i.MX6Dual-Lite/Solo
(MX6DL) by including the proper header.

Boards mx6qarm2, mx6qsabreauto, mx6qsabrelite, and mx6qsabresd
only support MX6Q, so they include mx6q_pins.h.

Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
arch/arm/include/asm/arch-mx6/mx6-pins.h  |   31 +
arch/arm/include/asm/arch-mx6/mx6dl_pins.h|  190 +--
arch/arm/include/asm/arch-mx6/mx6q_pins.h | 1671
+
arch/arm/include/asm/arch-mx6/mx6x_pins.h | 1671 -
board/freescale/mx6qarm2/mx6qarm2.c   |   78 +-
board/freescale/mx6qsabreauto/mx6qsabreauto.c |   60 +-
board/freescale/mx6qsabrelite/mx6qsabrelite.c |  190 +--
board/freescale/mx6qsabresd/mx6qsabresd.c |  102 +-
8 files changed, 2012 insertions(+), 1981 deletions(-)
create mode 100644 arch/arm/include/asm/arch-mx6/mx6-pins.h
create mode 100644 arch/arm/include/asm/arch-mx6/mx6q_pins.h
delete mode 100644 arch/arm/include/asm/arch-mx6/mx6x_pins.h

diff --git a/arch/arm/include/asm/arch-mx6/mx6-pins.h
b/arch/arm/include/asm/arch-mx6/mx6-pins.h
new file mode 100644
index 000..4011268
--- /dev/null
+++ b/arch/arm/include/asm/arch-mx6/mx6-pins.h
@@ -0,0 +1,31 @@
+/*
+ * Copyright (C) 2012 Boundary Devices Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+#ifndef __ASM_ARCH_MX6_PINS_H__
+#define __ASM_ARCH_MX6_PINS_H__
+
+#ifdef CONFIG_MX6Q
+#include mx6q_pins.h
+#else
+#if defined(CONFIG_MX6DL) || defined(CONFIG_MX6S)
+#include mx6dl_pins.h
+#else
+#error Please select cpu
+#endif /* CONFIG_MX6DL or CONFIG_MX6S */
+#endif /* CONFIG_MX6Q */
+
+#endif /*__ASM_ARCH_MX6_PINS_H__ */
diff --git a/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
b/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
index 79e2c4f..0395357 100644
--- a/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
+++ b/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
@@ -50,100 +50,100 @@
#define NO_MUX_I0
#define NO_PAD_I0
enum {
-   MX6DL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK =
IOMUX_PAD(0x03B0, 0x009C, 0, 0x, 0, PAD_CTL_DSE_120ohm),
-   MX6DL_PAD_DI0_PIN15__IPU1_DI0_PIN15 = IOMUX_PAD(0x03B4,
0x00A0, 0, 0x, 0, PAD_CTL_DSE_120ohm),
-   MX6DL_PAD_DI0_PIN2__IPU1_DI0_PIN2   = IOMUX_PAD(0x03B8,
0x00A4, 0, 0x, 0, PAD_CTL_DSE_120ohm),
-   MX6DL_PAD_DI0_PIN3__IPU1_DI0_PIN3   = IOMUX_PAD(0x03BC,
0x00A8, 0, 0x, 0, PAD_CTL_DSE_120ohm),
-   MX6DL_PAD_DI0_PIN4__GPIO_4_20   = IOMUX_PAD(0x03C0,
0x00AC, 5, 0x, 0, PAD_CTL_DSE_120ohm),


[...]


diff --git a/board/freescale/mx6qarm2/mx6qarm2.c
b/board/freescale/mx6qarm2/mx6qarm2.c
index ee20d4f..ff7f5e8 100644
--- a/board/freescale/mx6qarm2/mx6qarm2.c
+++ b/board/freescale/mx6qarm2/mx6qarm2.c
@@ -23,7 +23,7 @@
#include common.h
#include asm/io.h
#include asm/arch/imx-regs.h
-#include asm/arch/mx6x_pins.h
+#include asm/arch/mx6q_pins.h


Since you have defined mx6-pins.h, why not just include the mx6-pins.h?
If not using mx6-pins.h, then what's the purpose of it?



I kept mx6q_pins.h for existing boards that included
dual-quad support, since the only builds are for that
platform.

If these boards support Dual-Lite/Solo, they'll need
an additional board file with the proper declarations.

I have no idea whether that's planned.

Regards,


Eric

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

Re: [U-Boot] AM335x : failure to boot SPL from NAND

On 15/02/13 21:13, Tom Rini wrote:
On Thu, Feb 14, 2013 at 03:54:23PM +, Mark Jackson wrote:

I'm trying to diagnose why our AM335x based CPU board (based on the
AM335x Starter Kit) can boot SPL and U-Boot from an MMC card, but is
unable to boot from NAND (connected to CS0).

Following the TI wiki
(http://processors.wiki.ti.com/index.php/AM335x_U-Boot_User%27s_Guide#Flashing_images_to_NAND_in_SD_boot)
I:-

(1) boot from MMC
(2) erase the nand
(3) copy MLO from MMC into NAND
(4) verified it copied correctly (using crc32)

When I reboot the board in NAND mode, I get nothing on UART0.

If I reboot in MMC mode, SPL and U-Boot load correctly.

Can anyone give me some pointers on the boot sequence, and where I
might look to help debug the problem ?

Assuming you're using mainline U-Boot and can rule out vendor
problems, if you can access the SYSBOOT pins, set it up for a mode that
does NAND and UART. If you never see the 'CCC' on console (or only see
it the first time if you do UART then NAND), then you are starting SPL
and dying in there. If you just see a stream of C then your file is not
written to NAND correctly.

Interesting ... I don't get any 'CCC' on the console.

However, I then tested this by booting via MMC, erasing the NAND chip and
then trying to reboot via NAND again.

I still get no 'CCC' on the console !?!

This is using boot mode 10011 (NAND, NANDI2C, MMC0, UART0), so I would expect
to either boot via MMC (if I left it in) or get some 'CCC' output on the
console.

I can see that the NAND signals always have a burst of activity every 10ms.
That must be a timeout of some sort ... do you know if that's a hardware or
software timeout ?

Mark J.

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

Re: [U-Boot] AM335x : failure to boot SPL from NAND

On Mon, Feb 18, 2013 at 02:43:47PM +, Mark Jackson wrote:
On 15/02/13 21:13, Tom Rini wrote:
On Thu, Feb 14, 2013 at 03:54:23PM +, Mark Jackson wrote:

I'm trying to diagnose why our AM335x based CPU board (based on the
AM335x Starter Kit) can boot SPL and U-Boot from an MMC card, but is
unable to boot from NAND (connected to CS0).

Following the TI wiki
(http://processors.wiki.ti.com/index.php/AM335x_U-Boot_User%27s_Guide#Flashing_images_to_NAND_in_SD_boot)
I:-

(1) boot from MMC
(2) erase the nand
(3) copy MLO from MMC into NAND
(4) verified it copied correctly (using crc32)

When I reboot the board in NAND mode, I get nothing on UART0.

If I reboot in MMC mode, SPL and U-Boot load correctly.

Can anyone give me some pointers on the boot sequence, and where I
might look to help debug the problem ?

Interesting ... I don't get any 'CCC' on the console.

However, I then tested this by booting via MMC, erasing the NAND chip and
then trying to reboot via NAND again.

I still get no 'CCC' on the console !?!

How did you wire the SYSBOOT pins, and which UART is connected to
console? If you have UART0 as the one hooked up to console and have
SYSBOOT[4:0] as 00100, the order is UART0,XIP (NOR),MMC0,NAND. So you
should see '' (UART0 trying to initiate X-Modem), then it will
try MMC0 and then NAND..

This is using boot mode 10011 (NAND, NANDI2C, MMC0, UART0), so I would expect
to either boot via MMC (if I left it in) or get some 'CCC' output on the
console.

Correct. If you have an empty NAND and nothing inserted in MMC, it
should be an endless cycle of 'C'.

I can see that the NAND signals always have a burst of activity every 10ms.
That must be a timeout of some sort ... do you know if that's a hardware or
software timeout ?

Moving beyond what I can easily help with, sorry. Hit up the TI forums
at http://e2e.ti.com/ as this is getting a bit off-topic for the U-Boot
list as well :) Thanks!

--
Tom

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

Re: [U-Boot] [GIT PULL] Please pull u-boot-nds32/master into your branch

On Mon, Feb 18, 2013 at 03:43:14PM +0800, Macpaul Lin wrote:

 Hi Tom,
 
 Please pull a bug fix for the missing of including header which cause
 broken on NDS32 (board adp-ag102).
 
 Thanks,
 Macpaul Lin
 
 The following changes since commit ea6bd08b7717bf0d3f69ad9f016bf3b03b3eaf16:
 
   nds32: Add a basic errno.h (2013-02-18 15:29:07 +0800)
 
 are available in the git repository at:
 
   git://git.denx.de/u-boot-nds32.git master
 
 for you to fetch changes up to ea6bd08b7717bf0d3f69ad9f016bf3b03b3eaf16:
 
   nds32: Add a basic errno.h (2013-02-18 15:29:07 +0800)

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 05/10] am33xx: add ti814x specific register definitions

On Sun, Feb 17, 2013 at 09:28:33PM +0100, Peter Korsgaard wrote:
  Matt == Matt Porter mpor...@ti.com writes:
 
  Matt Support the ti814x specific register definitions within
  Matt arch-am33xx.
 
  Matt Signed-off-by: Matt Porter mpor...@ti.com
  Matt ---
  Matt  arch/arm/cpu/armv7/am33xx/sys_info.c|3 +++
  Matt  arch/arm/include/asm/arch-am33xx/cpu.h  |   11 +
  Matt  arch/arm/include/asm/arch-am33xx/hardware.h |   32 
 +++
  Matt  arch/arm/include/asm/arch-am33xx/omap.h |7 ++
  Matt  arch/arm/include/asm/arch-am33xx/spl.h  |5 +
  Matt  5 files changed, 54 insertions(+), 4 deletions(-)
  
  Matt diff --git a/arch/arm/include/asm/arch-am33xx/hardware.h 
 b/arch/arm/include/asm/arch-am33xx/hardware.h
  Matt index 41ab2c0..786c159 100644
  Matt --- a/arch/arm/include/asm/arch-am33xx/hardware.h
  Matt +++ b/arch/arm/include/asm/arch-am33xx/hardware.h
  Matt @@ -20,9 +20,14 @@
  Matt  #define __AM33XX_HARDWARE_H
  
  Matt  #include asm/arch/omap.h
  Matt +#include config.h
 
 Quite some of the base addresses are similar, but I wonder if it
 wouldn't be cleaner to simply have a hardware-am33xx.h /
 hardware-ti814x.h instead of all these ifdef / elif?

Since I suspect the things common from ti814x and am33xx are also common
to ti816x (which has been left as an exercise to whomever needs that
next), I think we can re-structure this into something like that, but
keeping the common parts within hardware.h still.

  Matt  /* Control Module Base Address */
  Matt +#ifdef CONFIG_AM33XX
  Matt  #define CTRL_BASE 0x44E1
  Matt  #define CTRL_DEVICE_BASE  0x44E10600
  Matt +#elif defined(CONFIG_TI814X)
  Matt +#define CTRL_BASE 0x4814
  Matt +#endif
 
 No CTRL_DEVICE_BASE on ti814x?

I think this is a side-effect of Matt not supporting the things attached
to it (USB in the case of am335x).

  Matt --- a/arch/arm/include/asm/arch-am33xx/spl.h
  Matt +++ b/arch/arm/include/asm/arch-am33xx/spl.h
  Matt @@ -25,8 +25,13 @@
  
  Matt  #define BOOT_DEVICE_XIP   2
  Matt  #define BOOT_DEVICE_NAND  5
  Matt +#ifdef CONFIG_AM33XX
  Matt  #define BOOT_DEVICE_MMC1  8
  Matt  #define BOOT_DEVICE_MMC2  9   /* eMMC or daughter card */
  Matt +#elif defined(CONFIG_TI814X)
  Matt +#define BOOT_DEVICE_MMC1  9
  Matt +#define BOOT_DEVICE_MMC2  8   /* ROM only supports 2nd 
 instance */
 
 Argh! Couldn't we just swap the meaning of mmc1/mmc2 or would that be
 too confusing?

IMHO, that will lead to further confusion down the line.  I talked with
Matt about this before and well, it's funky.

-- 
Tom


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

Re: [U-Boot] [PATCH 05/10] am33xx: add ti814x specific register definitions

2013-02-18 Thread Peter Korsgaard

 Tom == Tom Rini tr...@ti.com writes:

Hi,

  Quite some of the base addresses are similar, but I wonder if it
  wouldn't be cleaner to simply have a hardware-am33xx.h /
  hardware-ti814x.h instead of all these ifdef / elif?

 Tom Since I suspect the things common from ti814x and am33xx are also common
 Tom to ti816x (which has been left as an exercise to whomever needs that
 Tom next), I think we can re-structure this into something like that, but
 Tom keeping the common parts within hardware.h still.

FYI, I might very well be that guy as I've recently started work on a
ti816x based project.

  Argh! Couldn't we just swap the meaning of mmc1/mmc2 or would that be
  too confusing?

 Tom IMHO, that will lead to further confusion down the line.  I talked with
 Tom Matt about this before and well, it's funky.

Ok.

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

Re: [U-Boot] [PATCH 16/20] Roll crc32 into hash infrastructure

2013-02-18 Thread Simon Glass

Hi Wolfgang,

On Mon, Feb 18, 2013 at 3:35 AM, Wolfgang Denk w...@denx.de wrote:
 Dear Tom,

 In message 51216721.1010...@ti.com you wrote:

 There's another thread I don't have yet (and I don't have this one in
 gmail yet even).  But, I am OK with custodians using their repos, but
 not the master branch, for unrelated but otherwise good patches. I'm
 also fine with patchwork bundles.  I suppose we could use the staging
 repository for these changes instead.

 What I mostly object about there is that these patches would go into
 mainline basicly unreviewed, as patch submission and pull request is
 all done from a single person, with no other feedback on the patches
 at all.  And this affects a lot of common code...

Fair enough. I suspect a number of people scan the code, but few feel
invested enough to formally Ack it. Also, providing a full review of
such a series can take quite a bit of time. Against that, I think it
is better to get code in and tested than have it sit around until just
before the next release.


 Actually, I see this change when pulling u-boot-x86.git/master:

Thanks for looking at it. Some of it is just the code moving around,
but I will take a look at why hash_command grows so much, and why the
overall size has grown. Clearly I didn't do enough here when I checked
the series. One change was trying to unify the verify feature, so
perhaps something has gone wrong there.


 - bloat-o-meter u-boot-before u-boot
 add/remove: 9/0 grow/shrink: 3/14 up/down: 1006/-560 (446)
 function old new   delta
 hash_command   - 424+424
 strncasecmp- 156+156
 simple_itoa- 104+104
 crc32_wd_buf   -  76 +76
 setenv_hex -  68 +68
 setenv_ulong   -  52 +52
 strcasecmp -  36 +36
 do_mem_loopw 304 328 +24
 static.local   -  22 +22
 do_mem_loop  268 288 +20
 hash_algo  -  16 +16
 do_mem_cmp   332 340  +8
 do_mem_mw224 220  -4
 set_working_fdt_addr  72  52 -20
 load_serial_ymodem   300 280 -20
 load_serial  512 492 -20
 index_partitions 200 180 -20
 do_load_serial_bin  18441824 -20
 do_load  468 448 -20
 do_jffs2_fsload  320 300 -20
 do_imgextract636 592 -44
 NetLoop  832 788 -44
 do_mem_cp312 252 -60
 do_bootm12441180 -64
 do_mem_crc   188  88-100
 do_mem_mtest14361332-104


 So there are changes all over the place, including a growth of the
 memory footprint.  I think this needs at least minimal review.

We need more reviewers I think.

Regards,
Simon


 Best regards,

 Wolfgang Denk

 --
 DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
 Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
 Time is an illusion perpetrated by the manufacturers of space.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v7 16/19] arm926ejs: Remove deprecated and now unused NAND SPL

On Sun, Feb 17, 2013 at 04:51:37PM +0100, Beno??t Th??baudeau wrote:
 Hi Albert, Tom, Zhong,
 
 On Friday, February 15, 2013 9:54:22 PM, Beno??t Th??baudeau wrote:
  Signed-off-by: Beno??t Th??baudeau benoit.thebaud...@advansee.com
  ---
  Changes in v7: None
  Changes in v6:
   - New patch.
  
  Changes in v5: None
  Changes in v4: None
  Changes in v3: None
  Changes in v2: None
  
   arch/arm/cpu/arm926ejs/start.S |   10 --
   1 file changed, 10 deletions(-)
 
 I would like to get your feedback regarding the status of the Samsung SMDK6400
 board:
  - It is not in boards.cfg, so, according to commit 1285a28, support for it
should already have been removed a long time ago. It also seems to be the
only board remaining in the main Makefile.
  - It uses the deprecated NAND SPL.
  - MAKEALL does not test its build, which has been broken for a while.
  - If it were removed or fixed, ARM1176's start.S' relocate_code() could be 
 made
identical to all the other implementations of this function, so all this
duplicated code could be moved to a common location like crt0.S. Besides
that, it would be possible to completely get rid of the legacy NAND SPL on
ARM.
 
 I have no intention of fixing this board, but dropping it and cleaning up ARM
 after that would be easy.

I'm in favor of removing and updating README.scrapyard, baring quick
attention from the maintainer to update it to not being using the
Makefile and fix the rest of the breakage.

-- 
Tom


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

Re: [U-Boot] [PATCH v1] Refactor linker-generated arrays

2013-02-18 Thread Albert ARIBAUD

Hi Andreas,

On Mon, 18 Feb 2013 11:42:07 +0100, Andreas Bießmann
andreas.de...@googlemail.com wrote:

 On 02/18/2013 11:39 AM, Andreas Bießmann wrote:
  Hi Albert,
  
  On 02/16/2013 07:20 PM, Albert ARIBAUD wrote:
 
 snip
 
  It's ok so far, the arm-linux toolchain I have do not produce these
 
 I mean avr32-linux ... damn weekend ...

Thanks Andreas for the feedback. I am currently testing V2 locally
and will send it out in a few hours hopefully.

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

Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding

On Sun, Feb 17, 2013 at 05:16:49PM +0100, Beno??t Th??baudeau wrote:

 Hi Poonam, Andy,
 
 On Friday, February 15, 2013 9:54:19 PM, Beno??t Th??baudeau wrote:
  PAD_TO is not a generic SPL configuration option, so use CONFIG_SPL_MAX_SIZE
  instead.
  
  We want to use --pad-to with a size, but this option expects an address, so
  use
  u-boot-spl.bin instead of u-boot-spl as the input file in order to get
  addresses
  starting at 0.
  
  Signed-off-by: Beno??t Th??baudeau benoit.thebaud...@advansee.com
  ---
  Changes in v7:
   - Use u-boot-spl.bin instead of u-boot-spl in order to avoid having to use
 --change-addresses.
  
  Changes in v6:
   - Fix size passed to --pad-to thanks to --change-addresses.
  
  Changes in v5: None
  Changes in v4:
   - New patch.
  
  Changes in v3: None
  Changes in v2: None
  
   Makefile |3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)
  
  diff --git a/Makefile b/Makefile
  index a8c7b7b..317dffc 100644
  --- a/Makefile
  +++ b/Makefile
  @@ -486,7 +486,8 @@ $(obj)u-boot.dis:   $(obj)u-boot
  $(OBJDUMP) -d $  $@
   
   $(obj)u-boot-with-spl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
  -   $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary 
  $(obj)spl/u-boot-spl
  $(obj)spl/u-boot-spl-pad.bin
  +   $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(CONFIG_SPL_MAX_SIZE) \
  +   -I binary -O binary $ $(obj)spl/u-boot-spl-pad.bin
  cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin  $@
  rm $(obj)spl/u-boot-spl-pad.bin
 
 I would like to let you know what is going on, and to get your feedback for 
 this
 patch.
 
 include/configs/p1_p2_rdb_pc.h seems to be the only current user of
 u-boot-with-spl.bin, triggered for example by the P2020RDB-PC_NAND config.

cam_enc_4xx also uses this target.  Heiko?  It looks like this change
should be safe there as well.

 Before this patch, PAD_TO was used, but there is no such definition for this
 board for generic SPL, so this board seems broken, all the more none of the
 various values defined for CONFIG_SYS_TEXT_BASE relatively to
 CONFIG_SPL_TEXT_BASE would be compatible with an image built by appending 
 U-Boot
 to the generic SPL. Can you confirm?
 
 This patch won't fix this board, but I want to make sure that it won't be an
 issue for you now or later.

-- 
Tom


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

Re: [U-Boot] [PATCH 16/20] Roll crc32 into hash infrastructure

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/18/2013 11:36 AM, Simon Glass wrote:
 Hi Wolfgang,
 
 On Mon, Feb 18, 2013 at 3:35 AM, Wolfgang Denk w...@denx.de wrote:
 Dear Tom,
 
 In message 51216721.1010...@ti.com you wrote:
 
 There's another thread I don't have yet (and I don't have this 
 one in gmail yet even).  But, I am OK with custodians using 
 their repos, but not the master branch, for unrelated but 
 otherwise good patches. I'm also fine with patchwork bundles. I
 suppose we could use the staging repository for these changes 
 instead.
 
 What I mostly object about there is that these patches would go 
 into mainline basicly unreviewed, as patch submission and pull 
 request is all done from a single person, with no other feedback 
 on the patches at all.  And this affects a lot of common code...
 
 Fair enough. I suspect a number of people scan the code, but few 
 feel invested enough to formally Ack it. Also, providing a full 
 review of such a series can take quite a bit of time. Against
 that, I think it is better to get code in and tested than have it
 sit around until just before the next release.
[snip]
 So there are changes all over the place, including a growth of 
 the memory footprint.  I think this needs at least minimal 
 review.
 
 We need more reviewers I think.

This is where I'm trying to find a good balance right now.  If we just
wait for reviewed-by lines to fly by, things will sit forever.  Partly
because enough folks don't feel like they own things enough to risk
saying they reviewed something that turns out later to have a bug.
And partly there's just not enough folks reading patches.  I do try
and give things some sort of read-over when it's the person posting
who is doing the merging, especially for common rather than their
area code.

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRIl9FAAoJENk4IS6UOR1WJqMP/ie04KKI6NpMPDei9QSJ9+qg
peFMXyVXoNWVZ0OuVSgVYOyBNtTmZeUmNsyamtE/1QifAWX6F2lwXHl2teYcebMk
7Fn/N3uzoVisfcFhY3Ec0dgBigYbRm5hiSHF7qzBkS78FfI5XSFaR/XjkshCgLlC
i5Vf8Gh6ilb67fLumzxnXU2LLpbfcoOoT7iMLX0C5SFkx9sjo4k/5/WC64jsx8IS
NQiaoFX3Ow7uU63G7jEJ4hiqXsp2ulWZTBA4ynN7ydGYiPo+sRXoLRaBYB9yAkRQ
3Uj1a101VX+9LWdNoMRpqv6W3gq75+8nSggovK0DmxtF4X5PaF17Xmpc8dBTT9rE
cCIkePKDNgg6QjTAtCxk7+nw997JSjrj1nV0R2+Jm225tby4hIjmnIfnCNgeYbbI
II7+ecaUl4w+GxB1SgjFLmEyW0unDsYZauT4sXxSdBp/UOrs4I3XYW4gFofifMcB
peJELQYVUHnXblZ+xR+8zY3URsn2vNRxNq5fUDWMUADgvwecfvWFeKaVGDA+aWHs
vNFKWayZbt5MpqG4aQJ4mzIhf9avNytf8BSSQ+LFp53xOl5f08OsioN9+4H3rOND
LRuiMZ5wtrlJea3Eoi3PFXeO/l4N4eKvDNbwNSwDbS4EZj+4mZbGrNxGglcQK3C+
1EM1fpRioWEXpGaMpmKV
=W6Pn
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 16/20] Roll crc32 into hash infrastructure

2013-02-18 Thread Simon Glass

Hi Wolfgang,

On Mon, Feb 18, 2013 at 3:35 AM, Wolfgang Denk w...@denx.de wrote:
 Dear Tom,

 In message 51216721.1010...@ti.com you wrote:

 There's another thread I don't have yet (and I don't have this one in
 gmail yet even).  But, I am OK with custodians using their repos, but
 not the master branch, for unrelated but otherwise good patches. I'm
 also fine with patchwork bundles.  I suppose we could use the staging
 repository for these changes instead.

 What I mostly object about there is that these patches would go into
 mainline basicly unreviewed, as patch submission and pull request is
 all done from a single person, with no other feedback on the patches
 at all.  And this affects a lot of common code...

 Actually, I see this change when pulling u-boot-x86.git/master:

 - bloat-o-meter u-boot-before u-boot

What board is this please?

Some specific notes here - I think it boils down to moving crc32 into
the hash framework. This adds some overhead, but has a few benefits.

 add/remove: 9/0 grow/shrink: 3/14 up/down: 1006/-560 (446)
 function old new   delta
 hash_command   - 424+424

This is the generic hashing command. What is happening here is that
the crc32 command is getting a few more features, more like sha1sum.
However, this might not be desriable - and in fact this patch changes
the behaviour of the CRC storage and verify to support using an
environment variable, and requiring * before the argument when an
address is required! That needs to be fixed, at least.

The intent is to try to unify the hashing/crc features into a single
framework. If you enable only crc32 and nothing else then this has
quite a cost (0.5KB at present). I think I can reduce this code by
making the full features of hash.c only available when something more
than just crc32 is enabled. However, it might involve some #ifdefs...

 strncasecmp- 156+156
 simple_itoa- 104+104
 crc32_wd_buf   -  76 +76
 setenv_hex -  68 +68
 setenv_ulong   -  52 +52
 strcasecmp -  36 +36
 do_mem_loopw 304 328 +24
 static.local   -  22 +22
 do_mem_loop  268 288 +20
 hash_algo  -  16 +16
 do_mem_cmp   332 340  +8
 do_mem_mw224 220  -4
 set_working_fdt_addr  72  52 -20
 load_serial_ymodem   300 280 -20
 load_serial  512 492 -20
 index_partitions 200 180 -20
 do_load_serial_bin  18441824 -20
 do_load  468 448 -20
 do_jffs2_fsload  320 300 -20
 do_imgextract636 592 -44
 NetLoop  832 788 -44
 do_mem_cp312 252 -60
 do_bootm12441180 -64
 do_mem_crc   188  88-100
 do_mem_mtest14361332-104


 So there are changes all over the place, including a growth of the
 memory footprint.  I think this needs at least minimal review.

 Best regards,

 Wolfgang Denk

 --
 DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
 Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
 Time is an illusion perpetrated by the manufacturers of space.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding

On Monday, February 18, 2013 5:50:59 PM, Tom Rini wrote:
 On Sun, Feb 17, 2013 at 05:16:49PM +0100, Beno??t Th??baudeau wrote:
 
  Hi Poonam, Andy,
  
  On Friday, February 15, 2013 9:54:19 PM, Beno??t Th??baudeau wrote:
   PAD_TO is not a generic SPL configuration option, so use
   CONFIG_SPL_MAX_SIZE
   instead.
   
   We want to use --pad-to with a size, but this option expects an address,
   so
   use
   u-boot-spl.bin instead of u-boot-spl as the input file in order to get
   addresses
   starting at 0.
   
   Signed-off-by: Beno??t Th??baudeau benoit.thebaud...@advansee.com
   ---
   Changes in v7:
- Use u-boot-spl.bin instead of u-boot-spl in order to avoid having to
use
  --change-addresses.
   
   Changes in v6:
- Fix size passed to --pad-to thanks to --change-addresses.
   
   Changes in v5: None
   Changes in v4:
- New patch.
   
   Changes in v3: None
   Changes in v2: None
   
Makefile |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
   
   diff --git a/Makefile b/Makefile
   index a8c7b7b..317dffc 100644
   --- a/Makefile
   +++ b/Makefile
   @@ -486,7 +486,8 @@ $(obj)u-boot.dis: $(obj)u-boot
 $(OBJDUMP) -d $  $@

$(obj)u-boot-with-spl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
   - $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary
   $(obj)spl/u-boot-spl
   $(obj)spl/u-boot-spl-pad.bin
   + $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(CONFIG_SPL_MAX_SIZE) \
   + -I binary -O binary $ $(obj)spl/u-boot-spl-pad.bin
 cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin  $@
 rm $(obj)spl/u-boot-spl-pad.bin
  
  I would like to let you know what is going on, and to get your feedback for
  this
  patch.
  
  include/configs/p1_p2_rdb_pc.h seems to be the only current user of
  u-boot-with-spl.bin, triggered for example by the P2020RDB-PC_NAND config.
 
 cam_enc_4xx also uses this target.  Heiko?  It looks like this change
 should be safe there as well.

And MPC8313ERDB too.

But I've just seen that commit 74752ba did something for that in u-boot/master,
and this commit is not in u-boot-imx/master on which I based this series. Why
is u-boot-imx/master not sync'ed with u-boot/master? How am I supposed to handle
patch sets depending on several custodian repositories?

Commit 74752ba performs a '--pad-to=$(or $(CONFIG_SPL_PAD_TO),0)' on u-boot-spl.
I could use this CONFIG_SPL_PAD_TO for this series too, but is it really
necessary to have both CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE? In other
words, is there any case for which CONFIG_SPL_PAD_TO could be different from
CONFIG_SPL_TEXT_BASE + CONFIG_SPL_MAX_SIZE for a valid reason?

  Before this patch, PAD_TO was used, but there is no such definition for
  this
  board for generic SPL, so this board seems broken, all the more none of the
  various values defined for CONFIG_SYS_TEXT_BASE relatively to
  CONFIG_SPL_TEXT_BASE would be compatible with an image built by appending
  U-Boot
  to the generic SPL. Can you confirm?
  
  This patch won't fix this board, but I want to make sure that it won't be
  an
  issue for you now or later.

Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC PATCH] Provide a mechanism to avoid using #ifdef everywhere

2013-02-18 Thread Simon Glass

Many parts of the U-Boot code base are sprinkled with #ifdefs. This makes
different boards compile different versions of the source code, meaning
that we must build all boards to check for failures. It is easy to misspell
an #ifdef and there is not as much checking of this by the compiler. Multiple
dependent #ifdefs are harder to do than with if..then..else. Variable
declarations must be #idefed as well as the code that uses them, often much
later in the file/function. #ifdef indents don't match code indents and
have their own separate indent feature. Overall, excessive use of #idef
hurts readability and makes the code harder to modify and refactor. For
people coming newly into the code base, #ifdefs can be a big barrier.

The use of #ifdef in U-Boot has possibly got a little out of hand. In an
attempt to turn the tide, this patch provides a way to make CONFIG macros
available to C code without using the preprocessor. This makes it possible
to use standard C conditional features such as if/then instead of #ifdef.
A README update exhorts compliance.

As an example of how to use this, this patch replaces all but two #ifdefs
from the main code body of common/main.c, which has the dubious distinction
of having the most #ifdefs by at least one measure:

$ for f in $(find . -name *.c); do echo $(grep -c ifdef $f) $f; done \
|sort -nr |head
57 ./common/main.c
57 ./arch/powerpc/cpu/mpc83xx/cpu_init.c
48 ./arch/powerpc/lib/board.c
46 ./drivers/video/cfb_console.c
40 ./drivers/mtd/cfi_flash.c
38 ./net/tftp.c
38 ./common/cmd_bootm.c
37 ./drivers/usb/host/ohci-hcd.c
36 ./drivers/fpga/ivm_core.c
35 ./drivers/usb/gadget/ether.c

Code size for this patch seems to be roughly neutral (below numbers are
average change in byte size for each region:

   x86: (3 boards)   text -1.3   data +1.3
   sandbox: (1 boards)   bss +16.0
  m68k: (50 boards)   text -4.8
   powerpc: (634 boards)   text +7.4   data +0.0   bss +2.1
sh: (21 boards)   text -9.1   bss +2.5
 nios2: (3 boards)   text +24.0
   arm: (287 boards)   spl/u-boot-spl:text -0.3   text -2.3   bss +7.2
 nds32: (3 boards)   text -16.0

Signed-off-by: Simon Glass s...@chromium.org
---
 Makefile  |  41 ++-
 README|  87 -
 common/cmd_fitupd.c   |   1 +
 common/main.c | 794 ++
 include/command.h |   2 -
 include/common.h  |   9 +-
 include/config_drop.h |  17 +
 include/configs/pm9263.h  |   2 +-
 include/fdt_support.h |   4 +-
 include/hush.h|   2 -
 include/menu.h|   2 -
 include/net.h |   2 +
 tools/scripts/define2conf.sed |  36 ++
 tools/scripts/define2list.sed |  31 ++
 14 files changed, 563 insertions(+), 467 deletions(-)
 create mode 100644 include/config_drop.h
 create mode 100644 tools/scripts/define2conf.sed
 create mode 100644 tools/scripts/define2list.sed

diff --git a/Makefile b/Makefile
index fc18dd4..5ca3a57 100644
--- a/Makefile
+++ b/Makefile
@@ -614,6 +614,7 @@ updater:
 # parallel sub-makes creating .depend files simultaneously.
 depend dep:$(TIMESTAMP_FILE) $(VERSION_FILE) \
$(obj)include/autoconf.mk \
+   $(obj)include/generated/autoconf.h \
$(obj)include/generated/generic-asm-offsets.h \
$(obj)include/generated/asm-offsets.h
for dir in $(SUBDIRS) $(CPUDIR) $(LDSCRIPT_MAKEFILE_DIR) ; do \
@@ -688,6 +689,43 @@ $(obj)include/autoconf.mk: $(obj)include/config.h
sed -n -f tools/scripts/define2mk.sed  $@.tmp  \
mv $@.tmp $@
 
+# Create a C header file where every '#define CONFIG_XXX value' becomes
+# '#define config_xxx() value', or '#define config_xxx() 0' where the CONFIG
+# is not used by this board configuration. This allows C code to do things
+# like 'if (config_xxx())' and have the compiler remove the dead code,
+# instead of using '#ifdef CONFIG_XXX...#endif'. Note that in most cases
+# if the config_...() returns 0 then the option is not enabled. In some rare
+# cases such as CONFIG_BOOTDELAY, the config can be enabled but still have a
+# a value of 0. So in addition we a #define config_xxx_enabled(), setting the
+# value to 0 if the option is disabled, 1 if enabled. This last feature will
+# hopefully be deprecated soon.
+# The file is regenerated when any U-Boot header file changes.
+$(obj)include/generated/autoconf.h: $(obj)include/config.h
+   @$(XECHO) Generating $@ ; \
+   set -e ; \
+   : Extract the config macros to a C header file ; \
+   $(CPP) $(CFLAGS) -DDO_DEPS_ONLY -dM include/common.h | \
+   sed -n -f tools/scripts/define2conf.sed  $@.tmp; \
+   : Regenerate our list of all config macros if neeed ; \
+   if [ ! -f $@-all.tmp ] || \
+   find $(src) -name '*.h' -type f -newer $@-all.tmp | \
+   egrep -qv

Re: [U-Boot] [PATCH] CONFIG_BOOTDELAY default should not affect runtime

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/09/2013 11:21 AM, Otavio Salvador wrote:
 Hello Wolfgang,
 
 On Sat, Feb 9, 2013 at 4:54 AM, Wolfgang Denk w...@denx.de wrote:
 Dear Joe Hershberger,
 
 In message
 1360355280-1197-1-git-send-email-joe.hershber...@ni.com you
 wrote:
 Because the code that handles bootdelay is compiled in
 conditionally based on the default value, you are restricted in
 the default, regardless of what you want the runtime options to
 be.
 
 Change the source to always check if any default is given so
 that other values can be selected and used at runtime.
 
 Signed-off-by: Joe Hershberger joe.hershber...@ni.com --- 
 common/main.c | 14 ++ 1 file changed, 6
 insertions(+), 8 deletions(-)
 
 diff --git a/common/main.c b/common/main.c index
 e2d2e09..0973c59 100644 --- a/common/main.c +++
 b/common/main.c @@ -95,7 +95,7 @@ extern void mdm_init(void);
 /* defined in board.c */ * Watch for 'delay' seconds for
 autoboot stop or autoboot delay string. * returns: 0 -  no key
 string, allow autoboot 1 - got key string, abort */ -#if
 defined(CONFIG_BOOTDELAY)  (CONFIG_BOOTDELAY = 0) +#if
 defined(CONFIG_BOOTDELAY)
 
 Careful!! This is probably changing behaviour of a number of
 boards significantly.
 
 we have to check if we really want this, and if yes, we have to 
 announce it and provide a grace period (eventually using 
 doc/feature-removal-schedule.txt ?)
 
 It seems the CONFIG_BOOTDELAY as  0 is not very common:
 
 ~/hacking/u-boot% git grep CONFIG_BOOTDELAY | egrep 'BOOTDELAY\s*
 \-[0-9]' include/configs/RPXsuper.h:#define CONFIG_BOOTDELAY
 -1 include/configs/ep8260.h:#define CONFIG_BOOTDELAY-1 
 include/configs/espt.h:#define CONFIG_BOOTDELAY-1 
 include/configs/scb9328.h:#define CONFIG_BOOTDELAY   -1 
 include/configs/sh7763rdp.h:#define CONFIG_BOOTDELAY-1

I count 49 boards with git grep -E
'CONFIG_BOOTDELAY[[:blank:]]+-[0-9]' so it's not _that_ uncommon.

 So maybe those could have CONFIG_BOOTDELAY undefined keeping them 
 working as before?

The problem is that as I read the README, we document CONFIG_BOOTDELAY
as having a valid value range of from -2 to sane positive value.  So
yes, if we want to change this we need to (a) change the README too
and (b) give some sort of heads-up.

Off the top of my head, we could change to:
CONFIG_AUTOBOOT_DISABLED and CONFIG_FORCE_AUTOBOOT_NO_DELAY and update
doc/README.autoboot as well and add some sanity #warning checks for a
release or two in some common generated config related file or
something like that.

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRImLoAAoJENk4IS6UOR1W78kP/1xHVrQ4pZbAV8WnBsxje+gn
qphEJU5Ud+gA5ThyEm/I1d1VSSvLgOWGqnarleOSXUmcWkBcbfetO69VVLnvlUI+
oVXEopn7plCO7iM2YAiOW8vx5fy97JqGxWn1/BJ64ySjup5GlEXd97Op9LQ+wjy7
xNgFQ1KN9wdoabQU2PUy7jeGXY8LTdFx4GsYSK/KRJWIvo3O57c2uOsE2BiA2Uxq
Ue780cVqqsoRmZxo2gooAUTupz3kPYmFthPn2qxs1y3nLn4GVrJM5YurOhH2weeA
sHOffHqlUn1kUxrhRnM6mpeu+JUeKFP8IoyOuhCYA7D28Bk1XtqkZai+yobOrf3U
cr4WUdhZEA9hFZAXnlrVe/FjVLe6pvQ9hPjUshPoCerahrcpUOwiegrw6IWg+vzB
DdK5hbPh09rTdpfnjWWRf0fSrqQqaXmNQALmRQOc4G1Vn8xKruC4vacetdNRfgCn
gFOSTpbDBG7oKFXHpCzliXEg8lFy+af+oMKTztR/UtPrBX5cfr6XF2SekNm9jus4
Njjq1ouYKXfOyeNIrg0prOi14ZMF3uQYb/eUsffzeujdmbhcgENopUrGLl9FvlxV
bsktw7oWhgirVZ5CsODk/3siDfJc1pi9yz3oMO61Qqtrrv3HLLjGIFEx4DjxNmkk
COfH7og2vh8xQavT8IXY
=oTlx
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/18/2013 12:26 PM, Benoît Thébaudeau wrote:

[snip]
 But I've just seen that commit 74752ba did something for that in
 u-boot/master, and this commit is not in u-boot-imx/master on which
 I based this series. Why is u-boot-imx/master not sync'ed with
 u-boot/master? How am I supposed to handle patch sets depending on
 several custodian repositories?

I'm not sure why u-boot-imx is out of sync at the moment.  My rule of
thumb is to start working on u-boot/master and cherry-pick out things
I need from other places into a -test branch.

I know the kernel folks have to deal with a lot of this as well, but I
think it ends up being a developer choice on what best fits their
needs when they need N different series to be applied for their
starting point.

 Commit 74752ba performs a '--pad-to=$(or $(CONFIG_SPL_PAD_TO),0)'
 on u-boot-spl. I could use this CONFIG_SPL_PAD_TO for this series
 too, but is it really necessary to have both CONFIG_SPL_PAD_TO and
 CONFIG_SPL_MAX_SIZE? In other words, is there any case for which
 CONFIG_SPL_PAD_TO could be different from CONFIG_SPL_TEXT_BASE +
 CONFIG_SPL_MAX_SIZE for a valid reason?

I was wondering along those lines.  I don't _think_ we need both
CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE, but we can't combine
CONFIG_SPL_MAX_SIZE and CONFIG_SPL_TEXT_BASE as on TI platforms we
start quite well above zero (0x402F0400 on am33xx, etc).  That said, I
guess we do need CONFIG_SPL_PAD_TO so that some platforms can do:
#define CONFIG_SPL_PAD_TO (CONFIG_SPL_TEXT_BASE + CONFIG_SPL_MAX_SIZE)
and others just
#define CONFIG_SPL_PAD_TO CONFIG_SPL_MAX_SIZE

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRImSWAAoJENk4IS6UOR1W0DkP/3VBLW0gdRoIfvNHpO3cI0Db
FfjKGQoCgAmrlCE4PyGo2SkkBPl/doxLWYCOr8DJ/BDnjF04r/8NMT/wn/a9xrvv
d5fCpIxQPme356SfMS23LVnTmJR4mOKLdHjJ2QXxyrFXXTnI7W80iPgfslgCTJje
kxbH5chVQq7LYN9ZeynOP9XEZYT9rTcAXG9LVPqStWi73izpMa/D0adc/FqdWfi3
qcstiSxSQyPWmF7O7dRYzs9J4BMcT749NuQmkvbrh64/XL81emynfrYCgBU70QMr
uQV9qxq+zALmUuMTdWRD0ATLQiybuN5Mbam7X4ACAmi8THfSEuUWtS3g0PR9+FH+
/HYICi8l2WDONRCWDcj5PLpQNYaNeunSPj+8q4g4i/OiEO+1rWZqtrgXxcH/WTlT
dz6C6w/YFhfCakKwB8r2+5H3GyIpoDgbqsCfxI8LTNDA69/zXohbH6uDNMqWDPAV
IS0+7Z3iC+MPmfkAXL2vz02CoiUiX2YwgYrhVrmPAbbsHSLndh2oAmGkdl8Hc2BK
zhCKW75bv1flXwBIE3skocKZTDTjiMsMKoqosiFtSIaXQsn6Zz7YYh4ZpCNE0U3C
P3GRpeotnXk0jRp6DOGKceWfVQLbY3rAZKWoMAjTujGIh3YfXRVU+KWLqi8APjNK
a2aPpMFx6Oy72BQvV11W
=zJru
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding

On Monday, February 18, 2013 6:27:50 PM, Tom Rini wrote:
  Commit 74752ba performs a '--pad-to=$(or $(CONFIG_SPL_PAD_TO),0)'
  on u-boot-spl. I could use this CONFIG_SPL_PAD_TO for this series
  too, but is it really necessary to have both CONFIG_SPL_PAD_TO and
  CONFIG_SPL_MAX_SIZE? In other words, is there any case for which
  CONFIG_SPL_PAD_TO could be different from CONFIG_SPL_TEXT_BASE +
  CONFIG_SPL_MAX_SIZE for a valid reason?
 
 I was wondering along those lines.  I don't _think_ we need both
 CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE, but we can't combine
 CONFIG_SPL_MAX_SIZE and CONFIG_SPL_TEXT_BASE as on TI platforms we
 start quite well above zero (0x402F0400 on am33xx, etc).  That said, I
 guess we do need CONFIG_SPL_PAD_TO so that some platforms can do:
 #define CONFIG_SPL_PAD_TO (CONFIG_SPL_TEXT_BASE + CONFIG_SPL_MAX_SIZE)
 and others just
 #define CONFIG_SPL_PAD_TO CONFIG_SPL_MAX_SIZE

If we did like my patch here, i.e. use objcopy with u-boot-spl.bin instead of
u-boot-spl, objcopy would always get a fake 0x0 address at the beginning of the
.bin, so CONFIG_SPL_MAX_SIZE could be used with --pad-to, and CONFIG_SPL_PAD_TO
would be useless.

The only question is if we may need to have an empty gap between the SPL and
U-Boot within the resulting image. I don't think so since that would mean that
the target memory device has an area that is not really available at the
location of this gap.

Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding


On 02/18/2013 06:28:15 AM, Benoît Thébaudeau wrote:
I'm also wondering why there is both generic SPL for NAND and legacy  
NAND SPL
for p1_p2_rdb, all the more the NAND SPL version does not seem to  
be used in

boards.cfg.


p1_p2_rdb_pc and P1_P2_RDB are different targets (unfortunately).   
The former is for newer boards and has been converted to the new SPL.   
The latter is for older boards, which I do not have access to and have  
had a hard time getting information about (which would be required to  
merge the two targets).  Perhaps P1_P2_RDB should just be removed.


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

Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding


On 02/18/2013 12:00:52 PM, Benoît Thébaudeau wrote:

On Monday, February 18, 2013 6:27:50 PM, Tom Rini wrote:
  Commit 74752ba performs a '--pad-to=$(or $(CONFIG_SPL_PAD_TO),0)'
  on u-boot-spl. I could use this CONFIG_SPL_PAD_TO for this series
  too, but is it really necessary to have both CONFIG_SPL_PAD_TO and
  CONFIG_SPL_MAX_SIZE? In other words, is there any case for which
  CONFIG_SPL_PAD_TO could be different from CONFIG_SPL_TEXT_BASE +
  CONFIG_SPL_MAX_SIZE for a valid reason?


They're logically different things.


 I was wondering along those lines.  I don't _think_ we need both
 CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE, but we can't combine
 CONFIG_SPL_MAX_SIZE and CONFIG_SPL_TEXT_BASE as on TI platforms we
 start quite well above zero (0x402F0400 on am33xx, etc).  That  
said, I

 guess we do need CONFIG_SPL_PAD_TO so that some platforms can do:
 #define CONFIG_SPL_PAD_TO (CONFIG_SPL_TEXT_BASE +  
CONFIG_SPL_MAX_SIZE)

 and others just
 #define CONFIG_SPL_PAD_TO CONFIG_SPL_MAX_SIZE

If we did like my patch here, i.e. use objcopy with u-boot-spl.bin  
instead of
u-boot-spl, objcopy would always get a fake 0x0 address at the  
beginning of the
.bin, so CONFIG_SPL_MAX_SIZE could be used with --pad-to, and  
CONFIG_SPL_PAD_TO

would be useless.

The only question is if we may need to have an empty gap between the  
SPL and
U-Boot within the resulting image. I don't think so since that would  
mean that
the target memory device has an area that is not really available at  
the

location of this gap.


Why not allow that possibility?  Maybe it's easier for the SPL to load  
from a particular offset (e.g. NAND starting at the beginning of a  
block)?


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

Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding

On Monday, February 18, 2013 7:02:49 PM, Scott Wood wrote:
 On 02/18/2013 12:00:52 PM, Benoît Thébaudeau wrote:
  On Monday, February 18, 2013 6:27:50 PM, Tom Rini wrote:
Commit 74752ba performs a '--pad-to=$(or $(CONFIG_SPL_PAD_TO),0)'
on u-boot-spl. I could use this CONFIG_SPL_PAD_TO for this series
too, but is it really necessary to have both CONFIG_SPL_PAD_TO and
CONFIG_SPL_MAX_SIZE? In other words, is there any case for which
CONFIG_SPL_PAD_TO could be different from CONFIG_SPL_TEXT_BASE +
CONFIG_SPL_MAX_SIZE for a valid reason?
 
 They're logically different things.
 
   I was wondering along those lines.  I don't _think_ we need both
   CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE, but we can't combine
   CONFIG_SPL_MAX_SIZE and CONFIG_SPL_TEXT_BASE as on TI platforms we
   start quite well above zero (0x402F0400 on am33xx, etc).  That
  said, I
   guess we do need CONFIG_SPL_PAD_TO so that some platforms can do:
   #define CONFIG_SPL_PAD_TO (CONFIG_SPL_TEXT_BASE +
  CONFIG_SPL_MAX_SIZE)
   and others just
   #define CONFIG_SPL_PAD_TO CONFIG_SPL_MAX_SIZE
  
  If we did like my patch here, i.e. use objcopy with u-boot-spl.bin
  instead of
  u-boot-spl, objcopy would always get a fake 0x0 address at the
  beginning of the
  .bin, so CONFIG_SPL_MAX_SIZE could be used with --pad-to, and
  CONFIG_SPL_PAD_TO
  would be useless.
  
  The only question is if we may need to have an empty gap between the
  SPL and
  U-Boot within the resulting image. I don't think so since that would
  mean that
  the target memory device has an area that is not really available at
  the
  location of this gap.
 
 Why not allow that possibility?

To save a config setting (there are already many for SPL) if this is not
strictly required, but also for the reason below.

  Maybe it's easier for the SPL to load
 from a particular offset (e.g. NAND starting at the beginning of a
 block)?

CONFIG_SPL_MAX_SIZE would be closer to a NAND mapping in that case (e.g. size of
1 NAND Flash block) than CONFIG_SPL_PAD_TO (address within RAM that should be
considered relatively to CONFIG_SPL_TEXT_BASE to get the NAND offset).

Also, CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE depend on each other: If both
can be defined, you may change one forgetting the other one, which could e.g.
result in an overlapping of SPL and U-Boot that won't show up at build time
(with CONFIG_SPL_MAX_SIZE = 0x1000 and CONFIG_SPL_PAD_TO = CONFIG_SPL_TEXT_BASE
+ 0x800, the SPL would build fine, and objcopy wouldn't complain).

Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] trying to understand u-boot-nand.ais file for AM1808 exp kit

2013-02-18 Thread Robert P. J. Day


  i hope someone here can clear up what should be a simple question --
i'm trying to figure out what exactly is going on when building and
flashing a u-boot image for my new AM1808 experimenter kit or, more
accurately, someone else's modified version where the 8M of NOR flash
has been replaced with 2G of NAND flash.

  i've downloaded the DaVinci PSP SDK (v03.22.00.02) and i'm trying to
figure out what the prebuilt u-boot images mean, and what it means to
flash them.

  the earlier PSP SDK used separate ubl and u-boot images, so i've
seen examples of using the supplied windows-based sfh_OMAP-L138.exe
utility to flash the board, in that it had to reference both binary
files since, with that earlier PSP SDK, they were separate objects.

  with this current SDK, the build now creates a combination image, as
explained in the User's Guide:

  U-Boot included in this release will replace the UBL which was
being used to copy U-Boot to external RAM.

  the contents of the ready-to-flash images directory in this PSP SDK
is:

u-boot-mmcsd.ais
u-boot-mmcsd.bin
u-boot-nand.ais
u-boot-nor.bin
u-boot-spi.ais

so my questions are:

1) when one flashes these images to the board, where exactly are
they being placed? in some SPI flash of some kind totally separate
from the main NOR (or, in this case, NAND) flash?

2) given that the standard NOR flash has been replaced with NAND,
which (now single) u-boot image file should i be flashing? i *think*,
from the user guide, it would be u-boot-nand.ais, as the command for
flashing to NAND flash is given as:

   ..\sfh_OMAP-L138.exe -flash_noubl -flashType NAND u-boot AIS file

it's just not clear what command i'd use for this situation, and where
that single u-boot image would end up.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding


On 02/18/2013 12:22:58 PM, Benoît Thébaudeau wrote:

On Monday, February 18, 2013 7:02:49 PM, Scott Wood wrote:
 On 02/18/2013 12:00:52 PM, Benoît Thébaudeau wrote:
  The only question is if we may need to have an empty gap between  
the

  SPL and
  U-Boot within the resulting image. I don't think so since that  
would

  mean that
  the target memory device has an area that is not really available  
at

  the
  location of this gap.

 Why not allow that possibility?

To save a config setting (there are already many for SPL) if this is  
not

strictly required, but also for the reason below.

  Maybe it's easier for the SPL to load
 from a particular offset (e.g. NAND starting at the beginning of a
 block)?

CONFIG_SPL_MAX_SIZE would be closer to a NAND mapping in that case  
(e.g. size of
1 NAND Flash block) than CONFIG_SPL_PAD_TO (address within RAM that  
should be

considered relatively to CONFIG_SPL_TEXT_BASE to get the NAND offset).


CONFIG_SPL_PAD_TO is for the placement of the payload -- and it's not a  
RAM address.  Currently it is a link address (or zero if the linker  
script handles padding, or padding is not required for other reasons).   
With your patch it it is a file offset, IIUC.


CONFIG_SPL_MAX_SIZE is what it says -- the maximum size that the SPL  
may be, ideally to be enforced by the linker script.


They are different.  An SPL wanting the payload to begin as a block  
boundary does not mean the hardware is suddenly capable of loading an  
entire block of SPL.


Also, CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE depend on each other:  
If both
can be defined, you may change one forgetting the other one, which  
could e.g.
result in an overlapping of SPL and U-Boot that won't show up at  
build time
(with CONFIG_SPL_MAX_SIZE = 0x1000 and CONFIG_SPL_PAD_TO =  
CONFIG_SPL_TEXT_BASE

+ 0x800, the SPL would build fine, and objcopy wouldn't complain).


So add a check that CONFIG_SPL_PAD_TO = CONFIG_SPL_MAX_SIZE (assuming  
the new interpretation of CONFIG_SPL_PAD_TO as a file offset), and let  
CONFIG_SPL_PAD_TO default to CONFIG_SPL_MAX_SIZE if not set.


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

Re: [U-Boot] [PATCH 0/5] Add support for using an UBI volume for environment

On Fri, Feb 08, 2013 at 02:07:21PM -0600, Joe Hershberger wrote:

 NAND is not good at handling absolute addresses to sectors for storing
 particular data.  The current implementation of the NAND env support
 works around this in several ways such as storing a pointer to the
 sector in the OOB of the first sector (interferes with some CRC) or
 supporting a range of sectors (which unless it is huge is not
 guaranteed to be safe).  None of these options address wear-leveling
 concerns or bad block handling.
 
 Accessing the u-boot env from UBI eliminates these concerns.  However,
 it does require some of the basic settings for finding the UBI env to
 be in the default u-boot env.
 
 
 Joe Hershberger (5):
   ubi: Expose a few simple functions from the cmd_ubi
   ubi: ubifs: Turn off verbose prints
   mtd: Make mtdparts work with pre-reloc env
   env: Add support for UBI environment
   env: Add redundant env support to UBI env
 
  README|  21 +
  common/Makefile   |   1 +
  common/cmd_mtdparts.c |  23 +-
  common/cmd_nvedit.c   |   7 +-
  common/cmd_ubi.c  | 149 +++---
  common/env_ubi.c  | 218 
 ++
  drivers/mtd/mtdpart.c |  14 ++--
  drivers/mtd/ubi/ubi.h |   3 +-
  fs/ubifs/ubifs.h  |   2 +-
  include/environment.h |  18 +
  include/ubi_uboot.h   |   3 +
  tools/env/fw_env.c|   6 +-
  12 files changed, 387 insertions(+), 78 deletions(-)
  create mode 100644 common/env_ubi.c

Please add a patch 6 which enables all of these options for some board,
preferably the one you've been testing this with.  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 1/1] Davinci: Make MAC address offset in EEPROM configurable CONFIG_SYS_I2C_EEPROM_MAC_OFFSET

On Fri, Feb 01, 2013 at 07:18:58AM +, Kim B??ndergaard wrote:

 ---
  arch/arm/cpu/arm926ejs/davinci/misc.c | 2 +-
  include/configs/da830evm.h| 1 +
  include/configs/davinci_dm365evm.h| 1 +
  include/configs/davinci_dm6467evm.h   | 1 +
  include/configs/davinci_dvevm.h   | 1 +
  include/configs/davinci_sffsdr.h  | 1 +
  include/configs/davinci_sonata.h  | 1 +
  7 files changed, 7 insertions(+), 1 deletion(-)

With the following addition to fix da850_am18xxevm:

diff --git a/boards.cfg b/boards.cfg
index b1319aa..e89762b 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -137,7 +137,7 @@ portuxg20arm arm926ejs   
stamp9g20   taskit
 stamp9g20arm arm926ejs   stamp9g20   
taskit at91stamp9g20:AT91SAM9G20
 cam_enc_4xx  arm arm926ejs   cam_enc_4xx ait   
 davinci cam_enc_4xx
 da830evm arm arm926ejs   da8xxevm
davincidavinci
-da850_am18xxevm  arm arm926ejs   da8xxevm
davincidavinci 
da850evm:DA850_AM18X_EVM,MAC_ADDR_IN_EEPROM,SYS_I2C_EEPROM_ADDR_LEN=2,SYS_I2C_EEPROM_ADDR=0x50
+da850_am18xxevm  arm arm926ejs   da8xxevm
davincidavinci 
da850evm:DA850_AM18X_EVM,MAC_ADDR_IN_EEPROM,SYS_I2C_EEPROM_ADDR_LEN=2,SYS_I2C_EEPROM_ADDR=0x50,SYS_I2C_EEPROM_MAC_OFFSET=0x7F00
 da850evm arm arm926ejs   da8xxevm
davincidavinci da850evm:MAC_ADDR_IN_SPIFLASH
 da850evm_direct_nor  arm arm926ejs   da8xxevm
davincidavinci da850evm:MAC_ADDR_IN_SPIFLASH,USE_NOR,DIRECT_NOR_BOOT
 davinci_dm355evm arm arm926ejs   dm355evm
davincidavinci

Applied to u-boot-ti/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding

On Monday, February 18, 2013 7:24:51 PM, Scott Wood wrote:
 On 02/18/2013 12:22:58 PM, Benoît Thébaudeau wrote:
  On Monday, February 18, 2013 7:02:49 PM, Scott Wood wrote:
   On 02/18/2013 12:00:52 PM, Benoît Thébaudeau wrote:
The only question is if we may need to have an empty gap between
  the
SPL and
U-Boot within the resulting image. I don't think so since that
  would
mean that
the target memory device has an area that is not really available
  at
the
location of this gap.
  
   Why not allow that possibility?
  
  To save a config setting (there are already many for SPL) if this is
  not
  strictly required, but also for the reason below.
  
Maybe it's easier for the SPL to load
   from a particular offset (e.g. NAND starting at the beginning of a
   block)?
  
  CONFIG_SPL_MAX_SIZE would be closer to a NAND mapping in that case
  (e.g. size of
  1 NAND Flash block) than CONFIG_SPL_PAD_TO (address within RAM that
  should be
  considered relatively to CONFIG_SPL_TEXT_BASE to get the NAND offset).
 
 CONFIG_SPL_PAD_TO is for the placement of the payload

Correct.

 -- and it's not a
 RAM address.

It doesn't have to be, but it may be for some configs.

  Currently it is a link address (or zero if the linker
 script handles padding, or padding is not required for other reasons).

Correct.

 With your patch it it is a file offset, IIUC.

With my patch, it is nothing at all since only CONFIG_SPL_MAX_SIZE is used.

 CONFIG_SPL_MAX_SIZE is what it says -- the maximum size that the SPL
 may be, ideally to be enforced by the linker script.

Correct.

 They are different.  An SPL wanting the payload to begin as a block
 boundary does not mean the hardware is suddenly capable of loading an
 entire block of SPL.

Sure, but my question is: Why would you want to have a 2-kiB SPL followed by a
126-kiB gap before the payload? Why couldn't you place the payload on the 1st
page boundary after the SPL?

If there are hardware constraints or something that make CONFIG_SPL_PAD_TO
useful in some cases, then let's use it, but otherwise, why keep it?

And if we keep it, do we change it to an image offset, or do we keep it as a
link address?

  Also, CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE depend on each other:
  If both
  can be defined, you may change one forgetting the other one, which
  could e.g.
  result in an overlapping of SPL and U-Boot that won't show up at
  build time
  (with CONFIG_SPL_MAX_SIZE = 0x1000 and CONFIG_SPL_PAD_TO =
  CONFIG_SPL_TEXT_BASE
  + 0x800, the SPL would build fine, and objcopy wouldn't complain).
 
 So add a check that CONFIG_SPL_PAD_TO = CONFIG_SPL_MAX_SIZE (assuming
 the new interpretation of CONFIG_SPL_PAD_TO as a file offset), and let
 CONFIG_SPL_PAD_TO default to CONFIG_SPL_MAX_SIZE if not set.

That would make sense. The current default value of 0 for CONFIG_SPL_PAD_TO does
not make sense since it means that the SPL can't know where the payload is
located within the image.

Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] imx6, spl and falcon boot

2013-02-18 Thread Chaves, Kevin

Ok is there documentation anywhere that can show the requirements for 
supporting SPL if I'd like to be able to implement it, same with falcon mode? 
I've already got support for nitrogen6x through another vendor but they won't 
support the spl.

I'm taking a look at board/woodburn/woodburn.c to see what was done for another 
board that supports SPL. It just looks like void board_init_f(ulong dummy) 
needs to be implemented for the SPL. 

Someone recommend I look at another set of patch notes that have better docs, 
but I see it mostly has the falcon mode in it. 
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/146987/focus=147040

-Original Message-
From: Dirk Behme [mailto:dirk.be...@gmail.com] 
Sent: Saturday, February 16, 2013 2:32 AM
To: Chaves, Kevin
Cc: u-boot@lists.denx.de; Eric Nelson
Subject: Re: [U-Boot] imx6, spl and falcon boot

Am 15.02.2013 21:45, schrieb Chaves, Kevin:

 Hi,

 First off, sorry I'm not used to using mailing lists. I'm not sure if this is 
 the best way to dig for information. We've recently switched to uboot/linux 
 from wince and I'm trying to understand how configuring uboot works. I'm also 
 trying to find out how to use the SPL framework and possibly falcon mode with 
 a i.mx6 nitrogen6x board. I'd be delighted if any one could help!

I haven't used spl and falcon mode, so I can't help with these.

Regarding the general support for the i.mx6 nitrogen6x this isn't in U-Boot 
mainline, yet.

Try to git pull the most recent U-Boot mainline from 
git://git.denx.de/u-boot.git [1] and apply the patch

http://patchwork.ozlabs.org/patch/216991/

You should then be able to build one of the supported boards

nitrogen6q
nitrogen6dl
nitrogen6s
nitrogen6q2g
nitrogen6dl2g
nitrogen6s1g

by

make nitrogen6xxx_config
make

(replace the 'xxx' with the ending matching your board, e.g. 'q' if you have a 
Quad board).

Best regards

Dirk

[1] http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=summary

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

Re: [U-Boot] [PATCH 1/1] Davinci: Make MAC address offset in EEPROM configurable CONFIG_SYS_I2C_EEPROM_MAC_OFFSET

On Mon, Feb 18, 2013 at 01:39:45PM -0500, Tom Rini wrote:
 On Fri, Feb 01, 2013 at 07:18:58AM +, Kim B??ndergaard wrote:
 
  ---
   arch/arm/cpu/arm926ejs/davinci/misc.c | 2 +-
   include/configs/da830evm.h| 1 +
   include/configs/davinci_dm365evm.h| 1 +
   include/configs/davinci_dm6467evm.h   | 1 +
   include/configs/davinci_dvevm.h   | 1 +
   include/configs/davinci_sffsdr.h  | 1 +
   include/configs/davinci_sonata.h  | 1 +
   7 files changed, 7 insertions(+), 1 deletion(-)
 
 With the following addition to fix da850_am18xxevm:
 
 diff --git a/boards.cfg b/boards.cfg
 index b1319aa..e89762b 100644
 --- a/boards.cfg
 +++ b/boards.cfg
 @@ -137,7 +137,7 @@ portuxg20arm arm926ejs   
 stamp9g20   taskit
  stamp9g20arm arm926ejs   stamp9g20   
 taskit at91stamp9g20:AT91SAM9G20
  cam_enc_4xx  arm arm926ejs   cam_enc_4xx ait 
davinci cam_enc_4xx
  da830evm arm arm926ejs   da8xxevm
 davincidavinci
 -da850_am18xxevm  arm arm926ejs   da8xxevm
 davincidavinci 
 da850evm:DA850_AM18X_EVM,MAC_ADDR_IN_EEPROM,SYS_I2C_EEPROM_ADDR_LEN=2,SYS_I2C_EEPROM_ADDR=0x50
 +da850_am18xxevm  arm arm926ejs   da8xxevm
 davincidavinci 
 da850evm:DA850_AM18X_EVM,MAC_ADDR_IN_EEPROM,SYS_I2C_EEPROM_ADDR_LEN=2,SYS_I2C_EEPROM_ADDR=0x50,SYS_I2C_EEPROM_MAC_OFFSET=0x7F00
  da850evm arm arm926ejs   da8xxevm
 davincidavinci da850evm:MAC_ADDR_IN_SPIFLASH
  da850evm_direct_nor  arm arm926ejs   da8xxevm
 davincidavinci 
 da850evm:MAC_ADDR_IN_SPIFLASH,USE_NOR,DIRECT_NOR_BOOT
  davinci_dm355evm arm arm926ejs   dm355evm
 davincidavinci
 
 Applied to u-boot-ti/master, thanks!

Blarg, I take it back.  It's not applied as I see you didn't include a
Signed-off-by line.  Please incorporate the above change which is:
Signed-off-by: Tom Rini tr...@ti.com
and submit a v3, assuming the rules for a Signed-off-by-line are true.

-- 
Tom


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

[U-Boot] [PATCH] arm: pxa: Add support for ICP DAS LP-8x4x

2013-02-18 Thread Sergey Yanovich

LP-8x4x is a programmable automation controller by ICP DAS. It is
shipped with outdated U-Boot v1.3.0

This patch adds enough supports to boot the board:
 - 128M of 128M SDRAM
 - 32M of 48M NOR Flash memory
 - 1 of 4 Serial console (PXA FFUART)
 - 1 of 2 Ethernet controller (DM9000)

Signed-off-by: Sergey Yanovich ynv...@gmail.com
---
 arch/arm/include/asm/mach-types.h |   13 ++
 board/icpdas/lp8x4x/Makefile  |   41 ++
 board/icpdas/lp8x4x/lp8x4x.c  |  133 ++
 boards.cfg|1 +
 include/configs/lp8x4x.h  |  272 +
 5 files changed, 460 insertions(+)
 create mode 100644 board/icpdas/lp8x4x/Makefile
 create mode 100644 board/icpdas/lp8x4x/lp8x4x.c
 create mode 100644 include/configs/lp8x4x.h

diff --git a/arch/arm/include/asm/mach-types.h 
b/arch/arm/include/asm/mach-types.h
index a676b6d..644b937 100644
--- a/arch/arm/include/asm/mach-types.h
+++ b/arch/arm/include/asm/mach-types.h
@@ -1107,6 +1107,7 @@ extern unsigned int __machine_arch_type;
 #define MACH_TYPE_OMAP5_SEVM   3777
 #define MACH_TYPE_ARMADILLO_800EVA 3863
 #define MACH_TYPE_KZM9G4140
+#define MACH_TYPE_LP8X4X   4539
 
 #ifdef CONFIG_ARCH_EBSA110
 # ifdef machine_arch_type
@@ -14248,6 +14249,18 @@ extern unsigned int __machine_arch_type;
 # define machine_is_kzm9g()(0)
 #endif
 
+#ifdef CONFIG_MACH_LP8X4X
+# ifdef machine_arch_type
+#  undef machine_arch_type
+#  define machine_arch_type __machine_arch_type
+# else
+#  define machine_arch_type MACH_TYPE_LP8X4X
+# endif
+# define machine_is_lp8x4x()   (machine_arch_type == MACH_TYPE_LP8X4X)
+#else
+# define machine_is_lp8x4x()   (0)
+#endif
+
 /*
  * These have not yet been registered
  */
diff --git a/board/icpdas/lp8x4x/Makefile b/board/icpdas/lp8x4x/Makefile
new file mode 100644
index 000..cbe6aa9
--- /dev/null
+++ b/board/icpdas/lp8x4x/Makefile
@@ -0,0 +1,41 @@
+#
+# ICPDAS LP-8x4x Support
+#
+# Copyright (C) 2013 Sergey Yanovich ynv...@gmail.com
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS  := lp8x4x.o
+
+SRCS   := $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/icpdas/lp8x4x/lp8x4x.c b/board/icpdas/lp8x4x/lp8x4x.c
new file mode 100644
index 000..abdb84a
--- /dev/null
+++ b/board/icpdas/lp8x4x/lp8x4x.c
@@ -0,0 +1,133 @@
+/*
+ * ICP DAS LP-8x4x Support
+ *
+ * Copyright (C) 2010 Marek Vasut marek.va...@gmail.com
+ * adapted from Voipac PXA270 Support by
+ * Copyright (C) 2013 Sergey Yanovich ynv...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include asm/arch/hardware.h
+#include asm/arch/regs-mmc.h
+#include asm/arch/pxa.h
+#include netdev.h
+#include serial.h
+#include asm/io.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * Miscelaneous platform dependent initialisations
+ */
+int board_init(void)
+{
+   /* We have RAM, disable cache */
+   dcache_disable();
+   icache_disable();
+
+   /* memory and cpu-speed are setup before relocation */
+   /* so we do _nothing_ here */
+
+   /* Arch number of lp8x4x */
+   gd-bd-bi_arch_number = MACH_TYPE_LP8X4X;
+
+   /* adress of boot parameters */
+   gd-bd-bi_boot_params = 0xa100;
+

Re: [U-Boot] [PATCH] usb: Add new command to set USB 2.0 port test modes

On Fri, Feb 15, 2013 at 05:52:45PM -0800, Julius Werner wrote:

 This patch adds a new 'usb test' command, that will set a port to a USB
 2.0 test mode (see USB 2.0 spec 7.1.20). It supports all five test modes
 on both downstream hub ports and ordinary device's upstream ports. In
 addition, it supports EHCI root hub ports. The command is guarded by the
 CONFIG_CMD_USB_TEST ifdef (disabled by default).
 
 Signed-off-by: Julius Werner jwer...@chromium.org

We need to enable this on some target as well or we're adding dead code.

-- 
Tom


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

Re: [U-Boot] [PATCH] powerpc/p1022ds: Add support for NAND and NAND boot using SPL

2013-02-18 Thread McClintock Matthew-B29882

On Fri, Feb 15, 2013 at 6:34 PM, Scott Wood scottw...@freescale.com wrote:
 On 02/14/2013 03:35:13 PM, Matthew McClintock wrote:

 +#if defined(CONFIG_SYS_BR2_PRELIM)  defined(CONFIG_SYS_OR2_PRELIM)
 +   /* for FPGA */
 +   set_lbc_br(2, CONFIG_SYS_BR2_PRELIM);
 +   set_lbc_or(2, CONFIG_SYS_OR2_PRELIM);
 +#else
 +#error CONFIG_SYS_BR2_PRELIM, CONFIG_SYS_OR2_PRELIM must be defined
 +#endif


 As discussed internally, this if/else is pointless.  In internal discussion,
 you said it was moot, and then you post it again here?

Because one of us was confused. At some point I switched over the
thinking we were talking about the ifdefs in dui.c. But, this clears
things up quite a bit - these ifdefs are not required and not sure why
there were ever put there.

 diff --git a/drivers/video/Makefile b/drivers/video/Makefile
 index 170a358..a1c7895 100644
 --- a/drivers/video/Makefile
 +++ b/drivers/video/Makefile
 @@ -34,7 +34,9 @@ COBJS-$(CONFIG_EXYNOS_FB) += exynos_fb.o exynos_fimd.o
  COBJS-$(CONFIG_EXYNOS_MIPI_DSIM) += exynos_mipi_dsi.o
 exynos_mipi_dsi_common.o \
 exynos_mipi_dsi_lowlevel.o
  COBJS-$(CONFIG_EXYNOS_PWM_BL) += exynos_pwm_bl.o
 +ifndef CONFIG_SPL_BUILD
  COBJS-$(CONFIG_FSL_DIU_FB) += fsl_diu_fb.o videomodes.o
 +endif
  COBJS-$(CONFIG_S6E8AX0) += s6e8ax0.o
  COBJS-$(CONFIG_S6E63D6) += s6e63d6.o
  COBJS-$(CONFIG_LD9040) += ld9040.o


 I thought we discussed internally that you don't need this?

Right, I tested without this but somehow lost the changes. Will fix in v2.



 +/* Nand Flash */
 +#if defined(CONFIG_NAND_FSL_ELBC)  !defined(CONFIG_FSL_DIU_FB)
 +#define CONFIG_SYS_NAND_BASE   0xff80
 +#ifdef CONFIG_PHYS_64BIT
 +#define CONFIG_SYS_NAND_BASE_PHYS  0xfff80ull
 +#else
 +#define CONFIG_SYS_NAND_BASE_PHYS  CONFIG_SYS_NAND_BASE
 +#endif


 CONFIG_FSL_DIU_FB is always defined, so when would we ever set
 CONFIG_SYS_NAND_BASE?

 +#define CONFIG_SYS_NAND_BASE_LIST { CONFIG_SYS_NAND_BASE, }


 ...and here you use it outside the ifdef.  I think the only reason that this
 builds is that CONFIG_FSL_DIU_FB is defined *after* the above check.

 Why are you introducing a new ifdefs on CONFIG_FSL_DIU_FB here in the first
 place?

Seems you are right about these bits. Not sure why this is or was ever
written like this (for reference this is several internal patches
squashed together). I'll remove the CONFIG_FSL_DIU_FB bits

 +#ifdef CONFIG_FSL_DIU_FB
 +#define CONFIG_SYS_BR1_PRELIM \
 +   (BR_PHYS_ADDR(0xe000) | BR_PS_16 | BR_V)
 +#define CONFIG_SYS_OR1_PRELIM  (OR_AM_128MB | 0xff7)
 +#endif


 Here's another -- this one is dead code.  What does this have to do with
 NAND at all?

This should have been removed. It's since been fixed by Timur's other
patch to keep the BR/OR set when using the DIU.



 @@ -177,6 +284,8 @@
  #define PIXIS_LBMAP_SWITCH 7
  #define PIXIS_LBMAP_MASK   0xF0
  #define PIXIS_LBMAP_ALTBANK0x20
 +#define PIXIS_SPD  0x07
 +#define PIXIS_SPD_SYSCLK_MASK  0x07
  #define PIXIS_ELBC_SPI_MASK0xc0
  #define PIXIS_SPI  0x80


 Relevance?

The two new lines are used in spl_minimal.c when communicating with
the PIXIS to determine what the bus_clk is for serial baud rate.

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

Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding


On 02/18/2013 12:52:51 PM, Benoît Thébaudeau wrote:

On Monday, February 18, 2013 7:24:51 PM, Scott Wood wrote:
 On 02/18/2013 12:22:58 PM, Benoît Thébaudeau wrote:
  On Monday, February 18, 2013 7:02:49 PM, Scott Wood wrote:
   On 02/18/2013 12:00:52 PM, Benoît Thébaudeau wrote:
The only question is if we may need to have an empty gap  
between

  the
SPL and
U-Boot within the resulting image. I don't think so since that
  would
mean that
the target memory device has an area that is not really  
available

  at
the
location of this gap.
  
   Why not allow that possibility?
 
  To save a config setting (there are already many for SPL) if this  
is

  not
  strictly required, but also for the reason below.
 
Maybe it's easier for the SPL to load
   from a particular offset (e.g. NAND starting at the beginning  
of a

   block)?
 
  CONFIG_SPL_MAX_SIZE would be closer to a NAND mapping in that case
  (e.g. size of
  1 NAND Flash block) than CONFIG_SPL_PAD_TO (address within RAM  
that

  should be
  considered relatively to CONFIG_SPL_TEXT_BASE to get the NAND  
offset).


 CONFIG_SPL_PAD_TO is for the placement of the payload

Correct.

 -- and it's not a
 RAM address.

It doesn't have to be, but it may be for some configs.


Right.  My point is it shouldn't be defined as a RAM address.


  Currently it is a link address (or zero if the linker
 script handles padding, or padding is not required for other  
reasons).


Correct.

 With your patch it it is a file offset, IIUC.

With my patch, it is nothing at all since only CONFIG_SPL_MAX_SIZE is  
used.


Sorry, I just meant with your change to how objcopy is invoked.  What  
you pass into objcopy is a file offset.



 CONFIG_SPL_MAX_SIZE is what it says -- the maximum size that the SPL
 may be, ideally to be enforced by the linker script.

Correct.

 They are different.  An SPL wanting the payload to begin as a block
 boundary does not mean the hardware is suddenly capable of loading  
an

 entire block of SPL.

Sure, but my question is: Why would you want to have a 2-kiB SPL  
followed by a
126-kiB gap before the payload? Why couldn't you place the payload on  
the 1st

page boundary after the SPL?


You can, and we usually do.  But size-limited SPLs may want to simplify  
(e.g. bad block detection needs some special logic to handle beginning  
inside a block), and it may not always be 126 KiB.


E.g. MPC8313ERDB uses small-page NAND, so it's only 12KiB that gets  
wasted.  It currently has MAX_SIZE of 4KiB but PAD_TO of base plus  
16KiB.


If there are hardware constraints or something that make  
CONFIG_SPL_PAD_TO

useful in some cases, then let's use it, but otherwise, why keep it?


It's easier to mainain orthogonality (and use defaults for simplicity)  
than to restore it after the fact if we need it later.


And if we keep it, do we change it to an image offset, or do we keep  
it as a

link address?


Changing to an image offset sounds good.

  Also, CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE depend on each  
other:

  If both
  can be defined, you may change one forgetting the other one, which
  could e.g.
  result in an overlapping of SPL and U-Boot that won't show up at
  build time
  (with CONFIG_SPL_MAX_SIZE = 0x1000 and CONFIG_SPL_PAD_TO =
  CONFIG_SPL_TEXT_BASE
  + 0x800, the SPL would build fine, and objcopy wouldn't complain).

 So add a check that CONFIG_SPL_PAD_TO = CONFIG_SPL_MAX_SIZE  
(assuming
 the new interpretation of CONFIG_SPL_PAD_TO as a file offset), and  
let

 CONFIG_SPL_PAD_TO default to CONFIG_SPL_MAX_SIZE if not set.

That would make sense. The current default value of 0 for  
CONFIG_SPL_PAD_TO does
not make sense since it means that the SPL can't know where the  
payload is

located within the image.


CONFIG_SPL_PAD_TO is not the mechanism that is used for finding the  
payload.  On mpc85xx it is unnecessary because the SPL will always be  
fixed size, because the reset vector goes at the end.  It's also  
possible that some SPLs could use linker symbols to find the end of the  
SPL, if they want to pack more tightly.


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

Re: [U-Boot] trying to understand u-boot-nand.ais file for AM1808 exp kit

On Mon, Feb 18, 2013 at 01:15:13PM -0500, Robert P. J. Day wrote:

   i hope someone here can clear up what should be a simple question --
 i'm trying to figure out what exactly is going on when building and
 flashing a u-boot image for my new AM1808 experimenter kit or, more
 accurately, someone else's modified version where the 8M of NOR flash
 has been replaced with 2G of NAND flash.
 
   i've downloaded the DaVinci PSP SDK (v03.22.00.02) and i'm trying to
 figure out what the prebuilt u-boot images mean, and what it means to
 flash them.

OK, for PSP related questions, please head to http://e2e.ti.com and
poke the TI folks involved.

That said, the da850_am18xxevm target in mainline works on the AM1808.
The file board/davinci/da8xxevm/README.da850 documents the how and why
and ought to be fine for NAND and was fine for SPI last time I had mine
hooked up.

-- 
Tom


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

Re: [U-Boot] [PATCH] powerpc/p1022ds: Add support for NAND and NAND boot using SPL


On 02/18/2013 01:07:53 PM, Matthew McClintock wrote:

@@ -118,6 +172,7 @@
  * Localbus non-cacheable
  * 0xe000_	0xe80f_	Promjet/free		128M  
non-cacheable
  * 0xe800_	0xefff_	FLASH			128M  
non-cacheable
+ * 0xff80_	0xff80_1fff	NAND			8K  
non-cacheable
  * 0xffdf_	0xffdf_7fff	PIXIS			32K  
non-cacheable TLB0
  * 0xffd0_	0xffd0_3fff	L1 for stack		16K  
Cacheable TLB0
  * 0xffe0_	0xffef_	CCSR			1M  
non-cacheable


This says 8K...


+/* NAND flash config */
+#define CONFIG_SYS_NAND_BR_PRELIM   
(BR_PHYS_ADDR(CONFIG_SYS_NAND_BASE_PHYS) \
+			   | (2BR_DECC_SHIFT)/* Use HW ECC */  
\
+			   | BR_PS_8	   /* Port Size = 8  
bit */ \
+			   | BR_MS_FCM	   /* MSEL = FCM */  
\

+  | BR_V) /* valid */
+#define CONFIG_SYS_NAND_OR_PRELIM  (OR_AM_256KB	   /*  
length 256K */ \

+  | OR_FCM_PGS/* Large Page*/ \
+  | OR_FCM_CSCT \
+  | OR_FCM_CST \
+  | OR_FCM_CHT \
+  | OR_FCM_SCY_1 \
+  | OR_FCM_TRLX \
+  | OR_FCM_EHTR)


...this says 256K.

IIRC the minimum for localbus is 32K.

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

Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding

Hi Scott,

On Monday, February 18, 2013 8:11:22 PM, Scott Wood wrote:
 On 02/18/2013 12:52:51 PM, Benoît Thébaudeau wrote:
  On Monday, February 18, 2013 7:24:51 PM, Scott Wood wrote:
   On 02/18/2013 12:22:58 PM, Benoît Thébaudeau wrote:
On Monday, February 18, 2013 7:02:49 PM, Scott Wood wrote:
 On 02/18/2013 12:00:52 PM, Benoît Thébaudeau wrote:
  The only question is if we may need to have an empty gap
  between
the
  SPL and
  U-Boot within the resulting image. I don't think so since that
would
  mean that
  the target memory device has an area that is not really
  available
at
  the
  location of this gap.

 Why not allow that possibility?
   
To save a config setting (there are already many for SPL) if this
  is
not
strictly required, but also for the reason below.
   
  Maybe it's easier for the SPL to load
 from a particular offset (e.g. NAND starting at the beginning
  of a
 block)?
   
CONFIG_SPL_MAX_SIZE would be closer to a NAND mapping in that case
(e.g. size of
1 NAND Flash block) than CONFIG_SPL_PAD_TO (address within RAM
  that
should be
considered relatively to CONFIG_SPL_TEXT_BASE to get the NAND
  offset).
  
   CONFIG_SPL_PAD_TO is for the placement of the payload
  
  Correct.
  
   -- and it's not a
   RAM address.
  
  It doesn't have to be, but it may be for some configs.
 
 Right.  My point is it shouldn't be defined as a RAM address.
 
Currently it is a link address (or zero if the linker
   script handles padding, or padding is not required for other
  reasons).
  
  Correct.
  
   With your patch it it is a file offset, IIUC.
  
  With my patch, it is nothing at all since only CONFIG_SPL_MAX_SIZE is
  used.
 
 Sorry, I just meant with your change to how objcopy is invoked.  What
 you pass into objcopy is a file offset.
 
   CONFIG_SPL_MAX_SIZE is what it says -- the maximum size that the SPL
   may be, ideally to be enforced by the linker script.
  
  Correct.
  
   They are different.  An SPL wanting the payload to begin as a block
   boundary does not mean the hardware is suddenly capable of loading
  an
   entire block of SPL.
  
  Sure, but my question is: Why would you want to have a 2-kiB SPL
  followed by a
  126-kiB gap before the payload? Why couldn't you place the payload on
  the 1st
  page boundary after the SPL?
 
 You can, and we usually do.  But size-limited SPLs may want to simplify
 (e.g. bad block detection needs some special logic to handle beginning
 inside a block), and it may not always be 126 KiB.
 
 E.g. MPC8313ERDB uses small-page NAND, so it's only 12KiB that gets
 wasted.  It currently has MAX_SIZE of 4KiB but PAD_TO of base plus
 16KiB.
 
  If there are hardware constraints or something that make
  CONFIG_SPL_PAD_TO
  useful in some cases, then let's use it, but otherwise, why keep it?
 
 It's easier to mainain orthogonality (and use defaults for simplicity)
 than to restore it after the fact if we need it later.
 
  And if we keep it, do we change it to an image offset, or do we keep
  it as a
  link address?
 
 Changing to an image offset sounds good.
 
Also, CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE depend on each
  other:
If both
can be defined, you may change one forgetting the other one, which
could e.g.
result in an overlapping of SPL and U-Boot that won't show up at
build time
(with CONFIG_SPL_MAX_SIZE = 0x1000 and CONFIG_SPL_PAD_TO =
CONFIG_SPL_TEXT_BASE
+ 0x800, the SPL would build fine, and objcopy wouldn't complain).
  
   So add a check that CONFIG_SPL_PAD_TO = CONFIG_SPL_MAX_SIZE
  (assuming
   the new interpretation of CONFIG_SPL_PAD_TO as a file offset), and
  let
   CONFIG_SPL_PAD_TO default to CONFIG_SPL_MAX_SIZE if not set.
  
  That would make sense. The current default value of 0 for
  CONFIG_SPL_PAD_TO does
  not make sense since it means that the SPL can't know where the
  payload is
  located within the image.
 
 CONFIG_SPL_PAD_TO is not the mechanism that is used for finding the
 payload.  On mpc85xx it is unnecessary because the SPL will always be
 fixed size, because the reset vector goes at the end.  It's also
 possible that some SPLs could use linker symbols to find the end of the
 SPL, if they want to pack more tightly.

Thanks for all the clarifications.

So I will make a v8 with CONFIG_SPL_PAD_TO as an image offset, and use it to
generate u-boot-with-spl.bin. But first, I will wait for more feedback on v7
(Fabio should give his test results this week), and for Stefano to re-sync
u-boot-imx/master with u-boot/master.

Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] powerpc/p1022ds: Add support for NAND and NAND boot using SPL

2013-02-18 Thread Matthew McClintock

Add defines needed to access NAND, remove second flash bank that is
actually connected to NAND.

Add nand booting support for P1022DS with hardcoded DDR config using
SPL framework from 2011

Signed-off-by: Matthew McClintock m...@freescale.com
Signed-off-by: Jerry Huang chang-ming.hu...@freescale.com
Signed-off-by: Jiang Yutang b14...@freescale.com
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
v2:
- remove unneeded changes to drivers/video/Makefile
- remove unneeded preprocessor usage around setting OR2/BR2
- remove stale code that is now addressed by another DIU fix

 board/freescale/common/Makefile   |6 ++
 board/freescale/p1022ds/Makefile  |   14 
 board/freescale/p1022ds/law.c |1 +
 board/freescale/p1022ds/spl_minimal.c |  129 
 board/freescale/p1022ds/tlb.c |   20 +++--
 boards.cfg|2 +
 include/configs/P1022DS.h |  132 +
 7 files changed, 284 insertions(+), 20 deletions(-)
 create mode 100644 board/freescale/p1022ds/spl_minimal.c

diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile
index 75725b4..72bb56c 100644
--- a/board/freescale/common/Makefile
+++ b/board/freescale/common/Makefile
@@ -33,10 +33,14 @@ COBJS-$(CONFIG_FSL_CADMUS)  += cadmus.o
 COBJS-$(CONFIG_FSL_VIA)+= cds_via.o
 COBJS-$(CONFIG_FMAN_ENET)  += fman.o
 COBJS-$(CONFIG_FSL_PIXIS)  += pixis.o
+ifndef CONFIG_SPL_BUILD
 COBJS-$(CONFIG_FSL_NGPIXIS)+= ngpixis.o
+endif
 COBJS-$(CONFIG_FSL_QIXIS)  += qixis.o
 COBJS-$(CONFIG_PQ_MDS_PIB) += pq-mds-pib.o
+ifndef CONFIG_SPL_BUILD
 COBJS-$(CONFIG_ID_EEPROM)  += sys_eeprom.o
+endif
 COBJS-$(CONFIG_FSL_SGMII_RISER)+= sgmii_riser.o
 ifndef CONFIG_RAMBOOT_PBL
 COBJS-$(CONFIG_FSL_FIXED_MMC_LOCATION) += sdhc_boot.o
@@ -48,7 +52,9 @@ COBJS-$(CONFIG_MPC8555CDS)+= cds_pci_ft.o
 
 COBJS-$(CONFIG_MPC8536DS)  += ics307_clk.o
 COBJS-$(CONFIG_MPC8572DS)  += ics307_clk.o
+ifndef CONFIG_SPL_BUILD
 COBJS-$(CONFIG_P1022DS)+= ics307_clk.o
+endif
 COBJS-$(CONFIG_P2020DS)+= ics307_clk.o
 COBJS-$(CONFIG_P3041DS)+= ics307_clk.o
 COBJS-$(CONFIG_P4080DS)+= ics307_clk.o
diff --git a/board/freescale/p1022ds/Makefile b/board/freescale/p1022ds/Makefile
index c6d3418..0eeef05 100644
--- a/board/freescale/p1022ds/Makefile
+++ b/board/freescale/p1022ds/Makefile
@@ -11,12 +11,26 @@ include $(TOPDIR)/config.mk
 
 LIB= $(obj)lib$(BOARD).o
 
+MINIMAL=
+
+ifdef CONFIG_SPL_BUILD
+ifdef CONFIG_SPL_INIT_MINIMAL
+MINIMAL=y
+endif
+endif
+
+ifdef MINIMAL
+
+COBJS-y+= spl_minimal.o tlb.o law.o
+
+else
 COBJS-y+= $(BOARD).o
 COBJS-y+= ddr.o
 COBJS-y+= law.o
 COBJS-y+= tlb.o
 
 COBJS-$(CONFIG_FSL_DIU_FB) += diu.o
+endif
 
 SRCS   := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
 OBJS   := $(addprefix $(obj),$(COBJS-y))
diff --git a/board/freescale/p1022ds/law.c b/board/freescale/p1022ds/law.c
index b23b8f9..feee799 100644
--- a/board/freescale/p1022ds/law.c
+++ b/board/freescale/p1022ds/law.c
@@ -16,6 +16,7 @@
 struct law_entry law_table[] = {
SET_LAW(CONFIG_SYS_FLASH_BASE_PHYS, LAW_SIZE_256M, LAW_TRGT_IF_LBC),
SET_LAW(PIXIS_BASE_PHYS, LAW_SIZE_4K, LAW_TRGT_IF_LBC),
+   SET_LAW(CONFIG_SYS_NAND_BASE_PHYS, LAW_SIZE_8K, LAW_TRGT_IF_LBC),
 };
 
 int num_law_entries = ARRAY_SIZE(law_table);
diff --git a/board/freescale/p1022ds/spl_minimal.c 
b/board/freescale/p1022ds/spl_minimal.c
new file mode 100644
index 000..8d12fa6
--- /dev/null
+++ b/board/freescale/p1022ds/spl_minimal.c
@@ -0,0 +1,129 @@
+/*
+ * Copyright 2011 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ *
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+
+#include common.h
+#include ns16550.h
+#include asm/io.h
+#include nand.h
+#include asm/fsl_law.h
+#include asm/fsl_ddr_sdram.h
+
+
+/*
+ * Fixed sdram init -- doesn't use serial presence detect.
+ */
+void sdram_init(void)
+{
+   volatile ccsr_ddr_t *ddr = (ccsr_ddr_t *)CONFIG_SYS_MPC8xxx_DDR_ADDR;
+
+   __raw_writel(CONFIG_SYS_DDR_CS0_BNDS, ddr-cs0_bnds);
+   __raw_writel(CONFIG_SYS_DDR_CS0_CONFIG, ddr-cs0_config);
+#if CONFIG_CHIP_SELECTS_PER_CTRL  1
+   __raw_writel(CONFIG_SYS_DDR_CS1_BNDS,

Re: [U-Boot] [RFC PATCH] Provide a mechanism to avoid using #ifdef everywhere

Dear Simon,

In message 1361207920-24983-1-git-send-email-...@chromium.org you wrote:
 Many parts of the U-Boot code base are sprinkled with #ifdefs. This makes
 different boards compile different versions of the source code, meaning
 that we must build all boards to check for failures. It is easy to misspell
...
 +# Create a C header file where every '#define CONFIG_XXX value' becomes
 +# '#define config_xxx() value', or '#define config_xxx() 0' where the CONFIG
 +# is not used by this board configuration. This allows C code to do things
 +# like 'if (config_xxx())' and have the compiler remove the dead code,
 +# instead of using '#ifdef CONFIG_XXX...#endif'. Note that in most cases
 +# if the config_...() returns 0 then the option is not enabled. In some rare
 +# cases such as CONFIG_BOOTDELAY, the config can be enabled but still have a
 +# a value of 0. So in addition we a #define config_xxx_enabled(), setting the
 +# value to 0 if the option is disabled, 1 if enabled. This last feature will
 +# hopefully be deprecated soon.

I think config_* is not a good name to use here - it has never been a
reserved prefix so far, so it is IMO a bad idea to turn it into one
now .  We already have quite a number such variable names in the code
all over the place (not sure I caught them all):

config_2config_io_ctrl
config_8260_ioports config_kbc_gpio
config_8560_ioports config_list
config_address  config_list_t
config_backside_crossbar_muxconfig_mpc8xx_ioports
config_base config_nfc_clk
config_bit  config_node
config_buf  config_on_ebc_cs4_is_small_flash
config_byte config_pci_bridge
config_change   config_periph_clk
config_clockconfig_pin
config_cmd_ctrl config_pll_clk
config_core_clk config_qe_ioports
config_data config_reg
config_data_eye_leveling_samplesconfig_reg_helper
config_ddr  config_s
config_ddr_clk  config_sdram
config_ddr_data config_select_P
config_ddr_phy  config_selection
config_desc config_selection_t
config_device   config_status
config_fifo config_table
config_file_sizeconfig_val
config_frontside_crossbar_vsc3316   config_val_P
config_genmii_advertconfig_validity
config_hub_port config_validity_t
config_id   config_vtp
config_instance


 +The compiler will see that config_xxx() evalutes to a constant and will
 +eliminate the dead code. The resulting code (and code size) is the same.

Did you measure the impact on compile time?

 +This takes care of almost all CONFIG macros. Unfortunately there are a few
 +cases where a value of 0 does not mean the option is disabled. For example
 +CONFIG_BOOTDELAY can be defined to 0, which means that the bootdelay
 +code should be used, but with a value of 0. To get around this and other
 +sticky cases, an addition macro with an '_enabled' suffix is provided, where
 +the value is always either 0 or 1:
 +
 + // Will work even if boaard config has '#define CONFIG_BOOTDELAY 0'
 + if (config_bootdelay_enabled())
 + do_something;
 +
 +(Probably such config options should be deprecated and then we can remove
 +this feature)

These are perfectly valid cases, I think - there are quite a number of
these, including defines for console index, PHY address, etc. etc.

 --- a/common/cmd_fitupd.c
 +++ b/common/cmd_fitupd.c
 @@ -8,6 +8,7 @@
  
  #include common.h
  #include command.h
 +#include net.h
  
  #if !defined(CONFIG_UPDATE_TFTP)
  #error CONFIG_UPDATE_TFTP required

This seems to be an unrelated change?


 diff --git a/common/main.c b/common/main.c
 index e2d2e09..cd42b67 100644
 --- a/common/main.c
 +++ b/common/main.c
...
 -#include malloc.h  /* for free() prototype */
...
 +#include malloc.h

Why dropping the comment?

 -#undef DEBUG_PARSER
 +#define DEBUG_PARSER 0   /* set to 1 to debug */
 +
 +
 +#define debug_parser(fmt, args...)   \
 + debug_cond(DEBUG_PARSER, fmt, ##args)
 +
 +#ifndef DEBUG_BOOTKEYS
 +#define DEBUG_BOOTKEYS 0
 +#endif
 +#define debug_bootkeys(fmt, args...) \
 + debug_cond(DEBUG_BOOTKEYS, fmt, ##args)

This is also a different type of changes.  Please keep such separate.

 -#ifndef CONFIG_ZERO_BOOTDELAY_CHECK
 - if (bootdelay == 0)
 + if (config_zero_bootdelay_check()  bootdelay == 0)

This appears to be plain wrong.  That was a #ifndef before...

 + if (config_autoboot_delay_str()  delaykey[0].str == NULL)
 + delaykey[0].str = config_autoboot_delay_str();

Hm constructs like these make me think about side effects.  As is,
your implementation

Re: [U-Boot] [PATCH] powerpc/p1022ds: Add support for NAND and NAND boot using SPL

2013-02-18 Thread McClintock Matthew-B29882

On Mon, Feb 18, 2013 at 1:18 PM, Scott Wood scottw...@freescale.com wrote:
 On 02/18/2013 01:07:53 PM, Matthew McClintock wrote:

 @@ -118,6 +172,7 @@
   * Localbus non-cacheable
   * 0xe000_ 0xe80f_ Promjet/free128M non-cacheable
   * 0xe800_ 0xefff_ FLASH   128M non-cacheable
 + * 0xff80_ 0xff80_1fff NAND8K non-cacheable
   * 0xffdf_ 0xffdf_7fff PIXIS   32K non-cacheable
 TLB0
   * 0xffd0_ 0xffd0_3fff L1 for stack16K Cacheable TLB0
   * 0xffe0_ 0xffef_ CCSR1M non-cacheable


 This says 8K...


 +/* NAND flash config */
 +#define CONFIG_SYS_NAND_BR_PRELIM
 (BR_PHYS_ADDR(CONFIG_SYS_NAND_BASE_PHYS) \
 +  | (2BR_DECC_SHIFT)/* Use HW ECC */ \
 +  | BR_PS_8   /* Port Size = 8
 bit */ \
 +  | BR_MS_FCM /* MSEL = FCM */ \
 +  | BR_V) /* valid */
 +#define CONFIG_SYS_NAND_OR_PRELIM  (OR_AM_256KB   /* length
 256K */ \
 +  | OR_FCM_PGS/* Large Page*/ \
 +  | OR_FCM_CSCT \
 +  | OR_FCM_CST \
 +  | OR_FCM_CHT \
 +  | OR_FCM_SCY_1 \
 +  | OR_FCM_TRLX \
 +  | OR_FCM_EHTR)


 ...this says 256K.

 IIRC the minimum for localbus is 32K.

And the law is 8K and TLB is 16K - should I go with 32K for
everything? However, I don't think 32K TLB works on this part.

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

Re: [U-Boot] [PATCH] powerpc/p1022ds: Add support for NAND and NAND boot using SPL


On 02/18/2013 01:24:44 PM, McClintock Matthew-B29882 wrote:
On Mon, Feb 18, 2013 at 1:18 PM, Scott Wood scottw...@freescale.com  
wrote:

 On 02/18/2013 01:07:53 PM, Matthew McClintock wrote:

 @@ -118,6 +172,7 @@
   * Localbus non-cacheable
   * 0xe000_ 0xe80f_ Promjet/free128M  
non-cacheable
   * 0xe800_ 0xefff_ FLASH   128M  
non-cacheable
 + * 0xff80_ 0xff80_1fff NAND8K  
non-cacheable
   * 0xffdf_ 0xffdf_7fff PIXIS   32K  
non-cacheable

 TLB0
   * 0xffd0_ 0xffd0_3fff L1 for stack16K  
Cacheable TLB0
   * 0xffe0_ 0xffef_ CCSR1M  
non-cacheable



 This says 8K...


 +/* NAND flash config */
 +#define CONFIG_SYS_NAND_BR_PRELIM
 (BR_PHYS_ADDR(CONFIG_SYS_NAND_BASE_PHYS) \
 +  | (2BR_DECC_SHIFT)/* Use HW  
ECC */ \
 +  | BR_PS_8   /* Port  
Size = 8

 bit */ \
 +  | BR_MS_FCM /* MSEL =  
FCM */ \

 +  | BR_V) /* valid */
 +#define CONFIG_SYS_NAND_OR_PRELIM  (OR_AM_256KB   /*  
length

 256K */ \
 +  | OR_FCM_PGS/* Large  
Page*/ \

 +  | OR_FCM_CSCT \
 +  | OR_FCM_CST \
 +  | OR_FCM_CHT \
 +  | OR_FCM_SCY_1 \
 +  | OR_FCM_TRLX \
 +  | OR_FCM_EHTR)


 ...this says 256K.

 IIRC the minimum for localbus is 32K.

And the law is 8K and TLB is 16K - should I go with 32K for
everything? However, I don't think 32K TLB works on this part.


You don't need to create a 32K TLB, but the documented address map  
should agree with what you put in the actual hardware (and LAWs should  
agree with ORn/BRn).


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

Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding


On 02/17/2013 10:16:49 AM, Benoît Thébaudeau wrote:

Hi Poonam, Andy,

On Friday, February 15, 2013 9:54:19 PM, Benoît Thébaudeau wrote:
 PAD_TO is not a generic SPL configuration option, so use  
CONFIG_SPL_MAX_SIZE

 instead.

 We want to use --pad-to with a size, but this option expects an  
address, so

 use
 u-boot-spl.bin instead of u-boot-spl as the input file in order to  
get

 addresses
 starting at 0.

 Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
 ---
 Changes in v7:
  - Use u-boot-spl.bin instead of u-boot-spl in order to avoid  
having to use

--change-addresses.

 Changes in v6:
  - Fix size passed to --pad-to thanks to --change-addresses.

 Changes in v5: None
 Changes in v4:
  - New patch.

 Changes in v3: None
 Changes in v2: None

  Makefile |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/Makefile b/Makefile
 index a8c7b7b..317dffc 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -486,7 +486,8 @@ $(obj)u-boot.dis:  $(obj)u-boot
$(OBJDUMP) -d $  $@

  $(obj)u-boot-with-spl.bin: $(obj)spl/u-boot-spl.bin  
$(obj)u-boot.bin
 -		$(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary  
$(obj)spl/u-boot-spl

 $(obj)spl/u-boot-spl-pad.bin
 +		$(OBJCOPY) ${OBJCFLAGS} --pad-to=$(CONFIG_SPL_MAX_SIZE)  
\
 +			-I binary -O binary $  
$(obj)spl/u-boot-spl-pad.bin

cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin  $@
rm $(obj)spl/u-boot-spl-pad.bin

I would like to let you know what is going on, and to get your  
feedback for this

patch.

include/configs/p1_p2_rdb_pc.h seems to be the only current user of
u-boot-with-spl.bin, triggered for example by the P2020RDB-PC_NAND  
config.


Before this patch, PAD_TO was used, but there is no such definition  
for this

board for generic SPL, so this board seems broken,


--pad-to= with no argument behaves the same as --pad-to=0, though  
since it's undocumented we now avoid relying on that behavior as you  
observed in a followup post.



all the more none of the
various values defined for CONFIG_SYS_TEXT_BASE relatively to
CONFIG_SPL_TEXT_BASE would be compatible with an image built by  
appending U-Boot

to the generic SPL. Can you confirm?


I don't follow.  CONFIG_SYS_TEXT_BASE is for where the payload gets  
loaded to, and has nothing to do with its position in the SPL-concat  
image, nor with the address that the SPL starts running at.


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

Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding

On Monday, February 18, 2013 8:37:29 PM, Scott Wood wrote:
 On 02/17/2013 10:16:49 AM, Benoît Thébaudeau wrote:
  Hi Poonam, Andy,
  
  On Friday, February 15, 2013 9:54:19 PM, Benoît Thébaudeau wrote:
   PAD_TO is not a generic SPL configuration option, so use
  CONFIG_SPL_MAX_SIZE
   instead.
  
   We want to use --pad-to with a size, but this option expects an
  address, so
   use
   u-boot-spl.bin instead of u-boot-spl as the input file in order to
  get
   addresses
   starting at 0.
  
   Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
   ---
   Changes in v7:
- Use u-boot-spl.bin instead of u-boot-spl in order to avoid
  having to use
  --change-addresses.
  
   Changes in v6:
- Fix size passed to --pad-to thanks to --change-addresses.
  
   Changes in v5: None
   Changes in v4:
- New patch.
  
   Changes in v3: None
   Changes in v2: None
  
Makefile |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
  
   diff --git a/Makefile b/Makefile
   index a8c7b7b..317dffc 100644
   --- a/Makefile
   +++ b/Makefile
   @@ -486,7 +486,8 @@ $(obj)u-boot.dis: $(obj)u-boot
 $(OBJDUMP) -d $  $@
  
$(obj)u-boot-with-spl.bin: $(obj)spl/u-boot-spl.bin
  $(obj)u-boot.bin
   - $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary
  $(obj)spl/u-boot-spl
   $(obj)spl/u-boot-spl-pad.bin
   + $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(CONFIG_SPL_MAX_SIZE)
  \
   + -I binary -O binary $
  $(obj)spl/u-boot-spl-pad.bin
 cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin  $@
 rm $(obj)spl/u-boot-spl-pad.bin
  
  I would like to let you know what is going on, and to get your
  feedback for this
  patch.
  
  include/configs/p1_p2_rdb_pc.h seems to be the only current user of
  u-boot-with-spl.bin, triggered for example by the P2020RDB-PC_NAND
  config.
  
  Before this patch, PAD_TO was used, but there is no such definition
  for this
  board for generic SPL, so this board seems broken,
 
 --pad-to= with no argument behaves the same as --pad-to=0, though
 since it's undocumented we now avoid relying on that behavior as you
 observed in a followup post.

OK.

  all the more none of the
  various values defined for CONFIG_SYS_TEXT_BASE relatively to
  CONFIG_SPL_TEXT_BASE would be compatible with an image built by
  appending U-Boot
  to the generic SPL. Can you confirm?
 
 I don't follow.  CONFIG_SYS_TEXT_BASE is for where the payload gets
 loaded to, and has nothing to do with its position in the SPL-concat
 image, nor with the address that the SPL starts running at.

Right, sorry, I meant CONFIG_SYS_NAND_U_BOOT_OFFS. It is 0, which is not
compatible with the payload being appended to the SPL in the programmed image.

Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding


On 02/18/2013 01:52:10 PM, Benoît Thébaudeau wrote:

On Monday, February 18, 2013 8:37:29 PM, Scott Wood wrote:
 On 02/17/2013 10:16:49 AM, Benoît Thébaudeau wrote:
  Before this patch, PAD_TO was used, but there is no such  
definition

  for this
  board for generic SPL, so this board seems broken,

 --pad-to= with no argument behaves the same as --pad-to=0,  
though

 since it's undocumented we now avoid relying on that behavior as you
 observed in a followup post.

OK.

  all the more none of the
  various values defined for CONFIG_SYS_TEXT_BASE relatively to
  CONFIG_SPL_TEXT_BASE would be compatible with an image built by
  appending U-Boot
  to the generic SPL. Can you confirm?

 I don't follow.  CONFIG_SYS_TEXT_BASE is for where the payload gets
 loaded to, and has nothing to do with its position in the SPL-concat
 image, nor with the address that the SPL starts running at.

Right, sorry, I meant CONFIG_SYS_NAND_U_BOOT_OFFS. It is 0, which is  
not
compatible with the payload being appended to the SPL in the  
programmed image.


That just means we load the whole thing, including SPL, so that we're  
always loading from the start of the block.  Note the difference  
between CONFIG_SYS_NAND_U_BOOT_DST and CONFIG_SYS_NAND_U_BOOT_START.


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

Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding

On Monday, February 18, 2013 8:47:28 PM, Scott Wood wrote:
 On 02/18/2013 01:52:10 PM, Benoît Thébaudeau wrote:
  On Monday, February 18, 2013 8:37:29 PM, Scott Wood wrote:
   On 02/17/2013 10:16:49 AM, Benoît Thébaudeau wrote:
Before this patch, PAD_TO was used, but there is no such
  definition
for this
board for generic SPL, so this board seems broken,
  
   --pad-to= with no argument behaves the same as --pad-to=0,
  though
   since it's undocumented we now avoid relying on that behavior as you
   observed in a followup post.
  
  OK.
  
all the more none of the
various values defined for CONFIG_SYS_TEXT_BASE relatively to
CONFIG_SPL_TEXT_BASE would be compatible with an image built by
appending U-Boot
to the generic SPL. Can you confirm?
  
   I don't follow.  CONFIG_SYS_TEXT_BASE is for where the payload gets
   loaded to, and has nothing to do with its position in the SPL-concat
   image, nor with the address that the SPL starts running at.
  
  Right, sorry, I meant CONFIG_SYS_NAND_U_BOOT_OFFS. It is 0, which is
  not
  compatible with the payload being appended to the SPL in the
  programmed image.
 
 That just means we load the whole thing, including SPL, so that we're
 always loading from the start of the block.  Note the difference
 between CONFIG_SYS_NAND_U_BOOT_DST and CONFIG_SYS_NAND_U_BOOT_START.

OK. Hmm, this difference is CONFIG_SPL_MAX_SIZE, but CONFIG_SPL_PAD_TO is not
defined, so the payload is right after the SPL in the image and the SPL jumps to
somewhere in the middle of the payload?

Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding


On 02/18/2013 02:01:59 PM, Benoît Thébaudeau wrote:

On Monday, February 18, 2013 8:47:28 PM, Scott Wood wrote:
 On 02/18/2013 01:52:10 PM, Benoît Thébaudeau wrote:
  On Monday, February 18, 2013 8:37:29 PM, Scott Wood wrote:
   On 02/17/2013 10:16:49 AM, Benoît Thébaudeau wrote:
all the more none of the
various values defined for CONFIG_SYS_TEXT_BASE relatively to
CONFIG_SPL_TEXT_BASE would be compatible with an image built  
by

appending U-Boot
to the generic SPL. Can you confirm?
  
   I don't follow.  CONFIG_SYS_TEXT_BASE is for where the payload  
gets
   loaded to, and has nothing to do with its position in the  
SPL-concat

   image, nor with the address that the SPL starts running at.
 
  Right, sorry, I meant CONFIG_SYS_NAND_U_BOOT_OFFS. It is 0, which  
is

  not
  compatible with the payload being appended to the SPL in the
  programmed image.

 That just means we load the whole thing, including SPL, so that  
we're

 always loading from the start of the block.  Note the difference
 between CONFIG_SYS_NAND_U_BOOT_DST and CONFIG_SYS_NAND_U_BOOT_START.

OK. Hmm, this difference is CONFIG_SPL_MAX_SIZE, but  
CONFIG_SPL_PAD_TO is not
defined, so the payload is right after the SPL in the image and the  
SPL jumps to

somewhere in the middle of the payload?


It jumps to the beginning of the payload.  As mentioned elsewhere in  
the thread, mpc85xx NAND SPL is always fixed size (done in the linker  
script) because the reset vector comes at the end.  Thus, max size  
equals actual size without needing --pad-to.


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

Re: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding

On Monday, February 18, 2013 9:06:30 PM, Scott Wood wrote:
 On 02/18/2013 02:01:59 PM, Benoît Thébaudeau wrote:
  On Monday, February 18, 2013 8:47:28 PM, Scott Wood wrote:
   On 02/18/2013 01:52:10 PM, Benoît Thébaudeau wrote:
On Monday, February 18, 2013 8:37:29 PM, Scott Wood wrote:
 On 02/17/2013 10:16:49 AM, Benoît Thébaudeau wrote:
  all the more none of the
  various values defined for CONFIG_SYS_TEXT_BASE relatively to
  CONFIG_SPL_TEXT_BASE would be compatible with an image built
  by
  appending U-Boot
  to the generic SPL. Can you confirm?

 I don't follow.  CONFIG_SYS_TEXT_BASE is for where the payload
  gets
 loaded to, and has nothing to do with its position in the
  SPL-concat
 image, nor with the address that the SPL starts running at.
   
Right, sorry, I meant CONFIG_SYS_NAND_U_BOOT_OFFS. It is 0, which
  is
not
compatible with the payload being appended to the SPL in the
programmed image.
  
   That just means we load the whole thing, including SPL, so that
  we're
   always loading from the start of the block.  Note the difference
   between CONFIG_SYS_NAND_U_BOOT_DST and CONFIG_SYS_NAND_U_BOOT_START.
  
  OK. Hmm, this difference is CONFIG_SPL_MAX_SIZE, but
  CONFIG_SPL_PAD_TO is not
  defined, so the payload is right after the SPL in the image and the
  SPL jumps to
  somewhere in the middle of the payload?
 
 It jumps to the beginning of the payload.  As mentioned elsewhere in
 the thread, mpc85xx NAND SPL is always fixed size (done in the linker
 script) because the reset vector comes at the end.  Thus, max size
 equals actual size without needing --pad-to.

OK, clear.

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

Re: [U-Boot] [PATCH v5 04/23] Introduce generic link section.h symbol files

On Fri, Feb 08, 2013 at 07:12:00AM -0800, Simon Glass wrote:

 We create a separate header file for link symbols defined by the link
 scripts. It is helpful to have these all in one place and try to
 make them common across architectures. Since Linux already has a similar
 file, we bring this in even though many of the symbols there are not
 relevant to us.
 
 Each architecture has its own asm/sections.h where symbols specifc to
 that architecture can be added. For now everything except AVR32 just
 includes the generic header.
 
 One change is needed in arch/avr32/lib/board.c to make this conversion
 work.
 
 Signed-off-by: Simon Glass s...@chromium.org

Need to specify a tag/hash for where this came from in the kernel.
Also, didn't you and Wolfgang agree to drop the CREDITS file bit from
the boilerplate on new files?

Reviewed-by: Tom Rini tr...@ti.com

-- 
Tom


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

Re: [U-Boot] [PATCH v5 03/23] Replace __bss_end with bss_end

On Fri, Feb 08, 2013 at 07:11:59AM -0800, Simon Glass wrote:

 Note this is a tree-wide change affecting multiple architectures.
 
 At present we use __bss_start, but mostly __bss_end__. This seems
 inconsistent and in a number of places __bss_end is used instead.
 
 Change to use __bss_end for the BSS end symbol throughout U-Boot. This
 makes it possible to use the asm-generic/sections.h file on all
 archs.
 
 
 Signed-off-by: Simon Glass s...@chromium.org

Reviewed-by: Tom Rini tr...@ti.com

-- 
Tom


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

[U-Boot] [PATCH] powerpc/p1022ds: Add support for NAND and NAND boot using SPL

2013-02-18 Thread Matthew McClintock

Add defines needed to access NAND, remove second flash bank that is
actually connected to NAND.

Add nand booting support for P1022DS with hardcoded DDR config using
SPL framework from 2011

Signed-off-by: Matthew McClintock m...@freescale.com
Signed-off-by: Jerry Huang chang-ming.hu...@freescale.com
Signed-off-by: Jiang Yutang b14...@freescale.com
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
v2:
- remove unneeded changes to drivers/video/Makefile
- remove unneeded preprocessor usage around setting OR2/BR2
- remove stale code that is now addressed by another DIU fix
v3:
- make law and localbus sizes consistent

 board/freescale/common/Makefile   |6 ++
 board/freescale/p1022ds/Makefile  |   14 
 board/freescale/p1022ds/law.c |1 +
 board/freescale/p1022ds/spl_minimal.c |  129 
 board/freescale/p1022ds/tlb.c |   20 +++--
 boards.cfg|2 +
 include/configs/P1022DS.h |  132 +
 7 files changed, 284 insertions(+), 20 deletions(-)
 create mode 100644 board/freescale/p1022ds/spl_minimal.c

diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile
index 75725b4..72bb56c 100644
--- a/board/freescale/common/Makefile
+++ b/board/freescale/common/Makefile
@@ -33,10 +33,14 @@ COBJS-$(CONFIG_FSL_CADMUS)  += cadmus.o
 COBJS-$(CONFIG_FSL_VIA)+= cds_via.o
 COBJS-$(CONFIG_FMAN_ENET)  += fman.o
 COBJS-$(CONFIG_FSL_PIXIS)  += pixis.o
+ifndef CONFIG_SPL_BUILD
 COBJS-$(CONFIG_FSL_NGPIXIS)+= ngpixis.o
+endif
 COBJS-$(CONFIG_FSL_QIXIS)  += qixis.o
 COBJS-$(CONFIG_PQ_MDS_PIB) += pq-mds-pib.o
+ifndef CONFIG_SPL_BUILD
 COBJS-$(CONFIG_ID_EEPROM)  += sys_eeprom.o
+endif
 COBJS-$(CONFIG_FSL_SGMII_RISER)+= sgmii_riser.o
 ifndef CONFIG_RAMBOOT_PBL
 COBJS-$(CONFIG_FSL_FIXED_MMC_LOCATION) += sdhc_boot.o
@@ -48,7 +52,9 @@ COBJS-$(CONFIG_MPC8555CDS)+= cds_pci_ft.o
 
 COBJS-$(CONFIG_MPC8536DS)  += ics307_clk.o
 COBJS-$(CONFIG_MPC8572DS)  += ics307_clk.o
+ifndef CONFIG_SPL_BUILD
 COBJS-$(CONFIG_P1022DS)+= ics307_clk.o
+endif
 COBJS-$(CONFIG_P2020DS)+= ics307_clk.o
 COBJS-$(CONFIG_P3041DS)+= ics307_clk.o
 COBJS-$(CONFIG_P4080DS)+= ics307_clk.o
diff --git a/board/freescale/p1022ds/Makefile b/board/freescale/p1022ds/Makefile
index c6d3418..0eeef05 100644
--- a/board/freescale/p1022ds/Makefile
+++ b/board/freescale/p1022ds/Makefile
@@ -11,12 +11,26 @@ include $(TOPDIR)/config.mk
 
 LIB= $(obj)lib$(BOARD).o
 
+MINIMAL=
+
+ifdef CONFIG_SPL_BUILD
+ifdef CONFIG_SPL_INIT_MINIMAL
+MINIMAL=y
+endif
+endif
+
+ifdef MINIMAL
+
+COBJS-y+= spl_minimal.o tlb.o law.o
+
+else
 COBJS-y+= $(BOARD).o
 COBJS-y+= ddr.o
 COBJS-y+= law.o
 COBJS-y+= tlb.o
 
 COBJS-$(CONFIG_FSL_DIU_FB) += diu.o
+endif
 
 SRCS   := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
 OBJS   := $(addprefix $(obj),$(COBJS-y))
diff --git a/board/freescale/p1022ds/law.c b/board/freescale/p1022ds/law.c
index b23b8f9..c4398dd 100644
--- a/board/freescale/p1022ds/law.c
+++ b/board/freescale/p1022ds/law.c
@@ -16,6 +16,7 @@
 struct law_entry law_table[] = {
SET_LAW(CONFIG_SYS_FLASH_BASE_PHYS, LAW_SIZE_256M, LAW_TRGT_IF_LBC),
SET_LAW(PIXIS_BASE_PHYS, LAW_SIZE_4K, LAW_TRGT_IF_LBC),
+   SET_LAW(CONFIG_SYS_NAND_BASE_PHYS, LAW_SIZE_32K, LAW_TRGT_IF_LBC),
 };
 
 int num_law_entries = ARRAY_SIZE(law_table);
diff --git a/board/freescale/p1022ds/spl_minimal.c 
b/board/freescale/p1022ds/spl_minimal.c
new file mode 100644
index 000..8d12fa6
--- /dev/null
+++ b/board/freescale/p1022ds/spl_minimal.c
@@ -0,0 +1,129 @@
+/*
+ * Copyright 2011 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ *
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+
+#include common.h
+#include ns16550.h
+#include asm/io.h
+#include nand.h
+#include asm/fsl_law.h
+#include asm/fsl_ddr_sdram.h
+
+
+/*
+ * Fixed sdram init -- doesn't use serial presence detect.
+ */
+void sdram_init(void)
+{
+   volatile ccsr_ddr_t *ddr = (ccsr_ddr_t *)CONFIG_SYS_MPC8xxx_DDR_ADDR;
+
+   __raw_writel(CONFIG_SYS_DDR_CS0_BNDS, ddr-cs0_bnds);
+   __raw_writel(CONFIG_SYS_DDR_CS0_CONFIG, ddr-cs0_config);
+#if CONFIG_CHIP_SELECTS_PER_CTRL  1
+

Re: [U-Boot] [PATCH v7 16/19] arm926ejs: Remove deprecated and now unused NAND SPL

Hi Tom,

On Monday, February 18, 2013 5:40:21 PM, Tom Rini wrote:
 On Sun, Feb 17, 2013 at 04:51:37PM +0100, Beno??t Th??baudeau wrote:
  Hi Albert, Tom, Zhong,
  
  On Friday, February 15, 2013 9:54:22 PM, Beno??t Th??baudeau wrote:
   Signed-off-by: Beno??t Th??baudeau benoit.thebaud...@advansee.com
   ---
   Changes in v7: None
   Changes in v6:
- New patch.
   
   Changes in v5: None
   Changes in v4: None
   Changes in v3: None
   Changes in v2: None
   
arch/arm/cpu/arm926ejs/start.S |   10 --
1 file changed, 10 deletions(-)
  
  I would like to get your feedback regarding the status of the Samsung
  SMDK6400
  board:
   - It is not in boards.cfg, so, according to commit 1285a28, support for it
 should already have been removed a long time ago. It also seems to be
 the
 only board remaining in the main Makefile.
   - It uses the deprecated NAND SPL.
   - MAKEALL does not test its build, which has been broken for a while.
   - If it were removed or fixed, ARM1176's start.S' relocate_code() could be
   made
 identical to all the other implementations of this function, so all this
 duplicated code could be moved to a common location like crt0.S. Besides
 that, it would be possible to completely get rid of the legacy NAND SPL
 on
 ARM.
  
  I have no intention of fixing this board, but dropping it and cleaning up
  ARM
  after that would be easy.
 
 I'm in favor of removing and updating README.scrapyard, baring quick
 attention from the maintainer to update it to not being using the
 Makefile and fix the rest of the breakage.

OK. The s3c64xx SoC and all the drivers coming with it then become unused.
Should this be removed too? There may be out-of-tree users of this SoC.

Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v7 16/19] arm926ejs: Remove deprecated and now unused NAND SPL

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/18/2013 03:39 PM, Benoît Thébaudeau wrote:
 Hi Tom,
 
 On Monday, February 18, 2013 5:40:21 PM, Tom Rini wrote:
 On Sun, Feb 17, 2013 at 04:51:37PM +0100, Beno??t Th??baudeau 
 wrote:
 Hi Albert, Tom, Zhong,
 
 On Friday, February 15, 2013 9:54:22 PM, Beno??t Th??baudeau 
 wrote:
 Signed-off-by: Beno??t Th??baudeau 
 benoit.thebaud...@advansee.com --- Changes in v7: None 
 Changes in v6: - New patch.
 
 Changes in v5: None Changes in v4: None Changes in v3: None 
 Changes in v2: None
 
 arch/arm/cpu/arm926ejs/start.S |   10 -- 1 file 
 changed, 10 deletions(-)
 
 I would like to get your feedback regarding the status of the 
 Samsung SMDK6400 board: - It is not in boards.cfg, so, 
 according to commit 1285a28, support for it should already
 have been removed a long time ago. It also seems to be the
 only board remaining in the main Makefile. - It uses the
 deprecated NAND SPL. - MAKEALL does not test its build, which
 has been broken for a while. - If it were removed or fixed,
 ARM1176's start.S' relocate_code() could be made identical to
 all the other implementations of this function, so all this
 duplicated code could be moved to a common location like
 crt0.S. Besides that, it would be possible to completely get
 rid of the legacy NAND SPL on ARM.
 
 I have no intention of fixing this board, but dropping it and 
 cleaning up ARM after that would be easy.
 
 I'm in favor of removing and updating README.scrapyard, baring 
 quick attention from the maintainer to update it to not being 
 using the Makefile and fix the rest of the breakage.
 
 OK. The s3c64xx SoC and all the drivers coming with it then become 
 unused. Should this be removed too? There may be out-of-tree users 
 of this SoC.

Yes, it's what the scrapyard is for.  If an out-of-tree user exists
they can either support the reference board (and bring it back from
the dead) or their own board.

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRIpWVAAoJENk4IS6UOR1W8LoP/AjswbJBzJX2HkrQ2My5LSsk
SIqktkdZw68IvwqYHWNzCYow/O693dV5l3Dz+KFKQXQ/Loz6wqTolrQSKrwl8CRq
OLKLD6vcNI3Z+buNsV3Bq9+3XXM2d8T5o3U8TV3eLKzgVo6SnfsgaDEzTqs1LgvD
A0tran0YMTPhTzcHDoB4SXutRFE+Hrv8rJaRjKzQL9118kGA21NRAz46HcB+FzRo
idew5fkjo88PMoAdaKm9V0cMavH5AOAxuffUJTGSHCOZwq9MPJ4B+iWSitDKN8/I
tu2cv7tCqv/MhCsJU9JVarco0I4t4sXcjPAWMqpg1vllBBgxazLGLfLlQ3B/cx0Q
KEaAkn8iU7fxPt+FbIau/beMyi6E/PBLJ4PcTa2gLPEayRpiMBYG7VrwnIXahwuI
RcFKCJLr2XN9aYgQSmXnL9/k8Tc9Hf6bYzamjA6/Zf27GcU0TipfSNRY4fgRuQno
5r8iWv6JCJEqWc0VQG/1Lqs/oRGQ9vl1py/zHQoCV5ChM+1G4XSU7eCeJZKRREE6
abKoVhj1BJ6THdtM+0B+cqVM+gr4uGN7+wqHCsNJibKgQl1HHXDps9v72q7vYjI+
bEAcqGMOpD1+RtHm6Xsjznmaj5REGgHUQ0eO1S898TdUQlML3AbkcgS0x83GHZHE
ziLexJiV0qKbTG3O/d80
=tKpl
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers.

On Mon, Feb 18, 2013 at 11:01:42AM +0100, Lukasz Majewski wrote:
 Hi Tom,
 
  On Fri, Nov 30, 2012 at 08:01:12PM +0200, Pantelis Antoniou wrote:
  
   We didn't support upload/download larger than available memory.
   This is pretty bad when you have to update your root filesystem for
   example.
   
   This patch removes the limitation (and the crashes when you
   transfered any file larger than 4MB).
   On top of that reduces the huge dfu buffer from 4MB to just 64K,
   which was over the top.
   
   The sequence number is a 16 bit counter; make sure we
   handle rollover correctly. This fixes the wrong transfers for
   large ( 256MB) images.
   
   Also utilize a variable to handle initialization, so that we
   don't rely on just the counter sent by the host.
   
   Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
  
  To be clear, patches 1-8 are good and we should take, but this one
  means we can't use FAT/EXT* partitions without more work.  I would
  suggest that we set this part aside for a moment and perhaps limit
  transfers that are larget than RAM to RAW only where we can write in
  chunks today.
  
 
 As fair as I remember, some additional work needs to be done with
 composite.c file (to remove nasty #ifdefs). There was a problem with
 newer version of dfu-utils (new handling of descriptors). 

I see you and Pantelis talking about if some changes were really needed
in composite.c or not, but nothing about dfu-utils.  Were you objecting
to the composite.c changes because you didn't need them, or because they
in turn broke trats (can I get one of these somewhere?)  The only other
unresolved thing was about board_usb_init() which I think was settled on
trats needing to change behavior.

-- 
Tom


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

[U-Boot] [PATCH v2] Exynos5: Pinmux: Add fdt for pinmux

2013-02-18 Thread Akshay Saraswat

This patch adds fdt nodes for peripherals which require
pin muxing and configuration. Device tree bindings for pinctrl
are kept same as required for Linux. Existing pinmux code
modified to retrieve gpio range and function related info from fdt.

Depends-on: [PATCH 0/3 V2] EXYNOS5: Add GPIO numbering feature
URL: http://lists.denx.de/pipermail/u-boot/2013-January/144681.html

Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
Changes since v1:
- Device tree bindings changed to linux style.
- Added documentation for samsung pinctrl.

 arch/arm/cpu/armv7/exynos/pinmux.c   |  445 +
 arch/arm/dts/exynos5250-pinctrl.dtsi |  675 ++
 arch/arm/dts/exynos5250.dtsi |1 +
 doc/device-tree-bindings/samsung-pinctrl.txt |  253 ++
 include/fdtdec.h |1 +
 lib/fdtdec.c |1 +
 6 files changed, 1280 insertions(+), 96 deletions(-)
 create mode 100644 arch/arm/dts/exynos5250-pinctrl.dtsi
 create mode 100644 doc/device-tree-bindings/samsung-pinctrl.txt

diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c 
b/arch/arm/cpu/armv7/exynos/pinmux.c
index c79d58e..da59483 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -23,91 +23,302 @@
 
 #include common.h
 #include fdtdec.h
+#include linux/ctype.h
 #include asm/arch/gpio.h
 #include asm/arch/pinmux.h
 #include asm/arch/sromc.h
 
-static void exynos5_uart_config(int peripheral)
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Struct for storing pin function and gpio related info */
+struct pin_group {
+   void *dev_name;
+   int npins;
+   int function;
+   enum exynos5_gpio_pin gpio[];
+};
+
+static void get_pins(const struct fdt_property *fprop, struct pin_group *pgrp)
+{
+   int i;
+
+   pgrp-npins = 0;
+
+   for (i = 0; !(fprop-data[i] == (int)NULL 
+   fprop-data[i-1] == (int)NULL); i += 7) {
+   int pin_bank = -1;
+
+   if (strncmp(fprop-data + i, gpa0, 4) == 0)
+   pin_bank = GPIO_A00;
+   else if (strncmp(fprop-data + i, gpa1, 4) == 0)
+   pin_bank = GPIO_A10;
+   else if (strncmp(fprop-data + i, gpa2, 4) == 0)
+   pin_bank = GPIO_A20;
+   else if (strncmp(fprop-data + i, gpb0, 4) == 0)
+   pin_bank = GPIO_B00;
+   else if (strncmp(fprop-data + i, gpb1, 4) == 0)
+   pin_bank = GPIO_B10;
+   else if (strncmp(fprop-data + i, gpb2, 4) == 0)
+   pin_bank = GPIO_B20;
+   else if (strncmp(fprop-data + i, gpb3, 4) == 0)
+   pin_bank = GPIO_B30;
+   else if (strncmp(fprop-data + i, gpc0, 4) == 0)
+   pin_bank = GPIO_C00;
+   else if (strncmp(fprop-data + i, gpc1, 4) == 0)
+   pin_bank = GPIO_C10;
+   else if (strncmp(fprop-data + i, gpc2, 4) == 0)
+   pin_bank = GPIO_C20;
+   else if (strncmp(fprop-data + i, gpc3, 4) == 0)
+   pin_bank = GPIO_C30;
+   else if (strncmp(fprop-data + i, gpd0, 4) == 0)
+   pin_bank = GPIO_D00;
+   else if (strncmp(fprop-data + i, gpd1, 4) == 0)
+   pin_bank = GPIO_D10;
+   else if (strncmp(fprop-data + i, gpy0, 4) == 0)
+   pin_bank = GPIO_Y00;
+   else if (strncmp(fprop-data + i, gpy1, 4) == 0)
+   pin_bank = GPIO_Y10;
+   else if (strncmp(fprop-data + i, gpy2, 4) == 0)
+   pin_bank = GPIO_Y20;
+   else if (strncmp(fprop-data + i, gpy3, 4) == 0)
+   pin_bank = GPIO_Y30;
+   else if (strncmp(fprop-data + i, gpy4, 4) == 0)
+   pin_bank = GPIO_Y40;
+   else if (strncmp(fprop-data + i, gpy5, 4) == 0)
+   pin_bank = GPIO_Y50;
+   else if (strncmp(fprop-data + i, gpy6, 4) == 0)
+   pin_bank = GPIO_Y60;
+   else if (strncmp(fprop-data + i, gpc4, 4) == 0)
+   pin_bank = GPIO_C40;
+   else if (strncmp(fprop-data + i, gpx0, 4) == 0)
+   pin_bank = GPIO_X00;
+   else if (strncmp(fprop-data + i, gpx1, 4) == 0)
+   pin_bank = GPIO_X10;
+   else if (strncmp(fprop-data + i, gpx2, 4) == 0)
+   pin_bank = GPIO_X20;
+   else if (strncmp(fprop-data + i, gpx3, 4) == 0)
+   pin_bank = GPIO_X30;
+   else if (strncmp(fprop-data + i, gpe0, 4) == 0)
+   pin_bank = GPIO_E00;
+   else if (strncmp(fprop-data + i, gpe1, 4) == 0)
+   pin_bank = GPIO_E10;
+   else if

Re: [U-Boot] [RFC PATCH] Provide a mechanism to avoid using #ifdef everywhere

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/18/2013 02:23 PM, Wolfgang Denk wrote:
 Dear Simon,
 
 In message 1361207920-24983-1-git-send-email-...@chromium.org you
 wrote:
 Many parts of the U-Boot code base are sprinkled with #ifdefs.
 This makes different boards compile different versions of the
 source code, meaning that we must build all boards to check for
 failures. It is easy to misspell
 ...
 +# Create a C header file where every '#define CONFIG_XXX value'
 becomes +# '#define config_xxx() value', or '#define config_xxx()
 0' where the CONFIG +# is not used by this board configuration.
 This allows C code to do things +# like 'if (config_xxx())' and
 have the compiler remove the dead code, +# instead of using
 '#ifdef CONFIG_XXX...#endif'. Note that in most cases +# if the
 config_...() returns 0 then the option is not enabled. In some
 rare +# cases such as CONFIG_BOOTDELAY, the config can be enabled
 but still have a +# a value of 0. So in addition we a #define
 config_xxx_enabled(), setting the +# value to 0 if the option is
 disabled, 1 if enabled. This last feature will +# hopefully be
 deprecated soon.
 
 I think config_* is not a good name to use here - it has never been
 a reserved prefix so far, so it is IMO a bad idea to turn it into
 one now .  We already have quite a number such variable names in
 the code all over the place (not sure I caught them all):

Indeed.  It's not a good choice to suddenly reserve now either.
build_has_xxx() ?  I'm not sure.

[snip]
 +The compiler will see that config_xxx() evalutes to a constant
 and will +eliminate the dead code. The resulting code (and code
 size) is the same.
 
 Did you measure the impact on compile time?

Probably won't have a good handle on this without converting a whole
build target's needs (just about).

[snip]
 -#if defined CONFIG_ZERO_BOOTDELAY_CHECK /* * Check if key
 already pressed * Don't check if bootdelay  0 */ -  if (bootdelay
 = 0) { +if (config_zero_bootdelay_check()  bootdelay = 0) { 
 if (tstc()) {/* we got a key press   */ (void) getc();  /* consume
 input*/ puts (\b\b\b 0); abort = 1;/* don't auto boot  
 */ } } 
 -#endif
 
 I think code like this needs more careful editing.
 
 With the #ifdef, it was clear that the comment only applies if 
 CONFIG_ZERO_BOOTDELAY_CHECK is defined, but now it suddenly
 becomes valid _always_, which is pretty much misleading to someone
 trying to understand this code.   I think it would be necessary to
 rephrase the commend, and move it partially into the if() block.

Exactly.  This type of change will require a lot of re-commenting to
make it clear what's going on now, and after the change even more-so.

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRIp7WAAoJENk4IS6UOR1W1S0QAKzMt8KkcVdRTFElSjlze35P
PxFkO/W8YchPkzwMdhpU4UxHNYoFziLk5pLfj8hhh9uyQ7Lp0I411PZtJ+mkt3I5
RQf8xPHF9PDN2w0ZsxYKd0JE9LgFB/b9EmOOpzxy7Bge3aEGrfnhqgjNgnPGgVgO
eCcLGZLrGYlbcL9SOJNxBdFjgCxJvRfrNtsaLOJc5SveeqMNGISp6xc5WDWnmf1f
JAHNg7d9ik5d782AC76jbNUVOIp+85N0dMjhCdLR4YZBdNTC5grAW6x7gEGj+vYZ
xUE2/Y20FG1Ie3vQjbbW1gUhYtxCxjFLl+UkUOn5bf6F0eDgyUvaSt17nrO3GSbQ
hgunWaw9fZoVKMhb1WNnRHmLU5gS9rVlYGGsGibiMs1VPuiYpTLM/kuxfVitxJO0
Ysgkyotgfj2RbnKuBCkMVmvxBzIC3S2bAtxY97TwVrpEh2ZB7r2YwEKak8WhVxyQ
nMyMulgpZoMJLM3fJEcF/kQPIzsKtz1Fl/YQXGZlI2lQpohE03kAPVQDyVeTQpGA
FzGOUwVZY4WbcKrpcCV4tJOEnHRVyDR8ntQx0udMjtChaLE40fAmmUlWmWrnE4yV
SVBM+PS2d7NCXt85QpS0eMc/UdFI0v1i6R24KEHEfqQe1WEdQb1wC7XXYblutZ8z
ySlnbeEMfeDg5i5FHX46
=CF0y
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 03/23] Replace __bss_end with bss_end

On Mon, Feb 18, 2013 at 5:13 PM, Tom Rini tr...@ti.com wrote:
 On Fri, Feb 08, 2013 at 07:11:59AM -0800, Simon Glass wrote:

 Note this is a tree-wide change affecting multiple architectures.

 At present we use __bss_start, but mostly __bss_end__. This seems
 inconsistent and in a number of places __bss_end is used instead.

 Change to use __bss_end for the BSS end symbol throughout U-Boot. This
 makes it possible to use the asm-generic/sections.h file on all
 archs.


 Signed-off-by: Simon Glass s...@chromium.org

 Reviewed-by: Tom Rini tr...@ti.com

The short commit log is wrong; it say's twice __bss_end.

-- 
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854  http://projetos.ossystems.com.br
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] imx6, spl and falcon boot

2013-02-18 Thread Alexandre Belloni

Hi,

On Mon, Feb 18, 2013 at 11:44:36AM -0700, Chaves, Kevin wrote :
 Ok is there documentation anywhere that can show the requirements for 
 supporting SPL if I'd like to be able to implement it, same with falcon mode? 
 I've already got support for nitrogen6x through another vendor but they won't 
 support the spl.
 
 I'm taking a look at board/woodburn/woodburn.c to see what was done for 
 another board that supports SPL. It just looks like void board_init_f(ulong 
 dummy) needs to be implemented for the SPL. 
 
 Someone recommend I look at another set of patch notes that have better docs, 
 but I see it mostly has the falcon mode in it. 
 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/146987/focus=147040
 

i.Mx6 doen't really require an SPL as the romcode is already able to do
quite a lot. If what your are looking for is booting directly your
kernel, you can have a look at that bootloader (it is actually much
less than that):

https://github.com/alexandrebelloni/whoosh

It supports sabrelite and sabresd, it should be quite fast to port to
nitrogen6x. I can do it but I don't have access to the hardware...yet.

Regards,

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

Re: [U-Boot] imx6, spl and falcon boot

On Mon, Feb 18, 2013 at 6:36 PM, Alexandre Belloni
alexandre.bell...@piout.net wrote:
 Hi,

 On Mon, Feb 18, 2013 at 11:44:36AM -0700, Chaves, Kevin wrote :
 Ok is there documentation anywhere that can show the requirements for 
 supporting SPL if I'd like to be able to implement it, same with falcon 
 mode? I've already got support for nitrogen6x through another vendor but 
 they won't support the spl.

 I'm taking a look at board/woodburn/woodburn.c to see what was done for 
 another board that supports SPL. It just looks like void board_init_f(ulong 
 dummy) needs to be implemented for the SPL.

 Someone recommend I look at another set of patch notes that have better 
 docs, but I see it mostly has the falcon mode in it. 
 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/146987/focus=147040


 i.Mx6 doen't really require an SPL as the romcode is already able to do
 quite a lot. If what your are looking for is booting directly your
 kernel, you can have a look at that bootloader (it is actually much
 less than that):

 https://github.com/alexandrebelloni/whoosh

 It supports sabrelite and sabresd, it should be quite fast to port to
 nitrogen6x. I can do it but I don't have access to the hardware...yet.

The point of using the Falcon mode here would be to allow boot onto
interactive mode, when need, and boot fast by default. The whoosh goal
is *very* nice but it is different. :-)

-- 
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854  http://projetos.ossystems.com.br
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] imx6, spl and falcon boot

2013-02-18 Thread Chaves, Kevin

This is almost exactly what we want to do, we just want to be able to hold a 
key down during the boot and switch it to a recovery settings with a different 
kernel/rfs, would this be supported as well?

-Original Message-
From: Alexandre Belloni [mailto:alexandre.bell...@piout.net] 
Sent: Monday, February 18, 2013 4:37 PM
To: Chaves, Kevin
Cc: Dirk Behme; u-boot@lists.denx.de
Subject: Re: [U-Boot] imx6, spl and falcon boot

Hi,

On Mon, Feb 18, 2013 at 11:44:36AM -0700, Chaves, Kevin wrote :
 Ok is there documentation anywhere that can show the requirements for 
 supporting SPL if I'd like to be able to implement it, same with falcon mode? 
 I've already got support for nitrogen6x through another vendor but they won't 
 support the spl.

 I'm taking a look at board/woodburn/woodburn.c to see what was done for 
 another board that supports SPL. It just looks like void board_init_f(ulong 
 dummy) needs to be implemented for the SPL. 

 Someone recommend I look at another set of patch notes that have 
 better docs, but I see it mostly has the falcon mode in it. 
 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/146987/focus=14
 7040

i.Mx6 doen't really require an SPL as the romcode is already able to do quite a 
lot. If what your are looking for is booting directly your kernel, you can have 
a look at that bootloader (it is actually much less than that):

https://github.com/alexandrebelloni/whoosh

It supports sabrelite and sabresd, it should be quite fast to port to 
nitrogen6x. I can do it but I don't have access to the hardware...yet.

Regards,

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

Re: [U-Boot] [PATCH 12/20] common: Use new numeric setenv functions

On Wed, Dec 26, 2012 at 10:57:05AM -0800, Simon Glass wrote:

 Use setenv_ulong(), setenv_hex() and setenv_addr() in common/
 
 Signed-off-by: Simon Glass s...@chromium.org
[snip]
 diff --git a/common/cmd_fdos.c b/common/cmd_fdos.c
 index fbee861..5a35cc1 100644
 --- a/common/cmd_fdos.c
 +++ b/common/cmd_fdos.c
[snip]
 @@ -91,8 +90,7 @@ int do_fdosboot(cmd_tbl_t *cmdtp, int flag, int argc, char 
 * const argv[])
  }
  flush_cache (load_addr, size);
  
 -sprintf(buf, %x, size);
 -setenv(filesize, buf);
 + setenv_hex(filesize, size);

Tab and space mixing in the function.  I'll fix if git am
--whitespace=fix doesn't spot and fix.

-- 
Tom


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

Re: [U-Boot] [PATCH 13/20] drivers: Use new numeric setenv functions

On Wed, Dec 26, 2012 at 10:57:06AM -0800, Simon Glass wrote:

 Use setenv_ulong(), setenv_hex() and setenv_addr() in drivers/
 
 Signed-off-by: Simon Glass s...@chromium.org
 ---
  fs/fs.c  |4 +---
  fs/ubifs/ubifs.c |4 +---

fs/ not drivers/

-- 
Tom


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

Re: [U-Boot] [PATCH 16/20] Roll crc32 into hash infrastructure

On Mon, Feb 18, 2013 at 09:06:01AM -0800, Simon Glass wrote:
 Hi Wolfgang,
 
 On Mon, Feb 18, 2013 at 3:35 AM, Wolfgang Denk w...@denx.de wrote:
  Dear Tom,
 
  In message 51216721.1010...@ti.com you wrote:
 
  There's another thread I don't have yet (and I don't have this one in
  gmail yet even).  But, I am OK with custodians using their repos, but
  not the master branch, for unrelated but otherwise good patches. I'm
  also fine with patchwork bundles.  I suppose we could use the staging
  repository for these changes instead.
 
  What I mostly object about there is that these patches would go into
  mainline basicly unreviewed, as patch submission and pull request is
  all done from a single person, with no other feedback on the patches
  at all.  And this affects a lot of common code...
 
  Actually, I see this change when pulling u-boot-x86.git/master:
 
  - bloat-o-meter u-boot-before u-boot
 
 What board is this please?
 
 Some specific notes here - I think it boils down to moving crc32 into
 the hash framework. This adds some overhead, but has a few benefits.

So you're going to v2 this part?

-- 
Tom


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

Re: [U-Boot] [PATCH 0/20] Improvements to memory, hashing functions for sandbox

On Wed, Dec 26, 2012 at 10:56:53AM -0800, Simon Glass wrote:

 This series aims to get all the memory functions running correctly
 on sandbox.
 
 There was some discussion about this a while ago, and a commit was
 added to show a possible approach:
 
 355a8357 sandbox: Change md command to use map_physmem
 
 This commit was subsequently reverted because it used map_physmem()
 instead of the NOP that most architectures need for the memory functions.
 
 This series introduces map_sysmem(), a NOP on all architectures
 except sandbox. It allows us to use a ram buffer to which all U-Boot
 addresses are relative. The memory commands (including hashing) are
 updated to use this so that sandbox can now use those commands.
 
 Half of the mtest code is behind #ifdefs and there is duplication of
 some functions in both versions of the memory test. Several patches
 here clean this up a bit and get it working on sandbox.
 
 The numeric setenv_ulong() function is a useful way of avoiding a
 'char buf[17]; sprintf(buf, %ld, ...); setenv(..., buf)' sequence.
 There is also setenv_addr(). What is missing is setenv_hex() which sets
 a ulong in hex format. Add this function and then make use of it in the
 main places: common/ drivers/ and net/.
 
 The recently added and very basic hash instructure can help reduce
 code duplication in some cases. Redo the crc32 command to use this, and
 make it available through the 'hash' command. Also a few bugs were
 found in hashing with verify disabled - the arg count was not checked and
 a variable declaration was missing.
 
 To permit the memory tester to run on sandbox, we need ctrl-C to work.
 To achieve this, add a proper implementation of sandbox's tstc(), with a
 simple FIFO for character input. An os_usleep() is added to ensure that
 U-Boot does not consume infinite CPU when setting at the command prompt.
 
 With all of this it is possible to use the memory commands in sandbox, as
 well as crc32 and the other hashing commands.

So, aside from a few posted comments:
Reviewed-by: Tom Rini tr...@ti.com

And pending the answer to if you plan to v2 the hash command part (and
since everyone sets CONFIG_CMD_CRC32, we do want to be careful), I'm OK
with applying this bundle.

-- 
Tom


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

Re: [U-Boot] Please pull u-boot-x86.git

On Sun, Feb 17, 2013 at 01:32:58PM -0800, Simon Glass wrote:
 Hi Wolfgang,
 
 On Sun, Feb 17, 2013 at 12:58 PM, Wolfgang Denk w...@denx.de wrote:
  Dear Simon Glass,
 
  In message 
  capnjgz2p6sbdxiwxw2tecdjadmhkn5inbgrpzbtvwmqutyv...@mail.gmail.com you 
  wrote:
  Hi Tom,
 
  This series includes the sandbox map_sysmem() feature, and gets the
  memory and hashing functions running on sandbox to allow testing/code
  coverage. I have run it through buildman and it seems clean, with the
  proviso that I don't have fully-working toolchains for all
  architectures.
 
  NAK. It is not correct to push changes that affect global code
  through a arch-specific custodian tree, especially if the submitter
  of the patche(es) is identical to the custodian of the very tree, and
  even more so if there have been not ANY independent Acked-by: or at
  least Tested-by: messages.
 
  This is NOT how the peer review process is supposed to work!!
 
  Especially as a custodian you must not do such things.
 
 OK, I was not quite sure what to do, so may have misunderstood Tom's
 instructions - there is a short thread here
 http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/153342
 
 I have created a patchwork bundle instead.
 
 http://patchwork.ozlabs.org/bundle/sjg/sandbox-mem/

OK, I thought I said, but maybe I didn't, I'm OK with re-using the tree,
but _not_ the master branch,  u-boot-x86/sandbox would have been fine.

-- 
Tom


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

Re: [U-Boot] [PATCH v4 07/10] usb: mxs: Adapt code for i.MX23 support

2013-02-18 Thread Marek Vasut

Dear Otavio Salvador,

 The i.MX23 just one USB port so we shouldn't mess up with PLL1CTRL and
 USB1 port when building for i.MX23.
 
 Signed-off-by: Otavio Salvador ota...@ossystems.com.br
 ---
 Changes in v4:
 - Rework soc_ehci_hcd_{enable,disable}_clock to mxs_ehci_hcd_clock (Fabio /
 Marek)
 
 Changes in v3:
 - Improve commit log
 - Move code to enable/disable clock to soc_ehci_hcd_{enable,disable}_clock
 - Proper use mx23 clock registers
 
 Changes in v2:
 - Avoid wrong clock setting in MX23
 
  drivers/usb/host/ehci-mxs.c | 58
 +++-- 1 file changed, 35
 insertions(+), 23 deletions(-)
 
 diff --git a/drivers/usb/host/ehci-mxs.c b/drivers/usb/host/ehci-mxs.c
 index 5062af5..45333ce 100644
 --- a/drivers/usb/host/ehci-mxs.c
 +++ b/drivers/usb/host/ehci-mxs.c
 @@ -23,7 +23,11 @@
  #include asm/io.h
  #include asm/arch/regs-common.h
  #include asm/arch/regs-base.h
 +#if defined(CONFIG_MX23)
 +#include asm/arch/regs-clkctrl-mx23.h
 +#elif defined(CONFIG_MX28)
  #include asm/arch/regs-clkctrl-mx28.h
 +#endif

This should be handled automatically in imx-regs.h no ? I believe all this regs-
xxx.h crap should just be part of imx-regs.h and none of that should be here at 
all.

  #include asm/arch/regs-usb.h
  #include asm/arch/regs-usbphy.h
 
 @@ -50,10 +54,12 @@ int mxs_ehci_get_port(struct ehci_mxs *mxs_usb, int
 port) usb_base = MXS_USBCTRL0_BASE;
   phy_base = MXS_USBPHY0_BASE;
   break;
 +#ifdef CONFIG_MX28
   case 1:
   usb_base = MXS_USBCTRL1_BASE;
   phy_base = MXS_USBPHY1_BASE;
   break;
 +#endif
   default:
   printf(CONFIG_EHCI_MXS_PORT (port = %d)\n, port);
   return -1;
 @@ -67,17 +73,40 @@ int mxs_ehci_get_port(struct ehci_mxs *mxs_usb, int
 port) /* This DIGCTL register ungates clock to USB */
  #define  HW_DIGCTL_CTRL  0x8001c000
  #define  HW_DIGCTL_CTRL_USB0_CLKGATE (1  2)
 +#ifdef CONFIG_MX28
  #define  HW_DIGCTL_CTRL_USB1_CLKGATE (1  16)
 +#endif
 
 -int ehci_hcd_init(int index, struct ehci_hccr **hccr, struct ehci_hcor
 **hcor) +static void mxs_ehci_hcd_clock(bool enable)

I wonder if this shall not go to arch/arm.../mxs/clock.c ?

I'd say, pass also int index argument and call it twice for mx28 and once for 
mx23. That'd align well with the multi-controller stuff.

  {
 -
 - int ret;
 - uint32_t usb_base, cap_base;
   struct mxs_register_32 *digctl_ctrl =
   (struct mxs_register_32 *)HW_DIGCTL_CTRL;
   struct mxs_clkctrl_regs *clkctrl_regs =
   (struct mxs_clkctrl_regs *)MXS_CLKCTRL_BASE;
 + uint32_t reg = HW_DIGCTL_CTRL_USB0_CLKGATE;
 +
 + writel(CLKCTRL_PLL0CTRL0_EN_USB_CLKS | CLKCTRL_PLL0CTRL0_POWER,
 +(enable ? clkctrl_regs-hw_clkctrl_pll0ctrl0_set : \
 + clkctrl_regs-hw_clkctrl_pll0ctrl0_clr));
 +
 +#ifdef CONFIG_MX28
 + /* i.MX28 has two USB controllers */
 + reg |= HW_DIGCTL_CTRL_USB1_CLKGATE;
 +
 + writel(CLKCTRL_PLL1CTRL0_EN_USB_CLKS | CLKCTRL_PLL1CTRL0_POWER,
 +(enable ? clkctrl_regs-hw_clkctrl_pll1ctrl0_set : \
 + clkctrl_regs-hw_clkctrl_pll1ctrl0_clr));
 +#endif
 +
 + /* Gate/gateoff the USB clock */
 + writel(reg, (enable ? digctl_ctrl-reg_clr : \
 +  digctl_ctrl-reg_set));

Uh ... uh ... uh ...

No, kill the ternary operators. Good old if (enable)  else  please.

Something like (imprecise code warning):

if (enable)
   reg_offset = offsetof(mxs_register32, set);
else
   reg_offset = offsetof(mxs_register32, clk);

do_all_the_stuff here, all writel(val, mxs_register32 + offset); like this 
example.

 +}
 +
 +int ehci_hcd_init(int index, struct ehci_hccr **hccr, struct ehci_hcor
 **hcor) +{
 + int ret;
 + uint32_t usb_base, cap_base;
 
   ret = mxs_ehci_get_port(ehci_mxs, CONFIG_EHCI_MXS_PORT);
   if (ret)
 @@ -90,13 +119,7 @@ int ehci_hcd_init(int index, struct ehci_hccr **hccr,
 struct ehci_hcor **hcor) ehci_mxs.phy_regs-hw_usbphy_ctrl_clr);
 
   /* Enable USB clock */
 - writel(CLKCTRL_PLL0CTRL0_EN_USB_CLKS | CLKCTRL_PLL0CTRL0_POWER,
 - clkctrl_regs-hw_clkctrl_pll0ctrl0_set);
 - writel(CLKCTRL_PLL1CTRL0_EN_USB_CLKS | CLKCTRL_PLL1CTRL0_POWER,
 - clkctrl_regs-hw_clkctrl_pll1ctrl0_set);
 -
 - writel(HW_DIGCTL_CTRL_USB0_CLKGATE | HW_DIGCTL_CTRL_USB1_CLKGATE,
 - digctl_ctrl-reg_clr);
 + mxs_ehci_hcd_clock(true);
 
   /* Start USB PHY */
   writel(0, ehci_mxs.phy_regs-hw_usbphy_pwd);
 @@ -118,10 +141,6 @@ int ehci_hcd_stop(int index)
  {
   int ret;
   uint32_t usb_base, cap_base, tmp;
 - struct mxs_register_32 *digctl_ctrl =
 - (struct mxs_register_32 *)HW_DIGCTL_CTRL;
 - struct mxs_clkctrl_regs *clkctrl_regs =
 - (struct mxs_clkctrl_regs *)MXS_CLKCTRL_BASE;
   struct ehci_hccr *hccr;
   struct

Re: [U-Boot] [PATCH v4 4/4] Tegra: MMC: Add DT support to MMC driver for all T20 boards

2013-02-18 Thread Andy Fleming

On Thu, Feb 14, 2013 at 3:04 PM, Tom Warren twarren.nvi...@gmail.comwrote:

 tegra_mmc_init() now parses the DT info for bus width, WP/CD GPIOs, etc.
 Tested on Seaboard, fully functional.

 Tamonten boards (medcom-wide, plutux, and tec) use a different/new
 dtsi file w/common settings.

 Signed-off-by: Tom Warren twar...@nvidia.com
 Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
 ---
 v2:
 - all boards now call tegra_mmc_init once, w/no params
 - count MMC controllers, not aliases
 - AD boards (medcom/plutux/tec) use common tegra20-tamonten.dtsi
 v3:
 - move any power init inside board's pin_mux_mmc function, and/or
  create pin_mux_mmc function if necessary.
 - move board_mmc_init out of each board file and into ../common/board.c
 v4:
 - remove #ifdef CONFIG_TEGRA_MMC from trimslice.c
 - fix minor whitespace issue in board/nvidia/common/board.c
 - remove marking of used node_list entries in MMC driver, not needed




 diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c
 index d749ab0..918a98d 100644
 --- a/drivers/mmc/tegra_mmc.c
 +++ b/drivers/mmc/tegra_mmc.c
 @@ -21,6 +21,7 @@

  #include bouncebuf.h
  #include common.h
 +#include fdtdec.h
  #include asm/gpio.h
  #include asm/io.h
  #include asm/arch/clock.h
 @@ -28,54 +29,23 @@
  #include asm/arch-tegra/tegra_mmc.h
  #include mmc.h

 -/* support 4 mmc hosts */
 -struct mmc mmc_dev[4];
 -struct mmc_host mmc_host[4];
 +DECLARE_GLOBAL_DATA_PTR;

 +struct mmc mmc_dev[MAX_HOSTS];
 +struct mmc_host mmc_host[MAX_HOSTS];

 -/**
 - * Get the host address and peripheral ID for a device. Devices are
 numbered
 - * from 0 to 3.
 - *
 - * @param host Structure to fill in (base, reg, mmc_id)
 - * @param dev_indexDevice index (0-3)
 - */
 -static void tegra_get_setup(struct mmc_host *host, int dev_index)
 -{
 -   debug(tegra_get_setup: dev_index = %d\n, dev_index);
 -
 -   switch (dev_index) {
 -   case 1:
 -   host-base = TEGRA_SDMMC3_BASE;
 -   host-mmc_id = PERIPH_ID_SDMMC3;
 -   break;
 -   case 2:
 -   host-base = TEGRA_SDMMC2_BASE;
 -   host-mmc_id = PERIPH_ID_SDMMC2;
 -   break;
 -   case 3:
 -   host-base = TEGRA_SDMMC1_BASE;
 -   host-mmc_id = PERIPH_ID_SDMMC1;
 -   break;
 -   case 0:
 -   default:
 -   host-base = TEGRA_SDMMC4_BASE;
 -   host-mmc_id = PERIPH_ID_SDMMC4;
 -   break;
 -   }
 -
 -   host-reg = (struct tegra_mmc *)host-base;
 -}
 +#ifndef CONFIG_OF_CONTROL
 +#error Please enable device tree support to use this driver
 +#endif

  static void mmc_prepare_data(struct mmc_host *host, struct mmc_data *data,
 struct bounce_buffer *bbstate)
  {
 unsigned char ctrl;

 -
 -   debug(buf: %p (%p), data-blocks: %u, data-blocksize: %u\n,
 -   bbstate-bounce_buffer, bbstate-user_buffer, data-blocks,
 -   data-blocksize);
 +   debug(%s: buf: %p (%p), data-blocks: %u, data-blocksize: %u\n,
 +   __func__, bbstate-bounce_buffer, bbstate-user_buffer,
 +   data-blocks, data-blocksize);



This patch is FULL of these changes. It makes it almost impossible to
identify the substantive changes to this code. In the future, please put
changes to debug output in a separate patch, unless it directly applies to
the relevant change. Also, I note that you didn't mention the fact that you
reworked all the debug() calls to prefix with the function name in your
patch description.


 +/*
 + * Process a list of nodes, adding them to our list of SDMMC ports.
 + *
 + * @param blob  fdt blob
 + * @param node_list list of nodes to process (any =0 are ignored)
 + * @param count number of nodes to process
 + * @return 0 if ok, -1 on error
 + */
 +static int process_nodes(const void *blob, int node_list[], int count)
 +{
 +   struct mmc_host *host;
 +   int i, node;
 +
 +   debug(%s: count = %d\n, __func__, count);
 +
 +   /* build mmc_host[] for each controller */
 +   for (i = 0; i  count; i++) {
 +   node = node_list[i];
 +   if (node = 0)
 +   continue;
 +
 +   host = mmc_host[i];
 +   host-id = i;
 +
 +   if (mmc_get_config(blob, node, host)) {
 +   printf(%s: failed to decode dev %d\n, __func__,
 i);
 +   return -1;
 +   }
 +   do_mmc_init(i);
 +   }
 +   return 0;
 +}
 +
 +void tegra_mmc_init(void)
 +{
 +   int node_list[MAX_HOSTS], count;
 +   const void *blob = gd-fdt_blob;
 +   debug(%s entry\n, __func__);
 +
 +   count = fdtdec_find_aliases_for_id(blob, sdhci,
 +   COMPAT_NVIDIA_TEGRA20_SDMMC, node_list, MAX_HOSTS);
 +   debug(%s: count of sdhci nodes is %d\n, __func__, count);
 +
 +   if (process_nodes(blob, node_list, count)) {
 +

Re: [U-Boot] [PATCH 16/20] Roll crc32 into hash infrastructure

Dear Simon,

In message capnjgz09okkf0qtnifkorvg37nensnlfzylblp+4jt6u_l3...@mail.gmail.com 
you wrote:
 
  - bloat-o-meter u-boot-before u-boot
 
 What board is this please?

That was TQM5200S

 This is the generic hashing command. What is happening here is that
 the crc32 command is getting a few more features, more like sha1sum.
 However, this might not be desriable - and in fact this patch changes
 the behaviour of the CRC storage and verify to support using an
 environment variable, and requiring * before the argument when an
 address is required! That needs to be fixed, at least.

Indeed - such a change of user interface must not be done here (though
it does make a lot of sense to use common code for this stuff).

 The intent is to try to unify the hashing/crc features into a single

Understood and appreciayed.

 framework. If you enable only crc32 and nothing else then this has
 quite a cost (0.5KB at present). I think I can reduce this code by
 making the full features of hash.c only available when something more
 than just crc32 is enabled. However, it might involve some #ifdefs...

Actually 0.5 k is quite heavy impact, so I guess the #ifdef's win...


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
But the only way of discovering the limits  of  the  possible  is  to
venture a little way past them into the impossible.
 - _Profiles of the Future_ (1962; rev. 1973)
  ``Hazards of Prophecy: The Failure of Imagination''
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 09/10] mx23_olinuxino: Enable USB support

2013-02-18 Thread Fabio Estevam

On Sun, Feb 17, 2013 at 4:45 PM, Otavio Salvador
ota...@ossystems.com.br wrote:

 +#ifdef CONFIG_CMD_USB
 +   /* Enable LAN9512 */
 +   gpio_direction_output(MX23_PAD_GPMI_ALE__GPIO_0_17, 1);
 +#endif

What about doing like we do with other imx devices and write something like:

gpio_direction_output(MXS_GPIO_NR(0, 17), 1);

,where

#define MXS_GPIO_NR(bank, nr)  ((bank) * 32 + (nr))

This also aligns with the kernel style.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 03/23] Replace __bss_end with bss_end

2013-02-18 Thread Andy Fleming

On Fri, Feb 8, 2013 at 9:11 AM, Simon Glass s...@chromium.org wrote:

 Note this is a tree-wide change affecting multiple architectures.

 At present we use __bss_start, but mostly __bss_end__. This seems
 inconsistent and in a number of places __bss_end is used instead.

 Change to use __bss_end for the BSS end symbol throughout U-Boot. This
 makes it possible to use the asm-generic/sections.h file on all
 archs.


 Signed-off-by: Simon Glass s...@chromium.org



Builds for all 85xx, so:

Acked-by: Andy Fleming aflem...@freescale.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-x86.git

On Mon, Feb 18, 2013 at 7:52 PM, Tom Rini tr...@ti.com wrote:
 OK, I thought I said, but maybe I didn't, I'm OK with re-using the tree,
 but _not_ the master branch,  u-boot-x86/sandbox would have been fine.

Personally I'd prefer another tree as done for other custodians. It
makes life of new developers easier.

-- 
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854  http://projetos.ossystems.com.br
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-x86.git

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/18/2013 06:30 PM, Otavio Salvador wrote:
 On Mon, Feb 18, 2013 at 7:52 PM, Tom Rini tr...@ti.com wrote:
 OK, I thought I said, but maybe I didn't, I'm OK with re-using
 the tree, but _not_ the master branch,  u-boot-x86/sandbox would
 have been fine.
 
 Personally I'd prefer another tree as done for other custodians.
 It makes life of new developers easier.

It doesn't scale, however.  If I had my wish and we were starting this
afresh, I'd go with user repositories rather than subject
repositories.  Using Simon as the example, I don't think he needs one
for sandbox, one for patman (and other tools) and one for x86.  I'd
rather pull .../sjc/for-trini/x86-whatever-vs-something.

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRIr00AAoJENk4IS6UOR1W5BsP/0XxGgvNqvp/Od5k1JnrR9EW
mqf6xRV7IZ6MXwPBAK7/WBaAerEZ79vx2KSezQxejkxzJlTYVgiltJHf9GNCM3xh
aenk/RGsyjjPmvZXTY/kR79x3/tMMdEu3xHaLb9F2a62qWfOAjQAcjqWtfwN1mSP
TOgnEenxYovihC8hqQA+Qo6PjRwTQJStGapUCwxWinXAD1CWxcp3QdlHr8I2T6Ib
TYIBSzT5iM/9LSdexh0Z8HOqQ0Mdu91znbJZCROkSWN5E9PM/oRaiXoWfSF6zWZy
mjhmI9V+Egl9SOhJU3XL6Q2Zjs98jsnQMIELczHrHFxidWjbdopYD5GOEfx59A+z
R8zZc59TSe1ocWdoJOkToy33iiXhWSUJR3ig6fmofVV7IXF/i9yO07GrlpW+CUip
GVxAUaZdSgPfNtIKXQ10zwzO3VGRgxk2eLs5zb+cMR/wc/gy8cqQY9J9GJwF/k7t
cysCzTW+iaSBaXwYSgVIscO7e7B9x+rt7Py+1MkkYegVE5N5Z2Igh8J5Z/tHe1Fi
A+GuvkcX9aytvSiBtKjqBbe0pSc10h1EfsmAfhH1F/Go94RA+58cPMNPmzN9KkBj
6+TahbMkzk5vsHcLosio6Oj0ZNS0Xo6w/XAZGyhep0gl61YSZNwUGx5pBbcQ6OPi
2I6hs4o9GUZV2id6IZU9
=dJRp
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-x86.git

On Mon, Feb 18, 2013 at 8:45 PM, Tom Rini tr...@ti.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 02/18/2013 06:30 PM, Otavio Salvador wrote:
 On Mon, Feb 18, 2013 at 7:52 PM, Tom Rini tr...@ti.com wrote:
 OK, I thought I said, but maybe I didn't, I'm OK with re-using
 the tree, but _not_ the master branch,  u-boot-x86/sandbox would
 have been fine.

 Personally I'd prefer another tree as done for other custodians.
 It makes life of new developers easier.

 It doesn't scale, however.  If I had my wish and we were starting this
 afresh, I'd go with user repositories rather than subject
 repositories.  Using Simon as the example, I don't think he needs one
 for sandbox, one for patman (and other tools) and one for x86.  I'd
 rather pull .../sjc/for-trini/x86-whatever-vs-something.

The hassle to send to separated branches is the same for different
remotes; what concerns me is a new developer to try to find patman or
sandbox pending patches and do not realize it is at x86 tree. This is
confusing.

-- 
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854  http://projetos.ossystems.com.br
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-x86.git

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/18/2013 06:48 PM, Otavio Salvador wrote:
 On Mon, Feb 18, 2013 at 8:45 PM, Tom Rini tr...@ti.com wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 On 02/18/2013 06:30 PM, Otavio Salvador wrote:
 On Mon, Feb 18, 2013 at 7:52 PM, Tom Rini tr...@ti.com
 wrote:
 OK, I thought I said, but maybe I didn't, I'm OK with
 re-using the tree, but _not_ the master branch,
 u-boot-x86/sandbox would have been fine.
 
 Personally I'd prefer another tree as done for other
 custodians. It makes life of new developers easier.
 
 It doesn't scale, however.  If I had my wish and we were starting
 this afresh, I'd go with user repositories rather than subject 
 repositories.  Using Simon as the example, I don't think he needs
 one for sandbox, one for patman (and other tools) and one for
 x86.  I'd rather pull
 .../sjc/for-trini/x86-whatever-vs-something.
 
 The hassle to send to separated branches is the same for different 
 remotes; what concerns me is a new developer to try to find patman
 or sandbox pending patches and do not realize it is at x86 tree.
 This is confusing.

It's not that great in kernel-land, I agree.  But at least for U-Boot
I hope we would be able to keep the number, and possibly as/more
importantly, the time trees are not in master (or next) but have good
things in them.

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRIr6WAAoJENk4IS6UOR1WOOsP/2mxdE/HHOF0GMhDAo9xDPqm
24NHn5286PCGbQIizbbwBIOnb0/suFLbqNIhIXaE587z4veDFwiTR74Ns85NrDvi
2IUavB0QwpSO8dwpjykOHvo5aA8DUaM6jYxXhrgnm3fsvlZJIgrOcEHtBd3xKerq
LdGrHybmjPZFhC9kK04JoICVAJb8svnWH9C+ql56QLn1/ZjwHVP3OlYv3bmx+iKG
QuBtx30CmLwciJBAq6x3LlVasm76naA9S444RFPwxH0s3Eqlsl111Z9FdtAnc2HW
VCgzU+GPgowayLSnMCf0RdXL5ho23vpOYsABOd+jKVCoK3VgEkSpyQXWk52vKD5h
pRTqBNOl7KrVaCYcB5NC+xB/5dTUpem3qfvQ6UAbElehLDfHvI82Dd7ttPl0GMsH
+aUTNdqubHtU6DmApGQDrfOyzi4u4vLSy3CX6Am/7pGpfd3h1M+gLChhLNH010H0
b9BMOWRRc8TolydImTFHuibCtEfx7HcleIujlThodTocU4aTkaUMoi3nSeJ58KcA
vPJl1Y/vR8MmuS5mQr//Lzvf+nsSxQYg18crkasPqbqiiAeCAKHBkHd7ZD+ALCxY
k9Plxpa/sx8DUqQUdgFxyDz5kAPCOli/BLdC6h/+7Yflp6HAwa/Ly6QoFYT6yGA3
79hxzWjtJ5/uravy4eKl
=5qPb
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [GIT PULL] u-boot-mpc83xx: keymile board updates