Right now, this is just a suspicion on my behalf based on some preliminary poking around in the 1.04.10_V and 1.04.10_B firmware (the binary package, not the GPL’d source) over the past couple of days as well as observations made regarding comments concerning this firmware on the forums. Please do not take any of this as anything other than supposition for now; hopefully, in the next few days I’ll be able to come up with something more concrete, but that’s going to be heavily-dependent on my availability to continue looking into it.
Something that piqued my interest with this firmware release was the disparity in the number of issues people were having with it based on the device they were running - there seems to be a much lower instance of reported problems on the Plus vs. the ‘regular’ TV Live. Arguably, there are outside factors that could be influencing this: the Plus has been on the market for a shorter period than the Live, so fewer units are in the wild, etc. However, I’m not convinced that this is necessarily a factor.
From the small amount of effort I’ve put into this so far, it appears as though WD may be using a common build system for both firmwares. This makes sense; we know that this release was a merge of the two codebases into one common one. It also means that there’s a strong chance they’re using a common compiler, libraries, etc. for both hardware platforms, which also makes sense. However, I suspect that this may be causing issues on the Live that aren’t happening on the Plus.
So, with that out of the way, I could use help with the following:
If you have high-resolution photos of the mainboards of the Live or Plus (good enough detail to show part numbers on individual components down to an IC level), I need them. The ones I’ve found floating around online don’t go into quite the depth necessary to figure out if there’s a potential hardware support issue.
If you understand the format of the filesystem within wdtvlive.bin / wdtvlive2.bin, please clue me in. I can get both of them mounted without issue, but get I/O errors on trying to access certain files via standard system tools such as ls and cat. My unfamiliarity with romfs/cramfs filesystems isn’t helping here, and taking semieducated shots in the dark at it isn’t really getting anywhere. FWIW, they’re being mounted with mount -t auto -o loop,offset=32; using dd with a blocksize of 32 and skip of 1 and mounting the resulting image produces the same results.
Like I said, this is all suspicion - until I can get further with the two items above, there’s no very good way to treat it as anything else. But I would certainly appreciate any help anyone may be able to give.
From what I have been reading on this board, I think that there are just as many problems with the Plus. Most, if not all of the problems are there for both models. I think that there are far more users of the older products, and they have been on this board longer…so it makes it seem as if the Plus has fewer problems. I have a Plus, and believe me, after the latest firware update, it had many problems. I had to downgrade to 1.03.49.
That’s not the right way to unpack WD’s romfs image. Everything you need to know can be found at the b-rad.cc website. I encourage you to look there, too.
That’s not the right way to unpack WD’s romfs image. Everything you need to know can be found at the b-rad.cc website. I encourage you to look there, too.
There is no ‘unpacking’ of the wdtvlive.bin image that I’m aware of; it’s a loopbacked cramfs filesystem. Either of the ways that I described to mount it are the prescribed methods.
Secondly, it’s understood that the filesystem internal to it is read-only due to being treated as NAND flash. That’s fine; I’m only trying to read from it anyway. But I’m getting I/O errors on read. This is where I’m stuck, and from going through b-rad’s site (amongst other Google results) there was no clear answer to the specific question I was asking.
All I can say is that I’ve done it successfully quite a few times. … at least I haven’t run into the Filesystem errors since I started using the method I pointed you to.
BTW, the NAND Flash image is mounted in RAM, so it IS R/W, but the changes are NOT saved to FLASH.
Several files are dynamically created. You’ll note that the SAMBA config file “smb.conf” is not in the file set, yet it exists on a running box. It’s created in RAM and is stored in /etc along with the other files you see.
Give me an example of a filename you’re getting an error on and I’ll double check…
All I can say is that I’ve done it successfully quite a few times. … at least I haven’t run into the Filesystem errors since I started using the method I pointed you to.
*> Please clarify what you mean by ‘the method’ - I’d like to make sure we’re both referring to exactly the same thing, but it’s hard to know which part of the five Google results that that link gave that you’re specifically referring to.
Several files are dynamically created. You’ll note that the SAMBA config file “smb.conf” is not in the file set, yet it exists on a running box. It’s created in RAM and is stored in /etc along with the other files you see.
*> That’s fine; I’m only interested in binaries for right now and would expect that they are not created dynamically
Give me an example of a filename you’re getting an error on and I’ll double check…
Results are the same for this regardless of which method I use to mount the .bin file. Examples below are for the ‘V’ firmware, but apply equally to the ‘B’ firmware.
mount -t auto -o loop,offset=32 /path/to/wdtvlive.bin /mnt/wdtvlive_v
Or:
dd if=wdtvlive.bin of=wdtvlive.romfs bs=32 skip=1 && mount -t auto -o loop wdtvlive.romfs /mnt/wdtvlive_v
Take a look at:
/bin/busybox
/bin/smbpasswd
/bin/xlu_load_t3_noios.sh
/sbin/xfs_repair
/sbin/mkfs.xfs
/sbin/dhcpcd
/usr/bin/iwconfig
/usr/bin/iwlist
/usr/bin/wol
/usr/sbin/nmbd
/usr/sbin/rtc
/usr/sbin/smbd
That’s in the 1.04.10_V firmware, but the results are the same in 1.04.10_B - except for the examples given from /usr/sbin, which can be read in the ‘B’ firmware. No idea why that’s the case; stat and other tools report everything as looking perfectly normal.
Just to clarify: the problem seems to be with anything that opens the file directly for reading. You’ll be able to get a directory listing no problem, but if you try to open an individual file (with, say, cat, strings, or ldd), instant Input/Output error.
Oh!! Wait a sec. There’s another critical step; the EXPAND step.
Go find a package called “cramfs-1.1-16k.tgz”
That will do it. The WD cramfs is in 16k chunks, which that package will handle,
That package will open and EXPAND it into your own filessystem, as opposed to mounting it as a loopback device.
*Smacks forehead*
D’oh - makes perfect sense now. When I said I had little experience with cramfs, I meant it ;) Thanks for that; I’d somehow missed it in my digging into what was going on. I’ll install it when I’m back at the house.
FWIW, from the few binaries that I could look at in the ‘B’ firmware, it appears as though they’re statically-linked. Not a huge deal if that’s the case, but I’m mentioning it because that seems like an odd choice for a device with limited root filesystem space - you’d think dynamic libraries would make more sense, but there may be memory allocation juju going on in the kernel I’m not yet aware of. It’s also possible that just those specific binaries are static, since there are libraries included - could be an, ‘in order to build properly, version x of this library is needed’ thing for those specific binaries.
