I would guess so. Still waiting for the scope to be delivered. You can also use oliv3r's packer I think: https://gitlab.com/riglol/rigolee/#gel-packer
But I'm not sure if this is tested at all.
It was only tested to generate small GEL files that do, for example, backup the calibration partition etc. using the scripts here;
https://gitlab.com/riglol/rigolee/tree/MSO5000/targetYou simple build a GEL file by using one of the scripts as the update scripts. They have been tried and used, but not tested and validated
Yes, 00.01.01.02.06 was the first version having the the start of the ssh daemon commited away in /etc/init.d/rcS
You could try an earlier version or be the first person to try oliv3r's packer
Or did someone already test the packaging function?
EDIT: Oh okay, I guess downgrading is not possible?
You can downgrade, but you have to fake the version number.
Anyways. I don't know if downgrading is a good idea with calibration data and such. I think i also saw a check against it in fw4linux.sh.
oliv3r's packer will only do the firmware flash encryption (so i could batch out the downgrade stop). It will not generate the image files etc.
No, it will generate GEL update files. It will not however, generate filesystem images (such as initramfs and ubifs). It is afterall only a packer
@Oliv3r, I had to add --owner=rigolee --group=rigolee to the tar commands.
Sure, but why? Then again, I've only run the scripts so far, so the change does seem sensible of course.
So next step is to pack the rootfs/rigol folder as an UBIFS image
Yeah, but that's a little trickier with the permissions, git doesn't like the users much. I do add them with the proper permissions I think (root:root 600 for example) but haven't check what happens to this on check-out.
So generating an accurate ubifs would be harder (but far from impossible
This means hacking is now as easy as inserting a USB key and pressing "Go!" (or whatever it says on screen).
No need to mess around with SSH or Vi.
Once we can create the update files. I'm not the best in shell scripts, so somebody else might be faster. Oliv3r?
I've written the packer a few months ago :p and posted links here; nobody took up to challange to write scripts to do these things
(such as adding the -fullopt for example, and now patching the appEntry).
I hadn't gotten around to do doing it myself yet; and probably not going to yet. I probably will add a 'start ssh' update
Thank you!
So packaging should be possible with:
mkfs.ubifs -m 2048 -e 128KiB -c 800 -r /rootfs/rigol app.img
Not sure about the compression type (-x param)..
Then gzip it and run oliv3r's script. Can't try it till tomorrow though..
Sure, but why would you want to? You can also just add the patched appEntry; and write a simple update script that does 'cp appEntry /rigol/appEntry' no?
With regards to ubifs, i did use one of those python ubi unpackers. So repacking it with the same tool should be possible. A version check should be added though (md5sum of the original file) as you otherwise overwrite 'any' version.
I'm missing something... how do you plan to patch the app file that is currently running?? The system allows it?
Should work just fine, the file is read into memory and executed from there. App-entry should never try to rewrite itself anyway. So copy file, reboot scope, profit
Good idea :-D, but no. The easiest solution i found was to just convert the binary file to hexadecimal representation, patch it as text, and reverse the process. It looks like the busybox patch command is very slow though. But as an advantage you get the context sensitivity of patch, so it will also fail if the "surroundings" of the binary do not exactly match.
Little sledge-hammer method. Just be sure not to write the HEX file to the NAND filesystem. NAND is already super sensitive to wear and tear. Writing so much data just for the patch, just wears the NAND unessaserly. Write to tmpfs/ramfs instead. (/ and probably /tmp should be ramfs).
BUT monday/tuesday I should finally receive my own scope. Now if someone can free up some time on my calander