muta...@gmail.com
2021-07-09 13:29:17 UTC
Ok, it is extremely interesting inspecting other
people's BIOSes. It's truly fascinating. I had
assumed that older computers would still have
legacy mode support.
I am faced with an Acer Aspire ES1-432
There are a set of drivers available here:
https://www.acer.com/ac/en/KH/content/support-product/6976?b=1
The latest is version 1.28, but the user is on 1.18.
The BIOS setup shows insydeh20 setup utility.
I've looked at someone else using an Acer on youtube,
very similar, but they have a "boot mode" option appearing
on the screen with the boot order:
see 2:25 but I don't. They are using 1.06. I have already
set the supervisor password which enabled me to
disable secure boot from that same screen.
Mine looks exactly like this:
My understanding is that if you could switch to legacy
mode, it would mean:
1. The MBR signature would be checked.
2. The CPU would be in real mode.
3. Code would start executing from the beginning
of the MBR.
4. A BIOS would exist.
And I have a working theory that the BIOS doesn't exist
at all, which is why there is no option to switch on
legacy mode.
I downloaded the 1.18 software and looked at the
strings and saw this:
-BIOS Flash Intel BIOS region (Must use with -X)
-BIOS Flash BIOS region
-EOB Only flash BIOS when EC and bios are merge
And my theory is that you can have a BIOS on this machine,
you just need to run this utility with the "-BIOS" option, and
the manufacturer simply never did that.
So I'm thinking of getting the user to try running the
same 1.18 software, but I'll check the options that
come up and then ask them to specify "-BIOS". And
hopefully then a "legacy" option will appear.
The word "legacy" isn't one of the strings though, but
maybe it is compressed.
Doesn't appear in the 1.28 either. Nor 1.06. So it's not
as obvious as going forward or backwards.
1.18 dates it to 2018 so it's not as old as I expected.
I'm trying to tease out the underlying philosophy here.
Note that I refused to work with them until they backed
up their data, and I will take responsibility for replacing
their computer if I screw it up.
I have also been introduced to the concept of an
"option ROM".
It is unclear to me at what level I can start flashing
things onto the firmware.
The executable is quite odd. I can see this:
C:\Users\kerra\Downloads\xxx\BIOS_Acer_1.18_Windows>hexdump ZQF_118.exe | more
000000 4D5A0000 28001900 2000B704 B7057D08 MZ..(... .....}.
000010 80010000 54000000 3E000000 0100FB50 ....T...>......P
000020 6A720000 00000000 00000000 00000000 jr..............
000030 00000000 00000000 00000000 68160400 ............h...
000040 0000EC00 0000F704 00002208 00000708 ..........".....
000050 0000870E 0000820C 0000640C 0000560C ..........d...V.
000060 00000F10 00000110 0000AE10 0000BC12 ................
000070 00004A13 0000E313 0000D202 9D043C23 ..J...........<#
000080 00002E23 0000FF22 0000D822 00006224 ...#..."..."..b$
000090 00007A2B 00007C2C 0000962C 0000C72C ..z+..|,...,...,
0000A0 00000000 00000D0A 43575344 504D4920 ........CWSDPMI
0000B0 72352043 6F707972 69676874 20284329 r5 Copyright (C)
0000C0 20323030 30204357 2053616E 646D616E 2000 CW Sandman
0000D0 6E202873 616E646D 616E6E40 636C696F n (***@clio
0000E0 2E726963 652E6564 75292E0D 0A546865 .rice.edu)...The
0000F0 20737475 62206C6F 61646572 20697320 stub loader is
000100 436F7079 72696768 74202843 29203139 Copyright (C) 19
000110 39332D31 39393520 444A2044 656C6F72 93-1995 DJ Delor
000120 69652E0D 0A506572 6D697373 696F6E20 ie...Permission
000130 6772616E 74656420 746F2075 73652066 granted to use f
000140 6F722061 6E792070 7572706F 73652070 or any purpose p
000150 726F7669 64656420 74686973 20636F70 rovided this cop
000160 79726967 68740D0A 72656D61 696E7320 yright..remains
000170 70726573 656E7420 616E6420 756E6D6F present and unmo
000180 64696669 65642E0D 0A546869 73206F6E dified...This on
000190 6C792061 70706C69 65732074 6F207468 ly applies to th
0001A0 65207374 75622C20 616E6420 6E6F7420 e stub, and not
0001B0 6E656365 73736172 696C7920 74686520 necessarily the
0001C0 77686F6C 65207072 6F677261 6D2E0D0A whole program...
0001D0 00000000 00000000 00000000 00000000 ................
0001E0 00000000 00000000 00000000 00000000 ................
0001F0 00000000 00000000 00000000 00000000 ................
000200 676F3332 73747562 2C207620 322E3032 go32stub, v 2.02
000210 54000000 00000800 00000000 00000000 T...............
So it looks like it will do something under MSDOS - run
some sort of DOS extender.
But it's supposedly a Windows program.
This could be a "PE" signature:
041660 00000000 00000000 50450000 64860500 ........PE..d...
Who is the target audience for the non-Windows executable?
Some sort of standalone non-Windows firmware flasher?
I've seen Freedos mentioned in this sort of context before.
You're somehow supposed to boot Freedos, which requires
legacy mode? Why not boot Linux? The MSDOS DOS
extenders are better? You can't do this under Windows?
Would PDOS/386 be helpful here? It fits on a 360k floppy
and gives unrestricted hardware access in a Win32
executable. You can do the same thing with Freedos+HX
(I think) but it's a lot more baggage.
I'd hate to have to give up on this computer.
I am not interested in the details of the hardware,
but I am interested in the details of what the other
side is capable of doing at the OS interface level.
And if I can flash some C code, that would be great.
A new target for PDPCLIB. Not sure what it looks
like over there. Is there opportunity for both 16-bit
huge memory model and 32-bit flat mode? Bochs
comes with a BIOS:
romimage: file=$BXSHARE/BIOS-bochs-latest #romimage: file=bios/seabios-0.5.1.bin #romimage: file=mybios.bin, address=0xfff80000 # 512k at memory top
And I see seabios is given as an example. I wonder
how many competitors there are in this market?
Bochs actually already does what I want with
INT 14H, mapping it into something interesting.
I wonder if it can be mapped into Bluetooth
communication with my dumb phone? I would
take a lot more interest in bluetooth if I could
access it via INT 14H from PDOS/386. Maybe I
should volunteer to work on Bochs or something,
as a precursor to real hardware/firmware.
How much code would be required to marry up
INT 14H to someone else's libbluetooth so that
PDOS/386 only needs to deal with an actual
file transfer protocol? And would this be a
suitable substitute for Fidonet FTS-0001?
BFN. Paul.
people's BIOSes. It's truly fascinating. I had
assumed that older computers would still have
legacy mode support.
I am faced with an Acer Aspire ES1-432
There are a set of drivers available here:
https://www.acer.com/ac/en/KH/content/support-product/6976?b=1
The latest is version 1.28, but the user is on 1.18.
The BIOS setup shows insydeh20 setup utility.
I've looked at someone else using an Acer on youtube,
very similar, but they have a "boot mode" option appearing
on the screen with the boot order:
see 2:25 but I don't. They are using 1.06. I have already
set the supervisor password which enabled me to
disable secure boot from that same screen.
Mine looks exactly like this:
My understanding is that if you could switch to legacy
mode, it would mean:
1. The MBR signature would be checked.
2. The CPU would be in real mode.
3. Code would start executing from the beginning
of the MBR.
4. A BIOS would exist.
And I have a working theory that the BIOS doesn't exist
at all, which is why there is no option to switch on
legacy mode.
I downloaded the 1.18 software and looked at the
strings and saw this:
-BIOS Flash Intel BIOS region (Must use with -X)
-BIOS Flash BIOS region
-EOB Only flash BIOS when EC and bios are merge
And my theory is that you can have a BIOS on this machine,
you just need to run this utility with the "-BIOS" option, and
the manufacturer simply never did that.
So I'm thinking of getting the user to try running the
same 1.18 software, but I'll check the options that
come up and then ask them to specify "-BIOS". And
hopefully then a "legacy" option will appear.
The word "legacy" isn't one of the strings though, but
maybe it is compressed.
Doesn't appear in the 1.28 either. Nor 1.06. So it's not
as obvious as going forward or backwards.
1.18 dates it to 2018 so it's not as old as I expected.
I'm trying to tease out the underlying philosophy here.
Note that I refused to work with them until they backed
up their data, and I will take responsibility for replacing
their computer if I screw it up.
I have also been introduced to the concept of an
"option ROM".
It is unclear to me at what level I can start flashing
things onto the firmware.
The executable is quite odd. I can see this:
C:\Users\kerra\Downloads\xxx\BIOS_Acer_1.18_Windows>hexdump ZQF_118.exe | more
000000 4D5A0000 28001900 2000B704 B7057D08 MZ..(... .....}.
000010 80010000 54000000 3E000000 0100FB50 ....T...>......P
000020 6A720000 00000000 00000000 00000000 jr..............
000030 00000000 00000000 00000000 68160400 ............h...
000040 0000EC00 0000F704 00002208 00000708 ..........".....
000050 0000870E 0000820C 0000640C 0000560C ..........d...V.
000060 00000F10 00000110 0000AE10 0000BC12 ................
000070 00004A13 0000E313 0000D202 9D043C23 ..J...........<#
000080 00002E23 0000FF22 0000D822 00006224 ...#..."..."..b$
000090 00007A2B 00007C2C 0000962C 0000C72C ..z+..|,...,...,
0000A0 00000000 00000D0A 43575344 504D4920 ........CWSDPMI
0000B0 72352043 6F707972 69676874 20284329 r5 Copyright (C)
0000C0 20323030 30204357 2053616E 646D616E 2000 CW Sandman
0000D0 6E202873 616E646D 616E6E40 636C696F n (***@clio
0000E0 2E726963 652E6564 75292E0D 0A546865 .rice.edu)...The
0000F0 20737475 62206C6F 61646572 20697320 stub loader is
000100 436F7079 72696768 74202843 29203139 Copyright (C) 19
000110 39332D31 39393520 444A2044 656C6F72 93-1995 DJ Delor
000120 69652E0D 0A506572 6D697373 696F6E20 ie...Permission
000130 6772616E 74656420 746F2075 73652066 granted to use f
000140 6F722061 6E792070 7572706F 73652070 or any purpose p
000150 726F7669 64656420 74686973 20636F70 rovided this cop
000160 79726967 68740D0A 72656D61 696E7320 yright..remains
000170 70726573 656E7420 616E6420 756E6D6F present and unmo
000180 64696669 65642E0D 0A546869 73206F6E dified...This on
000190 6C792061 70706C69 65732074 6F207468 ly applies to th
0001A0 65207374 75622C20 616E6420 6E6F7420 e stub, and not
0001B0 6E656365 73736172 696C7920 74686520 necessarily the
0001C0 77686F6C 65207072 6F677261 6D2E0D0A whole program...
0001D0 00000000 00000000 00000000 00000000 ................
0001E0 00000000 00000000 00000000 00000000 ................
0001F0 00000000 00000000 00000000 00000000 ................
000200 676F3332 73747562 2C207620 322E3032 go32stub, v 2.02
000210 54000000 00000800 00000000 00000000 T...............
So it looks like it will do something under MSDOS - run
some sort of DOS extender.
But it's supposedly a Windows program.
This could be a "PE" signature:
041660 00000000 00000000 50450000 64860500 ........PE..d...
Who is the target audience for the non-Windows executable?
Some sort of standalone non-Windows firmware flasher?
I've seen Freedos mentioned in this sort of context before.
You're somehow supposed to boot Freedos, which requires
legacy mode? Why not boot Linux? The MSDOS DOS
extenders are better? You can't do this under Windows?
Would PDOS/386 be helpful here? It fits on a 360k floppy
and gives unrestricted hardware access in a Win32
executable. You can do the same thing with Freedos+HX
(I think) but it's a lot more baggage.
I'd hate to have to give up on this computer.
I am not interested in the details of the hardware,
but I am interested in the details of what the other
side is capable of doing at the OS interface level.
And if I can flash some C code, that would be great.
A new target for PDPCLIB. Not sure what it looks
like over there. Is there opportunity for both 16-bit
huge memory model and 32-bit flat mode? Bochs
comes with a BIOS:
romimage: file=$BXSHARE/BIOS-bochs-latest #romimage: file=bios/seabios-0.5.1.bin #romimage: file=mybios.bin, address=0xfff80000 # 512k at memory top
And I see seabios is given as an example. I wonder
how many competitors there are in this market?
Bochs actually already does what I want with
INT 14H, mapping it into something interesting.
I wonder if it can be mapped into Bluetooth
communication with my dumb phone? I would
take a lot more interest in bluetooth if I could
access it via INT 14H from PDOS/386. Maybe I
should volunteer to work on Bochs or something,
as a precursor to real hardware/firmware.
How much code would be required to marry up
INT 14H to someone else's libbluetooth so that
PDOS/386 only needs to deal with an actual
file transfer protocol? And would this be a
suitable substitute for Fidonet FTS-0001?
BFN. Paul.