vmlinux.gz with USB now BOOTS !

  • Hallo Leute !


    Ich habe gerade prinzipiellen support für USB sticks ins Beta 6.19 vom
    Multiboot eingebaut (also das Partitionslayout damit machen, copy von images zu und vom USB stick, aber noch nicht booten davon)


    es WÜRDE aber erlauben das root filesystem vom USB stick zu laden (nachdem man von CF Karte die bootpartition verwendet hat, die auch loszuwerden ist erst der übernächste schritt)


    ABER es funktioniert noch nicht, weil die verfügbaren Unix Kernel alle keinen USB support miteingebaut haben, sondern die driver erst später im boot cycle laden.


    Ich kenn mich mit dem OE nicht so aus, aber wenn mich mein Unix know how aus alten Zeiten nicht in den wald schickt kann man angeben welche driver in den Kernel dazugebaut werden sollen (mit compiler/make switch oder so ähnlich beim kernel builden)


    Könnte einer von Euch so einen Kernel bauen, weil wenn man dann von CF Karte bootet sollte man die /dev/sdaX devices sehen und man könnte sie dann als bootdevice im autorun.bat angeben.


    Weil so wie ich es verstehe extrahiert der secondstage bootlaoder das vmlinux.gz und fürhr es dann aus, das dann die autorun.bat interpretiert.


    Bitte um Bestätigung ob ich recht habe, sonst müssen wir die traurigen alternativen diskutieren
    ----------------------------------------------------------------------------------


    Hello folks !


    I just added some preliminiary support for USB sticks to Beta 6.19 of multiboot (doing Multiboot partitionlayout there, copy images to and from there, but not booting them yet).


    It WOULD allow to boot the root filesystem from USB sticks (after using the boot partiton of the CF card - getting rid of this is 2 steps ahead).


    BUT it doesn't work yet, because all the available linux kernels in the CSV Images are loading the USB modules later in their bootcycle.


    I'm not so familier with OE, but if my Unix know-how from the past is right it should be possible to build a vmlinux.gz that has the USB drivers already included (just a Compiler/make switch specifying the drivers included ?)


    Would it be possible that somebody creates such a kernel, because if this one would be bootet from CF card (or later Flash) in my assumption it would see already the /dev/sdaX devices so that they can be used as Boot device in autorun.bat).


    Because in my underdstanding the secondstage bootloader extracts the vmlinux.gz and executes it, which then interprets the rest of the autorun.bat ?


    Please confirm if I'm right, or let's discuss the not so bright alternatives.


    Ciao
    thowi

    7 Mal editiert, zuletzt von thowi ()

  • 1. I think you're aware of it, but just to make it absolutely clear: Loading the kernel from USB requires support in secondstage. I don't think this support is available, but the secondstage is undocumented and no sources are available, so who knows...
    2. Please see attached diff for kernel config to enable SCSI, SCSI disk, USB and USB storage as built-ins rather than as modules. I think this should be sufficient, but I haven't tested it.....
    3. Please be aware of the following problem and how to solve it: http://www.reactivated.net/web…-external-usb-flash-disk/
    4. I've compiled a kernel for the 7025 using the changed configuration, but the resulting vmlinux.gz is too large to post. Please advise me on a suitable method if you want me to send it to you.

  • Im NOT wanting to load the kernel from USB, it would stay in flash or CF card (similat to what FWZ does), but if this kernel would contain the USB drivers it could then boot his root / device from an USB partition.


    And yes, the timing could be a problem, but this is exactly why I want a kernel to test it :winking_face:


    I'll send you an e-mail adress via PN where you could send the extended kernel.


    I had the hope that the extended vmlinux.gz would fit in the 4MB flash, but let's see, it could be then almost 6-7MB big due to the jffs compression unless the gz did already a too good job :winking_face:


    Ciao
    thowi

    5 Mal editiert, zuletzt von thowi ()

  • Zitat

    Original von thowi


    I had the hope that the extended vmlinux.gz would fit in the 4MB flash, but let's see, it could be then almost 6-7MB big due to the jffs compression unless the gz did already a too good job :winking_face:


    It's on it's way, so you will see the size for yourself, but if anybody else is interested, a standard kernel from DMM is 1923521 bytes these days, while the one containing USB support is 2032044 bytes.

  • OK, I tried it and it is correctly initialized from the secondstage bootloader, but then it hangs on booting, so it looks like we really have the problem that the drivers are not fast enough bringing the device online so that /dev/sda5 is available.


    But if you try this kernel on a normal Multiboot image partiton residing on CF (and probably in flash too) you already get nice effects on the USB devices, so it is really an improvement for USB support !


    The 110k size increase of the kernel is not a big thing (4MB Flash have leave plenty of freespace)


    So we have to think for a moment on how to proceede from here and I'll play with the rootdelay parameter in the meantime asuming that this patch is built into the kernel ...


    But this IS promising, so let's see where this journey brings us.


    Ciao
    thowi

    8 Mal editiert, zuletzt von thowi ()

  • It would be interesting to know how much slower this kernel is during start-up. I would expect it to be slower if any USB devices are plugged in (but a little faster than loading kenel modules for the USB), the really interesting metric is how much slows down the boot if no USB devices are attached, i.e. how much it hurts those who have no interest in USB. Could you please post impressions and/or hard facts that you aquire during your testing?

  • I have a small USB hub from Conrad on my Dreambox where I have Joystick (for Dreamboy,...) and the USB sitck attached, and I could add also an USB Keyboard/mouse and DVD or Floppy Device.


    All this was tried out with a G*i image (where it is easier to load the appropiate kernel drivers)


    So I think I can test even the worst case :winking_face:


    But it looks like like the Hub and Joystick are not really slowing down the device recognition in a standard kernel when I do the mod* commands (maybe a few seconds more) ONLY for USB Storage drivers, it slows down significantly (+15-25 secs) only if all drivers are loaded and devices are present (this I already tested some weeks ago).


    And this would be a good sign for the bootable kerne with USB support - unless somebody wants to boot root from a CD and includes also these drivers :winking_face:


    I think this evening I should have some harder results, but at the moment I'm still suffering and watching console logs via the com port - but this is why I asked for this new toy so I'm not complaining.


    Ciao
    thowi

  • just a funny effect that I forgot to report in the meantime.


    If I boot normally from CF card with your USB linked kernel it doesn't mount the USB devices during boot that I added to fstab (eg. kernel is to slow in loading USB drivers/devices), but after booting I can mount them manually, so it seems to try to early.


    BUT if I add a rootdelay=30 the boot is as fast as usally BUT the USB is properly mounted from fstab.


    Strange, isn't it ...


    But because this is a positive effect without any harm I'll leave it in autorun.bat also if the root is a non-USB device :smiling_face:


    ----------------------------------------------------------------------------------------------------
    And I think it is not fair to let you wait any longer on my testresults :winking_face:
    ---------------------------------------------------------------------------------------------------


    YES, with rootdelay=30 it boots also from USB as long as the CF card is present to serve the vmlinux kernel. So with a small CF card (down to 8MB) we already have an USB boot !


    It works quite straightforward - it simply takes the 30 sec until the bootbar in LCD start to move and then it goes ...


    Why did it take so long to report back - well I tested it not only with the latest DMM standard image but also with some others - showing blue screens on booting :winking_face: And yes, it seems to work there also, as long as the image is not to old and the secondstage bootloader is from the latest CSV (I already added to multiboot how to update seconstage.gz)


    The only problem is that even when moving rootdelay to 60 or higher I cann't make these USB bootet images mount the USB from /etc/fstab


    But mounting them manually with multiboot info works, so this is not a real problem.


    So version 6.2 of Multiboot coming out today as Beta will contain USB Boot support with CF card GREAAAAAAAAAAAAAAAAAAT !


    Version 6.3 then will be able to do this also without CF and just USB device, but thiis is painfull to devleop and debug because I have to modify the autoexec.bat in flash and copy there the USB enabled vmlinux.gz. It is not TOO dificult and I'm sure that it will work, because I used the same approach for enableing multiboot on harddisk only installations (but making it run there was also a pain, because it needs serial flash when I do something wrong)


    So this version of multiboot will have to wait until next weekend.


    Again thanks for your help, and I hope it is OK to package the vmlinux.gz into the Multiboot 6.2 BETA kit, so that others can try and enjoy it also until the image buildes will start to build their vmlinux.gz this way - as a temporary workaround I implemented a copy V in multiboot to update only vmlinux.gz with the USB extended one, but this is not a perfect solution, because all patches adaption of the kernel
    the imagebuilders might have done is lost due to this.


    Ciao
    thowi

    8 Mal editiert, zuletzt von thowi ()

  • First of all, congratulations on your new version of multiboot! This story just proves that the greater work is not to come up with some changes and let the computer do some compilatioon work; it's the testing and making it work that takes time and effort.


    Zitat

    Original von thowi


    If I boot normally from CF card with your USB linked kernel it doesn't mount the USB devices during boot that I added to fstab (eg. kernel is to slow in loading USB drivers/devices), but after booting I can mount them manually, so it seems to try to early.


    I've seen reports from others that seems to indicate that this is also a problem if the standard USB modules are used.


    Zitat


    BUT if I add a rootdelay=30 the boot is as fast as usally BUT the USB is properly mounted from fstab.


    Strange, isn't it ...


    Yes, it's a bit strange that it doesn't delay the boot. I would guess that the explanation is that it actually does delay the boot a bit, but that some of that delay is "hidden" by some other initialization that needs to take place anyway.


    Zitat


    Again thanks for your help, and I hope it is OK to package the vmlinux.gz into the Multiboot 6.2 BETA kit, so that others can try and enjoy it also until the image buildes will start to build their vmlinux.gz this way - as a temporary workaround I implemented a copy V in multiboot to update only vmlinux.gz with the USB extended one, but this is not a perfect solution, because all patches adaption of the kernel
    the imagebuilders might have done is lost due to this.


    You needn't even have asked. Of course you can!

  • Well, it was just a long medidation on the problem during my vacation which led me to the conclusion that there must be another way to overcome the problem, and actually you gave me the final missing piece yourself by suggesting another way of building the kernel (even when you had something else in mind), which remembered me of my own kernel builds 10 years ago.


    And there it was very important to have all the needed drivers in the makefile, because dynamically loadable drivers where still speculation of some weird programmers or only available in commercial unix (well there were pinguins at that time but they were living in the antarktis)


    And yes, it is often not the inventor, it is the guy who makes a usable and sellable product that everybod can use who gets the flowers.


    Regarding the timeout and mount problems - well I think booting with debugging otions should give the right clue why and what happens, so this is something clever programmers can find out, and there is always the possibility to run a mount script later in the boot again until this is fixed.


    And this are small problem which can be solved on the way by all the volunteering multiboot testers and their inputs.


    At the moment I'll simply place the multiboot binaries needed at the moment on the harddisk (and not first USB partition) to overcome this problem for the moment, because as this example prooves if you cann't solve a problem then try to avoid it or go another way.


    Ciao
    thowi

    3 Mal editiert, zuletzt von thowi ()

  • IT IS DONE !


    Multiboot BETA 6.22 now allows to have multiboot with USB stick only.


    It is a little bit buggy, and I had to rape the flash bootpartition to serve the kernel for the USB Partitons, but it WORKS !


    I hope the people will have fun testing it so that we soon have a stable version for all the people who are fond of USB sticks - don't aks me why - probably notstalgia from the old boxes !


    Thanx again for your help and support - now it is on the image developers to build their kernels with these options and fix the mounting problems ...


    But I think as soon as it is prooven that this way works to get USB boot support there will be lots of testing and developing to iron out these remaining hick-ups.


    Ciao
    thowi

    Einmal editiert, zuletzt von thowi ()

  • one more question:


    could it be that the USB device driver doesn't allow more then 15 partitions per device, or that it has a bug ?


    Standard multiboot layout on USB is to have 1 primary partition for /media/usb at the beginning (part1) and 1 primary Partition for /media/mbX at the end (part3) and the second partition (part2) contains up to 12 logical partitions. Strange thing ist that with fdisk I can create all 12 logical paritions, but in the /dev/scsi directory only the device file up to part15 shows up, part 16 is always missing. But fdisk doesn't give an error.


    ls in /dev/scsi... directory:


    disc
    part1
    part10
    part11
    part12
    part13
    part14
    part15
    part2
    part3
    part5
    part6
    part7
    part8
    part9


    fidisk output:


    Disk disc: 1030 MB, 1030750208 bytes
    16 heads, 32 sectors/track, 3932 cylinders
    Units = cylinders of 512 * 512 = 262144 bytes


    Device Boot Start End Blocks Id System
    part1 * 1 58 14832 83 Linux
    part2 59 3809 960256 5 Extended
    part3 3810 3932 31488 83 Linux
    part5 59 364 78320 83 Linux
    part6 365 670 78320 83 Linux
    part7 671 976 78320 83 Linux
    part8 977 1282 78320 83 Linux
    part9 1283 1588 78320 83 Linux
    part10 1589 1894 78320 83 Linux
    part11 1895 2200 78320 83 Linux
    part12 2201 2506 78320 83 Linux
    part13 2507 2812 78320 83 Linux
    part14 2813 3118 78320 83 Linux
    part15 3119 3424 78320 83 Linux
    part16 3425 3730 78320 83 Linux


    This is a standard image with USB drivers loaded (not with USB linked kerne yet)


    Strange, isn't it ?


    Input is welcome


    ----- EDIT


    I also medidated on this problem - could it be that the driver is OK (hence fdisk works), but the kernel simply runs out of devices
    (16 for CF + 16 for USB + standard Devices) - eg could it be that there is a kernel parameter maxedv or something with is set to something like 64 and hence the device file cann't be created anymore because running out of device kernel slots ?


    Probabyl nobody created so many disk devices before so it could be taht I simply run into such a limitation) - then would it be possible to inclrease this kernel parameter for the Kernel built with USB drivers included to 96 or 128.


    ----------- EDIT


    Ciao
    thowi

    Einmal editiert, zuletzt von thowi ()

  • I'm not particularly familiar with the scsi code, but I think the following comment in kernel/scis/sd.c might provide an explanation:


    sd.c is "SCSI disk", and USB sticks are using the SCSI code.


    As you can see, 4 bits are used for the partition number, i.e. 16 partitions max. Someone probably thinks that 16 partitions on each disk are enough for anyone, and I can't really disagree.... :smiling_face:

  • Thanks for finding this explaination, at the moment I use Partition 1 and 3 as primary (for normale /media/usb and my exchange Partition created for multiboot things to be shared between images) and an extended with theup to 12 logical partitions bin between.


    So I'll simply reduce for USB the maximum Multiboot Partitions to 10 so that I have a spare one - you never know what it is good for :smiling_face:


    BTW, the whole USB drivers stuff still is a little bit wild in my understanding and test results so far.


    I have an USB stick not working at all (but can be formated on PC with windows and linux without problems), another one works only on an USB hub but not really when attached to the box directly,...


    So some testers are really suffering to see what is working and at the moment I'm stil holding out my hat (again) so that somebody builds a complete CSV Image with a kernel linked with the USB drivers, so that it is easier and more stable to begin multibooting on USB.


    But this is what I volunteered for when I asked for it, let's see where this journey brings us.


    Thanks a lot so far, and as a small thank You I created the first versions of the promised automount plugin already.


    Ciao
    thowi

    2 Mal editiert, zuletzt von thowi ()

  • hello !


    The vmlinux.gz that noggie posted with the USB drivers included is getting a little bit old - when my multilanguage support für multiboot is finished (in 1 week or so) I would like to include a more up-to-date one in Version 7.1, hence I'm asking if somebody could build a newer one from the current CVS over the weekend ?


    Thanks in advance
    thowi

    2 Mal editiert, zuletzt von thowi ()

  • As far as I know, the kernel is still at 2.6.12.6-r6, so I don't think there has been any official improvements compared to the one I sent you. Please correct me if I'm wrong.

  • I though I saw already r8 Kernels but sometimes the imagebuilders are not too precise in their readme and it could be that I just was confused.


    I'll check and come back only if needed.


    Probably I'll add also kernels to be downloaded via multiboot image download center anyway (when I have time to do the coding), because at the moment I simply replace the kernel, but later you should be able ot geth the original ones back (either from nfi image oder downloading) and then it would be no problem to get always the latest version if somebody spends his time to manage this :winking_face:


    Thanks again


    (BTW gettext support now starts to rock for multiboot - German works now 90% already and Italian with 60%)


    Ciao
    thowi