[U-Boot-Users] 1.3.3-rc3 - release status
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
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
"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
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.
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.
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...
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
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 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
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.
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
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 :)
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
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
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
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
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
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
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
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
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
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).
participants (9)
-
Haavard Skinnemoen -
Jean-Christophe PLAGNIOL-VILLARD -
Joakim Tjernlund -
Jon Loeliger -
Michal Simek -
Mike Montour -
Remy Bohmer -
Stelian Pop -
Wolfgang Denk