Not sure why this was never pushed and how the pr adding support for begonia was accepted without this.
Signed-off-by: Umer Uddin <umer.uddin@mentallysanemainliners.org>
For conveniency, stack_bottom points to the end of the stack region in the
linker file as it grows backwards on arm:
.stack ALIGN(0x1000) : {
__stack_top = .;
. += 0x1000;
__stack_bottom = .;
}
However, we have somehow missed that and STILL made sp point to __stack_top,
which makes it grow backwards into .bss... oops, lol. Tested on qemu-virt set
to use cortex-a15.
For a while now, both simple-framebuffer and uart were hard-wired to
the debug library. You could alternate between each or have both running,
but the implementation was really ugly - ifdefs based on whether uart/simplefb
are compiled in or not.
As uniLoader has advanced enough to feature a sane-ish probing system for
drivers, we can start experimenting with things like:
- multiple framebuffers / UART devices
- support for more complex peripherals (USB, storage)
- multiple boot paths
Hence registering output sinks as console devices, just like how u-boot and
linux do, is a feature we should've had a long while ago. So let's begin working
on that by decoupling framebuffer and uart from the "debug" interface in uni and
rather allowing the registering of such sinks as "console" devices.
With that, make the simple-framebuffer driver handle the debug level colors as
well as the message assembling and writing to the framebuffer. That fully detaches
it from the debug interface, as all that is required now is to invoke console_register()
with the appropriate struct passed as an argument.
As the drivers for output sinks are now responsible for the formatting of the messages,
their set-up and writing, UART can be implemented as a sole driver as well. However,
drivers register late in the boot process (after assembly, board early_initand other
drivers with higher priority). With that in mind and all the leftover UART puts/c code in
board files for several of the currently supported devices, introduce an early console
path dedicated for debugging via UART.
Looking at the currently supported devices, the only one requiring set-up before
being able to output to UART is lucky7. For ease of use, make early_console_init
weak, allowing it to be overrided by board files such as board-lucky7.
Lastly, debug -> console, as that more correctly addresses the purpose of the library
now.
The current drivers/framework.c is useless, as REGISTER_DRIVER() is a macro
that just directly calls the driver probe function. Every board file has to
reference each driver's probe function by name. This was just done to make room
for proper driver probing in the future, where we are now, so implement that.
Make drivers self-register at link time by emitting a struct driver into a
.uniloader_drivers section via DRIVER_REGISTER(). The linker brackets
the section with __drivers_start / __drivers_end symbols.
Boards describe their hardware as a static struct with the format
{ driver_name, plat_data, label }. Remove the drivers_init hook from
struct board_ops as it's no longer necessary.
The drivers probe will now be placed between early_init and splash.
The framework looks up each device's driver_name up in the
linker section and calls probe(plat_data). A failed probe is logged.
Do --whole-archive as well to convince the linker to not drop the drivers
in archived .o files that aren't called outside the archive.
Adopt all boards to use the framework.
All of the changes in this commit are co-dependent on each other, as we're
doing a large change to the ABI.
get_font_scale_factor() unconditionally dereferences fb_info and debug.c's
fb_output() calls get_font_scale_factor() on each printk call, even before
we have simplefb registered. As __simplefb_raw_print has a check if we're
past simplefb probe (fb_info is filled), do the same for get_font_scale_factor()
and return 1 (not scaled) if the struct is not filled.
The value 5 appeared bare in two places: simplefb.c (when text wraps
past the bottom of the screen) and debug.c (initial y position for
the printk overlay). Replace both with FB_TEXT_TOP_PADDING defined
once in simplefb.h.
The toolchain emits several sections that have no meaning for a flat
binary bootloader:
.eh_frame DWARF unwind tables (we never unwind)
.note.gnu.property BTI/PAC ELF markers (lost at objcopy)
.note.gnu.build-id debug identity (lost at objcopy)
.comment compiler version string
.ARM.attributes ABI metadata
Gcc emits roughly 7-8 KB of .eh_frame by default for a build of this
size; the others are smaller but equally pointless. Just drop all of
them in the linker scripts.
Net effect on dreamlte_defconfig w/ empty embedded blobs:
61960 -> ~54000 bytes. Stonks.
ALIGN(4) is left over from 32-bit linker script templates. On
aarch64 the natural pointer/long alignment is 8, and these sections
usually contain 64-bit constants (pointer tables, 64-bit literals). The
4-byte alignment was harmless because the linker happens to align
individual symbols anyway, but let's just align it properly for the
sake of correctness. For BSS also ensure we have extra padding before
the end of the section.
Several boards call readl()/writel() or use uint32_t but do not include
<string.h> (which is where unic declares these). They build today only
because <drivers/framework.h> pulls <string.h> in.
The framework header has no business pulling string.h; Include it properly
in case we remove framework.h later on (spoiler lol).
The current header implementation is incomplete: the text_offset and
image_size slots are overlaid with internal relocation metadata
(_rel_stack_base / _rel_stack_size), and the flags field is zero,
which makes some bootloaders unhappy. Fill up the the missing props and
while at it, stub out the image header into a header file to avoid duplicating.
image_size is computed in the linker script as _stack_end - _start
so the early stack page is included in the runtime memory footprint
advertised to the previous-stage bootloader.
Patch inspired by work from @Trijal08 and cleaned up to not account for
ELF PiE.
This is the correct format considering the BGRA write format was wrong before, leading it to actually use ABGR.
Signed-off-by: Umer Uddin <umer.uddin@mentallysanemainliners.org>
This is the correct format considering the BGRA write format was wrong before, leading it to actually use ABGR.
Signed-off-by: Umer Uddin <umer.uddin@mentallysanemainliners.org>
Xperia 1 VI is a flagship phone manufactured by Sony, based on the
Qualcomm Snapdragon 8 Gen 3 Mobile Platform.
Add support for this board.
NOTE: This board is new, and as such, it requires some ugly hax and
a fallback boot method to boot any sort of [u-boot/uniLoader/mainline]
In short:
- build:
- ARCH=aarch64 CROSS_COMPILE=aarch64-linux-gnu- make -j32
- cat uniLoader.gz dummy.dtb > uni.dtb
- mkbootimg --kernel uni.dtb --ramdisk <some ramdisk (required)> \
--pagesize 4096 --base 0x0 --kernel_offset 0x8000 \
--ramdisk_offset 0x1000000 --tags_offset 0x100 \
--dtb_offset 0x1f00000 --header_version 0 --os_version 16.0.0 \
--os_patch_level 2026-04 -o boot.img
(yes, all properties are required.)
- prepare device:
- boot to fastboot mode (volume up and plug in USB)
- fastboot erase dtbo erase vendor_boot
- flash:
- fastboot flash boot boot.img continue
Where:
- dummy.dtb is a skeleton.dtsi with a reserved memory node called
splash_region as a child of the chosen node.
Signed-off-by: Igor Belwon <igor.belwon@mentallysanemainliners.org>
Pass the address of the address of the DTB to patch_dtb in boot.c, rather than just the address to the DTB.
This allows the modified DTB address to overwrite the address of the original DTB, fixing a bug where
the ramdisk address was not being passed to the kernel via the DTB successfully.
Due to divmod performing division by subtracting in a linear loop,
it's *really* slow. When performing division with larger numbers (like
32-bit addresses), it goes thru massive amounts of iterations and causes
a stall-like appearance.
Instead, let the compiler handle it by using cpu instructions like
UDIV/MSUB for armv8.
Fixes#86.
