Omap4 DSS clocks

Omap4 DSS clocks

[Christoph Fritz]

Hi,

 Barebox crashes while reading a DSS register:

  $ md 0x48040000
  unable to handle paging request at address 0x48040000

I suppose this is due to a turned off clock.

Any hints?


Thanks
 -- Christoph


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Omap4 DSS clocks

[Alexander Shiyan]

> Hi,
> 
>  Barebox crashes while reading a DSS register:
> 
>   $ md 0x48040000
>   unable to handle paging request at address 0x48040000
> 
> I suppose this is due to a turned off clock.
> 
> Any hints?

Probably this is a bug. I reproduced it.

Try to specify start & end address, like:
md -l 0x48040000-0x48040010

---
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Omap4 DSS clocks

[Christoph Fritz]

On Thu, 2013-03-14 at 16:48 +0400, Alexander Shiyan wrote:
> >  Barebox crashes while reading a DSS register:
> > 
> >   $ md 0x48040000
> >   unable to handle paging request at address 0x48040000
> > 
> > I suppose this is due to a turned off clock.
> > 
> > Any hints?
> 
> Probably this is a bug. I reproduced it.
> 
> Try to specify start & end address, like:
> md -l 0x48040000-0x48040010

I get the same effect: it crashes.



_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re[2]: Omap4 DSS clocks

[Alexander Shiyan]

> On Thu, 2013-03-14 at 16:48 +0400, Alexander Shiyan wrote:
> > >  Barebox crashes while reading a DSS register:
> > > 
> > >   $ md 0x48040000
> > >   unable to handle paging request at address 0x48040000
> > > 
> > > I suppose this is due to a turned off clock.
> > > 
> > > Any hints?
> > 
> > Probably this is a bug. I reproduced it.
> > 
> > Try to specify start & end address, like:
> > md -l 0x48040000-0x48040010
> 
> I get the same effect: it crashes.

OK. It seems rw_buf not initialized.

So change line:
static char *rw_buf; 
to
static char *rw_buf[RW_BUF_SIZE]; 
in commands/mem.c

---
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re[3]: Omap4 DSS clocks

[Alexander Shiyan]

> > On Thu, 2013-03-14 at 16:48 +0400, Alexander Shiyan wrote:
> > > >  Barebox crashes while reading a DSS register:
> > > > 
> > > >   $ md 0x48040000
> > > >   unable to handle paging request at address 0x48040000
> > > > 
> > > > I suppose this is due to a turned off clock.
> > > > 
> > > > Any hints?
> > > 
> > > Probably this is a bug. I reproduced it.
> > > 
> > > Try to specify start & end address, like:
> > > md -l 0x48040000-0x48040010
> > 
> > I get the same effect: it crashes.
> 
> OK. It seems rw_buf not initialized.
> 
> So change line:
> static char *rw_buf; 
> to
> static char *rw_buf[RW_BUF_SIZE]; 
Without asterisk, like:
 static char rw_buf[RW_BUF_SIZE]; 
Sorry.

> in commands/mem.c

---
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Re[3]: Omap4 DSS clocks

[Christoph Fritz]

On Thu, 2013-03-14 at 17:11 +0400, Alexander Shiyan wrote:
> > > On Thu, 2013-03-14 at 16:48 +0400, Alexander Shiyan wrote:
> > > > >  Barebox crashes while reading a DSS register:
> > > > > 
> > > > >   $ md 0x48040000
> > > > >   unable to handle paging request at address 0x48040000
> > > > > 
> > > > > I suppose this is due to a turned off clock.
> > > > > 
> > > > > Any hints?
> > > > 
> > > > Probably this is a bug. I reproduced it.
> > > > 
> > > > Try to specify start & end address, like:
> > > > md -l 0x48040000-0x48040010
> > > 
> > > I get the same effect: it crashes.
> > 
> > OK. It seems rw_buf not initialized.
> > 
> > So change line:
> > static char *rw_buf; 
> > to
> > static char *rw_buf[RW_BUF_SIZE]; 
> Without asterisk, like:
>  static char rw_buf[RW_BUF_SIZE]; 

malloc expects a pointer:
commands/mem.c:634: error: incompatible types when assigning to type
‘char[4096]’ from type ‘void *’

As you can see below, for a quick test I commented the lines, but
barebox still crashes.

Why don't you suppose that this is due to the non functional DSS?

diff --git a/commands/mem.c b/commands/mem.c
index 51aa04d..af5cc46 100644
--- a/commands/mem.c
+++ b/commands/mem.c
@@ -40,7 +40,7 @@
 #endif
 
 #define RW_BUF_SIZE	4096
-static char *rw_buf;
+static char rw_buf[RW_BUF_SIZE];
 
 static char *DEVMEM = "/dev/mem";
 
@@ -631,11 +631,11 @@ static struct driver_d mem_drv = {
 
 static int mem_init(void)
 {
-	rw_buf = malloc(RW_BUF_SIZE);
-	if(!rw_buf) {
-		printf("%s: Out of memory\n", __FUNCTION__);
-		return -1;
-	}
+//	rw_buf = malloc(RW_BUF_SIZE);
+//	if(!rw_buf) {
+//		printf("%s: Out of memory\n", __FUNCTION__);
+//		return -1;
+//	}
 
 	add_mem_device("mem", 0, ~0, IORESOURCE_MEM_WRITEABLE);
 	platform_driver_register(&mem_drv);




_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Re[3]: Omap4 DSS clocks

[Sascha Hauer]

On Thu, Mar 14, 2013 at 02:23:56PM +0100, Christoph Fritz wrote:
> On Thu, 2013-03-14 at 17:11 +0400, Alexander Shiyan wrote:
> > > > On Thu, 2013-03-14 at 16:48 +0400, Alexander Shiyan wrote:
> > > > > >  Barebox crashes while reading a DSS register:
> > > > > > 
> > > > > >   $ md 0x48040000
> > > > > >   unable to handle paging request at address 0x48040000
> > > > > > 
> > > > > > I suppose this is due to a turned off clock.
> > > > > > 
> > > > > > Any hints?
> > > > > 
> > > > > Probably this is a bug. I reproduced it.
> > > > > 
> > > > > Try to specify start & end address, like:
> > > > > md -l 0x48040000-0x48040010
> > > > 
> > > > I get the same effect: it crashes.
> > > 
> > > OK. It seems rw_buf not initialized.
> > > 
> > > So change line:
> > > static char *rw_buf; 
> > > to
> > > static char *rw_buf[RW_BUF_SIZE]; 
> > Without asterisk, like:
> >  static char rw_buf[RW_BUF_SIZE]; 
> 
> malloc expects a pointer:
> commands/mem.c:634: error: incompatible types when assigning to type
> ‘char[4096]’ from type ‘void *’
> 
> As you can see below, for a quick test I commented the lines, but
> barebox still crashes.
> 
> Why don't you suppose that this is due to the non functional DSS?

I wouldn't expect a bug in the code. This would have been discovered
already.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Re[3]: Omap4 DSS clocks

[Christoph Fritz]

On Thu, 2013-03-14 at 14:33 +0100, Sascha Hauer wrote:
> On Thu, Mar 14, 2013 at 02:23:56PM +0100, Christoph Fritz wrote:
> > On Thu, 2013-03-14 at 17:11 +0400, Alexander Shiyan wrote:
> > > > > On Thu, 2013-03-14 at 16:48 +0400, Alexander Shiyan wrote:
> > > > > > >  Barebox crashes while reading a DSS register:
> > > > > > > 
> > > > > > >   $ md 0x48040000
> > > > > > >   unable to handle paging request at address 0x48040000
> > > > > > > 
> > > > > > > I suppose this is due to a turned off clock.
> > > > > > > 
> > > > > > > Any hints?
> > > > > > 
> > > > > > Probably this is a bug. I reproduced it.
> > > > > > 
> > > > > > Try to specify start & end address, like:
> > > > > > md -l 0x48040000-0x48040010
> > > > > 
> > > > > I get the same effect: it crashes.
> > > > 
> > > > OK. It seems rw_buf not initialized.
> > > > 
> > > > So change line:
> > > > static char *rw_buf; 
> > > > to
> > > > static char *rw_buf[RW_BUF_SIZE]; 
> > > Without asterisk, like:
> > >  static char rw_buf[RW_BUF_SIZE]; 
> > 
> > malloc expects a pointer:
> > commands/mem.c:634: error: incompatible types when assigning to type
> > ‘char[4096]’ from type ‘void *’
> > 
> > As you can see below, for a quick test I commented the lines, but
> > barebox still crashes.
> > 
> > Why don't you suppose that this is due to the non functional DSS?
> 
> I wouldn't expect a bug in the code. This would have been discovered
> already.

Register CM_DSS_DSS_CLKCTRL (0x4a009120) reads 0x00070F02 and so the
field [17:16] IDLEST reads 0x3 which means "Module is disabled and
cannot be accessed". On linux, its 0x2 which means "functional".

Any hints?

Thanks
 -- Christoph



_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Re[3]: Omap4 DSS clocks

[Christoph Fritz]

On Thu, 2013-03-14 at 14:46 +0100, Christoph Fritz wrote:
> On Thu, 2013-03-14 at 14:33 +0100, Sascha Hauer wrote:

> > I wouldn't expect a bug in the code. This would have been discovered
> > already.
> 
> Register CM_DSS_DSS_CLKCTRL (0x4a009120) reads 0x00070F02 and so the
> field [17:16] IDLEST reads 0x3 which means "Module is disabled and
> cannot be accessed". On linux, its 0x2 which means "functional".

I already asked about this on the TI E2E Community forum
http://e2e.ti.com/support/omap/f/849/t/251717.aspx but without gaining
success.

Overall, isn't it weird that DSS is offline (as indicated by IDLEST)?

I suppose in ./arch/arm/mach-omap/omap4_clock.c this check:

/* Check for DSS Clocks */
while ((__raw_readl(0x4A009100) & 0xF00) != 0xE00)
	;

should get extended to also check for correct IDLEST ...which would
currently end in an endless loop :)

Thanks
 -- Christoph


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re[5]: Omap4 DSS clocks

[Alexander Shiyan]

> On Thu, 2013-03-14 at 14:46 +0100, Christoph Fritz wrote:
> > On Thu, 2013-03-14 at 14:33 +0100, Sascha Hauer wrote:
> 
> > > I wouldn't expect a bug in the code. This would have been discovered
> > > already.
> > 
> > Register CM_DSS_DSS_CLKCTRL (0x4a009120) reads 0x00070F02 and so the
> > field [17:16] IDLEST reads 0x3 which means "Module is disabled and
> > cannot be accessed". On linux, its 0x2 which means "functional".
> 
> I already asked about this on the TI E2E Community forum
> http://e2e.ti.com/support/omap/f/849/t/251717.aspx but without gaining
> success.
> 
> Overall, isn't it weird that DSS is offline (as indicated by IDLEST)?
> 
> I suppose in ./arch/arm/mach-omap/omap4_clock.c this check:
> 
> /* Check for DSS Clocks */
> while ((__raw_readl(0x4A009100) & 0xF00) != 0xE00)
> 	;
> 
> should get extended to also check for correct IDLEST ...which would
> currently end in an endless loop :)

I revised commands/mem. All correct in the code, so problem is not here.

About DSS: I cannot help you with this CPU, but here is one point from
OMAP4430TRM:
"The main access to all DSS registers is through the L3 interconnect.
The access through the L4_PER interconnect is provided for back software
compatibility."

Maybe it help you.

---
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Re[5]: Omap4 DSS clocks

[Christoph Fritz]

On Thu, 2013-03-14 at 20:29 +0400, Alexander Shiyan wrote:
> > On Thu, 2013-03-14 at 14:46 +0100, Christoph Fritz wrote:
> > > On Thu, 2013-03-14 at 14:33 +0100, Sascha Hauer wrote:
> > 
> > > > I wouldn't expect a bug in the code. This would have been discovered
> > > > already.
> > > 
> > > Register CM_DSS_DSS_CLKCTRL (0x4a009120) reads 0x00070F02 and so the
> > > field [17:16] IDLEST reads 0x3 which means "Module is disabled and
> > > cannot be accessed". On linux, its 0x2 which means "functional".

Sascha, any comments on this?
 
> > I already asked about this on the TI E2E Community forum
> > http://e2e.ti.com/support/omap/f/849/t/251717.aspx but without gaining
> > success.
> > 
> > Overall, isn't it weird that DSS is offline (as indicated by IDLEST)?
> > 
> > I suppose in ./arch/arm/mach-omap/omap4_clock.c this check:
> > 
> > /* Check for DSS Clocks */
> > while ((__raw_readl(0x4A009100) & 0xF00) != 0xE00)
> > 	;
> > 
> > should get extended to also check for correct IDLEST ...which would
> > currently end in an endless loop :)
> 
> I revised commands/mem. All correct in the code, so problem is not here.

Thanks for pointing this out.

> About DSS: I cannot help you with this CPU, but here is one point from
> OMAP4430TRM:
> "The main access to all DSS registers is through the L3 interconnect.
> The access through the L4_PER interconnect is provided for back software
> compatibility."

I stumbled upon these lines too but have no clue what this means for
barebox command "md" concrete.

> Maybe it help you.

Thanks a lot for trying
 -- Christoph






_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re[7]: Omap4 DSS clocks

[Alexander Shiyan]

> On Thu, 2013-03-14 at 20:29 +0400, Alexander Shiyan wrote:
> > > On Thu, 2013-03-14 at 14:46 +0100, Christoph Fritz wrote:
> > > > On Thu, 2013-03-14 at 14:33 +0100, Sascha Hauer wrote:
> > > 
> > > > > I wouldn't expect a bug in the code. This would have been discovered
> > > > > already.
> > > > 
> > > > Register CM_DSS_DSS_CLKCTRL (0x4a009120) reads 0x00070F02 and so the
> > > > field [17:16] IDLEST reads 0x3 which means "Module is disabled and
> > > > cannot be accessed". On linux, its 0x2 which means "functional".
> 
> Sascha, any comments on this?
>  
> > > I already asked about this on the TI E2E Community forum
> > > http://e2e.ti.com/support/omap/f/849/t/251717.aspx but without gaining
> > > success.
> > > 
> > > Overall, isn't it weird that DSS is offline (as indicated by IDLEST)?
> > > 
> > > I suppose in ./arch/arm/mach-omap/omap4_clock.c this check:
> > > 
> > > /* Check for DSS Clocks */
> > > while ((__raw_readl(0x4A009100) & 0xF00) != 0xE00)
> > > 	;
> > > 
> > > should get extended to also check for correct IDLEST ...which would
> > > currently end in an endless loop :)
> > 
> > I revised commands/mem. All correct in the code, so problem is not here.
> 
> Thanks for pointing this out.
> 
> > About DSS: I cannot help you with this CPU, but here is one point from
> > OMAP4430TRM:
> > "The main access to all DSS registers is through the L3 interconnect.
> > The access through the L4_PER interconnect is provided for back software
> > compatibility."
> 
> I stumbled upon these lines too but have no clue what this means for
> barebox command "md" concrete.

MD command causes an error due to the inability of the reading memory area.
Error can be disabled via the option "enable arm exception handling support",
but it does not help solve the problem.
OMAP has a memory areas (modules), which are locked, so you need to
search this information from datasheet.

---
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH] [RFC] ARM OMAP4: enable DSS by default

[Christoph Fritz]

On Fri, 2013-03-15 at 12:40 +0400, Alexander Shiyan wrote:

> MD command causes an error due to the inability of the reading memory area.
> Error can be disabled via the option "enable arm exception handling support",
> but it does not help solve the problem.
> OMAP has a memory areas (modules), which are locked,

This corresponds with my register observations. As noted above, register
CM_DSS_DSS_CLKCTRL (0x4a009120) reads 0x00070F02 which means: "Module is
disabled and cannot be accessed".

>  so you need to
> search this information from datasheet.

Finnaly I was very wise inspired to do "mw 0x4a009100 2". This disables
the HW_AUTO-Mode (Automatic transition) and starts a software forced
wake-up (SW_WKUP).

Now even the IDLEST field from CM_DSS_CLKSTCTRL reads 0x0: "Module is
fully functional, including INTRCONN" :-)

et la voila:
md 0x48040000+4
48040000: 00000040

What do you think about the patch below?

---
Subject: [PATCH] [RFC] ARM OMAP4: enable DSS by default

This patch removes the anyway default reset setting of HW_AUTO in favour of
SW_WKUP. So the DSS Module gets enabled and you gain full register access.
---
 arch/arm/mach-omap/omap4_clock.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap/omap4_clock.c b/arch/arm/mach-omap/omap4_clock.c
index 0621fd3..72335d9 100644
--- a/arch/arm/mach-omap/omap4_clock.c
+++ b/arch/arm/mach-omap/omap4_clock.c
@@ -375,8 +375,8 @@ void omap4_enable_all_clocks(void)
 	/* Check for DSS Clocks */
 	while ((__raw_readl(0x4A009100) & 0xF00) != 0xE00)
 		;
-	/* Set HW_AUTO transition mode */
-	sr32(CM_DSS_CLKSTCTRL, 0, 32, 0x3);
+	/* Set SW_WKUP to enable DSS Module with full register access */
+	sr32(CM_DSS_CLKSTCTRL, 0, 32, 0x2);
 
 	/* Enable SGX clocks */
 	sr32(CM_SGX_CLKSTCTRL, 0, 32, 0x2);
-- 
1.7.10.4




_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH] [RFC] ARM OMAP4: enable DSS by default

[Christoph Fritz]

On Fri, 2013-03-15 at 14:39 +0100, Christoph Fritz wrote:
> On Fri, 2013-03-15 at 12:40 +0400, Alexander Shiyan wrote:
> 
> > MD command causes an error due to the inability of the reading memory area.
> > Error can be disabled via the option "enable arm exception handling support",
> > but it does not help solve the problem.
> > OMAP has a memory areas (modules), which are locked,
> 
> This corresponds with my register observations. As noted above, register
> CM_DSS_DSS_CLKCTRL (0x4a009120) reads 0x00070F02 which means: "Module is
> disabled and cannot be accessed".
> 
> >  so you need to
> > search this information from datasheet.
> 
> Finnaly I was very wise inspired to do "mw 0x4a009100 2". This disables
> the HW_AUTO-Mode (Automatic transition) and starts a software forced
> wake-up (SW_WKUP).
> 
> Now even the IDLEST field from CM_DSS_CLKSTCTRL reads 0x0: "Module is
> fully functional, including INTRCONN" :-)
> 
> et la voila:
> md 0x48040000+4
> 48040000: 00000040
> 
> What do you think about the patch below?
> 
> ---
> Subject: [PATCH] [RFC] ARM OMAP4: enable DSS by default
> 
> This patch removes the anyway default reset setting of HW_AUTO in favour of
> SW_WKUP. So the DSS Module gets enabled and you gain full register access.
> ---
>  arch/arm/mach-omap/omap4_clock.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-omap/omap4_clock.c b/arch/arm/mach-omap/omap4_clock.c
> index 0621fd3..72335d9 100644
> --- a/arch/arm/mach-omap/omap4_clock.c
> +++ b/arch/arm/mach-omap/omap4_clock.c
> @@ -375,8 +375,8 @@ void omap4_enable_all_clocks(void)
>  	/* Check for DSS Clocks */
>  	while ((__raw_readl(0x4A009100) & 0xF00) != 0xE00)
>  		;
> -	/* Set HW_AUTO transition mode */
> -	sr32(CM_DSS_CLKSTCTRL, 0, 32, 0x3);
> +	/* Set SW_WKUP to enable DSS Module with full register access */
> +	sr32(CM_DSS_CLKSTCTRL, 0, 32, 0x2);
>  
>  	/* Enable SGX clocks */
>  	sr32(CM_SGX_CLKSTCTRL, 0, 32, 0x2);

*ping*


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re[2]: [PATCH] [RFC] ARM OMAP4: enable DSS by default

[Alexander Shiyan]

> On Fri, 2013-03-15 at 14:39 +0100, Christoph Fritz wrote:
> > On Fri, 2013-03-15 at 12:40 +0400, Alexander Shiyan wrote:
> > 
> > > MD command causes an error due to the inability of the reading memory area.
> > > Error can be disabled via the option "enable arm exception handling support",
> > > but it does not help solve the problem.
> > > OMAP has a memory areas (modules), which are locked,
> > 
> > This corresponds with my register observations. As noted above, register
> > CM_DSS_DSS_CLKCTRL (0x4a009120) reads 0x00070F02 which means: "Module is
> > disabled and cannot be accessed".
> > 
> > >  so you need to
> > > search this information from datasheet.
> > 
> > Finnaly I was very wise inspired to do "mw 0x4a009100 2". This disables
> > the HW_AUTO-Mode (Automatic transition) and starts a software forced
> > wake-up (SW_WKUP).
> > 
> > Now even the IDLEST field from CM_DSS_CLKSTCTRL reads 0x0: "Module is
> > fully functional, including INTRCONN" :-)
> > 
> > et la voila:
> > md 0x48040000+4
> > 48040000: 00000040
> > 
> > What do you think about the patch below?
> > 
> > ---
> > Subject: [PATCH] [RFC] ARM OMAP4: enable DSS by default
> > 
> > This patch removes the anyway default reset setting of HW_AUTO in favour of
> > SW_WKUP. So the DSS Module gets enabled and you gain full register access.
> > ---
> >  arch/arm/mach-omap/omap4_clock.c |    4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/mach-omap/omap4_clock.c b/arch/arm/mach-omap/omap4_clock.c
> > index 0621fd3..72335d9 100644
> > --- a/arch/arm/mach-omap/omap4_clock.c
> > +++ b/arch/arm/mach-omap/omap4_clock.c
> > @@ -375,8 +375,8 @@ void omap4_enable_all_clocks(void)
> >  	/* Check for DSS Clocks */
> >  	while ((__raw_readl(0x4A009100) & 0xF00) != 0xE00)
> >  		;
> > -	/* Set HW_AUTO transition mode */
> > -	sr32(CM_DSS_CLKSTCTRL, 0, 32, 0x3);
> > +	/* Set SW_WKUP to enable DSS Module with full register access */
> > +	sr32(CM_DSS_CLKSTCTRL, 0, 32, 0x2);
> >  
> >  	/* Enable SGX clocks */
> >  	sr32(CM_SGX_CLKSTCTRL, 0, 32, 0x2);

I do not use OMAP and therefore can not comment on these changes.
I think AUTO mode should work by default, and the fact that it does not
work suggests that not all operations are performed (power, clocks etc.) ...
May be necessary to switch to AUTO back after forcing WKUP.

---
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox