Beta firmwares available (0.5.2.1) - Beta testers needed!

[mad_ady]

If you have the time you can manually start to enable options until you get a setup that boots the root.bin. I plan on doing this (I'm working remotely from work, over serial), but it might take a few days...

I made a diff between a config that works (root.bin boots) and the reset config, and IMHO, these are some of the settings that might make a difference (set to the values from the working config):
We should try to add them one by one and see which config triggers dmaosd not to crash:

Code: Select all

AAC_PASS_THROUGH=''
AC3_PASS_THROUGH=''
ADDITIONAL_ENCODING='ISO-8859-2'
AUDIO_OUT='0'
AUTO_AUDIO_OUT=''
CODEPAGE='cp437'
CONFIG_TV_SCAN='0'
CONFIG_TV_TRICK='0'
DDPLUS_PASS_THROUGH=''
DMA_CONTENT_AGGREGATION='0'
DMA_ENABLE_AUTO_STANDBY=''
DMA_MOVIE_BROWSEMODE='0'
DMA_MUSIC_BROWSEMODE='0'
DMA_PHOTO_BROWSEMODE='0'
DMA_SCREENSAVER='20'
DTS_PASS_THROUGH=''
ENABLE_AUTO_LOGIN='1'
FORCEHDMI='OFF'
IOCHARSET='utf8'
LIVE365_SWITCHER='shoutcast'
MSHEETMODE='wall'
PRESET_NAME_0=''
PRESET_NAME_1=''
PRESET_NAME_2=''
PRESET_NAME_3=''
PRESET_NAME_4=''
PRESET_NAME_5=''
PRESET_NAME_6=''
PRESET_NAME_7=''
PRESET_NAME_8=''
PRESET_NAME_9=''
SECURESOHO_CURRENT_SERVER_TYPE='20480'
SMBD_AUTO='OFF'
SMB_STANDBY='OFF'
SUPPORT_SCART=''
TV_COLOR_SPACE=''
VIDEO_OUT_RESOLUTION='480i60'
WMAPRO_PASS_THROUGH=''
YOTA_TYPE=''


As you can see, there are a lot of things to try out... I will scratch my head for a while and see if I can come up with a fast way of isolating the fault (probably I will use the divide and conquer approach...). I will let you know how it works.

[mad_ady]

I went with the lazy approach and made a script to test all the options. It's currently running, but so far the OSD booted correctly with this setting:

Code: Select all

CODEPAGE='cp437'


Can anybody set that and try to boot the root.bin? Either with your stock config, or with a reset config and with that option set? @kroetkroet: what CODEPAGE do you have set on your box?

Thanks.

Tests so far:

Code: Select all

***************FAILURE**********************
******************Going to test with AAC_PASS_THROUGH=''
******************
***************FAILURE**********************
******************Going to test with AC3_PASS_THROUGH=''
******************
***************FAILURE**********************
******************Going to test with ADDITIONAL_ENCODING='ISO-8859-2'
******************
***************FAILURE**********************
******************Going to test with AUDIO_OUT='0'
******************
***************FAILURE**********************
******************Going to test with AUTO_AUDIO_OUT=''
******************
***************FAILURE**********************
******************Going to test with CODEPAGE='cp437'
******************
***************SUCCESS**********************
******************Going to test with CONFIG_TV_SCAN='0'
******************
# ***************FAILURE**********************
******************Going to test with CONFIG_TV_TRICK='0'
******************


Here's what the setting does: http://en.wikipedia.org/wiki/Code_page_437

Edit2: According to the webend, you can select any of these codepage values: 'cp1250','cp1251','cp1255','cp437','cp737','cp775','cp850','cp852','cp855','cp857','cp860','cp861','cp862','cp863','cp864','cp865','cp866','cp869','cp874','cp932','cp936','cp949','cp950'
with "" (blank) being system default. Well, it seems the unit doesn't start with codepage=""... Anybody have time to test the others, or should I adapt my script?
Edit3: It seems setting DMA_PHOTO_BROWSEMODE='0' also causes the OSD to boot...

[mad_ady]

Ok, my automated tests have finished. I have the following values that if are set will cause DMAOSD to start correctly (I tested them independently of each other):

Code: Select all

CODEPAGE='cp437'
DMA_PHOTO_BROWSEMODE='0'
TV_COLOR_SPACE=''
VIDEO_OUT_RESOLUTION='480i60'


The values in the reset-config version are these:

Code: Select all

CODEPAGE=''
DMA_PHOTO_BROWSEMODE='1'
TV_COLOR_SPACE  -- is missing
VIDEO_OUT_RESOLUTION='480i'


I'm not sure what all of them do, but I will change the firmware defaults so that when you do a reset to factory defaults some sensible values get set.
Also, because of this problem and some more issues I want to fix I decided to postpone a bit the launch of 0.5.2.1. Before the next beta session (I guess I will bump the version number too), I want to add the following:

Code: Select all

* Add sensible defaults for config to allow DMAOSD to startup
* init - make all /conf/Sxx scripts executable before executing them (sometimes the executable bit doesn't stick)
* fix/investigate broken WDTVEXT Reboot command on OSD
* rtorrent - update to at least version 0.8.9 to support no ssl cert validation
* maybe add a webend redesign mod


In the mean time you can keep testing the other changes and report back.
Thanks

Edit2: Wait... I retested with CODEPAGE='cp437' and DMAOSD promptly crashed... I don't know what's going on here...

[mad_ady]

Ok, I put the firmware through a lot of stress-testing last night - I left the config unchanged (with CODEPAGE='cp437') and kept rebooting the box and checking if DMAOSD was up and running after 2 minutes. I ran 231 tests (reboots) and I had:
* 195 failures to start dmaosd
* 36 successes (dmaosd started with that config)

So, about 15% chances of DMAOSD starting correctly.

All the crash messages look the same - they all die at the same address and with the same register setup. Also, what's interesting is that the fault address is always in register t9:

Code: Select all

t9:     2c3b3c4000000000


From what I've seen in mips dissasembly, register t9 is usually used as a buffer to load the address of a function to call (just before doing a jalr $t9). Searching the hex code for that value yields nothing, so it must be a dynamic address (like I've seen all through dmaosd's code).

I will try to do the same test on 0.5.2.0 and see if the problem is not there, I will have to look into the wdtvext code I merged. It's strange that I never seen this problem before the attempted release.
Edit2: I've reflashed 0.5.2.0 and all 8 consecutive reboots had DMAOSD functioning correctly, so the issue must be related to some wdtvext commit... I'll put my digging hat on...

[kroetkroet]

Mad_ady, sorry for being idle, got struck by virii again.

My codepage & DMA photo browsing are:

Code: Select all

config:CODEPAGE='cp1250'
config:DMA_PHOTO_BROWSEMODE='1'


Hope to be able to test your root.bin soon!

[mad_ady]

I managed to find part of the problem. It seems that if the config is reset there is no default WDTVEXT variable and the box boots with WDTVEXT=ON if it can't find the variable. I'm working on a patch to fix this. However, this only solves part of the problem. It means that you can boot and use the box without issues as long as you don't enable WDTVEXT. If I enabled WDTVEXT with the default config I got the same crash.

I left the unit to do some stress testing last night, but alas, it seems to have crashed worse because I can't access it over serial (I need to physically reboot it), so I will test it later. I'll do more tests with my complete config and then try to remove items (I have about 400 config items) and do repeted tests to see if there is one config item that causes this commotion... It will take a while. In the meantime I'll work on adding the extra features we've discussed...

Sorry to hear about your viral state, kroetkroet. Hope you get well soon...

[kroetkroet]

Thx mad_ady, so if I understand you correctly: if I turn on WDTVExt, my unit will crash too? What to do to get out of it? Reset factory?

Don't want to get in too deep trouble

[mad_ady]

That's the strange bit. For me wdtvext=on never crashes on boot (may crash after a few minutes or hours). But if you go to default config it will crash most of the time on boot (I have now a 8-15% chance of correct startup). If wdtvext does not appear in your config it behaves like wdtvext=on.

If you find yourself in trouble you will need to explicittly turn wdtvext off. Here's how:
* boot an older firmware and set it via config
* boot with a usb drive attached with a file called S00custom-options with this content:

Code: Select all

#!/bin/sh
config_tool -c WDTVEXT=OFF
config_tool -s
config_tool -s


But it's best to have a backup config anyway.

I'm going to run some stability tests tonight with my regular config and wdtvext=on, and write a script to start checking with all the config settings to see which ones cause the unit to boot consistently. It will be a long experiment

Also I merged a newer rtorrent version today, but I will release a new beta when I can better understand the issue.

@kroetkroet: if the unit boots for you consistently with wdtvext=on can you pm me your /conf/config? I'd like to see what we have in common...

[kroetkroet]

Thanks for the fall-back plan, I thought it would be through S00customs, but was not sure.

I'll test the WDTVExt=on for you first thing tomorrow. Keep you posted!
KK

[distrata]

I managed to boot the 1.05 ext firmware to my box by setting the wdtvext value off on my flashed firmware. seems to work fine for now. What do you propose as a stress test?