Enabling telnet on the Foxsat-HD

Hi Gary,
I've had some recent success with compiling a custom kernel for the Foxsat HDR, so I've since downloaded HD sources and compiled a new HD kernel for you with devpts support. You can download it from HERE. Let me know if it works.
regards
raydon
 
Hey, thanks!I'll try it out as soon as I can.

I just logged on to let anyone following this thread know that the tinyftp works fine. I had a look at the link about creating the device nodes manually. Perhaps I didn't read carelfully enough or far enough but it is mainly concerned with creating the devices with mknod; but the devices already exist in /dev. I'll read it again sometime when there are fewer distractions.
 
Of course I couldn't resist trying it out immediately! It works perfectly! Thanks a lot, I wouldn't have been able to compile the kernel myself.
Do you know how I can see how much space the firmware is occupying, and how much is available? I guess this will very quickly become and issue. What I am thinking of doing is adding a script to the firmware that invokes a init.d-like construction on the USB stick. That should allow me to try out stuff without having to update the firmware each time.
 
cat /proc/mtd

or something like the following will give you output like at http://wiki.hummy.tv/wiki/Internal_Flash_Layout

assuming awk is available somewhere.

Code:
cat /proc/mtd | /mod/bin/busybox/awk '
        BEGIN {
                printf("  %-18s    %s + %s\n", "Name", "Address", "Size")
        }
        /^mtd/ {
                part = substr($1, 4, 1)
                size = sprintf("0x%s", $2);
                split($0, a, "\"")
                name = a[2]
 
                if (name ~ /physmap/) addr = 0
 
                if (!addr)
                        paddr = "0x00000000"
                else
                        paddr = sprintf("0x%08x", addr);
                psize = sprintf("%.1f MiB", size / (1024 * 1024))
                printf("%d: %-18s %s + 0x%08x (%s)\n", \
                    part, name, paddr, size, psize)
                addr += size
        }
'
 
Thanks af123.
For those who are interested:
Code:
FOXSAT-HD Internal Flash Layout
  Name                  Address + Size
0: cfe                0x00000000 + 0x00100000 (1.0 MiB)
1: vmlinux            0x00100000 + 0x00200000 (2.0 MiB)
2: rootfs             0x00300000 + 0x00100000 (1.0 MiB)
3: lib                0x00400000 + 0x00200000 (2.0 MiB)
4: settop             0x00600000 + 0x00600000 (6.0 MiB)
5: image              0x00c00000 + 0x00200000 (2.0 MiB)
6: channel            0x00e00000 + 0x00100000 (1.0 MiB)
7: flashfs            0x00f00000 + 0x00100000 (1.0 MiB)
8: phys_mapped_flash  0x01000000 + 0x01000000 (16.0 MiB)
 
Happy to see that you've finally got root access to the box. Exact same layout as the HDR.
The rootfs flash block is pretty full, but you can put apps in the settop block which gets mounted as /usr/bin and is included in the $PATH environment. The squashed settop app uses less than 3MB of the available 6. Have fun ! :)
 
The freeview boxes have 32MiB, so a bit more space to play around, but there's plenty that can be done in the 16.
 
I'm back again, with another problem although I think this is more of a (busybox) linux problem.

The HD does not have/use a /opt directory. What I want to do is to maximise the reuse of any packages already available for the HDR (at least those that make sense; perhaps the channel editor and maybe the web interface). To this end I created the /opt directory in the firmware and I mount the USB stick/drive as /opt. I then have a structure similar to the HDR and can hopefully reuse the HDR packages which make use for /opt/bin and so on.

For now, I manually mount /opt and append /opt/bin to the PATH after the box has booted
The first package I uploaded was opkg-tools. Of course I manually unpacked this and placed the scripts and executable in /opt/bin.
I then uploaded the webif and tried to unpack it with opkg-unpack.

Code:
( with current work dir as /opt and the webif package ìn /opt)
 
# ./bin/opkg-unpack webif_2.71_mips.opk
 
This fails with:
/bin/sh: ./bin/opkg-unpack: not found
#
Obviously I have tried many variants of this, but all give the same result. The error is confusing because I am sure it does find opkg-unpack; auto completion on the command line works. Commands such as ls and mount work. Googling, many people hacking their smart phones seem to have this problem. It appears to be something to do with programs not being able to locate dynamic libraries and the only 'solution' I have seen is to (re)compile everything with static libraries. This goes against my goal to reuse ready to use HDR packages. Could there be another explanation?
 
I suspect the file (which is a shell script) has ended up with DOS/Windows line endings instead of UNIX ones. The system is unable to invoke the interpreter called '/bin/sh^M' hence the message.
 
Yes, I had considered that because I had problems when I uploaded another script I wrote on a windows machine. I now work exclusively in my ubuntu VM to eliminate the risk. The script to unpack packages comes straight out of the opkg-tools package so I assume that shouldnt have any ^M 's lurking in the files.
 
Make sure owner and permissions are correct.
chown root:root /opt/bin/opkg-unpack
chmod 755 /opt/bin/opkg-unpack
 
Have you tried running hexdump or similar to make absolutely sure there are no '\r' line endings lurking in there?
 
@xyz321 This may be something. I can see \r\n combinations in the unpack script. Odd, as far as I know this hasn't been anywhere near windows. I'll look at this more carefully this evening.
@raydon Yes, I do that always (I actually set it to 777)
@af123 Thanks for putting the flash layout on the wiki, that's where it belongs. I haven't got round to asking Ezra for access yet.
 
btw, opkg-unpack is a way of unpacking the packages themselves on the box for inspection of modification but they are installed using the opkg binary which you'll find in the HDR firmware.
 
ftp binary mode.
I was sitting on a train and the penny dropped. I checked as soon as I got home. ftp was defaulting to ascii mode and was transforming the \n\n to \r\n as it uploaded the files. I should have spotted that one myself. Its amazing how much you forget if you dont use it for several years (I'm getting old).
The scripts use 'basename' which hasn't been linked in the HD, but that should be easy to sort.
 
Back
Top