grub for DM 7025 ??

    Hello Folks !


    Now that multiboot Version 4 is more or less finished (just minor bugfixes left) I start thinking if I couldn't implement also a SIMPLE bootloader.


    When I started developing multiboot I decided to implement it the standard way using Partitions for the various images (instead of subdirectories as Flashwizzard does), which would mean that it should be also possible to use a standard Unix bootloader like grub for choosing the Partitions.


    Could somebody compile grub for me, then I'm willing to find out if it is usable for multibooting the DM 7025 :winking_face:


    Why grub - well it is relatively simply to config and handle, doesn't need any fancy graphics output and maybe does the job only with very small or no changes.


    This simplicity of grub would enable to avoid the problem with the TV screen output, because we could switch the output to the lcd display
    just showing the partitonnumber and text in its config file that is choosen.


    When compiling it as it is I assume the output of grub would go to the serial console (I have a Null modem cable for displaying it), which would be also OK at the moment to find out in a PoC if it is usable.


    Even when the terminal output on the lcd or the console would not work just pressing the remote x times or the keyboard of the serial console at the beginning for choosing the image Partition would be enough because grub should work even without any output :winking_face:


    So is somebody willing to help me on this subject - input, feedback, critics and a compiled grub binary is welcome !


    regards
    thowi

    4 Mal editiert, zuletzt von thowi ()

    Zitat


    Even when the terminal output on the lcd or the console would not work just pressing the remote x times...


    doesn't make sense what you tell here. how to tell grub how the remote functions? you want to port the IR driver to grub? forget it.


    and booting some kernels via serial console from another locations like NFS servers or HD already goes with the existing bootloader, you don't need another bootloader for that.

    when I attach a serial terminal then grub would get the input key from there I would assume - but this needs to be tested.


    Porting IR driver would be really a pain and not sensemakingin the short run, I would more think about using the up and down buttons on the frontpannel at the beginning.


    But first I would need to find out if an additional bootloader could coexist with the current bootloader which would be worth a try, and I think this would be testable in the serial console by just porting/compiling the standard grub binary already.


    I know that when you use the curent bootloader in stop modus then enter via telnet, change the startup autorun.bat to an alternate one I CAN boot alternate confis/partitions already NOW


    In another thread I already asked if somebody would be interested to extend the standard bootloader so that you can choose
    for example autorun.bat1,2,3... as multiboot offers for booting now via the frontpannel keys, but I didn't get any feedback/reply on this idea
    (which would be only a very small codechange in my opionon).


    That's why I considered using a standard bootloader for doing the partition choosing instead.


    It is just a research project, so why not try out :winking_face:


    Cia
    thowi

    4 Mal editiert, zuletzt von thowi ()

    Zitat

    In another thread I already asked if somebody would be interested to extend the standard bootloader so that you can choose for example autorun.bat1,2,3... as multiboot offers for booting now via the frontpannel keys, but I didn't get any feedback/reply on this idea


    no. the best solution in your case is that the standard bootloader boots uboot instead of linux kernel and uboot boots the linux kernel from somewhere with your wishes :smiling_face: uboot is very flexible and ported to many MIPS boards, has even a builtin USB driver so that you can use a USB keyboard. admittedly you should adapt the USB driver to uboot. have a look at the xilleon usb kernel patches, i think, it's not a big effort. otherwise you also could use the framebuffer with uboot. this is the difficult part of porting. if you want, i send you the framebuffer specs of xilleon.

    OK, let me read the uboot docs and then come back.


    USB Booting and Keyboard support is nice but not on my current wishlist.


    My multiboot is not a great piece of software and it doesn't do anything that was not manually possible since months - it just made ist easier and simplier to use so that it got some acceptance by the users.


    This is what I have in mind when I think about bootloader support
    not porting or writing one.


    ciao
    thowi


    PS: I would not like to port anything to a framebuffer device - as already said, simple LCD output for boot selection and using the keys on the frontpannel is the maximum effort that I have in mind. If this does the job, why making things complicated.

    Zitat

    PS: I would not like to port anything to a framebuffer device - as already said, simple LCD output for boot selection and using the keys on the frontpannel is the maximum effort that I have in mind. If this does the job, why making things complicated.


    well then you have to do some reserve engineering job for LCD driver and frontpanel keys or kindly ask the DMM developers for help :smiling_face:

    Here's one way that I've been thinking about, but which I haven't done anything about (yet?).


    It's possible, at least on other architectures, to compile the linux kernel with "kexec" support. With "kexec", you can use the linux kernel as the bootloader, giving you access to all device drivers that already exist in linux. You could even load the Dream kenel modules to gain access to framebuffer and remote control.

    it's new for me that kexec is available for PowerPC and MIPS kernels.


    edit:


    I had a quick look at git-sources, kexec syscall is only available for the following archs: i386, x86_64, ppc, ppc64, ia_64, s390 and SH.


    it's very arch specific because some kernels are position dependent code, and loaded in unmapped memory, so a kernel would need to overwrite itself for kexec like in MIPS case. kexec still isn't flexible enough to handle this. so, bye bye kexec on DM7025! :face_with_tongue:

    Thanks for checking it up. Should of course have done it myself before posting...


    But still, maybe it's easier to port kexec to MIPS than it is to port uboot to DM7025. Hmmm. Will have to look closer at this some day.

    Zitat

    Original von Lior


    well then you have to do some reserve engineering job for LCD driver and frontpanel keys or kindly ask the DMM developers for help :smiling_face:


    This is exactly the reason why I FIRST want to try out if it works on the serial console, otherweise the begging would be useless like my suggested extension for the current bootloader :frowning_face:


    BTW Noggies Idea to use the standard kernel for doing the job is also a good one (miniroot is greeting, isn't it ?) even when it seems not to work.


    Finding Bootloaders working on mips (already) is really not an easy task as I found out on my web research during the last days (grub seems to be not available because of this)


    But let me see where this journey leads to - for this weekend I already have the lirc dameon as a toy for playing around so I'm not in a hurry :winking_face:


    ciao
    thowi

    Einmal editiert, zuletzt von thowi ()

    Zitat

    But still, maybe it's easier to port kexec to MIPS than it is to port uboot to DM7025. Hmmm. Will have to look closer at this some day.


    Well, If it had been something portable, then it would have been already ported :winking_face: I've done some work in glibc for MIPS and I have to say that MIPS is a very "clean" arch in comparison to x86, and if you want to give it a try, you must be very fit in "low level" MIPS things. :face_with_rolling_eyes: