Beiträge von noggie

  • Experimental: NFI2CF

    Your change to ripimage.py looks valid.


    About running buildimage: please remember that this package is over two years old, before the dm800 was introduced. Your best bet is probably to find the current sources for buildimage, and use those instead.

  • 2nd stage loader

    The decision to take a soldering iron to your dreambox or not, is not something I want to have an opinion on. It's not something I've done myself, so I have no advice to offer.

  • 2nd stage loader

    1st stage loader in eprom, 2nd stage in flash. You won't need to write the 2nd stage loader to a new flash. (Unless you really want to, of course. :smiling_face: Flashing is only dependant on 1st stage.

  • boot sequence

    Last thing first:

    Code
    ps ax

    on the dreambox will show that init is running at runlevel 3 (that's what the final 3 in square brackets means).


    Boot sequence: (please take this with a small pinch of salt. I've haven't tried any of this for a long time, and I can't be bothered to check the facts. Sorry...)


    1. The box executes a primary boot loader stored in a ROM in the box. This ROM is not re-programmable, so it is safe from user errors.
    2. Some kind of non-volatile read/write memory is used by the primary boot loader to keep the "environment", like where to boot from etc. Normal boot sequence is to load the secondary boot loader from the first few blocks on the flash (this is a separate partition).
    3. The secondary boot loader will first check if there is a FAT-formatted partition on CF containing the file "autoexec.bat". If so, this partition will be used to boot. If not present, the secondary boot loader opens the second partition on flash (jffs2 formatted) and finds the file "autorun.bat". First line is the name of the boot logo, second line is the name of the (compressed) kernel.
    4. The bat file may contain (at least on CF, not sure on flash) kernel boot parameters. "console=ttyS0,115200" is probably the one you want.
    5. The kernel gets uncompressed, starts up, etc. etc.


    The secondary boot loader will stop if the front-panel "up" key is pressed when it starts. It will then accept a web connection to flash the box, but it will also accept a telnet connection (ANSI escape sequences) to change the environment. Be careful! I don't know any way to fix a seriously f*cked up environment, so it's probably best to leave it alone.


    The boot partition is normally mounted read-only. If you want to take the risk it can be re-mounted read-write

    Code
    mount -o rw,remount /boot


    And yeah, you should probably confine your experiments to a CF. Then you just need to unplug it if you do something wrong.

  • SquashFS

    It's 3.2 with some additional lzma patches.


    The simplest way to get it (or at least the simplest way to explain how to get it) is to install OpenEmbedded. Then you will have everything you need to compile it for the 7025, or even for your Linux box if you so wish.

  • gst-plugins-ugly problem

    Checked my own build log:

    Code
    configure: *** checking feature: lame mp3 encoder library ***
configure: *** for plug-ins: lame ***
checking for lame_init in -lmp3lame... no
configure: *** These plugins will not be built: lame

    Seems like a build badness that you run into because you have also built mp3lame at some stage. The rest of us haven't, so we don't see it...

  • General Info required please


    Main internal storage is a flash. A small part of this contains the main bootloader, which is loaded by a tiny on-board PROM. The main part of the flash is the image. The flash is partitioned, one partition contains the kernel, one partition (read-only) contains the main part of the image and one partition is read-write for config files etc.


    When flashing a new image, the small linux-partition and the large main partition is overwritten by the image.


    The read-write partition can be cleared anytime by a special button sequence when powering up the box. A new pristine copy of the needed files will be made when the partition has been cleared.


    Zitat


    Is Enigma1 a 'permanently' running auto-started application running on top of Linux ? ( I would like to be able to kill and restart Enigma as mentioned elsewhere)


    Correct.

    Zitat


    What is considered the easiest/cheapest/most reliable way of getting access to the Linux command line ?


    Set up networking and run telnet. Username "root", password "dreambox", until you change it.

    Zitat


    I presume the IR keyboard will only interact with Enigma ?


    Correct.

    Zitat


    I intend connecting the box to my home network and presume that some kind of terminal emulation from either of my Windows/Linux PC's will get me in ?


    I can't remember if anything extra is required TE wise Linux to Linux ?


    On Linux, just use telnet. I've heard that "putty" or something similar is a good choice on windoze, but you should really ask someone else about that.

    Zitat


    I presume, perhaps incorrectly, that the OS size restrictions preclude the use of X windows ?


    Almost correct. Linux as such doesn't impose any limits. You can get around the flash limitation (e.g. store the programs on disk) but the limited RAM makes X unpractical.

  • do_rootfs: failed

    Copied my build directory to an ext3 partition, and it now builds without any problems. Same machine, same software, only changed from reiser to ext3.


    Thanks a lot for coming up with the right idea!

  • Bug in 7025 IDE driver?

    I also think it's an issue with my CFs, or as you say a combination with my disk. Since my disk is quit enough to run the root file system, I haven't done anything more with it.


    In case my disk model should be an issue, here's what the system reports:


    Code
    root@dm7025:~# cat /proc/ide/hda/model
SAMSUNG HM160JC


    One more thought: I had one of those bad power supplies, and that caused all sorts of really weird problems. Could this be one of them?

  • Second stage loader

    Zitat

    Originally posted by gutemine


    I think your input would be VERY valuable if and how this should be implemented.


    Not too sure about that, I'm afraid. I'm still using a combination of my own scripts and manual installation, which is good enough for my needs. Mostly because I don't really "multiboot", I do "alternative boot" so that I can install a new image before getting rid of my old one.


    To tempt me away from my current setup, I would need features similar to "grub", but it's just too much work (for me, at least) to start a project like that from scratch.