Hi Alex, > The problem is that this is a bit tedious (unless using e.g. qemu)> because > you have to put the test onto the USB-stick each time and reboot> the test > machine with it. Indeed! ok so time to install qemu.. but hmm if the current pilOS works on your qemu then it would not help right? Or does qemu also depends on its host hardware that its running?
> Hmm, perhaps, but I don't know how. Because we *need* to read the> sectors > from the stick, don't we?>> Perhaps there is another way to format the boot > partitions and/or use> another BIOS call. I just don't know about it. Hmm ok I think there should be a generic way to do this.. will see what i can find then.. > Also, it would be good to know if VirtualBox *really* doesn't support> this > BIOS call, or if there is some other reason why it fails. I think it should support coz i think almost all virtual machines should work as much as possible as near as an actual standalone hardware? But lets see.. Hmmm might be helpful if we can refer how those liveUSB handle their boot-up? BR,geo On Wednesday, July 8, 2015 8:25 PM, Alexander Burger <abu@software-labde> wrote: Hi Geo, > OK did a quick peek and most of them are in x86 assembly hmmm Yeah. Basically calls to the 'cpuid' instruction to question the CPU for its parameters. > I see, so it means it got stuck somewhere on the checking, would it be > possible to be inside an infinite loop? I believe that the 'cpuid' instruction cannot loop or crash. Rather, I suspect that for some reason the following messages are not printed because the CPU got into an unknown state. > it possible to have a debug mode for PilOS that it will not overwrite > the messages? Yes. What I did usually during development is inserting more 'print' messages, similar to mov $LongMsg, %si call print and and/or stopped the CPU with jmp stop so that the blue VGA screen of PilOS doesn't overwrite the boot screen. Even easier is, if you re-use some existing message, e.g. "Loading PilOS" (which is in 'LoadMsg') and then jump directly to 'bootError' which will output the message and stop the CPU. So if you insert mov $LoadMsg, %si jmp bootError after e.g. the first 'cpuid' call, and you see "Loading PilOS" appearing a second time, you are sure that the boot got this far. The problem is that this is a bit tedious (unless using e.g. qemu) because you have to put the test onto the USB-stick each time and reboot the test machine with it. > This is done via> BIOS interrupt 0x13: > >https://en.wikipedia.org/wiki/INT_13#INT_13h_AH.3D42h:_Extended_Read_Sectors_From_Drive > I think VirtualBox doesn't support this interrupt call. > I see, ok noted. But still this can be reworked right? Hmm, perhaps, but I don't know how. Because we *need* to read the sectors from the stick, don't we? Perhaps there is another way to format the boot partitions and/or use another BIOS call. I just don't know about it. Also, it would be good to know if VirtualBox *really* doesn't support this BIOS call, or if there is some other reason why it fails. ♪♫ Alex -- UNSUBSCRIBE: mailto:firstname.lastname@example.org?subject=Unsubscribe