-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add recipe for balena bootloader #1097
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Depends on balena-os/meta-balena#3326 |
|
||
KERNEL_DEVICETREE = "${RPI_KERNEL_DEVICETREE}" | ||
|
||
PROVIDES = "virtual/balena-bootloader" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not "virtual/bootloader"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is used to pull balena bootloader into the image without using the specific package name:
https://github.com/balena-os/balena-raspberrypi/pull/1091/files#diff-abca8cd7f0af2e032dfdeec9e689532b73da44e8b689133f6d02617cec7fb5f9R79
But I am not sure whether it is particularly useful since the package name will be per-device-repo anyway. That is the only place where it is used. I think it is virtual/balena-bootloader
because it was virtual/linux-kboot
in the old dev branches and I just changed linux-kboot
to balena-bootloader
everywhere.
I have no strong opinion either way, do you think we should provide virtual/bootloader
here and pull linux-balena-bootloader
into the image?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mtoman I think it's cleaner to use virtual/bootloader
as currently that will build u-boot. Not introducing a second virtual target simplifies things.
On other platforms where we might use u-boot as vendor bootloader and then the balena-bootloader we might need to use different virtual targets - so this might be a reason to also use separate targets here.
Just give it a thought and let me know what you prefer - I tend to prefer just using virtual/bootloader
as it's either u-boot or balena bootloader in this case, but I can see both.
This is a separate version of the kernel that will be used as a second stage bootloader instead of u-boot. With just this patch nothing will use it yet but it will be ready for use when we start to switch. Change-type: patch Changelog-entry: Add recipe for balena bootloader Signed-off-by: Michal Toman <michalt@balena.io>
cd34e64
to
39b5719
Compare
This is a separate version of the kernel that will be used as a second stage bootloader instead of u-boot. With just this patch nothing will use it yet but it will be ready for use when we start to switch.