[U-Boot] Flag -mno-cache-volatile to bypass the cache
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.
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
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@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
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
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@denx.de "What terrible way to die." "There are no good ways." -- Sulu and Kirk, "That Which Survives", stardate unknown
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@denx.de "What terrible way to die." "There are no good ways." -- Sulu and Kirk, "That Which Survives", stardate unknown
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
participants (3)
-
ivanchuklist ivanchu -
Scott McNutt -
Wolfgang Denk