Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

After upgrading the stock firmware the ft-GUI crashes by starting a SD-Card program #49

Closed
ski7777 opened this issue Aug 15, 2016 · 11 comments

Comments

@ski7777
Copy link
Member

commented Aug 15, 2016

Most is said in the title.
After upgrading the stock firmware to an beta version, I tried to run the ft-GUI in the Community firmware. Mainly it works fine, but after starting a program, which was stored on the SD-Card and which was compiled for RoBoPro 4.2.3, the ft-GUI crashed an started again. After re downloading (and compiling) the program to the TXT the Program works fine. The update script for the stock firmware deletes all downloaded program on the TXT´s Flash.
We need to check, whether the RoBoPro version changed and delete all Programs on the SD-Card.

Raphael

@ski7777

This comment has been minimized.

Copy link
Member Author

commented Aug 15, 2016

In /rom/etc/sysversion the ft-GUI version is stored. At boot we need to check, whether this version is equal to the version stored in a configfile. If the Version is not equal or the configfile is not present we need to delete all programms in /media/sdcard/robopro.
I am not sure, but I think I need to start this Python script via /etc/init.d/rcS. I will try it soon. Currently my Buildroot environment is working fine.

Raphael

@harbaum

This comment has been minimized.

Copy link
Member

commented Aug 15, 2016

RoboPro Version 4.2.3 is the latest available. I don't know what beta versions you use. But it doesn't make too much sense to worry about unreleased beta versions.

Also I personally don't think we should spend too much time working around robopro's shortcomings. And librobopro malfunctioning when trying to load one of its own binaries from a previous version is a problem of robopro and not of the community firmware.

The official firmware contains a bunch of serious flaws. Hacking around them and trying to hide them is imho counter productive. If we do that no-one will ever see a reason to improve the root cause.

@ski7777

This comment has been minimized.

Copy link
Member Author

commented Aug 15, 2016

I have a beta version of RoBoPro 4.2.4. That´s the first upgrade of the stock firmware while developing the Community firmware. If we had started developing the Community firmware earlier with RoBoPro version 4.2.2 and then upgrade to RoBoPro version 4.2.3 we would had the same problem. Now I will prevent the users from a little malfunction.

The problem is, that during the stock firmware update the script calls:
# remove downloaded programs and downloaded programs config file (ignore error)
rm /opt/knobloch/ROBOProFiles/* 2>/dev/null
This is removes all downloaded and compiled RoBoPro files. When this is not executed, the ft-GUI will crash. So on the Community firmware, we have to delete all compiled RoBoPro files, when the stock firmware was updated.

If we do that no-one will ever see a reason to improve the root cause.

Yes, that´s what I think too, but when we work with many errors in a preexisting system, the users will have trouble, they will open an issue and we don´t know where the problem is, because the users don´t write that they did a stock firmware upgrade.

Raphael

@PeterDHabermehl

This comment has been minimized.

Copy link
Contributor

commented May 15, 2018

Any news on this? Do we need to remove the precompiled robopro files?

@ski7777

This comment has been minimized.

Copy link
Member Author

commented May 15, 2018

@PeterDHabermehl

This comment has been minimized.

Copy link
Contributor

commented May 16, 2018

@ski7777 so what would you suggest to handle this?

@rkunze

This comment has been minimized.

Copy link
Member

commented May 16, 2018

I'd suggest to leave it as it is and not waste effort on workaround for RoboPro bugs (and yes, crashing while reading files created with a previous version is a bug).

I think it's an edge case anyway - in order to trigger this, you have to:

  • Store a persistent RoboPro program in the CFW
  • Upgrade RoboPro and the original TXT Firmware
  • Try to run the old program (again with RoboPro from the CFW)

If we do anything about it, I'd suggest to simply mention it on http://cfw.ftcommunity.de/ftcommunity-TXT/de/programming/robopro.html

@ski7777

This comment has been minimized.

Copy link
Member Author

commented May 16, 2018

@rkunze

This comment has been minimized.

Copy link
Member

commented May 16, 2018

Somewhere on the ROM you will find a file containing the Firmware Version.
We could save the contents and compare on every boot. If it has changed we
just drop the files.

That's exactly what I meant with "waste effort" :-) - write, maintain and run extra code in the CFW just to handle an edge case caused by RobPro being incompatible with older versions of itself.

@harbaum

This comment has been minimized.

Copy link
Member

commented May 16, 2018

It's even worse: These are regular arm binaries which are somehow pre-relocated at download time and they crash whenever size and memory layout of libraries they depend on change.

The entire setup is pretty broken. The time would imho better be spent convincing fischertechnik to cooperate with the community on fixing this. And if this is fixed we could even download and run RoboPro binaries on the Raspberry Pi.

@PeterDHabermehl

This comment has been minimized.

Copy link
Contributor

commented May 21, 2018

Ok, no-one has time to waste...
We go Richard's direction. No changes to the cfw, documentation update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.