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

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

<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.

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

<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.

<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

How to read and write value in two different systems?

17 Replies

Altera_Forum
Honored Contributor
16 years ago
If you really want to do a shared memory region, you don'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
Honored Contributor
16 years ago
<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'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't know the reason why. Is it because they are using the same sdram for running?
Altera_Forum
Honored Contributor
16 years ago
Sorry, but I'm not inclined to act as a tutor on the basics of hardware and software design and of English language. :(
-Michael
Altera_Forum
Honored Contributor
16 years ago
<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'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
Honored Contributor
16 years ago
So please come back after you did some decent research yourself. -Michael
Altera_Forum
Honored Contributor
16 years ago
<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's only a difference lies in the syslib between "helloworld_small" and "helloworld", I don't know why "helloworld" leading to the unknown interruption.
Altera_Forum
Honored Contributor
16 years ago
<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's only a difference lies in the syslib between "helloworld_small" and "helloworld", I don'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's only 17kb size for elf file. Thank you anyway!

Forum Discussion

How to read and write value in two different systems?

17 Replies

Recent Discussions

No valid license for Nios processor

Nios-V on Cyclone IV

Correct way to use mSGDMA with a NIOSV/m processor on a MAX10 FPGA

NIOS SDK SBOM/FOSS info

Unable to load Ashling Riscfree NiosV libraries