Re: [RFC PATCH 3/7] bootm: add kexec ELF support
On Sun, Apr 29, 2018 at 03:09:03PM +0200, Oleksij Rempel wrote:
> +static int do_bootm_elf(struct image_data *data)
> +{
> + kexec_load_bootm_data(data);
> +
> + reboot(LINUX_REBOOT_CMD_KEXEC, data);
> +
> + return -ERESTARTSYS;
> +}
> +
I can't really judge this series. This is the only thing I stumbled
upon: I see no reason to name the architecture specific kexec function
'reboot'. I would expect some kexec specific name, like arch_kexec or
similar.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [RESEND PATCH v2 0/2] Initial RAVE SP Linux driver port
On Wed, May 02, 2018 at 12:36:51PM -0700, Andrey Smirnov wrote: > Everyone: > > These two patches are first results of an effort to port RAVE SP > (Supervisory Processor) MFD and it's children drivers from Linux > kernel to Barebox. Patch 1/2 brings MFD driver with its core API and > patch 2/2 adds support for watchdog "cell" of the RAVE SP device. > > With a very few exceptions, the code of the drivers is identical to > the code of their Linux counterparts. > > These drivers are also first users of "serdev" API work that was > recently merged and should server as a reasonable example of its > usage. > > Feedback is wellcome! > > Changes since [v1]: > > - rave_sp_wdt_set_timeout fixed to correctly handle timeout of zero >(as pointed out by Sascha) > > Thanks, > Andrey Smirnov Applied, thanks Sascha > > [v1] http://lists.infradead.org/pipermail/barebox/2018-April/032725.html > > Andrey Smirnov (2): > mfd: Port RAVE SP driver from Linux kernel > watchdog: Port RAVE SP watchdog driver from Linux kernel > > drivers/mfd/Kconfig| 8 + > drivers/mfd/Makefile | 1 + > drivers/mfd/rave-sp.c | 758 > + > drivers/watchdog/Kconfig | 5 + > drivers/watchdog/Makefile | 1 + > drivers/watchdog/rave-sp-wdt.c | 426 +++ > include/linux/mfd/rave-sp.h| 78 + > 7 files changed, 1277 insertions(+) > create mode 100644 drivers/mfd/rave-sp.c > create mode 100644 drivers/watchdog/rave-sp-wdt.c > create mode 100644 include/linux/mfd/rave-sp.h > > -- > 2.14.3 > > > ___ > barebox mailing list > barebox@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/barebox > -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH] blspec: add checking of optional key machine-id
On 03.05.2018 11:34, Jan Lübbe wrote:
[...]
>>> Then the existing selection logic would
>>> handle your case as well.
>> Ohh ... ok. And could you explain please, who we could do that? Because,
>> all our DTs are compatible with barebox DT and barebox would choose simple
>> the first one and boot it. Or is using of Bootloader Spec isn't right
>> way, to solve this issue?
> So in the barebox DT you'd have:
> / {
> model = "Foo Common i.MX6 Board";
> compatible = "foo,mx6-common", "fsl,imx6q";
> };
> [...]
>
> Then for the kernel DTs you can use different compatible lists, which
> each use a different and more specific entry.
>
> mx6-variant1.dts:
> / {
> model = "Foo Variant 1 i.MX6 Board";
> compatible =
> "foo,mx6-variant1", "foo,mx6-common", "fsl,imx6q";
> };
> [...]
>
> mx6-variant2.dts:
> / {
> model = "Foo Variant 2 i.MX6 Board";
> compatible = "foo,mx6-variant2", "foo,mx6-common", "fsl,imx6q";
> };
> [...]
>
> Then, in barebox, you need to have a way to override which compatible
> string the bootspec code is looking for.
Ok, the way is to override/extend barebox DT compatible string while
initialisation,
so barebox would be match only one boot entry.
> I'd prefer this to the machine-id approach, as the DT compatible list
> mechanism is designed exactly for handing these different levels of
> compatibility declarations.
Yes, I agree with you. That could be better for us to solve our issue.
Thank you for explanation!
Do your mean, for using the machine-id in right way, the patch could be
apply?
If Sascha still agree, of course.
Regards,
Andreas
0xFEE0A611BEA6DEA0.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH] blspec: add checking of optional key machine-id
On Thu, 2018-05-03 at 10:42 +0200, Andreas Schmidt wrote:
> > Your use-case sound like you'd need a way to add a more specific DT
> > board compatible at runtime.
>
> We need a decision witch DT has to be load at runtime. But they are all
> compatible with the barebox DT. We have only one barebox DT for all devices.
Yes. So you have additional device declarations in the kernel device
trees, which are not relevant to barebox.
> > Then the existing selection logic would
> > handle your case as well.
>
> Ohh ... ok. And could you explain please, who we could do that? Because,
> all our DTs are compatible with barebox DT and barebox would choose simple
> the first one and boot it. Or is using of Bootloader Spec isn't right
> way, to solve this issue?
So in the barebox DT you'd have:
/ {
model = "Foo Common i.MX6 Board";
compatible = "foo,mx6-common", "fsl,imx6q";
};
[...]
Then for the kernel DTs you can use different compatible lists, which
each use a different and more specific entry.
mx6-variant1.dts:
/ {
model = "Foo Variant 1 i.MX6 Board";
compatible =
"foo,mx6-variant1", "foo,mx6-common", "fsl,imx6q";
};
[...]
mx6-variant2.dts:
/ {
model = "Foo Variant 2 i.MX6 Board";
compatible = "foo,mx6-variant2", "foo,mx6-common", "fsl,imx6q";
};
[...]
Then, in barebox, you need to have a way to override which compatible
string the bootspec code is looking for.
I'd prefer this to the machine-id approach, as the DT compatible list
mechanism is designed exactly for handing these different levels of
compatibility declarations.
Regards,
Jan
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH] blspec: add checking of optional key machine-id
Hallo Jan, On 02.05.2018 16:32, Jan Lübbe wrote: > On Sun, 2018-04-29 at 18:01 +0200, Andreas Schmidt wrote: >> I guess, for such an use case Bootloader Spec specify "machine-id" >> key. This patch implement the support for machine-id key. > The way I read https://www.freedesktop.org/wiki/Specifications/BootLoad > erSpec/ is that the "machine-id" field should contain the ID from > /etc/machine-id, which is basically a UUID: > "machine-id shall contain the machine ID of the OS /etc/machine-id. > This is useful for boot loaders and applications to filter out boot > entries, for example to show only a single newest kernel per OS, or to > group items by OS, or to maybe filter out the currently booted OS in > UIs that want to show only other installed operating systems." I read this part in same way. I think, the patch isn't in conflict with that. And, yes, you're right we would use it not exact in this way. Out /etc/machine-id is building dynamically and would be the same as barebox choose one. (Same way to set global.boot.machine_id and content of /etc/machine-id) But, all our FW would have different machine-id in dependent of devices and not on OS. The spec says: "for example to show only ...". So I guess, it is not hard requirement. Was I'm wrong? > Your use-case sound like you'd need a way to add a more specific DT > board compatible at runtime. We need a decision witch DT has to be load at runtime. But they are all compatible with the barebox DT. We have only one barebox DT for all devices. > Then the existing selection logic would > handle your case as well. Ohh ... ok. And could you explain please, who we could do that? Because, all our DTs are compatible with barebox DT and barebox would choose simple the first one and boot it. Or is using of Bootloader Spec isn't right way, to solve this issue? Regards, Andreas 0xFEE0A611BEA6DEA0.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH v2 03/10] ARM: i.MX6: Record reset reason as a part of startup
On Wed, 2018-05-02 at 10:46 -0700, Andrey Smirnov wrote: > On Wed, May 2, 2018 at 7:42 AM, Jan Lübbe wrote: > > There is already code in drivers/watchdog/imxwd.c to handle this. > > Is that obsolete now? > > AFAIK, watchdog IP block doesn't have as precise information about > reset source as SRSR register on i.MX SoCs that have the latter. > There, this code supersedes imxwd.c. OTHO SoCs that don't have SRSR > (i.MX21, i.MX31, etc) still rely on code imxwd.c for reset source > detection. > > Hope this answers your question. Yes, thanks. I didn't realize that these were different registers. Regards, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
