protected_size in TBF header

[Laura Abbott]

Hi,

The protected_size is defined in
https://github.com/tock/tock/blob/master/doc/TockBinaryFormat.md#1-main
as "the amount of flash, in bytes, after the header, to prevent
the process from writing to." Most boards in libtock-rs seem to be using
64 based on the call to elf2tab but I can't seem to find an
explanation about what this actually corresponds to. I _think_
this is supposed to be the crt0 header. Does anyone have a more detailed
explanation about how this field is intended to be used?

Thanks,
Laura

[Brad Campbell]

Since the TBF header is used by the kernel for loading apps and, importantly, finding where the next app is in flash after the current app, we consider the TBF header to be process-specified but owned by the kernel. That is, processes cannot modify their own TBF headers at runtime. As a future-looking extension of that concept, the TBF header has support (the protected_size field) for recording the length of additional space in flash after the TBF header that is owned by the kernel. The thought was that the kernel may want to keep nonvolatile state on behalf of a process, and this would give it space to store that state. You can almost think of this like a nonvolatile grant region.

With relocatable apps, the length of this region, and as a result the address of where the app's code actually resides, doesn't matter (modulo alignment issues). However, with libtock-rs and RISC-V apps needing to know their addresses in flash at compile time, suddenly the size of the TBF header matters quite a bit. The `--protected-region-size` in elf2tab is essentially a workaround that uses the existing protected_size field to ensure that app binaries are always placed at the same address. It doesn't have any effect on the crt0 header, which is completely owned by the app itself.

I know that was more than you asked about, but the context might be helpful for future readers.

- Brad

--
You received this message because you are subscribed to the Google Groups "Tock Embedded OS Development Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tock-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/35091b01-9606-316b-1d0b-acebec22be2f%40oxidecomputer.com.

[Laura Abbott]

On 2/19/20 12:20 PM, Brad Campbell wrote:
> Since the TBF header is used by the kernel for loading apps and,
> importantly, finding where the next app is in flash after the current
> app, we consider the TBF header to be process-specified but owned by the
> kernel. That is, processes cannot modify their own TBF headers at
> runtime. As a future-looking extension of that concept, the TBF header
> has support (the protected_size field) for recording the length of
> additional space in flash after the TBF header that is owned by the
> kernel. The thought was that the kernel may want to keep nonvolatile
> state on behalf of a process, and this would give it space to store that
> state. You can almost think of this like a nonvolatile grant region.
>
> With relocatable apps, the length of this region, and as a result the
> address of where the app's code actually resides, doesn't matter (modulo
> alignment issues). However, with libtock-rs and RISC-V apps needing to
> know their addresses in flash at compile time, suddenly the size of the
> TBF header matters quite a bit. The `--protected-region-size` in elf2tab
> is essentially a workaround that uses the existing protected_size field
> to ensure that app binaries are always placed at the same address. It
> doesn't have any effect on the crt0 header, which is completely owned by
> the app itself.
>
> I know that was more than you asked about, but the context might be
> helpful for future readers.
>

That was exactly the context I was hoping for and hit upon the problem
I'm working on actually :)

I've been struggling to get RISC-V applications built with libtock-rs
as they seem to be quite fragile with respect to memory layout. I came
up with a somewhat complicated scheme with a shell script to build with
the correct header size each time. It sounds like a somewhat cleaner
solution is to set the Flash origin to include the protected memory
region so as long as your header size doesn't grow larger than that
everything should always be consistent.

Thanks,
Laura

> - Brad
>
> On Wed, Feb 19, 2020 at 11:56 AM 'Laura Abbott' via Tock Embedded OS
> Development Discussion <tock...@googlegroups.com

> <mailto:tock...@googlegroups.com>> wrote:
>
> Hi,
>
> The protected_size is defined in
> https://github.com/tock/tock/blob/master/doc/TockBinaryFormat.md#1-main
> as "the amount of flash, in bytes, after the header, to prevent
> the process from writing to." Most boards in libtock-rs seem to be using
> 64 based on the call to elf2tab but I can't seem to find an
> explanation about what this actually corresponds to. I _think_
> this is supposed to be the crt0 header. Does anyone have a more detailed
> explanation about how this field is intended to be used?
>
> Thanks,
> Laura
>
> --
> You received this message because you are subscribed to the Google
> Groups "Tock Embedded OS Development Discussion" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to tock-dev+u...@googlegroups.com

> <mailto:tock-dev%2Bunsu...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/tock-dev/35091b01-9606-316b-1d0b-acebec22be2f%40oxidecomputer.com.
>

> --
> You received this message because you are subscribed to the Google
> Groups "Tock Embedded OS Development Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to tock-dev+u...@googlegroups.com

> <mailto:tock-dev+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/tock-dev/CADEbMG0UDY-Pu6MLa8HtY06eJ1r2yRW3HCjtM%3Da%2BYA-AXTQ3dA%40mail.gmail.com
> <https://groups.google.com/d/msgid/tock-dev/CADEbMG0UDY-Pu6MLa8HtY06eJ1r2yRW3HCjtM%3Da%2BYA-AXTQ3dA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Amit Levy]

I'm not entirely sure if this is related, but libtock-rs's memory
loading and layout on RISC-V is currently imperfect, and it could be
that you're simply running into a bug in that code/linker script. I have
a draft PR that I should get back to that tries to resolve it:
https://github.com/tock/libtock-rs/pull/110

On 2/19/20 12:37 PM, 'Laura Abbott' via Tock Embedded OS Development

[Laura Abbott]

Yes, I hit that as well. I have my own PR which fixes it
https://github.com/tock/libtock-rs/pull/147. I'd prefer if this could
be merged simply because it's very broken right now and it's easier
to verify the relative offsets if we know what was actually working
before.

Thanks,
Laura