[U-Boot] U-Boot Bug with newer GCC
Hello,
we are using u-boot in our embedded system with arm-1136jfs cpu. We recently tried a new toolchain with GCC 4.7.2. If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working. U-Boot start normally and on hitting TAB the system freezes. I tracked the problem down the variables __u_boot_cmd_start and __u_boot_cmd_end. Both are not valid with the new toolchain. And accessing one results in a system freeze. Probably the is a problem in arch/arm/cpu/u-boot.lds. I really bad at linker scripts.
Can someone help here?
Thanks. Sebastian
========================================== CADCON Ingenieurgesellschaft mbH & Co. KG Geschaeftsfuehrer: Robert Bauer, Andreas Gundel Sitz der Gesellschaft: D-86368 Gersthofen Registergericht: Amtsgericht Augsburg HRA 14521 ==========================================
Dear Sebastian,
In message E70AF999396FDF4EAE40E195B847096109F5D3A9@SRVEXCH-2K10.CADCON.INTERN you wrote:
we are using u-boot in our embedded system with arm-1136jfs cpu.
Which exact system / board configuration is this?
And which exact U-Boot version (git commit ID ?) is it?
We recently tried a new toolchain with GCC 4.7.2. If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
We have been using GCC 4.7.2 for several months now, on many systems. No such problems have been reported before, so I speculate if this is really a problem with mainline code?
Best regards,
Wolfgang Denk
Hi Wolfgang,
On 02/01/2013 12:31 PM, Wolfgang Denk wrote:
We recently tried a new toolchain with GCC 4.7.2. If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
We have been using GCC 4.7.2 for several months now, on many systems. No such problems have been reported before, so I speculate if this is really a problem with mainline code?
The twister board has the same problem, tested 4e5eb45898b6f05fef3a4690399726c03bc1f398 with twister_config / eldk 5.3 on a twister board (and it traps). So it does occur in mainline, but it must be a combination of board config and code or something, since also Albert did not know / didn't have this problem.
Regards, Jeroen
Dear Jeroen Hofstee,
In message 510BFE48.3060206@myspectrum.nl you wrote:
Hi Wolfgang,
On 02/01/2013 12:31 PM, Wolfgang Denk wrote:
We recently tried a new toolchain with GCC 4.7.2. If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
We have been using GCC 4.7.2 for several months now, on many systems. No such problems have been reported before, so I speculate if this is really a problem with mainline code?
The twister board has the same problem, tested 4e5eb45898b6f05fef3a4690399726c03bc1f398 with twister_config / eldk 5.3 on a twister board (and it traps). So it does occur in mainline,
Interesting - did you ever report this problem on the mailing list? I cannot find any such information in the archives. When was this observed for the dfirst time?
but it must be a combination of board config and code or something, since also Albert did not know / didn't have this problem.
So you think it's ARM specific?
Sebastian - I think you did not mention yet which SoC you're using - is this also ARM?
Best regards,
Wolfgang Denk
Hello Wolfgang,
On 02/01/2013 10:42 PM, Wolfgang Denk wrote:
Dear Jeroen Hofstee,
In message 510BFE48.3060206@myspectrum.nl you wrote:
Hi Wolfgang,
On 02/01/2013 12:31 PM, Wolfgang Denk wrote:
We recently tried a new toolchain with GCC 4.7.2. If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
We have been using GCC 4.7.2 for several months now, on many systems. No such problems have been reported before, so I speculate if this is really a problem with mainline code?
The twister board has the same problem, tested 4e5eb45898b6f05fef3a4690399726c03bc1f398 with twister_config / eldk 5.3 on a twister board (and it traps). So it does occur in mainline,
Interesting - did you ever report this problem on the mailing list? I cannot find any such information in the archives. When was this observed for the dfirst time?
no, I haven't (did bother people on irc with it though). I saw it about a month ago or so. One of the things I tried was to find a working release, but v2012.04 also traps. Since the arm relocation change is before that, I didn't test earlier releases.
So you think it's ARM specific?
Well I though so at least, currently I am in the dark actually. I will have a look at Sebastian's suggestion that it could be the linker script / variable placement. What I recall is that:
It traps at a strlen function in the command completion routine. Arguments / registers are nonsense, so it is not a simple unaligned access. Inserting printfs / making unrelated changes can make it go away, change the trap etc. So currently I only know that something is wrong somewhere. With gcc from eldk 5.2.1 things work as expected.
Sebastian - I think you did not mention yet which SoC you're using - is this also ARM?
He mentioned it, it is an arm-1136jfs.
Regards,
Jeroen
Hello Wolfgang, Sebastian,
On 01.02.2013 12:31, Wolfgang Denk wrote:
In message E70AF999396FDF4EAE40E195B847096109F5D3A9@SRVEXCH-2K10.CADCON.INTERN you wrote:
we are using u-boot in our embedded system with arm-1136jfs cpu.
Which exact system / board configuration is this?
And which exact U-Boot version (git commit ID ?) is it?
We recently tried a new toolchain with GCC 4.7.2. If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
We have been using GCC 4.7.2 for several months now, on many systems. No such problems have been reported before, so I speculate if this is really a problem with mainline code?
Sebastian wrote On 01.02.2013 08:55:
we are using u-boot in our embedded system with arm-1136jfs cpu. We recently tried a new toolchain with GCC 4.7.2. If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working. U-Boot start normally and on hitting TAB the system freezes. I tracked the problem down the variables __u_boot_cmd_start and __u_boot_cmd_end. Both are not valid with the new toolchain. And accessing one results in a system freeze. Probably the is a problem in arch/arm/cpu/u-boot.lds. I really bad at linker scripts.
I just see some problems with ll_entry_* functions described in my post here: http://lists.denx.de/pipermail/u-boot/2013-February/145711.html
I do not know, if this is the same problem, as I face problems only before relocation, after relocation all works fine ...
In this thread Marek wrote, that for this problem albert has a solution ... (CCed albert and marek)
Albert? Can you help here?
bye, Heiko
Hello,
On 02/02/2013 09:37 AM, Heiko Schocher wrote:
Hello Wolfgang, Sebastian,
On 01.02.2013 12:31, Wolfgang Denk wrote:
In message E70AF999396FDF4EAE40E195B847096109F5D3A9@SRVEXCH-2K10.CADCON.INTERN you wrote:
we are using u-boot in our embedded system with arm-1136jfs cpu.
Which exact system / board configuration is this?
And which exact U-Boot version (git commit ID ?) is it?
We recently tried a new toolchain with GCC 4.7.2. If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
We have been using GCC 4.7.2 for several months now, on many systems. No such problems have been reported before, so I speculate if this is really a problem with mainline code?
Sebastian wrote On 01.02.2013 08:55:
we are using u-boot in our embedded system with arm-1136jfs cpu. We recently tried a new toolchain with GCC 4.7.2. If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working. U-Boot start normally and on hitting TAB the system freezes. I tracked the problem down the variables __u_boot_cmd_start and __u_boot_cmd_end. Both are not valid with the new toolchain. And accessing one results in a system freeze. Probably the is a problem in arch/arm/cpu/u-boot.lds. I really bad at linker scripts.
I just see some problems with ll_entry_* functions described in my post here: http://lists.denx.de/pipermail/u-boot/2013-February/145711.html
I do not know, if this is the same problem, as I face problems only before relocation, after relocation all works fine ...
In this thread Marek wrote, that for this problem albert has a solution ... (CCed albert and marek)
Albert? Can you help here?
I am tempted to think that is unrelated. First of all since you encounter problems with the 4.6 toolchain. This trap is not present when compiling with a 4.6 version (at least not for me).
Second, because I bothered Marex and Albert already with this problem on irc and they concluded it could not be ll related.
Third, because dumping the array of commands to a console, displays them all correctly.
Regards, Jeroen
Hi Jeroen,
On Sat, 02 Feb 2013 11:18:44 +0100, Jeroen Hofstee jeroen@myspectrum.nl wrote:
Hello,
On 02/02/2013 09:37 AM, Heiko Schocher wrote:
Hello Wolfgang, Sebastian,
On 01.02.2013 12:31, Wolfgang Denk wrote:
In message E70AF999396FDF4EAE40E195B847096109F5D3A9@SRVEXCH-2K10.CADCON.INTERN you wrote:
we are using u-boot in our embedded system with arm-1136jfs cpu.
Which exact system / board configuration is this?
And which exact U-Boot version (git commit ID ?) is it?
We recently tried a new toolchain with GCC 4.7.2. If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
We have been using GCC 4.7.2 for several months now, on many systems. No such problems have been reported before, so I speculate if this is really a problem with mainline code?
Sebastian wrote On 01.02.2013 08:55:
we are using u-boot in our embedded system with arm-1136jfs cpu. We recently tried a new toolchain with GCC 4.7.2. If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working. U-Boot start normally and on hitting TAB the system freezes. I tracked the problem down the variables __u_boot_cmd_start and __u_boot_cmd_end. Both are not valid with the new toolchain. And accessing one results in a system freeze. Probably the is a problem in arch/arm/cpu/u-boot.lds. I really bad at linker scripts.
I just see some problems with ll_entry_* functions described in my post here: http://lists.denx.de/pipermail/u-boot/2013-February/145711.html
I do not know, if this is the same problem, as I face problems only before relocation, after relocation all works fine ...
In this thread Marek wrote, that for this problem albert has a solution ... (CCed albert and marek)
Albert? Can you help here?
I am tempted to think that is unrelated. First of all since you encounter problems with the 4.6 toolchain. This trap is not present when compiling with a 4.6 version (at least not for me).
Second, because I bothered Marex and Albert already with this problem on irc and they concluded it could not be ll related.
To be more complete, the ll_entry problems are only seen before relocation, are due to the way variables are referred to, and I do indeed have a patch for this, that I'll send out today.
But the tab issue happens after relocation, and therefore is unrelated to this ll_entry issue. AFAIK it has never been seen on mainline code, and has been very elusive for those who experience it -- enabling debug or simply adding/removing code makes it go away or reappear, leading me to thinking that some of the added code either does a data abort itself, or causes one in the mainline code it calls upon.
Third, because dumping the array of commands to a console, displays them all correctly.
Regards, Jeroen
Amicalement,
Hello Albert,
On 02/02/2013 12:32 PM, Albert ARIBAUD wrote:
Sebastian wrote On 01.02.2013 08:55:
we are using u-boot in our embedded system with arm-1136jfs cpu. We recently tried a new toolchain with GCC 4.7.2. If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
[..] AFAIK it has never been seen on mainline code,
The twister board from mainline / current master also has this problem. I believe the mt_ventoux will have it as well, but can't test it.
and has been very elusive for those who experience it -- enabling debug or simply adding/removing code makes it go away or reappear, leading me to thinking that some of the added code either does a data abort itself, or causes one in the mainline code it calls upon.
yes, it is confusing. The following patch will e.g. make the trap go away on the twister. Yet there is nothing wrong with the original code it touches (or I fail to see what it is).
Regards, Jeroen
diff --git a/common/command.c b/common/command.c index 50c8429..520bd39 100644 --- a/common/command.c +++ b/common/command.c @@ -185,7 +185,6 @@ static int complete_cmdv(int argc, char * const argv[], char last_char, int maxv cmd_tbl_t *cmdtp = ll_entry_start(cmd_tbl_t, cmd); const int count = ll_entry_count(cmd_tbl_t, cmd); const cmd_tbl_t *cmdend = cmdtp + count; - const char *p; int len, clen; int n_found = 0; const char *cmd; @@ -224,11 +223,7 @@ static int complete_cmdv(int argc, char * const argv[], char last_char, int maxv * Some commands allow length modifiers (like "cp.b"); * compare command name only until first dot. */ - p = strchr(cmd, '.'); - if (p == NULL) - len = strlen(cmd); - else - len = p - cmd; + len = strlen(cmd);
/* return the partial matches */ for (; cmdtp != cmdend; cmdtp++) {
Dear Jeroen Hofstee,
Hello Albert,
On 02/02/2013 12:32 PM, Albert ARIBAUD wrote:
Sebastian wrote On 01.02.2013 08:55:
we are using u-boot in our embedded system with arm-1136jfs cpu. We recently tried a new toolchain with GCC 4.7.2. If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
[..] AFAIK it has never been seen on mainline code,
The twister board from mainline / current master also has this problem. I believe the mt_ventoux will have it as well, but can't test it.
and has been very elusive for those who experience it -- enabling debug or simply adding/removing code makes it go away or reappear, leading me to thinking that some of the added code either does a data abort itself, or causes one in the mainline code it calls upon.
yes, it is confusing. The following patch will e.g. make the trap go away on the twister. Yet there is nothing wrong with the original code it touches (or I fail to see what it is).
Regards, Jeroen
diff --git a/common/command.c b/common/command.c index 50c8429..520bd39 100644 --- a/common/command.c +++ b/common/command.c @@ -185,7 +185,6 @@ static int complete_cmdv(int argc, char * const argv[], char last_char, int maxv cmd_tbl_t *cmdtp = ll_entry_start(cmd_tbl_t, cmd); const int count = ll_entry_count(cmd_tbl_t, cmd); const cmd_tbl_t *cmdend = cmdtp + count;
const char *p; int len, clen; int n_found = 0; const char *cmd;@@ -224,11 +223,7 @@ static int complete_cmdv(int argc, char * const argv[], char last_char, int maxv * Some commands allow length modifiers (like "cp.b"); * compare command name only until first dot. */
p = strchr(cmd, '.');if (p == NULL)len = strlen(cmd);elselen = p - cmd;
len = strlen(cmd); /* return the partial matches */ for (; cmdtp != cmdend; cmdtp++) {
Could it be that 'cmd' is possibly not zero-terminated string?
Best regards, Marek Vasut
Dear Marek Vasut,
In message 201302021605.21681.marex@denx.de you wrote:
Could it be that 'cmd' is possibly not zero-terminated string?
How would that ever happen?
Best regards,
Wolfgang Denk
Dear Jeroen Hofstee,
In message 510D1D1E.7080705@myspectrum.nl you wrote:
yes, it is confusing. The following patch will e.g. make the trap go away on the twister. Yet there is nothing wrong with the original code it touches (or I fail to see what it is).
Note that your patch breaks commands that use length modifiers ...
Best regards,
Wolfgang Denk
On 02/02/2013 10:22 PM, Wolfgang Denk wrote:
Dear Jeroen Hofstee,
In message 510D1D1E.7080705@myspectrum.nl you wrote:
yes, it is confusing. The following patch will e.g. make the trap go away on the twister. Yet there is nothing wrong with the original code it touches (or I fail to see what it is).
Note that your patch breaks commands that use length modifiers ...
Best regards,
Wolfgang Denk
I'm aware of that. This is not a patch to be applied, just to illustrate the weirdness encountered (it explicitly says the code is fine before this). This is resolved for now, see
http://patchwork.ozlabs.org/patch/217695/
Regards, Jeroen
Hello,
So it seems to be, that patch at least solves this issue. Sebastian: can you check if this is resolved also resolved for your board after applying http://patchwork.ozlabs.org/patch/217695/
Apperently we are still working with v2012.10. Could someone be so kind and provide a patch for v2012.10? We plan to upgrade to v2013.01, but not before the end of Februay.
Then this smells like a tool chain issue. You might contact Pengutronix support for help with their tool chain.
We already asked Pengutronix. They use barebox with their toolchains and didn't have any problem with their new toolchain, yet. In their barebox.lds they have: __barebox_cmd_start = .; __barebox_cmd : { KEEP(*(SORT_BY_NAME(.barebox_cmd*))) } __barebox_cmd_end = .;
And they thought __u_boot_cmd_start = .; .u_boot_cmd : { KEEP(*(.u_boot_cmd)) } __u_boot_cmd_end = .;
would solve the problem. But it didn't.
Best regards. Sebastian
========================================== CADCON Ingenieurgesellschaft mbH & Co. KG Geschaeftsfuehrer: Robert Bauer, Andreas Gundel Sitz der Gesellschaft: D-86368 Gersthofen Registergericht: Amtsgericht Augsburg HRA 14521 ========================================== -----Ursprüngliche Nachricht----- Von: Jeroen Hofstee [mailto:jeroen@myspectrum.nl] Gesendet: Samstag, 2. Februar 2013 22:45 An: Wolfgang Denk Cc: Jeroen Hofstee; Marek Vasut; Heiko Schocher; Priebe, Sebastian; u-boot@lists.denx.de Betreff: Re: [U-Boot] U-Boot Bug with newer GCC
On 02/02/2013 10:22 PM, Wolfgang Denk wrote:
Dear Jeroen Hofstee,
In message 510D1D1E.7080705@myspectrum.nl you wrote:
yes, it is confusing. The following patch will e.g. make the trap go away on the twister. Yet there is nothing wrong with the original code it touches (or I fail to see what it is).
Note that your patch breaks commands that use length modifiers ...
Best regards,
Wolfgang Denk
I'm aware of that. This is not a patch to be applied, just to illustrate the weirdness encountered (it explicitly says the code is fine before this). This is resolved for now, see
http://patchwork.ozlabs.org/patch/217695/
Regards, Jeroen
Hi Sebastian,
On Mon, 4 Feb 2013 07:11:30 +0000, "Priebe, Sebastian" Sebastian.Priebe@cadcon.de wrote:
Hello,
So it seems to be, that patch at least solves this issue. Sebastian: can you check if this is resolved also resolved for your board after applying http://patchwork.ozlabs.org/patch/217695/
Apperently we are still working with v2012.10. Could someone be so kind and provide a patch for v2012.10? We plan to upgrade to v2013.01, but not before the end of Februay.
Did you try to 'apply --reject' the patch to 2012.10 and see how this goes?
Then this smells like a tool chain issue. You might contact Pengutronix support for help with their tool chain.
We already asked Pengutronix. They use barebox with their toolchains and didn't have any problem with their new toolchain, yet. In their barebox.lds they have: __barebox_cmd_start = .; __barebox_cmd : { KEEP(*(SORT_BY_NAME(.barebox_cmd*))) } __barebox_cmd_end = .;
And they thought __u_boot_cmd_start = .; .u_boot_cmd : { KEEP(*(.u_boot_cmd)) } __u_boot_cmd_end = .;
would solve the problem. But it didn't.
As long as symbols are defined at linker level it won't, I guess. My patch actively changes the way the commands start and end symbols are defined.
Best regards. Sebastian
Amicalement,
Hello,
Did you try to 'apply --reject' the patch to 2012.10 and see how this goes?
This only adds a newline in command.c.
Regards, Sebastian
========================================== CADCON Ingenieurgesellschaft mbH & Co. KG Geschaeftsfuehrer: Robert Bauer, Andreas Gundel Sitz der Gesellschaft: D-86368 Gersthofen Registergericht: Amtsgericht Augsburg HRA 14521 ========================================== -----Ursprüngliche Nachricht----- Von: Albert ARIBAUD [mailto:albert.u.boot@aribaud.net] Gesendet: Montag, 4. Februar 2013 09:49 An: Priebe, Sebastian Cc: Jeroen Hofstee; Wolfgang Denk; Marek Vasut; u-boot@lists.denx.de; Heiko Schocher Betreff: Re: [U-Boot] U-Boot Bug with newer GCC
Hi Sebastian,
On Mon, 4 Feb 2013 07:11:30 +0000, "Priebe, Sebastian" Sebastian.Priebe@cadcon.de wrote:
Hello,
So it seems to be, that patch at least solves this issue. Sebastian: can you check if this is resolved also resolved for your board after applying http://patchwork.ozlabs.org/patch/217695/
Apperently we are still working with v2012.10. Could someone be so kind and provide a patch for v2012.10? We plan to upgrade to v2013.01, but not before the end of Februay.
Did you try to 'apply --reject' the patch to 2012.10 and see how this goes?
Then this smells like a tool chain issue. You might contact Pengutronix support for help with their tool chain.
We already asked Pengutronix. They use barebox with their toolchains and didn't have any problem with their new toolchain, yet. In their barebox.lds they have: __barebox_cmd_start = .; __barebox_cmd : { KEEP(*(SORT_BY_NAME(.barebox_cmd*))) } __barebox_cmd_end = .;
And they thought __u_boot_cmd_start = .; .u_boot_cmd : { KEEP(*(.u_boot_cmd)) } __u_boot_cmd_end = .;
would solve the problem. But it didn't.
As long as symbols are defined at linker level it won't, I guess. My patch actively changes the way the commands start and end symbols are defined.
Best regards. Sebastian
Amicalement, -- Albert.
Hi Sebastian,
On Mon, 4 Feb 2013 11:28:26 +0000, "Priebe, Sebastian" Sebastian.Priebe@cadcon.de wrote:
Hello,
Did you try to 'apply --reject' the patch to 2012.10 and see how this goes?
This only adds a newline in command.c.
Do you mean the only change you see at all is this new line addition? I suspect there are other changes, which you missed, maybe because they apply fine. What does a 'git status' produce?
Amicalement,
Hello,
Do you mean the only change you see at all is this new line addition? I suspect there are other changes, which you missed, maybe because they apply fine. What does a 'git status' produce?
We are using svn, not git. There are too many differences. I can't apply the patch. There is no e.g. linker_list.h, etc... svn status after patching show only command/command.c changed.
Greetings, Sebastian
========================================== CADCON Ingenieurgesellschaft mbH & Co. KG Geschaeftsfuehrer: Robert Bauer, Andreas Gundel Sitz der Gesellschaft: D-86368 Gersthofen Registergericht: Amtsgericht Augsburg HRA 14521 ========================================== -----Ursprüngliche Nachricht----- Von: Albert ARIBAUD [mailto:albert.u.boot@aribaud.net] Gesendet: Montag, 4. Februar 2013 12:36 An: Priebe, Sebastian Cc: Jeroen Hofstee; Wolfgang Denk; Marek Vasut; u-boot@lists.denx.de; Heiko Schocher Betreff: Re: [U-Boot] U-Boot Bug with newer GCC
Hi Sebastian,
On Mon, 4 Feb 2013 11:28:26 +0000, "Priebe, Sebastian" Sebastian.Priebe@cadcon.de wrote:
Hello,
Did you try to 'apply --reject' the patch to 2012.10 and see how this goes?
This only adds a newline in command.c.
Do you mean the only change you see at all is this new line addition? I suspect there are other changes, which you missed, maybe because they apply fine. What does a 'git status' produce?
Amicalement, -- Albert.
Hi Sebastian,
On Mon, 4 Feb 2013 14:23:17 +0000, "Priebe, Sebastian" Sebastian.Priebe@cadcon.de wrote:
Hello,
Do you mean the only change you see at all is this new line addition? I suspect there are other changes, which you missed, maybe because they apply fine. What does a 'git status' produce?
We are using svn, not git. There are too many differences. I can't apply the patch. There is no e.g. linker_list.h, etc... svn status after patching show only command/command.c changed.
(maybe you should set your mailing tool to wrap at ~70 characters)
If there is no linker_list.h, then the patch is basically not applicable -- you'd have to hand-port it by manually rewriting the linker file to include sections instead of defining symbols, something like
.u_boot_cmd_start : { KEEP(*(.u_boot_cmd_start)) } .u_boot_cmd : { KEEP(*(.u_boot_cmd)) } .u_boot_cmd_end : { KEEP(*(.u_boot_cmd_end)) }
And then, somewhere in a C file, define __u_boot_cmd_start as a 'struct {}' placed in section .u_boot_cmd_start, and __u_boot_cmd_end as a struct {} placed in section .u_boot_cmd_end.
Greetings, Sebastian
Amicalement,
Hello,
(maybe you should set your mailing tool to wrap at ~70 characters)
Apperently I can't. The mailing tool (MS Outlook) setting are restricted by my companys IT. I have no "root" rights on my windows machine. I develop only on my linux machine.
If there is no linker_list.h, then the patch is basically not applicable -- you'd have to hand-port it by manually rewriting the linker file to include sections instead of defining symbols, something like
I will wait until we upgraded to v2013.01 and apply the patch then. The problem seems to be solved, as several mailings said. I will work with the old toolchain until our upgrade. If the problem still exists after the upgrade I will scream again ;-)
Thanks for the fast support. Sebastian
========================================== CADCON Ingenieurgesellschaft mbH & Co. KG Geschaeftsfuehrer: Robert Bauer, Andreas Gundel Sitz der Gesellschaft: D-86368 Gersthofen Registergericht: Amtsgericht Augsburg HRA 14521 ========================================== -----Ursprüngliche Nachricht----- Von: Albert ARIBAUD [mailto:albert.u.boot@aribaud.net] Gesendet: Montag, 4. Februar 2013 15:32 An: Priebe, Sebastian Cc: Jeroen Hofstee; Wolfgang Denk; Marek Vasut; u-boot@lists.denx.de; Heiko Schocher Betreff: Re: [U-Boot] U-Boot Bug with newer GCC
Hi Sebastian,
On Mon, 4 Feb 2013 14:23:17 +0000, "Priebe, Sebastian" Sebastian.Priebe@cadcon.de wrote:
Hello,
Do you mean the only change you see at all is this new line addition? I suspect there are other changes, which you missed, maybe because they apply fine. What does a 'git status' produce?
We are using svn, not git. There are too many differences. I can't apply the patch. There is no e.g. linker_list.h, etc... svn status after patching show only command/command.c changed.
(maybe you should set your mailing tool to wrap at ~70 characters)
If there is no linker_list.h, then the patch is basically not applicable -- you'd have to hand-port it by manually rewriting the linker file to include sections instead of defining symbols, something like
.u_boot_cmd_start : { KEEP(*(.u_boot_cmd_start)) } .u_boot_cmd : { KEEP(*(.u_boot_cmd)) } .u_boot_cmd_end : { KEEP(*(.u_boot_cmd_end)) }
And then, somewhere in a C file, define __u_boot_cmd_start as a 'struct {}' placed in section .u_boot_cmd_start, and __u_boot_cmd_end as a struct {} placed in section .u_boot_cmd_end.
Greetings, Sebastian
Amicalement, -- Albert.
Dear "Priebe, Sebastian",
In message E70AF999396FDF4EAE40E195B847096109F5F87F@SRVEXCH-2K10.CADCON.INTERN you wrote:
(maybe you should set your mailing tool to wrap at ~70 characters)
Apperently I can't. The mailing tool (MS Outlook) setting are restricted by= my companys IT. I have no "root" rights on my windows machine. I develop only on my linux m= achine.
Don't use this, then, to communicate with public mailing lists.
There are many other options available, including many free ones.
Best regards,
Wolfgang Denk
Hello Heiko,
On 02/02/2013 11:18 AM, Jeroen Hofstee wrote:
Hello,
On 02/02/2013 09:37 AM, Heiko Schocher wrote:
Hello Wolfgang, Sebastian,
On 01.02.2013 12:31, Wolfgang Denk wrote:
In message E70AF999396FDF4EAE40E195B847096109F5D3A9@SRVEXCH-2K10.CADCON.INTERN you wrote:
we are using u-boot in our embedded system with arm-1136jfs cpu.
Which exact system / board configuration is this?
And which exact U-Boot version (git commit ID ?) is it?
We recently tried a new toolchain with GCC 4.7.2. If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
We have been using GCC 4.7.2 for several months now, on many systems. No such problems have been reported before, so I speculate if this is really a problem with mainline code?
Sebastian wrote On 01.02.2013 08:55:
we are using u-boot in our embedded system with arm-1136jfs cpu. We recently tried a new toolchain with GCC 4.7.2. If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working. U-Boot start normally and on hitting TAB the system freezes. I tracked the problem down the variables __u_boot_cmd_start and __u_boot_cmd_end. Both are not valid with the new toolchain. And accessing one results in a system freeze. Probably the is a problem in arch/arm/cpu/u-boot.lds. I really bad at linker scripts.
I just see some problems with ll_entry_* functions described in my post here: http://lists.denx.de/pipermail/u-boot/2013-February/145711.html
I do not know, if this is the same problem, as I face problems only before relocation, after relocation all works fine ...
In this thread Marek wrote, that for this problem albert has a solution ... (CCed albert and marek)
Albert? Can you help here?
I am tempted to think that is unrelated. First of all since you encounter problems with the 4.6 toolchain. This trap is not present when compiling with a 4.6 version (at least not for me).
Second, because I bothered Marex and Albert already with this problem on irc and they concluded it could not be ll related.
Third, because dumping the array of commands to a console, displays them all correctly.
For completeness, the third statement is wrong. It is only the case for the working version, the table has incorrect values for cmdtp->name in current master. So lets hope it is the same problem. I will wait for Albert his patch and check again. Thanks for the pointer.
Regards, Jeroen
Hello Jeroen,
On 02.02.2013 16:43, Jeroen Hofstee wrote:
Hello Heiko,
On 02/02/2013 11:18 AM, Jeroen Hofstee wrote:
Hello,
On 02/02/2013 09:37 AM, Heiko Schocher wrote:
Hello Wolfgang, Sebastian,
On 01.02.2013 12:31, Wolfgang Denk wrote:
In message E70AF999396FDF4EAE40E195B847096109F5D3A9@SRVEXCH-2K10.CADCON.INTERN you wrote:
we are using u-boot in our embedded system with arm-1136jfs cpu.
Which exact system / board configuration is this?
And which exact U-Boot version (git commit ID ?) is it?
We recently tried a new toolchain with GCC 4.7.2. If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
We have been using GCC 4.7.2 for several months now, on many systems. No such problems have been reported before, so I speculate if this is really a problem with mainline code?
Sebastian wrote On 01.02.2013 08:55:
we are using u-boot in our embedded system with arm-1136jfs cpu. We recently tried a new toolchain with GCC 4.7.2. If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working. U-Boot start normally and on hitting TAB the system freezes. I tracked the problem down the variables __u_boot_cmd_start and __u_boot_cmd_end. Both are not valid with the new toolchain. And accessing one results in a system freeze. Probably the is a problem in arch/arm/cpu/u-boot.lds. I really bad at linker scripts.
I just see some problems with ll_entry_* functions described in my post here: http://lists.denx.de/pipermail/u-boot/2013-February/145711.html
I do not know, if this is the same problem, as I face problems only before relocation, after relocation all works fine ...
In this thread Marek wrote, that for this problem albert has a solution ... (CCed albert and marek)
Albert? Can you help here?
I am tempted to think that is unrelated. First of all since you encounter problems with the 4.6 toolchain. This trap is not present when compiling with a 4.6 version (at least not for me).
Second, because I bothered Marex and Albert already with this problem on irc and they concluded it could not be ll related.
Third, because dumping the array of commands to a console, displays them all correctly.
For completeness, the third statement is wrong. It is only the case for the working version, the table has incorrect values for cmdtp->name in current master. So lets hope it is the same problem. I will wait for Albert his patch and check again. Thanks for the pointer.
Thanks for the info! In the meantime, I also tried with ELDK-5.3 and see the same issue (_u_boot_list_try__start is 0 before relocation).
bye, Heiko
Dear Heiko Schocher,
Hello Jeroen,
On 02.02.2013 16:43, Jeroen Hofstee wrote:
Hello Heiko,
On 02/02/2013 11:18 AM, Jeroen Hofstee wrote:
Hello,
On 02/02/2013 09:37 AM, Heiko Schocher wrote:
Hello Wolfgang, Sebastian,
On 01.02.2013 12:31, Wolfgang Denk wrote:
In message E70AF999396FDF4EAE40E195B847096109F5D3A9@SRVEXCH-2K10.CADCON.INTERN you
wrote:
we are using u-boot in our embedded system with arm-1136jfs cpu.
Which exact system / board configuration is this?
And which exact U-Boot version (git commit ID ?) is it?
We recently tried a new toolchain with GCC 4.7.2. If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
We have been using GCC 4.7.2 for several months now, on many systems. No such problems have been reported before, so I speculate if this is really a problem with mainline code?
Sebastian wrote On 01.02.2013 08:55:
we are using u-boot in our embedded system with arm-1136jfs cpu. We recently tried a new toolchain with GCC 4.7.2. If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working. U-Boot start normally and on hitting TAB the system freezes. I tracked the problem down the variables __u_boot_cmd_start and __u_boot_cmd_end. Both are not valid with the new toolchain. And accessing one results in a system freeze. Probably the is a problem in arch/arm/cpu/u-boot.lds. I really bad at linker scripts.
I just see some problems with ll_entry_* functions described in my post here: http://lists.denx.de/pipermail/u-boot/2013-February/145711.html
I do not know, if this is the same problem, as I face problems only before relocation, after relocation all works fine ...
In this thread Marek wrote, that for this problem albert has a solution ... (CCed albert and marek)
Albert? Can you help here?
I am tempted to think that is unrelated. First of all since you encounter problems with the 4.6 toolchain. This trap is not present when compiling with a 4.6 version (at least not for me).
Second, because I bothered Marex and Albert already with this problem on irc and they concluded it could not be ll related.
Third, because dumping the array of commands to a console, displays them all correctly.
For completeness, the third statement is wrong. It is only the case for the working version, the table has incorrect values for cmdtp->name in current master. So lets hope it is the same problem. I will wait for Albert his patch and check again. Thanks for the pointer.
Thanks for the info! In the meantime, I also tried with ELDK-5.3 and see the same issue (_u_boot_list_try__start is 0 before relocation).
It must be NULL before reloc. Albert rolled out a patch in [1], please give it a go. I believe Albert will be sending a followup RFC patch to the ML shortly.
[1] http://git.denx.de/?p=u-boot/u-boot-arm.git;a=shortlog;h=refs/heads/fix- linker-lists
Best regards, Marek Vasut
Hello,
On 02/02/2013 04:43 PM, Jeroen Hofstee wrote:
Sebastian wrote On 01.02.2013 08:55:
we are using u-boot in our embedded system with arm-1136jfs cpu. We recently tried a new toolchain with GCC 4.7.2. If compiled with the new toolchain the feature CONFIG_AUTO_COMPLETE isn't working.
I am tempted to think that is unrelated. First of all since you encounter problems with the 4.6 toolchain. This trap is not present when compiling with a 4.6 version (at least not for me).
Well, that turned out to be wrong, don't know exactly why, but it is related. Perhaps because it is not a toolchain issue I took it for, but slightly different placement between the different compiler versions.
Second, because I bothered Marex and Albert already with this problem on irc and they concluded it could not be ll related.
It might be that code running before relocation could corrupt the data used after relocation. Which would flaw the argument, "after relocation ll should be fine".
Third, because dumping the array of commands to a console, displays them all correctly.
For completeness, the third statement is wrong. It is only the case for the working version, the table has incorrect values for cmdtp->name in current master. So lets hope it is the same problem. I will wait for Albert his patch and check again. Thanks for the pointer.
So it seems to be, that patch at least solves this issue. Sebastian: can you check if this is resolved also resolved for your board after applying http://patchwork.ozlabs.org/patch/217695/
Regards, Jeroen
participants (6)
-
Albert ARIBAUD -
Heiko Schocher -
Jeroen Hofstee -
Marek Vasut -
Priebe, Sebastian -
Wolfgang Denk