RS Media fault help please :)

55 posts / 0 new
Last post
Vader
Vader's picture

#Error -3 while decompressing!
c00ec9b0(-7448380)->c0ac3000(4096)

That's referring to the kernel being unable to decompress files from the cramfs file system (which allows data to be decompressed on the fly). So one of the partitions on your RSM has probably gone bad, unfortunately.
I've actually had this happen to me once when I managed to run out of available memory.

Urgentemente
Urgentemente's picture

 

Vader said:

#Error -3 while decompressing! c00ec9b0(-7448380)->c0ac3000(4096)

That's referring to the kernel being unable to decompress files from the cramfs file system (which allows data to be decompressed on the fly). So one of the partitions on your RSM has probably gone bad, unfortunately. I've actually had this happen to me once when I managed to run out of available memory.

 

That's what I was beginning to suspect, especially looking back to the checksum error when trying to update the applications on nand3, I assumed the hex numbers (with their decimal equivalent in brackets) are the actual and expected sizes of whatever it was trying to decompress.

The nearest nand dump in terms of size from those I dumped last night, seems to be nand1 at 7340032 bytes, yet looking through /etc/profile, it's not explicitly mentioned in any of the lines, and it appears to be nand3 that is the only one with any actions on it after the audio driver initialised,

Hard to see really without being able to easily edit the profile and see echo's on screen. If I was doing this on my desktop I'd stick a bunch of "echo this is line xxxx" in , so I could see where it was prior to the error message being generated. Could I use the SDcard rsupdate feature to copy a modified profile to the bot, with sutiable echo statements in place, then use the dump script again and see the output again in dmesg , that should show the line it's reaching in the profile when the decompression error is occurring.

 

OR..

Will I be able to use the USBConsole to access the robots shell (linux shell that is, not it's plastic shell !! ),?  What stage of the robot's boot sequence does that become available at? If it's part of the application suite I'm out of luck,but it sounds more like something that would be part of the kernel, or at least in userspace for the main system.

It's a good job we enjoy a challenge!

Urgentemente
Urgentemente's picture

Hmmm, I got suspicious of the fsck output I had last night, even with verbose it was just saying "checking all file systems". I just tried again, but giving it the full path to the file (despite running it from the same directory last night..), and it now gives more expected output..

According to mount.txt, nand1 and nand2 are cramfs, nand3 is vfat, nand4 and nand5 are ext2 (and likely the source of the "fsck required" messages in dmesg)

So,fsck checks on the nand files again:

nand1: "fsck.cramfs: file length too short"

nand2: "warning: file extends past end of filesystem"

nand3: "dosfsck 3.0.9, 31 Jan 2010, FAT32, LFN

880 files, 7559/22188 clusters"

nand4: "e2fsck 1.41.12 (17-May-2010)

clean, 27/64 files, 32/512 blocks"

nand5: "e2fsck 1.41.12 (17-May-2010)
clean, 12/64 files, 27/512 blocks"

 

Both nand4 and nand5 were checked by fsck the first time I ran the commands tho,due to either  being mounted 299 times without checks (nand5), or being not unmounted cleanly (nand4), but no errors detecetd on either by fsck

/VAULT/RSMEDIA/RSMDUMP/nand4 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/VAULT/RSMEDIA/RSMDUMP/nand5 has been mounted 299 times without being checked, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/VAULT/RSMEDIA/RSMDUMP/nand5: 12/64 files (0.0% non-contiguous), 27/512 blocks

Urgentemente
Urgentemente's picture

Just downloaded the USB console files and read the readme, sounds like I won't be able to use that for now as it needs media mode..

"Go into: Media Mode → Options → USBNet → On."

and I can't get that far right now, so will wait until I've had a chance to remove the covers and check the wires/plugs are all correct.

EDIT:
Ah, perhaps ..
the script in /robot/rsupdateapp ..
"/robot/rsupdate
rsupdateapp Use this if you want to auto load the driver when the robot boots u"

I actually read the script itself before I noticed the comment in the readme :)

Any reason I can't just simply add startusbconsole.sh to the profile, to get it to do the action that would normally be done using the mediamode menus ?

Vader
Vader's picture

The nearest nand dump in terms of size from those I dumped last night, seems to be nand1 at 7340032 bytes, yet looking through /etc/profile, it's not explicitly mentioned in any of the lines, and it appears to be nand3 that is the only one with any actions on it after the audio driver initialised,

/dev/nand1 is mounted by the kernel.

Could I use the SDcard rsupdate feature to copy a modified profile to the bot, with sutiable echo statements in place, then use the dump script again and see the output again in dmesg , that should show the line it's reaching in the profile when the decompression error is occurring.

Not unless you create a custom firmware and flash that on, since cramfs doesn't have write support at all (I could do this for you if you want).

Any reason I can't just simply add startusbconsole.sh to the profile, to get it to do the action that would normally be done using the mediamode menus ?

That should work, although if you put it too early bad stuff tends to happen.

Helibot
Helibot's picture

Hi again,
Unfortunately you cant just copy new profile scripts to the robot cos the root file system is running from a cramfs system. So you actually have to extract out the filesystem , decompress it, modify the file, recompress it and reflash it. It can be done , but its messy. (I wrote a thread on it once - http://www.robocommunity.com/forum/thread/18092/Modfying-RSMedia-root-fi... )

Regarding the USBConsole. You dont need to access MEdia Mode (that step is just to confirm if old drivers need removing. The USBConsole rsupdateapp script will unload the USB mass storage driver and insmods a USB serial driver then redirects a console to the use the USB serial port. It will all work OK with just the basic linux kernal (it doesnt need any of the Wowwee UI or applications running). So if you are up to it then try the USB console - it will give you access to the linux console and then you could inspect the various partitions to see whats missing corrupted.

So in the USBConsole 1.5 readme file Skip step 1 and continue from step 2 (especially see 3.1. "...Optionally, you can place the rsupdateapp in the SDCard /rsupdate directory and have it start up at boot. If you do this, you can then skip Step 4."
So it will work from rsupdateapp script :-)

Here is some info about which partitions are mounted where. Note that /dev/nand3 is only mounted if SD card does NOT exist. So if you have errors on nand3 but are booting from an SDcard it should not matter.

mount WITHOUT SD CARD
/dev/nand1 on / type cramfs (ro)
ramfs on /buffer type ramfs (rw)
/proc on /proc type proc (rw)
/dev/nand2 on /mnt/default type cramfs (rw)
/dev/nand4 on /lnk type ext2 (rw)
/dev/nand5 on /pw type ext2 (ro)
/dev/nand3 on /mnt/sd type vfat (ro)

Mount WITH SDCARD
/dev/nand1 on / type cramfs (ro)
ramfs on /buffer type ramfs (rw)
/proc on /proc type proc (rw)
/dev/nand2 on /mnt/default type cramfs (rw)
/dev/nand4 on /lnk type ext2 (rw)
/dev/nand5 on /pw type ext2 (ro)
/dev/mmc on /mnt/sd type vfat (rw)

If SD is absent then /mnt/SD is mapped to /dev/nand3

During Boot RSMV1 shows
MX1ADS nand I/O driver installed
SSFDC Partitions
nand0 : block 0x0000-0x003e : "Kernel" 1008 KB direct map
nand1 : block 0x003f-0x01fe : "RootDisk" 7168 KB random map
nand2 : block 0x01ff-0x047e : "DefaultDisk" 10240 KB random map
nand3 : block 0x047f-0x0f5a : "UserDisk" 44480 KB random map
nand4 : block 0x0f5b-0x0f7a : "WritableDisk" 512 KB random map
ssxdc
MX1ADS nand flash partition definitions installed

[During boot RSMedia V2 shows
nand0 : block 0x0000-0x0049 : "Kernel" 1184 KB direct map
nand1 : block 0x004a-0x0229 : "RootDisk" 7680 KB random map
nand2 : block 0x022a-0x04a9 : "DefaultDisk" 10240 KB random map
nand3 : block 0x04aa-0x0f5a : "UserDisk" 43792 KB random map
nand4 : block 0x0f5b-0x0f7a : "WritableDisk" 512 KB random map
nand5 : block 0x0f7b-0x0f9a : "PassDisk" 512 KB random map
]

df (disk free) shows (for RSMV1 I think?)
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/nand1 14824 14824 0 100% /
/dev/nand2 11332 11332 0 100% /mnt/default
/dev/nand4 499 196 278 41% /lnk
/dev/nand5 499 14 460 3% /pw
/dev/nand3 44376 33408 10968 75% /mnt/sd

But since you originally saw the CHECKSUM error on Nand1 , then it suggests that some of your root filesystem maybe corrupt....which may explain why it locks up, and could cause issues for access some files from USBConsole??

>#Error -3 while decompressing!
>c00ec9b0(-7448380)->c0ac3000(4096)
>I assumed the hex numbers (with their decimal equivalent in brackets)
>are the actual and expected sizes of whatever it was trying to decompress.
Not sure the numbers are the size of the partition. My guess is that the numbers are the location of the part it is trying to decompress. I am assuming this is caused by a failure of the kernel/driver to extract part of a file from the CRAM File System (likely in nand1). Pyhsically the partition is just one huge compressed file. But logically the file system is a compressed read only file system. It is accessed like a normal file system , but really the driver just goes to the correct part of the compressed file image and extracts out the data it needs for the current read. So I think it is a runtime decompression problem when a particular file (or range of files) is accessed. It doesnt seem to be a terminal error because it continues.

And looking at your fsck above it stated "nand1: "fsck.cramfs: file length too short". So I think that your problem is that nand1 is not correctly programmed. Also when you got the checksum error while flashing the APPLICTIONS area , this is trying to flash /nand1.
Can you do a 'cramfsck -v nand1'? (I assume that when you did dsck it automatically called cramfsck behind the scenes - so you can probably just do 'fsck -v nand1'? Does it flag any files in error?

Also you could try reflashing just the nand1 area with a script like the following. Try it a few times and see if you can get success.
mount /dev/mmc /mnt/sd -o rw,remount
chmod 755 /mnt/sd/rsupdate/*

if [ -f /mnt/sd/rsupdate/rfs_system.cramfs ]
then
/mnt/sd/rsupdate/fb_msg n " "
/mnt/sd/rsupdate/fb_msg n "Updating"
/mnt/sd/rsupdate/fb_msg n "Applications..."
cat /mnt/sd/rsupdate/rfs_system.cramfs > /dev/nand1

/mnt/sd/rsupdate/fb_msg n "Checking..."
/mnt/sd/rsupdate/md5-arm /mnt/sd/rsupdate/rfs_system.md5 /dev/nand1
if [ $? = 0 ]
then
/mnt/sd/rsupdate/fb_msg n "Checksum ok"
else
/mnt/sd/rsupdate/fb_msg n "Checksum error"

/mnt/sd/rsupdate/md5-arm /mnt/sd/rsupdate/rfs_system.md5 /mnt/sd/rsupdate/rfs_system.cramfs
if [ $? = 0 ]
then
/mnt/sd/rsupdate/fb_msg n "Nand Write error"
else
/mnt/sd/rsupdate/fb_msg n "SD Read error"
fi

fi
fi

/mnt/sd/rsupdate/fb_msg n " "
/mnt/sd/rsupdate/fb_msg n "Finish Updating..."
/mnt/sd/rsupdate/fb_msg n "Please restart"
/mnt/sd/rsupdate/fb_msg n "the system."

(PS - you probably know this , but just to be safe - if you copy the text from above and paste it into a file then you MUST save it with UNIX line terminations. If you save it with Windows line termination it wont run correctly in RSMedia)

Cheers
helibot

Urgentemente
Urgentemente's picture

Thanks Vader and Helibot,

now I'm wondering if I've got a V1 or V2 !
The output from dmesg when I dumped it yesterday, matches the section above with "During Boot RSMV1 shows.."
i.e it has the "MX1ADS nand I/O driver installed
SSFDC Partitions
nand0 : block 0x00...." lines
ending with "MX1ADS nand flash partition definitions installed"

The memory shown at the start of dmesg output is 16MB..
"Memory: 16MB = 16MB total" - isn't the RSMV1 16MB, and the RSMV2 32MB?

I'd tried the "RSMV2ReloadFiles" scripts originally to try reloading the application (before we got to the "it might be a crossed over plug" idea ),
but the rsupdateapp script didn't complain about it not being a V2..
yet if I grep the dmesg output from the dump, the "1184 KB direct map" line doesn't exist,

So as I read it, the section of the rsupdateappp that checks the existence of that line, should have failed on my bot if it's a V1..?

#this checks that robot is a RSMV2
#(and therfore has space to fit the V2 kernel)
dmesg | grep "1184 KB direct map"
if [$? = 0 ]
then

If I do "grep "1184 KB direct map" dmesg.txt ;echo $?" (from within the directory where I've got the files from the dump), I get exit status of 1 (as you'd expect..), but on the bot's LCD it didn't display the "Kernel Failed, Wrong size" messages, and went ahead and did /tried to redo the filesystems.

What are the differences in files between a RSMV1 and RSMV2? V2 is missing USBNet right? (boohoo, just when I thought I'd have it 'easy').

What's the best way to confirm for definate what version of bot I have, remove the covers etc and find markings on the boards?
I'm just thinking, if it's gone ahead and reloaded V2 files when it is in fact a V1, could that be causing more problems (as if we the bot was short of them , LOL!)

Sorry for yet more questions!

FreddyA
FreddyA's picture

Hi urgentemente, The media board for a v2 will have solder jumpers on in for 32mb pads, also I think they have a 2007 date.

Freddy.

EDIT: forgot to mention to see the media board you will need to open the rsm plastic shell not the linux shell haha

Urgentemente
Urgentemente's picture

FreddyA said: Hi urgentemente, The media board for a v2 will have solder jumpers on in for 32mb pads, also I think they have a 2007 date. Freddy. EDIT: forgot to mention to see the media board you will need to open the rsm plastic shell not the linux shell haha

Hehe, LOL.

 

Cool, when I get the casing (just to avoid shell confusion  :)  ), off , I'll take some photos of the boards etc and determine just exactly which version it is.

I'm really trying to make myself wait till the weekend so I can take my time, but it's sooooo tempting to start opening it up tonight - but I'm trying to learn from my mistakes, as my poor RSV2 is still semi-naked with all the screws mixed up, and has been that way for about 6+ months ..

FreddyA
FreddyA's picture

Coincidence, My V2 was in parts for about the same time, just recently got it back together with a couple of mods and wire harness repairs.. I've learned where things go after taking the time to rebuild one of my RS Medias from the ground up with new parts. Now I could win an assembly race haha

Urgentemente
Urgentemente's picture

Well,well.well...

As RSV2 would say "USER ERROR" !!

I've just reflashed with the original RSMV1 firmware, based on the 16MB dmesg line, and more so the "During Boot RSMV1 shows
MX1ADS nand I/O driver installed
SSFDC Partitions" that Helibot posted earlier, leading to suspicions that it's a V1 and not a V2,..and....

nearly got deafened when it booted up and shouted "XY displacement" the rebooted.
Rebooted, "Systems check"...
cancelled it with Stop on the remote, then found the mute (girlfriend is alseep! LOL, and I don't think she'd appreciate being woken up by a very loud RSMedia..)
Took a photo as a quick test and appears to be working.

So I now have at least what appears to be a working bot from a OS point of view, now just have to strip it down and find out all the motor/gearbox issues that are causing the shutdowns..

I'll never know wether it was already flashed incorrectly with a V2 set or not, as at the point that I tried moving the head to get it past the white screen of death (WSOD, LOL sounds like WMD) , I had left the SDcard in with the updated script for a V2 flash.

Many continuing thanks to you guys for all the ideas to try, it's much appreciated to have you all to bounce ideas off first. e.g having never used cramfs before, I just assumed it was compressed/decompressed on the fly, so writing was same as any other filesystem, that would have lead to a few hours head bashing I think!

Urgentemente
Urgentemente's picture

Well, I've just been like a kid on xmas morning for the last 20 mins, despite the frequent reboots when I accidentally trigger a sequence that makes him try and move, I've flicked through the options (and put the volume on the 1st notch above complete silence for now!), view the (grainy..) photo I took earlier, and much to my suprise found that I can move the arms without any apparent problems using Arm mode, tho when I tried "left wave" it shutdown, probably it went to change position similar to the RSV2 motion?

So all in all, a major step forward so far, here's hoping I can get the motor/gear probs fixed at some point and bring him back to full health (before starting on mods,LOL)

FreddyA
FreddyA's picture

Very cool, good job on getting the OS going. In regards to the motor board, the parts you will find gone bad will likely be these http://www.robocommunity.com/forum/thread/17494/RS-Media-Fried-electroni...
and like helibot, I have also had to replace these.

Freddy

edit: here is the result of all that you might have very similar results! http://www.robocommunity.com/forum/thread/17494/RS-Media-Fried-electroni.... Helibot is the master

Urgentemente
Urgentemente's picture

Thanks Freddy,
I had a very quick browse through that "fried electronics" thread earlier today, but not in depth yet.
My soldering skills are, shall we say, not the best... :)

My RSV2 is probably needing some components replaced as well, it struggles getting up and Nocturnal suggested it may be one of the H-bridges giving up.

After reading the RSMV1 conversion to RSMV2 thread, I had misunderstood, I thought it was only possible on the 32MB version of the V2, but after re-reading it's the 16MB, so one day when I finally get it all working (hopefully..) , I'll probably then risk it all by adding a serial hack if I can build one, and flash it up to a V2 bootloader & firmware.

Helibot
Helibot's picture

Hi Urgentmente,
Fantastic that you got the OS going. When it said nand1: "fsck.cramfs: file length too short", I thought that it could be a size thing due to RSMV1 / V2 but very early on you said it has a progress bar on boot, which is definitely only a V2 feature. So if it had a progress bar before you reflashed it, this would suggest that someone else had tried flashing V2 firmware into it.
If you want to access the linux console (via USB or serial) then I highly recommend the V2 version as it then lets you telnet into RSMedia with multiple sessions. (Using a single serial console is tricky cos it does not support ^Z or ^C so you often lock yourself out of the console!!(and need a reboot).
Anyway todo the V1 to V2 upgrade you will need the Serial Hack done, so if you are pulling him apart , you may like to put some wires/cable in to connect the serial port. (The pads are quite big so the soldering ios not too hard!!)
(If you just solder some ribbon cable on now then you can come back and complete the serial hack later. Also you can put him back together with the 'neck plate' left out - this allows you easy access to the top of the media board.)

I am pretty sure he does twist todo a 'left wave' so you may have a problem with one of the body motors :-(. But he may also move his head so maybe its just the neck motor problem again....

You said "So all in all, a major step forward so far"..... but what you really need is for him to make some real steps forward ...Ha ha.

Good luck with the diassembly on the weekend!!
Cheers
Helibot

Urgentemente
Urgentemente's picture

 

Helibot said: Hi Urgentmente, Fantastic that you got the OS going. When it said nand1: "fsck.cramfs: file length too short", I thought that it could be a size thing due to RSMV1 / V2 but very early on you said it has a progress bar on boot, which is definitely only a V2 feature. So if it had a progress bar before you reflashed it, this would suggest that someone else had tried flashing V2 firmware into it. If you want to access the linux console (via USB or serial) then I highly recommend the V2 version as it then lets you telnet into RSMedia with multiple sessions. (Using a single serial console is tricky cos it does not support ^Z or ^C so you often lock yourself out of the console!!(and need a reboot). Anyway todo the V1 to V2 upgrade you will need the Serial Hack done, so if you are pulling him apart , you may like to put some wires/cable in to connect the serial port. (The pads are quite big so the soldering ios not too hard!!) (If you just solder some ribbon cable on now then you can come back and complete the serial hack later. Also you can put him back together with the 'neck plate' left out - this allows you easy access to the top of the media board.) I am pretty sure he does twist todo a 'left wave' so you may have a problem with one of the body motors :-(. But he may also move his head so maybe its just the neck motor problem again.... You said "So all in all, a major step forward so far"..... but what you really need is for him to make some real steps forward ...Ha ha. Good luck with the diassembly on the weekend!! Cheers Helibot

 

LOL, PMSL at the "steps forwards" ,hehehe

RE the V1/V2 question, I honestly can't tell. When I received it, all it did was white screen,then power down,which I assumed was due to it being wiped (also mentioned in the ebay listing). I'd tried the reload for V2 files (not knowing any differences at  the time), with no luck, then tried moving the head manually after the advice here,and when it sprung into life, still had the SD card in with V2 files on, so it *might* have been then that it got messed up, or it could already have been that way,we'll never know  :)  It did definately have the progress bar on boot tho, noticeable absent since reflashing to V1 this evening. One minor thing, I used a different SD card tonight, finally found where it was hiding (it's years old..), as I wondered initially if maybe the SD card was suspect also.

When I get it opened up I'll still check the board versions etc, and if it is indeed V1 hardware I'll definately want to be adding the serial hack, so thanks for the suggestion of adding the wires for now. I need to go and read up on the serial hack to see what I need.

Most definately got problems with either the gearbox and or one or more motors, most movements right now cause a shutdown/reboot.

What works:

turn head left (looking from back of robot), no sound of straining motors

turn body left after head has turned to max left, no sound of straining motors

move either arm in arm mode, seems nice and fluid, no sound of straining motors

Can lean the body forward or backward to an extent, tho there does sound like theres a lot of motor movement *before* the body moves (and I'm talking a second or so before the body moves).

Anything else right now, and it's lights out, goodnight Robo..

Vader
Vader's picture

Ahh, I see what's been happening with the OS now. The first time you got it to boot it would've flashed on the V2 firmware from the rsupdateapp, which of course doesn't fit on the smaller V1 system partition.

The memory shown at the start of dmesg output is 16MB..
"Memory: 16MB = 16MB total" - isn't the RSMV1 16MB, and the RSMV2 32MB?

Some of the early "V2" models were actually just V1s with the different bootloader and partition sizes and the PPP enabled kernel flashed onto them. This is why it's possible to upgrade the V1 bots to V2 firmware.

Helibot
Helibot's picture

Hi Urgentemente,
Yes I agree with Vader, its likely that your first successful boot lying down flashed the V2 system image into the V1 sized partition and it didn't fit. So files at the end of the partition were simply not there!!
When I have some time I will go over the V1-V2 upgrade script and check if the logic to check for V1 works correctly, as it didnt seem to for you :-( (although I dont have a V1 anymore...so if I make any changes , can I ask you to test them??)

Vader,I think that all V2 models are the same. They all have 32Meg of RAM and different partition size than V1s. The V1-V2 upgrade process recreates the partitions to the correct size, so then V2 software can run on a V1. But I think it still has less RAM, but this doesnt seem to cause a problem ;-)

Regarding your hardware problems, the motor drive circuits are setup to use two transistors to drive the motor backwards and another two transistors to drive the motor forward. So if the robot has a bad experience (like slipping or breaking a cog) then its possible for one set of transistors to get damaged when driving but others are OK. So RSM can move a limb OK in one direction but cause reset in the another direction! (I had a neck problem where this occurred.)

Some delay in the body moving fwd/backward is normal I think (but a second maybe too long??.) There is some slack in the linkages and a spring involved, so you maybe able to adjust this.

Urgentemente
Urgentemente's picture

Morning guys, Helibot, I looked at that/your update script myself and it all looked perfectly logical to me. . (not that I'm any expert in programming, most of the stuff I do is just the odd small project at work,most recently in php, but I can still remember the basics from when I was a kid learning on a ZX81 ,LOL)

The dmesg output on my bot definately doesn't have the "1184 direct map" line in it,

...but I think I've found the problem..

I made a copy of the rsupdate script on my linux box and removed the steps above the grep test, replaced the various check & write commands with echos just to simulate the actions.. but I was getting an error saying "./rsupdateapp.test: line 3: [1: command not found" , which is the line for the dmesg grep "if" test.

I Couldn't see why it wasn't working, when other examples I tried worked fine (I did another simple script just doing a grep on my box's dmesg for a known term, with a "sucess" echo, or a "failed" if the string wasn't found, and it was working OK.)

Looking at the rest of your rsupdate script, there is a very small,very subtle difference between the IF test line that's failing, and the others in the script..and it seems to be changing the way the shell interprets the line..

Look at the first instance of "if [$? = 0 ]" compared to the others.....

(I tried posting the output from grep "$?" rsupdateapp but it didn't post right in the forum..)

The first test has no space between the [ and $? , and it seems that the shell is looking for a command (called "1" in this case as the error status from dmesg|grep  would be 1 when failing to find the string" instead of treating it as a test.

Not too hard to debug given bit of time and the error output on a console, NOT so easy when you can't see what the console on the bot is doing!!

Helibot
Helibot's picture

Hi Urgentemente,
Well spotted, the missing space will be the culprit!! But I also noticed that I was only using the "dmesg | grep "1184 KB direct map" for the part that updates the kernel (in Nand0). So the script will still flash the nand1 with teh V2 files. So even with the extra space it will still have caused your problem!! I think it would be best to rework the script to detect the V1 right at the start and abort all the updates!!. I will add it to my todo list.!

I agree that debuging the stuff without console is VERY time consuming - hence why serial hack and USBConsole are very very useful!!

On a slightly related note - has anyone used ZED editor on linux? I have just found a copy that should run on RSMedia. I have been looking for a replacement for 'vi' for editing files on RSMedia (via serial, usb console or telnet). I really (really really) dont like vi....and it doesnt work well on the basic serial console in RSMedia. So wondering if ZED is any good? Will try it soon and see fo myself.

Cheers
Helibot

Urgentemente
Urgentemente's picture

Helibot said: Hi Urgentemente, Well spotted, the missing space will be the culprit!! But I also noticed that I was only using the "dmesg | grep "1184 KB direct map" for the part that updates the kernel (in Nand0). So the script will still flash the nand1 with teh V2 files. So even with the extra space it will still have caused your problem!! I think it would be best to rework the script to detect the V1 right at the start and abort all the updates!!. I will add it to my todo list.! I agree that debuging the stuff without console is VERY time consuming - hence why serial hack and USBConsole are very very useful!! On a slightly related note - has anyone used ZED editor on linux? I have just found a copy that should run on RSMedia. I have been looking for a replacement for 'vi' for editing files on RSMedia (via serial, usb console or telnet). I really (really really) dont like vi....and it doesnt work well on the basic serial console in RSMedia. So wondering if ZED is any good? Will try it soon and see fo myself. Cheers Helibot

Ah , yes, didn't spot that, got too focussed on that specific part of loop !

I could take a look at altering the script if you like, as it should only be a case of adding/moving an If-loop or two, save you a job (well, aside from checking it afterwards!).

I've written a couple of search pages in php recently at work that have a few nested condition loops in the code, and whilst they don't look pretty now it's all finished, it works :)

I think I must have some wires crossed in my own brain as I quite 'enjoy' working out code, especially when I write something that doesn't do as I expect the first time. Tho there may be a few choice swearwords used in the debugging process..!

Never heard of ZED editor to be honest, I just did a quick "yum list '*zed*'" b, but no matches in the Fedora repositories.

Helibot
Helibot's picture

Hello Urgentemente,
Would love it if you had a go at the script. You are right it should just be moving form loops around.
Actually I thought I would have a go at a harder script :- it should be possible to write a script that will check most partitions and say of they are programmed with V1 or V2 or unknown code. I should be able to use the MD5 checksums to verify each. It would be a useful script for people who have just brought RSMedas and want to know if they are V1 or V2 and if the partitions are correctly flashed.

I tried ZED, it works oOK on RSMedia and it looks quite nice, has menus or ctrl sequences todo most things , so I think it may work quite well - will try it some more now.

>I think I must have some wires crossed in my own brain as I quite 'enjoy'
>working out code, especially when I write something that doesn't do as I
>expect the first time.
I think I have the same wiring fault :-) - I have had a ball reverse engineering how RSMedias scripts and code works over the last few years. When you get something working it feels like much more of an acheivement when you have worked it out from scratch!!

Cheers
Helibot

Helibot
Helibot's picture

Hi All,
I created a new rsupdateapp script that works out if RSMV1 or RSMV2 versions are flashed to the kernal (nand0), root (nand1)and default (nand2) areas of an RSM. Also tells if the kernel partition is RSMV1 or RSMV2 size.
I have tested it on my RSMV2 , but would like someone with a RSMV1 to try it before I upload it to robocommunity. Can anyone with a V1 try it for me? (Send me a PM with your email and I will email the files and instructions to you.

Urgentemente , I guess you may have already have yours in bits?? Hope its going well!!
Also Sorry to hikack your thread - I will start a new thread once its been checked on a RSMV1.

Cheers
Helibot

Urgentemente
Urgentemente's picture

Hi Helibot,
no, I haven't started dismantling today, it's been too nice a day here, been relaxing outside in the sun then watching the Grand National.

I'll PM you my email and I'll try the files for you if you like

Pages