| Message ID | 44b858e8826f4617439aec11ad850431e4bc1a21.1628000645.git.jan.kiszka@siemens.com |
|---|---|
| State | Superseded |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | Add SIMATIC IOT2050 board support | expand |
On Tue, Aug 03, 2021 at 04:24:05PM +0200, Jan Kiszka wrote: > From: Jan Kiszka <jan.kiszka@siemens.com> > > This allows to use the watchdog in custom scripts but does not enforce > that the OS has to support it as well. > > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Sorry for the late reply. This causes CI to fail: Building current source for 1 boards (1 thread, 16 jobs per thread) aarch64: + iot2050 +(iot2050) WARNING ATF file bl31.bin NOT found, resulting binary is non-functional +(iot2050) WARNING OPTEE file bl32.bin NOT found, resulting might be non-functional +(iot2050) binman: Filename 'k3-rti-wdt.fw' not found in input path (.,/home/trini/work/u-boot/u-boot,board/siemens/iot2050,arch/arm/dts) (cwd='/tmp/iot2050/.bm-work/iot2050') +(iot2050) make[1]: *** [all] Error 1 +(iot2050) make: *** [sub-make] Error 2 0 0 1 /1 iot2050 And needs to be handled like ATF/OPTEE/etc where CI can build but throw a "THIS WILL NOT RUN CORRECTLY" type warning to the user.
On 11.09.21 02:10, Tom Rini wrote: > On Tue, Aug 03, 2021 at 04:24:05PM +0200, Jan Kiszka wrote: > >> From: Jan Kiszka <jan.kiszka@siemens.com> >> >> This allows to use the watchdog in custom scripts but does not enforce >> that the OS has to support it as well. >> >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > > Sorry for the late reply. This causes CI to fail: > Building current source for 1 boards (1 thread, 16 jobs per thread) > aarch64: + iot2050 > +(iot2050) WARNING ATF file bl31.bin NOT found, resulting binary is non-functional > +(iot2050) WARNING OPTEE file bl32.bin NOT found, resulting might be non-functional > +(iot2050) binman: Filename 'k3-rti-wdt.fw' not found in input path (.,/home/trini/work/u-boot/u-boot,board/siemens/iot2050,arch/arm/dts) (cwd='/tmp/iot2050/.bm-work/iot2050') > +(iot2050) make[1]: *** [all] Error 1 > +(iot2050) make: *** [sub-make] Error 2 > 0 0 1 /1 iot2050 > > And needs to be handled like ATF/OPTEE/etc where CI can build but throw > a "THIS WILL NOT RUN CORRECTLY" type warning to the user. > I was about to sent an update anyway - time passed, and now we even have support for the next generation integrated from the beginning. But related upstream DT changes are not yet merged. But back to this issue: How can CI be fed with all those required binaries? The build makes no sense in their absence. Jan
On Mon, Sep 13, 2021 at 09:57:45AM +0200, Jan Kiszka wrote: > On 11.09.21 02:10, Tom Rini wrote: > > On Tue, Aug 03, 2021 at 04:24:05PM +0200, Jan Kiszka wrote: > > > >> From: Jan Kiszka <jan.kiszka@siemens.com> > >> > >> This allows to use the watchdog in custom scripts but does not enforce > >> that the OS has to support it as well. > >> > >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > > > > Sorry for the late reply. This causes CI to fail: > > Building current source for 1 boards (1 thread, 16 jobs per thread) > > aarch64: + iot2050 > > +(iot2050) WARNING ATF file bl31.bin NOT found, resulting binary is non-functional > > +(iot2050) WARNING OPTEE file bl32.bin NOT found, resulting might be non-functional > > +(iot2050) binman: Filename 'k3-rti-wdt.fw' not found in input path (.,/home/trini/work/u-boot/u-boot,board/siemens/iot2050,arch/arm/dts) (cwd='/tmp/iot2050/.bm-work/iot2050') > > +(iot2050) make[1]: *** [all] Error 1 > > +(iot2050) make: *** [sub-make] Error 2 > > 0 0 1 /1 iot2050 > > > > And needs to be handled like ATF/OPTEE/etc where CI can build but throw > > a "THIS WILL NOT RUN CORRECTLY" type warning to the user. > > > > I was about to sent an update anyway - time passed, and now we even have > support for the next generation integrated from the beginning. But > related upstream DT changes are not yet merged. OK. > But back to this issue: How can CI be fed with all those required > binaries? The build makes no sense in their absence. To be clearer, CI isn't fed all of the binaries, we just use /dev/null in that case and try and make it clear it won't boot. K3 isn't a good example here, but I think sunxi uses binman and handles this same class of problem?
On 13.09.21 14:34, Tom Rini wrote: > On Mon, Sep 13, 2021 at 09:57:45AM +0200, Jan Kiszka wrote: >> On 11.09.21 02:10, Tom Rini wrote: >>> On Tue, Aug 03, 2021 at 04:24:05PM +0200, Jan Kiszka wrote: >>> >>>> From: Jan Kiszka <jan.kiszka@siemens.com> >>>> >>>> This allows to use the watchdog in custom scripts but does not enforce >>>> that the OS has to support it as well. >>>> >>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >>> >>> Sorry for the late reply. This causes CI to fail: >>> Building current source for 1 boards (1 thread, 16 jobs per thread) >>> aarch64: + iot2050 >>> +(iot2050) WARNING ATF file bl31.bin NOT found, resulting binary is non-functional >>> +(iot2050) WARNING OPTEE file bl32.bin NOT found, resulting might be non-functional >>> +(iot2050) binman: Filename 'k3-rti-wdt.fw' not found in input path (.,/home/trini/work/u-boot/u-boot,board/siemens/iot2050,arch/arm/dts) (cwd='/tmp/iot2050/.bm-work/iot2050') >>> +(iot2050) make[1]: *** [all] Error 1 >>> +(iot2050) make: *** [sub-make] Error 2 >>> 0 0 1 /1 iot2050 >>> >>> And needs to be handled like ATF/OPTEE/etc where CI can build but throw >>> a "THIS WILL NOT RUN CORRECTLY" type warning to the user. >>> >> >> I was about to sent an update anyway - time passed, and now we even have >> support for the next generation integrated from the beginning. But >> related upstream DT changes are not yet merged. > > OK. > >> But back to this issue: How can CI be fed with all those required >> binaries? The build makes no sense in their absence. > > To be clearer, CI isn't fed all of the binaries, we just use /dev/null > in that case and try and make it clear it won't boot. K3 isn't a good > example here, but I think sunxi uses binman and handles this same class > of problem? > I'm seeing it additionally carrying a "missing-msg" property, but that alone (even with missing-blob-help updated) does not make the build pass. It rather seems I'm missing some "allow_missing" property for that image, but even reading the code gives no clue yet how to achieve that. Yet another binman mystery. Jan
On Mon, Sep 13, 2021 at 04:31:37PM +0200, Jan Kiszka wrote: > On 13.09.21 14:34, Tom Rini wrote: > > On Mon, Sep 13, 2021 at 09:57:45AM +0200, Jan Kiszka wrote: > >> On 11.09.21 02:10, Tom Rini wrote: > >>> On Tue, Aug 03, 2021 at 04:24:05PM +0200, Jan Kiszka wrote: > >>> > >>>> From: Jan Kiszka <jan.kiszka@siemens.com> > >>>> > >>>> This allows to use the watchdog in custom scripts but does not enforce > >>>> that the OS has to support it as well. > >>>> > >>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > >>> > >>> Sorry for the late reply. This causes CI to fail: > >>> Building current source for 1 boards (1 thread, 16 jobs per thread) > >>> aarch64: + iot2050 > >>> +(iot2050) WARNING ATF file bl31.bin NOT found, resulting binary is non-functional > >>> +(iot2050) WARNING OPTEE file bl32.bin NOT found, resulting might be non-functional > >>> +(iot2050) binman: Filename 'k3-rti-wdt.fw' not found in input path (.,/home/trini/work/u-boot/u-boot,board/siemens/iot2050,arch/arm/dts) (cwd='/tmp/iot2050/.bm-work/iot2050') > >>> +(iot2050) make[1]: *** [all] Error 1 > >>> +(iot2050) make: *** [sub-make] Error 2 > >>> 0 0 1 /1 iot2050 > >>> > >>> And needs to be handled like ATF/OPTEE/etc where CI can build but throw > >>> a "THIS WILL NOT RUN CORRECTLY" type warning to the user. > >>> > >> > >> I was about to sent an update anyway - time passed, and now we even have > >> support for the next generation integrated from the beginning. But > >> related upstream DT changes are not yet merged. > > > > OK. > > > >> But back to this issue: How can CI be fed with all those required > >> binaries? The build makes no sense in their absence. > > > > To be clearer, CI isn't fed all of the binaries, we just use /dev/null > > in that case and try and make it clear it won't boot. K3 isn't a good > > example here, but I think sunxi uses binman and handles this same class > > of problem? > > > > I'm seeing it additionally carrying a "missing-msg" property, but that > alone (even with missing-blob-help updated) does not make the build > pass. It rather seems I'm missing some "allow_missing" property for that > image, but even reading the code gives no clue yet how to achieve that. > Yet another binman mystery. You might also need a new file in tools/binman/etype/ ? Also, it will have a non-zero exit status still, but with a value of 101 which we check for and know that's "binary blob missing" and so OK to allow CI to pass on.
On 13.09.21 16:56, Tom Rini wrote: > On Mon, Sep 13, 2021 at 04:31:37PM +0200, Jan Kiszka wrote: >> On 13.09.21 14:34, Tom Rini wrote: >>> On Mon, Sep 13, 2021 at 09:57:45AM +0200, Jan Kiszka wrote: >>>> On 11.09.21 02:10, Tom Rini wrote: >>>>> On Tue, Aug 03, 2021 at 04:24:05PM +0200, Jan Kiszka wrote: >>>>> >>>>>> From: Jan Kiszka <jan.kiszka@siemens.com> >>>>>> >>>>>> This allows to use the watchdog in custom scripts but does not enforce >>>>>> that the OS has to support it as well. >>>>>> >>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >>>>> >>>>> Sorry for the late reply. This causes CI to fail: >>>>> Building current source for 1 boards (1 thread, 16 jobs per thread) >>>>> aarch64: + iot2050 >>>>> +(iot2050) WARNING ATF file bl31.bin NOT found, resulting binary is non-functional >>>>> +(iot2050) WARNING OPTEE file bl32.bin NOT found, resulting might be non-functional >>>>> +(iot2050) binman: Filename 'k3-rti-wdt.fw' not found in input path (.,/home/trini/work/u-boot/u-boot,board/siemens/iot2050,arch/arm/dts) (cwd='/tmp/iot2050/.bm-work/iot2050') >>>>> +(iot2050) make[1]: *** [all] Error 1 >>>>> +(iot2050) make: *** [sub-make] Error 2 >>>>> 0 0 1 /1 iot2050 >>>>> >>>>> And needs to be handled like ATF/OPTEE/etc where CI can build but throw >>>>> a "THIS WILL NOT RUN CORRECTLY" type warning to the user. >>>>> >>>> >>>> I was about to sent an update anyway - time passed, and now we even have >>>> support for the next generation integrated from the beginning. But >>>> related upstream DT changes are not yet merged. >>> >>> OK. >>> >>>> But back to this issue: How can CI be fed with all those required >>>> binaries? The build makes no sense in their absence. >>> >>> To be clearer, CI isn't fed all of the binaries, we just use /dev/null >>> in that case and try and make it clear it won't boot. K3 isn't a good >>> example here, but I think sunxi uses binman and handles this same class >>> of problem? >>> >> >> I'm seeing it additionally carrying a "missing-msg" property, but that >> alone (even with missing-blob-help updated) does not make the build >> pass. It rather seems I'm missing some "allow_missing" property for that >> image, but even reading the code gives no clue yet how to achieve that. >> Yet another binman mystery. > > You might also need a new file in tools/binman/etype/ ? Also, it will > have a non-zero exit status still, but with a value of 101 which we > check for and know that's "binary blob missing" and so OK to allow CI to > pass on. > Err, that doesn't sound like binman is making my life easier. Why can't a I simple do something like k3-rti-wdt-firmware { type = "blob"; load = <0x82000000>; blob { filename = CONFIG_WDT_K3_RTI_FW_FILE; missing-msg = "k3-rti-wdt-firmware"; allow_missing; }; }; and be done? Jan
On Mon, Sep 13, 2021 at 04:59:35PM +0200, Jan Kiszka wrote: > On 13.09.21 16:56, Tom Rini wrote: > > On Mon, Sep 13, 2021 at 04:31:37PM +0200, Jan Kiszka wrote: > >> On 13.09.21 14:34, Tom Rini wrote: > >>> On Mon, Sep 13, 2021 at 09:57:45AM +0200, Jan Kiszka wrote: > >>>> On 11.09.21 02:10, Tom Rini wrote: > >>>>> On Tue, Aug 03, 2021 at 04:24:05PM +0200, Jan Kiszka wrote: > >>>>> > >>>>>> From: Jan Kiszka <jan.kiszka@siemens.com> > >>>>>> > >>>>>> This allows to use the watchdog in custom scripts but does not enforce > >>>>>> that the OS has to support it as well. > >>>>>> > >>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > >>>>> > >>>>> Sorry for the late reply. This causes CI to fail: > >>>>> Building current source for 1 boards (1 thread, 16 jobs per thread) > >>>>> aarch64: + iot2050 > >>>>> +(iot2050) WARNING ATF file bl31.bin NOT found, resulting binary is non-functional > >>>>> +(iot2050) WARNING OPTEE file bl32.bin NOT found, resulting might be non-functional > >>>>> +(iot2050) binman: Filename 'k3-rti-wdt.fw' not found in input path (.,/home/trini/work/u-boot/u-boot,board/siemens/iot2050,arch/arm/dts) (cwd='/tmp/iot2050/.bm-work/iot2050') > >>>>> +(iot2050) make[1]: *** [all] Error 1 > >>>>> +(iot2050) make: *** [sub-make] Error 2 > >>>>> 0 0 1 /1 iot2050 > >>>>> > >>>>> And needs to be handled like ATF/OPTEE/etc where CI can build but throw > >>>>> a "THIS WILL NOT RUN CORRECTLY" type warning to the user. > >>>>> > >>>> > >>>> I was about to sent an update anyway - time passed, and now we even have > >>>> support for the next generation integrated from the beginning. But > >>>> related upstream DT changes are not yet merged. > >>> > >>> OK. > >>> > >>>> But back to this issue: How can CI be fed with all those required > >>>> binaries? The build makes no sense in their absence. > >>> > >>> To be clearer, CI isn't fed all of the binaries, we just use /dev/null > >>> in that case and try and make it clear it won't boot. K3 isn't a good > >>> example here, but I think sunxi uses binman and handles this same class > >>> of problem? > >>> > >> > >> I'm seeing it additionally carrying a "missing-msg" property, but that > >> alone (even with missing-blob-help updated) does not make the build > >> pass. It rather seems I'm missing some "allow_missing" property for that > >> image, but even reading the code gives no clue yet how to achieve that. > >> Yet another binman mystery. > > > > You might also need a new file in tools/binman/etype/ ? Also, it will > > have a non-zero exit status still, but with a value of 101 which we > > check for and know that's "binary blob missing" and so OK to allow CI to > > pass on. > > > > Err, that doesn't sound like binman is making my life easier. Why can't > a I simple do something like > > k3-rti-wdt-firmware { > type = "blob"; > load = <0x82000000>; > blob { > filename = CONFIG_WDT_K3_RTI_FW_FILE; > missing-msg = "k3-rti-wdt-firmware"; > allow_missing; > }; > }; > > and be done? Sounds like a good idea, and I'm not quite sure what's missing to go from where we are today to there. I might be missing something myself.
On Mon, 13 Sept 2021 at 17:36, Tom Rini <trini@konsulko.com> wrote: > On Mon, Sep 13, 2021 at 04:59:35PM +0200, Jan Kiszka wrote: > > On 13.09.21 16:56, Tom Rini wrote: > > > On Mon, Sep 13, 2021 at 04:31:37PM +0200, Jan Kiszka wrote: > > >> On 13.09.21 14:34, Tom Rini wrote: > > >>> On Mon, Sep 13, 2021 at 09:57:45AM +0200, Jan Kiszka wrote: > > >>>> On 11.09.21 02:10, Tom Rini wrote: > > >>>>> On Tue, Aug 03, 2021 at 04:24:05PM +0200, Jan Kiszka wrote: > > >>>>> > > >>>>>> From: Jan Kiszka <jan.kiszka@siemens.com> > > >>>>>> > > >>>>>> This allows to use the watchdog in custom scripts but does not > enforce > > >>>>>> that the OS has to support it as well. > > >>>>>> > > >>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > > >>>>> > > >>>>> Sorry for the late reply. This causes CI to fail: > > >>>>> Building current source for 1 boards (1 thread, 16 jobs per thread) > > >>>>> aarch64: + iot2050 > > >>>>> +(iot2050) WARNING ATF file bl31.bin NOT found, resulting binary > is non-functional > > >>>>> +(iot2050) WARNING OPTEE file bl32.bin NOT found, resulting might > be non-functional > > >>>>> +(iot2050) binman: Filename 'k3-rti-wdt.fw' not found in input > path (.,/home/trini/work/u-boot/u-boot,board/siemens/iot2050,arch/arm/dts) > (cwd='/tmp/iot2050/.bm-work/iot2050') > > >>>>> +(iot2050) make[1]: *** [all] Error 1 > > >>>>> +(iot2050) make: *** [sub-make] Error 2 > > >>>>> 0 0 1 /1 iot2050 > > >>>>> > > >>>>> And needs to be handled like ATF/OPTEE/etc where CI can build but > throw > > >>>>> a "THIS WILL NOT RUN CORRECTLY" type warning to the user. > > >>>>> > > >>>> > > >>>> I was about to sent an update anyway - time passed, and now we even > have > > >>>> support for the next generation integrated from the beginning. But > > >>>> related upstream DT changes are not yet merged. > > >>> > > >>> OK. > > >>> > > >>>> But back to this issue: How can CI be fed with all those required > > >>>> binaries? The build makes no sense in their absence. > > >>> > > >>> To be clearer, CI isn't fed all of the binaries, we just use > /dev/null > > >>> in that case and try and make it clear it won't boot. K3 isn't a > good > > >>> example here, but I think sunxi uses binman and handles this same > class > > >>> of problem? > > >>> > > >> > > >> I'm seeing it additionally carrying a "missing-msg" property, but that > > >> alone (even with missing-blob-help updated) does not make the build > > >> pass. It rather seems I'm missing some "allow_missing" property for > that > > >> image, but even reading the code gives no clue yet how to achieve > that. > > >> Yet another binman mystery. > > > > > > You might also need a new file in tools/binman/etype/ ? Also, it will > > > have a non-zero exit status still, but with a value of 101 which we > > > check for and know that's "binary blob missing" and so OK to allow CI > to > > > pass on. > > > > > > > Err, that doesn't sound like binman is making my life easier. Why can't > > a I simple do something like > > > > k3-rti-wdt-firmware { > > type = "blob"; > > load = <0x82000000>; > > blob { > > filename = CONFIG_WDT_K3_RTI_FW_FILE; > > missing-msg = "k3-rti-wdt-firmware"; > > allow_missing; > > }; > > }; > > > > and be done? > > Sounds like a good idea, and I'm not quite sure what's missing to go > from where we are today to there. I might be missing something myself. > If that entry is located in a DT for U-Boot consumption why not, but in the DT that is associated to a platform that is passed to the OS, that sounds like a practice to avoid as this does not describe hardware. Thinking compatibility, is the filename/filepath really OS independent ? > > -- > Tom >
On 13.09.21 17:36, Tom Rini wrote: > On Mon, Sep 13, 2021 at 04:59:35PM +0200, Jan Kiszka wrote: >> On 13.09.21 16:56, Tom Rini wrote: >>> On Mon, Sep 13, 2021 at 04:31:37PM +0200, Jan Kiszka wrote: >>>> On 13.09.21 14:34, Tom Rini wrote: >>>>> On Mon, Sep 13, 2021 at 09:57:45AM +0200, Jan Kiszka wrote: >>>>>> On 11.09.21 02:10, Tom Rini wrote: >>>>>>> On Tue, Aug 03, 2021 at 04:24:05PM +0200, Jan Kiszka wrote: >>>>>>> >>>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com> >>>>>>>> >>>>>>>> This allows to use the watchdog in custom scripts but does not enforce >>>>>>>> that the OS has to support it as well. >>>>>>>> >>>>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >>>>>>> >>>>>>> Sorry for the late reply. This causes CI to fail: >>>>>>> Building current source for 1 boards (1 thread, 16 jobs per thread) >>>>>>> aarch64: + iot2050 >>>>>>> +(iot2050) WARNING ATF file bl31.bin NOT found, resulting binary is non-functional >>>>>>> +(iot2050) WARNING OPTEE file bl32.bin NOT found, resulting might be non-functional >>>>>>> +(iot2050) binman: Filename 'k3-rti-wdt.fw' not found in input path (.,/home/trini/work/u-boot/u-boot,board/siemens/iot2050,arch/arm/dts) (cwd='/tmp/iot2050/.bm-work/iot2050') >>>>>>> +(iot2050) make[1]: *** [all] Error 1 >>>>>>> +(iot2050) make: *** [sub-make] Error 2 >>>>>>> 0 0 1 /1 iot2050 >>>>>>> >>>>>>> And needs to be handled like ATF/OPTEE/etc where CI can build but throw >>>>>>> a "THIS WILL NOT RUN CORRECTLY" type warning to the user. >>>>>>> >>>>>> >>>>>> I was about to sent an update anyway - time passed, and now we even have >>>>>> support for the next generation integrated from the beginning. But >>>>>> related upstream DT changes are not yet merged. >>>>> >>>>> OK. >>>>> >>>>>> But back to this issue: How can CI be fed with all those required >>>>>> binaries? The build makes no sense in their absence. >>>>> >>>>> To be clearer, CI isn't fed all of the binaries, we just use /dev/null >>>>> in that case and try and make it clear it won't boot. K3 isn't a good >>>>> example here, but I think sunxi uses binman and handles this same class >>>>> of problem? >>>>> >>>> >>>> I'm seeing it additionally carrying a "missing-msg" property, but that >>>> alone (even with missing-blob-help updated) does not make the build >>>> pass. It rather seems I'm missing some "allow_missing" property for that >>>> image, but even reading the code gives no clue yet how to achieve that. >>>> Yet another binman mystery. >>> >>> You might also need a new file in tools/binman/etype/ ? Also, it will >>> have a non-zero exit status still, but with a value of 101 which we >>> check for and know that's "binary blob missing" and so OK to allow CI to >>> pass on. >>> >> >> Err, that doesn't sound like binman is making my life easier. Why can't >> a I simple do something like >> >> k3-rti-wdt-firmware { >> type = "blob"; >> load = <0x82000000>; >> blob { >> filename = CONFIG_WDT_K3_RTI_FW_FILE; >> missing-msg = "k3-rti-wdt-firmware"; >> allow_missing; >> }; >> }; >> >> and be done? > > Sounds like a good idea, and I'm not quite sure what's missing to go > from where we are today to there. I might be missing something myself. > Works now, with "blob-ext" rather than "blob". binman is actually called with --allow-missing. Jan
On Mon, Sep 13, 2021 at 06:08:10PM +0200, François Ozog wrote: > On Mon, 13 Sept 2021 at 17:36, Tom Rini <trini@konsulko.com> wrote: > > > On Mon, Sep 13, 2021 at 04:59:35PM +0200, Jan Kiszka wrote: > > > On 13.09.21 16:56, Tom Rini wrote: > > > > On Mon, Sep 13, 2021 at 04:31:37PM +0200, Jan Kiszka wrote: > > > >> On 13.09.21 14:34, Tom Rini wrote: > > > >>> On Mon, Sep 13, 2021 at 09:57:45AM +0200, Jan Kiszka wrote: > > > >>>> On 11.09.21 02:10, Tom Rini wrote: > > > >>>>> On Tue, Aug 03, 2021 at 04:24:05PM +0200, Jan Kiszka wrote: > > > >>>>> > > > >>>>>> From: Jan Kiszka <jan.kiszka@siemens.com> > > > >>>>>> > > > >>>>>> This allows to use the watchdog in custom scripts but does not > > enforce > > > >>>>>> that the OS has to support it as well. > > > >>>>>> > > > >>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > > > >>>>> > > > >>>>> Sorry for the late reply. This causes CI to fail: > > > >>>>> Building current source for 1 boards (1 thread, 16 jobs per thread) > > > >>>>> aarch64: + iot2050 > > > >>>>> +(iot2050) WARNING ATF file bl31.bin NOT found, resulting binary > > is non-functional > > > >>>>> +(iot2050) WARNING OPTEE file bl32.bin NOT found, resulting might > > be non-functional > > > >>>>> +(iot2050) binman: Filename 'k3-rti-wdt.fw' not found in input > > path (.,/home/trini/work/u-boot/u-boot,board/siemens/iot2050,arch/arm/dts) > > (cwd='/tmp/iot2050/.bm-work/iot2050') > > > >>>>> +(iot2050) make[1]: *** [all] Error 1 > > > >>>>> +(iot2050) make: *** [sub-make] Error 2 > > > >>>>> 0 0 1 /1 iot2050 > > > >>>>> > > > >>>>> And needs to be handled like ATF/OPTEE/etc where CI can build but > > throw > > > >>>>> a "THIS WILL NOT RUN CORRECTLY" type warning to the user. > > > >>>>> > > > >>>> > > > >>>> I was about to sent an update anyway - time passed, and now we even > > have > > > >>>> support for the next generation integrated from the beginning. But > > > >>>> related upstream DT changes are not yet merged. > > > >>> > > > >>> OK. > > > >>> > > > >>>> But back to this issue: How can CI be fed with all those required > > > >>>> binaries? The build makes no sense in their absence. > > > >>> > > > >>> To be clearer, CI isn't fed all of the binaries, we just use > > /dev/null > > > >>> in that case and try and make it clear it won't boot. K3 isn't a > > good > > > >>> example here, but I think sunxi uses binman and handles this same > > class > > > >>> of problem? > > > >>> > > > >> > > > >> I'm seeing it additionally carrying a "missing-msg" property, but that > > > >> alone (even with missing-blob-help updated) does not make the build > > > >> pass. It rather seems I'm missing some "allow_missing" property for > > that > > > >> image, but even reading the code gives no clue yet how to achieve > > that. > > > >> Yet another binman mystery. > > > > > > > > You might also need a new file in tools/binman/etype/ ? Also, it will > > > > have a non-zero exit status still, but with a value of 101 which we > > > > check for and know that's "binary blob missing" and so OK to allow CI > > to > > > > pass on. > > > > > > > > > > Err, that doesn't sound like binman is making my life easier. Why can't > > > a I simple do something like > > > > > > k3-rti-wdt-firmware { > > > type = "blob"; > > > load = <0x82000000>; > > > blob { > > > filename = CONFIG_WDT_K3_RTI_FW_FILE; > > > missing-msg = "k3-rti-wdt-firmware"; > > > allow_missing; > > > }; > > > }; > > > > > > and be done? > > > > Sounds like a good idea, and I'm not quite sure what's missing to go > > from where we are today to there. I might be missing something myself. > > > > If that entry is located in a DT for U-Boot consumption why not, but in the > DT that is associated to a platform that is passed to the OS, that sounds > like a practice to avoid as this does not describe hardware. Thinking > compatibility, is the filename/filepath really OS independent ? So, here's one of those cases where we aren't really talking about the runtime device tree so much as how we configure the build. binman is how we assemble the assorted binaries in to a functional blob for a given platform without having to write a new tool for every SoC.
diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi index 61745c6c23..8e3f1709e9 100644 --- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi +++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi @@ -59,6 +59,16 @@ filename = "arch/arm/dts/k3-am6548-iot2050-advanced.dtb"; }; }; + +#ifdef CONFIG_WDT_K3_RTI_FW_FILE + k3-rti-wdt-firmware { + type = "blob"; + load = <0x82000000>; + blob { + filename = CONFIG_WDT_K3_RTI_FW_FILE; + }; + }; +#endif }; configurations { @@ -68,12 +78,18 @@ description = "iot2050-basic"; firmware = "u-boot"; fdt = "fdt-iot2050-basic"; +#ifdef CONFIG_WDT_K3_RTI_FW_FILE + loadables = "k3-rti-wdt-firmware"; +#endif }; conf-iot2050-advanced { description = "iot2050-advanced"; firmware = "u-boot"; fdt = "fdt-iot2050-advanced"; +#ifdef CONFIG_WDT_K3_RTI_FW_FILE + loadables = "k3-rti-wdt-firmware"; +#endif }; }; }; diff --git a/configs/iot2050_defconfig b/configs/iot2050_defconfig index 6af8971aa5..b30483f73b 100644 --- a/configs/iot2050_defconfig +++ b/configs/iot2050_defconfig @@ -51,6 +51,7 @@ CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y CONFIG_CMD_REMOTEPROC=y CONFIG_CMD_USB=y +CONFIG_CMD_WDT=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_TIME=y # CONFIG_ISO_PARTITION is not set @@ -129,4 +130,9 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_USB_DWC3_GENERIC=y CONFIG_USB_KEYBOARD=y +# CONFIG_WATCHDOG is not set +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_K3_RTI=y +CONFIG_WDT_K3_RTI_LOAD_FW=y CONFIG_OF_LIBFDT_OVERLAY=y