Haiku activity report - November and December 2020 | Haiku Project

Blog
1

Welcome to the November-December activity report!

This report covers hrev54716-hrev54805 (about 5 weeks of work).

This is a companion discussion topic for the original entry at https://www.haiku-os.org/blog/pulkomandy/2020-12-22-haiku_activity_report_november_december_2020/
10 Likes
2

Thanks for the report, seems the number of committers is growing, that’s nice!

1 Like
3

The IOCache patch is from mark_mcs.

4

Thanks, fixed.

5

Thanks for the report, always appreciated.

6

Anyone else experiencing the following since user interface updates?

Folder has focus:
Bitmap Clip

without focus:
Bitmap Clip 2

Notice that the selected file in the home folder has gone completely gray (unreadeable). This was not happening until I changed the active window border to same color as active tab.

7

That must’ve been a coincidinc.
There’s ticket #16627 for this already.

8

Thanks for the report I was very happy to see Wonderbrush 64bit is there now, and the bug fixing was so fast thx…

9

Regarding the ARM port issues, has UEFI any advantage over a simple uboot making the hf troubles worthwhile?

So far all the ARM ventures I undertook never relied on any kind of EFI, and in my kind of perception EFIs are usually quite overcomplicated huge blobs (closed or open source depending on SOC support)

10

Many advantages.
First, it’s the default thing on arm64. Second, we already have a working uefi code. Third, it provides an actual environment with support for our bootloader, so we can show things on screen, load the kernel from disk, and all things our bootloader does, without having to add hardware specific drivers to our bootloader.

Linux works around this by loading the kernel directly with a ramdisk including drivers, they don’t have their own specific stage 2 bootloader.

We don’t really want to go that way because the bootloader has some important features in our case (passing arguments to the kernel which are a binary data structure, setting up the mmu, the bootmenu allowing to enable failsafe mode and boot older versions, etc).

U-boot is too minimal for our firmware needs.

Also, uboot does provide an efi implementation, whichis opensource and not blob at all. It’s just an api that allows our bootloader to talk with the firmware and that’s the minimum we can expect from any other platform as well.

1 Like