From: Nikita Kiryanov <nikita@compulab.co.il>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V2 3/4] common: introduce board_preboot_os hook
Date: Thu, 06 Nov 2014 13:31:36 +0200 [thread overview]
Message-ID: <545B5C18.3020401@compulab.co.il> (raw)
In-Reply-To: <545A18CF.6080604@denx.de>
Hi Stefano,
On 11/05/2014 02:32 PM, Stefano Babic wrote:
> Hi Nikita,
>
> On 29/10/2014 16:56, Nikita Kiryanov wrote:
>> Introduce board specific function board_preboot_os() to allow for board
>> specific config before we boot.
>>
>> Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
>> Cc: Igor Grinberg <grinberg@compulab.co.il>
>> Cc: Stefano Babic <sbabic@denx.de>
>> Cc: Tom Rini <trini@ti.com>
>> Cc: Jeroen Hofstee <jeroen@myspectrum.nl>
>> Cc: Otavio Salvador <otavio@ossystems.com.br>
>> ---
>> Changes in V2:
>> - Added board_preboot_os to bootm.h
>> - Split cm_fx6 stuff into a separate patch
>>
>> common/bootm_os.c | 7 +++++++
>> include/bootm.h | 1 +
>> 2 files changed, 8 insertions(+)
>>
>
> There is something that does not convince me. Really, the general
> statement should be to turn all devices off before booting the kernel,
> because this is what Linux expects. That said, this could be later
> solved with dm, because we will can iterate through all drivers and call
> a shutdown function.
>
> Currently, "preboot" functions are turning off the hardware, so the name
> is already misleading. And I see that arch_preboot_os() was also
> convinced (because it is weak) to become a board_preboot, for example
> here: board/renesas/koelsch/koelsch.c (and in other renesas
> implementation, too).
>
> I have some concerns adding a new weak function, that enables some
> further hooks inside board code. I find it not well scalable.
> In your case, you need such as sata_shutdown(), and it should be
> responsibility of the general sata code to call something specific for
> the board, if necessary.
>
> In current code, bootm_disable_interrupts() calls also usb_stop() and
> eth_halt(), - nothing to do with the name of the function. IMHO it
> should be better to move the code to shutdown interface inside
> boot_selected_os(), or having a common function "disable_hardware()"
> that calls usb_stop(), eth_halt() and then, why not, a sata_stop().
>
> There is also in arch/arm/imx-common/cpu.c a derived implementation for
> arch_preboot_os(). Really it has nothing to do with arch, as I can see:
> it shuts down only the IPU. But it is another hook, and IMHO it is
> better stopping sata here as adding a hidden callback.
You make some good points.
I'll switch to using arch_preboot_os until there's a better way of doing
this.
--
Regards,
Nikita Kiryanov
next prev parent reply other threads:[~2014-11-06 11:31 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-29 15:56 [U-Boot] [PATCH V2 0/4] cm-fx6 updates Nikita Kiryanov
2014-10-29 15:56 ` [U-Boot] [PATCH V2 1/4] arm: mx6: cm_fx6: change issd gpio order Nikita Kiryanov
2014-10-29 16:01 ` Nikita Kiryanov
2014-11-02 14:33 ` Igor Grinberg
2014-10-29 15:56 ` [U-Boot] [PATCH V2 2/4] arm: mx6: cm_fx6: detect 1GB DRAM correctly on solo Nikita Kiryanov
2014-10-29 16:02 ` Nikita Kiryanov
2014-11-02 14:34 ` Igor Grinberg
2014-10-29 15:56 ` [U-Boot] [PATCH V2 3/4] common: introduce board_preboot_os hook Nikita Kiryanov
2014-10-29 15:59 ` Otavio Salvador
2014-11-02 14:36 ` Igor Grinberg
2014-11-05 12:32 ` Stefano Babic
2014-11-06 11:31 ` Nikita Kiryanov [this message]
2014-10-29 15:56 ` [U-Boot] [PATCH V2 4/4] arm: mx6: cm_fx6: power down sata on OS boot Nikita Kiryanov
2014-10-29 15:59 ` Otavio Salvador
2014-11-02 14:36 ` Igor Grinberg
2014-11-05 16:19 ` [U-Boot] [PATCH V2 0/4] cm-fx6 updates Stefano Babic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=545B5C18.3020401@compulab.co.il \
--to=nikita@compulab.co.il \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.