How to read and write value in two different systems?

[Altera_Forum]

Dear everyone, 

I am now working on a multicore system. cpu_0 runs uclinux, cpu_1 runs a piece of program,   the base address of led_red( pio ) in the SOPCBuilder is 0x00400000, the base address of led_red in nios2_system.h in uclinux is 0x80400000. I have succeed in writing a value onto the led_red through program in uclinux, however, when I tried to read the written value through a program( cpu_1 ) without a system, it always appears the same value "-1".   Here&#39;s the small program in cpu_0(uclinux).# define LEDR_BASE 0x80400000 int main(){ int *led_red = (int *) LEDR_BASE; *(led_red) = 128; return 0; }   after running it in the uclinux, the 8th led_red lights on.   Here&#39;s the small program in cpu_1.# include <stdio.h># define LEDR_BASE 0x00400000 int main() {  printf("Hello from Nios II!\n");  int *red_red = (int *)LEDR_BASE;  printf("%d",*red_red);    return 0; } after running it the console always shows the value of -1   I don&#39;t know why,could somebody help me? Thanks.   Yours sincerely, babysnow

[Altera_Forum]

As already said in the other thread, I don&#39;t suppose it&#39;s a good idea to access anything (in fact especially memory) from both CPUs via the same Avalon bus.  

 Moreover I don&#39;t think it&#39;s a good idea to (in Linux) access anything from userland software using the "0x80000000 + hardware_address". There are decent (portable) means provided to do this (e.g. using "uio" from user land or better doing a decent Kernel driver) and using the correct (portable) macros provided to avoid caching.   But of course for testing purpose you can happily ignore these suggestions.  You do know that (only with a non-MMU-NIOS2-system) setting bit 31 means "don&#39;t cache" ?!?!?!?  Thus in your test you might try to use the "0x80000000 + hardware_address" notation with your second CPU as well, if same is a NIOS2 without MMU and with data-Cache.   -Michael

[Altera_Forum]

<div class='quotetop'>QUOTE (mschnell @ Aug 11 2009, 01:36 AM) <{post_snapback}> (index.php?act=findpost&pid=23473)</div> 

--- Quote Start ---  As already said in the other thread, I don&#39;t suppose it&#39;s a good idea to access anything (in fact especially memory) from both CPUs via the same Avalon bus.   Moreover I don&#39;t think it&#39;s a good idea to (in Linux) access anything from userland software using the "0x80000000 + hardware_address". There are decent (portable) means provided to do this (e.g. using "uio" from user land or better doing a decent Kernel driver) and using the correct (portable) macros provided to avoid caching.   But of course for testing purpose you can happily ignore these suggestions.  You do know that (only with a non-MMU-NIOS2-system) setting bit 31 means "don&#39;t cache" ?!?!?!?  Thus in your test you might try to use the "0x80000000 + hardware_address" notation with your second CPU as well, if same is a NIOS2 without MMU and with data-Cache.   -Michael[/b]  --- Quote End ---    Thank you for your reply. It&#39;s staying at a primary stage, so the simple thing is only for testing. I have tried the "0x80000000 + hardware_address" in NIOSII IDE program, but the result is always -1. I suppose whether the reason lies in the led hardware. led light doesn&#39;t store value, once it lights on, the value disappears. Or another reason may be using the led_red[17..0] is out of the variable range.  And I have found a reference in nioswiki: http://nioswiki.com/accessing_hardware_reg..._space_programs (http://nioswiki.com/accessing_hardware_registers_from_user_space_programs) Will it help?I am quite new to it, hoping to hear from your instruction.

[Altera_Forum]

There are many ways to do a more portable hardware access. mmap is one of them. Others are a dedicated Kernel driver that more specifically handles the hardware in question and the "uio" stuff that does not seem use specific Kernel code. 

 Of course it might be that the "LED" "hardware" port does not provide read access to the latches holding the state of the LEDs. IMHO that would be quite unusual. You should check the appropriate HDL implementation and maybe upgrade it.   -Michael

[Altera_Forum]

<div class='quotetop'>QUOTE </div> 

--- Quote Start ---  There are many ways to do a more portable hardware access. mmap is one of them. Others are a dedicated Kernel driver that more specifically handles the hardware in question and the "uio" stuff that does not seem use specific Kernel code.[/b]  --- Quote End ---   I have checked many references. Some mentioned the idea of mailbox, which I think is very convenient. Does it need to add an driver for uclinux to own the access to mailbox. Or any other ideas? I will gather more information about mmap and uio, coz they are quite new to me.   <div class='quotetop'>QUOTE </div>  --- Quote Start ---  Of course it might be that the "LED" "hardware" port does not provide read access to the latches holding the state of the LEDs. IMHO that would be quite unusual. You should check the appropriate HDL implementation and maybe upgrade it.[/b]  --- Quote End ---   Thanks to your instructions. I have tried the sram, the read and write function runs well. The problem may be the specific characteristic of LED hardware.

[Altera_Forum]

<div class='quotetop'>QUOTE (babysnow @ Aug 11 2009, 11:20 AM) <{post_snapback}> (index.php?act=findpost&pid=23477)</div> 

--- Quote Start ---  I have checked many references. Some mentioned the idea of mailbox, which I think is very convenient.[/b]  --- Quote End ---  Ooops Mailboxes are a means to communicate between two CPUs, not between a Linux userland process and some hardware device. Of course a mailbox is a hardware device (i.e. a one stage FIFO, a multi-stage FIFO will provide more performance, if needed), so the Linux system needs a dedicated device driver (or something else) to decently access same from userland. <div class='quotetop'>QUOTE (babysnow @ Aug 11 2009, 11:20 AM) <{post_snapback}> (index.php?act=findpost&pid=23477)</div>  --- Quote Start ---  I have tried the sram, the read and write function runs well. The problem may be the specific characteristic of LED hardware.[/b]  --- Quote End ---   So the "LED" hardware really does not provide read access to the latch.   -Michael

[Altera_Forum]

The ultimate purpose of doing so is to commucnicate between the uclinux and program. 

The user land process may be a destination, and the hardware device may be an transimittion, not the purpose. Which means I only wanna create a communication byte between them, also to prevent accessing simultaneously.  Also , I wanna create a share memory between them. But that may be the next step. 

[Altera_Forum]

<div class='quotetop'>QUOTE (babysnow @ Aug 11 2009, 11:54 AM) <{post_snapback}> (index.php?act=findpost&pid=23479)</div> 

--- Quote Start ---  Also , I wanna create a share memory between them. But that may be the next step.[/b]  --- Quote End ---  Not a good idea IMHO. A FIFO will be much less problematic and supposedly offer not much less performance. Maybe even more performance, as a shared memory - unless it&#39;s a dual ported design - needs to do hardware access control with any read and write cycle.  -Michael 

[Altera_Forum]

<div class='quotetop'>QUOTE (mschnell @ Aug 11 2009, 06:45 AM) <{post_snapback}> (index.php?act=findpost&pid=23480)</div> 

--- Quote Start ---  <div class='quotetop'>QUOTE (babysnow @ Aug 11 2009, 11:54 AM) <{post_snapback}> (index.php?act=findpost&pid=23479)  --- Quote End ---    --- Quote Start ---  Also , I wanna create a share memory between them. But that may be the next step.[/b]  --- Quote End ---  Not a good idea IMHO. A FIFO will be much less problematic and supposedly offer not much less performance. Maybe even more performance, as a shared memory - unless it&#39;s a dual ported design - needs to do hardware access control with any read and write cycle.  -Michael [/b]  --- Quote End ---    The shared memory is a intermediate medium ,which is used to sent messages between them. My thought is to create a mailbox, will that be much more trouble? If so, can you give much more details or useful reference about FIFO. Thank you very much.

[Altera_Forum]

Of course, shared memory, accompanied by a hardware Mutex, is a perfectly legal design. It can be done as (1) a real dual ported RAM, accessible simultaneously by both CPUs or (2) simply by using the Avalon bus to handle mutual accesses. (2) might slow down both systems, as any access to the RAM needs to wait until an access from the other CPU is over. This is especially bad if that RAM is not dedicated to the inter-CPU communication but holds other data or even code, as well.  

 Regarding designing a FiFo by means of an FPAG, I suppose there is lots of literature in the Internet.   Here supposedly a pair of FiFos, one in either direction, is the most useful design.   Each CPU sees it&#39;s own read port (reading the incoming FiFo), write port (writing the outgoing FiFo) and flag port. The flags being (e.g.) "outgoing FiFo full" and "incoming FiFo empty". A "clear outgoing FiFo" command port might be useful, too. (See the datasheet of some hardware FiFo.)  Additionally, for speed, it might be useful to have the FiFos create interrupts towards the appropriate CPU, if the incoming FiFo gets "not empty" and/or if the outgoing FiFo gets "not full" (or e.g. "not half full").   The CPU interface might be similar to a hardware UART with a built-in FiFo (e.g. 16550).   -Michael

[Altera_Forum]

Thank you for your instruction. 

Maybe I could use a more mediate way. the onchip memory (32 bit ) stores the flag, and the sram( 512kb ) stores the data wanna be communicated.  onchip memory&#39;s accessibility is arbitrated by avalon bridge. sram&#39;s accessibility is arbitrated by flag status.  What about this idea?  By the way,is there anything do with the cache? Should I notice the effect of cache flushing?

[Altera_Forum]

If you really want to do a shared memory region, you don&#39;t need the "flag", but you do need a hardware Mutex to allow the processors to be sure which one is allowed to write to critical memory locations e.g. to create a Mailbox mechanism: a CPU sets a bit to say: "mailbox contains data", the other CPU clears the bit to say: "data read and can be replaced" by new data. These operations need to be protected against each other. Altead SOPC-Builder does provide a Mutex on the Avalon bus for that purpose. I suppose it can issue an interrupt so that one CPU can notify the other of changes of the mailbox state.  

 If the shared memory is a "hardware" unit dedicated for communication, this will not slow down the CPUs, as (AFAIK) the Avalon "bus" is not a real bus, but a link between any master and any slave is created, so that accesses from two masters to different slaves can be done in parallel .   -Michael

[Altera_Forum]

<div class='quotetop'>QUOTE </div> 

--- Quote Start ---  but you do need a hardware Mutex to allow the processors to be sure which one is allowed to write to critical memory locations e.g. to create a Mailbox mechanism: a CPU sets a bit to say: "mailbox contains data", the other CPU clears the bit to say: "data read and can be replaced" by new data.[/b]  --- Quote End ---    What is the exact meaning of CPU bit?   <div class='quotetop'>QUOTE </div>  --- Quote Start ---  These operations need to be protected against each other. Altead SOPC-Builder does provide a Mutex on the Avalon bus for that purpose. I suppose it can issue an interrupt so that one CPU can notify the other of changes of the mailbox state.[/b]  --- Quote End ---   The mutex on the Avalon bus is automatically generated, isn&#39;t it? Which means although I cannot visually see it ,but the Avalon bus has its own arbitration, to prevent the conflict?  I have already tested an idea. cpu_1 in charges of Program which stores in sdram ( reset addr 2)  cpu_0 in charges of Uclinux which stores in sdram (reset addr 1) put the flag (or called it a status 32-bit storage ) in a on-chip memory (NO_DATA,DATA_IN,DATA_OUT) put the shared memory,which is used to store message, in a sram Program keep checking the status( on-chip mem ) ( I have already put a delay() function into it ) Uclinux writes a message onto shared memory and changes the flag, once program realize while checking, it will receive message from sram. However, when running the two processor simultaneously, cpu_1 keeps checking, cpu_0 runs uclinux, sometimes one or both of them go to dead.  I don&#39;t know the reason why. Is it because they are using the same sdram for running?

[Altera_Forum]

Sorry, but I&#39;m not inclined to act as a tutor on the basics of hardware and software design and of English language. :( 

-Michael

[Altera_Forum]

<div class='quotetop'>QUOTE (mschnell @ Aug 12 2009, 04:20 AM) <{post_snapback}> (index.php?act=findpost&pid=23489)</div> 

--- Quote Start ---  Sorry, but I&#39;m not inclined to act as a tutor on the basics of hardware and software design and of English language. :( -Michael[/b]  --- Quote End ---    Sorry to bother you so much. But thank you anyway for your great patience. 

[Altera_Forum]

So please come back after you did some decent research yourself. -Michael

[Altera_Forum]

<div class='quotetop'>QUOTE (mschnell @ Aug 12 2009, 08:26 AM) <{post_snapback}> (index.php?act=findpost&pid=23492)</div> 

--- Quote Start ---  So please come back after you did some decent research yourself. -Michael[/b]  --- Quote End ---     Thank you. I have tried dual core running simultaneously recently. However,I found that when running a uclinux system and a program generated on the basic of reference design "helloworld_small", it runs perfectly. When running a uclinux system and a program generated on the basic of reference design "helloworld", either of the process will stop. There&#39;s only a difference lies in the syslib between "helloworld_small" and "helloworld", I don&#39;t know why "helloworld" leading to the unknown interruption.

[Altera_Forum]

<div class='quotetop'>QUOTE (babysnow @ Aug 13 2009, 05:53 AM) <{post_snapback}> (index.php?act=findpost&pid=23499)</div> 

--- Quote Start ---  <div class='quotetop'>QUOTE (mschnell @ Aug 12 2009, 08:26 AM) <{post_snapback}> (index.php?act=findpost&pid=23492)  --- Quote End ---    --- Quote Start ---  So please come back after you did some decent research yourself. -Michael[/b]  --- Quote End ---     Thank you. I have tried dual core running simultaneously recently. However,I found that when running a uclinux system and a program generated on the basic of reference design "helloworld_small", it runs perfectly. When running a uclinux system and a program generated on the basic of reference design "helloworld", either of the process will stop. There&#39;s only a difference lies in the syslib between "helloworld_small" and "helloworld", I don&#39;t know why "helloworld" leading to the unknown interruption. [/b]  --- Quote End ---    Now I can finished the program simply by the supply of helloworld_small reference design. And it&#39;s only 17kb size for elf file. Thank you anyway!