English is below

Hallo Leute !

Erinnert Ihr Euch an meinen grub für DM 7025 Frage thread ?

Na ja, ich habe immer noch nicht aufgegeben einen booloader für meherere Images zum auswählen währen dem booten zu machen
(und bis jetzt habe ich IMMER einen weg gefunden wenn ich etwas wirklich wollte). Und weils FEZ immer noch nicht gibt ist es noch auf meiner To-Do Liste.

Eine der Meditationen in meinem Urlaub war ja über USB boot support - na ja und jetzt geht es (mit ein bischen Hilfe ...)

Und der Stadnard bootloader is gar nicht so schlecht nur das menu interface in telnet wenn man den boot stopped (mit Up taste beim Einschalten) um zu flashen ist für normaluser nicht geeignet.

Andererseits kann erschon bis zu 3 Images booten, also warum nicht versuchen dieses feature zu verwenden - nur halt auf meine weise ?

Könnte mir daher jemand eine Hinweis geben wo er seine Konfig speichert ?

Wenn man diesen Bereich manipulieren könnte wäre es mit einem kleinen Programm (wenn gebootet oder halb gebootet) möglich Ihm zu sagen was und wo er booten soll (so wie multiboot es mahct wenn es autorun.bat ändert, nur eben 1 ebene weiter unten).

Wahrscheinlich ist es eh nur 1 block oder sector im flash (der letzte von /dev/mtdblock/1 ?) weil secondstage.gz füllt den nicht ganz, und wenn man es mit dd zero padded drüberkopiert hat man wieder die defaulteinstellungen selbst wenn man vorher andere gespeicher hat.

Also tipps, ideen und Vorschläge sind willkommen !

Gruss
thowi

Hello Folks !

Remember my grub for DM7025 - question ?

Well, I still have not given up to implement a bootloader for choosing multiple images during boot on the DM7025 (and so far I always found a way to do something if i really wanted to do it). And because FWZ is still not there it is still on my to-do list.

One of the meditations I had during my vacation was on the USB boot - and well we now have it don't we (with a little help ...)

And the standard bootloader isn't that bad either, only the menu interface working only in telnet if Stopped (with up button during turn on) is not acceptable for the normal user.

But it offers already the possibility to specify and boot up to 3 Images, so why not raping it to do this - only the thowi way

Could therefore somebody give me a hint where and how it actually stores its config when you do a save and reboot within the bootloader ?

By manipulating this flash section we could achieve what we want with a VERY small programm or from the booted or halfbooted box (like multiboot does by manipulating the autorun.bat, only 1 level deeper).

Probably it s only a single block or sector, but it must be reserved in /dev/mtdblock/1 as would be my assumption (last block ?) because secondstage.gz isn't filling it completely, and if I copy it with dd to the /dev/mtdblock zero padded it comes up with the default values, even when I saved others before.

So any hint or ideas are welcome !

Ciao
thowi

well you are thinking too complicated - I just want to save the 4 different configs (boot from flash, and alternate 1,2,3) with the standard bootloader as it offers already now and then just dump the saved konfigs. By writing it back (even without knowing/decrypting the content) I could then choose which bootpaths are taken and prevent the telnet session.

So there is not really a need to write access routines which do read/write and decryption (I would have assumed that bootloader config is protected, because if you screw it up you are in deep problems).

The whole thing would be easier if we could only extend the bootloader a little bit (probably half a page of code - so that it switches the alternate bootsource by pressing the up and down buttons - not as nice as doing it with remote controll, but sufficient, and perfect if LCD would show booting X...). It is a little bit like your request for extending it to USB support - would be great, but lots of effort, just use the kernel in Flash and ignore the root in flash and use the root on USB stick does the job too - I like workarounds you know

But if I'm able to manipulate the loader's config then I'm already pretty close, because if I switch it to load a dummy kernel (miniroot ?) which does then the manipulation I would get more or less the wanted result.

So thanks for your input, I'll do some medidation on it.

Ciao
thowi

PS: And that you get an idea what crazy approaches are possible, here are 2 more:

I just thought about a PC programm which allows you to script Terminal character sequenzes (such programms are alreay available) - whith this you would be able to make a PC Bootloader raping the standard one which just manipulates as you would do in Telnet already now, but this needs still pressing of the up button - hence not really usable for normal usage.

Or another one - why not specifing a device list in /autoexec.bat or autorun.bat and then patch the linux kernel that before it mounts the root filesystem so that it waits 30secs (like it does for USB with the rootdelay parameter). Finding the place where this USB boot rootdelay patch is built into the kernel would be relatively easy (should be in changelog), and exactly there you could add code to the kernel to choose an alternate root from the list ! Actually this one would be nice, because when having a full kernel running you have all the drivers needed for LCD, button events,... and then you simply continue boot as normal. I even already tried if an entry in autorun.bat like this works and the kernle still boots (with the first device of the list):

root=/dev/hdc2,/dev/hdc3,/dev/hdc4

And I have some more ideas on how to solve this problem, but I need an easy one (because I'm not willing to code something in the kernel - even when this would be c code which I could probably handle)

and one more thing I forgot to mention:

when I asked the grub question I also did an extensive search on bootloaders for mips plattforms and found this, which might also look promising:

CoLo Bootloader for mips - looks like it is a simple vmlinux.gz replacement, hence standard bootloader should be able to work with it.

http://www.linux-mips.org/wiki/CoLo

http://www.colonel-panic.org/cobalt-mips/

Unfortunately in German:

http://www.gentoo.org/doc/de/h…ml?full=1&style=printable

Setting up colo for NFS looks promising:

# tar -xzvf colo-1.XX.tar.gz
# cd colo-1.XX/binaries

(Für Qube 2800, RaQ2, etc)
# gzip -9vc colo-chain.elf > /nfsroot/vmlinux_raq-2800.gz

(Für RaQ1, Qube 2700)
# gzip -9vc colo-chain.elf > /nfsroot/vmlinux.gz
# cd /nfsroot
# ln . boot

And i liked the scripting capabilities for boot menus and chainloading from existing firmware feature ...

Ciao
thowi

Zitat

Original von murks
@thowl

as i can see, the colo is very cobalt specific.. hardware support is for example only for tulip based network devices, the same for filesystems, only ext2 is supported.

Yes I've seen this, but for an Image partition typically only 50-60MB big ext2 is not a real limitation or problem.

And off course it is Cobalt speficif, but on this old MIPS box they had to overcome exactly the same problems - limits of existing bootloader and no chance to get a better one !

Hence it had to be done in a way which would be also usable for the dreambox - fake vmlinux.gz which then daisy chaines to the real one.

And at least it supported a MIPS architecturye (meaning that the cross compiler would not run away screaming if we feed him the source code)

I would also need only a minimal build without any network drivers (which would be hardware specific), etc. so this should be calculatable effort. And the IDE driver (which would then support harddisk and CF card already) very likely to work without any real changes on a dreambox !

And I didn't say that it is the solution, I just wanted to point in directions which maybe were not investigated yet (and belive me, sometimes I have really strange ideas - I'm not sharing half of them, but as long as there are a few working ones who cares)

And a clever person once said 'there are no dumb ideas'

And the process to solve a problem is quite simple - try to find ALL possible/thinkable solutions and then eleminate the ones that are NOT working until you find one that IS working.

Sitting together and complaining that it doesn't work ist not part of this process (unless you wanna be sure to fail)

PS: Feedback is welcome, so don't think that I'm upset - and belive me most of my good ideas I stole from other people who didn't realize what nuggets they had in their hands.

Ciao
thowi

With Ticalians gcc environment I think I could successfulls re-compile the CoLo bootloader on a DM 7025 (at least I didn't get any errors when using the standard included Makefile - only change was to link gcc to cc so that the makefile is happy and finds the compiler) - wanna play with it ?

I also tested some of the standalone tools included, they are executable on the DM 7025 after recompile - so I think the whole bootloader should work too but off course output would go only to console terminal connected via nullmodem cable

But if somebody would port the lcd routines (putlcd programm ins included, but off course not working yet) then we would be on the right way ...

At the moment I put this vmlinux.gz on the FAT Partiton of the
CF card, and it seems to do at least soemthing, because the harddisk is searched (IO going on) for a bootable kernel if you start it without any *.colo file - because this probably will not work from FAT, because it is not a supported filesystem of CoLo Kernel, but the secondstage bootlaoder (knowing FAT) seems to be able to extract and execute the vmlinux.gz from the attachment (oroginal sources are also included if you want to compile yourself). So there is really a chance that the daisy chaining of bootloaders and kernel will work - amazing !

Off course there would be a lot of work needed to kick out or migrate all the device support the Dreambox doesn't even offer, and to really make it work with support of the Dreambox LCD and the frontline buttons, but if it will start to give out error messages this would be a starting point for a more gifted programmer. I would already be happy if I manage to show the boot menu items or enter it's CLI mode in my serial console, no matter how dirty it would be done.

Ciao
thowi

Just a small update on my bootloader search.

CoLo has to many limitations in the device support as my tests found out, hence I continued.

Currently I'm playing with syslinux, because it is designed for bootfloppies (being FAT 12/16 too).

This is used by lots of Linux distributions during installation on strange (PC) Hardware, so maybe this is also a good starting point for the Dreambox.

http://syslinux.zytor.com/download.php

I'll keep you updated, because at the moment this is just a low priority hobby, but if I'm lucky and find one it would be a great new toy.

Problem is that it is partly written in Perl, hence I have problems building a MIPS binariy - help is welcome !

Ciao
thowi