Skyeye on Ubuntu 13.04 and Fedora Update

Joel Sherrill

unread,

Apr 29, 2013, 12:14:45 PM4/29/13

to skyeye-s...@googlegroups.com

Hi

I decided to follow your lead and try this on Ubuntu. After the final make install,

this is what was installed:

joel@JoelD830:~$ ls ~/skyeye/install-git/bin

mknandflashdump skyeye_cli.pyc skyeye_lib_path.py skyeye_module.py

prof_convert skyeye_init.py skyeye_lib_path.pyc skyeye_module.pyc

skyeye_cli.py skyeye_init.pyc skyeye_main.py uart_instance

joel@JoelD830:~$ cat /etc/issue

Ubuntu 13.04 \n \l

When I invoked skyeye_main.py, it reported a version number of 1.3.2.

Michael.Kang

unread,

May 2, 2013, 7:56:02 AM5/2/13

to skyeye-simulator

Sorry for my late response due to my labour day vacation. I have not worked on the labour day....

The master branch is not updated for too long time. I am trying to clean it and update to the stable and latest state

to keep up with our development recently.

You can try to use branch skyeye_1_3_5_rel or wait one day or two day for the done of master branch updated.

After a quick testing of rtems testcases in SkyEye against skyeye_1_3_5_rel, I found now only the testcase

of edb7312 can run hello.exe successfully.

Thanks your indication of the existing issue of automake/autoconf in SkyEye source tree. I will commit the

Makefile.in and other auto-generated file. And at the same time, exclude autom4te.cache directory under
source control. Probably I really need to spend more time on the system of autoconf/automake .

And skyeye_cli.py is temporary plan and now skyeye binary is return.

Any questions, please do not hesitate to send email to the list.

Thanks

MK

--
您收到此邮件是因为您订阅了 Google 网上论坛的“skyeye-simulator”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 skyeye-simulat...@googlegroups.com。
要向此网上论坛发帖，请发送电子邮件至 skyeye-s...@googlegroups.com。
通过以下网址访问此论坛：http://groups.google.com/group/skyeye-simulator?hl=zh-CN。
要查看更多选项，请访问 https://groups.google.com/groups/opt_out。

--

www.skyeye.org

Joel Sherrill

unread,

May 2, 2013, 11:16:12 AM5/2/13

to skyeye-s...@googlegroups.com

On Thu, May 2, 2013 at 6:56 AM, Michael.Kang <blackf...@gmail.com> wrote:

Sorry for my late response due to my labour day vacation. I have not worked on the labour day....

No problem.

The master branch is not updated for too long time. I am trying to clean it and update to the stable and latest state

to keep up with our development recently.

There are so many git development models. RTEMS uses master like a head and

branches for releases.

You can try to use branch skyeye_1_3_5_rel or wait one day or two day for the done of master branch updated.

No problem. I am hoping to get enough groundwork laid where another person

can step in and take over.

After a quick testing of rtems testcases in SkyEye against skyeye_1_3_5_rel, I found now only the testcase

of edb7312 can run hello.exe successfully.

Hmm.. I wonder how long ago each one ran actually ran successfully. :(

Any advice on a git bisect strategy? I planned to start by testing all RTEMS

executables in the tests against the end of all release branches? But once I have

that, should I git bisect the branch that is first broken on?

And ...how do you run skyeye these days? It doesn't look familiar. :(

And would it help to know about the other test cases working or not working

as we go through the testing?

Thanks your indication of the existing issue of automake/autoconf in SkyEye source tree. I will commit the

Makefile.in and other auto-generated file. And at the same time, exclude autom4te.cache directory under
source control. Probably I really need to spend more time on the system of autoconf/automake .
And skyeye_cli.py is temporary plan and now skyeye binary is return.

OK.

Any questions, please do not hesitate to send email to the list.

Thanks.

Reply all

Reply to author

Forward