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:picolisp@software-lab.de?subject=Unsubscribe


  

Reply via email to