* [U-Boot] Flag -mno-cache-volatile to bypass the cache
@ 2009-02-05 15:30 ivanchuklist ivanchu
2009-02-05 18:47 ` Wolfgang Denk
0 siblings, 1 reply; 7+ messages in thread
From: ivanchuklist ivanchu @ 2009-02-05 15:30 UTC (permalink / raw)
To: u-boot
Hi list,
I use readl() or writel() to access the hardware but i found a compiler flag
that bypass the cache for all volatile variables, it uses io versions of
load/store functions. So, what should i do, make use of write/read functions
or insert this flag in the makefile?.
It's a nios2 platform. Thank you in advance.
Ivan Llopard.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] Flag -mno-cache-volatile to bypass the cache
2009-02-05 15:30 [U-Boot] Flag -mno-cache-volatile to bypass the cache ivanchuklist ivanchu
@ 2009-02-05 18:47 ` Wolfgang Denk
2009-02-05 20:01 ` ivanchuklist ivanchu
2009-02-07 20:17 ` Scott McNutt
0 siblings, 2 replies; 7+ messages in thread
From: Wolfgang Denk @ 2009-02-05 18:47 UTC (permalink / raw)
To: u-boot
Dear ivanchuklist ivanchu,
In message <51a313240902050730k4f03247etc73ac5579c1f7154@mail.gmail.com> you wrote:
>
> I use readl() or writel() to access the hardware but i found a compiler flag
> that bypass the cache for all volatile variables, it uses io versions of
> load/store functions. So, what should i do, make use of write/read functions
> or insert this flag in the makefile?.
Please continue to use the I/O accessor functions. Your specific
compiler version may understand such an option, but don't expect that
any other compiler or architecture provides the same - so better stay
portable and use what was designed exactly for this purpose.
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
Perl itself is usually pretty good about telling you what you
shouldn't do. :-) - Larry Wall in <11091@jpl-devvax.JPL.NASA.GOV>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] Flag -mno-cache-volatile to bypass the cache
2009-02-05 18:47 ` Wolfgang Denk
@ 2009-02-05 20:01 ` ivanchuklist ivanchu
2009-02-05 21:18 ` Wolfgang Denk
2009-02-07 20:17 ` Scott McNutt
1 sibling, 1 reply; 7+ messages in thread
From: ivanchuklist ivanchu @ 2009-02-05 20:01 UTC (permalink / raw)
To: u-boot
Thank you wolfgang.
I see also in cpu/nios an implementation of the spi core, it uses volatiles
variables to access hardware, so it will not work. Nevertheless the
implementation is correct.
I'm adding sd access by spi protocol to u-boot, so i created a new file
called mmc_spi.c in cpu/nios2. I faced many problems. I just want to have
access to the fat partition, then i wrote mmc_get_dev and mmc_read_block but
i need to initialize the card so i implemented mmc_init (which add mmc
command) and i don't want to write mmc_read/write/2info. Should i implement
those functions?. In the other hand, should i use spi_xfer() to do spi
transactions?.
Regards,
Ivan Llopard.
2009/2/5 Wolfgang Denk <wd@denx.de>
> Dear ivanchuklist ivanchu,
>
> In message <51a313240902050730k4f03247etc73ac5579c1f7154@mail.gmail.com>
> you wrote:
> >
> > I use readl() or writel() to access the hardware but i found a compiler
> flag
> > that bypass the cache for all volatile variables, it uses io versions of
> > load/store functions. So, what should i do, make use of write/read
> functions
> > or insert this flag in the makefile?.
>
> Please continue to use the I/O accessor functions. Your specific
> compiler version may understand such an option, but don't expect that
> any other compiler or architecture provides the same - so better stay
> portable and use what was designed exactly for this purpose.
>
> 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
> Perl itself is usually pretty good about telling you what you
> shouldn't do. :-) - Larry Wall in <11091@jpl-devvax.JPL.NASA.GOV>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] Flag -mno-cache-volatile to bypass the cache
2009-02-05 20:01 ` ivanchuklist ivanchu
@ 2009-02-05 21:18 ` Wolfgang Denk
2009-02-06 16:26 ` ivanchuklist ivanchu
0 siblings, 1 reply; 7+ messages in thread
From: Wolfgang Denk @ 2009-02-05 21:18 UTC (permalink / raw)
To: u-boot
Dear ivanchuklist ivanchu,
In message <51a313240902051201k1977196cu314e60a1cfcd0e11@mail.gmail.com> you wrote:
>
> I see also in cpu/nios an implementation of the spi core, it uses volatiles
> variables to access hardware, so it will not work. Nevertheless the
> implementation is correct.
I'm not a NIOS expert - but if it doesn't work, this should be fixed.
Patches welcome.
> I'm adding sd access by spi protocol to u-boot, so i created a new file
> called mmc_spi.c in cpu/nios2. I faced many problems. I just want to have
> access to the fat partition, then i wrote mmc_get_dev and mmc_read_block but
> i need to initialize the card so i implemented mmc_init (which add mmc
> command) and i don't want to write mmc_read/write/2info. Should i implement
> those functions?. In the other hand, should i use spi_xfer() to do spi
> transactions?.
Sorry, I don't know any of this code,
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
"What terrible way to die."
"There are no good ways."
-- Sulu and Kirk, "That Which Survives", stardate unknown
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] Flag -mno-cache-volatile to bypass the cache
2009-02-05 21:18 ` Wolfgang Denk
@ 2009-02-06 16:26 ` ivanchuklist ivanchu
2009-02-07 11:07 ` ivanchuklist ivanchu
0 siblings, 1 reply; 7+ messages in thread
From: ivanchuklist ivanchu @ 2009-02-06 16:26 UTC (permalink / raw)
To: u-boot
I feel like a fool :S. If i didn't miss anything spi_xfer is defined in
include/spi.h and that function is implemented in cpu related code. I see
also that atmel has put their code in drivers/spi and drivers/mmc. Finally i
took as example cpu/pxa/mmc.c where i found functions (defined in
include/mmc.h) to provide access to the mmc card with the commands cp and
mmc (if CONFIG_CMD_MMC is defined). Then, i chose to put my code in
cpu/nios2/mmc_spi.c to implement the following functions,
Functions used in common/cmd_mmc.c,
mmc_read: return -1 (cp error)
mmc_write: return -1 (cp error)
mmc2info: return -1 (cp error)
mmc_init: it initializes the card in spi mode and it fills the
block_dev_desc_t structure (mmc command).
Functions used to access the block device,
mmc_block_read: it reads a block in spi mode and its passed as a pointer in
the field block_read in block_dev_desc_t (used in fs/fat/fat.c to access the
partition table)
mmc_get_dev: to give a pointer to the block_dev_desc_t variable (needed by
disk/part.c because CONFIG_MMC is defined).
Because i had to write functions to manage the spi core, i thought that
spi_xfer() should be used to access the core in mmc_block_read.
I'm a little lost because there are some implementations that places the
code in cpu/ and others in drivers/. Is the code well placed in cpu/?. I
would like to write the code as it should be written and i wouldn't like to
mess up the code tree.
Regards,
Ivan Llopard.
2009/2/5 Wolfgang Denk <wd@denx.de>
> Dear ivanchuklist ivanchu,
>
> In message <51a313240902051201k1977196cu314e60a1cfcd0e11@mail.gmail.com>
> you wrote:
> >
> > I see also in cpu/nios an implementation of the spi core, it uses
> volatiles
> > variables to access hardware, so it will not work. Nevertheless the
> > implementation is correct.
>
> I'm not a NIOS expert - but if it doesn't work, this should be fixed.
> Patches welcome.
>
> > I'm adding sd access by spi protocol to u-boot, so i created a new file
> > called mmc_spi.c in cpu/nios2. I faced many problems. I just want to have
> > access to the fat partition, then i wrote mmc_get_dev and mmc_read_block
> but
> > i need to initialize the card so i implemented mmc_init (which add mmc
> > command) and i don't want to write mmc_read/write/2info. Should i
> implement
> > those functions?. In the other hand, should i use spi_xfer() to do spi
> > transactions?.
>
> Sorry, I don't know any of this code,
>
> 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
> "What terrible way to die."
> "There are no good ways."
> -- Sulu and Kirk, "That Which Survives", stardate unknown
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] Flag -mno-cache-volatile to bypass the cache
2009-02-06 16:26 ` ivanchuklist ivanchu
@ 2009-02-07 11:07 ` ivanchuklist ivanchu
0 siblings, 0 replies; 7+ messages in thread
From: ivanchuklist ivanchu @ 2009-02-07 11:07 UTC (permalink / raw)
To: u-boot
I'd like to add mmc/spi support to u-boot for nios2 processors but i don't
receive any response about this. Anyway, thanks you all.
Regards,
Ivan Llopard
2009/2/6 ivanchuklist ivanchu <ivanchuklist@gmail.com>
> I feel like a fool :S. If i didn't miss anything spi_xfer is defined in
> include/spi.h and that function is implemented in cpu related code. I see
> also that atmel has put their code in drivers/spi and drivers/mmc. Finally i
> took as example cpu/pxa/mmc.c where i found functions (defined in
> include/mmc.h) to provide access to the mmc card with the commands cp and
> mmc (if CONFIG_CMD_MMC is defined). Then, i chose to put my code in
> cpu/nios2/mmc_spi.c to implement the following functions,
>
> Functions used in common/cmd_mmc.c,
> mmc_read: return -1 (cp error)
> mmc_write: return -1 (cp error)
> mmc2info: return -1 (cp error)
> mmc_init: it initializes the card in spi mode and it fills the
> block_dev_desc_t structure (mmc command).
>
> Functions used to access the block device,
> mmc_block_read: it reads a block in spi mode and its passed as a pointer in
> the field block_read in block_dev_desc_t (used in fs/fat/fat.c to access the
> partition table)
> mmc_get_dev: to give a pointer to the block_dev_desc_t variable (needed by
> disk/part.c because CONFIG_MMC is defined).
>
> Because i had to write functions to manage the spi core, i thought that
> spi_xfer() should be used to access the core in mmc_block_read.
> I'm a little lost because there are some implementations that places the
> code in cpu/ and others in drivers/. Is the code well placed in cpu/?. I
> would like to write the code as it should be written and i wouldn't like to
> mess up the code tree.
>
> Regards,
> Ivan Llopard.
>
> 2009/2/5 Wolfgang Denk <wd@denx.de>
>
>> Dear ivanchuklist ivanchu,
>>
>>
>> In message <51a313240902051201k1977196cu314e60a1cfcd0e11@mail.gmail.com>
>> you wrote:
>> >
>> > I see also in cpu/nios an implementation of the spi core, it uses
>> volatiles
>> > variables to access hardware, so it will not work. Nevertheless the
>> > implementation is correct.
>>
>> I'm not a NIOS expert - but if it doesn't work, this should be fixed.
>> Patches welcome.
>>
>> > I'm adding sd access by spi protocol to u-boot, so i created a new file
>> > called mmc_spi.c in cpu/nios2. I faced many problems. I just want to
>> have
>> > access to the fat partition, then i wrote mmc_get_dev and mmc_read_block
>> but
>> > i need to initialize the card so i implemented mmc_init (which add mmc
>> > command) and i don't want to write mmc_read/write/2info. Should i
>> implement
>> > those functions?. In the other hand, should i use spi_xfer() to do spi
>> > transactions?.
>>
>> Sorry, I don't know any of this code,
>>
>> 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
>> "What terrible way to die."
>> "There are no good ways."
>> -- Sulu and Kirk, "That Which Survives", stardate unknown
>>
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] Flag -mno-cache-volatile to bypass the cache
2009-02-05 18:47 ` Wolfgang Denk
2009-02-05 20:01 ` ivanchuklist ivanchu
@ 2009-02-07 20:17 ` Scott McNutt
1 sibling, 0 replies; 7+ messages in thread
From: Scott McNutt @ 2009-02-07 20:17 UTC (permalink / raw)
To: u-boot
> Please continue to use the I/O accessor functions. Your specific
> compiler version may understand such an option, but don't expect that
> any other compiler or architecture provides the same - so better stay
> portable and use what was designed exactly for this purpose.
Yes, please do use the accessor functions. This particular compiler
flag is the result of someone's brain fart -- and does little more
than confuse the meaning of the volatile keyword (which has absolutely
_nothing_ to do with cache access) ... while promoting poorly considered
code.
--Scott
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-02-07 20:17 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-02-05 15:30 [U-Boot] Flag -mno-cache-volatile to bypass the cache ivanchuklist ivanchu
2009-02-05 18:47 ` Wolfgang Denk
2009-02-05 20:01 ` ivanchuklist ivanchu
2009-02-05 21:18 ` Wolfgang Denk
2009-02-06 16:26 ` ivanchuklist ivanchu
2009-02-07 11:07 ` ivanchuklist ivanchu
2009-02-07 20:17 ` Scott McNutt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox