Hello,
Am 20.12.2010 17:08, schrieb John Rigby:
Earlier in this thread Alexander said:
I haven't add the definitions which are using a memory barrier because I
haven't found
a place in the kernel where they were actually enabled
(CONFIG_ARM_DMA_MEM_BUFFERABLE).
Because I've just run again
Dear Alessandro Rubini,
In message 20101229231004.ga17...@mail.gnudd.com you wrote:
#define writeb(v,c) ({ __iowmb(); __arch_putb(v,c); v;})
(note the additional 'v;') should result in correct code, too.
Yes, that's good. Also 0 may work, and may be more readable, (or not,
On 30.12.2010 00:10, Alessandro Rubini wrote:
Dirk Behme:
Just for the record:
The trick is to ensure that the __arch_putx() containing the volatile
is not the last statement in the GCC statement-expression. So, using
something like
#define writeb(v,c) ({ __iowmb();
On 22.12.2010 09:02, Wolfgang Denk wrote:
Dear Alexander Holler,
In message1292711230-3234-1-git-send-email-hol...@ahsoftware.de you wrote:
gcc 4.5.1 seems to ignore (at least some) volatile definitions,
avoid that as done in the kernel.
...
+#define writeb(v,c) ({
Dirk Behme:
Just for the record:
The trick is to ensure that the __arch_putx() containing the volatile
is not the last statement in the GCC statement-expression. So, using
something like
#define writeb(v,c) ({ __iowmb(); __arch_putb(v,c); v;})
(note the additional 'v;')
On 22.12.2010 08:52, Wolfgang Denk wrote:
Dear Dirk Behme,
In message4d11a65e.8040...@googlemail.com you wrote:
Btw, I tried to send a summary of our issues to the Codesourcery =
mailing list:
http://www.codesourcery.com/archives/arm-gnu/msg03989.html
Let's see if we get an answer.
Dear Alexander Holler,
In message 1292711230-3234-1-git-send-email-hol...@ahsoftware.de you wrote:
gcc 4.5.1 seems to ignore (at least some) volatile definitions,
avoid that as done in the kernel.
...
+#define writeb(v,c) ({ __iowmb(); __arch_putb(v,c); })
+#define
Am 22.12.2010 08:02, schrieb Albert ARIBAUD:
Le 22/12/2010 01:11, Alexander Holler a écrit :
Am 21.12.2010 21:04, schrieb Dirk Behme:
On 21.12.2010 20:52, Wolfgang Denk wrote:
Dear Albert friends,
what is your opinion? Should we include the memory barrier patch into
the upcoming
Hello,
Am 22.12.2010 09:02, schrieb Wolfgang Denk:
In message1292711230-3234-1-git-send-email-hol...@ahsoftware.de you wrote:
gcc 4.5.1 seems to ignore (at least some) volatile definitions,
avoid that as done in the kernel.
...
+#define writeb(v,c) ({ __iowmb();
On 21.12.2010 08:21, Albert ARIBAUD wrote:
Hi Dirk,
Le 21/12/2010 08:11, Dirk Behme a écrit :
But the issue with drivers/mtd/nand/omap_gpmc.c (i.e. the additional
ldrbr3, [r3]) is still open? Has anybody tried to replace it with
a nop in the binary to be sure this is the root cause?
Dear Dirk Behme,
In message 4d105fb3.3090...@googlemail.com you wrote:
Broken:
==
...
static void omap_nand_hwcontrol(struct mtd_info *mtd, int32_t cmd,
uint32_t ctrl)
{
register struct nand_chip *this = mtd-priv;
...
if (cmd != -1)
({ do { } while (0); (*(volatile
(Resend with corrected broken example)
On 21.12.2010 08:21, Albert ARIBAUD wrote:
Hi Dirk,
Le 21/12/2010 08:11, Dirk Behme a écrit :
But the issue with drivers/mtd/nand/omap_gpmc.c (i.e. the additional
ldrbr3, [r3]) is still open? Has anybody tried to replace it with
a nop in the
On 21.12.2010 09:17, Wolfgang Denk wrote:
Dear Dirk Behme,
In message4d105fb3.3090...@googlemail.com you wrote:
Broken:
==
...
static void omap_nand_hwcontrol(struct mtd_info *mtd, int32_t cmd,
uint32_t ctrl)
{
register struct nand_chip *this = mtd-priv;
...
if (cmd
On Tue, Dec 21, 2010 at 1:35 AM, Dirk Behme dirk.be...@googlemail.com wrote:
(Resend with corrected broken example)
On 21.12.2010 08:21, Albert ARIBAUD wrote:
Hi Dirk,
Le 21/12/2010 08:11, Dirk Behme a écrit :
But the issue with drivers/mtd/nand/omap_gpmc.c (i.e. the additional
ldrb
Le 21/12/2010 09:46, John Rigby a écrit :
On Tue, Dec 21, 2010 at 1:35 AM, Dirk Behmedirk.be...@googlemail.com wrote:
(Resend with corrected broken example)
On 21.12.2010 08:21, Albert ARIBAUD wrote:
Hi Dirk,
Le 21/12/2010 08:11, Dirk Behme a écrit :
But the issue with
Dear Albert ARIBAUD,
In message 4d1083b4.2060...@free.fr you wrote:
And I at your suggestion tried modifying the binary changing the extra
ldrb to a nop and it works.
Seems like a compiler issue to me, as the preprocessed C source is the
same for the register access and does not call for
Am 21.12.2010 11:53, schrieb Wolfgang Denk:
Dear Albert ARIBAUD,
In message4d1083b4.2060...@free.fr you wrote:
And I at your suggestion tried modifying the binary changing the extra
ldrb to a nop and it works.
Seems like a compiler issue to me, as the preprocessed C source is the
same
Le 21/12/2010 13:35, Alexander Holler a écrit :
Hmm, is there actual somethinbg which should forbid the compiler to
generate such code which rereads something? It might not be nice, but I
don't think that it is forbidden for a compiler to do so. So the proper
way to handle such, might be to
Am 21.12.2010 13:51, schrieb Albert ARIBAUD:
Le 21/12/2010 13:35, Alexander Holler a écrit :
Hmm, is there actual somethinbg which should forbid the compiler to
generate such code which rereads something? It might not be nice, but I
don't think that it is forbidden for a compiler to do so. So
Hello,
Am 21.12.2010 01:25, schrieb John Rigby:
On Mon, Dec 20, 2010 at 10:12 AM, Alexander Hollerhol...@ahsoftware.de
wrote:
There must be more problems. Using gcc 4.5.1, the read*/write*-patch and
...
Yes, you are correct, I see the same here with 4.5.2. I noticed that
bd did not have
Le 21/12/2010 14:30, Alexander Holler a écrit :
Am 21.12.2010 13:51, schrieb Albert ARIBAUD:
Le 21/12/2010 13:35, Alexander Holler a écrit :
Hmm, is there actual somethinbg which should forbid the compiler to
generate such code which rereads something? It might not be nice, but I
don't think
Dear Albert friends,
what is your opinion? Should we include the memory barrier patch into
the upcoming release (and eventually delay it for further testing), or
release as is and solve this issue in the next release?
I tend to leave it as is, as I expect that most people will disappear
in the
On 21.12.2010 20:52, Wolfgang Denk wrote:
Dear Albert friends,
what is your opinion? Should we include the memory barrier patch into
the upcoming release (and eventually delay it for further testing), or
release as is and solve this issue in the next release?
I tend to leave it as is, as
Le 21/12/2010 21:04, Dirk Behme a écrit :
I somehow tend to leave it as is, too.
Agree.
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Am 21.12.2010 21:04, schrieb Dirk Behme:
On 21.12.2010 20:52, Wolfgang Denk wrote:
Dear Albert friends,
what is your opinion? Should we include the memory barrier patch into
the upcoming release (and eventually delay it for further testing), or
release as is and solve this issue in the
Le 22/12/2010 01:11, Alexander Holler a écrit :
Am 21.12.2010 21:04, schrieb Dirk Behme:
On 21.12.2010 20:52, Wolfgang Denk wrote:
Dear Albertfriends,
what is your opinion? Should we include the memory barrier patch into
the upcoming release (and eventually delay it for further
On 22.12.2010 08:02, Albert ARIBAUD wrote:
Le 22/12/2010 01:11, Alexander Holler a écrit :
Am 21.12.2010 21:04, schrieb Dirk Behme:
On 21.12.2010 20:52, Wolfgang Denk wrote:
Dear Albert friends,
what is your opinion? Should we include the memory barrier patch into
the upcoming release
Dear Dirk Behme,
In message 4d11a65e.8040...@googlemail.com you wrote:
Btw, I tried to send a summary of our issues to the Codesourcery =
mailing list:
http://www.codesourcery.com/archives/arm-gnu/msg03989.html
Let's see if we get an answer.
You got one:
Earlier in this thread Alexander said:
I haven't add the definitions which are using a memory barrier because I
haven't found
a place in the kernel where they were actually enabled
(CONFIG_ARM_DMA_MEM_BUFFERABLE).
I think this is the problem because it is indeed defined for all v6
and v7 arm
On Mon, Dec 20, 2010 at 9:08 AM, John Rigby john.ri...@linaro.org wrote:
Earlier in this thread Alexander said:
I haven't add the definitions which are using a memory barrier because I
haven't found
a place in the kernel where they were actually enabled
(CONFIG_ARM_DMA_MEM_BUFFERABLE).
I
Hello,
Am 20.12.2010 07:07, schrieb John Rigby:
With your patch and the following hack nand works:
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index 99b9cef..5e94155 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -29,6 +29,8 @@
On Mon, Dec 20, 2010 at 10:12 AM, Alexander Holler hol...@ahsoftware.de wrote:
There must be more problems. Using gcc 4.5.1, the read*/write*-patch and
your hack, my kernel doesn't boot. Using gcc 4.3.5 and the same source to
compile u-boot the kernel comes up. Here is the output for the
On Mon, Dec 20, 2010 at 5:25 PM, John Rigby john.ri...@linaro.org wrote:
On Mon, Dec 20, 2010 at 10:12 AM, Alexander Holler hol...@ahsoftware.de
wrote:
There must be more problems. Using gcc 4.5.1, the read*/write*-patch and
your hack, my kernel doesn't boot. Using gcc 4.3.5 and the same
On 21.12.2010 01:46, John Rigby wrote:
On Mon, Dec 20, 2010 at 5:25 PM, John Rigbyjohn.ri...@linaro.org wrote:
On Mon, Dec 20, 2010 at 10:12 AM, Alexander Hollerhol...@ahsoftware.de
wrote:
There must be more problems. Using gcc 4.5.1, the read*/write*-patch and
your hack, my kernel
Hi Dirk,
Le 21/12/2010 08:11, Dirk Behme a écrit :
But the issue with drivers/mtd/nand/omap_gpmc.c (i.e. the additional
ldrbr3, [r3]) is still open? Has anybody tried to replace it with
a nop in the binary to be sure this is the root cause?
Can you try and preprocess the C file for both
Hello,
On 19.12.2010 08:51, Dirk Behme wrote:
On 18.12.2010 23:27, Alexander Holler wrote:
gcc 4.5.1 seems to ignore (at least some) volatile definitions,
avoid that as done in the kernel.
Acked-by: Dirk Behme dirk.be...@googlemail.com
Thanks for the ack, but I have to say, that those
Le 19/12/2010 11:22, Alexander Holler a écrit :
Hello,
On 19.12.2010 08:51, Dirk Behme wrote:
On 18.12.2010 23:27, Alexander Holler wrote:
gcc 4.5.1 seems to ignore (at least some) volatile definitions,
avoid that as done in the kernel.
Acked-by: Dirk Behmedirk.be...@googlemail.com
Hello,
Am 19.12.2010 12:28, schrieb Albert ARIBAUD:
Le 19/12/2010 11:22, Alexander Holler a écrit :
Hello,
On 19.12.2010 08:51, Dirk Behme wrote:
On 18.12.2010 23:27, Alexander Holler wrote:
gcc 4.5.1 seems to ignore (at least some) volatile definitions,
avoid that as done in the kernel.
On Sun, Dec 19, 2010 at 3:22 AM, Alexander Holler hol...@ahsoftware.de wrote:
side effects here. Reading NAND now fails on my BeagleBoard. Regardless
if I use gcc 4.3.5 or gcc 4.5.1, after applying that patch the wrong ID
of the NAND is read. In nand_get_flash_type()
Am 19.12.2010 19:45, schrieb John Rigby:
On Sun, Dec 19, 2010 at 3:22 AM, Alexander Hollerhol...@ahsoftware.de
wrote:
side effects here. Reading NAND now fails on my BeagleBoard. Regardless
if I use gcc 4.3.5 or gcc 4.5.1, after applying that patch the wrong ID
of the NAND is read. In
On Sun, Dec 19, 2010 at 12:59 PM, Alexander Holler hol...@ahsoftware.de wrote:
...
No EEPROM on expansion board
Die ID #062a0004040365fa16019019
Hit any key to stop autoboot: 0
OMAP3 beagleboard.org # nand info
Device 0: nand0, sector size 16 KiB
I
Am 20.12.2010 01:39, schrieb John Rigby:
On Sun, Dec 19, 2010 at 12:59 PM, Alexander Hollerhol...@ahsoftware.de
wrote:
...
No EEPROM on expansion board
Die ID #062a0004040365fa16019019
Hit any key to stop autoboot: 0
OMAP3 beagleboard.org # nand info
Device 0: nand0, sector
On Sun, Dec 19, 2010 at 5:56 PM, Alexander Holler hol...@ahsoftware.de wrote:
Am 20.12.2010 01:39, schrieb John Rigby:
On Sun, Dec 19, 2010 at 12:59 PM, Alexander Hollerhol...@ahsoftware.de
wrote:
...
No EEPROM on expansion board
Die ID #062a0004040365fa16019019
Hit any key to
On Sun, Dec 19, 2010 at 9:18 PM, John Rigby john.ri...@linaro.org wrote:
On Sun, Dec 19, 2010 at 5:56 PM, Alexander Holler hol...@ahsoftware.de
wrote:
Am 20.12.2010 01:39, schrieb John Rigby:
On Sun, Dec 19, 2010 at 12:59 PM, Alexander Hollerhol...@ahsoftware.de
wrote:
...
No EEPROM on
On 20.12.2010 07:07, John Rigby wrote:
On Sun, Dec 19, 2010 at 9:18 PM, John Rigbyjohn.ri...@linaro.org wrote:
On Sun, Dec 19, 2010 at 5:56 PM, Alexander Hollerhol...@ahsoftware.de
wrote:
Am 20.12.2010 01:39, schrieb John Rigby:
On Sun, Dec 19, 2010 at 12:59 PM, Alexander
On Sun, Dec 19, 2010 at 11:49 PM, Dirk Behme dirk.be...@googlemail.com wrote:
On 20.12.2010 07:07, John Rigby wrote:
The working assembly looks like this:
if (cmd != NAND_CMD_NONE)
80024d28: e3710001 cmn r1, #1
origwriteb(cmd, this-IO_ADDR_W);
gcc 4.5.1 seems to ignore (at least some) volatile definitions,
avoid that as done in the kernel.
Reading C99 6.7.3 8 and the comment 114) there, I think it is a bug of that
gcc version to ignore the volatile type qualifier used e.g. in __arch_getl().
Anyway, using a definition as in the kernel
On 18.12.2010 23:27, Alexander Holler wrote:
gcc 4.5.1 seems to ignore (at least some) volatile definitions,
avoid that as done in the kernel.
Reading C99 6.7.3 8 and the comment 114) there, I think it is a bug of that
gcc version to ignore the volatile type qualifier used e.g. in
48 matches
Mail list logo
