[U-Boot-Users] 1.3.3-rc3 - release status

[U-Boot-Users] 1.3.3-rc3 - release status

[Wolfgang Denk]

Hello,

U-Boot v1.3.3-rc3 has been released.

The major architectures (PowerPC, ARM, MIPS) seemt o be in a prtty
good shape now, with only few (usually minor and/or old) issues
remaining.

We have one week left before the  scheduled  release  of  v1.3.3,  an
unless  someone comes up with a real show-stopper I think we can make
the deadline (hey, that would be a novelty - having deadlines at  all
was one already, and not it seems we can actually meet those - wow!).

So please - help test the new code, and report any  problems  /  post
remaining fixes within the next few days.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
How does a project get to be a year late?      ... One day at a time.

[U-Boot-Users] 1.3.3-rc3 - release status

[Remy Bohmer]

Hello Wolfgang,

2008/5/5 Wolfgang Denk <wd@denx.de>:
> Hello,
>  U-Boot v1.3.3-rc3 has been released.
>  The major architectures (PowerPC, ARM, MIPS) seemt o be in a prtty
>  good shape now, with only few (usually minor and/or old) issues
>  remaining.
>  So please - help test the new code, and report any  problems  /  post
>  remaining fixes within the next few days.

I am looking at this tree, and am trying to get the AT91SAM9261-EK
board up and running, I derived it from the AT91SAM9260-EK board (and
the Atmel 1.1.5 U-boot release which works), and I notice some
oddities, from which I assume that they are also there in the 9260
tree (I cannot verify this, because I do not have the 9260-EK board
available, I hope Haavard is capable of checking these on 9260EK?)

Here they come:
* The environment variables work strange. When the environment section
in dataflash has been erased (fresh install), the first boot will
produce garbage when the 'printenv'  command is executed. (It even
reports that the size of the environment is bigger than possible.)
* the 'saveenv' command corrects this, but I can store many variables
with the same name in the environment, I can, for example, enter 10
'ipaddr' variables, if I want to, at the same time. 'printenv' will
list them all, but only the first one is used.

Related to the 'printenv' problem, I already noticed that the setup of
the dataflash-environment goes wrong, memory is allocated in
'common/env_common.c:226', after which the environment is assumed
invalid. Only the malloced area is initialized (line 244+245), after
which the flag 'gd->env_valid' is set to 1.
Because gd->flags does not contain the flag GD_FLG_RELOC, and
'gd->env_valid' is set to 1, env_get_char_init() will call
env_get_char_spec() eventually, causing a direct read from dataflash
(see common/env_dataflash.c), which is not yet initialized.
Because dataflash is not initialized, only garbage is read and put out
to the terminal.

I am figuring out how to fix this nicely, apparently something is
forgotten to be initialized here. Do you have any ideas/suggestions
what is missing here?

The 2nd problem about the duplicate variables in the environment is
still to be investigated, but it wouldn't surprise me if it is related
to the 1st problem.

Further, I am wondering if someone else is working on a patchset for
the AT91SAM9261-EK board. If so, I would be very willing to be a
alpha-tester here. If not, I will publish my patchset for this board
once it is working properly.


Kind Regards,

Remy

[U-Boot-Users] 1.3.3-rc3 - release status

[Haavard Skinnemoen]

"Remy Bohmer" <linux@bohmer.net> wrote:
> Hello Wolfgang,
> 
> 2008/5/5 Wolfgang Denk <wd@denx.de>:
> > Hello,
> >  U-Boot v1.3.3-rc3 has been released.
> >  The major architectures (PowerPC, ARM, MIPS) seemt o be in a prtty
> >  good shape now, with only few (usually minor and/or old) issues
> >  remaining.
> >  So please - help test the new code, and report any  problems  /  post
> >  remaining fixes within the next few days.
> 
> I am looking at this tree, and am trying to get the AT91SAM9261-EK
> board up and running, I derived it from the AT91SAM9260-EK board (and
> the Atmel 1.1.5 U-boot release which works), and I notice some
> oddities, from which I assume that they are also there in the 9260
> tree (I cannot verify this, because I do not have the 9260-EK board
> available, I hope Haavard is capable of checking these on 9260EK?)

I'm afraid not, sorry. I only have AVR32 boards available right now.

I've Cc'd Nicolas and Stelian...hopefully one of them will be able to
help you.

Haavard

[fullquoting because of added Ccs]

> Here they come:
> * The environment variables work strange. When the environment section
> in dataflash has been erased (fresh install), the first boot will
> produce garbage when the 'printenv'  command is executed. (It even
> reports that the size of the environment is bigger than possible.)
> * the 'saveenv' command corrects this, but I can store many variables
> with the same name in the environment, I can, for example, enter 10
> 'ipaddr' variables, if I want to, at the same time. 'printenv' will
> list them all, but only the first one is used.
> 
> Related to the 'printenv' problem, I already noticed that the setup of
> the dataflash-environment goes wrong, memory is allocated in
> 'common/env_common.c:226', after which the environment is assumed
> invalid. Only the malloced area is initialized (line 244+245), after
> which the flag 'gd->env_valid' is set to 1.
> Because gd->flags does not contain the flag GD_FLG_RELOC, and
> 'gd->env_valid' is set to 1, env_get_char_init() will call
> env_get_char_spec() eventually, causing a direct read from dataflash
> (see common/env_dataflash.c), which is not yet initialized.
> Because dataflash is not initialized, only garbage is read and put out
> to the terminal.
> 
> I am figuring out how to fix this nicely, apparently something is
> forgotten to be initialized here. Do you have any ideas/suggestions
> what is missing here?
> 
> The 2nd problem about the duplicate variables in the environment is
> still to be investigated, but it wouldn't surprise me if it is related
> to the 1st problem.
> 
> Further, I am wondering if someone else is working on a patchset for
> the AT91SAM9261-EK board. If so, I would be very willing to be a
> alpha-tester here. If not, I will publish my patchset for this board
> once it is working properly.
> 
> 
> Kind Regards,
> 
> Remy

[U-Boot-Users] 1.3.3-rc3 - release status

[Stelian Pop]

Le mardi 06 mai 2008 ? 10:08 +0200, Haavard Skinnemoen a ?crit :
> "Remy Bohmer" <linux@bohmer.net> wrote:

> > I am looking at this tree, and am trying to get the AT91SAM9261-EK
> > board up and running, I derived it from the AT91SAM9260-EK board (and
> > the Atmel 1.1.5 U-boot release which works), and I notice some
> > oddities,
[...]

> I've Cc'd Nicolas and Stelian...hopefully one of them will be able to
> help you.

Thanks Haavard for forwarding, I indeed missed this message on the
mailing list.

Remy: your problem *might* be related to the size of the malloc'ed area.
Ensure you have something like:

#define CFG_MALLOC_LEN         ROUND(3 * CFG_ENV_SIZE + 128*1024, 0x1000)
in include/configs/at91sam9261.h (notice the 3 factor).

Anyways, I have a full series of patches ready, adding support for:
	- AT91SAM9261
	- AT91SAM9263
	- AT91SAM9RL
	- LCD display for all AT91SAM platforms.

I'm just waiting for the merge window to open and I'll post them all.
Meanwhile, if you wish, I can send you the patches privately.

Stelian.
-- 
Stelian Pop <stelian@popies.net>

[U-Boot-Users] 1.3.3-rc3 - release status

[Jean-Christophe PLAGNIOL-VILLARD]

On 10:24 Tue 06 May     , Stelian Pop wrote:
> 
> Le mardi 06 mai 2008 ? 10:08 +0200, Haavard Skinnemoen a ?crit :
> > "Remy Bohmer" <linux@bohmer.net> wrote:
> 
> > > I am looking at this tree, and am trying to get the AT91SAM9261-EK
> > > board up and running, I derived it from the AT91SAM9260-EK board (and
> > > the Atmel 1.1.5 U-boot release which works), and I notice some
> > > oddities,
> [...]
> 
> > I've Cc'd Nicolas and Stelian...hopefully one of them will be able to
> > help you.
> 
> Thanks Haavard for forwarding, I indeed missed this message on the
> mailing list.
> 
> Remy: your problem *might* be related to the size of the malloc'ed area.
> Ensure you have something like:
> 
> #define CFG_MALLOC_LEN         ROUND(3 * CFG_ENV_SIZE + 128*1024, 0x1000)
> in include/configs/at91sam9261.h (notice the 3 factor).
> 
> Anyways, I have a full series of patches ready, adding support for:
> 	- AT91SAM9261
> 	- AT91SAM9263
> 	- AT91SAM9RL
> 	- LCD display for all AT91SAM platforms.
> 
> I'm just waiting for the merge window to open and I'll post them all.
> Meanwhile, if you wish, I can send you the patches privately.
You could send it even if the merge window is not open

Best Regards,
J.

[U-Boot-Users] 1.3.3-rc3 - release status

[Stelian Pop]

Le mardi 06 mai 2008 ? 14:43 +0200, Jean-Christophe PLAGNIOL-VILLARD a
?crit :

> > I'm just waiting for the merge window to open and I'll post them all.
> > Meanwhile, if you wish, I can send you the patches privately.
> You could send it even if the merge window is not open

Sure, they are coming...

-- 
Stelian Pop <stelian@popies.net>

[U-Boot-Users] 1.3.3-rc3 - release status

[Wolfgang Denk]

In message <20080506124318.GA15533@game.jcrosoft.org> you wrote:
>
> > I'm just waiting for the merge window to open and I'll post them all.
> > Meanwhile, if you wish, I can send you the patches privately.
> You could send it even if the merge window is not open

Speaking for me only - doing so singnificantly increases  the  chance
that the patch gets lost. I'd rather see such stuff on the list when
the merge window is open only.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Real programmers can write assembly code in any language.   :-)
                      - Larry Wall in  <8571@jpl-devvax.JPL.NASA.GOV>

[U-Boot-Users] 1.3.3-rc3 - release status

[Stelian Pop]

Le mardi 06 mai 2008 ? 19:48 +0200, Wolfgang Denk a ?crit :
> In message <20080506124318.GA15533@game.jcrosoft.org> you wrote:
> >
> > > I'm just waiting for the merge window to open and I'll post them all.
> > > Meanwhile, if you wish, I can send you the patches privately.
> > You could send it even if the merge window is not open
> 
> Speaking for me only - doing so singnificantly increases  the  chance
> that the patch gets lost. I'd rather see such stuff on the list when
> the merge window is open only.

That's why I was holding up on them.

But since Jean-Christophe wanted to see them, I posted them. So it's up
to him now: either he integrates them into his tree and waits for the
merge window to push them to you, or I'll post them again in a few days
when the merge window opens.

Stelian.
-- 
Stelian Pop <stelian@popies.net>

[U-Boot-Users] 1.3.3-rc3 - release status

[Jon Loeliger]

Stelian Pop wrote:
> Le mardi 06 mai 2008 ? 19:48 +0200, Wolfgang Denk a ?crit :
>> In message <20080506124318.GA15533@game.jcrosoft.org> you wrote:
>>>> I'm just waiting for the merge window to open and I'll post them all.
>>>> Meanwhile, if you wish, I can send you the patches privately.
>>> You could send it even if the merge window is not open
>> Speaking for me only - doing so singnificantly increases  the  chance
>> that the patch gets lost. I'd rather see such stuff on the list when
>> the merge window is open only.
> 
> That's why I was holding up on them.
> 
> But since Jean-Christophe wanted to see them, I posted them. So it's up
> to him now: either he integrates them into his tree and waits for the
> merge window to push them to you, or I'll post them again in a few days
> when the merge window opens.
> 
> Stelian.

Also, don't forget that by posting them Early and Often (tm),
you give others a chance to review them.  It's the Open Source Way (tm)!

Thanks,
jdl

[U-Boot-Users] 1.3.3-rc3 - release status

[Jean-Christophe PLAGNIOL-VILLARD]

On 21:04 Tue 06 May     , Stelian Pop wrote:
> 
> Le mardi 06 mai 2008 ? 19:48 +0200, Wolfgang Denk a ?crit :
> > In message <20080506124318.GA15533@game.jcrosoft.org> you wrote:
> > >
> > > > I'm just waiting for the merge window to open and I'll post them all.
> > > > Meanwhile, if you wish, I can send you the patches privately.
> > > You could send it even if the merge window is not open
> > 
> > Speaking for me only - doing so singnificantly increases  the  chance
> > that the patch gets lost. I'd rather see such stuff on the list when
> > the merge window is open only.
Normaly I agree too but as said Stelian I'm intrested in this patch and
other engenier have report some problem. So maybye it could help them
> 
> That's why I was holding up on them.
> 
> But since Jean-Christophe wanted to see them, I posted them. So it's up
> to him now: either he integrates them into his tree and waits for the
> merge window to push them to you, or I'll post them again in a few days
> when the merge window opens.
And thanks for it

Best Regards,
J.

[U-Boot-Users] 1.3.3-rc3 - release status

[Haavard Skinnemoen]

Wolfgang Denk <wd@denx.de> wrote:
> In message <20080506124318.GA15533@game.jcrosoft.org> you wrote:
> >  
> > > I'm just waiting for the merge window to open and I'll post them all.
> > > Meanwhile, if you wish, I can send you the patches privately.  
> > You could send it even if the merge window is not open  
> 
> Speaking for me only - doing so singnificantly increases  the  chance
> that the patch gets lost. I'd rather see such stuff on the list when
> the merge window is open only.

I think it's much better to get it properly reviewed and queued up in
some subsystem tree _before_ the merge window opens. That way, you
won't rely on people who are very busy merging to do the review...and
we don't end up cramming everything in during the last hour because the
maintainers were waiting for some patch to get finalized...

Besides, I think Stelian knows how the process works well enough to
resend the patch if nobody responds :-)

Haavard

[U-Boot-Users] 1.3.3-rc3 - release status

[Stelian Pop]

Le mercredi 07 mai 2008 ? 11:12 +0200, Haavard Skinnemoen a ?crit :
> Wolfgang Denk <wd@denx.de> wrote:
> > In message <20080506124318.GA15533@game.jcrosoft.org> you wrote:
> > >  
> > > > I'm just waiting for the merge window to open and I'll post them all.
> > > > Meanwhile, if you wish, I can send you the patches privately.  
> > > You could send it even if the merge window is not open  
> > 
> > Speaking for me only - doing so singnificantly increases  the  chance
> > that the patch gets lost. I'd rather see such stuff on the list when
> > the merge window is open only.
> 
> I think it's much better to get it properly reviewed and queued up in
> some subsystem tree _before_ the merge window opens. That way, you
> won't rely on people who are very busy merging to do the review...and
> we don't end up cramming everything in during the last hour because the
> maintainers were waiting for some patch to get finalized...

I agree.

> Besides, I think Stelian knows how the process works well enough to
> resend the patch if nobody responds :-)

Indeed :)

-- 
Stelian Pop <stelian@popies.net>

[U-Boot-Users] 1.3.3-rc3 - release status

[Remy Bohmer]

Hello All,

I have found the root-cause of these problems:

>  > * The environment variables work strange. When the environment section
>  > in dataflash has been erased (fresh install), the first boot will
>  > produce garbage when the 'printenv'  command is executed. (It even
>  > reports that the size of the environment is bigger than possible.)
>  > * the 'saveenv' command corrects this, but I can store many variables
>  > with the same name in the environment, I can, for example, enter 10
>  > 'ipaddr' variables, if I want to, at the same time. 'printenv' will
>  > list them all, but only the first one is used.

They appear to be caused by this git-commit
=================================================
c0559be371b2a64b1a817088c3308688e2182f93 is first bad commit
commit c0559be371b2a64b1a817088c3308688e2182f93
Author: Joakim Tjernlund <joakim.tjernlund@transmode.se>
Date:   Mon Apr 14 23:01:50 2008 +0200

    Change env_get_char from a global function ptr to a function.

    This avoids an early global data reference.

    Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
=================================================

_Without_ this commit, the environment storage works properly.

So, this is what happens: (we assume an erased environment section in
dataflash)
In the old situation the malloc-ed memory area was used for all
environment read/writes, once it was created. (And saveenv updates the
flash)
With this commit the environment is set to be valid after doing a
memory allocation and fill it with the default values.
However, this flag (gd->env_valid) is also used to determine if the
environment must be read from memory or directly from flash by
env_get_char().
The data flash is not updated before/after the flag is set to valid,
so every new read will be done from the non-initialised data flash,
and thus resulting in bogus data.
This causes both problems above.

So, Wolfgang, probably it is better to undo this commit for now, until
it is fixed? It is a bug in 1.3.3-rc3...

I believe that this bug will also show up in the at91sam9260-ek tree.
I bet Stelian will also run into these problems when he uses the
latest git version... :-)


Kind Regards,

Remy

[U-Boot-Users] 1.3.3-rc3 - release status

[Joakim Tjernlund]

On Tue, 2008-05-06 at 13:16 +0200, Remy Bohmer wrote:
> Hello All,
> 
> I have found the root-cause of these problems:
> 
> >  > * The environment variables work strange. When the environment section
> >  > in dataflash has been erased (fresh install), the first boot will
> >  > produce garbage when the 'printenv'  command is executed. (It even
> >  > reports that the size of the environment is bigger than possible.)
> >  > * the 'saveenv' command corrects this, but I can store many variables
> >  > with the same name in the environment, I can, for example, enter 10
> >  > 'ipaddr' variables, if I want to, at the same time. 'printenv' will
> >  > list them all, but only the first one is used.
> 
> They appear to be caused by this git-commit
> =================================================
> c0559be371b2a64b1a817088c3308688e2182f93 is first bad commit
> commit c0559be371b2a64b1a817088c3308688e2182f93
> Author: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> Date:   Mon Apr 14 23:01:50 2008 +0200
> 
>     Change env_get_char from a global function ptr to a function.
> 
>     This avoids an early global data reference.
> 
>     Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> =================================================
> 
> _Without_ this commit, the environment storage works properly.
> 
> So, this is what happens: (we assume an erased environment section in
> dataflash)
> In the old situation the malloc-ed memory area was used for all
> environment read/writes, once it was created. (And saveenv updates the
> flash)
> With this commit the environment is set to be valid after doing a
> memory allocation and fill it with the default values.
> However, this flag (gd->env_valid) is also used to determine if the
> environment must be read from memory or directly from flash by
> env_get_char().
> The data flash is not updated before/after the flag is set to valid,
> so every new read will be done from the non-initialised data flash,
> and thus resulting in bogus data.
> This causes both problems above.
> 
> So, Wolfgang, probably it is better to undo this commit for now, until
> it is fixed? It is a bug in 1.3.3-rc3...

Hmm, if reverted it won't get fixed.
What happens if you modify to this:
 if ((gd->flags & GD_FLG_RELOC) && (gd->env_valid == 1))

   Jocke
> 
> I believe that this bug will also show up in the at91sam9260-ek tree.
> I bet Stelian will also run into these problems when he uses the
> latest git version... :-)
> 
> 
> Kind Regards,
> 
> Remy
> 

[U-Boot-Users] 1.3.3-rc3 - release status

[Remy Bohmer]

Hello,

>  Hmm, if reverted it won't get fixed.

uhh, I tested/using it... And it is working properly now without this
commit... (So, it fixes the problem I had here)

>  What happens if you modify to this:
>   if ((gd->flags & GD_FLG_RELOC) && (gd->env_valid == 1))

Which file/line/function are you talking about exactly, so I can try this?


Kind Regards,

Remy

[U-Boot-Users] 1.3.3-rc3 - release status

[Joakim Tjernlund]

On Tue, 2008-05-06 at 14:58 +0200, Remy Bohmer wrote:
> Hello,
> 
> >  Hmm, if reverted it won't get fixed.
> 
> uhh, I tested/using it... And it is working properly now without this
> commit... (So, it fixes the problem I had here)

I meant if reverted, it will never be fixed properly.

> 
> >  What happens if you modify to this:
> >   if ((gd->flags & GD_FLG_RELOC) && (gd->env_valid == 1))
> 
> Which file/line/function are you talking about exactly, so I can try this?

common/env_common.c, search for GD_FLG_RELOC. It is obvious if
you look at the diff for the problem commit.

> 
> 
> Kind Regards,
> 
> Remy
> 

[U-Boot-Users] 1.3.3-rc3 - release status

[Remy Bohmer]

Hello,

>  > uhh, I tested/using it... And it is working properly now without this
>  > commit... (So, it fixes the problem I had here)
>  I meant if reverted, it will never be fixed properly.

Then we agree, but leaving it in without a fix, makes the next release
of U-boot quite buggy on these boards...

>  > >  What happens if you modify to this:
>  > >   if ((gd->flags & GD_FLG_RELOC) && (gd->env_valid == 1))

In that case it will not help, because GD_FLG_RELOC is _not_ set on
this board, so the 'if' will never become 'true'.
So, I made it an || and that works...

I will post a patch immediately in a separate mail.


Kind Regards,

Remy

[U-Boot-Users] 1.3.3-rc3 - release status

[Joakim Tjernlund]

On Tue, 2008-05-06 at 16:04 +0200, Remy Bohmer wrote:
> Hello,
> 
> >  > uhh, I tested/using it... And it is working properly now without this
> >  > commit... (So, it fixes the problem I had here)
> >  I meant if reverted, it will never be fixed properly.
> 
> Then we agree, but leaving it in without a fix, makes the next release
> of U-boot quite buggy on these boards...
> 
> >  > >  What happens if you modify to this:
> >  > >   if ((gd->flags & GD_FLG_RELOC) && (gd->env_valid == 1))
> 
> In that case it will not help, because GD_FLG_RELOC is _not_ set on
> this board, so the 'if' will never become 'true'.
> So, I made it an || and that works...

This makes me think that the test should perhaps only test
gd->env_valid:
  if (gd->env_valid == 1)
Not sure and I am busy ATM.

Curious, why isn't GD_FLG_RELOC set on you board?

> 
> I will post a patch immediately in a separate mail.
> 
> 
> Kind Regards,
> 
> Remy
> 

[U-Boot-Users] 1.3.3-rc3 - release status

[Remy Bohmer]

Hello,

>  This makes me think that the test should perhaps only test
>  gd->env_valid:
>   if (gd->env_valid == 1)
>  Not sure and I am busy ATM.

This sounds more like finetuning, and we can look at it later. For
now, we have a solution that works for 1.3.3, with your change in
it...

>  Curious, why isn't GD_FLG_RELOC set on you board?

I did not write the complete support for this board, so I have not a
good explanation...
But, looking at the comments and where it is used, it did not appear
to me that this flag was also needed. It would have caused other
problems.
(U-boot is loaded by dataflashboot, an external binary, U-boot is a
2nd stage bootloader here, and loaded by dataflashboot in RAM
immediately)


Kind Regards,

Remy

[U-Boot-Users] 1.3.3-rc3 - release status

[Michal Simek]

Hi Wolfgang,

Microblaze cpu is OK for 1.3.3.

Regards,
Michal Simek

> Hello,
> 
> U-Boot v1.3.3-rc3 has been released.
> 
> The major architectures (PowerPC, ARM, MIPS) seemt o be in a prtty
> good shape now, with only few (usually minor and/or old) issues
> remaining.
> 
> We have one week left before the  scheduled  release  of  v1.3.3,  an
> unless  someone comes up with a real show-stopper I think we can make
> the deadline (hey, that would be a novelty - having deadlines at  all
> was one already, and not it seems we can actually meet those - wow!).
> 
> So please - help test the new code, and report any  problems  /  post
> remaining fixes within the next few days.
> 
> 
> Best regards,
> 
> Wolfgang Denk
> 

[U-Boot-Users] 1.3.3-rc3 - release status

[Wolfgang Denk]

In message <482064E3.6040702@seznam.cz> you wrote:
> 
> Microblaze cpu is OK for 1.3.3.

Thanks a lot for the confirmation!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Eureka!                                                 -- Archimedes

[U-Boot-Users] 1.3.3-rc3 - release status

[Mike Montour]

Wolfgang Denk wrote:

> So please - help test the new code, and report any  problems  /  post
> remaining fixes within the next few days.

I don't know why, but commit de109d909707e2dfe806be5efc3cdb103b47c8ad 
"Makefile: fix parallel builds" results in a "bricked" Openmoko 
GTA01/Neo1973 device (screen doesn't turn on and nothing is written to 
the debug-board serial console when the power button is pressed). I 
posted a message about this to the Openmoko kernel list a few days ago 
but so far I have not seen any followups there, so I thought I should 
mention it here as well.

This issue will not affect most users, since the "standard" build of 
Openmoko is using an earlier upstream tag for u-boot. Also note that 
Openmoko applies its own series of patches on top of the u-boot git tree 
(but I don't know much about those patches as I'm only a community 
member, not one of the core developers).