Re: [ipxe-devel] 486 with a Realtek 8139
On 16/05/2021 21:04, Michael Brown wrote: On 16/05/2021 21:04, Nikolai Zhubr wrote: Ok, no need for a floppy actually. Apparently the "boot partition" method is still usable as long as disk partitioning was performed carefully (I ran Msdos' fdisk utility on this same board to add a partition so as to avoid possible conflicts with BIOS' geometry settings). The result is a total hang with no message displayed whatsoever and Caps Lock not responding. I'm quite sure loading from disk is successfull, because from my previous attempts I know an error message would be displayed in case of a read failure. Thanks for testing. Next step is probably to try building with DEBUG=libprefix I've sourced a 486 system (courtesy of some kind people who responded on Twitter) so should be able to also test for myself on Wednesday. Michael ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
On 16/05/2021 21:04, Nikolai Zhubr wrote: Ok, no need for a floppy actually. Apparently the "boot partition" method is still usable as long as disk partitioning was performed carefully (I ran Msdos' fdisk utility on this same board to add a partition so as to avoid possible conflicts with BIOS' geometry settings). The result is a total hang with no message displayed whatsoever and Caps Lock not responding. I'm quite sure loading from disk is successfull, because from my previous attempts I know an error message would be displayed in case of a read failure. Thanks for testing. Next step is probably to try building with DEBUG=libprefix Michael ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
16.05.2021 16:06, I wrote: [...] I'm asking for this testing in order to eliminate problems potentially caused by interaction with your Etherboot ROM. Yes, this is reasonable enough. As harddisk image somehow failed to be recognized by this board, I'll try to look into attaching a floppy drive (so a real fun starts) Ok, no need for a floppy actually. Apparently the "boot partition" method is still usable as long as disk partitioning was performed carefully (I ran Msdos' fdisk utility on this same board to add a partition so as to avoid possible conflicts with BIOS' geometry settings). The result is a total hang with no message displayed whatsoever and Caps Lock not responding. I'm quite sure loading from disk is successfull, because from my previous attempts I know an error message would be displayed in case of a read failure. Thank you, Regards, Nikolai ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
16.05.2021 13:09, Michael Brown: [...] To be fair: "cd src ; make" would have built you the exact bin/ipxe.pxe target that I already suggested using. Sure, but my point was that normally, such a binary would only be of interest for just some quick test/demo/debugging puposes, because hardly anyone would want to burn an image containing support for all possible controllers with all possible boot protocols for everyday use, therefore a consistent step-by-step instruction for building a typical custom image containing some selected features would be helpfull, I was certainly expecting something like that near the top of main page. Debug builds are fairly specialised (and not something that most users This is true. will need), debugging a hang at this stage of operation is even more specialised, and getting iPXE working on a 30-year-old CPU is definitely well into the depths of obscure corner cases. I certainly understand that 486 is not very usual currently. But it is itself just a target platform, not a corner case. As such, it can be either supported or not. The board in question is a regular one of that time, nothing special. I'm asking for this testing in order to eliminate problems potentially caused by interaction with your Etherboot ROM. Yes, this is reasonable enough. As harddisk image somehow failed to be recognized by this board, I'll try to look into attaching a floppy drive (so a real fun starts) Thank you, Regards, Nikolai Thanks, Michael ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
On 16/05/2021 10:00, Nikolai Zhubr wrote: I have to correct myself. The documentation does exist (online), however for me as a user it is arranged in a very unexpected manner, and it confuses to a surprisingly high degree. First, the material goes all upside-down: command line goes before build options, architecture of wimboot goes before build targets. One could suppose it does not matter (as long as the links are within a single page anyway), but yes it does matter quite a lot. Second, it is presented in way that somehow discourages long sequential reading (by "long" I mean more than 3 lines), very much pushing the idea that as a user you only need to comprehence "cd src; make" at most, which is not always good enough. To be fair: "cd src ; make" would have built you the exact bin/ipxe.pxe target that I already suggested using. Debug builds are fairly specialised (and not something that most users will need), debugging a hang at this stage of operation is even more specialised, and getting iPXE working on a 30-year-old CPU is definitely well into the depths of obscure corner cases. I personally dislike reading documentation that is polluted with corner cases and historical arcana. The overriding goal of any documentation that I write is to make it easy for the reader to get the basic use case working as quickly as possible and with zero distractions. For your testing: I would first suggest trying to boot iPXE from a storage medium such as a USB key (or floppy disk, given that you're talking about a 486-era system). Both bin/ipxe.usb and bin/ipxe.dsk will also already be built by "cd src ; make". I'm asking for this testing in order to eliminate problems potentially caused by interaction with your Etherboot ROM. Thanks, Michael ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
On Sun, May 16, 2021 at 12:03:54PM +0300, Nikolai Zhubr wrote: > Hi Geert, ;-) > 16.05.2021 9:26, Geert Stappers: > [...] > > > ... same result: > > > "640kB free base memory after PXE unload" > > > > Over here is that recieved as "it hangs" > > Yes, exactly. > > > Thank you, > > Regards, > Nikolai > > > > > > Thanks for testing, > > > > Which DEBUG=... is recommend as next step? > > At https://ipxe.org/download#debug_builds is example make bin/ipxe.iso DEBUG=iscsi and mentions `iscsi.c`. What follows is a wild guess make bin/10ec8139.pxe DEBUG=console It is solely based upon on existence of `src/core/console.c`. Please give it a try. Since https://lists.ipxe.org/pipermail/ipxe-devel/2021-May/007445.html has iPXE again better i486 support, so we can go tackle further hardware oddness ... Groeten Geert Stappers -- Silence is hard to parse ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
Hi Geert, 16.05.2021 9:26, Geert Stappers: [...] ... same result: "640kB free base memory after PXE unload" Over here is that recieved as "it hangs" Yes, exactly. Thank you, Regards, Nikolai Thanks for testing, Which DEBUG=... is recommend as next step? Michael Regards Geert Stappers ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
16.05.2021 0:56, Nikolai Zhubr: [...] Not sure if I did something obviously stupid because documentation is pretty much non-existent. I have to correct myself. The documentation does exist (online), however for me as a user it is arranged in a very unexpected manner, and it confuses to a surprisingly high degree. First, the material goes all upside-down: command line goes before build options, architecture of wimboot goes before build targets. One could suppose it does not matter (as long as the links are within a single page anyway), but yes it does matter quite a lot. Second, it is presented in way that somehow discourages long sequential reading (by "long" I mean more than 3 lines), very much pushing the idea that as a user you only need to comprehence "cd src; make" at most, which is not always good enough. Thank you, Regards, Nikolai ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
On Sun, May 16, 2021 at 03:15:43AM +0300, Nikolai Zhubr wrote: > 16.05.2021 1:26, Michael Brown: > > You can keep it simple and just build using any reasonably current (less > > than 10 years old) Linux distro's default gcc, with the command: > > > > make bin/10ec8139.pxe > > Yes, it now builds successfully with both compilers. > Unfortunately the result is the same as before, except that the message now > says "640kB" instead of "633kB". > ... > ... same result: > "640kB free base memory after PXE unload" Over here is that recieved as "it hangs" > > Thanks for testing, Which DEBUG=... is recommend as next step? > > Michael > > Regards Geert Stappers -- https://duckduckgo.com/?q=640kb+memory+is+enough&ia=web ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
16.05.2021 1:26, Michael Brown: [...] Not sure where you got the notion of using "ARCH=x86" from - there is no "x86" build architecture supported in iPXE, no documentation suggesting that it does, and no documentation suggesting that "ARCH=..." should ever be specified on the build command line. This will be the cause of your circular DEPS problem. Indeed, removing ARCH helped. (It was a leftover of building kernels, my mistake. Got too much used to it) You can keep it simple and just build using any reasonably current (less than 10 years old) Linux distro's default gcc, with the command: make bin/10ec8139.pxe Yes, it now builds successfully with both compilers. Unfortunately the result is the same as before, except that the message now says "640kB" instead of "633kB". (note .pxe rather than .kpxe - the .kpxe suffix is for the undionly.kpxe build target only, as per all available documentation). Well, for me as a user, some suffix descriptions (pxe, kpxe, kkpxe) looked somewhat vague. Anyway, I initially tried both, with the same result. You also have the option of using bin/ipxe.pxe, which will contain the full set of PCI NIC drivers. There's a prebuilt version downloadable at all times from http://boot.ipxe.org/ipxe.pxe Just tried this one too, same result: "640kB free base memory after PXE unload" Thank you, Regards, Nikolai Thanks for testing, Michael ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
On 15/05/2021 22:56, Nikolai Zhubr wrote: One note is that I had to compile using the default ancient system gcc compiler with: "make -j1 bin/10ec8139.kpxe EMBED=chain.ipxe" where gcc says: gcc (SUSE Linux) 4.8.3 An attempt to cross-compile using my preferred 486 toolchain with gcc 7.5 fails because DEPS start going circles forever. For that attempt, I used: "make -j1 CROSS_COMPILE=... ARCH=x86 bin/10ec8139.kpxe EMBED=chain.ipxe" Usually, the command line like above works fine. Not sure where you got the notion of using "ARCH=x86" from - there is no "x86" build architecture supported in iPXE, no documentation suggesting that it does, and no documentation suggesting that "ARCH=..." should ever be specified on the build command line. This will be the cause of your circular DEPS problem. You can keep it simple and just build using any reasonably current (less than 10 years old) Linux distro's default gcc, with the command: make bin/10ec8139.pxe (note .pxe rather than .kpxe - the .kpxe suffix is for the undionly.kpxe build target only, as per all available documentation). There is no need to use -j1, and no need for any custom gcc toolchain. You also have the option of using bin/ipxe.pxe, which will contain the full set of PCI NIC drivers. There's a prebuilt version downloadable at all times from http://boot.ipxe.org/ipxe.pxe Thanks for testing, Michael ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
Hi Michael, 12.05.2021 13:12, Michael Brown: [...] With those changes, there would be no need for any compile-time option or accompanying documentation: the code would Just Work on a 486. All three of the above are now implemented: https://github.com/ipxe/ipxe/commit/13c1abe10 https://github.com/ipxe/ipxe/commit/05fcf1a2f https://github.com/ipxe/ipxe/commit/a6a8bb1a9 With the current master branch, I am able to boot successfully using iPXE on a (bochs-emulated) 486. An attempt to chainload iPXE compiled as 10ec8139.kpxe using Etherboot as a primary loader, resulted in last message displayed "633kB free base memory after PXE unload" then nothing (and Caps Lock not working) Just to be sure, immediately replacing "10ec8139.kpxe" with "pxelinux.0" in my DHCP server settings and restarting it results in pxelinux's menu successfully appering so I know the environment is most probably OK. One note is that I had to compile using the default ancient system gcc compiler with: "make -j1 bin/10ec8139.kpxe EMBED=chain.ipxe" where gcc says: gcc (SUSE Linux) 4.8.3 An attempt to cross-compile using my preferred 486 toolchain with gcc 7.5 fails because DEPS start going circles forever. For that attempt, I used: "make -j1 CROSS_COMPILE=... ARCH=x86 bin/10ec8139.kpxe EMBED=chain.ipxe" Usually, the command line like above works fine. Not sure if I did something obviously stupid because documentation is pretty much non-existent. A side note is the size of 10ec8139.rom is almost 70kb, which somewhat beyond the capacity of even the largest ROM chip that Realtek 8139 can be equipped with. Thank you, Regards, Nikolai Michael ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
On Wed, May 12, 2021 at 11:12:36AM +0100, Michael Brown wrote: > On 05/05/2021 20:13, Michael Brown wrote: > > For unlzma.S, just changing to ".arch i486" is fine, since there are no > > 586-class instructions in that file. > > > > For undinet.c, the "rdtsc" instructions are used only for profiling. > > It's probably not worth the marginally increased accuracy from having > > the rdtsc within the real-mode code: those TSC reads could be moved > > outside the REAL_CODE() block and implemented using the standard > > profile_xxx() functions instead of hardcoded "rdtsc" instructions. (An > > alternative approach would be to conditionalise the presence of the > > "rdtsc" instructions, but it would need to be an exceptionally neat > > solution to justify such a special case.) > > > > For rtc_entropy.c, the use of the TSC is intrinsic to the way that the > > code operates. There is already an entropy_enable() call that is > > allowed to return an error to indicate that the entropy source is > > unusable: this could be extended to include a low-overhead check for the > > existence of the TSC. > > > > With those changes, there would be no need for any compile-time option > > or accompanying documentation: the code would Just Work on a 486. > > All three of the above are now implemented: > > https://github.com/ipxe/ipxe/commit/13c1abe10 > https://github.com/ipxe/ipxe/commit/05fcf1a2f > https://github.com/ipxe/ipxe/commit/a6a8bb1a9 > > With the current master branch, I am able to boot successfully using iPXE on > a (bochs-emulated) 486. > > Michael Thanks. Looking forward to reports on real hardware ... Groeten Geert Stappers -- Silence is hard to parse ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
On 05/05/2021 20:13, Michael Brown wrote: For unlzma.S, just changing to ".arch i486" is fine, since there are no 586-class instructions in that file. For undinet.c, the "rdtsc" instructions are used only for profiling. It's probably not worth the marginally increased accuracy from having the rdtsc within the real-mode code: those TSC reads could be moved outside the REAL_CODE() block and implemented using the standard profile_xxx() functions instead of hardcoded "rdtsc" instructions. (An alternative approach would be to conditionalise the presence of the "rdtsc" instructions, but it would need to be an exceptionally neat solution to justify such a special case.) For rtc_entropy.c, the use of the TSC is intrinsic to the way that the code operates. There is already an entropy_enable() call that is allowed to return an error to indicate that the entropy source is unusable: this could be extended to include a low-overhead check for the existence of the TSC. With those changes, there would be no need for any compile-time option or accompanying documentation: the code would Just Work on a 486. All three of the above are now implemented: https://github.com/ipxe/ipxe/commit/13c1abe10 https://github.com/ipxe/ipxe/commit/05fcf1a2f https://github.com/ipxe/ipxe/commit/a6a8bb1a9 With the current master branch, I am able to boot successfully using iPXE on a (bochs-emulated) 486. Michael ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
Hi Michael, 09.05.2021 23:06, Michael Brown: [...] You're welcome to fork Etherboot and maintain it on your own, but if you want there to be any chance of what you need being supported upstream, then you'll need to work with the current iPXE codebase. Yes, I'll certainly keep that in mind. Thank you, Regards, Nikolai Michael ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139, patch
On Mon, May 10, 2021 at 12:37:50AM +0300, Nikolai Zhubr wrote: > Hi Geert, > > 09.05.2021 22:56, Geert Stappers: > [...] > > Where originates the 2010 realmode_asm.S from? > > Please see e.g.: > > https://github.com/etherboot/etherboot/blob/master/src/arch/i386/core/realmode_asm.S > > I took my copy elsewhere back then, but comparing now says my original files > are all identical to this repo. > Now for additional convenience here is a fork with the patch already > applied: > > https://github.com/zhubr/etherboot > Ah, that explains why the patch did not apply. It was for etherboot, not for iPXE. Feel welcome at iPXE project. Regards Geert Stappers Worked with Ken Yap, founder of Etherboot Fought against Marty Connor, former Etherboot project boss -- Silence is hard to parse ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139, patch
Hi Geert, 09.05.2021 22:56, Geert Stappers: [...] Where originates the 2010 realmode_asm.S from? Please see e.g.: https://github.com/etherboot/etherboot/blob/master/src/arch/i386/core/realmode_asm.S I took my copy elsewhere back then, but comparing now says my original files are all identical to this repo. Now for additional convenience here is a fork with the patch already applied: https://github.com/zhubr/etherboot Thank you, Regards, Nikolai Groeten Geert Stappers ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
On 07/05/2021 00:20, Nikolai Zhubr wrote: I appologise for bugging you with ancient etherboot, please ignore if it is too much off topic. I'm just not sure how to proceed yet. I'm pleased that you managed to get something working, but just to be clear: there is zero chance of any changes being accepted to a codebase that became obsolete around 15 years ago. You're welcome to fork Etherboot and maintain it on your own, but if you want there to be any chance of what you need being supported upstream, then you'll need to work with the current iPXE codebase. Michael ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139, patch
On Sun, May 09, 2021 at 03:37:18AM +0300, Nikolai Zhubr wrote: > 08.05.2021 9:45, Geert Stappers: > > ... > > Any chance in dumping somewhere > > a rough / rude version of the made changes? > > No worries, it is basically a 5-liner, and I don't hide my bugfixes. Please > see a diff file attached, > --- src/arch/i386/core/realmode_asm.S 2010-09-05 23:47:29.0 +0300 > +++ src/arch/i386/core/realmode_asm.S 2021-05-09 01:25:42.042733352 +0300 > @@ -301,9 +301,11 @@ > movl%eax, %ebx > shrl$4, %ebx > pushw %bx > - leal3f(%ebp), %ebx > + movw%bx, (p2r_ljmp_rm+3)(%ebp) > + leal(p2r_ljmp_rm+5)(%ebp), %ebx > subl%eax, %ebx > pushw %bx > + movw%bx, (p2r_ljmp_rm+1)(%ebp) > /* Continuation address */ > pushl $(p2r_rmcs - p2r_gdt) > leal2f(%ebp), %ebx > @@ -348,12 +350,21 @@ > /* Make intersegment jmp to flush the processor pipeline >* and reload %cs:%eip (to clear upper 16 bits of %eip). >*/ > - lret > -3: > > +p2r_ljmp_rm: > + ljmp$0, $9f /* EA oo oo ss ss */ > +9: > /* Load real-mode segment value to %ss. %sp already OK */ > shrl$4, %eax > movw%ax, %ss > + movzwl %sp, %esp > + movw%ax, %ds > + movw%ax, %es > + movw%ax, %fs > + movw%ax, %gs > + > + popw%bx > + popw%bx > > /* Restore registers */ > popl%eax > I wasn't able to apply that patch. Screenshot: |... output of `patch < /path/to/saved/email` ... ||--- src/arch/i386/core/realmode_asm.S 2010-09-05 23:47:29.0 +0300 ||+++ src/arch/i386/core/realmode_asm.S 2021-05-09 01:25:42.042733352 +0300 |-- |File to patch: src/arch/i386/core/realmode_asm.S |src/arch/i386/core/realmode_asm.S: No such file or directory |Skip this patch? [y] |Skipping patch. |2 out of 2 hunks ignored |$ ls src/arch/i386/core/ |gdbidt.S nulltrap.c setjmp.S |$ Where originates the 2010 realmode_asm.S from? Groeten Geert Stappers -- Silence is hard to parse ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
Hi Geert, 08.05.2021 9:45, Geert Stappers: [...] What I've done is using prot_to_real implementation in current iPXE, I tried to mimic it as much as possible in respective place in Etherboot. "in Etherboot", so not in iPXE. Yes. And it is for a reason. Etherboot has been serving me for years as a workhorse, on a daily basis, on a lot of computers. And iPXE has not yet (and honestly I was not even aware of its existence until some few days ago) and testing it failed somewhat, due to a number of (non-fatal) problems discussed earlier. Any chance in dumping somewhere a rough / rude version of the made changes? No worries, it is basically a 5-liner, and I don't hide my bugfixes. Please see a diff file attached, but I think I'll fork a github repo to make it easier searchable and browsable. (I could also create a PR though it is unlikely going to be applied to a discontinued tree anyway) Same request in other words: Relief yourself from any quality demand and share you iPXE i80486 version.[1] As you might remember I reported that my attempts to run iPXE on real hardware failed more or less, although I've got an impression that with some effort it should be possible. Meanwhile, if you are willing to take the burden of preparing and submitting some 486-compatability patches upstream, you can use replies from Michael and Martin earlier in this thread as a source, and I'll appreciate that. My understanding is that iPXE does not suffer the peculiar problem I've just fixed in etherboot (in the attached diff), but simply employs some 586+ features in a couple of places. Probably I'll plan to test it eventually, as time permits, however funny thing is, I can not see any hardware target/compatability statement neither at ipxe.org nor in the source tree, which is a bit discouraging. Thank you, Regards, Nikolai --- src/arch/i386/core/realmode_asm.S 2010-09-05 23:47:29.0 +0300 +++ src/arch/i386/core/realmode_asm.S 2021-05-09 01:25:42.042733352 +0300 @@ -301,9 +301,11 @@ movl%eax, %ebx shrl$4, %ebx pushw %bx - leal3f(%ebp), %ebx + movw%bx, (p2r_ljmp_rm+3)(%ebp) + leal(p2r_ljmp_rm+5)(%ebp), %ebx subl%eax, %ebx pushw %bx + movw%bx, (p2r_ljmp_rm+1)(%ebp) /* Continuation address */ pushl $(p2r_rmcs - p2r_gdt) leal2f(%ebp), %ebx @@ -348,12 +350,21 @@ /* Make intersegment jmp to flush the processor pipeline * and reload %cs:%eip (to clear upper 16 bits of %eip). */ - lret -3: +p2r_ljmp_rm: + ljmp$0, $9f /* EA oo oo ss ss */ +9: /* Load real-mode segment value to %ss. %sp already OK */ shrl$4, %eax movw%ax, %ss + movzwl %sp, %esp + movw%ax, %ds + movw%ax, %es + movw%ax, %fs + movw%ax, %gs + + popw%bx + popw%bx /* Restore registers */ popl%eax ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
On Sat, May 08, 2021 at 04:03:50AM +0300, Nikolai Zhubr wrote: > Hi all, > > I've finished with the subject successfully. Yeah \o/ \o/\o/chear > What I've done is using prot_to_real implementation in current iPXE, I tried > to mimic it as much as possible in respective place in Etherboot. "in Etherboot", so not in iPXE. > That is: > > - use ljmp instead of lret (after cr0 change); > - assign ss and esp explicitely after that; > - assign all other segment registers explicitely. > > Then Etherboot works fine on 486. > > So iPXE's implementation is likely correct and supposedly it should work > too, as soon as all 586 opcodes are eliminated or handled carefully as > discussed previously. However my brain has pretty much exploded already > so I'm not going into more testing for now. Any chance in dumping somewhere a rough / rude version of the made changes? Same request in other words: Relief yourself from any quality demand and share you iPXE i80486 version.[1] > Thank you, Thank you for keeping us posted and especially on reporting "problem solved"[2] > Regards, > Nikolai Groeten Geert Stappers [1] I volunteer for converting "Here is my version" in a "git formatted patch". Feel free to contact me off-list. [2] I wish more people do that. -- Silence is hard to parse ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
Hi all, I've finished with the subject successfully. What I've done is using prot_to_real implementation in current iPXE, I tried to mimic it as much as possible in respective place in Etherboot. That is: - use ljmp instead of lret (after cr0 change); - assign ss and esp explicitely after that; - assign all other segment registers explicitely. Then Etherboot works fine on 486. So iPXE's implementation is likely correct and supposedly it should work too, as soon as all 586 opcodes are eliminated or handled carefully as discussed previously. However my brain has pretty much exploded already so I'm not going into more testing for now. Thank you, Regards, Nikolai ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
Hi all, After some more attempts with etherboot 5.4.4, it seems very likely some necessary flushing/resetting is missing in prot_to_real function. The prot_to_real still exists in iPXE, so I've tried to compare them. Look similar, although not identical. From what I vaguely remember, after a drop to real mode, some shadow registers might still hold unwanted obsolete values so explicite reloading might be necessary. Here in prot_to_real, cs:ip and pipeline apparently get reloaded by lret or ljmp correctly, but other registers I'm not sure, and these parts differ between iPXE and Etherboot. Maybe someone familiar with this code could give some hints, or better yet point to some good reference document describing considerations when switching modes on 386+ (I think I saw one years ago, but can't find it now). Thank you, Regards, Nikolai ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
Hi all,
I've got some more input on the subject.
First, unfortunately I could not get the patched current iPXE to load to
a real board, because the board is unaware of CD/USB booting, and using
an .hd and .usb image for harddisk resulted in either freezing at boot
or prompting to insert another one. Maybe its some disk geometry issue,
but whatever settings I chose in BIOS setup, it didn't help.
Now because "good old" etherboot 5.4.4 at least boots itself from
harddisk successfully, I tried debugging it, sort of. Observing that
freezing likely happens in pxe_call(), I inserted a couple of
tty-putchar fragments just before leaving real mode and shortly after
return to real mode within etherboot's service handler, basically like this:
movw$0x0E28, %ax
int $0x10
The actual characters were '(' and ')' so as to easily see the event of
no return. (Surrounding pushf/popf and push/pop ax were also inserted of
course)
And great surprise, beside showing the '()' series, it started
communicating! At some point it still freezed, but before that, it
managed to find and download my default config file.
Now this is both encouraging and scaring, as soon as the thing appears
that fragile. Anyway, at least CPU instruction set and memory layout
errors (E820 or otherwise) can probably be sorted out right away.
Apparently it is something more dynamic, like caching/flushing/timing or
maybe something to do with unwanted higher halves of 32-bit registers in
real mode. Pretty puzzling.
I appologise for bugging you with ancient etherboot, please ignore if it
is too much off topic. I'm just not sure how to proceed yet.
Thank you,
Regards,
Nikolai
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
The CPUID opcode also does not exist on i486. See arch/x86/include/ipxe/cpuid.h I think iPXE will cope with this if it calls cpuid_supported() in the right places. New i586 opcodes are at: https://en.wikipedia.org/wiki/X86_instruction_listings#Added_with_Pentium Martin On Wed, May 05, 2021 at 08:13:39PM +0100, Michael Brown wrote: > On 05/05/2021 19:53, Nikolai Zhubr wrote: > > Thanks for mentioning Bochs, I've copied your 486 config commandline and > > was able to build and start testing. Its way more handy than with real > > iron. It is even possible to disable e820 function by hand. > > > > Now as long as 586+ requirement is not really critical for operation, > > maybe put such fragments into conditional ifdefs and introduce some > > config option (say LEGACY486) to allow 486-compatible builds? > > I've gone to a *lot* of effort over the past 15 years to eliminate that kind > of conditional ifdef from the codebase (see the various "#ifdef considered > harmful" articles around the web). > > For unlzma.S, just changing to ".arch i486" is fine, since there are no > 586-class instructions in that file. > > For undinet.c, the "rdtsc" instructions are used only for profiling. It's > probably not worth the marginally increased accuracy from having the rdtsc > within the real-mode code: those TSC reads could be moved outside the > REAL_CODE() block and implemented using the standard profile_xxx() functions > instead of hardcoded "rdtsc" instructions. (An alternative approach would > be to conditionalise the presence of the "rdtsc" instructions, but it would > need to be an exceptionally neat solution to justify such a special case.) > > For rtc_entropy.c, the use of the TSC is intrinsic to the way that the code > operates. There is already an entropy_enable() call that is allowed to > return an error to indicate that the entropy source is unusable: this could > be extended to include a low-overhead check for the existence of the TSC. > > With those changes, there would be no need for any compile-time option or > accompanying documentation: the code would Just Work on a 486. > > Michael > ___ > ipxe-devel mailing list > ipxe-devel@lists.ipxe.org > https://lists.ipxe.org/mailman/listinfo/ipxe-devel ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
Hi Michael, Ok, understood. I'll probably not be able to implement it myself anyway, but I'll certainly appreciate if someone does. Thank you, Regards, Nikolai 05.05.2021 22:13, Michael Brown: [...] I've gone to a *lot* of effort over the past 15 years to eliminate that kind of conditional ifdef from the codebase (see the various "#ifdef considered harmful" articles around the web). For unlzma.S, just changing to ".arch i486" is fine, since there are no 586-class instructions in that file. For undinet.c, the "rdtsc" instructions are used only for profiling. It's probably not worth the marginally increased accuracy from having the rdtsc within the real-mode code: those TSC reads could be moved outside the REAL_CODE() block and implemented using the standard profile_xxx() functions instead of hardcoded "rdtsc" instructions. (An alternative approach would be to conditionalise the presence of the "rdtsc" instructions, but it would need to be an exceptionally neat solution to justify such a special case.) For rtc_entropy.c, the use of the TSC is intrinsic to the way that the code operates. There is already an entropy_enable() call that is allowed to return an error to indicate that the entropy source is unusable: this could be extended to include a low-overhead check for the existence of the TSC. With those changes, there would be no need for any compile-time option or accompanying documentation: the code would Just Work on a 486. Michael ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
On 05/05/2021 19:53, Nikolai Zhubr wrote: Thanks for mentioning Bochs, I've copied your 486 config commandline and was able to build and start testing. Its way more handy than with real iron. It is even possible to disable e820 function by hand. Now as long as 586+ requirement is not really critical for operation, maybe put such fragments into conditional ifdefs and introduce some config option (say LEGACY486) to allow 486-compatible builds? I've gone to a *lot* of effort over the past 15 years to eliminate that kind of conditional ifdef from the codebase (see the various "#ifdef considered harmful" articles around the web). For unlzma.S, just changing to ".arch i486" is fine, since there are no 586-class instructions in that file. For undinet.c, the "rdtsc" instructions are used only for profiling. It's probably not worth the marginally increased accuracy from having the rdtsc within the real-mode code: those TSC reads could be moved outside the REAL_CODE() block and implemented using the standard profile_xxx() functions instead of hardcoded "rdtsc" instructions. (An alternative approach would be to conditionalise the presence of the "rdtsc" instructions, but it would need to be an exceptionally neat solution to justify such a special case.) For rtc_entropy.c, the use of the TSC is intrinsic to the way that the code operates. There is already an entropy_enable() call that is allowed to return an error to indicate that the entropy source is unusable: this could be extended to include a low-overhead check for the existence of the TSC. With those changes, there would be no need for any compile-time option or accompanying documentation: the code would Just Work on a 486. Michael ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
Hi Michael, Thanks for mentioning Bochs, I've copied your 486 config commandline and was able to build and start testing. Its way more handy than with real iron. It is even possible to disable e820 function by hand. Now as long as 586+ requirement is not really critical for operation, maybe put such fragments into conditional ifdefs and introduce some config option (say LEGACY486) to allow 486-compatible builds? 486s are still not uncommon in production and network boot is quite usefull in such environments. Still no result with my 8139 problem yet, but at least I now have a convenient testing environment. Thank you, Regards, Nikolai 05.05.2021 15:18, Michael Brown: A quick test indicates that unlzma.S will still build with ".arch i486". AFAICT the only non-i386 instruction in there is "bswap", which should exist on a 486. I did some quick testing in bochs configured for a 486 using: ./configure --enable-a20-pin --disable-x86_64 --enable-cpu-level=4 \ --enable-pci --enable-e1000 --enable-debugger \ --disable-debugger-gui --enable-readline \ --enable-all-optimizations --enable-cdrom --disable-smp This showed that iPXE is getting stuck on the "rdtsc" instruction, which is an undefined opcode on i486. The rdtsc-based timer isn't causing the problem: the code in rdtsc_probe() already checks for an invariant TSC (which isn't present on i486) and so never issues the rdtsc instruction. There are two remaining uses: in undinet_call() where the TSC value gets used only for profiling, and in rtc_sample() where the TSC value gets used as part of entropy generation. Commenting out these instructions (via the attached patch) gave me an iPXE binary that worked fine on i486. Michael ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
On 05/05/2021 07:54, Martin Habets wrote:
Long ago Etherboot used to be i386 code.
Nowadays I think iPXE only runs on i586 or later,
e.g. arch/x86/prefix/unlzma.S has:
.arch i586
From memory there are a couple of places in the code where
iPXE uses assembler opcodes that don't exist in 486.
Your best bet is probably using the old Etherboot code base and
debug/patch that.
A quick test indicates that unlzma.S will still build with ".arch i486".
AFAICT the only non-i386 instruction in there is "bswap", which should
exist on a 486.
I did some quick testing in bochs configured for a 486 using:
./configure --enable-a20-pin --disable-x86_64 --enable-cpu-level=4 \
--enable-pci --enable-e1000 --enable-debugger \
--disable-debugger-gui --enable-readline \
--enable-all-optimizations --enable-cdrom --disable-smp
This showed that iPXE is getting stuck on the "rdtsc" instruction, which
is an undefined opcode on i486.
The rdtsc-based timer isn't causing the problem: the code in
rdtsc_probe() already checks for an invariant TSC (which isn't present
on i486) and so never issues the rdtsc instruction.
There are two remaining uses: in undinet_call() where the TSC value gets
used only for profiling, and in rtc_sample() where the TSC value gets
used as part of entropy generation.
Commenting out these instructions (via the attached patch) gave me an
iPXE binary that worked fine on i486.
Michael
diff --git a/src/arch/x86/drivers/net/undinet.c b/src/arch/x86/drivers/net/undinet.c
index 9b7d6d849..de6f4aa66 100644
--- a/src/arch/x86/drivers/net/undinet.c
+++ b/src/arch/x86/drivers/net/undinet.c
@@ -288,14 +288,14 @@ static int undinet_call ( struct undi_nic *undinic, unsigned int function,
*/
profile_start ( &profiler->total );
__asm__ __volatile__ ( REAL_CODE ( "pushl %%ebp\n\t" /* gcc bug */
- "rdtsc\n\t"
+ //"rdtsc\n\t"
"pushl %%eax\n\t"
"pushw %%es\n\t"
"pushw %%di\n\t"
"pushw %%bx\n\t"
"lcall *undinet_entry_point\n\t"
"movw %%ax, %%bx\n\t"
- "rdtsc\n\t"
+ //"rdtsc\n\t"
"addw $6, %%sp\n\t"
"popl %%edx\n\t"
"popl %%ebp\n\t" /* gcc bug */ )
diff --git a/src/arch/x86/interface/pcbios/rtc_entropy.c b/src/arch/x86/interface/pcbios/rtc_entropy.c
index e9e6baa59..428397968 100644
--- a/src/arch/x86/interface/pcbios/rtc_entropy.c
+++ b/src/arch/x86/interface/pcbios/rtc_entropy.c
@@ -226,7 +226,7 @@ uint8_t rtc_sample ( void ) {
"testb %b2, %b2\n\t"
"jz 1b\n\t"
/* Read "before" TSC */
- "rdtsc\n\t"
+ //"rdtsc\n\t"
/* Store "before" TSC on stack */
"pushl %0\n\t"
/* Wait for another RTC interrupt */
@@ -237,7 +237,7 @@ uint8_t rtc_sample ( void ) {
"testb %b2, %b2\n\t"
"jz 1b\n\t"
/* Read "after" TSC */
- "rdtsc\n\t"
+ //"rdtsc\n\t"
/* Retrieve "before" TSC on stack */
"popl %1\n\t"
/* Disable interrupts */
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
Hi Martin, Thanks for pointing to .arch i586, it'd otherwise take some time for me to find it. Its strange the Pentium+ requirement is not stated somewhere one could see it immediately. The FAQ implies "what does the 'i' in 'iPXE' stand for" and such similar questions are more essential. Anyways. Yes, I'm now thinking it would be more usefull to get back to Etherboot and try to fix issues there. At least it is able to get to the point of trying to start pxelinux. The negative side is it is abandonware. I hope though someone on this list could be involved in Etherboot back then and still might remember something about it, in case I get to some extreme complications and need help again :-) Thank you, Regards, Nikolai 05.05.2021 9:54, Martin Habets: Long ago Etherboot used to be i386 code. Nowadays I think iPXE only runs on i586 or later, e.g. arch/x86/prefix/unlzma.S has: .arch i586 From memory there are a couple of places in the code where iPXE uses assembler opcodes that don't exist in 486. Your best bet is probably using the old Etherboot code base and debug/patch that. Martin ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
Long ago Etherboot used to be i386 code. Nowadays I think iPXE only runs on i586 or later, e.g. arch/x86/prefix/unlzma.S has: .arch i586 >From memory there are a couple of places in the code where iPXE uses assembler opcodes that don't exist in 486. Your best bet is probably using the old Etherboot code base and debug/patch that. Martin On Wed, May 05, 2021 at 01:37:46AM +0300, Nikolai Zhubr wrote: > Hi all, > > I'm having some trouble getting a Realtek 8139 card to boot successfully on > a 486 box. > > Long ago I made an rtl8139 rom using Etherboot project and flashed it into a > number of EEPROM chips. I found them working fine with all systems I tried > starting Pentium1. However, 486s had problems. Basically, pxelinux failed to > run somehow, whereas if using Realtek's official ROM blob, pxelinux started > successfully. Now I'm trying to workaround/fix/understand the issue. > > My new idea was to chainload most current 8139 native image built from iPXE > to see if it runs well on 486. Unfortunately, it does not: > > = Screenshot == > Loading 192.168.0.99:10ec8139.pxe ...(PXE)done > PXE->EB: !PXE at 9F40:, entry point at 9F40:0680 > UNDI code segment 9F40:0AAD, data segment 9E40:1000 (633-640kB) > UNDI device is PCI 00:0E.0, type Etherboot (workaround enabled) > 640kB free base memory after PXE unload > (nothing happens after that line, like completely hanging) > === > > Supposedly there should not be any Pentium+ dependancies, right? > Any other hints before I start digging through? > > > Thank you, > > Regards, > Nikolai > ___ > ipxe-devel mailing list > ipxe-devel@lists.ipxe.org > https://lists.ipxe.org/mailman/listinfo/ipxe-devel ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
Hi, 05.05.2021 1:55, Christian Iwata Nilsson: [...] Have you tried any build with #undef TIVOLI_VMM_WORKAROUND? Just tried after your hint. No difference here. I'm suspecting some memory management issue. This specific BIOS totally lacks E820 function, which made it necessary e.g. to patch some bugs in grub for it to work. (However, linux runs fine out of the box apparently) I could not figure how to enable all those beautifull DBG() things. Probably they could help somewhat. The manual says about DEBUG=scsi but I'm not really interested in scsi yet, and building with just "make bin/10ec8139.pxe DEBUG=2" fails saying "No rule to make target 'bin/2.dbg1.o'", same fail with DEBUG=1. Puzzled. Thank you, Regards, Nikolai ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
Re: [ipxe-devel] 486 with a Realtek 8139
On Wed, 5 May 2021, 00:28 Nikolai Zhubr, wrote: > Hi all, > > I'm having some trouble getting a Realtek 8139 card to boot successfully > on a 486 box. > > Long ago I made an rtl8139 rom using Etherboot project and flashed it > into a number of EEPROM chips. I found them working fine with all > systems I tried starting Pentium1. However, 486s had problems. > Basically, pxelinux failed to run somehow, whereas if using Realtek's > official ROM blob, pxelinux started successfully. Now I'm trying to > workaround/fix/understand the issue. > > My new idea was to chainload most current 8139 native image built from > iPXE to see if it runs well on 486. Unfortunately, it does not: > > = Screenshot == > Loading 192.168.0.99:10ec8139.pxe ...(PXE)done > PXE->EB: !PXE at 9F40:, entry point at 9F40:0680 > UNDI code segment 9F40:0AAD, data segment 9E40:1000 (633-640kB) > UNDI device is PCI 00:0E.0, type Etherboot (workaround enabled) > 640kB free base memory after PXE unload > (nothing happens after that line, like completely hanging) > === > > Supposedly there should not be any Pentium+ dependancies, right? > Any other hints before I start digging through? > > > Thank you, > > Regards, > Nikolai > > Have you tried any build with #undef TIVOLI_VMM_WORKAROUND? ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
