SDHI polling

SDHI polling

[Simon Horman]

Hi,

I have it in mind to run the SDHI hardware block in some sort of
polling mode - that is, with interrupts disabled - during early
boot. Does this make any sense?

The aim is to be able to read a kernel off an SD card and then boot from it.

Re: SDHI polling

[Magnus Damm]

Hi Simon,

On Mon, Dec 27, 2010 at 7:45 AM, Simon Horman <horms@verge.net.au> wrote:
> I have it in mind to run the SDHI hardware block in some sort of
> polling mode - that is, with interrupts disabled - during early
> boot. Does this make any sense?

I guess it depends on how early you mean. =)

Usually you want to make use of interrupts if they are available, but
for really early code there is no interrupt support. So the in-kernel
early printk support is implemented without any interrupts for
instance. At least this is true for the SCIF driver used by SH and
SH-Mobile / R-Mobile, pretty sure it applies to other hardware
platforms as well.

As for the SDHI version of the MMC loader, I think you should do the
same as the MMCIF loader that is present in
include/linux/mmc/sh_mmcif.h. As you know it gets compiled into a
separate image together with the rest of the zImage loader. No
interrupt handling is available in that code, so just implementing
things using polling mode is good enough.

I'm not 100% sure about U-boot these days, but I wouldn't be surprised
if many boot loaders only implement polling.

Cheers,

/ magnus

Re: SDHI polling

[Paul Mundt]

On Mon, Dec 27, 2010 at 07:59:15AM +0900, Magnus Damm wrote:
> On Mon, Dec 27, 2010 at 7:45 AM, Simon Horman <horms@verge.net.au> wrote:
> > I have it in mind to run the SDHI hardware block in some sort of
> > polling mode - that is, with interrupts disabled - during early
> > boot. Does this make any sense?
> 
> I guess it depends on how early you mean. =)
> 
> Usually you want to make use of interrupts if they are available, but
> for really early code there is no interrupt support. So the in-kernel
> early printk support is implemented without any interrupts for
> instance. At least this is true for the SCIF driver used by SH and
> SH-Mobile / R-Mobile, pretty sure it applies to other hardware
> platforms as well.
> 
> As for the SDHI version of the MMC loader, I think you should do the
> same as the MMCIF loader that is present in
> include/linux/mmc/sh_mmcif.h. As you know it gets compiled into a
> separate image together with the rest of the zImage loader. No
> interrupt handling is available in that code, so just implementing
> things using polling mode is good enough.
> 
> I'm not 100% sure about U-boot these days, but I wouldn't be surprised
> if many boot loaders only implement polling.
> 
That's probably true, but note that most boot loaders do have rudimentary
interrupt stubs for the timer tick and so forth. I wouldn't classify a
boot loader as early code, it's more just half-assed. For true "early"
code polling is probably ok, particularly if you aren't able to continue
on without reading the image from the card. You will probably still want
to be able to track various state changes in order to ease debugging and
work out whether you get stuck or not. If the block raises an exception
for recoverable errors and so on then you're still going to have to deal
with an asynchronous code flow, too.

Re: SDHI polling

[Magnus Damm]

On Mon, Dec 27, 2010 at 8:24 AM, Paul Mundt <lethal@linux-sh.org> wrote:
> On Mon, Dec 27, 2010 at 07:59:15AM +0900, Magnus Damm wrote:
>> On Mon, Dec 27, 2010 at 7:45 AM, Simon Horman <horms@verge.net.au> wrote:
>> > I have it in mind to run the SDHI hardware block in some sort of
>> > polling mode - that is, with interrupts disabled - during early
>> > boot. Does this make any sense?
>>
>> I guess it depends on how early you mean. =)
>>
>> Usually you want to make use of interrupts if they are available, but
>> for really early code there is no interrupt support. So the in-kernel
>> early printk support is implemented without any interrupts for
>> instance. At least this is true for the SCIF driver used by SH and
>> SH-Mobile / R-Mobile, pretty sure it applies to other hardware
>> platforms as well.
>>
>> As for the SDHI version of the MMC loader, I think you should do the
>> same as the MMCIF loader that is present in
>> include/linux/mmc/sh_mmcif.h. As you know it gets compiled into a
>> separate image together with the rest of the zImage loader. No
>> interrupt handling is available in that code, so just implementing
>> things using polling mode is good enough.
>>
>> I'm not 100% sure about U-boot these days, but I wouldn't be surprised
>> if many boot loaders only implement polling.
>>
> That's probably true, but note that most boot loaders do have rudimentary
> interrupt stubs for the timer tick and so forth. I wouldn't classify a
> boot loader as early code, it's more just half-assed. For true "early"
> code polling is probably ok, particularly if you aren't able to continue
> on without reading the image from the card. You will probably still want
> to be able to track various state changes in order to ease debugging and
> work out whether you get stuck or not. If the block raises an exception
> for recoverable errors and so on then you're still going to have to deal
> with an asynchronous code flow, too.

http://git.denx.de/?p=u-boot.git;a=blob;f=arch/sh/cpu/sh4/interrupts.c;hi88ecc7c28d1f345ee9d0b904c8e8b4e3eb8ccb;hbÍc51c294ad33879c4e57edf4c9d2155381b1d59

Re: SDHI polling

[Paul Mundt]

On Mon, Dec 27, 2010 at 08:34:10AM +0900, Magnus Damm wrote:
> On Mon, Dec 27, 2010 at 8:24 AM, Paul Mundt <lethal@linux-sh.org> wrote:
> > On Mon, Dec 27, 2010 at 07:59:15AM +0900, Magnus Damm wrote:
> >> On Mon, Dec 27, 2010 at 7:45 AM, Simon Horman <horms@verge.net.au> wrote:
> >> > I have it in mind to run the SDHI hardware block in some sort of
> >> > polling mode - that is, with interrupts disabled - during early
> >> > boot. Does this make any sense?
> >>
> >> I guess it depends on how early you mean. =)
> >>
> >> Usually you want to make use of interrupts if they are available, but
> >> for really early code there is no interrupt support. So the in-kernel
> >> early printk support is implemented without any interrupts for
> >> instance. At least this is true for the SCIF driver used by SH and
> >> SH-Mobile / R-Mobile, pretty sure it applies to other hardware
> >> platforms as well.
> >>
> >> As for the SDHI version of the MMC loader, I think you should do the
> >> same as the MMCIF loader that is present in
> >> include/linux/mmc/sh_mmcif.h. As you know it gets compiled into a
> >> separate image together with the rest of the zImage loader. No
> >> interrupt handling is available in that code, so just implementing
> >> things using polling mode is good enough.
> >>
> >> I'm not 100% sure about U-boot these days, but I wouldn't be surprised
> >> if many boot loaders only implement polling.
> >>
> > That's probably true, but note that most boot loaders do have rudimentary
> > interrupt stubs for the timer tick and so forth. I wouldn't classify a
> > boot loader as early code, it's more just half-assed. For true "early"
> > code polling is probably ok, particularly if you aren't able to continue
> > on without reading the image from the card. You will probably still want
> > to be able to track various state changes in order to ease debugging and
> > work out whether you get stuck or not. If the block raises an exception
> > for recoverable errors and so on then you're still going to have to deal
> > with an asynchronous code flow, too.
> 
> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/sh/cpu/sh4/interrupts.c;hi88ecc7c28d1f345ee9d0b904c8e8b4e3eb8ccb;hbÍc51c294ad33879c4e57edf4c9d2155381b1d59

Wow, that's really taking half-assed to a whole new level. If only it
were possible to unsee bootloader code.

In any event, just because the boot loader people are useless doesn't
mean you can't set the bar a bit higher for yourself when designing new
features.

Re: SDHI polling

[Simon Horman]

On Mon, Dec 27, 2010 at 07:59:15AM +0900, Magnus Damm wrote:
> Hi Simon,
> 
> On Mon, Dec 27, 2010 at 7:45 AM, Simon Horman <horms@verge.net.au> wrote:
> > I have it in mind to run the SDHI hardware block in some sort of
> > polling mode - that is, with interrupts disabled - during early
> > boot. Does this make any sense?
> 
> I guess it depends on how early you mean. =)
> 
> Usually you want to make use of interrupts if they are available, but
> for really early code there is no interrupt support. So the in-kernel
> early printk support is implemented without any interrupts for
> instance. At least this is true for the SCIF driver used by SH and
> SH-Mobile / R-Mobile, pretty sure it applies to other hardware
> platforms as well.
> 
> As for the SDHI version of the MMC loader, I think you should do the
> same as the MMCIF loader that is present in
> include/linux/mmc/sh_mmcif.h. As you know it gets compiled into a
> separate image together with the rest of the zImage loader. No
> interrupt handling is available in that code, so just implementing
> things using polling mode is good enough.
> 
> I'm not 100% sure about U-boot these days, but I wouldn't be surprised
> if many boot loaders only implement polling.

My plan is to implement the SDHI version of the MMC loader along
the same lines of the MMCIF version. That plan involves early boot
where there are no interrupts.

My question was really to ask if from a hardware point of view it is
possible/reasonable to read from an MMC card using SHDI without interrupts.
I gather that the answer is yes.

If the answer is no then I will need to deviate from my
based-on-MMCIF-MMC-boot plan.

Re: SDHI polling

[Magnus Damm]

On Mon, Dec 27, 2010 at 9:23 AM, Simon Horman <horms@verge.net.au> wrote:
> On Mon, Dec 27, 2010 at 07:59:15AM +0900, Magnus Damm wrote:
>> Hi Simon,
>>
>> On Mon, Dec 27, 2010 at 7:45 AM, Simon Horman <horms@verge.net.au> wrote:
>> > I have it in mind to run the SDHI hardware block in some sort of
>> > polling mode - that is, with interrupts disabled - during early
>> > boot. Does this make any sense?
>>
>> I guess it depends on how early you mean. =)
>>
>> Usually you want to make use of interrupts if they are available, but
>> for really early code there is no interrupt support. So the in-kernel
>> early printk support is implemented without any interrupts for
>> instance. At least this is true for the SCIF driver used by SH and
>> SH-Mobile / R-Mobile, pretty sure it applies to other hardware
>> platforms as well.
>>
>> As for the SDHI version of the MMC loader, I think you should do the
>> same as the MMCIF loader that is present in
>> include/linux/mmc/sh_mmcif.h. As you know it gets compiled into a
>> separate image together with the rest of the zImage loader. No
>> interrupt handling is available in that code, so just implementing
>> things using polling mode is good enough.
>>
>> I'm not 100% sure about U-boot these days, but I wouldn't be surprised
>> if many boot loaders only implement polling.
>
> My plan is to implement the SDHI version of the MMC loader along
> the same lines of the MMCIF version. That plan involves early boot
> where there are no interrupts.
>
> My question was really to ask if from a hardware point of view it is
> possible/reasonable to read from an MMC card using SHDI without interrupts.
> I gather that the answer is yes.

I believe that is possible, yes. Maybe you can ask around for some
out-of-tree SDHI u-boot excellence to use as an example. I imagine
such code may use polling. =)

> If the answer is no then I will need to deviate from my
> based-on-MMCIF-MMC-boot plan.

No need to deviate IMO.  Also, I don't think it's worth implementing
interrupt handling in the tiny zImage decompressor blob.

Thanks,

/ magnus

Re: SDHI polling

[Magnus Damm]

On Mon, Dec 27, 2010 at 9:10 AM, Paul Mundt <lethal@linux-sh.org> wrote:
> On Mon, Dec 27, 2010 at 08:34:10AM +0900, Magnus Damm wrote:
>> On Mon, Dec 27, 2010 at 8:24 AM, Paul Mundt <lethal@linux-sh.org> wrote:
>> > On Mon, Dec 27, 2010 at 07:59:15AM +0900, Magnus Damm wrote:
>> >> On Mon, Dec 27, 2010 at 7:45 AM, Simon Horman <horms@verge.net.au> wrote:
>> >> > I have it in mind to run the SDHI hardware block in some sort of
>> >> > polling mode - that is, with interrupts disabled - during early
>> >> > boot. Does this make any sense?
>> >>
>> >> I guess it depends on how early you mean. =)
>> >>
>> >> Usually you want to make use of interrupts if they are available, but
>> >> for really early code there is no interrupt support. So the in-kernel
>> >> early printk support is implemented without any interrupts for
>> >> instance. At least this is true for the SCIF driver used by SH and
>> >> SH-Mobile / R-Mobile, pretty sure it applies to other hardware
>> >> platforms as well.
>> >>
>> >> As for the SDHI version of the MMC loader, I think you should do the
>> >> same as the MMCIF loader that is present in
>> >> include/linux/mmc/sh_mmcif.h. As you know it gets compiled into a
>> >> separate image together with the rest of the zImage loader. No
>> >> interrupt handling is available in that code, so just implementing
>> >> things using polling mode is good enough.
>> >>
>> >> I'm not 100% sure about U-boot these days, but I wouldn't be surprised
>> >> if many boot loaders only implement polling.
>> >>
>> > That's probably true, but note that most boot loaders do have rudimentary
>> > interrupt stubs for the timer tick and so forth. I wouldn't classify a
>> > boot loader as early code, it's more just half-assed. For true "early"
>> > code polling is probably ok, particularly if you aren't able to continue
>> > on without reading the image from the card. You will probably still want
>> > to be able to track various state changes in order to ease debugging and
>> > work out whether you get stuck or not. If the block raises an exception
>> > for recoverable errors and so on then you're still going to have to deal
>> > with an asynchronous code flow, too.
>>
>> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/sh/cpu/sh4/interrupts.c;hi88ecc7c28d1f345ee9d0b904c8e8b4e3eb8ccb;hbÍc51c294ad33879c4e57edf4c9d2155381b1d59
>
> Wow, that's really taking half-assed to a whole new level. If only it
> were possible to unsee bootloader code.

Perhaps you would like me to send links to code for other unnamed architectures?

> In any event, just because the boot loader people are useless doesn't
> mean you can't set the bar a bit higher for yourself when designing new
> features.

Sure, but I don't think that raising the bar by implementing interrupt
support is a good idea in this case. This since all you're doing is
loading a kernel image from a single device.

/ magnus

Re: SDHI polling

[Simon Horman]

On Mon, Dec 27, 2010 at 09:57:50AM +0900, Magnus Damm wrote:
> On Mon, Dec 27, 2010 at 9:23 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Mon, Dec 27, 2010 at 07:59:15AM +0900, Magnus Damm wrote:
> >> Hi Simon,
> >>
> >> On Mon, Dec 27, 2010 at 7:45 AM, Simon Horman <horms@verge.net.au> wrote:
> >> > I have it in mind to run the SDHI hardware block in some sort of
> >> > polling mode - that is, with interrupts disabled - during early
> >> > boot. Does this make any sense?
> >>
> >> I guess it depends on how early you mean. =)
> >>
> >> Usually you want to make use of interrupts if they are available, but
> >> for really early code there is no interrupt support. So the in-kernel
> >> early printk support is implemented without any interrupts for
> >> instance. At least this is true for the SCIF driver used by SH and
> >> SH-Mobile / R-Mobile, pretty sure it applies to other hardware
> >> platforms as well.
> >>
> >> As for the SDHI version of the MMC loader, I think you should do the
> >> same as the MMCIF loader that is present in
> >> include/linux/mmc/sh_mmcif.h. As you know it gets compiled into a
> >> separate image together with the rest of the zImage loader. No
> >> interrupt handling is available in that code, so just implementing
> >> things using polling mode is good enough.
> >>
> >> I'm not 100% sure about U-boot these days, but I wouldn't be surprised
> >> if many boot loaders only implement polling.
> >
> > My plan is to implement the SDHI version of the MMC loader along
> > the same lines of the MMCIF version. That plan involves early boot
> > where there are no interrupts.
> >
> > My question was really to ask if from a hardware point of view it is
> > possible/reasonable to read from an MMC card using SHDI without interrupts.
> > I gather that the answer is yes.
> 
> I believe that is possible, yes. Maybe you can ask around for some
> out-of-tree SDHI u-boot excellence to use as an example. I imagine
> such code may use polling. =)

Good thinking.

Re: SDHI polling

[Paul Mundt]

On Mon, Dec 27, 2010 at 10:03:06AM +0900, Magnus Damm wrote:
> On Mon, Dec 27, 2010 at 9:10 AM, Paul Mundt <lethal@linux-sh.org> wrote:
> > In any event, just because the boot loader people are useless doesn't
> > mean you can't set the bar a bit higher for yourself when designing new
> > features.
> 
> Sure, but I don't think that raising the bar by implementing interrupt
> support is a good idea in this case. This since all you're doing is
> loading a kernel image from a single device.
> 
I agree that things should be kept as simple as possible, we basically
want as few variables that can lead to failure as possible at that stage.
If this can be accomplished without having to model some sort of an
asynchronous state machine, then of course that's the most
straightforward.

The entire point after all is to get away from this sort of boot loader
ineptitude, so we don't really want to recreate a boot loader within the
image loading stubs as a replacement.

I don't know enough about how SDHI works to have any strong opinions on
the matter one way or the other, but one does need to keep in mind that
cards will degrade over time and will need to have recoverable errors
handled for any sort of real-world application, whether this is something
we will invariably have to install an exception handler for or not I
don't know. Ideally if there is some retry logic in the mask ROM then
this all gets much simpler.

Re: SDHI polling

[Simon Horman]

On Mon, Dec 27, 2010 at 10:36:49AM +0900, Paul Mundt wrote:
> On Mon, Dec 27, 2010 at 10:03:06AM +0900, Magnus Damm wrote:
> > On Mon, Dec 27, 2010 at 9:10 AM, Paul Mundt <lethal@linux-sh.org> wrote:
> > > In any event, just because the boot loader people are useless doesn't
> > > mean you can't set the bar a bit higher for yourself when designing new
> > > features.
> > 
> > Sure, but I don't think that raising the bar by implementing interrupt
> > support is a good idea in this case. This since all you're doing is
> > loading a kernel image from a single device.
> > 
> I agree that things should be kept as simple as possible, we basically
> want as few variables that can lead to failure as possible at that stage.
> If this can be accomplished without having to model some sort of an
> asynchronous state machine, then of course that's the most
> straightforward.

Agreed.

> The entire point after all is to get away from this sort of boot loader
> ineptitude, so we don't really want to recreate a boot loader within the
> image loading stubs as a replacement.
> 
> I don't know enough about how SDHI works to have any strong opinions on
> the matter one way or the other, but one does need to keep in mind that
> cards will degrade over time and will need to have recoverable errors
> handled for any sort of real-world application, whether this is something
> we will invariably have to install an exception handler for or not I
> don't know. Ideally if there is some retry logic in the mask ROM then
> this all gets much simpler.

I am also not sufficiently familiar with the SHDI to answer that yet.

Re: SDHI polling

[Magnus Damm]

On Mon, Dec 27, 2010 at 10:36 AM, Paul Mundt <lethal@linux-sh.org> wrote:
> On Mon, Dec 27, 2010 at 10:03:06AM +0900, Magnus Damm wrote:
>> On Mon, Dec 27, 2010 at 9:10 AM, Paul Mundt <lethal@linux-sh.org> wrote:
>> > In any event, just because the boot loader people are useless doesn't
>> > mean you can't set the bar a bit higher for yourself when designing new
>> > features.
>>
>> Sure, but I don't think that raising the bar by implementing interrupt
>> support is a good idea in this case. This since all you're doing is
>> loading a kernel image from a single device.
>>
> I agree that things should be kept as simple as possible, we basically
> want as few variables that can lead to failure as possible at that stage.
> If this can be accomplished without having to model some sort of an
> asynchronous state machine, then of course that's the most
> straightforward.
>
> The entire point after all is to get away from this sort of boot loader
> ineptitude, so we don't really want to recreate a boot loader within the
> image loading stubs as a replacement.

Exactly.

> I don't know enough about how SDHI works to have any strong opinions on
> the matter one way or the other, but one does need to keep in mind that
> cards will degrade over time and will need to have recoverable errors
> handled for any sort of real-world application, whether this is something
> we will invariably have to install an exception handler for or not I
> don't know. Ideally if there is some retry logic in the mask ROM then
> this all gets much simpler.

There is most likely some retry logic in the Mask ROM. At least the
MMCIF Mask ROM code does retry according to the docs I've seen.

On top of that we do probably need to make the MMCIF/SDHI loader code
more robust. I suspect that most errors can be dealt with by just
implementing correct error handing of status flag bits in each
"driver", ie MMCIF/SDHI loader code. If that's not enough then we may
have to checksum the image as well. I don't think any exceptions will
be raised.

Just loading the image as a first step would most likely put us on a
similar level as U-boot.

/ magnus