Location of FrameBuffer-to-vesa Setting

Ok, did some more poking around.

This variable can also be enabled from the kernel settings file. So make sure it’s disabled there (checking the obvious things, ju#t in case)

I think the other option is if the accelerant somehow fails to initialize? I think I saw some logs (from the radeon driver maybe?) where the accelerant would be loaded, but detegt no screens, return an error, and then app_server would eventually try to fallback to vesa. But it could also happen because of missing symbols, trying to use a 32bit accelerant in a 64bit system, or anything else that would prevent the accelerant from starting.

Unfortunately as i said already in the ticket it always crashes without writing to syslog, tried several times it never does?? sorry, i know it’s not very helpfull without it.

Thanks:

  • 64bit confirmed OK
  • both kerneldriver and accelerant from same build, so should be OK (no missing symbols in syslog, I’ve seen that this indeed can happen on other occasions)
  • The accelerant never gets called or there would be a syslog entry. Besides, the vesa accelerant gets called before the intel driver gets loaded. Also, this same usb stick boots 64-bit non UEFI nicely to the intel driver/accelerant desktop (Ivy bridge).
  • No failsafe mode set in the kernel settings file.

I have another question myself:

  • Can you or someone else confirm that a 64-bit UEFI boot indeed works with another driver than the vesa driver??

Thanks a lot…

Thanks for link. Maybe it is better to revert change and keep separate framebuffer driver. It is strange to have VESA driver with old DOS code on RISC-V (and possibly ARM) that is used only for framebuffer and the rest code is not functional and not used.

2 Likes

I use the radeon_hd driver with efi on 64bit arch, albeit in 16bit color, I can provide a syslog if you would like.

1 Like

Hmm, ok. Very good to know :relaxed: strange… so I will poke around some more in another direction then…

The syslog is not needed I think. Thanks for responding!

Hello,
After some more testing I came to the conclusion I now need to lose the packagefs thing so I can freely add/remove/modify literally all aspects of haiku.
I tried a few things already, but I couldn’t manage yet.
Can anyone explain howto get rid of the read-only filesystem with the packages? I want an old-fashioned BeOS so to speak to continue my testing… :thinking:

AFAIK you can boot from a different disk and extract the packages to your target drive.

Hmm. Already tried that… Or do I need to do something extra-special if it concerns a (uefi) 64-bit version?

I was able to relocate the efi partition to the end of my usb stick, place the files back on it and succesfully boot the Haiku on the other partion: but deleting and recreating that partition with the same files as were there when booted did not work… Won’t boot.

Testing new drivers is kind of harder than it should be, but some of it is just knowing the tricks. Trying to get rid of the package system is probably more work than learning some of the tricks. In my brief experience when working on the HDA driver you have to blacklist the system driver and make sure your test driver is in the correct location under non-packaged. I also think I had to set up a symlink but I cannot remember the details.

I also wonder if trying to get the PXE network boot working again would be worth it to ease your testing? Though that adds more work too. I don’t know what is currently wrong there but I think it would be nice if it worked again.

One thing that I do and that works reasonably well is rebuilding just the haiku package.

jam -q haiku.hpkg
pkgman install generated/objects/.../haiku.hpkg

Then reboot and test. No need to have blacklist and all these complicated things. And if you broke everything, you can easily boot back to an older version from the bootloader and try again.

I do not find that “harder than it should be”, do you? Now I don’t even have to know the path where the driver is installed :sunglasses:

2 Likes

Thanks for the pointers, still my question remains. Or is it not possible at all without too much hassle?

I have additional problems where I even want to change app_server for instance along with blacklisted drivers, but without needing the startmenu (that fails over here: no kb support if internal (works after boot though), and if I add a usb keyboard I get a systematically boot-crash at icon 4: no boot partitions found. This is (probably) due to a power problem on the USB bus: this problem also happens if the system starts-up too fast: apparantly the usb power needs some (hundreds) millilseconds to relay enough power to the USB host. This delay is probably wise to add somewhere as well, I can imagine more systems have this problem, especially tablet or so like stuff.

When I look at this from an electronics standpoint, I’d say the power is switched on, but some capacitor is not fully charged yet, making too much power draw too soon make usb devices fail.

Anyhow: I need a combination of tricks to be able to continue I hope I made clear with this story :slight_smile:

3 Likes

IIRC you need to copy your /system and /boot/home folder to another bfs partition, delete everything in system/packages except for haiku_loader.hpkg and boot from this new partition.
I haven’t tried it myself, tho.

You can try to boot with Clover, it can Patch various usb relaxed problems. AFAIK it can delay the usb initialization too.

Btw I used the haiku.hpkg trick to test the app_server fix this morning.

Do you have to work on the same machine? Maybe you could scp haiku.hpkg to it ?

You can extract all packages to /boot/system directory and delete /boot/system/packages. I use that for testing Haiku RISC-V port, files are updated with a script. If you want to do this, I recommend to create separate disk/partition for testing because it breaks package installation.

Rebuilding haiku.hpkg takes much more time than compiling and copying just one file. Speed is important when testing, it allows to do more test cycles at the same period of time.

5 Likes

Thanks everyone for all the hints, gives me a lot more to try… I will keep you posted :slight_smile:
Well, I guess in the meantime approx 8 systems are lying around here, just added three more from my employer. Really cool, grabbed them literally from the old scrap bin (among others a samsung laptop which still had some juice but no hd). It’s so cool to just plug in my 1Gb 50 cent Haiku stick and stand next to the bin with a working Haiku desktop within half a minute! :heart_eyes:

Anyhow, I’ll stay focussed on the 64bit boot on the microsoft surface for now to see if the intel driver will run on that (in the end)…

thanks again!

10 Likes

I’d recommend getting the EFI app from an older version of Haiku. I’m not sure but it may try to do package validation on boot now.