* [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