User avatar
Gavinmc42
Posts: 6211
Joined: Wed Aug 28, 2013 3:31 am

Re: open firmware and booting custom apps fast

Thu Sep 23, 2021 2:13 am

but the pi4 3d core, isnt even supported by the blob!, so all of the answers are in the source for linux and mesa
I am hoping there are no dependencies for that Mesa DRM/DRI stuff.
For bare metal compile for arm-none instead of arm-system?

I need to find time to play with your LK to see if it will boot Ultibo kernels.
Start.elf is now bigger than my baremetal kernels.

The start.elf and devicetree etc interactions are affecting things.
They change things to make it generic for Linux, putting more capabilities into it.
More stuff means more boot time, bigger blobs and unknown side effects for baremetal.

Hmm, most Linux kernels are now relying of devicetree?
So an open booter will need devicetree support.
I understand where and why now.
Good luck with that mess :roll:
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

cleverca22
Posts: 4748
Joined: Sat Aug 18, 2012 2:33 pm

Re: open firmware and booting custom apps fast

Thu Sep 23, 2021 2:31 am

Gavinmc42 wrote:
Thu Sep 23, 2021 2:13 am
Hmm, most Linux kernels are now relying of devicetree?
So an open booter will need devicetree support.
I understand where and why now.
with my current design, i'm building LK in rpi2-test mode, to create a custom baremetal kernel, that acts as a bootloader to run linux

it is using device-tree to make linux happy
but if you wanted, you could replace that entire rpi2-test chunk, with your own baremetal arm

but i have also added my own custom devicetree, for passing data into that first arm kernel

https://github.com/librerpi/lk-overlay/ ... .c#L34-L38

Code: Select all

inter_core_header hdr __attribute__((aligned(16))) = {
  .magic = INTER_ARCH_MAGIC,
  .header_size = sizeof(inter_core_header),
  .end_of_ram = MEMSIZE
};
the VPU half of the firmware will search for that magic number, and to make the search go faster, it only checks 16 byte aligned locations
it will then copy a DTB into ram, to fit after end_of_ram, so it doesnt overwrite anything important in your kernel
and it sets hdr.dtb_base to the addr it chose

currently, the dtb just has 2 nodes, a framebuffer node with the width/height/addr, and a timestamps node with the timestamp at several points in the boot
but i do plan to add things like the serial# to it

Code: Select all

-rwxr-xr-x 1 clever users 129K Sep 21 02:56 build-rpi2-test/lk.bin
-rwxr-xr-x 1 clever users 856K Sep 22 22:29 build-vc4-stage2/lk.elf
if you replace the rpi2-test blob, then you can subtract that 129kb from the lk.elf size, and then add in the size of whatever arm blob your using
so thats just 727kb of .elf to get your arm kernel running, with ntsc video out, and very minimal device-tree
Gavinmc42 wrote:
Thu Sep 23, 2021 2:13 am
and unknown side effects for baremetal.
and the source for that .elf is open, so you can see what its doing, and what side-effects it would have

Return to “Bare metal, Assembly language”