Hello,
On 2015-01-28 15:24, Ulf Hansson wrote:
On 28 January 2015 at 14:59, Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> wrote:
There are boards (like Hardkernel's Odroid boards) on which eMMC card's
reset line is connected to GPIO line instead of the hardware reset
logic. In case of such boards, if first stage of bootloader is loaded
from such eMMC card, before performing system reboot, additional reset
of eMMC card is required to properly boot the whole system again. This
patch adds code for handling reset gpio lines defined in device tree.
I don't follow the above sequence. Can you try to elaborate and
describe for what exact scenario we require the hardware reset to be
done?
Odroid boards uses multi stage bootloaders. The very first stage is in
SoC ROM.
That code loads next stages (called bl1, bl2, tz) from either eMMC or SD
card
(depending on jumper configuration or some card detect pins). This ROM
code is
very simple and assumes that the mmc card has been reset to the default
configuration. However, eMMC card is not being reset by the board
'reboot' logic.
Instead the nreset line from emmc card is connected to gpio line of SoC.
Thus to
perform full system reboot procedure, before triggering reboot inside
the SoC,
one need to manually toggle nreset line of this emmc card to 'zero' for
a while.
Only then the card is put back to the default state, so ROM code is able
to read
bootloaders from it.
My patch adds code for managing gpio line connected to nreset signal of
emmc card.
It registers reset handler, which is being triggered from Linux reboot
code. This
handler toggles such gpio line before the final reboot is triggered. My
patch also
provides a function for registering as a mmc host hw_reset callback, so
it can be
used to reset mmc card before initializing it with kernel driver (this
is already
implemented), which also might help to get it working if broken
bootloader left
the emmc card in some unknown/broken state (already observed such issue,
but it
has been fixed finally by patching bootloader).
Also, I wonder whether we could extend the mmc-pwrseq to cover your
case? Did you consider that as an option?
I didn't consider mmc-pwrseq yet. For me it looked straightforward to
implement
it just like card detect or write-protection gpio pins. I already
noticed that
there is code for some mmc host driver, which perform mmc hardware
reset. If you
think that extending pwrseq is the better approach, I will try to update my
patches. This will add reboot handler to mmc-pwrseq then. The only
question is
weather to use it always when mmc-pwrseq has been enabled or only if some
additional property like 'reset-on-reboot' has been provided.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
