/dev/disk0 vs /dev/mmc0

/dev/disk0 vs /dev/mmc0

[David Jander]

Hi all,

I am following barebox git closely and noticed a change recently: Device names
for MMC (MCI) and USB mass-storage devices have changed to the
generic "/dev/diskX". Earlier an MMC device was named "/dev/mmc0".
Unfortunately this change breaks my /env/bin/init script and I don't know how
to fix it. I relied on the existence of certain devices to distinguish between
USB mass-storage device presence and/or SD-card presence. How can I do this
with this new device naming convention?

I used to have these kind of checks in /env/bin/init:

# Mount MMC (first partition) if available
if [ -e "/dev/mmc0.0" ]; then
        mkdir /mmc
        mount /dev/mmc0.0 /mmc
        if [ -e "/mmc/uImage" ]; then
                boot_target="mmc"
        fi
fi

Booting like this is only allowed from MMC and not from USB, and now it seems
impossible to distinguish between them anymore.

Btw, why was this changed in the first place?

Best regards,

-- 
David Jander
Protonic Holland.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: /dev/disk0 vs /dev/mmc0

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:17 Thu 03 Oct     , David Jander wrote:
> 
> Hi all,
> 
> I am following barebox git closely and noticed a change recently: Device names
> for MMC (MCI) and USB mass-storage devices have changed to the
> generic "/dev/diskX". Earlier an MMC device was named "/dev/mmc0".
> Unfortunately this change breaks my /env/bin/init script and I don't know how
> to fix it. I relied on the existence of certain devices to distinguish between
> USB mass-storage device presence and/or SD-card presence. How can I do this
> with this new device naming convention?
> 
> I used to have these kind of checks in /env/bin/init:
> 
> # Mount MMC (first partition) if available
> if [ -e "/dev/mmc0.0" ]; then
>         mkdir /mmc
>         mount /dev/mmc0.0 /mmc
>         if [ -e "/mmc/uImage" ]; then
>                 boot_target="mmc"
>         fi
> fi
> 
> Booting like this is only allowed from MMC and not from USB, and now it seems
> impossible to distinguish between them anymore.
> 
> Btw, why was this changed in the first place?

now you an use devname parameter to specify a specifc name for mmc

not all the drivers have the platform_data update to support but it will be
easy enough to add it

I recently add this to atmel_mci and animeo_ip board

and I recomment you to switch to defaultenv-2 for this

and use boot sequence this will simplify your env hugely

Best Regards,
J.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: /dev/disk0 vs /dev/mmc0

[David Jander]

Hi Jean-Christophe,

On Thu, 3 Oct 2013 21:23:49 +0200
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote:

> On 17:17 Thu 03 Oct     , David Jander wrote:
> > 
> > Hi all,
> > 
> > I am following barebox git closely and noticed a change recently: Device
> > names for MMC (MCI) and USB mass-storage devices have changed to the
> > generic "/dev/diskX". Earlier an MMC device was named "/dev/mmc0".
> > Unfortunately this change breaks my /env/bin/init script and I don't know
> > how to fix it. I relied on the existence of certain devices to distinguish
> > between USB mass-storage device presence and/or SD-card presence. How can
> > I do this with this new device naming convention?
> > 
> > I used to have these kind of checks in /env/bin/init:
> > 
> > # Mount MMC (first partition) if available
> > if [ -e "/dev/mmc0.0" ]; then
> >         mkdir /mmc
> >         mount /dev/mmc0.0 /mmc
> >         if [ -e "/mmc/uImage" ]; then
> >                 boot_target="mmc"
> >         fi
> > fi
> > 
> > Booting like this is only allowed from MMC and not from USB, and now it
> > seems impossible to distinguish between them anymore.
> > 
> > Btw, why was this changed in the first place?
> 
> now you an use devname parameter to specify a specifc name for mmc

My board is fully device-tree based, but your suggestion pointed me in the
right direction: the "alias" section seems to have a whole new meaning now ;-)
I hope this won't interfere with Linux, since I intend to use a single DT for
both Barebox _and_ Linux.

> not all the drivers have the platform_data update to support but it will be
> easy enough to add it
> 
> I recently add this to atmel_mci and animeo_ip board

Didn't find that one... probably not in mainline yet? Never mind.

> and I recomment you to switch to defaultenv-2 for this
> 
> and use boot sequence this will simplify your env hugely

Although I agree defaultenv-2 looks pretty cool and will add a lot of
convenience and flexibility for complex systems, IMHO it will not simplify the
env of this board the least bit :-)
In fact, on a simple embedded system that has to have a strictly predefined
boot-behavior with a few simple rules, it is overly complex and if an
"outsider" ever needs to understand how it works, that can be a bit of a
problem (the default boot path probably going through some 5 different
scripts with lots of compound config-variables).

Best regards,

-- 
David Jander
Protonic Holland.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: /dev/disk0 vs /dev/mmc0

[Sascha Hauer]

On Fri, Oct 04, 2013 at 09:17:39AM +0200, David Jander wrote:
> 
> Hi Jean-Christophe,
> 
> On Thu, 3 Oct 2013 21:23:49 +0200
> Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote:
> 
> > On 17:17 Thu 03 Oct     , David Jander wrote:
> > > 
> > > Hi all,
> > > 
> > > I am following barebox git closely and noticed a change recently: Device
> > > names for MMC (MCI) and USB mass-storage devices have changed to the
> > > generic "/dev/diskX". Earlier an MMC device was named "/dev/mmc0".
> > > Unfortunately this change breaks my /env/bin/init script and I don't know
> > > how to fix it. I relied on the existence of certain devices to distinguish
> > > between USB mass-storage device presence and/or SD-card presence. How can
> > > I do this with this new device naming convention?
> > > 
> > > I used to have these kind of checks in /env/bin/init:
> > > 
> > > # Mount MMC (first partition) if available
> > > if [ -e "/dev/mmc0.0" ]; then
> > >         mkdir /mmc
> > >         mount /dev/mmc0.0 /mmc
> > >         if [ -e "/mmc/uImage" ]; then
> > >                 boot_target="mmc"
> > >         fi
> > > fi
> > > 
> > > Booting like this is only allowed from MMC and not from USB, and now it
> > > seems impossible to distinguish between them anymore.
> > > 
> > > Btw, why was this changed in the first place?
> > 
> > now you an use devname parameter to specify a specifc name for mmc
> 
> My board is fully device-tree based, but your suggestion pointed me in the
> right direction: the "alias" section seems to have a whole new meaning now ;-)
> I hope this won't interfere with Linux, since I intend to use a single DT for
> both Barebox _and_ Linux.

It doesn't interfere with the kernel. The kernel currently ignores this
aliases. There are patches floating to let the kernel honor this
aliases, but then they should simply have the same effect as they have
in barebox.

> 
> > not all the drivers have the platform_data update to support but it will be
> > easy enough to add it
> > 
> > I recently add this to atmel_mci and animeo_ip board
> 
> Didn't find that one... probably not in mainline yet? Never mind.
> 
> > and I recomment you to switch to defaultenv-2 for this
> > 
> > and use boot sequence this will simplify your env hugely
> 
> Although I agree defaultenv-2 looks pretty cool and will add a lot of
> convenience and flexibility for complex systems, IMHO it will not simplify the
> env of this board the least bit :-)
> In fact, on a simple embedded system that has to have a strictly predefined
> boot-behavior with a few simple rules, it is overly complex and if an
> "outsider" ever needs to understand how it works, that can be a bit of a
> problem (the default boot path probably going through some 5 different
> scripts with lots of compound config-variables).

At least I recently replaced the boot script with a command (not yet
mainline), so there are fewer scripts involved.

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-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: /dev/disk0 vs /dev/mmc0

[Jean-Christophe PLAGNIOL-VILLARD]

On 12:39 Sun 06 Oct     , Sascha Hauer wrote:
> On Fri, Oct 04, 2013 at 09:17:39AM +0200, David Jander wrote:
> > 
> > Hi Jean-Christophe,
> > 
> > On Thu, 3 Oct 2013 21:23:49 +0200
> > Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote:
> > 
> > > On 17:17 Thu 03 Oct     , David Jander wrote:
> > > > 
> > > > Hi all,
> > > > 
> > > > I am following barebox git closely and noticed a change recently: Device
> > > > names for MMC (MCI) and USB mass-storage devices have changed to the
> > > > generic "/dev/diskX". Earlier an MMC device was named "/dev/mmc0".
> > > > Unfortunately this change breaks my /env/bin/init script and I don't know
> > > > how to fix it. I relied on the existence of certain devices to distinguish
> > > > between USB mass-storage device presence and/or SD-card presence. How can
> > > > I do this with this new device naming convention?
> > > > 
> > > > I used to have these kind of checks in /env/bin/init:
> > > > 
> > > > # Mount MMC (first partition) if available
> > > > if [ -e "/dev/mmc0.0" ]; then
> > > >         mkdir /mmc
> > > >         mount /dev/mmc0.0 /mmc
> > > >         if [ -e "/mmc/uImage" ]; then
> > > >                 boot_target="mmc"
> > > >         fi
> > > > fi
> > > > 
> > > > Booting like this is only allowed from MMC and not from USB, and now it
> > > > seems impossible to distinguish between them anymore.
> > > > 
> > > > Btw, why was this changed in the first place?
> > > 
> > > now you an use devname parameter to specify a specifc name for mmc
> > 
> > My board is fully device-tree based, but your suggestion pointed me in the
> > right direction: the "alias" section seems to have a whole new meaning now ;-)
> > I hope this won't interfere with Linux, since I intend to use a single DT for
> > both Barebox _and_ Linux.
> 
> It doesn't interfere with the kernel. The kernel currently ignores this
> aliases. There are patches floating to let the kernel honor this
> aliases, but then they should simply have the same effect as they have
> in barebox.
> 
> > 
> > > not all the drivers have the platform_data update to support but it will be
> > > easy enough to add it
> > > 
> > > I recently add this to atmel_mci and animeo_ip board
> > 
> > Didn't find that one... probably not in mainline yet? Never mind.
> > 
> > > and I recomment you to switch to defaultenv-2 for this
> > > 
> > > and use boot sequence this will simplify your env hugely
> > 
> > Although I agree defaultenv-2 looks pretty cool and will add a lot of
> > convenience and flexibility for complex systems, IMHO it will not simplify the
> > env of this board the least bit :-)
> > In fact, on a simple embedded system that has to have a strictly predefined
> > boot-behavior with a few simple rules, it is overly complex and if an
> > "outsider" ever needs to understand how it works, that can be a bit of a
> > problem (the default boot path probably going through some 5 different
> > scripts with lots of compound config-variables).
> 
> At least I recently replaced the boot script with a command (not yet
> mainline), so there are fewer scripts involved.

and I hope we can kill the old defaultenv soon
for my board I just need to resend the bootp support

Best Regards,
J.
> 
> 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-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: /dev/disk0 vs /dev/mmc0

[Sascha Hauer]

On Mon, Oct 07, 2013 at 08:32:03AM +0200, David Jander wrote:
> 
> Dear Sascha,
> 
> On Sun, 6 Oct 2013 12:39:50 +0200
> Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > 
> > It doesn't interfere with the kernel. The kernel currently ignores this
> > aliases. There are patches floating to let the kernel honor this
> > aliases, but then they should simply have the same effect as they have
> > in barebox.
> 
> That doesn't _feel_ right. Changing standard device names in Linux via aliases
> in the DT might be a fancy idea, but it'd have a different reason/use-case
> than in the case of barebox. IMHO using the same DT for both seems to be the
> Right Thing (tm) to do, but then the semantics must be the same also.
> If I need aliases in the DT only to be able to tell devices apart from each
> other in barebox, while in Linux the effect would only be a rather inconvenient
> renaming of devices with no other added value, I think we need a different way
> to differentiate devices in barebox. Why not just use a simple driver-provided
> prefix (mci, mmc, usb, sata, etc...) for now?

That's not enough. We also need a fixed numbering. Otherwise a
nonremovable eMMC and a removable SD card change their device names
depending on the detect order.

Using aliases to provide a numbering is done in the Kernel aswell at
least for gpios, uarts and i2c busses, so expanding this scheme to
mmc/sd slots doesn't feel too wrong to me.

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-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: /dev/disk0 vs /dev/mmc0

[David Jander]

On Mon, 7 Oct 2013 08:41:11 +0200
Sascha Hauer <s.hauer@pengutronix.de> wrote:

> On Mon, Oct 07, 2013 at 08:32:03AM +0200, David Jander wrote:
> > 
> > Dear Sascha,
> > 
> > On Sun, 6 Oct 2013 12:39:50 +0200
> > Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > 
> > > It doesn't interfere with the kernel. The kernel currently ignores this
> > > aliases. There are patches floating to let the kernel honor this
> > > aliases, but then they should simply have the same effect as they have
> > > in barebox.
> > 
> > That doesn't _feel_ right. Changing standard device names in Linux via
> > aliases in the DT might be a fancy idea, but it'd have a different
> > reason/use-case than in the case of barebox. IMHO using the same DT for
> > both seems to be the Right Thing (tm) to do, but then the semantics must
> > be the same also. If I need aliases in the DT only to be able to tell
> > devices apart from each other in barebox, while in Linux the effect would
> > only be a rather inconvenient renaming of devices with no other added
> > value, I think we need a different way to differentiate devices in
> > barebox. Why not just use a simple driver-provided prefix (mci, mmc, usb,
> > sata, etc...) for now?
> 
> That's not enough. We also need a fixed numbering. Otherwise a
> nonremovable eMMC and a removable SD card change their device names
> depending on the detect order.

True. Can host->dev.id be used? Should be fixed AFAICS...

> Using aliases to provide a numbering is done in the Kernel aswell at
> least for gpios, uarts and i2c busses, so expanding this scheme to
> mmc/sd slots doesn't feel too wrong to me.

Yes, but we are doing it in barebox now only because there is no other way to
tell devices apart from each other. While the MMC device being called
"mmcblk0" or whatever in Linux is perfectly fine (no need for alias), in
barebox the device is now named "disk0", and there is no way of knowing what
"disk0" actually is. Using DT-aliases for that purpose seems wrong to me.
Why was this changed anyway? Introduction of some common "disk" layer (like
scsi-disk on Linux)? Or just for the sake of confusing it with other
"disk"-like devices?

Best regards,

-- 
David Jander
Protonic Holland.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: /dev/disk0 vs /dev/mmc0

[Sascha Hauer]

On Mon, Oct 07, 2013 at 11:57:35AM +0200, David Jander wrote:
> On Mon, 7 Oct 2013 08:41:11 +0200
> Sascha Hauer <s.hauer@pengutronix.de> wrote:
> 
> > On Mon, Oct 07, 2013 at 08:32:03AM +0200, David Jander wrote:
> > > 
> > > Dear Sascha,
> > > 
> > > On Sun, 6 Oct 2013 12:39:50 +0200
> > > Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > > 
> > > > It doesn't interfere with the kernel. The kernel currently ignores this
> > > > aliases. There are patches floating to let the kernel honor this
> > > > aliases, but then they should simply have the same effect as they have
> > > > in barebox.
> > > 
> > > That doesn't _feel_ right. Changing standard device names in Linux via
> > > aliases in the DT might be a fancy idea, but it'd have a different
> > > reason/use-case than in the case of barebox. IMHO using the same DT for
> > > both seems to be the Right Thing (tm) to do, but then the semantics must
> > > be the same also. If I need aliases in the DT only to be able to tell
> > > devices apart from each other in barebox, while in Linux the effect would
> > > only be a rather inconvenient renaming of devices with no other added
> > > value, I think we need a different way to differentiate devices in
> > > barebox. Why not just use a simple driver-provided prefix (mci, mmc, usb,
> > > sata, etc...) for now?
> > 
> > That's not enough. We also need a fixed numbering. Otherwise a
> > nonremovable eMMC and a removable SD card change their device names
> > depending on the detect order.
> 
> True. Can host->dev.id be used? Should be fixed AFAICS...

host->dev.id depends on the probe order.

> 
> > Using aliases to provide a numbering is done in the Kernel aswell at
> > least for gpios, uarts and i2c busses, so expanding this scheme to
> > mmc/sd slots doesn't feel too wrong to me.
> 
> Yes, but we are doing it in barebox now only because there is no other way to
> tell devices apart from each other. While the MMC device being called
> "mmcblk0" or whatever in Linux is perfectly fine (no need for alias),

Linux has exactly the same problem. There are enough systems on which
the eMMC changes its name depending on a SD card being plugged in or
not.

> in
> barebox the device is now named "disk0", and there is no way of knowing what
> "disk0" actually is. Using DT-aliases for that purpose seems wrong to me.
> Why was this changed anyway? Introduction of some common "disk" layer (like
> scsi-disk on Linux)? Or just for the sake of confusing it with other
> "disk"-like devices?

It has always been diskx on barebox, this behaviour hasn't changed.

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-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: /dev/disk0 vs /dev/mmc0

[David Jander]

On Mon, 7 Oct 2013 22:19:36 +0200
Sascha Hauer <s.hauer@pengutronix.de> wrote:

> On Mon, Oct 07, 2013 at 11:57:35AM +0200, David Jander wrote:
> > On Mon, 7 Oct 2013 08:41:11 +0200
> > Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > 
> > > On Mon, Oct 07, 2013 at 08:32:03AM +0200, David Jander wrote:
> > > > 
> > > > Dear Sascha,
> > > > 
> > > > On Sun, 6 Oct 2013 12:39:50 +0200
> > > > Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > > > 
> > > > > It doesn't interfere with the kernel. The kernel currently ignores
> > > > > this aliases. There are patches floating to let the kernel honor this
> > > > > aliases, but then they should simply have the same effect as they
> > > > > have in barebox.
> > > > 
> > > > That doesn't _feel_ right. Changing standard device names in Linux via
> > > > aliases in the DT might be a fancy idea, but it'd have a different
> > > > reason/use-case than in the case of barebox. IMHO using the same DT for
> > > > both seems to be the Right Thing (tm) to do, but then the semantics
> > > > must be the same also. If I need aliases in the DT only to be able to
> > > > tell devices apart from each other in barebox, while in Linux the
> > > > effect would only be a rather inconvenient renaming of devices with no
> > > > other added value, I think we need a different way to differentiate
> > > > devices in barebox. Why not just use a simple driver-provided prefix
> > > > (mci, mmc, usb, sata, etc...) for now?
> > > 
> > > That's not enough. We also need a fixed numbering. Otherwise a
> > > nonremovable eMMC and a removable SD card change their device names
> > > depending on the detect order.
> > 
> > True. Can host->dev.id be used? Should be fixed AFAICS...
> 
> host->dev.id depends on the probe order.

:-(

> > > Using aliases to provide a numbering is done in the Kernel aswell at
> > > least for gpios, uarts and i2c busses, so expanding this scheme to
> > > mmc/sd slots doesn't feel too wrong to me.
> > 
> > Yes, but we are doing it in barebox now only because there is no other way
> > to tell devices apart from each other. While the MMC device being called
> > "mmcblk0" or whatever in Linux is perfectly fine (no need for alias),
> 
> Linux has exactly the same problem. There are enough systems on which
> the eMMC changes its name depending on a SD card being plugged in or
> not.

Yes, but you have udev/mdev hotplugging and the sysfs interface to figure out
what you need to know. Barebox has nothing like that AFAICS.

> > in
> > barebox the device is now named "disk0", and there is no way of knowing
> > what "disk0" actually is. Using DT-aliases for that purpose seems wrong to
> > me. Why was this changed anyway? Introduction of some common "disk" layer
> > (like scsi-disk on Linux)? Or just for the sake of confusing it with other
> > "disk"-like devices?
> 
> It has always been diskx on barebox, this behaviour hasn't changed.

You are right. Sorry for the confusion. There were aliases in barebox's
version of imx53.dtsi which went missing somehow in my tree. I have been
merging stuff from mainline Linux....
That leads me to the question: What is the intended relationship between
barebox and Linux kernel DTS files? Which one is supposed to be the "master" or
"upstream" version? Aren't they supposed to be kept in sync somehow? At least
the basic SoC-specific .dtsi files?

Best regards,

-- 
David Jander
Protonic Holland.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: /dev/disk0 vs /dev/mmc0

[Lucas Stach]

Am Dienstag, den 08.10.2013, 09:02 +0200 schrieb David Jander:
> On Mon, 7 Oct 2013 22:19:36 +0200
> Sascha Hauer <s.hauer@pengutronix.de> wrote:
> 
> > On Mon, Oct 07, 2013 at 11:57:35AM +0200, David Jander wrote:
> > > On Mon, 7 Oct 2013 08:41:11 +0200
> > > Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > 
> > > > On Mon, Oct 07, 2013 at 08:32:03AM +0200, David Jander wrote:
> > > > > 
> > > > > Dear Sascha,
> > > > > 
> > > > > On Sun, 6 Oct 2013 12:39:50 +0200
> > > > > Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > > > > 
> > > > > > It doesn't interfere with the kernel. The kernel currently ignores
> > > > > > this aliases. There are patches floating to let the kernel honor this
> > > > > > aliases, but then they should simply have the same effect as they
> > > > > > have in barebox.
> > > > > 
> > > > > That doesn't _feel_ right. Changing standard device names in Linux via
> > > > > aliases in the DT might be a fancy idea, but it'd have a different
> > > > > reason/use-case than in the case of barebox. IMHO using the same DT for
> > > > > both seems to be the Right Thing (tm) to do, but then the semantics
> > > > > must be the same also. If I need aliases in the DT only to be able to
> > > > > tell devices apart from each other in barebox, while in Linux the
> > > > > effect would only be a rather inconvenient renaming of devices with no
> > > > > other added value, I think we need a different way to differentiate
> > > > > devices in barebox. Why not just use a simple driver-provided prefix
> > > > > (mci, mmc, usb, sata, etc...) for now?
> > > > 
> > > > That's not enough. We also need a fixed numbering. Otherwise a
> > > > nonremovable eMMC and a removable SD card change their device names
> > > > depending on the detect order.
> > > 
> > > True. Can host->dev.id be used? Should be fixed AFAICS...
> > 
> > host->dev.id depends on the probe order.
> 
> :-(
> 
> > > > Using aliases to provide a numbering is done in the Kernel aswell at
> > > > least for gpios, uarts and i2c busses, so expanding this scheme to
> > > > mmc/sd slots doesn't feel too wrong to me.
> > > 
> > > Yes, but we are doing it in barebox now only because there is no other way
> > > to tell devices apart from each other. While the MMC device being called
> > > "mmcblk0" or whatever in Linux is perfectly fine (no need for alias),
> > 
> > Linux has exactly the same problem. There are enough systems on which
> > the eMMC changes its name depending on a SD card being plugged in or
> > not.
> 
> Yes, but you have udev/mdev hotplugging and the sysfs interface to figure out
> what you need to know. Barebox has nothing like that AFAICS.
> 
> > > in
> > > barebox the device is now named "disk0", and there is no way of knowing
> > > what "disk0" actually is. Using DT-aliases for that purpose seems wrong to
> > > me. Why was this changed anyway? Introduction of some common "disk" layer
> > > (like scsi-disk on Linux)? Or just for the sake of confusing it with other
> > > "disk"-like devices?
> > 
> > It has always been diskx on barebox, this behaviour hasn't changed.
> 
> You are right. Sorry for the confusion. There were aliases in barebox's
> version of imx53.dtsi which went missing somehow in my tree. I have been
> merging stuff from mainline Linux....
> That leads me to the question: What is the intended relationship between
> barebox and Linux kernel DTS files? Which one is supposed to be the "master" or
> "upstream" version? Aren't they supposed to be kept in sync somehow? At least
> the basic SoC-specific .dtsi files?
> 
Missing other options we regard the Linux DTs as the upstream. Ideally
DTs should be stored in a separate repo, so they don't get broken
unnecessarily.

We will try to keep the Barebox DTs in sync with Linux as much as
possible. But even then there is no guarantee that Barebox and Linux DTs
don't drift away from each other over time.
If a binding gets broken (let's hope that everyone gets their act
together and don't do this anymore), it will require code changes and
maintenance work to get things in sync again.

Another real-life use-case where you might end up with different DTs is
if you update your Linux kernel more regularly than the Barebox on your
device. So please if ever possible don't boot the Linux kernel with the
builtin Barebox DT, but design your boot concept in a way that you
always deliver a DTB fitting your kernel.

Regards,
Lucas

-- 
Pengutronix e.K.                           | Lucas Stach                 |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: /dev/disk0 vs /dev/mmc0

[David Jander]

On Tue, 08 Oct 2013 09:45:05 +0200
Lucas Stach <l.stach@pengutronix.de> wrote:

> Am Dienstag, den 08.10.2013, 09:02 +0200 schrieb David Jander:
> > On Mon, 7 Oct 2013 22:19:36 +0200
> > Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > 
> > > On Mon, Oct 07, 2013 at 11:57:35AM +0200, David Jander wrote:
> > > > On Mon, 7 Oct 2013 08:41:11 +0200
> > > > Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > > 
> > > > > On Mon, Oct 07, 2013 at 08:32:03AM +0200, David Jander wrote:
> > > > > > 
> > > > > > Dear Sascha,
> > > > > > 
> > > > > > On Sun, 6 Oct 2013 12:39:50 +0200
> > > > > > Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > > > > > 
> > > > > > > It doesn't interfere with the kernel. The kernel currently
> > > > > > > ignores this aliases. There are patches floating to let the
> > > > > > > kernel honor this aliases, but then they should simply have the
> > > > > > > same effect as they have in barebox.
> > > > > > 
> > > > > > That doesn't _feel_ right. Changing standard device names in Linux
> > > > > > via aliases in the DT might be a fancy idea, but it'd have a
> > > > > > different reason/use-case than in the case of barebox. IMHO using
> > > > > > the same DT for both seems to be the Right Thing (tm) to do, but
> > > > > > then the semantics must be the same also. If I need aliases in the
> > > > > > DT only to be able to tell devices apart from each other in
> > > > > > barebox, while in Linux the effect would only be a rather
> > > > > > inconvenient renaming of devices with no other added value, I
> > > > > > think we need a different way to differentiate devices in barebox.
> > > > > > Why not just use a simple driver-provided prefix (mci, mmc, usb,
> > > > > > sata, etc...) for now?
> > > > > 
> > > > > That's not enough. We also need a fixed numbering. Otherwise a
> > > > > nonremovable eMMC and a removable SD card change their device names
> > > > > depending on the detect order.
> > > > 
> > > > True. Can host->dev.id be used? Should be fixed AFAICS...
> > > 
> > > host->dev.id depends on the probe order.
> > 
> > :-(
> > 
> > > > > Using aliases to provide a numbering is done in the Kernel aswell at
> > > > > least for gpios, uarts and i2c busses, so expanding this scheme to
> > > > > mmc/sd slots doesn't feel too wrong to me.
> > > > 
> > > > Yes, but we are doing it in barebox now only because there is no other
> > > > way to tell devices apart from each other. While the MMC device being
> > > > called "mmcblk0" or whatever in Linux is perfectly fine (no need for
> > > > alias),
> > > 
> > > Linux has exactly the same problem. There are enough systems on which
> > > the eMMC changes its name depending on a SD card being plugged in or
> > > not.
> > 
> > Yes, but you have udev/mdev hotplugging and the sysfs interface to figure
> > out what you need to know. Barebox has nothing like that AFAICS.
> > 
> > > > in
> > > > barebox the device is now named "disk0", and there is no way of knowing
> > > > what "disk0" actually is. Using DT-aliases for that purpose seems
> > > > wrong to me. Why was this changed anyway? Introduction of some common
> > > > "disk" layer (like scsi-disk on Linux)? Or just for the sake of
> > > > confusing it with other "disk"-like devices?
> > > 
> > > It has always been diskx on barebox, this behaviour hasn't changed.
> > 
> > You are right. Sorry for the confusion. There were aliases in barebox's
> > version of imx53.dtsi which went missing somehow in my tree. I have been
> > merging stuff from mainline Linux....
> > That leads me to the question: What is the intended relationship between
> > barebox and Linux kernel DTS files? Which one is supposed to be the
> > "master" or "upstream" version? Aren't they supposed to be kept in sync
> > somehow? At least the basic SoC-specific .dtsi files?
> > 
> Missing other options we regard the Linux DTs as the upstream. Ideally
> DTs should be stored in a separate repo, so they don't get broken
> unnecessarily.
> 
> We will try to keep the Barebox DTs in sync with Linux as much as
> possible. But even then there is no guarantee that Barebox and Linux DTs
> don't drift away from each other over time.
> If a binding gets broken (let's hope that everyone gets their act
> together and don't do this anymore), it will require code changes and
> maintenance work to get things in sync again.
> 
> Another real-life use-case where you might end up with different DTs is
> if you update your Linux kernel more regularly than the Barebox on your
> device. So please if ever possible don't boot the Linux kernel with the
> builtin Barebox DT, but design your boot concept in a way that you
> always deliver a DTB fitting your kernel.

Our boot-scheme checks for a DTB on the boot-medium. If it finds one matching
the board, it is used, otherwise it boots with barebox's built-in DTB, and
that should be the default situation, unless it becomes necessary to overrule
the internal DTB for whatever regrettable reason.

I have had strong discussions (almost flame-war) long time ago on alkml about
the issue of hardware initialization. IMNSHO, hardware initialization that has
to do with the electrical layout of the board (PAD settings, drive-strength,
etc...) must always be done in the boot-loader. Back in the time where there
was no DT for ARM, Linux kernel board support code was a bloody mess with this
sort of HW initialization everywhere, and everywhere done differently. Only
the hardware designer know what drive-strength and other PAD settings need to
be chosen for each PAD. That is where your design is based on. Kernel
(-developers) do not know, and should not need to care.
Now there is this "invention" of putting all this information in the DT. This
actually seems like a good compromise between what I said above and the fact
that the kernel sometimes needs to reconfigure PADs due to PM, pluggable
devices and such. But still the knowledge about PAD settings (and what
hardware the board happens to have for that matter) belongs to the
boot-loader. Having more than one source for this is dangerous.

Best regards,

-- 
David Jander
Protonic Holland.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: /dev/disk0 vs /dev/mmc0

[Lucas Stach]

Am Dienstag, den 08.10.2013, 11:13 +0200 schrieb David Jander:
[...]
> > > You are right. Sorry for the confusion. There were aliases in barebox's
> > > version of imx53.dtsi which went missing somehow in my tree. I have been
> > > merging stuff from mainline Linux....
> > > That leads me to the question: What is the intended relationship between
> > > barebox and Linux kernel DTS files? Which one is supposed to be the
> > > "master" or "upstream" version? Aren't they supposed to be kept in sync
> > > somehow? At least the basic SoC-specific .dtsi files?
> > > 
> > Missing other options we regard the Linux DTs as the upstream. Ideally
> > DTs should be stored in a separate repo, so they don't get broken
> > unnecessarily.
> > 
> > We will try to keep the Barebox DTs in sync with Linux as much as
> > possible. But even then there is no guarantee that Barebox and Linux DTs
> > don't drift away from each other over time.
> > If a binding gets broken (let's hope that everyone gets their act
> > together and don't do this anymore), it will require code changes and
> > maintenance work to get things in sync again.
> > 
> > Another real-life use-case where you might end up with different DTs is
> > if you update your Linux kernel more regularly than the Barebox on your
> > device. So please if ever possible don't boot the Linux kernel with the
> > builtin Barebox DT, but design your boot concept in a way that you
> > always deliver a DTB fitting your kernel.
> 
> Our boot-scheme checks for a DTB on the boot-medium. If it finds one matching
> the board, it is used, otherwise it boots with barebox's built-in DTB, and
> that should be the default situation, unless it becomes necessary to overrule
> the internal DTB for whatever regrettable reason.
> 
Yeah that's the conclusion you may be inclined to take if you try to
live in an ideal world. (Including a dot-shaped earth in a vacuum.)

Experience with the device tree shows that there are a lot more of those
regrettable reasons than one might imagine. So in order to get around
all those real world problems always boot your kernel with a devicetree
matching exactly that kernel version. Take this as a well-meaning advise
from someone who hit the hard wall of the real-world device tree more
than one.

> I have had strong discussions (almost flame-war) long time ago on alkml about
> the issue of hardware initialization. IMNSHO, hardware initialization that has
> to do with the electrical layout of the board (PAD settings, drive-strength,
> etc...) must always be done in the boot-loader. Back in the time where there
> was no DT for ARM, Linux kernel board support code was a bloody mess with this
> sort of HW initialization everywhere, and everywhere done differently. Only
> the hardware designer know what drive-strength and other PAD settings need to
> be chosen for each PAD. That is where your design is based on. Kernel
> (-developers) do not know, and should not need to care.
> Now there is this "invention" of putting all this information in the DT. This
> actually seems like a good compromise between what I said above and the fact
> that the kernel sometimes needs to reconfigure PADs due to PM, pluggable
> devices and such. But still the knowledge about PAD settings (and what
> hardware the board happens to have for that matter) belongs to the
> boot-loader. Having more than one source for this is dangerous.
> 
No, that is utterly wrong. Linux should always know everything about
your hardware and _not_ expect anything to be set up by the bootloader.
There are some corner cases like chip errata fixes here, but generally
don't assume the bootloader to set things up for you. The bootloader
should only do the minimal needed init for loading the kernel and
booting. The kernel is your hardware abstraction for your running
system, not the bootloader.

Ideally both the bootloader and kernel would source their needed
information from a shared DT that's decoupled from kernel development
and stable, once again reality strikes in here. I agree with you that
not a kernel developer, but board designer should write the DT and we
might actually get this separation in a clean way, if we manage to split
out the DTs from the kernel some day.

Regards,
Lucas
-- 
Pengutronix e.K.                           | Lucas Stach                 |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: /dev/disk0 vs /dev/mmc0

[David Jander]

Dear Lucas,

On Tue, 08 Oct 2013 11:39:24 +0200
Lucas Stach <l.stach@pengutronix.de> wrote:

> Am Dienstag, den 08.10.2013, 11:13 +0200 schrieb David Jander:
> [...]
> > > > You are right. Sorry for the confusion. There were aliases in barebox's
> > > > version of imx53.dtsi which went missing somehow in my tree. I have
> > > > been merging stuff from mainline Linux....
> > > > That leads me to the question: What is the intended relationship
> > > > between barebox and Linux kernel DTS files? Which one is supposed to
> > > > be the "master" or "upstream" version? Aren't they supposed to be kept
> > > > in sync somehow? At least the basic SoC-specific .dtsi files?
> > > > 
> > > Missing other options we regard the Linux DTs as the upstream. Ideally
> > > DTs should be stored in a separate repo, so they don't get broken
> > > unnecessarily.
> > > 
> > > We will try to keep the Barebox DTs in sync with Linux as much as
> > > possible. But even then there is no guarantee that Barebox and Linux DTs
> > > don't drift away from each other over time.
> > > If a binding gets broken (let's hope that everyone gets their act
> > > together and don't do this anymore), it will require code changes and
> > > maintenance work to get things in sync again.
> > > 
> > > Another real-life use-case where you might end up with different DTs is
> > > if you update your Linux kernel more regularly than the Barebox on your
> > > device. So please if ever possible don't boot the Linux kernel with the
> > > builtin Barebox DT, but design your boot concept in a way that you
> > > always deliver a DTB fitting your kernel.
> > 
> > Our boot-scheme checks for a DTB on the boot-medium. If it finds one
> > matching the board, it is used, otherwise it boots with barebox's built-in
> > DTB, and that should be the default situation, unless it becomes necessary
> > to overrule the internal DTB for whatever regrettable reason.
> > 
> Yeah that's the conclusion you may be inclined to take if you try to
> live in an ideal world. (Including a dot-shaped earth in a vacuum.)

Aren't we living on a dot-shaped earth in a vacuum?

> Experience with the device tree shows that there are a lot more of those
> regrettable reasons than one might imagine. So in order to get around
> all those real world problems always boot your kernel with a devicetree
> matching exactly that kernel version. Take this as a well-meaning advise
> from someone who hit the hard wall of the real-world device tree more
> than one.

Don't get me wrong, I have had enough cases of device-trees changing and
kernels being incompatible with them. I have hit the hard wall enough times
already, but that doesn't mean it hasn't always been for pretty regrettable
reasons. Open Firmware and Device-Trees are both good ideas and we are not
using them (yet) as they are supposed to be used. Saying that we shouldn't just
because we haven't been able to make it work as intended sounds more like an
excuse to me than a hard fact.... ;-)
Make the problem be the exception, not the rule.

> > I have had strong discussions (almost flame-war) long time ago on alkml
> > about the issue of hardware initialization. IMNSHO, hardware
> > initialization that has to do with the electrical layout of the board (PAD
> > settings, drive-strength, etc...) must always be done in the boot-loader.
> > Back in the time where there was no DT for ARM, Linux kernel board support
> > code was a bloody mess with this sort of HW initialization everywhere, and
> > everywhere done differently. Only the hardware designer know what
> > drive-strength and other PAD settings need to be chosen for each PAD. That
> > is where your design is based on. Kernel (-developers) do not know, and
> > should not need to care. Now there is this "invention" of putting all this
> > information in the DT. This actually seems like a good compromise between
> > what I said above and the fact that the kernel sometimes needs to
> > reconfigure PADs due to PM, pluggable devices and such. But still the
> > knowledge about PAD settings (and what hardware the board happens to have
> > for that matter) belongs to the boot-loader. Having more than one source
> > for this is dangerous.
> > 
> No, that is utterly wrong. Linux should always know everything about
> your hardware and _not_ expect anything to be set up by the bootloader.

Huh? AFAIK, it has never been like that. PC's have BIOS (or UEFI firmware for
that matter) that takes care of signal integrity setup of the PC's chipset,
motherboard, CPU and RAM. Next, do you want to leave DDR timing setup to the
Linux kernel?? You are kidding, right?

> There are some corner cases like chip errata fixes here, but generally
> don't assume the bootloader to set things up for you.

Another case of making the problem the rule instead of the exception....
The fact that board manufacturers don't get their act together to make decent
firmware (bootloader) is no excuse for saying it shouldn't be done like that.

> The bootloader
> should only do the minimal needed init for loading the kernel and
> booting. The kernel is your hardware abstraction for your running
> system, not the bootloader.

That is ok. What I am saying is that settings that have strictly to do with
_hardware_ constraints should never be bothered by the Linux kernel. Otherwise
you would need to recompile the kernel (or change the device-tree) for
potentially every single hardware revision of one board model.
If I place other RAM chips on the board for instance, or if there is a layout
revision, or a peripheral chip that has had a die revision requiring different
drive-strength and such changes.... that information should be taken care of
by the boot-loader.

Configuring peripherals, setting MUX registers and such is a different story.
That should (and many times must) be done in the kernel.

> Ideally both the bootloader and kernel would source their needed
> information from a shared DT that's decoupled from kernel development
> and stable, once again reality strikes in here. I agree with you that
> not a kernel developer, but board designer should write the DT and we
> might actually get this separation in a clean way, if we manage to split
> out the DTs from the kernel some day.

Well, I am a board designer, and I am trying to do just that. Pardon me for
being an idealist sometimes ;-)

Funny enough, some of my gripes about the state of ARM-Linux initially were
echoed years later by Linus himself in his famous e-mail about the mess that
was ARM-Linux board support before DT came along. Back then, when I asked why
ARM wouldn't benefit from OF-device-trees just like PowerPC and Sparc did, I
was being laughed at. Unfortunately a few conceptual things have been
implemented the wrong way (like PAD setup), but hey! Not bad ;-)

Best regards,

-- 
David Jander
Protonic Holland.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: /dev/disk0 vs /dev/mmc0

[Lucas Stach]

Am Dienstag, den 08.10.2013, 15:47 +0200 schrieb David Jander:
> Dear Lucas,
> 
> On Tue, 08 Oct 2013 11:39:24 +0200
> Lucas Stach <l.stach@pengutronix.de> wrote:
> 
> > Am Dienstag, den 08.10.2013, 11:13 +0200 schrieb David Jander:
> > [...]
> > > > > You are right. Sorry for the confusion. There were aliases in barebox's
> > > > > version of imx53.dtsi which went missing somehow in my tree. I have
> > > > > been merging stuff from mainline Linux....
> > > > > That leads me to the question: What is the intended relationship
> > > > > between barebox and Linux kernel DTS files? Which one is supposed to
> > > > > be the "master" or "upstream" version? Aren't they supposed to be kept
> > > > > in sync somehow? At least the basic SoC-specific .dtsi files?
> > > > > 
> > > > Missing other options we regard the Linux DTs as the upstream. Ideally
> > > > DTs should be stored in a separate repo, so they don't get broken
> > > > unnecessarily.
> > > > 
> > > > We will try to keep the Barebox DTs in sync with Linux as much as
> > > > possible. But even then there is no guarantee that Barebox and Linux DTs
> > > > don't drift away from each other over time.
> > > > If a binding gets broken (let's hope that everyone gets their act
> > > > together and don't do this anymore), it will require code changes and
> > > > maintenance work to get things in sync again.
> > > > 
> > > > Another real-life use-case where you might end up with different DTs is
> > > > if you update your Linux kernel more regularly than the Barebox on your
> > > > device. So please if ever possible don't boot the Linux kernel with the
> > > > builtin Barebox DT, but design your boot concept in a way that you
> > > > always deliver a DTB fitting your kernel.
> > > 
> > > Our boot-scheme checks for a DTB on the boot-medium. If it finds one
> > > matching the board, it is used, otherwise it boots with barebox's built-in
> > > DTB, and that should be the default situation, unless it becomes necessary
> > > to overrule the internal DTB for whatever regrettable reason.
> > > 
> > Yeah that's the conclusion you may be inclined to take if you try to
> > live in an ideal world. (Including a dot-shaped earth in a vacuum.)
> 
> Aren't we living on a dot-shaped earth in a vacuum?
> 
> > Experience with the device tree shows that there are a lot more of those
> > regrettable reasons than one might imagine. So in order to get around
> > all those real world problems always boot your kernel with a devicetree
> > matching exactly that kernel version. Take this as a well-meaning advise
> > from someone who hit the hard wall of the real-world device tree more
> > than one.
> 
> Don't get me wrong, I have had enough cases of device-trees changing and
> kernels being incompatible with them. I have hit the hard wall enough times
> already, but that doesn't mean it hasn't always been for pretty regrettable
> reasons. Open Firmware and Device-Trees are both good ideas and we are not
> using them (yet) as they are supposed to be used. Saying that we shouldn't just
> because we haven't been able to make it work as intended sounds more like an
> excuse to me than a hard fact.... ;-)
> Make the problem be the exception, not the rule.

Without doubt we all should always treat DTs the way we would like them
to be used in the ideal case, but don't depend on those assumptions for
your real products.

Using the builtin DTB normally, but having a way to override it when
needed sounds like a reasonable compromise to make.

> > > I have had strong discussions (almost flame-war) long time ago on alkml
> > > about the issue of hardware initialization. IMNSHO, hardware
> > > initialization that has to do with the electrical layout of the board (PAD
> > > settings, drive-strength, etc...) must always be done in the boot-loader.
> > > Back in the time where there was no DT for ARM, Linux kernel board support
> > > code was a bloody mess with this sort of HW initialization everywhere, and
> > > everywhere done differently. Only the hardware designer know what
> > > drive-strength and other PAD settings need to be chosen for each PAD. That
> > > is where your design is based on. Kernel (-developers) do not know, and
> > > should not need to care. Now there is this "invention" of putting all this
> > > information in the DT. This actually seems like a good compromise between
> > > what I said above and the fact that the kernel sometimes needs to
> > > reconfigure PADs due to PM, pluggable devices and such. But still the
> > > knowledge about PAD settings (and what hardware the board happens to have
> > > for that matter) belongs to the boot-loader. Having more than one source
> > > for this is dangerous.
> > > 
> > No, that is utterly wrong. Linux should always know everything about
> > your hardware and _not_ expect anything to be set up by the bootloader.
> 
> Huh? AFAIK, it has never been like that. PC's have BIOS (or UEFI firmware for
> that matter) that takes care of signal integrity setup of the PC's chipset,
> motherboard, CPU and RAM. Next, do you want to leave DDR timing setup to the
> Linux kernel?? You are kidding, right?
> 
And those BIOS settings are so regularly wrong that the kernel has to
ship a lot of cludge just to work around or correct that bootloader
setup.

I agree that the bootloader should set up things needed for the boot,
but in many cases the kernel needs the same knowledge anyway. Your DDR
timing is a pretty prime example for this. The bootloader has to set it
up initially, but the Linux kernel has to change timings dynamically
(including calibration in some situations) when doing dynamic memory
clock scaling.
CPU bringup is the same matter, Linux needs to know how to do it anyway
as we need it for CPU hotplug when saving power.

Just because there is a real small amount of static setup that could be
done exclusively in the bootloader, doesn't mean we should always force
it down into the bootloader and tell Linux to depend on it.

> > There are some corner cases like chip errata fixes here, but generally
> > don't assume the bootloader to set things up for you.
> 
> Another case of making the problem the rule instead of the exception....
> The fact that board manufacturers don't get their act together to make decent
> firmware (bootloader) is no excuse for saying it shouldn't be done like that.
> 
> > The bootloader
> > should only do the minimal needed init for loading the kernel and
> > booting. The kernel is your hardware abstraction for your running
> > system, not the bootloader.
> 
> That is ok. What I am saying is that settings that have strictly to do with
> _hardware_ constraints should never be bothered by the Linux kernel. Otherwise
> you would need to recompile the kernel (or change the device-tree) for
> potentially every single hardware revision of one board model.
> If I place other RAM chips on the board for instance, or if there is a layout
> revision, or a peripheral chip that has had a die revision requiring different
> drive-strength and such changes.... that information should be taken care of
> by the boot-loader.
> 
> Configuring peripherals, setting MUX registers and such is a different story.
> That should (and many times must) be done in the kernel.
> 
> > Ideally both the bootloader and kernel would source their needed
> > information from a shared DT that's decoupled from kernel development
> > and stable, once again reality strikes in here. I agree with you that
> > not a kernel developer, but board designer should write the DT and we
> > might actually get this separation in a clean way, if we manage to split
> > out the DTs from the kernel some day.
> 
> Well, I am a board designer, and I am trying to do just that. Pardon me for
> being an idealist sometimes ;-)
> 
We can all do our share to better the overall situation by being
idealist, but avoid basing your decision for real-world products on
assumptions that are only true for an ideal world. :)

> Funny enough, some of my gripes about the state of ARM-Linux initially were
> echoed years later by Linus himself in his famous e-mail about the mess that
> was ARM-Linux board support before DT came along. Back then, when I asked why
> ARM wouldn't benefit from OF-device-trees just like PowerPC and Sparc did, I
> was being laughed at. Unfortunately a few conceptual things have been
> implemented the wrong way (like PAD setup), but hey! Not bad ;-)

Regards,
Lucas
-- 
Pengutronix e.K.                           | Lucas Stach                 |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: /dev/disk0 vs /dev/mmc0

[David Jander]

On Tue, 08 Oct 2013 16:11:16 +0200
Lucas Stach <l.stach@pengutronix.de> wrote:

> Am Dienstag, den 08.10.2013, 15:47 +0200 schrieb David Jander:
> > Dear Lucas,
> > 
> > On Tue, 08 Oct 2013 11:39:24 +0200
> > Lucas Stach <l.stach@pengutronix.de> wrote:
> > 
> > > Am Dienstag, den 08.10.2013, 11:13 +0200 schrieb David Jander:
> > > [...]
> > > > > > You are right. Sorry for the confusion. There were aliases in
> > > > > > barebox's version of imx53.dtsi which went missing somehow in my
> > > > > > tree. I have been merging stuff from mainline Linux....
> > > > > > That leads me to the question: What is the intended relationship
> > > > > > between barebox and Linux kernel DTS files? Which one is supposed
> > > > > > to be the "master" or "upstream" version? Aren't they supposed to
> > > > > > be kept in sync somehow? At least the basic SoC-specific .dtsi
> > > > > > files?
> > > > > > 
> > > > > Missing other options we regard the Linux DTs as the upstream.
> > > > > Ideally DTs should be stored in a separate repo, so they don't get
> > > > > broken unnecessarily.
> > > > > 
> > > > > We will try to keep the Barebox DTs in sync with Linux as much as
> > > > > possible. But even then there is no guarantee that Barebox and Linux
> > > > > DTs don't drift away from each other over time.
> > > > > If a binding gets broken (let's hope that everyone gets their act
> > > > > together and don't do this anymore), it will require code changes and
> > > > > maintenance work to get things in sync again.
> > > > > 
> > > > > Another real-life use-case where you might end up with different DTs
> > > > > is if you update your Linux kernel more regularly than the Barebox
> > > > > on your device. So please if ever possible don't boot the Linux
> > > > > kernel with the builtin Barebox DT, but design your boot concept in
> > > > > a way that you always deliver a DTB fitting your kernel.
> > > > 
> > > > Our boot-scheme checks for a DTB on the boot-medium. If it finds one
> > > > matching the board, it is used, otherwise it boots with barebox's
> > > > built-in DTB, and that should be the default situation, unless it
> > > > becomes necessary to overrule the internal DTB for whatever
> > > > regrettable reason.
> > > > 
> > > Yeah that's the conclusion you may be inclined to take if you try to
> > > live in an ideal world. (Including a dot-shaped earth in a vacuum.)
> > 
> > Aren't we living on a dot-shaped earth in a vacuum?
> > 
> > > Experience with the device tree shows that there are a lot more of those
> > > regrettable reasons than one might imagine. So in order to get around
> > > all those real world problems always boot your kernel with a devicetree
> > > matching exactly that kernel version. Take this as a well-meaning advise
> > > from someone who hit the hard wall of the real-world device tree more
> > > than one.
> > 
> > Don't get me wrong, I have had enough cases of device-trees changing and
> > kernels being incompatible with them. I have hit the hard wall enough times
> > already, but that doesn't mean it hasn't always been for pretty regrettable
> > reasons. Open Firmware and Device-Trees are both good ideas and we are not
> > using them (yet) as they are supposed to be used. Saying that we shouldn't
> > just because we haven't been able to make it work as intended sounds more
> > like an excuse to me than a hard fact.... ;-)
> > Make the problem be the exception, not the rule.
> 
> Without doubt we all should always treat DTs the way we would like them
> to be used in the ideal case, but don't depend on those assumptions for
> your real products.
> 
> Using the builtin DTB normally, but having a way to override it when
> needed sounds like a reasonable compromise to make.

Thanks.

> > > > I have had strong discussions (almost flame-war) long time ago on alkml
> > > > about the issue of hardware initialization. IMNSHO, hardware
> > > > initialization that has to do with the electrical layout of the board
> > > > (PAD settings, drive-strength, etc...) must always be done in the
> > > > boot-loader. Back in the time where there was no DT for ARM, Linux
> > > > kernel board support code was a bloody mess with this sort of HW
> > > > initialization everywhere, and everywhere done differently. Only the
> > > > hardware designer know what drive-strength and other PAD settings need
> > > > to be chosen for each PAD. That is where your design is based on.
> > > > Kernel (-developers) do not know, and should not need to care. Now
> > > > there is this "invention" of putting all this information in the DT.
> > > > This actually seems like a good compromise between what I said above
> > > > and the fact that the kernel sometimes needs to reconfigure PADs due
> > > > to PM, pluggable devices and such. But still the knowledge about PAD
> > > > settings (and what hardware the board happens to have for that matter)
> > > > belongs to the boot-loader. Having more than one source for this is
> > > > dangerous.
> > > > 
> > > No, that is utterly wrong. Linux should always know everything about
> > > your hardware and _not_ expect anything to be set up by the bootloader.
> > 
> > Huh? AFAIK, it has never been like that. PC's have BIOS (or UEFI firmware
> > for that matter) that takes care of signal integrity setup of the PC's
> > chipset, motherboard, CPU and RAM. Next, do you want to leave DDR timing
> > setup to the Linux kernel?? You are kidding, right?
> > 
> And those BIOS settings are so regularly wrong that the kernel has to
> ship a lot of cludge just to work around or correct that bootloader
> setup.

I don't think a BIOS has ever been wrong about chipset drive-strength and
slew-rate settings in a way the Linux kernel could do anything about it....

> I agree that the bootloader should set up things needed for the boot,
> but in many cases the kernel needs the same knowledge anyway. Your DDR
> timing is a pretty prime example for this. The bootloader has to set it
> up initially, but the Linux kernel has to change timings dynamically
> (including calibration in some situations) when doing dynamic memory
> clock scaling.

For DRAM clock scaling, only the clock divider or PLL should ever be
changed. Any other parameters should stay the same. If this has really been
done, I'd like to see it...
DRAM calibration settings have to do with signal propagation on the PCB. That
has nothing to do with clock speeds or -settings.

> CPU bringup is the same matter, Linux needs to know how to do it anyway
> as we need it for CPU hotplug when saving power.

(Un)fortunately we don't have ACPI on ARM ;-)
But then again, CPU bringup is still very different from PAD settings.

> Just because there is a real small amount of static setup that could be
> done exclusively in the bootloader, doesn't mean we should always force
> it down into the bootloader and tell Linux to depend on it.

Yes we should! This "real small" amount as you call it is something you can't
understand even if you had all the documentation of the chips placed on the
board, because it is part of the total hardware design, including the board
layout. And sometimes a crucial part of it I might add. The most ugly thing is
that other settings might even work correctly 95% of the time, so it can be
potentially very hard to find a bug related to "thinking I know what I am
doing by defining some seemingly arbitrary drive-strength settings for this
PAD", or even copying settings from a complete other hardware design based on
the same chip.

Things like this in a dtsi file like imx53.dtsi:

	pinctrl_fec_1: fecgrp-1 {
		fsl,pins = <
			MX53_PAD_FEC_MDC__FEC_MDC	 0x80000000
			MX53_PAD_FEC_MDIO__FEC_MDIO	 0x80000000
			MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x80000000
			MX53_PAD_FEC_RX_ER__FEC_RX_ER    0x80000000
			MX53_PAD_FEC_CRS_DV__FEC_RX_DV   0x80000000
			MX53_PAD_FEC_RXD1__FEC_RDATA_1   0x80000000
			MX53_PAD_FEC_RXD0__FEC_RDATA_0   0x80000000
			MX53_PAD_FEC_TX_EN__FEC_TX_EN    0x80000000
			MX53_PAD_FEC_TXD1__FEC_TDATA_1   0x80000000
			MX53_PAD_FEC_TXD0__FEC_TDATA_0   0x80000000
		>;
	};

... are conceptually wrong. They suggest one can universally apply
pinctrl_fec_1 if the FEC happens to be connected to the MX53_PAD_FEC_... pads.
Wrong! Because these settings also sneakily overrule the PAD settings for
drive-strength, slew-rate, pull-/keepers, etc....
There is nothing wrong with having this option, but it may apply only to one
hardware design, and be mostly useless to the rest. Ok, maybe I exaggerate a
little, but I assume you understand what I mean by "conceptually wrong".

The only semantically correct solution I have been able to come up with for
this, is to actually generate this DT in the boot-loader.

> > > There are some corner cases like chip errata fixes here, but generally
> > > don't assume the bootloader to set things up for you.
> > 
> > Another case of making the problem the rule instead of the exception....
> > The fact that board manufacturers don't get their act together to make
> > decent firmware (bootloader) is no excuse for saying it shouldn't be done
> > like that.
> > 
> > > The bootloader
> > > should only do the minimal needed init for loading the kernel and
> > > booting. The kernel is your hardware abstraction for your running
> > > system, not the bootloader.
> > 
> > That is ok. What I am saying is that settings that have strictly to do with
> > _hardware_ constraints should never be bothered by the Linux kernel.
> > Otherwise you would need to recompile the kernel (or change the
> > device-tree) for potentially every single hardware revision of one board
> > model. If I place other RAM chips on the board for instance, or if there
> > is a layout revision, or a peripheral chip that has had a die revision
> > requiring different drive-strength and such changes.... that information
> > should be taken care of by the boot-loader.
> > 
> > Configuring peripherals, setting MUX registers and such is a different
> > story. That should (and many times must) be done in the kernel.
> > 
> > > Ideally both the bootloader and kernel would source their needed
> > > information from a shared DT that's decoupled from kernel development
> > > and stable, once again reality strikes in here. I agree with you that
> > > not a kernel developer, but board designer should write the DT and we
> > > might actually get this separation in a clean way, if we manage to split
> > > out the DTs from the kernel some day.
> > 
> > Well, I am a board designer, and I am trying to do just that. Pardon me for
> > being an idealist sometimes ;-)
> > 
> We can all do our share to better the overall situation by being
> idealist, but avoid basing your decision for real-world products on
> assumptions that are only true for an ideal world. :)

I don't do that of course. But with 99% of all ARM boards having broken
firmware we shouldn't loose our horizon while developing either Barebox or the
Linux kernel :-)

> > Funny enough, some of my gripes about the state of ARM-Linux initially were
> > echoed years later by Linus himself in his famous e-mail about the mess
> > that was ARM-Linux board support before DT came along. Back then, when I
> > asked why ARM wouldn't benefit from OF-device-trees just like PowerPC and
> > Sparc did, I was being laughed at. Unfortunately a few conceptual things
> > have been implemented the wrong way (like PAD setup), but hey! Not bad ;-)

Ok, now can we both please go back to work?

Best regards,

-- 
David Jander
Protonic Holland.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: /dev/disk0 vs /dev/mmc0

[Lucas Stach]

Am Dienstag, den 08.10.2013, 16:49 +0200 schrieb David Jander:
[...]
> 
> For DRAM clock scaling, only the clock divider or PLL should ever be
> changed. Any other parameters should stay the same. If this has really been
> done, I'd like to see it...
> DRAM calibration settings have to do with signal propagation on the PCB. That
> has nothing to do with clock speeds or -settings.
> 
Take a look at the Tegra20 Colibri in the mainline kernel. The DT there
contains optimized timing register settings for every DRAM clock
frequency. Those are loaded into a shadow registerset in the
memory-controller that latches the settings into the live registers at
the same moment the clock divider is changed.

My understanding of the docs says a similar thing thing is possible on
i.MX6, although no one has done such a thing there up until now.

> Ok, now can we both please go back to work?

Absolutely.

Regards,
Lucas

-- 
Pengutronix e.K.                           | Lucas Stach                 |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox