bare metal app

Applications, development tools, FPGA, C, WEB
pavel
Posts: 790
Joined: Sat May 23, 2015 5:22 pm

Re: bare metal app

Post by pavel » Wed Jun 24, 2015 10:04 am

Could you explain the difference between the two commands? Why you call the first one a bug?

The current version of Makefile works for me without any problem.

Arnold
Posts: 54
Joined: Wed Mar 11, 2015 3:07 pm

Re: bare metal app

Post by Arnold » Wed Jun 24, 2015 11:03 pm

Because on some linkers, it will search for the functions from left to right... So if main.o needs a function from hello.o, it sees that in main.o first, then searches to the right, and finds the correct function.

http://lampwww.epfl.ch/~fsalvi/docs/gcc ... ro_14.html
that page explains it, and yes, it says that newer compilers wont care... However, it makes no harm to link things in the correct order in case someone uses a compiler which does care.

pavel
Posts: 790
Joined: Sat May 23, 2015 5:22 pm

Re: bare metal app

Post by pavel » Wed Jun 24, 2015 11:57 pm

The LIBRARIES variable in my Makefile looks like the following:

Code: Select all

 LIBRARIES = -Wl,--start-group,-lxil,-lgcc,-lc,--end-group
Here is what the ld man page says about the start-group/end-group option:
--start-group archives --end-group
The archives should be a list of archive files. They may be either explicit file names, or -l options.
The specified archives are searched repeatedly until no new undefined references are created. Normally, an archive is searched only once in the order that it is specified on the command line. If a symbol in that archive is needed to resolve an undefined symbol referred to by an object in an archive that appears later on the command line, the linker would not be able to resolve that reference. By grouping the archives, they all be searched repeatedly until all possible references are resolved.
So, the start-group/end-group option solves the library ordering problem that you mentioned and I don't see any reason to change anything in my Makefile.

Mike1010
Posts: 23
Joined: Mon Jun 15, 2015 8:02 pm

Re: bare metal app

Post by Mike1010 » Thu Jul 02, 2015 9:52 pm

I tried to use your updated version.

I cannot stop the remoteproc after some on offs....

Does does not deactivate the leds:

Code: Select all

echo 0 > /sys/devices/soc0/1e000000.remoteproc/remoteproc0/up
And i get a error: module zynq_remoteproc with this comment:

Code: Select all

rmmod zynq_remoteproc

pavel
Posts: 790
Joined: Sat May 23, 2015 5:22 pm

Re: bare metal app

Post by pavel » Thu Jul 02, 2015 10:36 pm

I cannot stop the remoteproc after some on offs....
Does it works at least once or twice?

If so, then I've also noticed that sometimes it stops working.

The zynq_remoteproc patch is very simple. If it does not work, then it could be the 'up' file that does not always receive the command or the 'rproc_shutdown(rproc)' function that does not always do that it should.

I'd suggest to ask Henry Choi if he already observed something similar.

Mike1010
Posts: 23
Joined: Mon Jun 15, 2015 8:02 pm

Re: bare metal app

Post by Mike1010 » Thu Jul 02, 2015 10:49 pm

It works once or twice... But than stops working

I remember the first version you uploaded didnt have that problem. This version didnt have modules added....

Can we debug it somehow? How would you do it?
How can you debug app_cpu1.elf?

pavel
Posts: 790
Joined: Sat May 23, 2015 5:22 pm

Re: bare metal app

Post by pavel » Thu Jul 02, 2015 11:07 pm

The only difference between the very first version and the latest one is the following instructions:
Copy modules.order and modules.builtin to /lib/modules/3.18.0-xilinx
I don't think that the problem is with these files.

I've just made a simple script:

Code: Select all

while true
do
  modprobe zynq_remoteproc
  echo 1 > /sys/devices/soc0/1e000000.remoteproc/remoteproc0/up

  sleep 2

  echo 0 > /sys/devices/soc0/1e000000.remoteproc/remoteproc0/up
  rmmod zynq_remoteproc

  sleep 2
done
It was running for a few minutes without any problem. Then I stopped it. So, 30-40 on/offs work just fine.

However, when I do the following:

Code: Select all

modprobe zynq_remoteproc
echo 1 > /sys/devices/soc0/1e000000.remoteproc/remoteproc0/up
echo 1 > /sys/devices/soc0/1e000000.remoteproc/remoteproc0/up
echo 0 > /sys/devices/soc0/1e000000.remoteproc/remoteproc0/up
rmmod zynq_remoteproc
then I get the error:

Code: Select all

rmmod: ERROR: Module zynq_remoteproc is in use
But if I do again

Code: Select all

echo 0 > /sys/devices/soc0/1e000000.remoteproc/remoteproc0/up
rmmod zynq_remoteproc
everything works as it should.

So, it's sensitive to extra 'echo 1'. Otherwise, it works without much problem.

pavel
Posts: 790
Joined: Sat May 23, 2015 5:22 pm

Re: bare metal app

Post by pavel » Thu Jul 02, 2015 11:12 pm

Another way to get the error message:

Code: Select all

modprobe zynq_remoteproc
echo 0 > /sys/devices/soc0/1e000000.remoteproc/remoteproc0/up
rmmod zynq_remoteproc

rmmod: ERROR: Module zynq_remoteproc is in use
So, 'echo 0' before 'echo 1' blocks the zynq_remoteproc driver.

However, the module can be removed with 'rmmod -f':

Code: Select all

rmmod -f zynq_remoteproc
After this command, everything is back to normal.

wickywaka
Posts: 3
Joined: Mon Aug 06, 2018 4:25 pm

Re: bare metal app

Post by wickywaka » Thu Aug 15, 2019 7:54 pm

Hello People,

I know this thread is been long dead but I am working on AMP system using redpitaya and would like know if someone here is of any help or is interested in the topic. Some of my progress can be found on github here hxxps://github.com/RedPitaya/RedPitaya/issues/163

Cheers.
Waqar

wickywaka
Posts: 3
Joined: Mon Aug 06, 2018 4:25 pm

Re: bare metal app

Post by wickywaka » Thu Aug 15, 2019 7:56 pm

Can we change the name of this thread to "Asymmetric Multiprocessing on RedPitaya" or should I open a new one with title.

Post Reply
jadalnie klasyczne ekskluzywne meble wypoczynkowe do salonu ekskluzywne meble tapicerowane ekskluzywne meble do sypialni ekskluzywne meble włoskie

Who is online

Users browsing this forum: No registered users and 24 guests