On Tue, 2025-12-30 at 22:56 +0000, Timur Tabi wrote:
> Hmmm... that would require that I implement FalconLoadParams for
> GenericBootloader. That's not a
> bad idea. I'm not sure how I would build the Dmem FalconLoadTarget, however,
> given that it needs
> to
> reference data from the FRTS FalconFirmware object.
>
> impl FalconLoadParams for GenericBootloader {
> fn imem_sec_load_params(&self) -> FalconLoadTarget {
> FalconLoadTarget {
> }
> }
>
> fn imem_ns_load_params(&self) -> Option<FalconLoadTarget> {
> FalconLoadTarget {
> }
> }
>
> fn dmem_load_params(&self) -> FalconLoadTarget {
> FalconLoadTarget {
> // How do I extract data from the FRTS firmware image here?
> }
> }
> }
So I'm having doubts about this approach now. It turns out that we would need
to make everything
except dmem_load_params return an Option<>, including boot_args. I would also
need to add a
start_tag() method for PIO, and that would also return an Option<>. Does it
really make sense to
have FalconLoadParams look like this:
pub(crate) trait FalconLoadParams {
fn imem_sec_load_params(&self) -> Option<FalconLoadTarget>;
fn imem_ns_load_params(&self) -> Option<FalconLoadTarget>;
fn dmem_load_params(&self) -> FalconLoadTarget;
fn brom_params(&self) -> Option<FalconBromParams>;
fn boot_addr(&self) -> Option<u32>;
fn start_tag(&self) -> Option<u16>;
}
This seems to defeat the purpose of having a unified FalconLoadParams, if
almost everything in it is
optional.
