[U-Boot] [PATCH] ARM: bootm: do not add PSCI to fdt when booting in secure mode.

2014-12-21 Thread Ian Campbell 
Commit 8bc347e2ec17 ARM: bootm: Allow booting in secure mode on hyp capable
systems added the capability to select nonsec vs sec mode boot via an
environment var.

There is a subtle gotcha with this functionality, which is that the PSCI nodes
are still created in the fdt (via armv7_update_dt-fdt_psci) even when booting
in secure mode. Which means that if the kernel is PSCI aware then it will fail
to boot because it will try and do PSCI from secure world, which won't work.

This likely didn't get noticed before because the original purpose was to
support booting the legacy linux-sunxi kernels which don't understand PSCI.

To fix expose boot_nonsec (renaming with armv7_ prefix) outside of bootm.c and
use from the virt-dt code.

As well as avoiding the creation of the PSCI nodes we should also avoid
reserving the secure RAM, so do so.

Signed-off-by: Ian Campbell i...@hellion.org.uk
Cc: Hans de Goede hdego...@redhat.com
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Cc: Tom Rini tr...@ti.com
---
I think this should go into v2015.01 as a bug fix.
---
 arch/arm/cpu/armv7/virt-dt.c | 2 ++
 arch/arm/include/asm/armv7.h | 1 +
 arch/arm/lib/bootm.c | 4 ++--
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/virt-dt.c b/arch/arm/cpu/armv7/virt-dt.c
index 0b0d6a7..ad19e4c 100644
--- a/arch/arm/cpu/armv7/virt-dt.c
+++ b/arch/arm/cpu/armv7/virt-dt.c
@@ -90,6 +90,8 @@ static int fdt_psci(void *fdt)
 
 int armv7_update_dt(void *fdt)
 {
+   if (!armv7_boot_nonsec())
+   return 0;
 #ifndef CONFIG_ARMV7_SECURE_BASE
/* secure code lives in RAM, keep it alive */
fdt_add_mem_rsv(fdt, (unsigned long)__secure_start,
diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
index 323f282..a13da23 100644
--- a/arch/arm/include/asm/armv7.h
+++ b/arch/arm/include/asm/armv7.h
@@ -80,6 +80,7 @@ void v7_outer_cache_inval_range(u32 start, u32 end);
 
 int armv7_init_nonsec(void);
 int armv7_update_dt(void *fdt);
+bool armv7_boot_nonsec(void);
 
 /* defined in assembly file */
 unsigned int _nonsec_init(void);
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index a7f7c67..0c1298a 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -238,7 +238,7 @@ static void boot_prep_linux(bootm_headers_t *images)
 }
 
 #if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
-static bool boot_nonsec(void)
+bool armv7_boot_nonsec(void)
 {
char *s = getenv(bootm_boot_mode);
 #ifdef CONFIG_ARMV7_BOOT_SEC_DEFAULT
@@ -305,7 +305,7 @@ static void boot_jump_linux(bootm_headers_t *images, int 
flag)
 
if (!fake) {
 #if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
-   if (boot_nonsec()) {
+   if (armv7_boot_nonsec()) {
armv7_init_nonsec();
secure_ram_addr(_do_nonsec_entry)(kernel_entry,
  0, machid, r2);
-- 
2.1.3

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

Re: [U-Boot] [PATCH] RFC: am35xx: Rearrange SPL on am35xx

2014-12-21 Thread Tom Rini 
On Fri, Dec 19, 2014 at 08:32:35AM -0700, Simon Glass wrote:
 Hi Tom, Albert,
 
 On 19 December 2014 at 07:40, Tom Rini tr...@ti.com wrote:
  On Thu, Dec 18, 2014 at 05:21:21PM -0700, Simon Glass wrote:
 
  This is an attempt to tidy up the early SPL code in an attempt to pave
  the way for driver model in SPL:
 
  - Avoid setting up SDRAM before board_init_f()
  - Avoid touching global_data before board_init_f()
  - Allow board_init_f() to set up a new stack (seems that the SRAM stack
  is not large enough on these boards)
 
  This needs more work but it does boot on Beaglebone Black.
 
  Signed-off-by: Simon Glass s...@chromium.org
  ---
 
   arch/arm/cpu/armv7/am33xx/board.c  | 60 
  ++
   arch/arm/cpu/armv7/lowlevel_init.S |  4 ---
   arch/arm/include/asm/spl.h |  3 ++
   arch/arm/lib/crt0.S|  9 ++
   include/configs/ti_armv7_common.h  |  5 ++--
   5 files changed, 56 insertions(+), 25 deletions(-)
 
  This takes things in the wrong direction I think.  Since omap3/4/5 have
  the same problem we're going to have to duplicate a bunch of this code.
  But we can do omap_save_boot_params a bit later I'm pretty sure we can
  shove it into spl_board_init() in
  arch/arm/cpu/armv7/omap-common/boot-common.c and I'm going to do my best
  to do that today and test it on at least a few boards.
 
 I don't have a lot of background on SPL stuff as I only know one
 implementation in detail. So these comments may be a bit off.
 
 There seem to be two drivers causing this oddness:
 
 1. The need to save boot params before global_data is available. I
 wonder if it is possible to avoid overwriting the boot params, and
 save them later, in board_init_f()? If not, then I don't think the
 global_data structure should be used. A static local variable in the
 data section, with just a few fields in it, could be used instead.
 That avoids the temptation to thing that we are creating a global_data
 structure before crt0.S does it officially. If the data had just been
 stored into the data section, without messing with global_data, then I
 don't think we would have this problem.

This is actually covered today, really.  We do save_boot_params first
thing and that function must save a magic register value from ROM (or
whatever) to a stable magic location in memory.

 2. Need for more stack that can be fitted into SRAM. I think the only
 sensible option here is to change the stack after board_init_f(). As
 Albert says this should be done in crt0.S (in fact that's where I put
 my code). Forcing the dram init to before board_init_f() in SPL seems
 broken to me.

This is also covered.  The flow is cpu_init_crit - lowlevel_init (set
stack to CONFIG_SYS_INIT_SP_ADDR) - s_init (init DDR) - _main (set
stack to CONFIG_SPL_STACK, can be in DDR).

 I think we should try to have the same flow as U-Boot proper:
 
 start.S
 lowlevel_init (no stack, no global_data, no dram) - can only use
 'data' section to write stuff
 crt0.S (sets up stack and global_data, no dram)
 board_init_f (sets up dram)
 relocate stack if required (but not code)
 board_init_r (running with full stack in dram)

I suppose since old school PowerPC needed i2c to read spd eeproms it's
possible this ordering could work still today where there's a good bit
of stuff neeed in order to bring DDR on some ARM platforms.

-- 
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 2/3] usb: eth: add ASIX AX88179 DRIVER

2014-12-21 Thread Marek Vasut 
On Thursday, December 18, 2014 at 09:07:30 PM, Joe Hershberger wrote:
 On Thu, Dec 18, 2014 at 5:17 AM, Marek Vasut ma...@denx.de wrote:
  Would you pick it and submit for current release or do you want me to do
 
 it?
 
 If you can do it that would be great.

Applied 2/3 and 3/3, thank you!

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

Re: [U-Boot] [PATCH v2] arm: socfpga: Change watchdog timeout

2014-12-21 Thread Marek Vasut 
On Friday, December 19, 2014 at 01:49:10 PM, Stefan Roese wrote:
 The current current watchdog timeout of 12 seconds is a bit small for
 booting into Linux, especially when using a NFS based rootfs. So lets
 change this timeout to a more defensive value of 30 seconds.
 
 Also we now call the hw_watchdog_init() function so that we override
 the value already configured from the Preloader.
 
 Signed-off-by: Stefan Roese s...@denx.de
 Cc: Vince Bridgers vbrid...@opensource.altera.com
 Cc: Dinh Nguyen dingu...@opensource.altera.com
 Cc: Chin Liang See cl...@altera.com
 Cc: Marek Vasut ma...@denx.de
 Cc: Pavel Machek pa...@denx.de

Applied, thank you!

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

Re: [U-Boot] [PATCH] RFC: am35xx: Rearrange SPL on am35xx

2014-12-21 Thread Simon Glass 
Hi Tom,

On 21 December 2014 at 05:30, Tom Rini tr...@ti.com wrote:
 On Fri, Dec 19, 2014 at 08:32:35AM -0700, Simon Glass wrote:
 Hi Tom, Albert,

 On 19 December 2014 at 07:40, Tom Rini tr...@ti.com wrote:
  On Thu, Dec 18, 2014 at 05:21:21PM -0700, Simon Glass wrote:
 
  This is an attempt to tidy up the early SPL code in an attempt to pave
  the way for driver model in SPL:
 
  - Avoid setting up SDRAM before board_init_f()
  - Avoid touching global_data before board_init_f()
  - Allow board_init_f() to set up a new stack (seems that the SRAM stack
  is not large enough on these boards)
 
  This needs more work but it does boot on Beaglebone Black.
 
  Signed-off-by: Simon Glass s...@chromium.org
  ---
 
   arch/arm/cpu/armv7/am33xx/board.c  | 60 
  ++
   arch/arm/cpu/armv7/lowlevel_init.S |  4 ---
   arch/arm/include/asm/spl.h |  3 ++
   arch/arm/lib/crt0.S|  9 ++
   include/configs/ti_armv7_common.h  |  5 ++--
   5 files changed, 56 insertions(+), 25 deletions(-)
 
  This takes things in the wrong direction I think.  Since omap3/4/5 have
  the same problem we're going to have to duplicate a bunch of this code.
  But we can do omap_save_boot_params a bit later I'm pretty sure we can
  shove it into spl_board_init() in
  arch/arm/cpu/armv7/omap-common/boot-common.c and I'm going to do my best
  to do that today and test it on at least a few boards.

 I don't have a lot of background on SPL stuff as I only know one
 implementation in detail. So these comments may be a bit off.

 There seem to be two drivers causing this oddness:

 1. The need to save boot params before global_data is available. I
 wonder if it is possible to avoid overwriting the boot params, and
 save them later, in board_init_f()? If not, then I don't think the
 global_data structure should be used. A static local variable in the
 data section, with just a few fields in it, could be used instead.
 That avoids the temptation to thing that we are creating a global_data
 structure before crt0.S does it officially. If the data had just been
 stored into the data section, without messing with global_data, then I
 don't think we would have this problem.

 This is actually covered today, really.  We do save_boot_params first
 thing and that function must save a magic register value from ROM (or
 whatever) to a stable magic location in memory.

Ah OK. So long as it doesn't save to global_data we are fine. It could
just have a little structure somewhere in the data segment.


 2. Need for more stack that can be fitted into SRAM. I think the only
 sensible option here is to change the stack after board_init_f(). As
 Albert says this should be done in crt0.S (in fact that's where I put
 my code). Forcing the dram init to before board_init_f() in SPL seems
 broken to me.

 This is also covered.  The flow is cpu_init_crit - lowlevel_init (set
 stack to CONFIG_SYS_INIT_SP_ADDR) - s_init (init DDR) - _main (set
 stack to CONFIG_SPL_STACK, can be in DDR).

Well s_init is a board-specific thing. What I mean is that crt0.S
should set up an initial stack - there should be no stack before that.
Then board_init_f() uses the initial stack, sets up DRAM, then we move
to a second larger stack before board_init_r() is called.


 I think we should try to have the same flow as U-Boot proper:

 start.S
 lowlevel_init (no stack, no global_data, no dram) - can only use
 'data' section to write stuff
 crt0.S (sets up stack and global_data, no dram)
 board_init_f (sets up dram)
 relocate stack if required (but not code)
 board_init_r (running with full stack in dram)

 I suppose since old school PowerPC needed i2c to read spd eeproms it's
 possible this ordering could work still today where there's a good bit
 of stuff neeed in order to bring DDR on some ARM platforms.

(Note I am talking just about SPL here, as above)

I suppose what I am saying is that there is no point in setting up
DRAM before board_init_f() in SPL. There is no global_data available,
nor is there any console, so any code that happens before
board_init_f() should be absolutely essential for getting to
board_init_f(). I can't think of much that fits in that category,
maybe some clock things?

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

Re: [U-Boot] [PATCH 3/3] omap-common/hwinit-common.c: timer_init() doesn't need to touch gd

2014-12-21 Thread Simon Glass 
On 19 December 2014 at 14:52, Tom Rini tr...@ti.com wrote:
 The gd will be cleared at first so we don't need to set arch.tbl to 0.
 In addition, the checks later against lastinc also work fine with an
 initial value of 0 here.  This also brings us in line with sunxi code
 for example.

 Signed-off-by: Tom Rini tr...@ti.com
 ---
  arch/arm/cpu/armv7/omap-common/timer.c |5 -
  1 file changed, 5 deletions(-)


Reviewed-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH RFT 1/2] TI ARMv7: Don't use GD before crt0.S has set it

2014-12-21 Thread Simon Glass 
Hi Tom,

On 19 December 2014 at 14:53, Tom Rini tr...@ti.com wrote:
 Prior to this change we set the gd pointer early so that we can store
 data in it.  This becomes problematic for DM changes as well as being
 odd in general.  Re-work the code paths so that we don't need to set the
 gd pointer so early and instead can rely upon the normal setting of it.

 In order to do this we do need to move certain calls from s_init into
 spl_board_init(), mainly preloader_console_init and
 save_omap_boot_params.

 Tested on: Beaglebone Black, AM43xx GP EVM, Beagleboard, Beagleboard xM,
 OMAP5 uEVM, DRA7xx EVM
 Signed-off-by: Tom Rini tr...@ti.com

This seems like it's going in the right direction to me!

Tested on Beaglebone Black.

Tested-by: Simon Glass s...@chromium.org
Reviewed-by: Simon Glass s...@chromium.org

 ---
  arch/arm/cpu/armv7/am33xx/board.c  |   11 ---
  arch/arm/cpu/armv7/omap-common/boot-common.c   |   10 ++
  arch/arm/cpu/armv7/omap-common/hwinit-common.c |   11 ---
  arch/arm/cpu/armv7/omap3/board.c   |9 +
  4 files changed, 11 insertions(+), 30 deletions(-)

 diff --git a/arch/arm/cpu/armv7/am33xx/board.c 
 b/arch/arm/cpu/armv7/am33xx/board.c
 index eaf09d1..81477aa 100644
 --- a/arch/arm/cpu/armv7/am33xx/board.c
 +++ b/arch/arm/cpu/armv7/am33xx/board.c
 @@ -285,14 +285,6 @@ void s_init(void)
  #ifdef CONFIG_NOR_BOOT
 enable_norboot_pin_mux();
  #endif
 -   /*
 -* Save the boot parameters passed from romcode.
 -* We cannot delay the saving further than this,
 -* to prevent overwrites.
 -*/
 -#ifdef CONFIG_SPL_BUILD
 -   save_omap_boot_params();
 -#endif
 watchdog_disable();
 set_uart_mux_conf();
 setup_clocks_for_console();
 @@ -301,9 +293,6 @@ void s_init(void)
 gd-baudrate = CONFIG_BAUDRATE;
 serial_init();
 gd-have_console = 1;
 -#elif defined(CONFIG_SPL_BUILD)
 -   gd = gdata;
 -   preloader_console_init();
  #endif
  #if defined(CONFIG_SPL_AM33XX_ENABLE_RTC32K_OSC)
 /* Enable RTC32K clock */
 diff --git a/arch/arm/cpu/armv7/omap-common/boot-common.c 
 b/arch/arm/cpu/armv7/omap-common/boot-common.c
 index cb18908..3ba62db 100644
 --- a/arch/arm/cpu/armv7/omap-common/boot-common.c
 +++ b/arch/arm/cpu/armv7/omap-common/boot-common.c
 @@ -104,6 +104,16 @@ u32 spl_boot_mode(void)

  void spl_board_init(void)
  {
 +   /*
 +* Save the boot parameters passed from romcode.
 +* We cannot delay the saving further than this,
 +* to prevent overwrites.
 +*/
 +   save_omap_boot_params();
 +
 +   /* Prepare console output */
 +   preloader_console_init();
 +
  #ifdef CONFIG_SPL_NAND_SUPPORT
 gpmc_init();
  #endif
 diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c 
 b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
 index dd52e93..cb35c19 100644
 --- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
 +++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
 @@ -111,14 +111,6 @@ int arch_cpu_init(void)
   */
  void s_init(void)
  {
 -   /*
 -* Save the boot parameters passed from romcode.
 -* We cannot delay the saving further than this,
 -* to prevent overwrites.
 -*/
 -#ifdef CONFIG_SPL_BUILD
 -   save_omap_boot_params();
 -#endif
 init_omap_revision();
 hw_data_init();

 @@ -133,9 +125,6 @@ void s_init(void)
 srcomp_enable();
 setup_clocks_for_console();

 -   gd = gdata;
 -
 -   preloader_console_init();
 do_io_settings();
  #endif
 prcm_init();
 diff --git a/arch/arm/cpu/armv7/omap3/board.c 
 b/arch/arm/cpu/armv7/omap3/board.c
 index 53a9e5d..90d6ae7 100644
 --- a/arch/arm/cpu/armv7/omap3/board.c
 +++ b/arch/arm/cpu/armv7/omap3/board.c
 @@ -119,6 +119,7 @@ int board_mmc_init(bd_t *bis)

  void spl_board_init(void)
  {
 +   preloader_console_init();
  #if defined(CONFIG_SPL_NAND_SUPPORT) || defined(CONFIG_SPL_ONENAND_SUPPORT)
 gpmc_init();
  #endif
 @@ -264,14 +265,6 @@ void s_init(void)
 ehci_clocks_enable();
  #endif

 -#ifdef CONFIG_SPL_BUILD
 -   gd = gdata;
 -
 -   preloader_console_init();
 -
 -   timer_init();
 -#endif
 -
 if (!in_sdram)
 mem_init();
  }
 --
 1.7.9.5

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

Re: [U-Boot] [PATCH 2/3] am33xx: Drop timer_init call from s_init

2014-12-21 Thread Simon Glass 
On 19 December 2014 at 14:52, Tom Rini tr...@ti.com wrote:
 In both SPL and non-SPL cases we will make a call to timer_init() early
 on and do not need to call it again within s_init().

 Signed-off-by: Tom Rini tr...@ti.com
 ---
  arch/arm/cpu/armv7/am33xx/board.c |1 -
  1 file changed, 1 deletion(-)

Reviewed-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] L2 cache and LCD on sunxi

2014-12-21 Thread Simon Glass 
Hi,

I ran up a banana PI and noticed that HDMI works in U-Boot. Great!

Scrolling seems very slow though - is the L2 cache disabled perhaps?

Also are there instructions for getting an LCD running in U-Boot? I
have an Olimex A20-OLinuxion-MICRO (what a mouthful!) with a 7 inch
display if that matters. I can't find any useful information so far.

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

Re: [U-Boot] [PATCH] mmc: sunxi: Fix misuse of gpio_direction_input()

2014-12-21 Thread Simon Glass 
On 19 December 2014 at 20:41, Axel Lin axel@ingics.com wrote:
 It does not make sense to make gpio_direction_input() return the gpio input
 status. The return value of gpio_direction_input() is inconsistent if
 CONFIG_DM_GPIO is defined.
 And we don't need to call gpio_direction_input() int sunxi_mmc_getcd().
 Just init the gpio once in mmc_resource_init() is enough.

 Signed-off-by: Axel Lin axel@ingics.com
 ---
 Only compile tested, so please test this patch.
 Thanks.
  drivers/gpio/sunxi_gpio.c | 2 +-
  drivers/mmc/sunxi_mmc.c   | 7 +--
  2 files changed, 6 insertions(+), 3 deletions(-)

Reviewed-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 2/2] dm: i2c: support 10bit addressing in I2C uclass layer

2014-12-21 Thread Simon Glass 
Hi Masahiro,

On 20 December 2014 at 00:25, Masahiro YAMADA yamad...@jp.panasonic.com wrote:
 Hi Simon,


 2014-12-20 6:34 GMT+09:00 Simon Glass s...@chromium.org:
 Hi Masahiro,

 On 19 December 2014 at 11:34, Masahiro Yamada yamad...@jp.panasonic.com 
 wrote:
 Master send to / receive from 10-bit addressed slave devices
 can be supported by software layer without any hardware change
 because the LSB 8bit of the slave address is treated as data part.

 Master Send to a 10bit-addressed slave chip is performed like this:

  DIRFormat
  M-S   0 + address[9:8] + R/W(0)
  M-S   address[7:0]
  M-S   data0
  M-S   data1
   ...

 Master Receive from a 10bit-addressed slave chip is like this:

  DIRFormat
  M-S   0 + address[9:8] + R/W(0)
  M-S   address[7:0]
 (Restart)
  M-S   10 + address[9:8] + R/W(1)
  S-M   data0
  S-M   data1
   ...

 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
 Cc: Heiko Schocher h...@denx.de
 Cc: Simon Glass s...@chromium.org
 ---

  drivers/i2c/i2c-uclass.c | 80 
 +++-
  include/i2c.h|  4 +++
  2 files changed, 56 insertions(+), 28 deletions(-)

 Seems like a good idea if we can make it work...

 But this is driver-specific. Some drivers have hardware to send the
 address and it isn't part of the message. For example see the tegra
 driver.

 So what you have here feels a bit like a hack to me. Can't the driver
 implement it? If you are trying to avoid driver work to support 10-bit
 addresses, maybe it should be an option that we can enable for each
 driver, so we don't break the other drivers?


 I was writing two I2C drivers on DM,
 both of which have no dedicated hardware support for 10bit addressing.

 Of course, the driver could implement it, but it means
 I put the completely the same code in each of driver.

 For write transaction, for example, we create a new buffer and copy
 offset-address + data in Uclass layer.

 Do I have to create a new buffer again, in my driver,
 and copy  lower-slave-address + offset-address + data ?

I see your point!


 Perhaps, is it a good idea to have it optional?

 DM_I2C_FLAG_SW_TENBIT  - if set, uclass takes care of 10bit addressing
 by software
 if unset, each
 driver is responsible to handle I2C_M_TEN correctly

 altough I do think 10bit support on U-Boot is urgent necessity...

I've thought about this quite a bit. We have only just changed the API
to be the same as Linux (the list of messages). It seems wrong to now
hack it around, such that the address field only stores the first part
of the address in 10-bit mode. Did we like the API or not?

I see two options that are somewhat sane and defensible:

- Add a helper function in the uclass that the driver can call to turn
the address + message into a single stream of bytes (we can avoid a
second malloc() by reserving space for the address bytes before the
message or similar similar, so long is it is clearly documented)
- Allow the driver to request that the message bytes should always
contain the address, which would remove the address-processing code
from the driver.

I think this needs a little more discussion before we decide what to do.

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

Re: [U-Boot] [PATCH 3/5] x86: Add an API for finding pci devices in the early phase

2014-12-21 Thread Simon Glass 
Hi Bin,

On 19 December 2014 at 22:34, Bin Meng bmeng...@gmail.com wrote:
 Hi Simon,

 On Sat, Dec 20, 2014 at 12:56 PM, Simon Glass s...@chromium.org wrote:
 Hi Bin,

 On 19 December 2014 at 19:37, Bin Meng bmeng...@gmail.com wrote:

 Hi Simon,

 On Sat, Dec 20, 2014 at 5:53 AM, Simon Glass s...@chromium.org wrote:
  Hi Bin,
 
  On 19 December 2014 at 00:19, Bin Meng bmeng...@gmail.com wrote:
  This new API pci_early_find_devices() is derived from the generic
  version of pci_find_devices() with modifications required in the
  early phase (like hose, config space access routines).
 
  Signed-off-by: Bin Meng bmeng...@gmail.com
  ---
 
   arch/x86/cpu/pci.c | 41 
  +
   arch/x86/include/asm/pci.h |  2 ++
   2 files changed, 43 insertions(+)
 
  diff --git a/arch/x86/cpu/pci.c b/arch/x86/cpu/pci.c
  index 1eee08b..cdfb981 100644
  --- a/arch/x86/cpu/pci.c
  +++ b/arch/x86/cpu/pci.c
  @@ -111,3 +111,44 @@ void pci_write_config32(pci_dev_t dev, unsigned 
  where, unsigned value)
   {
  pci_hose_write_config_dword(get_hose(), dev, where, value);
   }
  +
  +pci_dev_t pci_early_find_devices(struct pci_device_id *ids, int index)
 
  Can't we just call the normal function? We have an early 'hose'...
 

 We can, but doing this way requires a large update of the
 drivers/pci/pci.c file, and requires every architecture to have an
 early hose in its global data. So that early hose becomes a generic
 feature for every arch we support, not only x86. Do you want to do
 this?

 Are you sure it requires a large update? The idea with the early PCI
 support was that it would use the same data structures, etc. and avoid
 duplicating code. In fact I avoided using the x86-specific config
 calls because I didn't want to invent a parallel API.

 Yes I think early hose should be a generic feature potentially.


 OK, I will try to make the early hose a generic feature.

OK. Perhaps it just needs to be called from x86_cpu_init_f()?

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

Re: [U-Boot] [PATCH] RFC: am35xx: Rearrange SPL on am35xx

2014-12-21 Thread Tom Rini 
On Sun, Dec 21, 2014 at 11:53:21AM -0700, Simon Glass wrote:
 Hi Tom,
 
 On 21 December 2014 at 05:30, Tom Rini tr...@ti.com wrote:
  On Fri, Dec 19, 2014 at 08:32:35AM -0700, Simon Glass wrote:
  Hi Tom, Albert,
 
  On 19 December 2014 at 07:40, Tom Rini tr...@ti.com wrote:
   On Thu, Dec 18, 2014 at 05:21:21PM -0700, Simon Glass wrote:
  
   This is an attempt to tidy up the early SPL code in an attempt to pave
   the way for driver model in SPL:
  
   - Avoid setting up SDRAM before board_init_f()
   - Avoid touching global_data before board_init_f()
   - Allow board_init_f() to set up a new stack (seems that the SRAM stack
   is not large enough on these boards)
  
   This needs more work but it does boot on Beaglebone Black.
  
   Signed-off-by: Simon Glass s...@chromium.org
   ---
  
arch/arm/cpu/armv7/am33xx/board.c  | 60 
   ++
arch/arm/cpu/armv7/lowlevel_init.S |  4 ---
arch/arm/include/asm/spl.h |  3 ++
arch/arm/lib/crt0.S|  9 ++
include/configs/ti_armv7_common.h  |  5 ++--
5 files changed, 56 insertions(+), 25 deletions(-)
  
   This takes things in the wrong direction I think.  Since omap3/4/5 have
   the same problem we're going to have to duplicate a bunch of this code.
   But we can do omap_save_boot_params a bit later I'm pretty sure we can
   shove it into spl_board_init() in
   arch/arm/cpu/armv7/omap-common/boot-common.c and I'm going to do my best
   to do that today and test it on at least a few boards.
 
  I don't have a lot of background on SPL stuff as I only know one
  implementation in detail. So these comments may be a bit off.
 
  There seem to be two drivers causing this oddness:
 
  1. The need to save boot params before global_data is available. I
  wonder if it is possible to avoid overwriting the boot params, and
  save them later, in board_init_f()? If not, then I don't think the
  global_data structure should be used. A static local variable in the
  data section, with just a few fields in it, could be used instead.
  That avoids the temptation to thing that we are creating a global_data
  structure before crt0.S does it officially. If the data had just been
  stored into the data section, without messing with global_data, then I
  don't think we would have this problem.
 
  This is actually covered today, really.  We do save_boot_params first
  thing and that function must save a magic register value from ROM (or
  whatever) to a stable magic location in memory.
 
 Ah OK. So long as it doesn't save to global_data we are fine. It could
 just have a little structure somewhere in the data segment.
 
 
  2. Need for more stack that can be fitted into SRAM. I think the only
  sensible option here is to change the stack after board_init_f(). As
  Albert says this should be done in crt0.S (in fact that's where I put
  my code). Forcing the dram init to before board_init_f() in SPL seems
  broken to me.
 
  This is also covered.  The flow is cpu_init_crit - lowlevel_init (set
  stack to CONFIG_SYS_INIT_SP_ADDR) - s_init (init DDR) - _main (set
  stack to CONFIG_SPL_STACK, can be in DDR).
 
 Well s_init is a board-specific thing. What I mean is that crt0.S
 should set up an initial stack - there should be no stack before that.
 Then board_init_f() uses the initial stack, sets up DRAM, then we move
 to a second larger stack before board_init_r() is called.

I'd like to see someone re-jigger all of the code here.  It could work
but most armv7 SoCs have a lot of things going on in s_init and I'm not
sure how much of it we can delay all that much.  We can (and do) use an
initial stack pointing elsewhere so maybe we could delay relocating the
main stack.

  I think we should try to have the same flow as U-Boot proper:
 
  start.S
  lowlevel_init (no stack, no global_data, no dram) - can only use
  'data' section to write stuff
  crt0.S (sets up stack and global_data, no dram)
  board_init_f (sets up dram)
  relocate stack if required (but not code)
  board_init_r (running with full stack in dram)
 
  I suppose since old school PowerPC needed i2c to read spd eeproms it's
  possible this ordering could work still today where there's a good bit
  of stuff neeed in order to bring DDR on some ARM platforms.
 
 (Note I am talking just about SPL here, as above)
 
 I suppose what I am saying is that there is no point in setting up
 DRAM before board_init_f() in SPL. There is no global_data available,
 nor is there any console, so any code that happens before
 board_init_f() should be absolutely essential for getting to
 board_init_f(). I can't think of much that fits in that category,
 maybe some clock things?

Clock and pinmux.  It could work...

-- 
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] [linux-sunxi] linux-sunxi/u-boot-sunxi is no longer supported, time to switch to upstream u-boot

2014-12-21 Thread Siarhei Siamashka 
On Sun, 21 Dec 2014 17:00:46 -0300
Emilio López emi...@elopez.com.ar wrote:

 Hi Hans,
 
 El 20/12/14 a las 15:27, Hans de Goede escibió:
  Hi All,
 
  There are 3 topics which I would like to cover in this mail:
 
  1) Switching over to upstream u-boot for the linux-sunxi project
 (...)
  Here are some example instructions on how to build upstream u-boot for
  the Cubietruck:
 
  git clone git://git.denx.de/u-boot.git
  cd u-boot
  make -j4 CROSS_COMPILE=arm-linux-gnu- Cubietruck_defconfig
  # If you want to use an upstream kernel the next steps can be skipped (*)
  make -j4 CROSS_COMPILE=arm-linux-gnu- menuconfig
  #  select ARM architecture - Enable workarounds for booting old
  kernels
  #  exit  save
  make -j4 CROSS_COMPILE=arm-linux-gnu- spl/menuconfig
  #  select ARM architecture - Enable workarounds for booting old
  kernels
  #  exit  save
  # skip to here if you're using an upstream kernel
  make -j4 CROSS_COMPILE=arm-linux-gnu-
 
  And now you will have a u-boot-sunxi-with-spl.bin to dd to your sdcard as
  usual.
 (...)
 
 So I thought it'd be a good idea to move over to mainline uboot, but it 
 doesn't seem to be working at all on Cubietruck. When applying power to 
 the board, all I get is
 
 U-Boot SPL 2015.01-rc3-00163-gd8bec60 (Dec 21 2014 - 16:43:41)
 DRAM:Timeout initialising DRAM
 
 resetting ...
 
 U-Boot SPL 2015.01-rc3-00163-gd8bec60 (Dec 21 2014 - 16:43:41)
 DRAM:Timeout initialising DRAM
 
 resetting ...
 
 ...ad infinitum.
 
 The hardware itself is fine, the NAND bootloader runs OK and I used the 
 board with an old uboot-sunxi some days back. Any ideas on what may be 
 going on?

Thanks for reporting this.

First of all, please ensure that there is no obvious misconfiguration.
For example, whether you have really configured u-boot for Cubietruck.

If everything is configured correctly, then it would help a lot to
identify which of the await_bits_set() or await_bits_clear() calls
is failing in 'arch/arm/cpu/armv7/sunxi/dram_sun4i.c' by adding
some extra debugging prints.

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

[U-Boot] [PATCH 1/1] cmd, fdt: fix working_fdt is set to wrong value

2014-12-21 Thread Hua Yanghao 
Being a long time u-boot developer, this is the first time I'm trying
to get some fix for the open source code back to mainline.
If anything wrong during the process, please be gentle :-) Thank you.

From 225c8f8f2af4cf6092260e5c133d90096e2f3352 Mon Sep 17 00:00:00 2001
From: Hua Yanghao huayang...@gmail.com
Date: Mon, 22 Dec 2014 04:32:39 +0800
Subject: [PATCH 1/1] cmd, fdt: fix working_fdt is set to wrong value

Instead of setting working_fdt to map_sysmem(addr) (e.g. blob), it should be set
to addr directly as inside set_working_fdt_addr it uses map_sysmem(addr) again.
To test: ./u-boot -d dts/dt.bin , then issue: fdt addr 0x100, fdt print will
then cause an segmentation fault. After this fix fdt print is functional.
---
 common/cmd_fdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/cmd_fdt.c b/common/cmd_fdt.c
index 5640ded..d5eebcb 100644
--- a/common/cmd_fdt.c
+++ b/common/cmd_fdt.c
@@ -123,7 +123,7 @@ static int do_fdt(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
  if (control)
  gd-fdt_blob = blob;
  else
- set_working_fdt_addr(blob);
+ set_working_fdt_addr((void *)addr);

  if (argc = 2) {
  int  len;
-- 
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] da850evm: Use generic board and libfdt, fix size for SPI flash

2014-12-21 Thread Peter Howard 
On Fri, 2014-12-19 at 12:14 +0530, Jagan Teki wrote:
 On 19 December 2014 at 02:54, Peter Howard p...@northern-ridge.com.au wrote:
  On Thu, 2014-12-18 at 12:33 +0530, Jagan Teki wrote:
  On 17 December 2014 at 06:44, Peter Howard p...@northern-ridge.com.au 
  wrote:
   Add defines to use CONFIG_SYS_GENERIC_BOARD and CONFIG_OF_LIBFDT.
   Semi-separate to this: the size of the image for the da850evm has
   increased to the point that the size in da850evm.h and the offset for
   the environment in SPI flash no longer work.  They are modified to
   account for the larger image size.
  
   Signed-off-by: Peter Howard phow...@gme.net.au
   ---
include/configs/da850evm.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
  
   diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
   index e5f8afe..e5a612c 100644
   --- a/include/configs/da850evm.h
   +++ b/include/configs/da850evm.h
   @@ -157,7 +157,7 @@
#define CONFIG_SPL_SPI_FLASH_SUPPORT
#define CONFIG_SPL_SPI_LOAD
#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x8000
   -#define CONFIG_SYS_SPI_U_BOOT_SIZE 0x3
   +#define CONFIG_SYS_SPI_U_BOOT_SIZE 0x4
#endif
  
/*
   @@ -251,7 +251,7 @@
#undef CONFIG_ENV_IS_IN_NAND
#define CONFIG_ENV_IS_IN_SPI_FLASH
#define CONFIG_ENV_SIZE(64  10)
   -#define CONFIG_ENV_OFFSET  (256  10)
   +#define CONFIG_ENV_OFFSET  (512  10)
 
  Please make sure the proper testing of this new flash env size.
 
 
  What sort of testing were you thinking of?  I've confirmed that it
  basically works (i.e. saving/loading/editing+save) - env size is 64K,
  SPI is 8MB and offset is only 512K in, so it fits.  u-boot image size is
  ~260K so there's plenty of room before the env.
 
 Looks fine to me, but we have some recent changes in sf which we published
 on master 5 days back - did you test on top of that?
 

If you're referring to commits 54ba653ab63b31c8f5405fb0ee9dfba05cbb1521,
74c2cee4e82bb71953267e87900e279ab5aa1dc3,
b648742a17c16639976ac5b38f246cb0f7d41da5, and
6dd6e90e13acc4014634d78fc469e7e82eefc255, then yes I tested on top of
those.

 
  Is there something more you wanted?
 
  Thanks.
 
  Reviewed-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
 
#define CONFIG_ENV_SECT_SIZE   (64  10)
#define CONFIG_SYS_NO_FLASH
#endif
   @@ -259,6 +259,7 @@
/*
 * U-Boot general configuration
 */
   +#define CONFIG_SYS_GENERIC_BOARD
#define CONFIG_MISC_INIT_R
#define CONFIG_BOARD_EARLY_INIT_F
#define CONFIG_BOOTFILEuImage /* Boot file name */
   @@ -275,6 +276,7 @@
#define CONFIG_SYS_LONGHELP
#define CONFIG_CRC32_VERIFY
#define CONFIG_MX_CYCLIC
   +#define CONFIG_OF_LIBFDT
  
/*
 * Linux Information
   --
   1.9.3
 
 thanks!


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

Re: [U-Boot] [PATCH 1/2] embestmx6boards: convert to use config_distro_defaults.h

2014-12-21 Thread Nikolay Dimitrov 

Hi Iain,

On 12/14/2014 04:51 PM, Iain Paton wrote:

Update to use config_distro_defaults.h and remove explicit settings

Signed-off-by: Iain Paton ipat...@gmail.com
---
  include/configs/embestmx6boards.h | 21 -
  1 file changed, 4 insertions(+), 17 deletions(-)


Tested on RIoTboard  MarsBoard.

Tested-by: Nikolay Dimitrov picmas...@mail.bg

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

Re: [U-Boot] [PATCH 2/2] embestmx6boards: convert to use config_distro_bootcmd.h

2014-12-21 Thread Nikolay Dimitrov 

Hi Iain,

On 12/14/2014 04:51 PM, Iain Paton wrote:

Since the Riot  Mars boards are dev boards it's likely people will want to
run standard distros on them. So replace the current boot scripts with the
standard one from config_distro_bootcmd.h

Signed-off-by: Iain Paton ipat...@gmail.com
---
  include/configs/embestmx6boards.h | 168 +-
  1 file changed, 39 insertions(+), 129 deletions(-)


Tested on RIoTboard  MarsBoard.

Tested-by: Nikolay Dimitrov picmas...@mail.bg

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

Re: [U-Boot] [PATCH RFT 2/2] davinci: Do not duplicate setting of gd

2014-12-21 Thread Peter Howard 
On Fri, 2014-12-19 at 16:53 -0500, Tom Rini wrote:
 In f0c3a6c we stopped setting gd in board_init_f, but later had to
 revert to due problems on certain platforms.  As davinci does not look
 to have these problems, we can drop the setting here and rely upon
 crt0.S to do it.
 
 Cc: Peter Howard p...@northern-ridge.com.au
 Signed-off-by: Tom Rini tr...@ti.com
 
 ---
 Peter, I don't have my davinci board hooked up but since you were doing
 some changes recently is there a chance you can test this easily?
 Thanks!

Applied this patch (with and without 1/1 as well - given part 1 is ARMv7
it shouldn't have any bearing on davinci but wanted to be sure).

U-boot doesn't boot on the da850evm with this change.  I tried both with
my changes to the generic board, and on a fresh clone of u-boot.git. And
on u-boot-ti.git.  I haven't looked further, but I'm guessing there is
early access to gd of the sort you patched out for v7.

 ---
  arch/arm/cpu/arm926ejs/davinci/spl.c |1 -
  1 file changed, 1 deletion(-)
 
 diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c 
 b/arch/arm/cpu/arm926ejs/davinci/spl.c
 index 59b304e..7b14420 100644
 --- a/arch/arm/cpu/arm926ejs/davinci/spl.c
 +++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
 @@ -51,7 +51,6 @@ void board_init_f(ulong dummy)
   memset(__bss_start, 0, __bss_end - __bss_start);
  
   /* Finally, setup gd and move to the next step. */
 - gd = gdata;
   board_init_r(NULL, 0);
  }
  

-- 
Peter Howard p...@northern-ridge.com.au

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

Re: [U-Boot] [PATCH RFT 2/2] davinci: Do not duplicate setting of gd

2014-12-21 Thread Tom Rini 
On Mon, Dec 22, 2014 at 08:34:11AM +1100, Peter Howard wrote:
 On Fri, 2014-12-19 at 16:53 -0500, Tom Rini wrote:
  In f0c3a6c we stopped setting gd in board_init_f, but later had to
  revert to due problems on certain platforms.  As davinci does not look
  to have these problems, we can drop the setting here and rely upon
  crt0.S to do it.
  
  Cc: Peter Howard p...@northern-ridge.com.au
  Signed-off-by: Tom Rini tr...@ti.com
  
  ---
  Peter, I don't have my davinci board hooked up but since you were doing
  some changes recently is there a chance you can test this easily?
  Thanks!
 
 Applied this patch (with and without 1/1 as well - given part 1 is ARMv7
 it shouldn't have any bearing on davinci but wanted to be sure).
 
 U-boot doesn't boot on the da850evm with this change.  I tried both with
 my changes to the generic board, and on a fresh clone of u-boot.git. And
 on u-boot-ti.git.  I haven't looked further, but I'm guessing there is
 early access to gd of the sort you patched out for v7.

Thanks for testing, I feared it wasn't quite as easy as it looked, I'll
have a think about it and see if I can recall what else might be
tickling gd that early over there.

-- 
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] RFC: am35xx: Rearrange SPL on am35xx

2014-12-21 Thread Simon Glass 
Hi Tom,

On 21 December 2014 at 12:29, Tom Rini tr...@ti.com wrote:
 On Sun, Dec 21, 2014 at 11:53:21AM -0700, Simon Glass wrote:
 Hi Tom,

 On 21 December 2014 at 05:30, Tom Rini tr...@ti.com wrote:
  On Fri, Dec 19, 2014 at 08:32:35AM -0700, Simon Glass wrote:
  Hi Tom, Albert,
 
  On 19 December 2014 at 07:40, Tom Rini tr...@ti.com wrote:
   On Thu, Dec 18, 2014 at 05:21:21PM -0700, Simon Glass wrote:
  
   This is an attempt to tidy up the early SPL code in an attempt to pave
   the way for driver model in SPL:
  
   - Avoid setting up SDRAM before board_init_f()
   - Avoid touching global_data before board_init_f()
   - Allow board_init_f() to set up a new stack (seems that the SRAM stack
   is not large enough on these boards)
  
   This needs more work but it does boot on Beaglebone Black.
  
   Signed-off-by: Simon Glass s...@chromium.org
   ---
  
arch/arm/cpu/armv7/am33xx/board.c  | 60 
   ++
arch/arm/cpu/armv7/lowlevel_init.S |  4 ---
arch/arm/include/asm/spl.h |  3 ++
arch/arm/lib/crt0.S|  9 ++
include/configs/ti_armv7_common.h  |  5 ++--
5 files changed, 56 insertions(+), 25 deletions(-)
  
   This takes things in the wrong direction I think.  Since omap3/4/5 have
   the same problem we're going to have to duplicate a bunch of this code.
   But we can do omap_save_boot_params a bit later I'm pretty sure we can
   shove it into spl_board_init() in
   arch/arm/cpu/armv7/omap-common/boot-common.c and I'm going to do my best
   to do that today and test it on at least a few boards.
 
  I don't have a lot of background on SPL stuff as I only know one
  implementation in detail. So these comments may be a bit off.
 
  There seem to be two drivers causing this oddness:
 
  1. The need to save boot params before global_data is available. I
  wonder if it is possible to avoid overwriting the boot params, and
  save them later, in board_init_f()? If not, then I don't think the
  global_data structure should be used. A static local variable in the
  data section, with just a few fields in it, could be used instead.
  That avoids the temptation to thing that we are creating a global_data
  structure before crt0.S does it officially. If the data had just been
  stored into the data section, without messing with global_data, then I
  don't think we would have this problem.
 
  This is actually covered today, really.  We do save_boot_params first
  thing and that function must save a magic register value from ROM (or
  whatever) to a stable magic location in memory.

 Ah OK. So long as it doesn't save to global_data we are fine. It could
 just have a little structure somewhere in the data segment.

 
  2. Need for more stack that can be fitted into SRAM. I think the only
  sensible option here is to change the stack after board_init_f(). As
  Albert says this should be done in crt0.S (in fact that's where I put
  my code). Forcing the dram init to before board_init_f() in SPL seems
  broken to me.
 
  This is also covered.  The flow is cpu_init_crit - lowlevel_init (set
  stack to CONFIG_SYS_INIT_SP_ADDR) - s_init (init DDR) - _main (set
  stack to CONFIG_SPL_STACK, can be in DDR).

 Well s_init is a board-specific thing. What I mean is that crt0.S
 should set up an initial stack - there should be no stack before that.
 Then board_init_f() uses the initial stack, sets up DRAM, then we move
 to a second larger stack before board_init_r() is called.

 I'd like to see someone re-jigger all of the code here.  It could work
 but most armv7 SoCs have a lot of things going on in s_init and I'm not
 sure how much of it we can delay all that much.  We can (and do) use an
 initial stack pointing elsewhere so maybe we could delay relocating the
 main stack.

Yes I've had a bit of a look around. I feel that s_init() should be
for very limited purposes and is being abused. There is a tendency for
everything to just keep moving earlier!


  I think we should try to have the same flow as U-Boot proper:
 
  start.S
  lowlevel_init (no stack, no global_data, no dram) - can only use
  'data' section to write stuff
  crt0.S (sets up stack and global_data, no dram)
  board_init_f (sets up dram)
  relocate stack if required (but not code)
  board_init_r (running with full stack in dram)
 
  I suppose since old school PowerPC needed i2c to read spd eeproms it's
  possible this ordering could work still today where there's a good bit
  of stuff neeed in order to bring DDR on some ARM platforms.

 (Note I am talking just about SPL here, as above)

 I suppose what I am saying is that there is no point in setting up
 DRAM before board_init_f() in SPL. There is no global_data available,
 nor is there any console, so any code that happens before
 board_init_f() should be absolutely essential for getting to
 board_init_f(). I can't think of much that fits in that category,
 maybe some clock things?

 Clock and pinmux.  It could work...

Now that you

[U-Boot] [PATCH 1/4] arm: rmobile: koelsch: Migrate serial driver to drivers model

2014-12-21 Thread Nobuhiro Iwamatsu 
This adds drivers model support of serial port to Koelsch board,
and migrate serial port to drivers model.

Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
---
 board/renesas/koelsch/koelsch.c| 14 ++
 configs/koelsch_defconfig  |  1 +
 include/configs/koelsch.h  |  3 ---
 include/configs/rcar-gen2-common.h |  2 ++
 4 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/board/renesas/koelsch/koelsch.c b/board/renesas/koelsch/koelsch.c
index 10fa571..f627433 100644
--- a/board/renesas/koelsch/koelsch.c
+++ b/board/renesas/koelsch/koelsch.c
@@ -9,6 +9,8 @@
 
 #include common.h
 #include malloc.h
+#include dm.h
+#include dm/platform_data/serial_sh.h
 #include asm/processor.h
 #include asm/mach-types.h
 #include asm/io.h
@@ -160,3 +162,15 @@ void reset_cpu(ulong addr)
val |= 0x02;
i2c_write(CONFIG_SYS_I2C_POWERIC_ADDR, 0x13, 1, val, 1);
 }
+
+static const struct sh_serial_platdata serial_platdata = {
+   .base = SCIF0_BASE,
+   .type = PORT_SCIF,
+   .clk = 14745600,
+   .clk_mode = EXT_CLK,
+};
+
+U_BOOT_DEVICE(koelsch_serials) = {
+   .name = serial_sh,
+   .platdata = serial_platdata,
+};
diff --git a/configs/koelsch_defconfig b/configs/koelsch_defconfig
index 35f605c..b00f458 100644
--- a/configs/koelsch_defconfig
+++ b/configs/koelsch_defconfig
@@ -1,3 +1,4 @@
 CONFIG_ARM=y
 CONFIG_RMOBILE=y
 CONFIG_TARGET_KOELSCH=y
+CONFIG_DM_SERIAL=y
diff --git a/include/configs/koelsch.h b/include/configs/koelsch.h
index c14889c..f7c7b2a 100644
--- a/include/configs/koelsch.h
+++ b/include/configs/koelsch.h
@@ -39,8 +39,6 @@
 
 /* SCIF */
 #define CONFIG_SCIF_CONSOLE
-#define CONFIG_CONS_SCIF0
-#define CONFIG_SCIF_USE_EXT_CLK
 
 /* FLASH */
 #define CONFIG_SYS_NO_FLASH
@@ -68,7 +66,6 @@
 #define RMOBILE_XTAL_CLK   2000u
 #define CONFIG_SYS_CLK_FREQRMOBILE_XTAL_CLK
 #define CONFIG_SH_TMU_CLK_FREQ (CONFIG_SYS_CLK_FREQ / 2)
-#define CONFIG_SH_SCIF_CLK_FREQ14745600
 #define CONFIG_SYS_TMU_CLK_DIV 4
 
 /* i2c */
diff --git a/include/configs/rcar-gen2-common.h 
b/include/configs/rcar-gen2-common.h
index c33f1cb..e9ef7cc 100644
--- a/include/configs/rcar-gen2-common.h
+++ b/include/configs/rcar-gen2-common.h
@@ -35,6 +35,8 @@
 #define CONFIG_SYS_THUMB_BUILD
 #define CONFIG_SYS_GENERIC_BOARD
 
+#define CONFIG_SYS_MALLOC_F_LEN(1  10)
+
 /* Support File sytems */
 #define CONFIG_FAT_WRITE
 #define CONFIG_DOS_PARTITION
-- 
2.1.3

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

[U-Boot] [PATCH 2/4] arm: rmobile: gose: Migrate serial driver to drivers model

2014-12-21 Thread Nobuhiro Iwamatsu 
This adds drivers model support of serial port to Gose board,
and migrate serial port to drivers model.

Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
---
 board/renesas/gose/gose.c | 14 ++
 configs/gose_defconfig|  1 +
 include/configs/gose.h|  3 ---
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/board/renesas/gose/gose.c b/board/renesas/gose/gose.c
index 677b976..d72bc29 100644
--- a/board/renesas/gose/gose.c
+++ b/board/renesas/gose/gose.c
@@ -8,6 +8,8 @@
 
 #include common.h
 #include malloc.h
+#include dm.h
+#include dm/platform_data/serial_sh.h
 #include asm/processor.h
 #include asm/mach-types.h
 #include asm/io.h
@@ -144,3 +146,15 @@ void reset_cpu(ulong addr)
val |= 0x02;
i2c_write(CONFIG_SYS_I2C_POWERIC_ADDR, 0x13, 1, val, 1);
 }
+
+static const struct sh_serial_platdata serial_platdata = {
+   .base = SCIF0_BASE,
+   .type = PORT_SCIF,
+   .clk = 14745600,
+   .clk_mode = EXT_CLK,
+};
+
+U_BOOT_DEVICE(gose_serials) = {
+   .name = serial_sh,
+   .platdata = serial_platdata,
+};
diff --git a/configs/gose_defconfig b/configs/gose_defconfig
index 54a56f5..33fca8d 100644
--- a/configs/gose_defconfig
+++ b/configs/gose_defconfig
@@ -1,3 +1,4 @@
 CONFIG_ARM=y
 CONFIG_RMOBILE=y
 CONFIG_TARGET_GOSE=y
+CONFIG_DM_SERIAL=y
diff --git a/include/configs/gose.h b/include/configs/gose.h
index 44c8a30..808a8b0 100644
--- a/include/configs/gose.h
+++ b/include/configs/gose.h
@@ -39,8 +39,6 @@
 
 /* SCIF */
 #define CONFIG_SCIF_CONSOLE
-#define CONFIG_CONS_SCIF0
-#define CONFIG_SCIF_USE_EXT_CLK
 
 /* FLASH */
 #define CONFIG_SYS_NO_FLASH
@@ -68,7 +66,6 @@
 #define RMOBILE_XTAL_CLK   2000u
 #define CONFIG_SYS_CLK_FREQRMOBILE_XTAL_CLK
 #define CONFIG_SH_TMU_CLK_FREQ (CONFIG_SYS_CLK_FREQ / 2)
-#define CONFIG_SH_SCIF_CLK_FREQ14745600
 #define CONFIG_SYS_TMU_CLK_DIV 4
 
 /* I2C */
-- 
2.1.3

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

[U-Boot] [PATCH 3/4] arm: rmobile: lager: Migrate serial driver to drivers model

2014-12-21 Thread Nobuhiro Iwamatsu 
This adds drivers model support of serial port to Lager board,
and migrate serial port to drivers model.

Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
---
 board/renesas/lager/lager.c | 14 ++
 configs/lager_defconfig |  1 +
 include/configs/lager.h |  3 ---
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/board/renesas/lager/lager.c b/board/renesas/lager/lager.c
index d1e29d2..d35d20f 100644
--- a/board/renesas/lager/lager.c
+++ b/board/renesas/lager/lager.c
@@ -11,6 +11,8 @@
 #include common.h
 #include malloc.h
 #include netdev.h
+#include dm.h
+#include dm/platform_data/serial_sh.h
 #include asm/processor.h
 #include asm/mach-types.h
 #include asm/io.h
@@ -189,3 +191,15 @@ void reset_cpu(ulong addr)
val |= 0x02;
i2c_write(CONFIG_SYS_I2C_POWERIC_ADDR, 0x13, 1, val, 1);
 }
+
+static const struct sh_serial_platdata serial_platdata = {
+   .base = SCIF0_BASE,
+   .type = PORT_SCIF,
+   .clk = 14745600,
+   .clk_mode = EXT_CLK,
+};
+
+U_BOOT_DEVICE(lager_serials) = {
+   .name = serial_sh,
+   .platdata = serial_platdata,
+};
diff --git a/configs/lager_defconfig b/configs/lager_defconfig
index 8b4aeea..aac59c0 100644
--- a/configs/lager_defconfig
+++ b/configs/lager_defconfig
@@ -1,3 +1,4 @@
 CONFIG_ARM=y
 CONFIG_RMOBILE=y
 CONFIG_TARGET_LAGER=y
+CONFIG_DM_SERIAL=y
diff --git a/include/configs/lager.h b/include/configs/lager.h
index 291267f..1c96b8a 100644
--- a/include/configs/lager.h
+++ b/include/configs/lager.h
@@ -39,8 +39,6 @@
 
 /* SCIF */
 #define CONFIG_SCIF_CONSOLE
-#define CONFIG_CONS_SCIF0
-#define CONFIG_SCIF_USE_EXT_CLK
 
 /* SPI */
 #define CONFIG_SPI
@@ -83,7 +81,6 @@
 #define CONFIG_PLL1_DIV2_CLK_FREQ  (CONFIG_PLL1_CLK_FREQ / 2)
 #define CONFIG_MP_CLK_FREQ (CONFIG_PLL1_DIV2_CLK_FREQ / 15)
 #define CONFIG_HP_CLK_FREQ (CONFIG_PLL1_CLK_FREQ / 12)
-#define CONFIG_SH_SCIF_CLK_FREQ14745600 /* External Clock */
 
 #define CONFIG_SYS_TMU_CLK_DIV 4
 
-- 
2.1.3

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

[U-Boot] [PATCH 4/4] arm: rmobile: alt: Migrate serial driver to drivers model

2014-12-21 Thread Nobuhiro Iwamatsu 
This adds drivers model support of serial port to Alt board,
and migrate serial port to drivers model.

Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
---
 board/renesas/alt/alt.c | 14 ++
 configs/alt_defconfig   |  1 +
 include/configs/alt.h   |  3 ---
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/board/renesas/alt/alt.c b/board/renesas/alt/alt.c
index 8cc17e9..c0caeb9 100644
--- a/board/renesas/alt/alt.c
+++ b/board/renesas/alt/alt.c
@@ -8,6 +8,8 @@
 
 #include common.h
 #include malloc.h
+#include dm.h
+#include dm/platform_data/serial_sh.h
 #include asm/processor.h
 #include asm/mach-types.h
 #include asm/io.h
@@ -159,3 +161,15 @@ void reset_cpu(ulong addr)
val |= 0x02;
i2c_write(CONFIG_SYS_I2C_POWERIC_ADDR, 0x13, 1, val, 1);
 }
+
+static const struct sh_serial_platdata serial_platdata = {
+   .base = SCIF2_BASE,
+   .type = PORT_SCIF,
+   .clk = 14745600,
+   .clk_mode = EXT_CLK,
+};
+
+U_BOOT_DEVICE(alt_serials) = {
+   .name = serial_sh,
+   .platdata = serial_platdata,
+};
diff --git a/configs/alt_defconfig b/configs/alt_defconfig
index d722306..19cb7a1 100644
--- a/configs/alt_defconfig
+++ b/configs/alt_defconfig
@@ -1,3 +1,4 @@
 CONFIG_ARM=y
 CONFIG_RMOBILE=y
 CONFIG_TARGET_ALT=y
+CONFIG_DM_SERIAL=y
diff --git a/include/configs/alt.h b/include/configs/alt.h
index 58eac31..01382cf 100644
--- a/include/configs/alt.h
+++ b/include/configs/alt.h
@@ -38,8 +38,6 @@
 
 /* SCIF */
 #define CONFIG_SCIF_CONSOLE
-#define CONFIG_CONS_SCIF2
-#define CONFIG_SCIF_USE_EXT_CLK
 
 /* FLASH */
 #define CONFIG_SPI
@@ -70,7 +68,6 @@
 #define CONFIG_SH_TMU_CLK_FREQ  (CONFIG_SYS_CLK_FREQ / 2) /* EXT / 2 */
 #define CONFIG_PLL1_CLK_FREQ(CONFIG_SYS_CLK_FREQ * 156 / 2)
 #define CONFIG_P_CLK_FREQ  (CONFIG_PLL1_CLK_FREQ / 24)
-#define CONFIG_SH_SCIF_CLK_FREQ14745600 /* External Clock */
 
 #define CONFIG_SYS_TMU_CLK_DIV  4
 
-- 
2.1.3

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

Re: [U-Boot] [PATCH] dm: README: recommend u-boot.dtb to try driver-model on sandbox

2014-12-21 Thread Masahiro Yamada 
Hi Simon,



On Fri, 19 Dec 2014 13:48:16 -0700
Simon Glass s...@chromium.org wrote:

 On 19 December 2014 at 06:39, Masahiro Yamada yamad...@jp.panasonic.com 
 wrote:
  Jagan,
 
  On Fri, 19 Dec 2014 18:43:37 +0530
  Jagan Teki jagannadh.t...@gmail.com wrote:
 
  On 19 December 2014 at 10:46, Masahiro Yamada yamad...@jp.panasonic.com 
  wrote:
   To enjoy driver-model on sandbox, using device tree is recommended.
   While we are here, change sandbox_config to sandbox_defconfig too.
  
   Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
   ---
  
doc/driver-model/README.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
  
   diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt
   index 3e2f622..eafa825 100644
   --- a/doc/driver-model/README.txt
   +++ b/doc/driver-model/README.txt
   @@ -36,9 +36,9 @@ How to try it
  
Build U-Boot sandbox and run it:
  
   -   make sandbox_config
   +   make sandbox_defconfig
   make
   -   ./u-boot
   +   ./u-boot -d u-boot.dtb
 
  this -d is an optional I suppose without dtb we can able to access dm 
  isn't it?
 
 
  Without -d, DM can still have access to platform data, but
  arch/sandbox/sandbox.dts provies us more features.
  With -d u-boot.dtb, you will notice a difference at glance: cyan 
  terminal.
 
 Acked-by: Simon Glass s...@chromium.org
 
 Masahiro, do you think U-Boot should automatically pick up u-boot.dtb
 in the same directory as the executable, unless -d gives another file?
 I suppose we could add a '--nodtb' option too.

I generally do not like programs to do what I do not ask to do behind the scene,
so I personally think it should be as it is.

(If you want to save -d u-boot.dtb, you can use CONFIG_OF_EMBED)



Best Regards
Masahiro Yamada

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

[U-Boot] [PATCH v4] dm: sh: serial: Add support driver model

2014-12-21 Thread Nobuhiro Iwamatsu 
This adds driver model support with this driver. This was tested by Koelsch
board and Gose board.

Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
Acked-by: Simon Glass s...@chromium.org
---
 V4: Fix build with SH.
 V3: Add function of checking -EAGAIN without DM.
 V2: Fix loop for tx fifo and tx fifo.
 Fix write return code writing with DM.

 drivers/serial/serial_sh.c   | 323 ---
 drivers/serial/serial_sh.h   |  10 +-
 include/dm/platform_data/serial_sh.h |  37 
 3 files changed, 262 insertions(+), 108 deletions(-)
 create mode 100644 include/dm/platform_data/serial_sh.h

diff --git a/drivers/serial/serial_sh.c b/drivers/serial/serial_sh.c
index 7c1f271..9e1e3a2 100644
--- a/drivers/serial/serial_sh.c
+++ b/drivers/serial/serial_sh.c
@@ -1,78 +1,21 @@
 /*
  * SuperH SCIF device driver.
  * Copyright (C) 2013  Renesas Electronics Corporation
- * Copyright (C) 2007,2008,2010 Nobuhiro Iwamatsu
+ * Copyright (C) 2007,2008,2010, 2014 Nobuhiro Iwamatsu
  * Copyright (C) 2002 - 2008  Paul Mundt
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
 
 #include common.h
+#include errno.h
+#include dm.h
 #include asm/io.h
 #include asm/processor.h
-#include serial_sh.h
 #include serial.h
 #include linux/compiler.h
-
-#if defined(CONFIG_CONS_SCIF0)
-# define SCIF_BASE SCIF0_BASE
-#elif defined(CONFIG_CONS_SCIF1)
-# define SCIF_BASE SCIF1_BASE
-#elif defined(CONFIG_CONS_SCIF2)
-# define SCIF_BASE SCIF2_BASE
-#elif defined(CONFIG_CONS_SCIF3)
-# define SCIF_BASE SCIF3_BASE
-#elif defined(CONFIG_CONS_SCIF4)
-# define SCIF_BASE SCIF4_BASE
-#elif defined(CONFIG_CONS_SCIF5)
-# define SCIF_BASE SCIF5_BASE
-#elif defined(CONFIG_CONS_SCIF6)
-# define SCIF_BASE SCIF6_BASE
-#elif defined(CONFIG_CONS_SCIF7)
-# define SCIF_BASE SCIF7_BASE
-#else
-# error Default SCIF doesn't set.
-#endif
-
-#if defined(CONFIG_SCIF_A)
-   #define SCIF_BASE_PORT  PORT_SCIFA
-#else
-   #define SCIF_BASE_PORT  PORT_SCIF
-#endif
-
-static struct uart_port sh_sci = {
-   .membase= (unsigned char*)SCIF_BASE,
-   .mapbase= SCIF_BASE,
-   .type   = SCIF_BASE_PORT,
-};
-
-static void sh_serial_setbrg(void)
-{
-   DECLARE_GLOBAL_DATA_PTR;
-#ifdef CONFIG_SCIF_USE_EXT_CLK
-   unsigned short dl = DL_VALUE(gd-baudrate, CONFIG_SH_SCIF_CLK_FREQ);
-   sci_out(sh_sci, DL, dl);
-   /* Need wait: Clock * 1/dl $B!_(B 1/16 */
-   udelay((100 * dl * 16 / CONFIG_SYS_CLK_FREQ) * 1000 + 1);
-#else
-   sci_out(sh_sci, SCBRR,
-   SCBRR_VALUE(gd-baudrate, CONFIG_SH_SCIF_CLK_FREQ));
-#endif
-}
-
-static int sh_serial_init(void)
-{
-   sci_out(sh_sci, SCSCR , SCSCR_INIT(sh_sci));
-   sci_out(sh_sci, SCSCR , SCSCR_INIT(sh_sci));
-   sci_out(sh_sci, SCSMR, 0);
-   sci_out(sh_sci, SCSMR, 0);
-   sci_out(sh_sci, SCFCR, SCFCR_RFRST|SCFCR_TFRST);
-   sci_in(sh_sci, SCFCR);
-   sci_out(sh_sci, SCFCR, 0);
-
-   serial_setbrg();
-   return 0;
-}
+#include dm/platform_data/serial_sh.h
+#include serial_sh.h
 
 #if defined(CONFIG_CPU_SH7760) || \
defined(CONFIG_CPU_SH7780) || \
@@ -86,7 +29,7 @@ static int scif_rxfill(struct uart_port *port)
 static int scif_rxfill(struct uart_port *port)
 {
if ((port-mapbase == 0xffe0) ||
-   (port-mapbase == 0xffe08000)) {
+   (port-mapbase == 0xffe08000)) {
/* SCIF0/1*/
return sci_in(port, SCRFDR)  0xff;
} else {
@@ -109,80 +52,255 @@ static int scif_rxfill(struct uart_port *port)
 }
 #endif
 
-static int serial_rx_fifo_level(void)
+static void sh_serial_init_generic(struct uart_port *port)
 {
-   return scif_rxfill(sh_sci);
+   sci_out(port, SCSCR , SCSCR_INIT(port));
+   sci_out(port, SCSCR , SCSCR_INIT(port));
+   sci_out(port, SCSMR, 0);
+   sci_out(port, SCSMR, 0);
+   sci_out(port, SCFCR, SCFCR_RFRST|SCFCR_TFRST);
+   sci_in(port, SCFCR);
+   sci_out(port, SCFCR, 0);
 }
 
-static void handle_error(void)
+static void
+sh_serial_setbrg_generic(struct uart_port *port, int clk, int baudrate)
 {
-   sci_in(sh_sci, SCxSR);
-   sci_out(sh_sci, SCxSR, SCxSR_ERROR_CLEAR(sh_sci));
-   sci_in(sh_sci, SCLSR);
-   sci_out(sh_sci, SCLSR, 0x00);
+#if defined(CONFIG_R8A7790) || defined(CONFIG_R8A7791) || \
+   defined(CONFIG_R8A7793) || defined(CONFIG_R8A7794)
+   if (port-clk_mode == EXT_CLK) {
+   unsigned short dl = DL_VALUE(baudrate, clk);
+   sci_out(port, DL, dl);
+   /* Need wait: Clock * 1/dl $B!_(B 1/16 */
+   udelay((100 * dl * 16 / clk) * 1000 + 1);
+   } else
+#endif
+   sci_out(port, SCBRR, SCBRR_VALUE(baudrate, clk));
 }
 
-static void serial_raw_putc(const char c)
+static void handle_error(struct uart_port *port)
 {
-   while (1) {
-   /* Tx fifo is empty */
-   if (sci_in(sh_sci, SCxSR)

Re: [U-Boot] [PATCH] powerpc/913x: Add config flag for bootdelay

2014-12-21 Thread Harninder Rai 
 I am guessing you has some extra character for the CONFIG_BOOTDELAY. Anyway,
 since you are on this line common/autoboot.c:247, you can see the bootdelay
 variable one line above. Your purpose of adding delay to boot is easily
 implemented by these command under u-boot
 
 setenv bootdelay 10
 saveenv
 
 There is no need to change the code for this purpose.
Thanks for the review. Let me look into this

Harry++
 
 York
 

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

Re: [U-Boot] [linux-sunxi] linux-sunxi/u-boot-sunxi is no longer supported, time to switch to upstream u-boot

2014-12-21 Thread Emilio López 

Hi Hans,

El 20/12/14 a las 15:27, Hans de Goede escibió:

Hi All,

There are 3 topics which I would like to cover in this mail:

1) Switching over to upstream u-boot for the linux-sunxi project

(...)

Here are some example instructions on how to build upstream u-boot for
the Cubietruck:

git clone git://git.denx.de/u-boot.git
cd u-boot
make -j4 CROSS_COMPILE=arm-linux-gnu- Cubietruck_defconfig
# If you want to use an upstream kernel the next steps can be skipped (*)
make -j4 CROSS_COMPILE=arm-linux-gnu- menuconfig
#  select ARM architecture - Enable workarounds for booting old
kernels
#  exit  save
make -j4 CROSS_COMPILE=arm-linux-gnu- spl/menuconfig
#  select ARM architecture - Enable workarounds for booting old
kernels
#  exit  save
# skip to here if you're using an upstream kernel
make -j4 CROSS_COMPILE=arm-linux-gnu-

And now you will have a u-boot-sunxi-with-spl.bin to dd to your sdcard as
usual.

(...)

So I thought it'd be a good idea to move over to mainline uboot, but it 
doesn't seem to be working at all on Cubietruck. When applying power to 
the board, all I get is


U-Boot SPL 2015.01-rc3-00163-gd8bec60 (Dec 21 2014 - 16:43:41)
DRAM:Timeout initialising DRAM

resetting ...

U-Boot SPL 2015.01-rc3-00163-gd8bec60 (Dec 21 2014 - 16:43:41)
DRAM:Timeout initialising DRAM

resetting ...

...ad infinitum.

The hardware itself is fine, the NAND bootloader runs OK and I used the 
board with an old uboot-sunxi some days back. Any ideas on what may be 
going on?


Cheers!

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

Re: [U-Boot] [linux-sunxi] linux-sunxi/u-boot-sunxi is no longer supported, time to switch to upstream u-boot

2014-12-21 Thread Emilio López 

Hi,

El 21/12/14 a las 17:28, Siarhei Siamashka escibió:

On Sun, 21 Dec 2014 17:00:46 -0300
Emilio López emi...@elopez.com.ar wrote:


Hi Hans,

El 20/12/14 a las 15:27, Hans de Goede escibió:

Hi All,

There are 3 topics which I would like to cover in this mail:

1) Switching over to upstream u-boot for the linux-sunxi project

(...)

Here are some example instructions on how to build upstream u-boot for
the Cubietruck:

git clone git://git.denx.de/u-boot.git
cd u-boot
make -j4 CROSS_COMPILE=arm-linux-gnu- Cubietruck_defconfig
# If you want to use an upstream kernel the next steps can be skipped (*)
make -j4 CROSS_COMPILE=arm-linux-gnu- menuconfig
#  select ARM architecture - Enable workarounds for booting old
kernels
#  exit  save
make -j4 CROSS_COMPILE=arm-linux-gnu- spl/menuconfig
#  select ARM architecture - Enable workarounds for booting old
kernels
#  exit  save
# skip to here if you're using an upstream kernel
make -j4 CROSS_COMPILE=arm-linux-gnu-

And now you will have a u-boot-sunxi-with-spl.bin to dd to your sdcard as
usual.

(...)

So I thought it'd be a good idea to move over to mainline uboot, but it
doesn't seem to be working at all on Cubietruck. When applying power to
the board, all I get is

U-Boot SPL 2015.01-rc3-00163-gd8bec60 (Dec 21 2014 - 16:43:41)
DRAM:Timeout initialising DRAM

resetting ...

U-Boot SPL 2015.01-rc3-00163-gd8bec60 (Dec 21 2014 - 16:43:41)
DRAM:Timeout initialising DRAM

resetting ...

...ad infinitum.

The hardware itself is fine, the NAND bootloader runs OK and I used the
board with an old uboot-sunxi some days back. Any ideas on what may be
going on?


Thanks for reporting this.

First of all, please ensure that there is no obvious misconfiguration.
For example, whether you have really configured u-boot for Cubietruck.


Sorry for the noise, I messed up and was using the Cubieboard config 
instead of the Cubietruck one .


Seems to work fine other than this warning:

Error: dwmac.1c5 address ab:cd:ef:ab:cd:ef illegal value

Cheers!

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

Re: [U-Boot] [PATCH 09/14] sun6i: Add k and m parameters to clock_set_pll5()

2014-12-21 Thread Siarhei Siamashka 
On Fri, 19 Dec 2014 17:40:27 +0100
Hans de Goede hdego...@redhat.com wrote:

 Hi,
 
 On 19-12-14 11:03, Siarhei Siamashka wrote:
  On Tue, 16 Dec 2014 21:31:34 +0100
  Hans de Goede hdego...@redhat.com wrote:
 
  The A23 (sun8i) requires different values for these then sun6i, so make 
  them
  function parameters.
 
  Signed-off-by: Hans de Goede hdego...@redhat.com
 
  What happens if A23 does not get these special k and m parameters, but
  the 'clock_set_pll5' function picks some other values for them (with
  the same resulting target clock speed)?
 
 The major difference is that on the A23 pll5 must be set to dram_clk / 2,
 where as on A31 it needs to be set to dram_clk * 2. By codifying k and m
 so that they do the * 2 on A31 and / 2 on A23 we can make any multiple of
 24 MHz as DRAM clk without needing any other code to figure out the optimal
 k and m.

Wouldn't such other code in 'clock_set_pll5' just look like this
(adds only a few extra instructions with an optimizing compiler):

const int max_n = 32;
int k = 1, m = 2;
if (clk  2400 * k * max_n / m) {
m = 1;
if (clk  2400 * k * max_n / m)
k = 2;
}

As an additional bonus, you get 12 MHz clock frequency selection
granularity on A31 for the DRAM clock speeds up to 384 MHz. And
keep the current 24 MHz granularity for anything larger than that.

 AFAIK using other k and m factors with the same end-result should
 work fine.

This statement seems to somewhat contradict with your original commit
message. Should the commit message be updated?

 But doing things this way follows the KISS principle and I'm
 a great fan of KISS.

By instead spreading the complexity all across the sources? So that each
caller code needs to make assumptions about the valid clock frequency
range and statically pick the right multiplier/divisor parameters as
an additional burden?

In what way is it simple?


 
 Regards,
 
 Hans
 
 
 
 
  And if they are really required for A23, then why exposing them as the
  function arguments instead of hiding this implementation detail inside
  of the 'clock_set_pll5' function?
 
  ---
arch/arm/cpu/armv7/sunxi/clock_sun6i.c| 4 +---
arch/arm/cpu/armv7/sunxi/dram_sun6i.c | 2 +-
arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 2 +-
3 files changed, 3 insertions(+), 5 deletions(-)
 
  diff --git a/arch/arm/cpu/armv7/sunxi/clock_sun6i.c 
  b/arch/arm/cpu/armv7/sunxi/clock_sun6i.c
  index 193e314..8ef19df 100644
  --- a/arch/arm/cpu/armv7/sunxi/clock_sun6i.c
  +++ b/arch/arm/cpu/armv7/sunxi/clock_sun6i.c
  @@ -144,12 +144,10 @@ void clock_set_pll3(unsigned int clk)
ccm-pll3_cfg);
}
 
  -void clock_set_pll5(unsigned int clk, bool sigma_delta_enable)
  +void clock_set_pll5(unsigned int clk, int k, int m, bool 
  sigma_delta_enable)
{
 struct sunxi_ccm_reg * const ccm =
 (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
  -  const int k = 2;
  -  const int m = 1;
 
 if (sigma_delta_enable)
 writel(CCM_PLL5_PATTERN, ccm-pll5_pattern_cfg);
  diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c 
  b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c
  index bc6428a..a8bbdfd 100644
  --- a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c
  +++ b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c
  @@ -46,7 +46,7 @@ static void mctl_sys_init(void)
 (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
 const int dram_clk_div = 2;
 
  -  clock_set_pll5(DRAM_CLK * dram_clk_div, false);
  +  clock_set_pll5(DRAM_CLK * dram_clk_div, 2, 1, false);
 
 clrsetbits_le32(ccm-dram_clk_cfg, CCM_DRAMCLK_CFG_DIV0_MASK,
 CCM_DRAMCLK_CFG_DIV0(dram_clk_div) | CCM_DRAMCLK_CFG_RST |
  diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h 
  b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
  index f807af3..7d61216 100644
  --- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
  +++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
  @@ -311,6 +311,6 @@ struct sunxi_ccm_reg {
#define CCM_DE_CTRL_PLL10(5  24)
#define CCM_DE_CTRL_GATE (1  31)
 
  -void clock_set_pll5(unsigned int clk, bool sigma_delta_enable);
  +void clock_set_pll5(unsigned int clk, int k, int m, bool 
  sigma_delta_enable);
 
#endif /* _SUNXI_CLOCK_SUN6I_H */
 
 
 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 10/14] sunxi: Move await_completion dram helper to dram.h

2014-12-21 Thread Siarhei Siamashka 
On Fri, 19 Dec 2014 17:42:58 +0100
Hans de Goede hdego...@redhat.com wrote:

 Hi,
 
 On 19-12-14 11:06, Siarhei Siamashka wrote:
  On Tue, 16 Dec 2014 21:31:35 +0100
  Hans de Goede hdego...@redhat.com wrote:
 
  The await_completion helper is already copy pasted between the sun4i and 
  sun6i
  dram code, and we need it for sun8i too, so lets make it an inline helper 
  in
  dram.h, rather then adding yet another copy.
 
  Signed-off-by: Hans de Goede hdego...@redhat.com
 
  Making this function static inline and placing it into a header file
  encourages the compiler to actually inline it. Which is not great for
  code size:
 
 
  == Before the patch and using gcc version 4.8.3 ==
 
  $ arm-none-linux-gnieabi-size spl/arch/arm/cpu/armv7/sunxi/dram_sun4i.o
textdata bss dec hex filename
1731   0   01731 6c3
 
  $ arm-none-linux-gnieabi-size spl/arch/arm/cpu/armv7/sunxi/dram_sun6i.o
textdata bss dec hex filename
1841   0   01841 731
 
  == After the patch and using gcc version 4.8.3 ==
 
  $ arm-none-linux-gnieabi-size spl/arch/arm/cpu/armv7/sunxi/dram_sun4i.o
textdata bss dec hex filename
1763   0   01763 6e3
 
  $ arm-none-linux-gnieabi-size spl/arch/arm/cpu/armv7/sunxi/dram_sun6i.o
textdata bss dec hex filename
1983   0   01983 7bf
 
 Ah, thanks for catching that, the size increase does not seem to be a problem
 right now, but it certainly is something to keep in mind.
 
  Could we perhaps just introduce something like a new source file
  dram_common.c or even dram.c?
 
 Sounds like a good idea, patches welcome.

I would definitely appreciate if we could have avoided having this
unnecessary code size increase in the first place.

But if we run out of the code size space, then the oversized static
inline functions in the headers are always relatively easy to identify
and eliminate in one go. That's only a minor annoyance and I'm not
going to waste time on pointless debates.

  As an additional observation, moving await_bits_clear/await_bits_set
  functions into a common header file and using them in the sun6i dram
  code might improve readability.
 
 Sounds like another good idea, patches welcome.


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

Re: [U-Boot] [PATCH 11/14] sunxi: Fill memory before comparing it when doing dram init on sun6i

2014-12-21 Thread Siarhei Siamashka 
On Fri, 19 Dec 2014 17:56:40 +0100
Hans de Goede hdego...@redhat.com wrote:

 Hi,
 
 On 19-12-14 11:08, Siarhei Siamashka wrote:
  On Thu, 18 Dec 2014 19:12:13 +
  Ian Campbell i...@hellion.org.uk wrote:
 
  On Tue, 2014-12-16 at 21:31 +0100, Hans de Goede wrote:
  The sun8i boot0 code fills the DRAM with a random pattern before 
  comparing
  it at different offsets to do columns, etc. detection. The sun6i boot0 
  code
  does not do it, but it seems like a good idea to do this regardless.
 
  Is this the right way round? The existing sun6i code (which you are
  moving here) seems to _rely_ on something having written a useful
  pattern, which I would have assumed to have been boot0. Or else how does
  it work now? Chance?
 
  It appears that this code is just trying to find the first address line,
  which is not connected anywhere. If the address line is not connected,
  then having the corresponding bit set or clear in the memory address
  does not matter and we are effectively accessing the same location.
 
 Correct.
 
  Both sun6i and sun8i code is incorrect and only works because of relying
  on luck.
 
  The sun6i code is incorrect because it is just reading memory without
  initializing it at all. Probably relying on having some unique garbage
  there in a natural way.
 
  The newer sun8i code is still incorrect because it is not safeguarding
  against accidentally encountering the same test pattern at an unrelated
  memory location. Yes, the probability is extremely low, but still not
  zero.
 
 The probability is so low that it really does not matter, so I've no intention
 to fix this.

If anything bad can happen, it probably will :-)

There are many real life examples, when something supposedly almost
impossible has in fact happened. Like the following story:
http://ixbtlabs.com/articles2/magia-chisel/
In a nutshell, the designers of some old CD/CD-RW drives just did not
bother to ensure that the written user data can be never confused
with the service information (sync headers) on disk. The probability
of encountering something that resembles a sync header was considered
to be way too low. Well, until somebody has encountered a hardware
glitch and a sync header fragment got mistakenly read from the drive
as part of some file. Now this corrupted file can wreak havoc if
written to a CD disk, because the false sync header in it is getting
interpreted as an actual sync header. Oops.

Anyway, this is a bug in the sun6i/sun8i dram code. And the submitted
patch appears to be only a partial/incomplete fix. A strong NAK from
me.

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

Re: [U-Boot] [PATCH 13/14] sun8i: Add dram initialization support

2014-12-21 Thread Siarhei Siamashka 
On Fri, 19 Dec 2014 18:05:49 +0100
Hans de Goede hdego...@redhat.com wrote:

 Hi,
 
 On 19-12-14 11:20, Siarhei Siamashka wrote:
  On Tue, 16 Dec 2014 21:31:38 +0100
  Hans de Goede hdego...@redhat.com wrote:
 
  Based on the register / dram_para headers from the Allwinner u-boot / linux
  sources + the init sequences from boot0.
 
  Can the commit message have more detailed information about the precise
  location of the original Allwinner code, which was used as the
  reference?
 
 No, it cannot because no code was referenced, I traced the boot0 binary to
 figure out what was needed to get dram going on the A23.

Thanks for explaining. And good job extracting all the information
from there.

In this case, can we have a clear reference to this binary in the
commit message? It might be useful to have a look at objdump logs
when reviewing your patch.

[...]

  +++ b/arch/arm/cpu/armv7/sunxi/dram_sun8i.c
  @@ -0,0 +1,340 @@
  +/*
  + * Sun8i platform dram controller init.
  + *
  + * (C) Copyright 2014 Hans de Goede hdego...@redhat.com
 
  Is Allwinner copyright really not necessary here?
 
  + * SPDX-License-Identifier:   GPL-2.0+
  + */
  +
  +/*
  + * Note this code uses a lot of magic hex values, that is because this 
  code
  + * simply replays the init sequence as done by the Allwinner boot0 code, 
  so
  + * we do not know what these values mean. There are no symbolic constants 
  for
  + * these magic values, since we do not know how to name them and making up
  + * names for them is not useful.
  + */
 
  You are well aware of this documentation since a long time ago, right?
  http://www.ti.com/lit/ug/spruhn7a/spruhn7a.pdf
 
 I'm aware you've used various sources to figure out more about the A10
 dram controller, since this DRAM controller seems significantly different
 I assumed your sources would not apply, it is good to hear that they do.

I wonder how could you have ended up with this strange assumption?
When I clearly told you that It looks like the Allwinner A31 DRAM
controller registers are very similar to what is used in RK3288 and
provided the links to the relevant sources and documentation back
in September:
http://lists.denx.de/pipermail/u-boot/2014-September/189199.html

Then reminded yet again about this RK3288 similarity and used the
mctl_phy-ptr0 register as an example:
http://lists.denx.de/pipermail/u-boot/2014-December/198582.html

When we were discussing the A31 DRAM controller, of course you should
have expected the information about A31.

Yes, A23 was not a part of the picture at that time. However comparing
its registers with the information from spruhn7a.pdf and various
Rockchip source code drops is a very natural thing to try.

So far the best matching pairs (almost 100% identical PHY) are:
   Allwinner A10 (sun4i) - RK29xx
   Allwinner A31 (sun6i) - RK3288
   Allwinner A23 (sun8i) - TI Keystone2

It's all the same family of DRAM controllers, very likely just
different revisions/generations from the same supplier. I don't
expect A80 or other Allwinner chips to be any different.

[...]

  +  else
  +  writel(0x140b, mctl_phy-dcr);
 
  The bit 28 is marked as reserved and Reads return zeros in the
  TI Keystone2 documentation. It's a nice chance to test whether
  this write has any effect and whether it does modify the register.
 
 It modifies the register, so that means that at least that bit does
 not match the TI Keystone2 documentation.

OK.

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