On Fri, Apr 07, 2023 at 12:05:27PM +, Emmanuel Dreyfus wrote:
> The other solution is to make the kernel self-relocatable: if at
> start in locore.S, we detect we are not loaded at 0x20, then
> first relocate the kernel. This can be done by reusing bootx64.efi's
> startprog64(). There was
On Fri, Apr 07, 2023 at 03:18:21PM +0200, Martin Husemann wrote:
> Just to be sure: you did rebuild and update bootx64.efi afterwards?
> (Not accidently only the kernel)
Yes, and I am certain I run the updated bootloader since I added
many printf in it.
> This change (at least in my minimal
On Fri, Apr 07, 2023 at 12:05:27PM +, Emmanuel Dreyfus wrote:
> On Thu, Apr 06, 2023 at 05:08:34PM +0200, Martin Husemann wrote:
> > I wonder if tuning EFI_ALLOCATE_MAX_ADDRESS in
> > src/sys/arch/i386/stand/efiboot/Makefile.efiboot would be enough.
>
> No success. Here is my conclusions so
On Thu, Apr 06, 2023 at 05:08:34PM +0200, Martin Husemann wrote:
> I wonder if tuning EFI_ALLOCATE_MAX_ADDRESS in
> src/sys/arch/i386/stand/efiboot/Makefile.efiboot would be enough.
No success. Here is my conclusions so far:
At kernel start time, the kernel assumes it is loaded at 0x20,
but
On Thu, Apr 06, 2023 at 04:13:45PM +, Emmanuel Dreyfus wrote:
> If I understand correctly, chaning EFI_ALLOCATE_MAX_ADDRESS
> will change efi_loadaddr, which means it will only change
> the source address for startprog64(), not the destination.
I am not sure, but I thought the efi code would
On Thu, Apr 06, 2023 at 05:08:34PM +0200, Martin Husemann wrote:
> I wonder if tuning EFI_ALLOCATE_MAX_ADDRESS in
> src/sys/arch/i386/stand/efiboot/Makefile.efiboot would be enough.
I will test that, but I am not convinced it can help.
The crash happens in startprog64(), where the kernel is
I wonder if tuning EFI_ALLOCATE_MAX_ADDRESS in
src/sys/arch/i386/stand/efiboot/Makefile.efiboot would be enough.
Martin
On Wed, Apr 05, 2023 at 08:16:13AM +, Emmanuel Dreyfus wrote:
> Inspecting EFI memory map, I now understand why: the kernel
> is too big to fit in the coventional memory mapping where
> bootstrap code attempts to copy it.
In bootstrap, memmap says (a few leading zeros removed
for the sake of
On Wed, Apr 05, 2023 at 06:47:58AM +, Emmanuel Dreyfus wrote:
> Bootstrap code looses ground on rep movsq or rep movsb
> instructions.
Inspecting EFI memory map, I now understand why: the kernel
is too big to fit in the coventional memory mapping where
bootstrap code attempts to copy it.
On Wed, Apr 05, 2023 at 06:47:58AM +, Emmanuel Dreyfus wrote:
> On Tue, Apr 04, 2023 at 09:04:02PM +0200, Joerg Sonnenberger wrote:
> > Look for beep_on_reset in the ACPI wake code. If your machine has a PC
> > speaker emulated, that might be the easiest option:
>
> This is brilliant!
>
> I
On Tue, Apr 04, 2023 at 09:04:02PM +0200, Joerg Sonnenberger wrote:
> Look for beep_on_reset in the ACPI wake code. If your machine has a PC
> speaker emulated, that might be the easiest option:
This is brilliant!
I moved the beep code at various places in startprog64 in
Am Tue, Apr 04, 2023 at 08:30:51AM + schrieb Emmanuel Dreyfus:
> Debugging what happens after that is more tricky. This is assembly
> code, I am not sure I can printf from there. I try to make the
> machine reboot at startprog64() start to see if I just reach that
> place.
Look for
On Wed, Jan 11, 2023 at 08:30:20AM +, Emmanuel Dreyfus wrote:
> An interesting problem on an all-in-one HP PC. Booting
> NetBSD-10.0_BETA/amd64 (or prior versions) works fine until the
> kernel starts displaying its messages. At that point the screen
> turns dark.
So far, the thing seems to
Le 16/01/2023 à 10:38, Emmanuel Dreyfus a écrit :
On Mon, Jan 16, 2023 at 09:08:20AM +, Emmanuel Dreyfus wrote:
On Mon, Jan 16, 2023 at 06:50:18AM +, Emmanuel Dreyfus wrote:
Clearly broken firmware - is there an update available?
Perhaps I can have more luck booting through grub, I
Le Tue, Feb 21, 2023 at 10:00:10AM -0400, Jared McNeill a écrit :
> Yeah sorry you can?t just not exit boot services and boot the OS. UEFI code
> has certain expectations around the execution environment (MMU on, 1:1 PA to
> VA for example) that starting the kernel is going to interfere with.
On Tue, Feb 21, 2023 at 10:00:10AM -0400, Jared McNeill wrote:
> Yeah sorry you can?t just not exit boot services and boot the OS.
Sure, it just helps finding out what happens if it crashes early during
bootstrap.
--
Emmanuel Dreyfus
m...@netbsd.org
Yeah sorry you can’t just not exit boot services and boot the OS. UEFI code has
certain expectations around the execution environment (MMU on, 1:1 PA to VA for
example) that starting the kernel is going to interfere with. The moment the
kernel touches the MMU, all of the resident UEFI code will
On Tue, Feb 21, 2023 at 08:05:00AM -0400, Jared McNeill wrote:
> After calling ExitBootServices(), the only things that work are UEFI runtime
> services. You'll have to find another way to print to the console.
I can skip the ExitBootServices call and keep printing, I have already
done thatn at
After calling ExitBootServices(), the only things that work are UEFI
runtime services. You'll have to find another way to print to the console.
On Mon, 20 Feb 2023, Emmanuel Dreyfus wrote:
On Wed, Jan 11, 2023 at 08:30:20AM +, Emmanuel Dreyfus wrote:
An interesting problem on an
On Mon, Feb 20, 2023 at 09:52:53AM +, Emmanuel Dreyfus wrote:
> I patched bootx64.efi to comment out the vbe_commit() call,
> the screen does not go dark, but system still crashes.
And if I let vbe_commit() proceed and printf() just after that,
I get the output (with topleft in the middle
On Wed, Jan 11, 2023 at 08:30:20AM +, Emmanuel Dreyfus wrote:
> An interesting problem on an all-in-one HP PC. Booting
> NetBSD-10.0_BETA/amd64 (or prior versions) works fine until the
> kernel starts displaying its messages. At that point the screen
> turns dark.
I patched bootx64.efi to
On Mon, Jan 16, 2023 at 09:08:20AM +, Emmanuel Dreyfus wrote:
> On Mon, Jan 16, 2023 at 06:50:18AM +, Emmanuel Dreyfus wrote:
> > > Clearly broken firmware - is there an update available?
> > Perhaps I can have more luck booting through grub, I will
> > try that.
>
> Same problem, grub
On Thu, Jan 12, 2023 at 02:02:30PM +, Emmanuel Dreyfus wrote:
> It goes dark when kernel starts displaying, before DRM takes over,
> hence userconf is not usable.
Can you play with different gop commands?
This sounds like broken firmware to me.
Martin
eon, disable nouveau, and get dmesg
> from the previous boot?
It goes dark when kernel starts displaying, before DRM takes over,
hence userconf is not usable.
--
Emmanuel Dreyfus
m...@netbsd.org
> Date: Wed, 11 Jan 2023 08:30:20 +
> From: Emmanuel Dreyfus
>
> An interesting problem on an all-in-one HP PC. Booting
> NetBSD-10.0_BETA/amd64 (or prior versions) works fine until the
> kernel starts displaying its messages. At that point the screen
> turns dark.
Do you have serial
m...@netbsd.org (Emmanuel Dreyfus) writes:
>I suspect a mode problem. In the boot prompt, gop displays:
>*0: 1920x1080 BGRR pitch 1920 bpp 32
> 1: 640x480 BGRR pitch 640 bpp 32
> 2: 800x600 BGRR pitch 800 bpp 32
> 3: 1024x768 BGRR pitch 1024 bpp 32
> 4: 1280x1024 BGRR pitch 1280 bpp 32
>Trying
Hello
An interesting problem on an all-in-one HP PC. Booting
NetBSD-10.0_BETA/amd64 (or prior versions) works fine until the
kernel starts displaying its messages. At that point the screen
turns dark.
I suspect a mode problem. In the boot prompt, gop displays:
*0: 1920x1080 BGRR pitch 1920 bpp
27 matches
Mail list logo
