[Galaxy Note 4 Android Development (Snapdragon)] fattire:
This is great news. I'm gonna take this as confirmation that the fix is working for everyone :)

I'm not sure if this is what you guys are talking about but aboot is an android bootloader which I think came from "little kernel" (lk) project. I think it's the bootloader used to allow flashing w/fastboot and to choose whether to start the recovery or system boot. Here's the google source for it, but Samsung I guess modifies it for use w/odin rather than fastboot and does other things. Like things the Samsung-specific bootloader needs to do is throw up the Samsung "Note 4" logo, see if it's booting in secure mode, check the signature of the boot.img, set up KNOX stuff, etc.

Another popular bootloader which I'm more familiar with is u-boot, which I modified heavily for the Nook Color/Tablet back in the day.

In case anyone was wondering what a "bootloader" is/does, basically when you turn the power on on a phone, the hardware needs to start loading the operating system somewhere-- so the first bit of code that loads from the emmc--even before the linux kernel-- is this small piece of software-- the bootloader-- whose job it is to initialize ("bring up") bits of hardware, maybe show a splash screen, then decide which boot image (boot.img or recovery.img-- a partition containing the kernel & a ramdisk full of boot instructions + adbd) to load next. It makes this decision in part on whether it detects special keys are being held down or if some state has been pre-set via a "reboot to recovery" command.

A bootloader also may have a special mode that lets you reflash certain partitions (say, via fastboot), and it may flat-out refuse to load certain bootimages, if say, they are not signed by the manufacturer (a "locked" bootloader) by sending commands via USB. The bootloader code itself may have been signed and include a signature -- and the hardware may refuse to start an unsigned or mis-signed bootloader. This "chain of trust" where the hardware checks the bootloader, the bootloader checks the boot.img (incl. the kernel), and then the kernel checks the operating system (/system) it runs via dm-verity is supposed to guarantee that no one has tampered with the device from power-on to when the system finishes loading.

[power on] --loads-> [bootloader] --loads-->[kernel/init.rc boot instructions (in boot.img)] --loads--> [Android (in /system)]

but if you hold keys down it might go...

[power on] --loads-> [bootloader] --loads-->[kernel/recovery stuff (in recovery.img]

or maybe other keys held down might go...

[power on] --loads-> [bootloader--waits for fastboot commands to flash stuff]

or even...

[power on] --loads-> [bootloader--show menu to say 'do you want to unlock this device?' and unlock/wipe everything if you say "yes"]

A locked bootloader may also prohibit running your own modified OS (like lineageos) requiring that you go through an "unlock" process. So many bootloaders also manage this functionality-- offering a mode where it doesn't care if the boot image (boot.img) is signed or not, and hopefully displaying something on screen to the effect that this system has been modified so you know the chain of trust has been been broken.

Anyhoo. There ya go.