Re: [U-Boot] [PATCH 2/2] i.MX6: nand: add nandbcb command for imx

[Sergey Kubushyn]

On Mon, 10 Jun 2019, Stefano Babic wrote:




On 10/06/19 19:35, Sergey Kubushyn wrote:

On Mon, 10 Jun 2019, Stefano Babic wrote:


Hi Jagan, Shyam,


[dd]


Thanks for this work - this is still missing in current U-Boot. I will
merge this for the upcoming release - letting this in, we could win some
more testers helping to adjust if there are some issues.


Thanks. Looks like it is FINALLY making it into the main tree...


Never say never...and it is not yet in.


:)


Patch breaks several boards due to the moving of  mxs-nand.h.  In fact,
drivers/mtd/nand/raw/mxs_nand_dt.c expects to find the file in the same
directory.

Could someone of you fix this and repost, please ?


Eh, let Shyam do this -- I'm out of programming realm now, back to
Electrical Engineering which is my primary trade...

Might get back from time to time as I'm still in charge of lowest level
firmware at my new job but that is not my primary role anymore...

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] i.MX6: nand: add nandbcb command for imx

[Sergey Kubushyn]

On Mon, 10 Jun 2019, Stefano Babic wrote:


Hi Jagan, Shyam,


[dd]


Thanks for this work - this is still missing in current U-Boot. I will
merge this for the upcoming release - letting this in, we could win some
more testers helping to adjust if there are some issues.


Thanks. Looks like it is FINALLY making it into the main tree...

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] dm: Add a No-op uclass

[Sergey Kubushyn]

On Fri, 22 Mar 2019, Jean-Jacques Hiblot wrote:

It is probably the right solution, just have one suggestion -- why wouldn't
we make it UCLASS_GLUE instead? NOP is too generic, IMHO and it is just NOP.
There is definitely a place for such thing but we might want to add some
specific functionality  for glues and NOP is not a very good place to do
so...

Just my $.25...

BTW, there is yet another thing with USB gadgets bound by a glue. The
usb_gadget_initialize() in udc-uclass.c calls uclass_get_device_by_seq()
that requires either already probed device or an alias. If neither is found
it fails so it is not possible to get USB Glue gadget subnode to come up
automagically.

Replacing uclass_get_device_by_seq() with plain uclass_get_device() solves
this problem -- it probes the device without a need for an alias. Tested
here on a custom imx8mq board.

Yet another $.25 :)


This uclass is intended for devices that do not need any features from the
uclass, including binding children.
This will typically be used by devices that are used to bind child devices
but do not use dm_scan_fdt_dev() to do it.

Signed-off-by: Jean-Jacques Hiblot 
---
drivers/core/uclass.c  | 5 +
include/dm/uclass-id.h | 1 +
2 files changed, 6 insertions(+)

diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index fc3157de39..dc9eb62893 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -757,3 +757,8 @@ int uclass_pre_remove_device(struct udevice *dev)
return 0;
}
#endif
+
+UCLASS_DRIVER(nop) = {
+   .id = UCLASS_NOP,
+   .name   = "nop",
+};
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index 86e59781b0..3797cd48f6 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -61,6 +61,7 @@ enum uclass_id {
UCLASS_MMC, /* SD / MMC card or chip */
UCLASS_MOD_EXP, /* RSA Mod Exp device */
UCLASS_MTD, /* Memory Technology Device (MTD) device */
+   UCLASS_NOP, /* No-op devices */
UCLASS_NORTHBRIDGE, /* Intel Northbridge / SDRAM controller */
UCLASS_NVME,/* NVM Express device */
UCLASS_PANEL,   /* Display panel, such as an LCD */
--
2.17.1



---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] UCLASS_MISC bug

[Sergey Kubushyn]

I would like to point that this was not a very good idea:

=== Cut ===
--- uboot-imx-next/drivers/misc/misc-uclass.c   2018-12-20 20:35:22.505180339 
-0800
+++ u-boot-imx/drivers/misc/misc-uclass.c   2019-03-13 11:50:19.408982814 
-0700
@@ -68,4 +68,7 @@ int misc_set_enabled(struct udevice *dev
 UCLASS_DRIVER(misc) = {
.id = UCLASS_MISC,
.name   = "misc",
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
+   .post_bind  = dm_scan_fdt_dev,
+#endif
 };
=== Cut ===

The problem comes up with all those "glue" layers like e.g. in usb/dwc3 and
everywhere else.

Those "glues" primarily bind drivers to e.g. USB interfaces like e.g.
dwc3-generic does. That is where it should stop because glue knows better
what to bind. However, after glue has bound appropriate drivers to their
interfaces that post_bind scans FDT again and finds yet another bunch of
drivers that it binds on top of what glue already bound. This happens e.g.
with DWC3 drivers that glues bind to interfaces depending on their declared
roles. However both peripheral and XHCI drivers are compatible with
"snps,dwc3" so they are bound on top creating a huge mess. Here is a dm tree
fragment of its action:

=== Cut ===
 phy  0  [ + ]   imx8mq_usb_phy|-- phy@381f0040
 misc 0  [ + ]   imx8m_dwc3_glue   |-- usb@3810
 usb  0  [   ]   imx8m_dwc3_periphera  |   |-- dwc3
 usb  0  [   ]   xhci-dwc3 |   `-- dwc3
 phy  1  [   ]   imx8mq_usb_phy|-- phy@382f0040
 misc 1  [   ]   imx8m_dwc3_glue   |-- usb@3820
 usb  1  [   ]   xhci-dwc3 |   |-- dwc3
 usb  2  [   ]   xhci-dwc3 |   `-- dwc3
=== Cut ===

The glue bound imx8m_dwc3_peripheral to USB0 then post_bind found yet
another "compatible" driver, xhci-dwc3 and bound it to the same interface.

Then glue bound xhci-dwc3 to USB1 but post_bind found yet another
"compatible" driver, xhci-dwc3 and bound it again so there are TWO xhci
drivers bound to the same interface.

This is simplified picture -- I removed "compatible" from my peripheral
driver so it only comes up once, under USB0. If I leave that "compatible"
with "snps,dwc3" there everything gets even weirder :(

That diff above is the latest 2019.04-rc3 u-boot-imx-next vs 2019.01-rc
something release.

We either need some additional special flag to disable that post_bind where
it is not needed or create a special new class for those binding "glues" or
this change should be reverted.

P.S. I'm going to post imx8m USB glue, USB PHY, USB peripheral initial
drivers probably Monday late night as they still need some cleanup. It all
works with full Linux Kernel DTS files, picks power domains from there.

Don't know what to do with my board-specific DTS as there is (and probably
will not be) our board submitted -- it is not secret but used in our devices
only and not available to the public -- so it doesn't make sense to post a
full DTS. Will probably send a fragment.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] imx8mq-evk: Outbound network packets lost

[Sergey Kubushyn]

On Fri, 1 Feb 2019, Chris Spencer wrote:


On Fri, 1 Feb 2019 at 16:10, Sergey Kubushyn  wrote:

Turns out there's already a patch to add the driver as part of the
i.MX8MM patch series. [1] Go figure.


What the fcuk is i.MX8MM? Are they going to do anything with their i.MX8MQ
documentation? It is currently at Rev.0 dated January 8, 2018. In its
present state it is not even a joke -- it is way worse than that. It is
missing lots of info while including hundreds and hundreds of pages that has
absolutely no relevance to i.MX8MQ like e.g. 120 pages long description of
different interfaces to LCDIF that simply don't apply to what's in that
chip. On the other hand there is _ABSOLUTELY_ nothing about e.g. USB PHYs in
that, sorry for an expression, documentation. Nada, zero, zilch. Not a word
about SIP. And it is all around their documentation. Hell, just try to find
out what those 4 input clock sources are to their PWM that are selectable
from a per-PWM configuration register...

And their only reaction for e.g. missing USB PHY information was "We told
design/documentation guys to include it in the future revisions" somewhen
around August last year. There we no revisions for a whole year since the
initial Rev.0 was released. Zero. Nada. Zilch. It is still that stinking
pile of manure, Rev.0 on NXP site.


Looks like the i.MX8M Mini. The naming of the i.MX8 variants seems to
be almost deliberatly confusing.


So they put some yet non-existing chip first in their priority list and
totally abandoned i.MX8MQ that is just year (?) old. Of course, they needed
yet another undocumented chip badly so everything else could wait. Then
there will be yet another one and so on. I bet i.MX8MM documentation will be
even worse than that of i.MX8MQ that is almost impossible task -- that pile
of manure was created by copypasting pieces from those different IPs they
somehow glued together to make that chip. Those pieces were not edited, no
glue description, many pieces are totally missing and so on. This is not
what one would expect from a company that is supposed to be a decent
semiconductor manufacturer.

It looks like the entire i.MX family is doomed. The last decent one was
i.MX6Q from Freescale. Once they got sold to NXP all that went downhill and
going to its death with constantly increasing speed.

Time to switch to Rockchip and its siblings and totally forget everything
not designed and made in China -- Chinese stuff is at least 2x better than
everything else while at least 2x cheaper. Documentation is way better and
their teams are very active here in U-Boot development unlike NXP.


I haven't had to do much with the documentation, but yeah it's kind of
inscrutable. Just finding anything is challenging.


If it is there at all. Like e.g. USB PHY. Or ethernet clocks. Or hundreds of
other things. Then one should somehow sort out what actually applies to this
particular chip and what just came in from copypasted IP desription and
totally bogus.


I guess that everything else must just happen to be usable in the
default reset state.


It won't work. Pins come up as GPIOs on powerup and something _MUST_
reconfigure them for Ethernet. If there is no driver and they are not
reconfigured in board files there will be no Ethernet.

Same is true with USB. DTS files reference USB PHY that doesn't have a
driver in U-Boot. DWC3 USB references driver that doesn't exist in U-Boot.
There is no wonder nothing works.


Sorry, I meant stuff like the usdhc (i.e., the bare minimum that needs
to work to boot into Linux). Something must do at least some
initialisation here to load U-Boot in the first place. I'm guessing
the Ethernet doesn't work for anyone using this chip at the moment on
the upstream U-Boot.


USDHC is initialized in non-DM fashion in SPL so it is still same old
thing...

As for Ethernet not working it is far from a single defficiency. There is no
USB, no PWM, no any signs of Video (LCDIF and friends) and much more. But
hey, they are busy working on that i.MX8MM that doesn't even exist yet so
we're good :(

That means we either have to take everything in our own hands and forget
about NXP or switch to something better. That actually makes sense -- what
would be the reason for holding on NXP vaporware when there are better,
cheaper, actively developed chips like e.g. RK3328 or even RK3399? Just look
at www.pine64.org and try to give a single reason why one would even think
of using any of those NXP chips. And whatever is on pine64.org is real,
existing things. I do even have ROCKPro64 on my desk now that I paid a
whopping $79 for the whole SBC with 4GBytes of RAM.

And there is even stock Fedora for Pine64 family...

Unfortunately our higher-ups made their choice in favor of i.MX8MQ on some
SOMs so I have no other choice but working on that Frankenstein...

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las

Re: [U-Boot] imx8mq-evk: Outbound network packets lost

[Sergey Kubushyn]

On Fri, 1 Feb 2019, Chris Spencer wrote:


On Thu, 31 Jan 2019 at 18:43, Sergey Kubushyn  wrote:

OK, it worked. The second patch is irrelevant for me because I'm working on
a custom device, not MCIMX8M-EVK (I don't have that, just using its
schematic from time to time as reference to its drivers and such) and I
_DID_ have "CONFIG_PINCTRL_IMX8M=y" in my config that made no good without
actual driver...

I wonder how come nobody noticed that so far? It should affect other
functionality that relies on proper pin muxing...

Anyway, it is solved so I'm on USB (host and peripheral) now. Next come
PWM/backlight/LCDIF->DSI->SN65DSI84->LVDS Panel (1024x768)...


Turns out there's already a patch to add the driver as part of the
i.MX8MM patch series. [1] Go figure.


What the fcuk is i.MX8MM? Are they going to do anything with their i.MX8MQ
documentation? It is currently at Rev.0 dated January 8, 2018. In its
present state it is not even a joke -- it is way worse than that. It is
missing lots of info while including hundreds and hundreds of pages that has
absolutely no relevance to i.MX8MQ like e.g. 120 pages long description of
different interfaces to LCDIF that simply don't apply to what's in that
chip. On the other hand there is _ABSOLUTELY_ nothing about e.g. USB PHYs in
that, sorry for an expression, documentation. Nada, zero, zilch. Not a word
about SIP. And it is all around their documentation. Hell, just try to find
out what those 4 input clock sources are to their PWM that are selectable
from a per-PWM configuration register...

And their only reaction for e.g. missing USB PHY information was "We told
design/documentation guys to include it in the future revisions" somewhen
around August last year. There we no revisions for a whole year since the
initial Rev.0 was released. Zero. Nada. Zilch. It is still that stinking
pile of manure, Rev.0 on NXP site.


I guess that everything else must just happen to be usable in the
default reset state.


It won't work. Pins come up as GPIOs on powerup and something _MUST_
reconfigure them for Ethernet. If there is no driver and they are not
reconfigured in board files there will be no Ethernet.

Same is true with USB. DTS files reference USB PHY that doesn't have a
driver in U-Boot. DWC3 USB references driver that doesn't exist in U-Boot.
There is no wonder nothing works.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] imx8mq-evk: Outbound network packets lost

[Sergey Kubushyn]

On Thu, 31 Jan 2019, Chris Spencer wrote:


On Wed, 30 Jan 2019 at 00:44, Sergey Kubushyn  wrote:

OK, I've got it working. The problem was DM FEC driver does _NOT_ do pin
muxing and FEC pins in i.MX8MQ come up as GPIOs after rest so no wonder it
can't talk to the PHY or whatever else.

I don't know yet if there is some setting that I've missed to force it to do
pin muxing but didn't find anything appropriate in reference fsl-imx8mq-evk
board configs or board source files.

Once pin muxing is done in the board file FEC comes up as expected, finds
the PHY and all network stuff works as expected.

Dedicated "regulator" and PHY reset works OK from DTB provided FEC driver is
patched for regulator (regulator_set_enable instead of regulator_autoset)
and PHY reset GPIO set "ACTIVE_LOW" in the board's DTS file (fec driver sets
it to "1" to reset then resets it to "0").

So it is either pin muxing is missing and one should do it in his board's
file or I've missed some setting that I can't find to get the DM FEC driver
to do it itself from DTS file.


Welp. There's no pinctrl driver. That would explain a lot...

The attached patches fix the networking in U-Boot for me (I can at
least ping; haven't tried anything else). If it works for you then I
will submit the patches properly with your Tested-by.

Weirdly, I still get the issue in Linux where it intermittently uses
the wrong phy driver, but, with this change, the generic phy driver
now seems to work fine. I guess maybe U-Boot is now leaving the phy in
a different state that happens to work.


OK, it worked. The second patch is irrelevant for me because I'm working on
a custom device, not MCIMX8M-EVK (I don't have that, just using its
schematic from time to time as reference to its drivers and such) and I
_DID_ have "CONFIG_PINCTRL_IMX8M=y" in my config that made no good without
actual driver...

I wonder how come nobody noticed that so far? It should affect other
functionality that relies on proper pin muxing...

Anyway, it is solved so I'm on USB (host and peripheral) now. Next come
PWM/backlight/LCDIF->DSI->SN65DSI84->LVDS Panel (1024x768)...

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] imx8mq-evk: Outbound network packets lost

[Sergey Kubushyn]

On Sat, 26 Jan 2019, Chris Spencer wrote:


On Sat, 26 Jan 2019 at 01:14, Sergey Kubushyn  wrote:

Thanks for a reply. The problem here is not with leftover descriptors -- it
is MDIO bus not working at all. It is either bogus speed/clock in DM mode or
something else that I haven't found yet. Reading all zeroes means there is
no communication with the PHY whatsoever, it comes from bare wire. And there
is no need for the PHY to be present at all for an MDIO transaction to
complete successfully -- PHY is a slave device with all clocks coming from
FEC MDIO so it WILL complete successfully even if it not connected to a PHY.
It is kinda like SPI that always succeeds for the master.


What I found when debugging the Linux driver is that an MII interrupt
was being delivered too early after the first MDIO read the driver
issues, resulting in it reading back the wrong value. I was able to
reliably stop this from happening by zeroing out ENET_MMFR immediately
before the driver sets ENET_MSCR. If I disable networking in U-Boot
then the problem in the Linux driver doesn't occur at all, so the only
explanation I can come up with is that U-Boot is somehow leaving
something in ENET_MMFR which is being unintentionally triggered when
the Linux driver sets ENET_MSCR. You have a very good point though
because the reads are still completing in U-Boot, even if they always
come back zero, so I'm not really sure how there would end up being
something left over in ENET_MMFR.


OK, I've got it working. The problem was DM FEC driver does _NOT_ do pin
muxing and FEC pins in i.MX8MQ come up as GPIOs after rest so no wonder it
can't talk to the PHY or whatever else.

I don't know yet if there is some setting that I've missed to force it to do
pin muxing but didn't find anything appropriate in reference fsl-imx8mq-evk
board configs or board source files.

Once pin muxing is done in the board file FEC comes up as expected, finds
the PHY and all network stuff works as expected.

Dedicated "regulator" and PHY reset works OK from DTB provided FEC driver is
patched for regulator (regulator_set_enable instead of regulator_autoset)
and PHY reset GPIO set "ACTIVE_LOW" in the board's DTS file (fec driver sets
it to "1" to reset then resets it to "0").

So it is either pin muxing is missing and one should do it in his board's
file or I've missed some setting that I can't find to get the DM FEC driver
to do it itself from DTS file.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC 1/3] dm: blk: add UCLASS_PARTITION

[Sergey Kubushyn]

On Tue, 29 Jan 2019, Alexander Graf wrote:


On 01/29/2019 04:17 AM, Sergey Kubushyn wrote:

 On Tue, 29 Jan 2019, AKASHI Takahiro wrote:

 My $.25 -- IMHO, block device partitions in Device Tree is _NOT_ a very
 good
 idea.


This is about device model, not device tree :). Device trees indeed should 
not contain partition information. Our internal object model however would do 
well if it had them.


DM assumes using Device Tree.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC 1/3] dm: blk: add UCLASS_PARTITION

[Sergey Kubushyn]

On Tue, 29 Jan 2019, AKASHI Takahiro wrote:

My $.25 -- IMHO, block device partitions in Device Tree is _NOT_ a very good
idea.

What if one decided to re-partition his drive? Or just use bigger or smaller
drive? Would he has to re-write DTS file and re-compile everything? And such
change is not something extraordinary, it is a routine action.

IMHO partitions do _NOT_ belong to Block Device. That's what partition
tables are.

It _MIGHT_ make sense for some particular devices such as MTD that don't
have partition tables but _NOT_ for Block Devices in general.


UCLASS_PARTITION device will be created as a child node of
UCLASS_BLK device.

Signed-off-by: AKASHI Takahiro 


---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] imx8mq-evk: Outbound network packets lost

[Sergey Kubushyn]

On Fri, 25 Jan 2019, Chris Spencer wrote:

Thanks for a reply. The problem here is not with leftover descriptors -- it
is MDIO bus not working at all. It is either bogus speed/clock in DM mode or
something else that I haven't found yet. Reading all zeroes means there is
no communication with the PHY whatsoever, it comes from bare wire. And there
is no need for the PHY to be present at all for an MDIO transaction to
complete successfully -- PHY is a slave device with all clocks coming from
FEC MDIO so it WILL complete successfully even if it not connected to a PHY.
It is kinda like SPI that always succeeds for the master.

Unfortunately NXPs, sorry for an expression, documentation is totally
useless -- for ENET clocks their RM (see p. 4335, 11.4.4) only tells "The
table found here describes the clock sources for ENET" and that's all
information available. There is no table "here" :) And that is not an
exception -- such "information" is all over their 6,800 pages thick
Reference Manual while stuffed with hundreds of totally bogus pages
absolutely irrelevant for i.MX8MQ SoC (see e.g. their 120+ pages long
description of LCDIF interfaces and external pins.)

Damn, Freescale was pretty decent on documentation but NXP is absolute
disaster...


On Thu, 24 Jan 2019 at 23:51, Sergey Kubushyn  wrote:

On Fri, 4 Jan 2019, Chris Spencer wrote:
Hi Chris,

Did you figure out what was wrong with the PHY always reading zeroes over
MDIO?

I have exactly same problem here with out i.MX8MQ-based device -- it worked
just fine with older U-Boot without DM_ETH but always reads zeroes over MDIO
with 2019.01...

I'm still fighting and will probably find the culprit but it would've saved
me some time if you had found what was wrong...

Your reply is highly appreciated.

My best regards,
Sergey.


Hi Sergey,

I never quite got to the bottom of why it doesn't work in U-Boot, but
I did discover that U-Boot's failure to correctly initialise the
Ethernet controller is what was breaking the Linux driver. Basically,
it's leaving behind an 'unspent' transfer request in the ENET_MMFR
register (otherwise known as FEC_MII_DATA in the Linux driver) which
gets triggered when the Linux driver starts initialising the Ethernet
controller. This has a nasty habit of interfering with the first
transfer request the driver tries to make.

If you don't need networking in U-Boot then you can just set
CONFIG_CMD_NET=n in your build config and that will fix the Linux
driver. I'm afraid I can't offer any further insight if you do need
networking in U-Boot.

Thanks,
Chris



---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] i.MX8M layout, rephrased

[Sergey Kubushyn]

On Wed, 26 Dec 2018, Fabio Estevam wrote:


On Wed, Dec 26, 2018 at 7:18 PM Sergey Kubushyn  wrote:


OK, so is it going to be IMX8M or MX8M?


Peng has already replied. It is going to be IMX8M:
http://git.denx.de/?p=u-boot/u-boot-imx.git;a=commitdiff;h=3d145ff59d183850f11ba4157f03d05fc2fcb992;hp=0c0fbad318dd6d5bee5685489455f5a5eb48ff31


OK, thanks. That's what I picked so won't have to re-do it again :)

BTW I somehow missed Peng's reply, never received that email.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] i.MX8M layout, rephrased

[Sergey Kubushyn]

On Wed, 26 Dec 2018, Tom Rini wrote:


On Mon, Dec 17, 2018 at 07:14:02PM -0800, Sergey Kubushyn wrote:


On Mon, 17 Dec 2018, Sergey Kubushyn wrote:

Yet another thought -- maybe it's time to move all 64-bit ARM stuff to its
own arch/arm64 as it is in Linux kernel since I don't remember when? There
are quite a few SoCs out there to justify such a move...


No, we don't want to split ARMv8 out from arch/arm.  In Linux the split
was done to leave a large amount of legacy decisions behind (similar to
how there was arch/i386 and arch/x86_64 and is now just arch/x86) which
we do not want/need to do.


OK, so is it going to be IMX8M or MX8M?

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] i.MX8M layout, rephrased

[Sergey Kubushyn]

On Mon, 17 Dec 2018, Sergey Kubushyn wrote:

Yet another thought -- maybe it's time to move all 64-bit ARM stuff to its
own arch/arm64 as it is in Linux kernel since I don't remember when? There
are quite a few SoCs out there to justify such a move...


I'm looking at U-Boot master tree and u-boot-imx repository. What we have
now is quite a mess for i.MX8M.

In master we have the following directories:

 arch/arm/mach-imx/imx8
 arch/arm/mach-imx/mx8m

 arch/arm/include/asm/arch-imx8
 arch/arm/include/asm/arch-mx8m

In u-boot-imx it is different:

 arch/arm/mach-imx/imx8
 arch/arm/mach-imx/imx8m (vs ../mx8m in master)

 arch/arm/include/asm/arch/arch-imx8
 arch/arm/include/asm/arch/arch-imx8m (vs ../mx8m in master)

The question is which one is going to make it in the master tree?

The problem here is that files from those directories are referenced in
multiple places and the "imx8m"/"mx8m" is all over in the header files and
sources so once we decided on either naming one tree would have to make a
lot of changes either adding or removing that 'i' before "mx8m".

Can anybody responsible tell _WHICH_ one is going to make it into the main
source tree? Would it be better if we decide on it sooner than later (i.e.
_NOW_) so we won't have to hunt it all over the tree later on?

I assume it should be "mx8m" as it is in master tree following suit for
other flavors so it is u-boot-imx tree that has to be fixed.


Another issue is that ARCH_IMX8 and ARCH_IMX8M are treated as different
ARCHITECTURES in u-boot-imx unlike e.g. IMX6 that is treated as one ARCH
with different flavors (SX/DL/Q/whatever). That makes a lot of unnecessary
confusion and, IMHO, should be somehow cleaned up to make it consistent.


Can anybody tell something on this? Any thoughts, ideas, recomendations?


---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] i.MX8M layout, rephrased

[Sergey Kubushyn]

I'm looking at U-Boot master tree and u-boot-imx repository. What we have
now is quite a mess for i.MX8M.

In master we have the following directories:

arch/arm/mach-imx/imx8
arch/arm/mach-imx/mx8m

arch/arm/include/asm/arch-imx8
arch/arm/include/asm/arch-mx8m

In u-boot-imx it is different:

arch/arm/mach-imx/imx8
arch/arm/mach-imx/imx8m (vs ../mx8m in master)

arch/arm/include/asm/arch/arch-imx8
arch/arm/include/asm/arch/arch-imx8m (vs ../mx8m in master)

The question is which one is going to make it in the master tree?

The problem here is that files from those directories are referenced in
multiple places and the "imx8m"/"mx8m" is all over in the header files and
sources so once we decided on either naming one tree would have to make a
lot of changes either adding or removing that 'i' before "mx8m".

Can anybody responsible tell _WHICH_ one is going to make it into the main
source tree? Would it be better if we decide on it sooner than later (i.e.
_NOW_) so we won't have to hunt it all over the tree later on?

I assume it should be "mx8m" as it is in master tree following suit for
other flavors so it is u-boot-imx tree that has to be fixed.


Another issue is that ARCH_IMX8 and ARCH_IMX8M are treated as different
ARCHITECTURES in u-boot-imx unlike e.g. IMX6 that is treated as one ARCH
with different flavors (SX/DL/Q/whatever). That makes a lot of unnecessary
confusion and, IMHO, should be somehow cleaned up to make it consistent.


Can anybody tell something on this? Any thoughts, ideas, recomendations?

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Quick question on i.MX8MQ

[Sergey Kubushyn]

I'm working on a i.MX8MQ port to our new device that is in very advanced
manufacturing stage. It is not a board but a self-contained terminal that is
going into production really soon (various molds are being done, mechanical
parts, wire harnesses and so on) so it would hardly be of general interest
i.e. I might submit some patches but not a new board.

I have one question right now for those involved and maintaning IMX tree.
What platform name is more likely to win, MX8M as in the main source tree
right now or IMX8M as in u-boot-imx.git?

It doesn't make a real difference but I would like to pick the more probable
one for my port so I won't have to add/remove that 'I' in a hundred
different files when u-boot-imx is merged into main tree.

I can use either one but would like to avoid that possible unnecessary job
later on when re-syncing with the main tree.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/2] arm: i.MX: Add CMD_NANDBCB Kconfig entry

[Sergey Kubushyn]

On Wed, 7 Feb 2018, Jagan Teki wrote:


Add Kconfig entry for CMD_NANDBCB, and default y on i.MX6
platform with NAND_MXS defined.

Signed-off-by: Jagan Teki 
---
Changes for v2:
- New patch

arch/arm/mach-imx/Kconfig | 11 +++
1 file changed, 11 insertions(+)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 3aec89d..a8c1239 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -71,6 +71,17 @@ config CMD_HDMIDETECT
  This enables the 'hdmidet' command which detects if an HDMI monitor
  is connected.

+config CMD_NANDBCB
+   bool "i.MX6 NAND Boot Control Block(BCB) command"
+   depends on NAND && CMD_MTDPARTS
+   default y if ARCH_MX6 && NAND_MXS
+   help
+ Unlike normal 'nand write/erase' commands, this command update
+ Boot Control Block(BCB) for i.MX6 platform NAND IP's.
+
+ This is similar to kobs-ng, which is used in Linux as seprate

^^^
Typo here


+ rootfs package.
+
config NXP_BOARD_REVISION
bool "Read NXP board revision from fuses"
depends on ARCH_MX6 || ARCH_MX7
--
2.7.4


---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Swig now required to build U-Boot?

[Sergey Kubushyn]

On Fri, 8 Dec 2017, Simon Glass wrote:


Hi Stephen,

On 8 December 2017 at 16:28, Stephen Warren  wrote:

Simon,

Is it expected that the latest u-boot-dm.git master branch now requires
swig? All the non-sandbox builds on my test systems are failing:

  CHK include/config/uboot.release
  CHK include/generated/timestamp_autogenerated.h
  GEN ./Makefile
  UPD include/generated/timestamp_autogenerated.h
  CHK include/config.h
  CFG u-boot.cfg
  SHIPPED scripts/dtc/pylibfdt/libfdt.i
  PYMOD   scripts/dtc/pylibfdt/_libfdt.so
unable to execute 'swig': No such file or directory
error: command 'swig' failed with exit status 1
make[4]: *** [scripts/dtc/pylibfdt/_libfdt.so] Error 1
make[3]: *** [scripts/dtc/pylibfdt] Error 2
make[2]: *** [scripts/dtc] Error 2
make[1]: *** [scripts] Error 2
make[1]: *** Waiting for unfinished jobs


Yes, unless we have a very recent libfdt on the system (and even then
I'm not sure that it is picked up). We need swig to build pylibfdt
which is needed for binman.


Err, would it be long before we need Java/Eclipse/Maven/younameit to just
build U-Boot?

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] accessing eMMC boot partitions from U-Boot

[Sergey Kubushyn]

On Mon, 13 Mar 2017, Stephen Warren wrote:


On 03/13/2017 07:08 PM, Sergey Kubushyn wrote:

 On Mon, 13 Mar 2017, Stephen Warren wrote:

>  On 03/13/2017 03:34 PM, Tim Harvey wrote:
> >   Greetings,
> > 
> >   I'm working with some boards with eMMC FLASH and understand that I 
> >   can
> >   set the fields of the PARTITION_CONFIG with the 'mmc partconf' 
> >   command

> >   to specify what partition is used for boot. Once I do that to set the
> >   boot0 partition for example, how can I access that  partition from
> >   within u-boot via mmc read/write? In Linux the kernel provides access
> >   to user/boot0/boot1/rpmb via different devices, but I don't see 
> >   u-boot

> >   doing that.
> 
>  The "mmc dev" command can be used to select which MMC device to

>  operate on. The "typical" command "mmc dev 0" selects the main
>  partition on MMC device 0 for later MMC-specific commands such as "mmc
>  read". You can add an extra parameter to that command to request a
>  specific HW partition, e.g. "mmc dev 0 1" selects boo0 of MMC device 0
>  and "mmc dev 0 2" selects boot1.
> 
>  A similar naming scheme exists for commands that take a complete

>  device specification each time. For example, "part list mmc 0" to list
>  partitions in the main partition on MMC device 0, or "part list mmc
>  0.1" to list partitions on boot0 of MMC device 0.

 Unfortunately this has absolutely nothing to do with eMMC _BOOT_
 partitions...


That's incorrect. See my other reply for details.


 There 2 of those on eMMC and they are _NOT_ accessible in
 this fashion. Neither they bear any FS on them.


The boot HW partitions are block storage just like any other. SW can place 
whatever data structures it wants into these HW partitions; the 
interpretation of any data stored here is up to the SW or HW that reads and 
interprets it, e.g. a SoC boot ROM. While many systems will place raw data 
here, others certainly do place SW partition tables, and perhaps even 
filesystems, in the HW partitions.


That would've meant something has changed since last year. Will check
tomorrow when I'm back at my desk.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] accessing eMMC boot partitions from U-Boot

[Sergey Kubushyn]

On Mon, 13 Mar 2017, Stephen Warren wrote:


On 03/13/2017 03:34 PM, Tim Harvey wrote:

 Greetings,

 I'm working with some boards with eMMC FLASH and understand that I can
 set the fields of the PARTITION_CONFIG with the 'mmc partconf' command
 to specify what partition is used for boot. Once I do that to set the
 boot0 partition for example, how can I access that  partition from
 within u-boot via mmc read/write? In Linux the kernel provides access
 to user/boot0/boot1/rpmb via different devices, but I don't see u-boot
 doing that.


The "mmc dev" command can be used to select which MMC device to operate on. 
The "typical" command "mmc dev 0" selects the main partition on MMC device 0 
for later MMC-specific commands such as "mmc read". You can add an extra 
parameter to that command to request a specific HW partition, e.g. "mmc dev 0 
1" selects boo0 of MMC device 0 and "mmc dev 0 2" selects boot1.


A similar naming scheme exists for commands that take a complete device 
specification each time. For example, "part list mmc 0" to list partitions in 
the main partition on MMC device 0, or "part list mmc 0.1" to list partitions 
on boot0 of MMC device 0.


Unfortunately this has absolutely nothing to do with eMMC _BOOT_
partitions... There 2 of those on eMMC and they are _NOT_ accessible in
this fashion. Neither they bear any FS on them. eMMC is _SPECIAL_ in that
respect -- although it does look like e.g. SD Card it has 2 additional
_HARDWARE_ boot partitions that none of other MMC devices have. Those are
invisible and they are _NOT_ a part of user partition.

I did try to push a patch that would've allowed to put U-Boot environment
into boot partitions so entire _USER_ partition would be free but
unfortunately it had been met with fierce resistance, as usual, as well as
my patch for writing a bootable U-Boot into boot NAND on iMX6. I will
probably make another attempt tomorrow or later this week as time permitted
against 2017-03 but will give up if this one also failed...

We do use U-Boot with those patches in production devices which we
manufacture many thousands of with no problems at all.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v7 18/21] mtd: nand: Kconfig: Add NAND_MXS entry

[Sergey Kubushyn]

On Wed, 12 Oct 2016, Jörg Krause wrote:


On Sa, 2016-10-08 at 18:00 +0530, Jagan Teki wrote:

From: Jagan Teki 

Added kconfig for NAND_MXS driver.

Cc: Scott Wood 
Cc: Simon Glass 
Cc: Fabio Estevam 
Cc: Stefano Babic 
Cc: Peng Fan 
Cc: Matteo Lisi 
Cc: Michael Trimarchi 
Signed-off-by: Jagan Teki 
---
 drivers/mtd/nand/Kconfig | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 5ce7d6d..df154bf 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -80,6 +80,13 @@ config NAND_ARASAN
      controller. This uses the hardware ECC for read and
      write operations.
 
+config NAND_MXS
+   bool "MXS NAND support"
+   depends on MX6


Isn't mxs supposed to be i.MX23/i.MX28 and not i.MX6?


i.MX6 has the same MXS NAND controller.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1]: filesystems : add "file exists" cmd

[Sergey Kubushyn]

On Sat, 8 Oct 2016, Sergey Kubushyn wrote:


On Sat, 8 Oct 2016, Tom Rini wrote:


 On Wed, Oct 05, 2016 at 12:38:01PM -0700, Sergey Kubushyn wrote:

>  This adds "file exists" commands to generic FS as well as to FAT, EXT4,
>  and UBIFS. Also adds "file size" command to UBIFS.
> 
>  The return value for "file exists" commands is REVERSED i.e. they

>  return 1 if file exists and 0 otherwise. This is a deliberate decision
>  because those commands are supposed to be used almost exclusively in
>  scripts and TRUE value is _not_ zero while FALSE is zero.
> 
>  As of now the only way to check for a file existence is to attempt a

>  read on that file (aka load.) That works but it makes an unnecessary
>  read, overwrites memory at destination address if file not a zero
>  length one, and outputs unnecessary messages to the console in any
>  case.
> 
>  Checking file existence in scripts is a valuable feature that allows

>  the higher level software (e.g. Linux) to interact with U-Boot by
>  creating some semaphore files and rebooting. We do use it quite
>  extensively for system setup at manufacturing time and for other
>  purposes (e.g. our Android "recovery" is implemented this way.)
> 
>  Signed-off-by: Sergey Kubushyn <k...@koi8.net>


 Can you please do this in at least two patches?  file size to ubi should
 be its own patch.  Also:


Sure, will do later today.


>  +int do_ext4_file_exists(cmd_tbl_t *cmdtp, int flag, int argc,
>  + char *const argv[])
>  +{
>  + int ret;
>  +
>  + ret = do_file_exists(cmdtp, flag, argc, argv, FS_TYPE_EXT);
>  + +   if (ret == 0) return 1;
>  + if (ret == 1) return 0;
>  + return ret;
>  +}

 I can only assume this hasn't been compile tested in a while, and you
 should simplify the code into a single if/else and a comment on what we
 want/mean.  Thanks!


The problem is do_file_exists() can return not just 0 if file exists or
1 if it doesn't but also a negative value for "I don't know" i.e. when
e.g. FS mount failed.

I don't know if those return codes are somehow processed further up (too
much time to dig everything to the bare metal) so I decided to return
that value as-is if it happened. Sure it could be done like e.g.

return (ret == 0);

even without any if-elses and it is probably the proper way to do it but
I fell victim of perfectionism :))

Will re-do it with the above construction and split in 2 parts. Will also
send it with git send-email so it won't end up garbled.


OK, please disregard this patch altogether. I somehow missed "test -e"
command that has been implemented something like 2 years ago and that
command makes this entire patch unnecessary.

I will rewrite my scripts with "test -e" before submitting new boards.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1]: environment in eMMC boot partition

[Sergey Kubushyn]

On Sat, 8 Oct 2016, Tom Rini wrote:


On Wed, Oct 05, 2016 at 01:28:07PM -0700, Sergey Kubushyn wrote:


This allows to place U-Boot environment into eMMC boot partition thus
saving space on user partition for the OS (or whatever.) When booting
off of eMMC many (all?) MCUs can use dedicated boot0/boot1 partitions
to boot so U-Boot (or SPL) is written to one (or both) such partitions.
When such boot configuration is used it makes sense to place environment
in the same partition where the U-Boot itself is so the entire user
partition is available for the OS.

It might be not well polished yet but it is a simple patch that can be
reworked later.

It uses 4 Kconfig variables right now which probably belong to the board
Kconfig. Those are:

CONFIG_ENV_IN_EMMC_BOOT -- tells that environment is in eMMC boot
 partition if defined

CONFIG_EMMC_ENV_PART -- tells which boot partition environment should be
 stored in (either 1 or 2)

CONFIG_EMMC_BOOT_PART -- which boot partition will be used by eMMC to
 read U-Boot/SPL binary for boot protocol (either 1 or 2.) That can be
 different from the environment partition

CONFIG_EMMC_BOOT_ACK -- tells that eMMC should provide boot ACKs if
 defined

Here is an excerpt from actual board Kconfig:


I think what's missing is that in the other cases where we do
environment in the eMMC boot partitions we don't need the boot ack part.
Can you see if the existing hooks work, when you add in something for
boot ack?


Eh, I _DO_ use existing hook. And one of the parameters passed to that
hook is boot ack (drivers/mmc/mmc_boot.c, line 101):

=== Cut ===
int mmc_set_part_conf(struct mmc *mmc, u8 ack, u8 part_num, u8 access)
=== Cut ===

I could've just set it to 0 unconditionally but there might be some board
configs that might require it to be enabled so I made it configurable.

And I don't think we have any boards with environment in boot partition
because there is simply no support for this in common/enc_mmc.c. Remember,
eMMC boot partition and a partition on eMMC you boot off of are totally
orthogonal :) Boot partitions (there are 2 of those and one user partition
on eMMC) are special. You have to explicitely switch to a boot partition
to access it. When U-Boot is started eMMC boot partition it had been read
off (if the system boots off of boot partition using special boot protocol)
is long gone and what U-Boot sees is _USER_ partition. One can create
up to 4 GP partitions on eMMC but those are _DIFFERENT_ partitions and
they all reside in _USER_ partition i.e. GP partitions just subdivide the
single _USER_ partition into up to 4 parts.

When you boot off of an eMMC boot partition U-Boot binary is written into
boot partition so no part of visible _USER_ partition is taken, not a
single byte. That means that only one 512-byte block of the user partition
is reserved (MBR/partition table) so one can start a primary DOS partition
on eMMC at block 1 and use the entire space up to the last block for that
partition. However there is still U-Boot environment that one has to put
somewhere. Although it is possible to put it into user partition starting
first DOS (or GP) partition at e.g. block 160 or so and using that gap
between MBR and start of the first partition for environment it is not a
right thing to do. This way we are wasting some otherwise useable eMMC
storage space while still have plenty of unused space in 2 boot partitions.

If we put U-Boot in a boot partition it is logical to put its environment
in the same partition, isn't it? This is even more logical knowing the
fact it would save us some storage space for the OS filesystem...

But anyway, please hold off -- that patch won't apply because the alpine
email client "beautifies" text-only emails for some moronic reasons by
adding trailing whitespace to _SOME_ lines on mail _SEND_ thus screwing up
the patch. I will re-send that patch using git send-email that seems to
work correctly in a couple of hours. I will format it to follow official
rules and add proper CCs before re-sending.

Did you get that nand-bootupdate patch I re-sent yesterday with git
send-email? Did it work if you got it? It's been done against u-boot-imx.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1]: environment in eMMC boot partition

[Sergey Kubushyn]

On Sat, 8 Oct 2016, Tom Rini wrote:


On Sat, Oct 08, 2016 at 03:41:50PM -0700, Sergey Kubushyn wrote:

On Sat, 8 Oct 2016, Tom Rini wrote:


On Wed, Oct 05, 2016 at 01:28:07PM -0700, Sergey Kubushyn wrote:


This allows to place U-Boot environment into eMMC boot partition thus
saving space on user partition for the OS (or whatever.) When booting
off of eMMC many (all?) MCUs can use dedicated boot0/boot1 partitions
to boot so U-Boot (or SPL) is written to one (or both) such partitions.
When such boot configuration is used it makes sense to place environment
in the same partition where the U-Boot itself is so the entire user
partition is available for the OS.

It might be not well polished yet but it is a simple patch that can be
reworked later.

It uses 4 Kconfig variables right now which probably belong to the board
Kconfig. Those are:

CONFIG_ENV_IN_EMMC_BOOT -- tells that environment is in eMMC boot
partition if defined

CONFIG_EMMC_ENV_PART -- tells which boot partition environment should be
stored in (either 1 or 2)

CONFIG_EMMC_BOOT_PART -- which boot partition will be used by eMMC to
read U-Boot/SPL binary for boot protocol (either 1 or 2.) That can be
different from the environment partition

CONFIG_EMMC_BOOT_ACK -- tells that eMMC should provide boot ACKs if
defined

Here is an excerpt from actual board Kconfig:


I think what's missing is that in the other cases where we do
environment in the eMMC boot partitions we don't need the boot ack part.
Can you see if the existing hooks work, when you add in something for
boot ack?


Eh, I _DO_ use existing hook. And one of the parameters passed to that
hook is boot ack (drivers/mmc/mmc_boot.c, line 101):

=== Cut ===
int mmc_set_part_conf(struct mmc *mmc, u8 ack, u8 part_num, u8 access)
=== Cut ===

I could've just set it to 0 unconditionally but there might be some board
configs that might require it to be enabled so I made it configurable.

And I don't think we have any boards with environment in boot partition
because there is simply no support for this in common/enc_mmc.c. Remember,


I've put environment on the boot partitions on the eMMC on Beaglebone
black for a number of years.  See include/configs/am335x_evm.h:
#elif defined(CONFIG_EMMC_BOOT)
#define CONFIG_ENV_IS_IN_MMC
#define CONFIG_SYS_MMC_ENV_DEV  1
#define CONFIG_SYS_MMC_ENV_PART 2
#define CONFIG_ENV_OFFSET   0x0
#define CONFIG_ENV_OFFSET_REDUND(CONFIG_ENV_OFFSET +
CONFIG_ENV_SIZE)
#define CONFIG_SYS_REDUNDAND_ENVIRONMENT

Now, I fully accept that it's not working in your case and there must be
something further needed.


That's all nice but it is not like it boots off of eMMC special boot
partition and environment is actually NOT in eMMC boot partition...

eMMC is special -- it has 2 additional boot partitions that are HIDDEN
on normal use and only used for special boot protocol that is only
implemented in SOME SoCs. Regular MMC card has only one hardware part
that is same as eMMC user partition. Actually there is yet another one
in eMMC called RPMB but that one is totally special and not a storage
partition at all. Linux shows up at least 3 partitions on eMMC that are
usually named /dev/block/mmcblkXboot[0,1] and /dev/block/mmcblkXpY so
boot partitions can be accessed as regular block devices. They are made
read-only by default so one has to set a partition R/W before it can be
written to.

Older SoCs can not take advantage of those boot partitions -- they treat
eMMC as a regular MMC device with only one partition and it works just
fine, just advanced eMMC features are wasted. i.MX6 boots off of eMMC
boot partition if available and there are special boot configuration
switches for this -- you can select the boot proto bus width, boot ACK,
and some other parameters. It is OK to waste those resources if SoC does
not support those -- there is no other choice anyway -- but if they ARE
supported why wouldn't we use those?

eMMC boot partitions are _NOT_ in eMMC address space by default -- all
address space corresponds to USER partition. In order to access a boot
(or RPMB) partition one has to issue a special mmc command writing to
extended command register, EXT_CSD[179] that allows to switch to a boot
partition. When you switched to a boot partition user partition becomes
unavailable i.e. the entire address space corresponds to that boot
partition you switched to and is looks like the only one available on
that eMMC device.

There are special compile-time config variables in U-Boot for including
boot and RPMB partition access (CONFIG_SUPPORT_EMMC_BOOT and
CONFIG_SUPPORT_EMMC_RPMB respectively) that add corresponding commands
and access methods to regular "mmc" command (cmd/mmc.c line 742 and
other places.) It is eMMC-specific, regular MMC devices do _NOT_ have
those features.

BTW, U-Boot list server ran out of space so it won't show up in regular
list posts until the space issu

Re: [U-Boot] [PATCH 1/1]: filesystems : add "file exists" cmd

[Sergey Kubushyn]

On Sat, 8 Oct 2016, Tom Rini wrote:


On Wed, Oct 05, 2016 at 12:38:01PM -0700, Sergey Kubushyn wrote:


This adds "file exists" commands to generic FS as well as to FAT, EXT4,
and UBIFS. Also adds "file size" command to UBIFS.

The return value for "file exists" commands is REVERSED i.e. they
return 1 if file exists and 0 otherwise. This is a deliberate decision
because those commands are supposed to be used almost exclusively in
scripts and TRUE value is _not_ zero while FALSE is zero.

As of now the only way to check for a file existence is to attempt a
read on that file (aka load.) That works but it makes an unnecessary
read, overwrites memory at destination address if file not a zero
length one, and outputs unnecessary messages to the console in any
case.

Checking file existence in scripts is a valuable feature that allows
the higher level software (e.g. Linux) to interact with U-Boot by
creating some semaphore files and rebooting. We do use it quite
extensively for system setup at manufacturing time and for other
purposes (e.g. our Android "recovery" is implemented this way.)

Signed-off-by: Sergey Kubushyn <k...@koi8.net>


Can you please do this in at least two patches?  file size to ubi should
be its own patch.  Also:


Sure, will do later today.


+int do_ext4_file_exists(cmd_tbl_t *cmdtp, int flag, int argc,
+   char *const argv[])
+{
+   int ret;
+
+   ret = do_file_exists(cmdtp, flag, argc, argv, FS_TYPE_EXT);
+ + if (ret == 0) return 1;
+   if (ret == 1) return 0;
+   return ret;
+}


I can only assume this hasn't been compile tested in a while, and you
should simplify the code into a single if/else and a comment on what we
want/mean.  Thanks!


The problem is do_file_exists() can return not just 0 if file exists or
1 if it doesn't but also a negative value for "I don't know" i.e. when
e.g. FS mount failed.

I don't know if those return codes are somehow processed further up (too
much time to dig everything to the bare metal) so I decided to return
that value as-is if it happened. Sure it could be done like e.g.

return (ret == 0);

even without any if-elses and it is probably the proper way to do it but
I fell victim of perfectionism :))

Will re-do it with the above construction and split in 2 parts. Will also
send it with git send-email so it won't end up garbled.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] Add support for eMMC environment in boot partition

[Sergey Kubushyn]

This allows to place U-Boot environment into eMMC boot partition thus
saving space on user partition for the OS (or whatever.) When booting
off of eMMC many (all?) MCUs can use dedicated boot0/boot1 partitions
to boot so U-Boot (or SPL) is written to one (or both) such partitions.
When such boot configuration is used it makes sense to place environment
in the same partition where the U-Boot itself is so the entire user
partition is available for the OS.

It might be not well polished yet but it is a simple patch that can be
reworked later.

It uses 4 Kconfig variables right now which probably belong to the board
Kconfig. Those are:

CONFIG_ENV_IN_EMMC_BOOT -- tells that environment is in eMMC boot
 partition if defined

CONFIG_EMMC_ENV_PART -- tells which boot partition environment should be
 stored in (either 1 or 2)

CONFIG_EMMC_BOOT_PART -- which boot partition will be used by eMMC to
 read U-Boot/SPL binary for boot protocol (either 1 or 2.) That can be
 different from the environment partition

CONFIG_EMMC_BOOT_ACK -- tells that eMMC should provide boot ACKs if
 defined

Here is an excerpt from actual board Kconfig:

=== Cut ===
config ENV_IN_EMMC_BOOT
bool "Environment is in eMMC boot partition"
default y

config EMMC_ENV_PART
hex "eMMC boot partition used for environment (1 or 2)"
default 1

config EMMC_BOOT_PART
hex "eMMC boot partition the board boots off of (1 or 2)"
default 1

config EMMC_BOOT_ACK
bool "Enable ACKs from eMMC when booting off of boot partition"
    default n
=== Cut ===

Signed-off-by: Sergey Kubushyn <k...@koi8.net>
Cc: Tom Rini <tr...@konsulko.com>
Cc: Pantelis Antoniou <pa...@antoniou-consulting.com>
---
 common/env_mmc.c | 50 ++
 1 file changed, 50 insertions(+)

diff --git a/common/env_mmc.c b/common/env_mmc.c
index 16f6a17..3b2477c 100644
--- a/common/env_mmc.c
+++ b/common/env_mmc.c
@@ -68,6 +68,45 @@ int env_init(void)
return 0;
 }
 
+#ifdef CONFIG_ENV_IN_EMMC_BOOT
+__weak u8 mmc_get_env_part(struct mmc *mmc)
+{
+   return CONFIG_EMMC_ENV_PART;
+}
+
+__weak u8 mmc_get_boot_part(struct mmc *mmc)
+{
+   return CONFIG_EMMC_BOOT_PART;
+}
+
+__weak u8 mmc_get_boot_ack(struct mmc *mmc)
+{
+#ifdef CONFIG_EMMC_BOOT_ACK
+   return 1;
+#else
+   return 0;
+#endif
+}
+
+static int mmc_set_env_part(struct mmc *mmc)
+{
+   int ret = 0;
+   u8 boot_part = 0;
+   u8 boot_ack = 0;
+   u8 env_part = 0;
+
+   boot_part = mmc_get_boot_part(mmc);
+   boot_ack = mmc_get_boot_ack(mmc);
+   env_part = mmc_get_env_part(mmc);
+
+   ret = mmc_set_part_conf(mmc, boot_ack, boot_part, env_part);
+
+   if (ret)
+   puts("MMC switch to boot partition failed\n");
+
+   return ret;
+}
+#else
 #ifdef CONFIG_SYS_MMC_ENV_PART
 __weak uint mmc_get_env_part(struct mmc *mmc)
 {
@@ -96,6 +135,7 @@ static int mmc_set_env_part(struct mmc *mmc)
 #else
 static inline int mmc_set_env_part(struct mmc *mmc) {return 0; };
 #endif
+#endif
 
 static const char *init_mmc_for_env(struct mmc *mmc)
 {
@@ -113,6 +153,15 @@ static const char *init_mmc_for_env(struct mmc *mmc)
 
 static void fini_mmc_for_env(struct mmc *mmc)
 {
+#ifdef CONFIG_ENV_IN_EMMC_BOOT
+   u8 boot_part = 0;
+   u8 boot_ack = 0;
+
+   boot_part = mmc_get_boot_part(mmc);
+   boot_ack = mmc_get_boot_ack(mmc);
+
+   mmc_set_part_conf(mmc, boot_ack, boot_part, 0);
+#else
 #ifdef CONFIG_SYS_MMC_ENV_PART
int dev = mmc_get_env_dev();
 
@@ -121,6 +170,7 @@ static void fini_mmc_for_env(struct mmc *mmc)
 #endif
blk_select_hwpart_devnum(IF_TYPE_MMC, dev, env_mmc_orig_hwpart);
 #endif
+#endif
 }
 
 #ifdef CONFIG_CMD_SAVEENV
-- 
2.5.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3] Add nand bootupdate command for i.MX6 and similar platforms

[Sergey Kubushyn]

This one adds nand_bootupdate command for i.MX6 and similar MCUs. It
generates proper NAND boot structures (FCB, DBBT, etc) and writes those
along with U-Boot imx image to where they belong so system would be able
to boot off of raw NAND.

As of now the only way to do it is by using user-space kobs-ng utility
that has lots of unnecessary bells and whistles and only runs from
Linux so it is impossible to update raw NAND U-Boot from U-Boot itself.

It does not give any choice for the actual data placement in NAND but
that is done deliberately -- there is no reason to put it anywhere but
the only location i.MX6 Boot ROM expects it to be.

Signed-off-by: Sergey Kubushyn <k...@koi8.net>
Cc: Scott Wood <o...@buserror.net>
Cc: Stefano Babic <sba...@denx.de>
---
Changes for v3:

- Renamed some functions to more appropriate names
- Files moved to where they belong
- Code cleanup
- Converted to Kconfig

 arch/arm/include/asm/imx-common/mxs_nand.h |  37 ++
 cmd/Kconfig|   9 +
 cmd/nand.c |  61 
 drivers/mtd/nand/Makefile  |   1 +
 drivers/mtd/nand/mxs_nand.c|   7 +-
 drivers/mtd/nand/mxs_nand_bootupdate.c | 556 +
 6 files changed, 668 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/include/asm/imx-common/mxs_nand.h
 create mode 100644 drivers/mtd/nand/mxs_nand_bootupdate.c

diff --git a/arch/arm/include/asm/imx-common/mxs_nand.h 
b/arch/arm/include/asm/imx-common/mxs_nand.h
new file mode 100644
index 000..7826a9f
--- /dev/null
+++ b/arch/arm/include/asm/imx-common/mxs_nand.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2015 PHYTEC Messtechnik GmbH,
+ * Author: Stefan Christ 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __NAND_MXS_H
+#define __NAND_MXS_H
+
+/*
+ * Functions are definied in drivers/mtd/nand/nand_mxs.c.  They are used to
+ * calculate the ECC Strength, BadBlockMarkerByte and BadBlockMarkerStartBit
+ * which are placed into the FCB structure. The i.MX6 ROM needs these
+ * parameters to read the firmware from NAND.
+ *
+ * The parameters depends on the pagesize and oobsize of NAND chips and are
+ * different for each combination. To avoid placing hardcoded values in the bbu
+ * update handler code, the generic calculation from the driver code is used.
+ */
+
+uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
+   uint32_t page_oob_size);
+
+uint32_t mxs_nand_mark_byte_offset(struct mtd_info *mtd);
+
+uint32_t mxs_nand_mark_bit_offset(struct mtd_info *mtd);
+
+#endif /* __NAND_MXS_H */
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 86554ea..520d3c3 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -571,6 +571,15 @@ config CMD_TIME
help
  Run commands and summarize execution time.
 
+config CMD_NAND_BOOTUPDATE
+   bool "Update NAND bootloader on iMX6 and its brethen"
+   depends on ARCH_MX6 && NAND_BOOT && CMD_NAND
+   help
+ Having iMX6 NAND U-Boot image in memory creates all necessary
+ structures and writes those where they belong along with that
+ U-Boot image so system is able to boot off of raw NAND. Kinda
+ like kobs-ng utility but simpler.
+
 # TODO: rename to CMD_SLEEP
 config CMD_MISC
bool "sleep"
diff --git a/cmd/nand.c b/cmd/nand.c
index c16ec77..d10b794 100644
--- a/cmd/nand.c
+++ b/cmd/nand.c
@@ -38,6 +38,11 @@ int find_dev_and_part(const char *id, struct mtd_device 
**dev,
  u8 *part_num, struct part_info **part);
 #endif
 
+#ifdef CONFIG_CMD_NAND_BOOTUPDATE
+/* This comes from a separate file in drivers/mtd/nand */
+int mxs_do_nand_bootupdate(ulong addr, size_t len);
+#endif
+
 static int nand_dump(struct mtd_info *mtd, ulong off, int only_oob,
 int repeat)
 {
@@ -372,6 +377,9 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
loff_t off, size, maxsize;
char *cmd, *s;
struct mtd_info *mtd;
+#ifdef CONFIG_CMD_NAND_BOOTUPDATE
+   size_t cnt;
+#endif
 #ifdef CONFIG_SYS_NAND_QUIET
int quiet = CONFIG_SYS_NAND_QUIET;
 #else
@@ -777,6 +785,48 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
}
 #endif
 
+#ifdef CONFIG_CMD_NAND_BOOTUPDATE
+   if (strncmp(cmd, "bootupdate", 10) == 0) {
+
+

[U-Boot] [PATCH v3] Add nand bootupdate command for i.MX6 and similar platforms

[Sergey Kubushyn]

This one adds nand_bootupdate command for i.MX6 and similar MCUs. It
generates proper NAND boot structures (FCB, DBBT, etc) and writes those
along with U-Boot imx image to where they belong so system would be able
to boot off of raw NAND.

As of now the only way to do it is by using user-space kobs-ng utility
that has lots of unnecessary bells and whistles and only runs from
Linux so it is impossible to update raw NAND U-Boot from U-Boot itself.

It does not give any choice for the actual data placement in NAND but
that is done deliberately -- there is no reason to put it anywhere but
the only location i.MX6 Boot ROM expects it to be.

Signed-off-by: Sergey Kubushyn <k...@koi8.net>
Cc: Scott Wood <o...@buserror.net>
Cc: Stefano Babic <sba...@denx.de>
---
Changes for v3:

- Renamed some functions to more appropriate names
- Files moved to where they belong
- Code cleanup
- Converted to Kconfig

 arch/arm/include/asm/imx-common/mxs_nand.h |  37 ++
 cmd/Kconfig|   9 +
 cmd/nand.c |  61 
 drivers/mtd/nand/Makefile  |   1 +
 drivers/mtd/nand/mxs_nand.c|   7 +-
 drivers/mtd/nand/mxs_nand_bootupdate.c | 556 +
 6 files changed, 668 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/include/asm/imx-common/mxs_nand.h
 create mode 100644 drivers/mtd/nand/mxs_nand_bootupdate.c

diff --git a/arch/arm/include/asm/imx-common/mxs_nand.h 
b/arch/arm/include/asm/imx-common/mxs_nand.h
new file mode 100644
index 000..7826a9f
--- /dev/null
+++ b/arch/arm/include/asm/imx-common/mxs_nand.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2015 PHYTEC Messtechnik GmbH,
+ * Author: Stefan Christ 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __NAND_MXS_H
+#define __NAND_MXS_H
+
+/*
+ * Functions are definied in drivers/mtd/nand/nand_mxs.c.  They are used to
+ * calculate the ECC Strength, BadBlockMarkerByte and BadBlockMarkerStartBit
+ * which are placed into the FCB structure. The i.MX6 ROM needs these
+ * parameters to read the firmware from NAND.
+ *
+ * The parameters depends on the pagesize and oobsize of NAND chips and are
+ * different for each combination. To avoid placing hardcoded values in the bbu
+ * update handler code, the generic calculation from the driver code is used.
+ */
+
+uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
+   uint32_t page_oob_size);
+
+uint32_t mxs_nand_mark_byte_offset(struct mtd_info *mtd);
+
+uint32_t mxs_nand_mark_bit_offset(struct mtd_info *mtd);
+
+#endif /* __NAND_MXS_H */
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 86554ea..520d3c3 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -571,6 +571,15 @@ config CMD_TIME
help
  Run commands and summarize execution time.
 
+config CMD_NAND_BOOTUPDATE
+   bool "Update NAND bootloader on iMX6 and its brethen"
+   depends on ARCH_MX6 && NAND_BOOT && CMD_NAND
+   help
+ Having iMX6 NAND U-Boot image in memory creates all necessary
+ structures and writes those where they belong along with that
+ U-Boot image so system is able to boot off of raw NAND. Kinda
+ like kobs-ng utility but simpler.
+
 # TODO: rename to CMD_SLEEP
 config CMD_MISC
bool "sleep"
diff --git a/cmd/nand.c b/cmd/nand.c
index c16ec77..d10b794 100644
--- a/cmd/nand.c
+++ b/cmd/nand.c
@@ -38,6 +38,11 @@ int find_dev_and_part(const char *id, struct mtd_device 
**dev,
  u8 *part_num, struct part_info **part);
 #endif
 
+#ifdef CONFIG_CMD_NAND_BOOTUPDATE
+/* This comes from a separate file in drivers/mtd/nand */
+int mxs_do_nand_bootupdate(ulong addr, size_t len);
+#endif
+
 static int nand_dump(struct mtd_info *mtd, ulong off, int only_oob,
 int repeat)
 {
@@ -372,6 +377,9 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
loff_t off, size, maxsize;
char *cmd, *s;
struct mtd_info *mtd;
+#ifdef CONFIG_CMD_NAND_BOOTUPDATE
+   size_t cnt;
+#endif
 #ifdef CONFIG_SYS_NAND_QUIET
int quiet = CONFIG_SYS_NAND_QUIET;
 #else
@@ -777,6 +785,48 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
}
 #endif
 
+#ifdef CONFIG_CMD_NAND_BOOTUPDATE
+   if (strncmp(cmd, "bootupdate", 10) == 0) {
+
+

Re: [U-Boot] [PATCH v2] Added nand bootupdate command for i.MX6 and similar systems

[Sergey Kubushyn]

On Fri, 7 Oct 2016, Fabio Estevam wrote:


On Fri, Oct 7, 2016 at 10:36 PM, Sergey Kubushyn <k...@koi8.net> wrote:


OK, it is done against the latest u-boot master as it is stated in that
manual on U-Boot patches. I don't know why it fails on u-boot-imx tree.
U-Boot master has been pulled 2 hours ago so it is the most recent one.


If I try to apply against U-Boot master which has top of tree commit:

commit 4dc34be4301e9f9ddca2d22a8ddb1161ee40f2d1
Author: Simon Glass <s...@chromium.org>
Date:   Sun Oct 2 18:01:11 2016 -0600

   README: Fix CONFIG_SYS_NAND_MAX_DEVICE typo

$ patch -p1 --dry-run < nand.patch
checking file arch/arm/include/asm/imx-common/mxs_nand.h
checking file cmd/Kconfig
Hunk #1 FAILED at 571.
1 out of 1 hunk FAILED
checking file cmd/nand.c
Hunk #1 FAILED at 38.
Hunk #2 FAILED at 372.
Hunk #3 FAILED at 777.
Hunk #4 FAILED at 798.
4 out of 4 hunks FAILED
checking file drivers/mtd/nand/Makefile
Hunk #1 FAILED at 67.
1 out of 1 hunk FAILED
checking file drivers/mtd/nand/mxs_nand.c
Hunk #1 FAILED at 26.
Hunk #2 FAILED at 150.
Hunk #3 FAILED at 226.
3 out of 3 hunks FAILED
checking file drivers/mtd/nand/mxs_nand_bootupdate.c


OK, I don't know why it is failing. It looks like some bug in my git
that generates that patch with format-patch command. I'm cloning master,
applying my changes, committing them, generating a patch. Then that
generated patch fails to apply to yet another fresh clone of the same
master with exactly the same errors you see.

Trying to find out what's wrong right now...

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] Added nand bootupdate command for i.MX6 and similar systems

[Sergey Kubushyn]

On Fri, 7 Oct 2016, Fabio Estevam wrote:


On Fri, Oct 7, 2016 at 8:30 PM, Sergey Kubushyn <k...@koi8.net> wrote:


This is my FOURTH attempt to get it into the main U-Boot tree. I do
really hope it would get applied before I retire.


No need for such comment in the commit log.

Tried to apply it against u-boot-imx tree:

patch -p1 --dry-run < nand.patch
checking file arch/arm/include/asm/imx-common/mxs_nand.h
checking file cmd/Kconfig
Hunk #1 FAILED at 571.
1 out of 1 hunk FAILED
checking file cmd/nand.c
Hunk #1 FAILED at 38.
Hunk #2 FAILED at 372.
Hunk #3 FAILED at 777.
Hunk #4 FAILED at 798.
4 out of 4 hunks FAILED
checking file drivers/mtd/nand/Makefile
Hunk #1 FAILED at 67.
1 out of 1 hunk FAILED
checking file drivers/mtd/nand/mxs_nand.c
Hunk #1 FAILED at 26.
Hunk #2 FAILED at 150.
Hunk #3 FAILED at 226.
3 out of 3 hunks FAILED
checking file drivers/mtd/nand/mxs_nand_bootupdate.c


OK, it is done against the latest u-boot master as it is stated in that
manual on U-Boot patches. I don't know why it fails on u-boot-imx tree.
U-Boot master has been pulled 2 hours ago so it is the most recent one.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] Added nand bootupdate command for i.MX6 and similar systems

[Sergey Kubushyn]

This one adds nand_bootupdate command for i.MX6 and similar MCUs. It
generates proper NAND boot structures (FCB, DBBT, etc) and writes those
along with U-Boot imx image to where they belong so system would be able
to boot off of raw NAND.

As of now the only way to do it is by using user-space kobs-ng utility
that has lots of unnecessary bells and whistles and only runs from
Linux so it is impossible to update raw NAND U-Boot from U-Boot itself.

It does not give any choice for the actual data placement in NAND but
that is done deliberately -- there is no reason to put it anywhere but
the only location i.MX6 Boot ROM expects it to be.

This is my FOURTH attempt to get it into the main U-Boot tree. I do
really hope it would get applied before I retire.


Signed-off-by: Sergey Kubushyn <k...@koi8.net>
Cc: Scott Wood <o...@buserror.net>
Cc: Stefano Babic <sba...@denx.de>
---
Changes for v2:

- Renamed some functions to more appropriate names
- Files moved to where they belong
- Code cleanup
- Converted to Kconfig

 arch/arm/include/asm/imx-common/mxs_nand.h |  37 ++
 cmd/Kconfig|  10 +
 cmd/nand.c |  61 
 drivers/mtd/nand/Makefile  |   1 +
 drivers/mtd/nand/mxs_nand.c|   7 +-
 drivers/mtd/nand/mxs_nand_bootupdate.c | 556 +
 6 files changed, 669 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/include/asm/imx-common/mxs_nand.h
 create mode 100644 drivers/mtd/nand/mxs_nand_bootupdate.c

diff --git a/arch/arm/include/asm/imx-common/mxs_nand.h 
b/arch/arm/include/asm/imx-common/mxs_nand.h
new file mode 100644
index 000..7826a9f
--- /dev/null
+++ b/arch/arm/include/asm/imx-common/mxs_nand.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2015 PHYTEC Messtechnik GmbH,
+ * Author: Stefan Christ 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __NAND_MXS_H
+#define __NAND_MXS_H
+
+/*
+ * Functions are definied in drivers/mtd/nand/nand_mxs.c.  They are used to
+ * calculate the ECC Strength, BadBlockMarkerByte and BadBlockMarkerStartBit
+ * which are placed into the FCB structure. The i.MX6 ROM needs these
+ * parameters to read the firmware from NAND.
+ *
+ * The parameters depends on the pagesize and oobsize of NAND chips and are
+ * different for each combination. To avoid placing hardcoded values in the bbu
+ * update handler code, the generic calculation from the driver code is used.
+ */
+
+uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
+   uint32_t page_oob_size);
+
+uint32_t mxs_nand_mark_byte_offset(struct mtd_info *mtd);
+
+uint32_t mxs_nand_mark_bit_offset(struct mtd_info *mtd);
+
+#endif /* __NAND_MXS_H */
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 86554ea..6ef7253 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -571,6 +571,16 @@ config CMD_TIME
help
  Run commands and summarize execution time.

+config CMD_NAND_BOOTUPDATE
+   bool "Update NAND bootloader on iMX6 and its brethen"
+   depends on ARCH_MX6 && NAND_BOOT && CMD_NAND
+   help
+ Having iMX6 NAND U-Boot image in memory creates all necessary
+ structures and writes those where they belong along with that
+ U-Boot image so system is able to boot off of raw NAND. Kinda
+ like kobs-ng utility but simpler.
+
+
 # TODO: rename to CMD_SLEEP
 config CMD_MISC
bool "sleep"
diff --git a/cmd/nand.c b/cmd/nand.c
index c16ec77..c25f1ef 100644
--- a/cmd/nand.c
+++ b/cmd/nand.c
@@ -38,6 +38,11 @@ int find_dev_and_part(const char *id, struct mtd_device 
**dev,
  u8 *part_num, struct part_info **part);
 #endif

+#ifdef CONFIG_CMD_NAND_BOOTUPDATE
+/* This comes from a separate file in drivers/mtd/nand */
+int mxs_do_nand_bootupdate(ulong addr, size_t len);
+#endif
+
 static int nand_dump(struct mtd_info *mtd, ulong off, int only_oob,
 int repeat)
 {
@@ -372,6 +377,9 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
loff_t off, size, maxsize;
char *cmd, *s;
struct mtd_info *mtd;
+#ifdef CONFIG_CMD_NAND_BOOTUPDATE
+   size_t cnt;
+#endif
 #ifdef CONFIG_SYS_NAND_QUIET
int quiet = CONFIG_SYS_NAND_QUIET;
 #else
@@ -777,6 +785,48 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
}
 #endif

+#ifdef CONFIG_CM

Re: [U-Boot] [PATCH 1/1]: add nand_bootupdate for i.MX6 and likes

[Sergey Kubushyn]

On Fri, 7 Oct 2016, Scott Wood wrote:


On Wed, 2016-10-05 at 12:57 -0700, Sergey Kubushyn wrote:

This one adds nand_bootupdate command for i.MX6 and similar MCUs. It
generates proper NAND boot structures (FCB, DBBT, etc) and writes those
along with U-Boot mx image to where they belong so system would be able
to boot off of raw NAND.


This seems like a lot of code just to write some images to various places.
 What are these "NAND boot structures" and do they really need to be generated
by U-Boot, or can they be generated by a tool to produce an image that U-Boot
writes to NAND as is?  I do see there are some things to be filled in based on
NAND parameters, bad blocks, etc. but can this patching up be minimized (and
the necessary parts explained in the changelog)?


The entire idea is to _REPLACE_ the only existing tool, kobs-ng. It only
works from Linux so one has to get everything up and running before he
could actually write U-Boot in NAND that is catch 22.

It can _NOT_ be generated with an external tool somewhere else because it
is specific to the NAND chip installed on a particular board i.e. it MUST
be generated in-place. Furthermore it is NOT a static info as it can change
as time goes and NAND develops new bad blocks so it MUST be re-generated
each and every time U-Boot is written to a particular board's NAND.

Those NAND boot structures are headers required by i.MX6 and their brethen
Boot ROM to boot off of raw NAND. It won't boot if any of those headers is
missing or incorrect.

There is no other method for putting i.MX6 NAND U-boot for bootup from
raw NAND at present time other than using kobs-ng utility under Linux
_RAN ON THAT PARTICULAR BOARD_ where U-Boot needs to be written to NAND.


This is my THIRD attempt to get it into the main U-Boot tree. I do
really hope it would get applied before I retire.


It helps to CC relevant people...


Making another patch with proper CCs now so the ritual will be performed
properly.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/1]: nand bootupdate for i.MX6 -- REBASED

[Sergey Kubushyn]

Here it is agains your latest u-boot-imx master.

Won't post that description again to lower the noise level, just a diff
itself.

Signed-off-by: Sergey Kubushyn <k...@koi8.net>
---
 arch/arm/include/asm/imx-common/mxs_nand.h |  37 ++
 cmd/Kconfig|  10 +
 cmd/nand.c |  61 +++
 drivers/mtd/nand/Makefile  |   1 +
 drivers/mtd/nand/mxs_nand.c|   7 +-
 drivers/mtd/nand/mxs_nand_bootupdate.c | 556 +
 6 files changed, 669 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/imx-common/mxs_nand.h 
b/arch/arm/include/asm/imx-common/mxs_nand.h
new file mode 100644
index 000..7826a9f
--- /dev/null
+++ b/arch/arm/include/asm/imx-common/mxs_nand.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2015 PHYTEC Messtechnik GmbH,
+ * Author: Stefan Christ 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __NAND_MXS_H
+#define __NAND_MXS_H
+
+/*
+ * Functions are definied in drivers/mtd/nand/nand_mxs.c.  They are used to
+ * calculate the ECC Strength, BadBlockMarkerByte and BadBlockMarkerStartBit
+ * which are placed into the FCB structure. The i.MX6 ROM needs these
+ * parameters to read the firmware from NAND.
+ *
+ * The parameters depends on the pagesize and oobsize of NAND chips and are
+ * different for each combination. To avoid placing hardcoded values in the bbu
+ * update handler code, the generic calculation from the driver code is used.
+ */
+
+uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
+   uint32_t page_oob_size);
+
+uint32_t mxs_nand_mark_byte_offset(struct mtd_info *mtd);
+
+uint32_t mxs_nand_mark_bit_offset(struct mtd_info *mtd);
+
+#endif /* __NAND_MXS_H */
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 86554ea..6ef7253 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -571,6 +571,16 @@ config CMD_TIME
help
  Run commands and summarize execution time.

+config CMD_NAND_BOOTUPDATE
+   bool "Update NAND bootloader on iMX6 and its brethen"
+   depends on ARCH_MX6 && NAND_BOOT && CMD_NAND
+   help
+ Having iMX6 NAND U-Boot image in memory creates all necessary
+ structures and writes those where they belong along with that
+ U-Boot image so system is able to boot off of raw NAND. Kinda
+ like kobs-ng utility but simpler.
+
+
 # TODO: rename to CMD_SLEEP
 config CMD_MISC
bool "sleep"
diff --git a/cmd/nand.c b/cmd/nand.c
index c16ec77..c25f1ef 100644
--- a/cmd/nand.c
+++ b/cmd/nand.c
@@ -38,6 +38,11 @@ int find_dev_and_part(const char *id, struct mtd_device 
**dev,
  u8 *part_num, struct part_info **part);
 #endif

+#ifdef CONFIG_CMD_NAND_BOOTUPDATE
+/* This comes from a separate file in drivers/mtd/nand */
+int mxs_do_nand_bootupdate(ulong addr, size_t len);
+#endif
+
 static int nand_dump(struct mtd_info *mtd, ulong off, int only_oob,
 int repeat)
 {
@@ -372,6 +377,9 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
loff_t off, size, maxsize;
char *cmd, *s;
struct mtd_info *mtd;
+#ifdef CONFIG_CMD_NAND_BOOTUPDATE
+   size_t cnt;
+#endif
 #ifdef CONFIG_SYS_NAND_QUIET
int quiet = CONFIG_SYS_NAND_QUIET;
 #else
@@ -777,6 +785,48 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
}
 #endif

+#ifdef CONFIG_CMD_NAND_BOOTUPDATE
+   if (strncmp(cmd, "bootupdate", 10) == 0) {
+
+   if (argc < 3) {
+   /* All default values */
+   addr = getenv_ulong("fileaddr", 16, 0UL);
+   cnt = getenv_ulong("filesize", 16, 0UL);
+   }
+
+   if (argc == 3) {
+   /* 'addr' only, file size from environment */
+   if ((addr = simple_strtoul(argv[2], NULL, 16)) == 0UL)
+   addr = getenv_ulong("fileaddr", 16, 0UL);
+
+   cnt = getenv_ulong("filesize", 16, 0UL);
+   }
+
+   if (argc > 3) {
+   /* 'addr', 'size', and possibly more */
+   if ((addr = simple_strtoul(argv[2], NULL, 16)) == 0UL)
+   addr = getenv_ulong("fileaddr", 16, 0UL);
+
+   if ((cnt = simpl

Re: [U-Boot] [PATCH 1/1]: add nand_bootupdate for i.MX6 and likes

[Sergey Kubushyn]

On Fri, 7 Oct 2016, Stefano Babic wrote:


Hi Sergey,

On 07/10/2016 17:04, Sergey Kubushyn wrote:


Can you please check this (before you retire, of course !) ?


What should I use a base? I did my patches against whatever is the main
U-Boot git tree (doing git pull befofe generating patches)


I tried on top of v2016.11-rc1, but it fails.


but it is a
moving target


..yes, this is the game :-)


so there is absolutely no guarantee it will work if I pull
again and redo the patches against whatever it is today.


Do not worry - I merge the small conflicts, but patches shoult at least
appliable on the last tag set by Tom un -master.



Any particular version/repo/commit/whatever I should use?


Can you take then on top of u-boot-imx, -master ? This is where patches
are applied first.


Will do in a couple of hours.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1]: add nand_bootupdate for i.MX6 and likes

[Sergey Kubushyn]

On Fri, 7 Oct 2016, Stefano Babic wrote:


Hi Sergey,

On 05/10/2016 21:57, Sergey Kubushyn wrote:

This one adds nand_bootupdate command for i.MX6 and similar MCUs. It
generates proper NAND boot structures (FCB, DBBT, etc) and writes those
along with U-Boot mx image to where they belong so system would be able
to boot off of raw NAND.

As of now the only way to do it is by using user-space kobs-ng utility
that has lots of unnecessary bells and whistles and only runs from
Linux so it is impossible to update raw NAND U-Boot from U-Boot itself.

It does not give any choice for the actual data placement in NAND but
that is done deliberately -- there is no reason to put it anywhere but
the only location i.MX6 Boot ROM expects it to be.

This is my THIRD attempt to get it into the main U-Boot tree. I do
really hope it would get applied before I retire.



Do not think twice, I would *really* like to have this feature merged.
But the patch should at least be applied clean. I cannot apply it
becuase there are conflicts in cmd/nand.c and mxs_nand.c (the other
conflicts are marginals).

Can you please check this (before you retire, of course !) ?


What should I use a base? I did my patches against whatever is the main
U-Boot git tree (doing git pull befofe generating patches) but it is a
moving target so there is absolutely no guarantee it will work if I pull
again and redo the patches against whatever it is today.

Any particular version/repo/commit/whatever I should use?



Best regards,
Stefano Babic



Signed-off-by: Sergey Kubushyn <k...@koi8.net>
---
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -571,6 +571,16 @@ config CMD_TIME
 help
   Run commands and summarize execution time.

+config CMD_NAND_BOOTUPDATE
+bool "Update NAND bootloader on iMX6 and its brethen"
+depends on ARCH_MX6 && NAND_BOOT && CMD_NAND
+help
+  Having iMX6 NAND U-Boot image in memory creates all necessary
+  structures and writes those where they belong along with that
+  U-Boot image so system is able to boot off of raw NAND. Kinda
+  like kobs-ng utility but simpler.
+
+
 # TODO: rename to CMD_SLEEP
 config CMD_MISC
 bool "sleep"

--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_NAND_OMAP_GPMC) += omap_gpmc.o
 obj-$(CONFIG_NAND_OMAP_ELM) += omap_elm.o
 obj-$(CONFIG_NAND_PLAT) += nand_plat.o
 obj-$(CONFIG_NAND_SUNXI) += sunxi_nand.o
+obj-$(CONFIG_CMD_NAND_BOOTUPDATE) += mxs_nand_bootupdate.o

 else  # minimal SPL drivers

--- a/drivers/mtd/nand/mxs_nand.c
+++ b/drivers/mtd/nand/mxs_nand.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 

 #defineMXS_NAND_DMA_DESCRIPTOR_COUNT4

@@ -150,7 +151,7 @@ static uint32_t mxs_nand_aux_status_offset(void)
 return (MXS_NAND_METADATA_SIZE + 0x3) & ~0x3;
 }

-static inline uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
+uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
 uint32_t page_oob_size)
 {
 int ecc_strength;
@@ -226,14 +227,14 @@ static inline uint32_t
mxs_nand_get_mark_offset(uint32_t page_data_size,
 return block_mark_bit_offset;
 }

-static uint32_t mxs_nand_mark_byte_offset(struct mtd_info *mtd)
+uint32_t mxs_nand_mark_byte_offset(struct mtd_info *mtd)
 {
 uint32_t ecc_strength;
 ecc_strength = mxs_nand_get_ecc_strength(mtd->writesize,
mtd->oobsize);
 return mxs_nand_get_mark_offset(mtd->writesize, ecc_strength) >> 3;
 }

-static uint32_t mxs_nand_mark_bit_offset(struct mtd_info *mtd)
+uint32_t mxs_nand_mark_bit_offset(struct mtd_info *mtd)
 {
 uint32_t ecc_strength;
 ecc_strength = mxs_nand_get_ecc_strength(mtd->writesize,
mtd->oobsize);

--- /dev/null
+++ b/arch/arm/include/asm/imx-common/mxs_nand.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2015 PHYTEC Messtechnik GmbH,
+ * Author: Stefan Christ 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __NAND_MXS_H
+#define __NAND_MXS_H
+
+/*
+ * Functions are definied in drivers/mtd/nand/nand_mxs.c.  They are
used to
+ * calculate the ECC Strength, BadBlockMarkerByte and
BadBlockMarkerStartBit
+ * which are placed into the FCB structure. The i.MX6 ROM needs these
+ * parameters to read the firmware from NAND.
+ *
+ * The parameters depends on the pagesize and oobsize of NAND chips and
are
+ * different for each combination. To avoid placing hardcoded values in
the bbu
+ * update handler code, the generic calculation from 

[U-Boot] [PATCH 1/1]: environment in eMMC boot partition

[Sergey Kubushyn]

This allows to place U-Boot environment into eMMC boot partition thus
saving space on user partition for the OS (or whatever.) When booting
off of eMMC many (all?) MCUs can use dedicated boot0/boot1 partitions
to boot so U-Boot (or SPL) is written to one (or both) such partitions.
When such boot configuration is used it makes sense to place environment
in the same partition where the U-Boot itself is so the entire user
partition is available for the OS.

It might be not well polished yet but it is a simple patch that can be
reworked later.

It uses 4 Kconfig variables right now which probably belong to the board
Kconfig. Those are:

CONFIG_ENV_IN_EMMC_BOOT -- tells that environment is in eMMC boot
 partition if defined

CONFIG_EMMC_ENV_PART -- tells which boot partition environment should be
 stored in (either 1 or 2)

CONFIG_EMMC_BOOT_PART -- which boot partition will be used by eMMC to
 read U-Boot/SPL binary for boot protocol (either 1 or 2.) That can be
 different from the environment partition

CONFIG_EMMC_BOOT_ACK -- tells that eMMC should provide boot ACKs if
 defined

Here is an excerpt from actual board Kconfig:

=== Cut ===
config ENV_IN_EMMC_BOOT
bool "Environment is in eMMC boot partition"
default y

config EMMC_ENV_PART
hex "eMMC boot partition used for environment (1 or 2)"
default 1

config EMMC_BOOT_PART
hex "eMMC boot partition the board boots off of (1 or 2)"
default 1

config EMMC_BOOT_ACK
bool "Enable ACKs from eMMC when booting off of boot partition"
    default n
=== Cut ===

Signed-off-by: Sergey Kubushyn <k...@koi8.net>
---
--- a/common/env_mmc.c
+++ b/common/env_mmc.c
@@ -68,6 +68,45 @@ int env_init(void)
return 0;
 }

+#ifdef CONFIG_ENV_IN_EMMC_BOOT
+__weak u8 mmc_get_env_part(struct mmc *mmc)
+{
+   return CONFIG_EMMC_ENV_PART;
+}
+
+__weak u8 mmc_get_boot_part(struct mmc *mmc)
+{
+   return CONFIG_EMMC_BOOT_PART;
+}
+
+__weak u8 mmc_get_boot_ack(struct mmc *mmc)
+{
+#ifdef CONFIG_EMMC_BOOT_ACK
+   return 1;
+#else
+   return 0;
+#endif
+}
+
+static int mmc_set_env_part(struct mmc *mmc)
+{
+   int ret = 0;
+   u8 boot_part = 0;
+   u8 boot_ack = 0;
+   u8 env_part = 0;
+
+   boot_part = mmc_get_boot_part(mmc);
+   boot_ack = mmc_get_boot_ack(mmc);
+   env_part = mmc_get_env_part(mmc);
+
+   ret = mmc_set_part_conf(mmc, boot_ack, boot_part, env_part);
+
+   if (ret)
+   puts("MMC switch to boot partition failed\n");
+
+   return ret;
+}
+#else
 #ifdef CONFIG_SYS_MMC_ENV_PART
 __weak uint mmc_get_env_part(struct mmc *mmc)
 {
@@ -96,6 +135,7 @@ static int mmc_set_env_part(struct mmc *mmc)
 #else
 static inline int mmc_set_env_part(struct mmc *mmc) {return 0; };
 #endif
+#endif

 static const char *init_mmc_for_env(struct mmc *mmc)
 {
@@ -113,6 +153,15 @@ static const char *init_mmc_for_env(struct mmc *mmc)

 static void fini_mmc_for_env(struct mmc *mmc)
 {
+#ifdef CONFIG_ENV_IN_EMMC_BOOT
+   u8 boot_part = 0;
+   u8 boot_ack = 0;
+
+   boot_part = mmc_get_boot_part(mmc);
+   boot_ack = mmc_get_boot_ack(mmc);
+
+   mmc_set_part_conf(mmc, boot_ack, boot_part, 0);
+#else
 #ifdef CONFIG_SYS_MMC_ENV_PART
int dev = mmc_get_env_dev();

@@ -121,6 +170,7 @@ static void fini_mmc_for_env(struct mmc *mmc)
 #endif
blk_select_hwpart_devnum(IF_TYPE_MMC, dev, env_mmc_orig_hwpart);
 #endif
+#endif
 }

 #ifdef CONFIG_CMD_SAVEENV


---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/1]: add nand_bootupdate for i.MX6 and likes

[Sergey Kubushyn]

This one adds nand_bootupdate command for i.MX6 and similar MCUs. It
generates proper NAND boot structures (FCB, DBBT, etc) and writes those
along with U-Boot mx image to where they belong so system would be able
to boot off of raw NAND.

As of now the only way to do it is by using user-space kobs-ng utility
that has lots of unnecessary bells and whistles and only runs from
Linux so it is impossible to update raw NAND U-Boot from U-Boot itself.

It does not give any choice for the actual data placement in NAND but
that is done deliberately -- there is no reason to put it anywhere but
the only location i.MX6 Boot ROM expects it to be.

This is my THIRD attempt to get it into the main U-Boot tree. I do
really hope it would get applied before I retire.

Signed-off-by: Sergey Kubushyn <k...@koi8.net>
---
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -571,6 +571,16 @@ config CMD_TIME
help
  Run commands and summarize execution time.

+config CMD_NAND_BOOTUPDATE
+   bool "Update NAND bootloader on iMX6 and its brethen"
+   depends on ARCH_MX6 && NAND_BOOT && CMD_NAND
+   help
+ Having iMX6 NAND U-Boot image in memory creates all necessary
+ structures and writes those where they belong along with that
+ U-Boot image so system is able to boot off of raw NAND. Kinda
+ like kobs-ng utility but simpler.
+
+
 # TODO: rename to CMD_SLEEP
 config CMD_MISC
bool "sleep"

--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_NAND_OMAP_GPMC) += omap_gpmc.o
 obj-$(CONFIG_NAND_OMAP_ELM) += omap_elm.o
 obj-$(CONFIG_NAND_PLAT) += nand_plat.o
 obj-$(CONFIG_NAND_SUNXI) += sunxi_nand.o
+obj-$(CONFIG_CMD_NAND_BOOTUPDATE) += mxs_nand_bootupdate.o

 else  # minimal SPL drivers

--- a/drivers/mtd/nand/mxs_nand.c
+++ b/drivers/mtd/nand/mxs_nand.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 

 #defineMXS_NAND_DMA_DESCRIPTOR_COUNT   4

@@ -150,7 +151,7 @@ static uint32_t mxs_nand_aux_status_offset(void)
return (MXS_NAND_METADATA_SIZE + 0x3) & ~0x3;
 }

-static inline uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
+uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
uint32_t page_oob_size)
 {
int ecc_strength;
@@ -226,14 +227,14 @@ static inline uint32_t mxs_nand_get_mark_offset(uint32_t 
page_data_size,
return block_mark_bit_offset;
 }

-static uint32_t mxs_nand_mark_byte_offset(struct mtd_info *mtd)
+uint32_t mxs_nand_mark_byte_offset(struct mtd_info *mtd)
 {
uint32_t ecc_strength;
ecc_strength = mxs_nand_get_ecc_strength(mtd->writesize, mtd->oobsize);
return mxs_nand_get_mark_offset(mtd->writesize, ecc_strength) >> 3;
 }

-static uint32_t mxs_nand_mark_bit_offset(struct mtd_info *mtd)
+uint32_t mxs_nand_mark_bit_offset(struct mtd_info *mtd)
 {
uint32_t ecc_strength;
ecc_strength = mxs_nand_get_ecc_strength(mtd->writesize, mtd->oobsize);

--- /dev/null
+++ b/arch/arm/include/asm/imx-common/mxs_nand.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2015 PHYTEC Messtechnik GmbH,
+ * Author: Stefan Christ 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __NAND_MXS_H
+#define __NAND_MXS_H
+
+/*
+ * Functions are definied in drivers/mtd/nand/nand_mxs.c.  They are used to
+ * calculate the ECC Strength, BadBlockMarkerByte and BadBlockMarkerStartBit
+ * which are placed into the FCB structure. The i.MX6 ROM needs these
+ * parameters to read the firmware from NAND.
+ *
+ * The parameters depends on the pagesize and oobsize of NAND chips and are
+ * different for each combination. To avoid placing hardcoded values in the bbu
+ * update handler code, the generic calculation from the driver code is used.
+ */
+
+uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
+   uint32_t page_oob_size);
+
+uint32_t mxs_nand_mark_byte_offset(struct mtd_info *mtd);
+
+uint32_t mxs_nand_mark_bit_offset(struct mtd_info *mtd);
+
+#endif /* __NAND_MXS_H */

--- /dev/null
+++ b/drivers/mtd/nand/mxs_nand_bootupdate.c
@@ -0,0 +1,556 @@
+/*
+ * mxs_nand_bootupdate.c - write U-Boot to MXS NAND to make it bootable
+ *
+ * Copyright (c) 2016 Sergey Kubushyn <k...@koi8.net>
+ *
+ * Most of the source shamelesly stolen from barebox.
+ *
+ * Here is the original copyright:
+ *
+ *=== Cut ===
+ * Copyright (C) 2014

[U-Boot] [PATCH 1/1]: filesystems : add "file exists" cmd

[Sergey Kubushyn]

This adds "file exists" commands to generic FS as well as to FAT, EXT4,
and UBIFS. Also adds "file size" command to UBIFS.

The return value for "file exists" commands is REVERSED i.e. they
return 1 if file exists and 0 otherwise. This is a deliberate decision
because those commands are supposed to be used almost exclusively in
scripts and TRUE value is _not_ zero while FALSE is zero.

As of now the only way to check for a file existence is to attempt a
read on that file (aka load.) That works but it makes an unnecessary
read, overwrites memory at destination address if file not a zero
length one, and outputs unnecessary messages to the console in any
case.

Checking file existence in scripts is a valuable feature that allows
the higher level software (e.g. Linux) to interact with U-Boot by
creating some semaphore files and rebooting. We do use it quite
extensively for system setup at manufacturing time and for other
purposes (e.g. our Android "recovery" is implemented this way.)

Signed-off-by: Sergey Kubushyn <k...@koi8.net>
---
--- a/include/fs.h
+++ b/include/fs.h
@@ -90,6 +90,8 @@ int do_ls(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
argv[],
int fstype);
 int file_exists(const char *dev_type, const char *dev_part, const char *file,
int fstype);
+int do_file_exists(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[],
+   int fstype);
 int do_save(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[],
int fstype);

--- a/fs/fs.c
+++ b/fs/fs.c
@@ -76,7 +76,7 @@ struct fstype_info {
 * Is it legal to pass NULL as .probe()'s  fs_dev_desc parameter? This
 * should be false in most cases. For "virtual" filesystems which
 * aren't based on a U-Boot block device (e.g. sandbox), this can be
-* set to true. This should also be true for the dumm entry at the end
+* set to true. This should also be true for the dummy entry at the end
 * of fstypes[], since that is essentially a "virtual" (non-existent)
 * filesystem.
 */
@@ -449,6 +449,18 @@ int file_exists(const char *dev_type, const char 
*dev_part, const char *file,
return fs_exists(file);
 }

+int do_file_exists(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[],
+   int fstype)
+{
+   if (argc != 4)
+   return CMD_RET_USAGE;
+
+   if (fs_set_blk_dev(argv[1], argv[2], fstype))
+   return 1;
+
+   return fs_exists(argv[3]);
+}
+
 int do_save(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[],
int fstype)
 {

--- a/cmd/ext4.c
+++ b/cmd/ext4.c
@@ -48,6 +48,18 @@ int do_ext4_size(cmd_tbl_t *cmdtp, int flag, int argc,
return do_size(cmdtp, flag, argc, argv, FS_TYPE_EXT);
 }

+int do_ext4_file_exists(cmd_tbl_t *cmdtp, int flag, int argc,
+   char *const argv[])
+{
+   int ret;
+
+   ret = do_file_exists(cmdtp, flag, argc, argv, FS_TYPE_EXT);
+ 
+	if (ret == 0) return 1;

+   if (ret == 1) return 0;
+   return ret;
+}
+
 int do_ext4_load(cmd_tbl_t *cmdtp, int flag, int argc,
char *const argv[])
 {
@@ -92,3 +104,9 @@ U_BOOT_CMD(ext4load, 7, 0, do_ext4_load,
   " [<dev[:part]> [addr [filename [bytes [pos]\n"
   "- load binary file 'filename' from 'dev' on 'interface'\n"
   "  to address 'addr' from ext4 filesystem");
+
+U_BOOT_CMD(ext4exist,  4,  0,  do_ext4_file_exists,
+   "check if a file exists",
+   " <dev[:part]> \n"
+   "- Check if file 'filename' from 'dev' on 'interface'\n"
+   "  exists and return true/false (for scripting.)");

--- a/cmd/fat.c
+++ b/cmd/fat.c
@@ -19,6 +19,23 @@
 #include 
 #include 

+int do_fat_file_exists(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
argv[])
+{
+   int ret;
+ 
+	ret= do_file_exists(cmdtp, flag, argc, argv, FS_TYPE_FAT);

+
+   if (ret == 0) return 1;
+   if (ret == 1) return 0;
+   return ret;
+}
+
+U_BOOT_CMD(fatexist,   4,  0,  do_fat_file_exists,
+   "check if a file exists",
+   " <dev[:part]> \n"
+   "- Check if file 'filename' from 'dev' on 'interface'\n"
+   "  exists and return true/false (for scripting.)");
+
 int do_fat_size(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
return do_size(cmdtp, flag, argc, argv, FS_TYPE_FAT);

--- a/cmd/ubifs.c
+++ b/cmd/ubifs.c
@@ -98,6 +98,7 @@ static int do_ubifs_ls(cmd_tbl_t *cmdtp, int flag, int argc,
return ret;
 }

+
 static int do_ubifs_load(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
 {
@@ -137,6 +138,45 @@ static int do_ubifs_load(cmd_tbl

Re: [U-Boot] [PATCH] i.MX6 nand bootupdate, reworked

[Sergey Kubushyn]

On Wed, 28 Sep 2016, Jagan Teki wrote:


On Sun, Jun 19, 2016 at 3:14 AM, Sergey Kubushyn <k...@koi8.net> wrote:

Here is yet another version, diff made against latest u-boot-imx master.

Actual code moved from drivers/mtd/nand to /arch/arm/imx-common, some
functions renamed. No other changes.






return CMD_RET_USAGE;
 }
@@ -766,6 +816,17 @@ static char nand_help_text[] =
"'addr', skipping bad blocks and dropping any pages at the
end\n"
"of eraseblocks that contain only 0xFF\n"
 #endif
+#ifdef CONFIG_CMD_NAND_BOOTUPDATE
+   "nand bootupdate - [addr] [size]\n"


What is the addr here the nand offset or the ddr addr? I tried of
doing the same but unable to boot any help?


It is where the actual U-Boot image is loaded in RAM. If "nand bootupdate"
is done right after reading U-Boot binary into RAM (e.g. with ext4load)
those can be both omitted.

As a matter of fact I'm finishing a bunch of changes to U-Boot, including
that bootupdate command and 2 new boards right now and going to submit all
that either tonight or tomorrow.

NAND bootupdate works like a charm here and we do actually use it in actual
production environment with both Linux and Android; firmware updates do
update U-Boot itself as a part of regular network (or OTA how it is called
in Android) updates.

Will try to write a small README file on that if times permitted.

Please note that it has been only tested on i.MX6 (don't have anything else
here; all our boards are i.MX6D/Q/DL.) We do not use SPL.

As of your case I'm not exactly sure what you are trying to achieve. That
entire NAND boot thing with all FCB/DBBT/whatever only applies to INITIAL
boot off of raw NAND device. It allows to boot either the full U-Boot or
SPL using i.MX6 NAND ROM boot routine that reads that FCB and whatever
else then loads actual binary (either U-Boot or SPL or whatever) according
to information in that FCB and runs it.

If you are booting your SPL off of some other media and then trying to load
second stage U-Boot from raw NAND you don't need all that FCB kabang. The
DCB part (if U-Boot is built as i.MX6 image) is also not needed so it can
be stripped or skipped. However your SPL must properly configure NAND
itself so it would be able to read from it and it should include all stuff
required to actually read data from NAND.

The FCB/DBBT stuff is only needed for initial boot off of raw NAND. If you
are going to boot off of NAND and want to have your U-Boot in NAND (that is
the only logical use of NAND for U-Boot) I can not see any reason for going
SPL road but you might have your own reasons that I don't know.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] i.MX6 nand bootupdate, reworked

[Sergey Kubushyn]

On Wed, 28 Sep 2016, Jagan Teki wrote:


On Wed, Sep 28, 2016 at 10:04 PM, Jagan Teki <jagannadh.t...@gmail.com> wrote:

On Sun, Jun 19, 2016 at 3:14 AM, Sergey Kubushyn <k...@koi8.net> wrote:

Here is yet another version, diff made against latest u-boot-imx master.

Actual code moved from drivers/mtd/nand to /arch/arm/imx-common, some
functions renamed. No other changes.






return CMD_RET_USAGE;
 }
@@ -766,6 +816,17 @@ static char nand_help_text[] =
"'addr', skipping bad blocks and dropping any pages at the
end\n"
"of eraseblocks that contain only 0xFF\n"
 #endif
+#ifdef CONFIG_CMD_NAND_BOOTUPDATE
+   "nand bootupdate - [addr] [size]\n"


What is the addr here the nand offset or the ddr addr? I tried of
doing the same but unable to boot any help?

$ dd if=SPL of=SPL-new bs=512 seek=2


Sorry it's work for me w/o seek hope this is doing inside your code, thanks!


Yep, it is taken care of inside nand bootupdate code -- it allows to
just load u-boot.imx image without bothering with offsets or skipping
that leading empty kilobyte yourself.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] A64 fastboot, faster way to compile/test

[Sergey Kubushyn]

On Sun, 14 Aug 2016, jonsm...@gmail.com wrote:


I'm trying out various versions of the A64 u-boot -- Allwinner lichee,
longsleep, apritzel, etc on the Pine64. I can get all of them up to
the prompt, but fastboot doesn't work in an of them. There is code
from Allwinner in there for implementing fastboot, but so far I've had
no luck getting it to do anything. I added a bunch of debug and the
USB controller does not appear to be generating interrupts.

Has anyone worked with A64 fastboot? Any tips on what might be wrong?

I want a faster was to update the SD Card without physically moving it
between machines.


Use ums. Works like a charm. As of fastboot it is Android weirdo and its
support in U-Boot is rudimentary. Dunno why it is in the source tree at
all -- if it was me I would've removed it altogether...

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] i.MX6 nand bootupdate, reworked

[Sergey Kubushyn]

Here is yet another version, diff made against latest u-boot-imx master.

Actual code moved from drivers/mtd/nand to /arch/arm/imx-common, some
functions renamed. No other changes.

Signed-off-by: Sergey Kubushyn <k...@koi8.net>
---
 arch/arm/imx-common/Makefile   |   3 +
 arch/arm/imx-common/cmd_nand_bootupdate.c  | 556 +
 arch/arm/include/asm/imx-common/mxs_nand.h |  37 ++
 cmd/nand.c |  61 
 drivers/mtd/nand/mxs_nand.c|   7 +-
 5 files changed, 661 insertions(+), 3 deletions(-)

diff --git a/arch/arm/imx-common/Makefile b/arch/arm/imx-common/Makefile
index d34a784..b77c231 100644
--- a/arch/arm/imx-common/Makefile
+++ b/arch/arm/imx-common/Makefile
@@ -34,6 +34,9 @@ endif
 ifeq ($(SOC),$(filter $(SOC),vf610))
 obj-y += ddrmc-vf610.o
 endif
+ifeq ($(SOC),$(filter $(SOC),mx6))
+obj-$(CONFIG_CMD_NAND_BOOTUPDATE) += cmd_nand_bootupdate.o
+endif
 obj-$(CONFIG_CMD_BMODE) += cmd_bmode.o
 obj-$(CONFIG_CMD_HDMIDETECT) += cmd_hdmidet.o
 obj-$(CONFIG_CMD_DEKBLOB) += cmd_dek.o
diff --git a/arch/arm/imx-common/cmd_nand_bootupdate.c 
b/arch/arm/imx-common/cmd_nand_bootupdate.c
new file mode 100644
index 000..1dcb637
--- /dev/null
+++ b/arch/arm/imx-common/cmd_nand_bootupdate.c
@@ -0,0 +1,556 @@
+/*
+ * cmd_nand_bootupdate.c - write U-Boot to MXS NAND to make it bootable
+ *
+ * Copyright (c) 2016 Sergey Kubushyn <k...@koi8.net>
+ *
+ * Most of the source shamelesly stolen from barebox.
+ *
+ * Here is the original copyright:
+ *
+ *=== Cut ===
+ * Copyright (C) 2014 Sascha Hauer, Pengutronix
+ *=== Cut ===
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+#ifndef CONFIG_CMD_MTDPARTS
+#error "CONFIG_CMD_MTDPARTS is not set, mtd partition support missing"
+#endif
+
+static const char *uboot_tgt = "nand0,0";
+
+/* partition handling routines */
+int mtdparts_init(void);
+int id_parse(const char *id, const char **ret_id, u8 *dev_type, u8 *dev_num);
+int find_dev_and_part(const char *id, struct mtd_device **dev,
+ u8 *part_num, struct part_info **part);
+
+struct dbbt_block {
+   uint32_t Checksum;  /* reserved on i.MX6 */
+   uint32_t FingerPrint;
+   uint32_t Version;
+   uint32_t numberBB;  /* reserved on i.MX6 */
+   uint32_t DBBTNumOfPages;
+};
+
+struct fcb_block {
+   uint32_t Checksum;  /* First fingerprint in first byte */
+   uint32_t FingerPrint;   /* 2nd fingerprint at byte 4 */
+   uint32_t Version;   /* 3rd fingerprint at byte 8 */
+   uint8_t DataSetup;
+   uint8_t DataHold;
+   uint8_t AddressSetup;
+   uint8_t DSAMPLE_TIME;
+   /* These are for application use only and not for ROM. */
+   uint8_t NandTimingState;
+   uint8_t REA;
+   uint8_t RLOH;
+   uint8_t RHOH;
+   uint32_t PageDataSize;  /* 2048 for 2K pages, 4096 for 4K pages 
*/
+   uint32_t TotalPageSize; /* 2112 for 2K pages, 4314 for 4K pages 
*/
+   uint32_t SectorsPerBlock;   /* Number of 2K sections per block */
+   uint32_t NumberOfNANDs; /* Total Number of NANDs - not used by 
ROM */
+   uint32_t TotalInternalDie;  /* Number of separate chips in this 
NAND */
+   uint32_t CellType;  /* MLC or SLC */
+   uint32_t EccBlockNEccType;  /* Type of ECC, can be one of BCH-0-20 
*/
+   uint32_t EccBlock0Size; /* Number of bytes for Block0 - BCH */
+   uint32_t EccBlockNSize; /* Block size in bytes for all blocks 
other than Block0 - BCH */
+   uint32_t EccBlock0EccType;  /* Ecc level for Block 0 - BCH */
+   uint32_t MetadataBytes; /* Metadata size - BCH */
+   uint32_t NumEccBlocksPerPage;   /* Number of blocks per page for ROM 
use - BCH */
+   uint32_t EccBlockNEccLevelSDK;  /* Type of ECC, can be one of BCH-0-20 
*/
+   uint32_t EccBlock0SizeSDK;  /* Number of bytes for Block0 - BCH */
+   uint32_t EccBlockNSizeSDK;  /* Block size in bytes for all blocks 
other than Block0 - BCH */
+   uint32_t EccBlock0EccLevelSDK;  /* Ecc level for Block 0 - BCH */
+   uint32_t NumEccBlocksPerPageSDK;/* Number of blocks per page for SDK 
use - BCH */
+   uint32_t MetadataBytesSDK;  /* Metadata size - BCH */
+   uint32_t EraseThreshold;/* To set into BCH_MODE register */
+   uint32_t BootPatch; /* 0 for normal boot and 1 to load 
patch starting next to FCB */
+   uint32_t PatchSectors;  /* Size of patch in sectors */
+   uint32_t Firmware1_startingPage;/* Firmware image starts on this sector 
*/
+   uint32_t Firmware2_startingPage;/* Secondary FW Image starting Sector */
+   uint32_t PagesInFirmware1;  /* Number of sectors in fir

[U-Boot] [PATCH] Initial NAND U-Boot update for i.MX6 SOCs

[Sergey Kubushyn]

Here is that patch again. Rebased, multiline comments fixed, some
whitespace trimmed. One header file with non-SPDX license is not
changed because the entire file has been stolen verbatim with no
changes at all. No other changes so far... This is against today's
git tree.

Signed-off-by: Sergey Kubushyn <k...@koi8.net>
---
 arch/arm/include/asm/imx-common/mxs_nand.h |  37 ++
 cmd/nand.c |  61 
 drivers/mtd/nand/Makefile  |   1 +
 drivers/mtd/nand/mxs_nand.c|   7 +-
 drivers/mtd/nand/mxs_nand_bootupdate.c | 556 +
 5 files changed, 659 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/imx-common/mxs_nand.h 
b/arch/arm/include/asm/imx-common/mxs_nand.h
new file mode 100644
index 000..7826a9f
--- /dev/null
+++ b/arch/arm/include/asm/imx-common/mxs_nand.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2015 PHYTEC Messtechnik GmbH,
+ * Author: Stefan Christ 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __NAND_MXS_H
+#define __NAND_MXS_H
+
+/*
+ * Functions are definied in drivers/mtd/nand/nand_mxs.c.  They are used to
+ * calculate the ECC Strength, BadBlockMarkerByte and BadBlockMarkerStartBit
+ * which are placed into the FCB structure. The i.MX6 ROM needs these
+ * parameters to read the firmware from NAND.
+ *
+ * The parameters depends on the pagesize and oobsize of NAND chips and are
+ * different for each combination. To avoid placing hardcoded values in the bbu
+ * update handler code, the generic calculation from the driver code is used.
+ */
+
+uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
+   uint32_t page_oob_size);
+
+uint32_t mxs_nand_mark_byte_offset(struct mtd_info *mtd);
+
+uint32_t mxs_nand_mark_bit_offset(struct mtd_info *mtd);
+
+#endif /* __NAND_MXS_H */
diff --git a/cmd/nand.c b/cmd/nand.c
index 583a18f..b932ce2 100644
--- a/cmd/nand.c
+++ b/cmd/nand.c
@@ -38,6 +38,11 @@ int find_dev_and_part(const char *id, struct mtd_device 
**dev,
  u8 *part_num, struct part_info **part);
 #endif

+#ifdef CONFIG_CMD_NAND_BOOTUPDATE
+/* This comes from a separate file in drivers/mtd/nand */
+int mxs_do_nand_bootupdate(ulong addr, size_t len);
+#endif
+
 static int nand_dump(struct mtd_info *mtd, ulong off, int only_oob,
 int repeat)
 {
@@ -373,6 +378,9 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
loff_t off, size, maxsize;
char *cmd, *s;
struct mtd_info *mtd;
+#ifdef CONFIG_CMD_NAND_BOOTUPDATE
+   size_t cnt;
+#endif
 #ifdef CONFIG_SYS_NAND_QUIET
int quiet = CONFIG_SYS_NAND_QUIET;
 #else
@@ -745,6 +753,48 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
}
 #endif

+#ifdef CONFIG_CMD_NAND_BOOTUPDATE
+   if (strncmp(cmd, "bootupdate", 10) == 0) {
+
+   if (argc < 3) {
+   /* All default values */
+   addr = getenv_ulong("fileaddr", 16, 0UL);
+   cnt = getenv_ulong("filesize", 16, 0UL);
+   }
+
+   if (argc == 3) {
+   /* 'addr' only, file size from environment */
+   if ((addr = simple_strtoul(argv[2], NULL, 16)) == 0UL)
+   addr = getenv_ulong("fileaddr", 16, 0UL);
+
+   cnt = getenv_ulong("filesize", 16, 0UL);
+   }
+
+   if (argc > 3) {
+   /* 'addr', 'size', and possibly more */
+   if ((addr = simple_strtoul(argv[2], NULL, 16)) == 0UL)
+   addr = getenv_ulong("fileaddr", 16, 0UL);
+
+   if ((cnt = simple_strtoul(argv[3], NULL, 16)) == 0UL)
+   cnt = getenv_ulong("filesize", 16, 0UL);
+   }
+
+
+   if (addr == 0 || cnt == 0) {
+   puts("Invalid arguments to nand bootupdate!\n");
+   return 1;
+   }
+
+   if (mxs_do_nand_bootupdate(addr, cnt)) {
+   puts("NAND bootupdate failed!\n");
+   return 1;
+   }
+
+   puts("NAND bootupdate successful\n");
+   return 0;
+   }
+#endif
+
 usage:
return CMD_RET_USAGE;

Re: [U-Boot] [PATCH] i.MX6 nand bootupdate

[Sergey Kubushyn]

On Wed, 15 Jun 2016, Stefano Babic wrote:

Hi,


Hi Sergey,


On 14/06/2016 20:32, Sergey Kubushyn wrote:

Here is the initial support for writing i.MX6 NAND U-Boot into NAND
with all FCB and DBBT stuff as required.



This is a very interesting feature missing in U-Boot. Up now we are
constrained to update the bootloader from user space with kobs-ng, and
this is really an improvement. Thanks for that.

Anyway, as remarked by Peng, please rebase your patch on current tree,
else we cannot test it.


I will when time permits, probably tomorrow. Now let's go over other
stuff...


Just build U-Boot for NAND as u-boot.imx, load it somehow in RAM and
say "nand bootupdate [addr] [size]". It will create all necessary
structures and write everything as needed.


The whole phrase is misleading here. I guess this is the way you have to
put on your board, it is not a general case.


The very (and only) purpose for this function is to put U-Boot with
proper FCB/DBBT header on one's board so i.MX6 bootrom would be able to
boot off of it. There is _NO_ general case. One can _NOT_ change the way
i.MX6 (or whatever) boots up, it is in the ROM and it always reads FCB
starting from sector 0 of NAND 0. BTW, if your particular NAND chip is
not supported by that ROM you are out of luck -- it won't boot off of
that chip.

Once again -- it is _NOT_ my board, it is how the i.MX6 boot code works.


I am expecting to have some parameters like in kobs-ng: I set the number
of copies with --search_exponent, how is it done here ?


It makes no sense for limited purpose U-Boot command. You need at least
2 copies of FCB/DBBT. That kobs-ng puts FCB and corresponding DBBT in 2
consecutive erase blocks (sectors) thus taking 2 sectors per FCB/DBBT
instance. I put DBBT in the same sector with FCB (exactly like BareBox
does) so I can squeeze 4 copies in the same 4 sectors kobs-ng takes for
2 copies.

Then, it is a _LIMITED_ use command so it makes no sense to do something
with a long command line and its parsing code. If somebody needs more
complex/sophisticated utility he can just put U-Boot with this simple
command, boot into their favority OS and use a utility whatever complex
or big he wants.

That is what U-Boot is about. I do also miss the mkfs.ext4 or fsck or
even just an option to delete or rename a file on ext4 but I do
understand it is not all that easy and make workarounds to live with
what I have.


No SPL required, just plain single stage U-Boot.


Why ? This has nothing to do. We could write SPL into the NAND as first
bootloader, and SPL will load the u-boot.img unabhängig von FCB.


"No SPL required" means exactly that :) It does _NOT_ mean "No SPL is
possible" -- as a matter of fact neither that added command nor i.MX6
bootrom even care what that binary payload is. As long as FCB is valid
and that binary has a proper header nobody cares what it is -- it is
simply loaded and ran.


Supposed to write into
first NAND partition, recommended size 4MiB.


Where is this size coming ? This depends on the number of copies (can we
have configurable as for kobs-ng ?) and the size of U-Boot. If we write
SPL, we need less.


It needs at least 4 sectors for 4 copies of FCB/DBBT (this is 2 copies
in kbs-ng, nbare minimum) and at least 2 sectors for each copy of the
actual binary if the latter fits in one sector (minimal guarantee we can
write it if one of the 2 sectors is bad.) In real life you need some
more for NAND. Minimum/standard sector is 128K so you need at least 1MiB
for a binary that fits in 128KiB (for bootrom you also need leading 1KiB
padding and one trailing empty page so binary must fit in 125KiB.)

If the SPL is that small, yes, one can save some space so SPL partition
can be smaller. However possible 3MiB saving on a NAND chip seem hardly
worth a bother. I can make 2 commands instead of one, say ubootupdate
and splupdate but that is hardly worth a bother. What if one wanted to
put a non-SPL U-Boot on his NAND later once it's been partitioned for
SPL (more on partition later, see below)?


Supposed to write into mtd0 works in most cases, yes. But it should be
better let it configurable as in kobs-ng.


And the reason to do it is...? What are you going to do with a copy on
mtd other than 0? Remember, it is not us who decide where to boot from,
it is i.MX6 bootrom. It can NOT boot off of anything but nand0. And
remember, that FCB page is not even readable with regular mtd read -- it
will fail ECC...

The only use case I could imagine would be 2 redundant NANDs with their
CS lines swapped as needed by jumpers or whatever for recovery/dualboot
purposes but you can use that very switching mechanism when writing
U-Boot into that combination...


One reason is to show the user an easy path from kobs-ng to u-boot - and
of course, how to change from kobs-ng to this command should be
explained into the README.


There is no path at all. And nothing can be easier than just issue one
command -- there a

[U-Boot] [PATCH] i.MX6 nand bootupdate

[Sergey Kubushyn]

Here is the initial support for writing i.MX6 NAND U-Boot into NAND
with all FCB and DBBT stuff as required.

Just build U-Boot for NAND as u-boot.imx, load it somehow in RAM and
say "nand bootupdate [addr] [size]". It will create all necessary
structures and write everything as needed.

No SPL required, just plain single stage U-Boot. Supposed to write into
first NAND partition, recommended size 4MiB. Creates 4 redundant copies
of boot structures in first 4 sectors and 2 redundant copies of U-Boot
in the remaining space.

Tested on a Variscite VAR-SOM-SOLO based board with i.MX6DL SoC. Will
probably post that board support files later, when config is cleaned up
so people could have a working NAND boot DCD portion to be able actually
use those braindead SOMs.

Signed-off-by: Sergey Kubushyn <k...@koi8.net>
---
diff --git a/arch/arm/include/asm/imx-common/mxs_nand.h 
b/arch/arm/include/asm/imx-common/mxs_nand.h
new file mode 100644
index 000..7826a9f
--- /dev/null
+++ b/arch/arm/include/asm/imx-common/mxs_nand.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2015 PHYTEC Messtechnik GmbH,
+ * Author: Stefan Christ 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __NAND_MXS_H
+#define __NAND_MXS_H
+
+/*
+ * Functions are definied in drivers/mtd/nand/nand_mxs.c.  They are used to
+ * calculate the ECC Strength, BadBlockMarkerByte and BadBlockMarkerStartBit
+ * which are placed into the FCB structure. The i.MX6 ROM needs these
+ * parameters to read the firmware from NAND.
+ *
+ * The parameters depends on the pagesize and oobsize of NAND chips and are
+ * different for each combination. To avoid placing hardcoded values in the bbu
+ * update handler code, the generic calculation from the driver code is used.
+ */
+
+uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
+   uint32_t page_oob_size);
+
+uint32_t mxs_nand_mark_byte_offset(struct mtd_info *mtd);
+
+uint32_t mxs_nand_mark_bit_offset(struct mtd_info *mtd);
+
+#endif /* __NAND_MXS_H */
diff --git a/cmd/nand.c b/cmd/nand.c
index 583a18f..12e38e1 100644
--- a/cmd/nand.c
+++ b/cmd/nand.c
@@ -38,6 +38,11 @@ int find_dev_and_part(const char *id, struct mtd_device 
**dev,
  u8 *part_num, struct part_info **part);
 #endif

+#ifdef CONFIG_CMD_NAND_BOOTUPDATE
+/* This comes from a separate file in drivers/mtd/nand */
+int mxs_do_nand_bootupdate(ulong addr, size_t len);
+#endif
+
 static int nand_dump(struct mtd_info *mtd, ulong off, int only_oob,
 int repeat)
 {
@@ -373,6 +378,9 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
loff_t off, size, maxsize;
char *cmd, *s;
struct mtd_info *mtd;
+#ifdef CONFIG_CMD_NAND_BOOTUPDATE
+   size_t cnt;
+#endif
 #ifdef CONFIG_SYS_NAND_QUIET
int quiet = CONFIG_SYS_NAND_QUIET;
 #else
@@ -745,6 +753,48 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
}
 #endif

+#ifdef CONFIG_CMD_NAND_BOOTUPDATE
+   if (strncmp(cmd, "bootupdate", 10) == 0) {
+
+   if (argc < 3) {
+   /* All default values */
+   addr = getenv_ulong("fileaddr", 16, 0UL);
+   cnt = getenv_ulong("filesize", 16, 0UL);
+   }
+
+   if (argc == 3) {
+   /* 'addr' only, file size from environment */
+   if ((addr = simple_strtoul(argv[2], NULL, 16)) == 0UL)
+   addr = getenv_ulong("fileaddr", 16, 0UL);
+
+   cnt = getenv_ulong("filesize", 16, 0UL);
+   }
+
+   if (argc > 3) {
+   /* 'addr', 'size', and possibly more */
+   if ((addr = simple_strtoul(argv[2], NULL, 16)) == 0UL)
+   addr = getenv_ulong("fileaddr", 16, 0UL);
+
+   if ((cnt = simple_strtoul(argv[3], NULL, 16)) == 0UL)
+   cnt = getenv_ulong("filesize", 16, 0UL);
+   }
+
+
+   if (addr == 0 || cnt == 0) {
+   puts("Invalid arguments to nand bootupdate!\n");
+   return 1;
+   }
+ 
+		if (mxs_do_nand_bootupdate(addr, cnt)) {

+   puts("NAND bootupdate failed!\n");
+   return 1;
+ 

[U-Boot] BOOT_DELAY broken

[Sergey Kubushyn]

OK, it is broken in last commit. Totally broken.

I can NOT get my custom board to stop at all. "CONFIG_BOOTDELAY=3" added
to my board defconfig doesn't change anything. Even changing default to
3 from 0 in common/Kconfig doesn't help.

Putting "CONFIG_BOOTDELAY 3" in my board config in /include/configs
makes gcc to output a whole lot of warning that it is redefined but it
_DOES_ work.

I do NOT have time chasing this -- I'm in firefighting mode now with 14
hours workdays because of this Tuesday deadline -- but guys, WTF!?

I could understand somebody submitting such a stupid patch affecting
_HUNDREDS_ of boards without thinking of consequences but why had it
been accepted and applied to uboot-master right away? There are other
things that are broken and won't compile but trivial one-line patches
fixing that breakage are silently ignored but such a enormous screwup
leaving holes all over is accepted right away without any checking...

Please do _NOT_ make such things any more. And if you do care please
take my vehement NACK to this entire thing. I suggest it would be better
to rollback that patch in its entirety -- there is too much work to fix
the damage and there is absolutely no reason for this change at all in
the first place.

Sorry for ranting but I simply could not stand it...

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] HUSH_PARSER...

[Sergey Kubushyn]

I wonder is there any clarity wrt CONFIG_HUSH_PARSER vs
CONFIG_SYS_HUSH_PARSER?

That stupid definition seems to be constantly oscillating between those
two definitions from release to release so one is left with missing
scripting every time new version is released...

I'm putting both definition in my configs from now on but guys, is it
somehow possible to decide on either one and use it consistently from
that point on? It is so frustrating to waste time guessing which way it
is set up today :(

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/1] common: fb_nand: won't compile

[Sergey Kubushyn]

Somehow this got overlooked when getting rid of nand_info.

Small patch, won't affect anything else, no reason to wait for the
next cycle.

Signed-off-by: Sergey Kubushyn <k...@koi8.net>
---
diff --git a/common/fb_nand.c b/common/fb_nand.c
index e55ea38..ae34f48 100644
--- a/common/fb_nand.c
+++ b/common/fb_nand.c
@@ -34,7 +34,7 @@ __weak int board_fastboot_write_partition_setup(char *name)
 }

 static int fb_nand_lookup(const char *partname, char *response,
- struct mtd_info **nand,
+ struct mtd_info **mtd,
  struct part_info **part)
 {
struct mtd_device *dev;


---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/1] cmd: bootefi: cosmetic

[Sergey Kubushyn]

Short help (description) in bootefi command has a trailing "\n" that
breaks the "help" command output (empty line after "bootefi").

Nothing important, doesn't affect anything but better be fixed in the
upcoming release.

Still working on i.MX6 and their siblings NAND U-Boot update -- it
works here but not ready for a submission yet. Anyway it is for the
next cycle, not going to go into this release because it is too big
and may affect something else.

Also have some thoughts about fastboot (using multiple devices) but
this will go into separate email with RFC.

Signed-off-by: Sergey Kubushyn <k...@koi8.net>
---
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 2169065..011f62c 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -255,7 +255,7 @@ static char bootefi_help_text[] =

 U_BOOT_CMD(
bootefi, 3, 0, do_bootefi,
-   "Boots an EFI payload from memory\n",
+   "Boots an EFI payload from memory",
bootefi_help_text
 );



---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/5] Update fastboot sparse image handling

[Sergey Kubushyn]

On Tue, 7 Jun 2016, Steve Rae wrote:

Quick question before diving in -- does anybody work on making
fastboot able to flash multiple devices?

There are some braindead designs (e.g. Variscite SOMs) that have both
eMMC and NAND on board and only able to boot off of NAND. Android
FS layout uses insane number of partitions so it would be logical to
put some of those onto NAND while keeping others on eMMC. However at
present time the target device for "flash" command is a compile-time
option that only allows writing to one device.

Is anybody working on this currently? I don't want to re-invent the
wheel. I will come up with initial RFC if nobody work on this...


While retaining the storage abstraction feature implemented in U-Boot,
this series updates the fastboot sparse image handling by
(1) fixing broken code,
(2) resync'ing with the upstream code, and
(3) improving performance when writing CHUNK_TYPE_FILL

Changes in v2:
- series rebased onto v2016.07-rc1

Steve Rae (5):
 fastboot: sparse: remove session-id logic
 fastboot: sparse: resync common/image-sparse.c (part 1)
 fastboot: sparse: resync common/image-sparse.c (part 2)
 fastboot: sparse: implement reserve()
 fastboot: sparse: improve CHUNK_TYPE_FILL write performance

common/fb_mmc.c |  79 +++
common/fb_nand.c| 106 +
common/image-sparse.c   | 478 +++-
drivers/usb/gadget/f_fastboot.c |  47 ++--
include/fastboot.h  |   4 +-
include/fb_mmc.h|   7 +-
include/fb_nand.h   |   7 +-
include/image-sparse.h  |  29 ++-
8 files changed, 312 insertions(+), 445 deletions(-)

--
1.8.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot



---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem of git clone with http

[Sergey Kubushyn]

On Wed, 27 Apr 2016, Wolfgang Denk wrote:


Dear Andreas,

In message <20160427144315.gh2...@borg.dal.design.ti.com> you wrote:



But i can't pull and fetch anything with http..

...

I was just banging my head not being able to fetch the latest U-Boot
stuff, running into the same issue, and successfully worked around it by
using the git:// URL. However it wasn't until I wanted to post about
this on this mailing list that I found this thread :)

Anyways it seems like this issue already persists for one month without
a fix. For folks behind draconian corporate firewalls the http:// URLs
are often easier to use, so this is a bit of a trap


Agreed.  But the first step of getting something fixed is to report it
to the responsible admins, or here on the list.  I never use HTTP
myself to access the repository, as git protocol is so much more
efficient.  So unless somebody shouts about it, I will never notice
any such problems.

I've tweaked things a bit - can you please give it another try?  If
you still see problems (either now or later) please make sure to
report them to me, and I will make sure someone looks into it.


This seems to be a widespread thing. It is definitely caused by buggy Cisco
firewalls corrupting binary files. I had the same problem in corporate
environment (where I have my day job right now) 100% traced to their proxy
servers. All traffic is going through some Cisco proxies (don't know what
devices/software it is) and it was impossible to clone a git repo because
data was corrupted when going through those buggy things.

In my case, as I'm more like a principal engineer here, corporate IT made a
hole for my development machines so they go to the Net directly. That solved
the issue.

Before that cloning always failed when uncompressing objects. That also
applied to _ANY_ compressed files downloaded from the Net if those were
big enough. Smaller files were OK and small git repos didn't have any
problems but when they were bigger than some threshold all such files
arrived corrupted.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] imx6 devices failing to build with 2016.05

[Sergey Kubushyn]

On Wed, 27 Apr 2016, Stefano Babic wrote:

Guys, it looks like it is already time to finally get that series of ARM lib
patches in. This will occur again and again until it is done.

Face the reality -- not everybody uses a special softfloat toolchain just
for building U-Boot. And it is simply pathetic to expect this when there is
well proven solution which is in Linux kernel since the dawn of times.

Get those patches in please.


Hi Peter,

On 27/04/2016 12:15, Peter Robinson wrote:

Hi All,

I didn't look closely when it happened with rc1 because I saw a pull
req from Stefano shortly afterwards and I decided to try again after
that landed. With rc3 I'm still seeing the same issue.

Basically all the i.MX6 devices
(cm_fx6,mx6cuboxi,novena,riotboard,udoo,wandboard,warp) we currently
build for Fedora are failing to build. It looks very similar to some
64 bit math issues [1] [2] a search gives me although from the linker
command I'm failing to see what code is at fault so any assistance in
debugging this would be great. I've checked it failed on < gcc6 too
and 2016.03 builds so it appears a regression in 05rcX.

The (for cuboxi example) basic error is:
  ld.bfd   -pie  --gc-sections -Bstatic -Ttext 0x1780 -o u-boot -T
u-boot.lds arch/arm/cpu/armv7/start.o --start-group
arch/arm/cpu/built-in.o  arch/arm/cpu/armv7/built-in.o
arch/arm/imx-common/built-in.o  arch/arm/lib/built-in.o
board/solidrun/mx6cuboxi/built-in.o  cmd/built-in.o  common/built-in.o
 disk/built-in.o  drivers/built-in.o  drivers/dma/built-in.o
drivers/gpio/built-in.o  drivers/i2c/built-in.o
drivers/mmc/built-in.o  drivers/mtd/built-in.o
drivers/mtd/onenand/built-in.o  drivers/mtd/spi/built-in.o
drivers/net/built-in.o  drivers/net/phy/built-in.o
drivers/pci/built-in.o  drivers/power/built-in.o
drivers/power/battery/built-in.o  drivers/power/fuel_gauge/built-in.o
drivers/power/mfd/built-in.o  drivers/power/pmic/built-in.o
drivers/power/regulator/built-in.o  drivers/serial/built-in.o
drivers/spi/built-in.o  drivers/usb/common/built-in.o
drivers/usb/dwc3/built-in.o  drivers/usb/emul/built-in.o
drivers/usb/eth/built-in.o  drivers/usb/gadget/built-in.o
drivers/usb/gadget/udc/built-in.o  drivers/usb/host/built-in.o
drivers/usb/musb-new/built-in.o  drivers/usb/musb/built-in.o
drivers/usb/phy/built-in.o  drivers/usb/ulpi/built-in.o  fs/built-in.o
 lib/built-in.o  net/built-in.o  test/built-in.o  test/dm/built-in.o
--end-group arch/arm/lib/eabi_compat.o  -L
/usr/lib/gcc/armv7hl-redhat-linux-gnueabi/6.0.0 -lgcc -Map u-boot.map
ld.bfd: error: 
/usr/lib/gcc/armv7hl-redhat-linux-gnueabi/6.0.0/libgcc.a(_udivmoddi4.o)
uses VFP register arguments, u-boot does not
ld.bfd: failed to merge target specific data of file
/usr/lib/gcc/armv7hl-redhat-linux-gnueabi/6.0.0/libgcc.a(_udivmoddi4.o)

Full log at https://pbrobinson.fedorapeople.org/u-boot-mx6cuboxi-fail.txt



I can confirm this - I started bisect and I have found this one:

commit 3cb4f25cc702db17455583599d0940c81337a17a
Author: Peng Fan 
Date:   Wed Mar 9 16:07:21 2016 +0800

   video: ipu: avoid overflow issue

   Multiplication, as "clk->parent->rate * 16" may overflow. So use
   do_div to avoid such issue.

   Signed-off-by: Peng Fan 
   Signed-off-by: Sandor Yu 
   Cc: Anatolij Gustschin 
   Cc: Stefano Babic 
   Cc: Fabio Estevam 

:04 04 9672cb921a1051b5357931e8835884e2cccf8ec6
3cbbeea448780bb4855f5458dd98d017239b729a M  drivers


Checking the patch, I have found:

clk->rate = (u64)(clk->parent->rate * 16) / div;


This seems the cause for the failing build.

This confirms an issue. IMHO we can replace it with:

clk->rate = (u64)lldiv(clk->parent->rate * 16, div);

Peng, what do you mind ?

Best regards,
Stefano Babic

--
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot



---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] RFC: i.MX6 write U-Boot to NAND

[Sergey Kubushyn]

On Tue, 26 Apr 2016, Stefan Roese wrote:

OK, if nobody worked on this so far I'll bite the bullet -- working on a
NAND boot only i.mx6 module right now at my day job and need manufacturing
tools for production. Just didn't want to re-invent the wheel and mess with
somebody's else work...

Will try to submit a patch by the end of week if nothing come into the way.


Hi Sergey, Hi Heiko,

On 26.04.2016 07:43, Heiko Schocher wrote:

 add Stefano to Cc as he is the imx6 custodian,

 Am 25.04.2016 um 22:29 schrieb Sergey Kubushyn:
>  Hi everybody,
> 
>  It looks like using kobs-ng utility is the only way to make a bootable

>  NAND
>  for i.MX6 and their siblings. There might be other utilities I'm not
>  aware
>  of but that doesn't change anything -- you need Linux (or whatever that
>  utility runs on) running on your board to create and write all those
>  FCB and
>  other parts onto a virgin raw NAND device.

 Yes, I stumbled over that too recently ...

>  This makes initial programming a cumbersome and complicated operation.
>  One
>  can not program NAND on a development machine as it is easy to do with
>  e.g.
>  SD Card -- the OS must run on the same board where that NAND is
>  because NAND
>  is not removable.
> 
>  It is possible, of course, to assemble something on an SD Card and use

>  that
>  to program NAND but that assumes there is an SD Card slot on a target
>  system
>  and some means to tell it to boot off of SD Card. However it is not
>  always a
>  case -- there might be boards with NAND as only storage device 
>  available.

>  That leaves only Serial/USB boot as only options for initial boot on a
>  virgin board. However it does not provide means for writing the NAND
>  U-Boot
>  into actual NAND.
> 
>  There are many different varieties of NAND chips so those FCB and other

>  structures are not generic i.e. they can not be defined beforehead and
>  just
>  prepended to the actual U-Boot image. Even if we have made those a
>  configuration parameters there are still bad block tables that are chip
>  specific so they should be discovered first i.e. FCB should be built
>  dynamically based on NAND scanning results.
> 
>  Sure, one can write a custom first stage SPL that would've booted the

>  actual
>  U-Boot via the same Serial/USB interface and run it but then what? Let's
>  assume the target board doesn't have ethernet so it would make it
>  impossible
>  to mount rootfs over NFS and no other storage devices available. It is
>  still
>  possible to load Linux kernel and bare minimal rootfs in initramfs
>  image but
>  that's a lot of serial downloading just for initializing NAND...
> 
>  It would be nice to have a U-Boot command that would've allowed

>  initial NAND
>  setup and writing NAND U-Boot image to it properly updating the headers.

 Yes, that would be great!

>  There might be other ways to do this that I might've overlooked...
> 
>  Does anybody knows a ready-made solution or works on something

>  suitable for
>  this purpose? I don't want to re-invent the wheel starting my own
>  solution
>  so it would've been good to hear from other guys who might've solved 
>  this

>  dilemma.

 Sorry, I do not know another way.

>  Any thoughts?

 I think, an U-Boot command which writes the headers into the nand would
 be a good thing.

 tools/imximage.c is may the wrong place, as the infos in FCB and DBBT
 are dependend on the boards nand.


I've missed such a tool a few years ago while porting U-Boot & Linux
to a i.MX6 based NAND booting board as well. And noticed since then
that barebox has included such a tool:

http://lists.infradead.org/pipermail/barebox/2014-March/018202.html

Perhaps its not too much work to port this tool over to U-Boot?
Just an idea...

Thanks,
Stefan




---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] RFC: i.MX6 write U-Boot to NAND

[Sergey Kubushyn]

Hi everybody,

It looks like using kobs-ng utility is the only way to make a bootable NAND
for i.MX6 and their siblings. There might be other utilities I'm not aware
of but that doesn't change anything -- you need Linux (or whatever that
utility runs on) running on your board to create and write all those FCB and
other parts onto a virgin raw NAND device.

This makes initial programming a cumbersome and complicated operation. One
can not program NAND on a development machine as it is easy to do with e.g.
SD Card -- the OS must run on the same board where that NAND is because NAND
is not removable.

It is possible, of course, to assemble something on an SD Card and use that
to program NAND but that assumes there is an SD Card slot on a target system
and some means to tell it to boot off of SD Card. However it is not always a
case -- there might be boards with NAND as only storage device available.
That leaves only Serial/USB boot as only options for initial boot on a
virgin board. However it does not provide means for writing the NAND U-Boot
into actual NAND.

There are many different varieties of NAND chips so those FCB and other
structures are not generic i.e. they can not be defined beforehead and just
prepended to the actual U-Boot image. Even if we have made those a
configuration parameters there are still bad block tables that are chip
specific so they should be discovered first i.e. FCB should be built
dynamically based on NAND scanning results.

Sure, one can write a custom first stage SPL that would've booted the actual
U-Boot via the same Serial/USB interface and run it but then what? Let's
assume the target board doesn't have ethernet so it would make it impossible
to mount rootfs over NFS and no other storage devices available. It is still
possible to load Linux kernel and bare minimal rootfs in initramfs image but
that's a lot of serial downloading just for initializing NAND...

It would be nice to have a U-Boot command that would've allowed initial NAND
setup and writing NAND U-Boot image to it properly updating the headers.

There might be other ways to do this that I might've overlooked...

Does anybody knows a ready-made solution or works on something suitable for
this purpose? I don't want to re-invent the wheel starting my own solution
so it would've been good to hear from other guys who might've solved this
dilemma.

Any thoughts?

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Sergey Kubushyn]

On Thu, 24 Mar 2016, Tom Rini wrote:


On Thu, Mar 24, 2016 at 08:50:03AM +0100, Albert ARIBAUD wrote:

Hello Tom,

On Wed, 23 Mar 2016 17:36:17 -0400, Tom Rini  wrote:

On Wed, Mar 23, 2016 at 06:08:45PM +0100, Albert ARIBAUD wrote:

Hello Tom,

On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini  wrote:

On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:

Hello Marek,

On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut  wrote:

This patch decouples U-Boot binary from the toolchain on systems where
private libgcc is available. Instead of pulling in functions provided
by the libgcc from the toolchain, U-Boot will use it's own set of libgcc
functions. These functions are usually imported from Linux kernel, which
also uses it's own libgcc functions instead of the ones provided by the
toolchain.

This patch solves a rather common problem. The toolchain can usually
generate code for many variants of target architecture and often even
different endianness. The libgcc on the other hand is usually compiled
for one particular configuration and the functions provided by it may
or may not be suited for use in U-Boot. This can manifest in two ways,
either the U-Boot fails to compile altogether and linker will complain
or, in the much worse case, the resulting U-Boot will build, but will
misbehave in very subtle and hard to debug ways.


I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some
cases where a target cannot properly link with the libgcc provided by
the (specific release of the) GCC toolchain in use. Using private libgcc
to other cases than these does not fix or improve anything; those
other cases were working and did not require any fix in this respect.


This isn't true, exactly.  If using clang for example everyone needs to
enable this code.  We're also using -fno-builtin -ffreestanding which
should limit the amount of interference from the toolchain.  And we get
that.


You mean clang does not produce self-sustained binaries?


clang does not provide "libgcc", so there's no -lgcc providing all of
the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S  _lshrdi3.S _modsi3.S _udivsi3.S
_umodsi3.S div0.S  _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx


(ok, that explains what you mean by AEABI functions -- those are
actually not functions defined by the AEABI, but functions that the GCC
folks prefixed with __aeabi.)


No.  For reference,
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf
and chapter 4 is all about the support library.  We are entirely in our
right to do either of (a) use the compiler-provided library (b) provide
our own implementation of what we need.  The kernel opts for (b) and I
would like us to follow that as well, consistently, rather than ad-hoc.


Second that. By having _EVERYTHING_ coming from U-Boot we are taking care of
_ANY_ possible mismatch between what we are building and pre-built toolchain
libraries. Soft float in ARM U-Boot and VFP hard float in most i.MX6/7
toolchains is just one of such prominent examples.

U-Boot is a standalone program not supposed to coexist with any external
applications i.e. it is totally self-sufficient, not living in some kind of
system environment so it makes perfect sense for it not to use _ANY_
external parts in the final binary.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Sergey Kubushyn]

On Thu, 24 Mar 2016, Marek Vasut wrote:


On 03/24/2016 08:08 PM, Sergey Kubushyn wrote:

On Thu, 24 Mar 2016, Marek Vasut wrote:


On 03/24/2016 07:43 PM, Sergey Kubushyn wrote:

On Thu, 24 Mar 2016, Sergey Kubushyn wrote:


On Thu, 24 Mar 2016, Marek Vasut wrote:


 On 03/24/2016 12:54 AM, Sergey Kubushyn wrote:

 On Thu, 24 Mar 2016, Marek Vasut wrote:

 On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:
 On Thu, 24 Mar 2016, Marek Vasut wrote:

 On 03/24/2016 12:08 AM, Tom Rini wrote:

 On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn

wrote:

 On Wed, 23 Mar 2016, Tom Rini wrote:

 On Wed, Mar 23, 2016 at 06:08:45PM +0100,

Albert ARIBAUD > > > > > > >  wrote:

 Hello Tom,

 On Wed, 23 Mar 2016 09:22:38 -0400,

Tom Rini > > > > > > > >  <tr...@konsulko.com>

 wrote:

 On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert

ARIBAUD > > > > > > > > >  wrote:

 Hello Marek,

 On Sun, 20 Mar 2016 17:15:34

+0100, Marek Vasut > > > > > > > > > >  <ma...@denx.de>

 wrote:

 This patch decouples U-Boot binary from the >

 toolchain on

 systems where
 private libgcc is available. Instead of

pulling in > > > > > > > > > > >  functions

 provided
 by the libgcc from the toolchain, U-Boot will

use > > > > > > > > > > >  it's own set

 of libgcc
 functions. These functions are usually

imported from > > > > > > > > > > >  Linux

 kernel, which
 also uses it's own libgcc functions instead of

the > > > > > > > > > > >  ones

 provided by the
 toolchain.

 This patch solves a

rather common problem. The > > > > > > > > > > >  toolchain can

 usually
 generate code for many variants of target > >

 architecture and

 often even
 different endianness. The libgcc on the other

hand > > > > > > > > > > >  is usually

 compiled
 for one particular configuration and the

functions > > > > > > > > > > >  provided by

 it may
 or may not be suited for use in U-Boot. This

can > > > > > > > > > > >  manifest in

 two ways,
 either the U-Boot fails to compile altogether

and > > > > > > > > > > >  linker will

 complain
 or, in the much worse case, the resulting

U-Boot > > > > > > > > > > >  will build,

 but will
 misbehave in very subtle and hard to debug ways.

 I don't think using private

libgcc by default is a > > > > > > > > > >  good idea.

 U-Boot's private libgcc is

not a feature of U-Boot, > > > > > > > > > >  but a fix

 for some
 cases where a target cannot properly link with

the > > > > > > > > > >  libgcc

 provided by
 the (specific release of the) GCC toolchain in

use. > > > > > > > > > >  Using

 private libgcc
 to other cases than these does not fix or

improve > > > > > > > > > >  anything; those

 other cases were working and did not require any

fix > > > > > > > > > >  in this

 respect.

 This isn't true, exactly.  If

using clang for example > > > > > > > > >  everyone

 needs to
 enable this code.  We're also using -fno-builtin >

 -ffreestanding

 which
 should limit the amount of interference from the >

 toolchain.  And

 we get
 that.

 You mean clang does not produce

self-sustained binaries?

 clang does not provide "libgcc", so

there's no -lgcc > > > > > > >  providing

 all of
 the functions that are (today) in:
 _ashldi3.S _ashrdi3.S _divsi3.S  _lshrdi3.S _modsi3.S
 _udivsi3.S
 _umodsi3.S div0.S  _uldivmod.S
 which aside from __modsi3 and __umodsi3 are all

__aeabi_xxx

 There is also _udivmoddi4 pulled from libgcc

for 64-bit > > > > > >  division

 since we
 switched to 64-bit all around ARM. It comes from clock
 calculations for
 video, e.g. from drivers/video/ipu_common.c for i.MX6.

 Well, this is an example of why we both don't

want libgcc ever > > > > >  nor

 do we
 want to overly expand what we do offer.  In this case

isn't it > > > > >  an

 example of something that should be using lldiv/do_div/etc?

 I haven't seen the _udivmoddi4 emitted in my tests.

Linux's libgcc > > > >  copy

 also doesn't implement the function. Which toolchain do you

use > > > >  and

 which target did you compile?

 I'm using my own armv7hl-linux-gnueabi toolchain built

for hard > > >  float.

 Linux
 arm libgcc does have arch/arm/lib/div64.S file that provides
 __do_div64()
 function that is used by do_div() from includ

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Sergey Kubushyn]

On Thu, 24 Mar 2016, Marek Vasut wrote:


On 03/24/2016 07:43 PM, Sergey Kubushyn wrote:

On Thu, 24 Mar 2016, Sergey Kubushyn wrote:


On Thu, 24 Mar 2016, Marek Vasut wrote:


 On 03/24/2016 12:54 AM, Sergey Kubushyn wrote:

 On Thu, 24 Mar 2016, Marek Vasut wrote:

 On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:
 On Thu, 24 Mar 2016, Marek Vasut wrote:

 On 03/24/2016 12:08 AM, Tom Rini wrote:

 On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn

wrote:

 On Wed, 23 Mar 2016, Tom Rini wrote:

 On Wed, Mar 23, 2016 at 06:08:45PM +0100,

Albert ARIBAUD > > > > > > >  wrote:

 Hello Tom,

 On Wed, 23 Mar 2016 09:22:38 -0400,

Tom Rini > > > > > > > >  <tr...@konsulko.com>

 wrote:

 On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert

ARIBAUD > > > > > > > > >  wrote:

 Hello Marek,

 On Sun, 20 Mar 2016 17:15:34

+0100, Marek Vasut > > > > > > > > > >  <ma...@denx.de>

 wrote:

 This patch decouples U-Boot binary from the >

 toolchain on

 systems where
 private libgcc is available. Instead of

pulling in > > > > > > > > > > >  functions

 provided
 by the libgcc from the toolchain, U-Boot will

use > > > > > > > > > > >  it's own set

 of libgcc
 functions. These functions are usually

imported from > > > > > > > > > > >  Linux

 kernel, which
 also uses it's own libgcc functions instead of

the > > > > > > > > > > >  ones

 provided by the
 toolchain.

 This patch solves a

rather common problem. The > > > > > > > > > > >  toolchain can

 usually
 generate code for many variants of target > >

 architecture and

 often even
 different endianness. The libgcc on the other

hand > > > > > > > > > > >  is usually

 compiled
 for one particular configuration and the

functions > > > > > > > > > > >  provided by

 it may
 or may not be suited for use in U-Boot. This

can > > > > > > > > > > >  manifest in

 two ways,
 either the U-Boot fails to compile altogether

and > > > > > > > > > > >  linker will

 complain
 or, in the much worse case, the resulting

U-Boot > > > > > > > > > > >  will build,

 but will
 misbehave in very subtle and hard to debug ways.

 I don't think using private

libgcc by default is a > > > > > > > > > >  good idea.

 U-Boot's private libgcc is

not a feature of U-Boot, > > > > > > > > > >  but a fix

 for some
 cases where a target cannot properly link with

the > > > > > > > > > >  libgcc

 provided by
 the (specific release of the) GCC toolchain in

use. > > > > > > > > > >  Using

 private libgcc
 to other cases than these does not fix or

improve > > > > > > > > > >  anything; those

 other cases were working and did not require any

fix > > > > > > > > > >  in this

 respect.

 This isn't true, exactly.  If

using clang for example > > > > > > > > >  everyone

 needs to
 enable this code.  We're also using -fno-builtin >

 -ffreestanding

 which
 should limit the amount of interference from the >

 toolchain.  And

 we get
 that.

 You mean clang does not produce

self-sustained binaries?

 clang does not provide "libgcc", so

there's no -lgcc > > > > > > >  providing

 all of
 the functions that are (today) in:
 _ashldi3.S _ashrdi3.S _divsi3.S  _lshrdi3.S _modsi3.S
 _udivsi3.S
 _umodsi3.S div0.S  _uldivmod.S
 which aside from __modsi3 and __umodsi3 are all

__aeabi_xxx

 There is also _udivmoddi4 pulled from libgcc

for 64-bit > > > > > >  division

 since we
 switched to 64-bit all around ARM. It comes from clock
 calculations for
 video, e.g. from drivers/video/ipu_common.c for i.MX6.

 Well, this is an example of why we both don't

want libgcc ever > > > > >  nor

 do we
 want to overly expand what we do offer.  In this case

isn't it > > > > >  an

 example of something that should be using lldiv/do_div/etc?

 I haven't seen the _udivmoddi4 emitted in my tests.

Linux's libgcc > > > >  copy

 also doesn't implement the function. Which toolchain do you

use > > > >  and

 which target did you compile?

 I'm using my own armv7hl-linux-gnueabi toolchain built

for hard > > >  float.

 Linux
 arm libgcc does have arch/arm/lib/div64.S file that provides
 __do_div64()
 function that is used by do_div() from include/asm/div64.h for
 32-bit
 ARM
 platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Sergey Kubushyn]

On Thu, 24 Mar 2016, Sergey Kubushyn wrote:


On Thu, 24 Mar 2016, Marek Vasut wrote:


 On 03/24/2016 12:54 AM, Sergey Kubushyn wrote:
>  On Thu, 24 Mar 2016, Marek Vasut wrote:
> 
> >  On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:

> > >  On Thu, 24 Mar 2016, Marek Vasut wrote:
> > > 
> > > >  On 03/24/2016 12:08 AM, Tom Rini wrote:

> > > > >  On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:
> > > > > >  On Wed, 23 Mar 2016, Tom Rini wrote:
> > > > > > 
> > > > > > >  On Wed, Mar 23, 2016 at 06:08:45PM +0100, Albert ARIBAUD 
> > > > > > >  wrote:

> > > > > > > >  Hello Tom,
> > > > > > > > 
> > > > > > > >  On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini 
> > > > > > > >  <tr...@konsulko.com>

> > > > > > > >  wrote:
> > > > > > > > >  On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD 
> > > > > > > > >  wrote:

> > > > > > > > > >  Hello Marek,
> > > > > > > > > > 
> > > > > > > > > >  On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut 
> > > > > > > > > >  <ma...@denx.de>

> > > > > > > > > >  wrote:
> > > > > > > > > > >  This patch decouples U-Boot binary from the 
> > > > > > > > > > >  toolchain on

> > > > > > > > > > >  systems where
> > > > > > > > > > >  private libgcc is available. Instead of pulling in 
> > > > > > > > > > >  functions

> > > > > > > > > > >  provided
> > > > > > > > > > >  by the libgcc from the toolchain, U-Boot will use 
> > > > > > > > > > >  it's own set

> > > > > > > > > > >  of libgcc
> > > > > > > > > > >  functions. These functions are usually imported from 
> > > > > > > > > > >  Linux

> > > > > > > > > > >  kernel, which
> > > > > > > > > > >  also uses it's own libgcc functions instead of the 
> > > > > > > > > > >  ones

> > > > > > > > > > >  provided by the
> > > > > > > > > > >  toolchain.
> > > > > > > > > > > 
> > > > > > > > > > >  This patch solves a rather common problem. The 
> > > > > > > > > > >  toolchain can

> > > > > > > > > > >  usually
> > > > > > > > > > >  generate code for many variants of target 
> > > > > > > > > > >  architecture and

> > > > > > > > > > >  often even
> > > > > > > > > > >  different endianness. The libgcc on the other hand 
> > > > > > > > > > >  is usually

> > > > > > > > > > >  compiled
> > > > > > > > > > >  for one particular configuration and the functions 
> > > > > > > > > > >  provided by

> > > > > > > > > > >  it may
> > > > > > > > > > >  or may not be suited for use in U-Boot. This can 
> > > > > > > > > > >  manifest in

> > > > > > > > > > >  two ways,
> > > > > > > > > > >  either the U-Boot fails to compile altogether and 
> > > > > > > > > > >  linker will

> > > > > > > > > > >  complain
> > > > > > > > > > >  or, in the much worse case, the resulting U-Boot 
> > > > > > > > > > >  will build,

> > > > > > > > > > >  but will
> > > > > > > > > > >  misbehave in very subtle and hard to debug ways.
> > > > > > > > > > 
> > > > > > > > > >  I don't think using private libgcc by default is a 
> > > > > > > > > >  good idea.
> > > > > > > > > > 
> > > > > > > > > >  U-Boot's private libgcc is not a feature of 

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Sergey Kubushyn]

On Thu, 24 Mar 2016, Marek Vasut wrote:


On 03/24/2016 12:54 AM, Sergey Kubushyn wrote:

On Thu, 24 Mar 2016, Marek Vasut wrote:


On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:

On Thu, 24 Mar 2016, Marek Vasut wrote:


On 03/24/2016 12:08 AM, Tom Rini wrote:

On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:

On Wed, 23 Mar 2016, Tom Rini wrote:


On Wed, Mar 23, 2016 at 06:08:45PM +0100, Albert ARIBAUD wrote:

Hello Tom,

On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini <tr...@konsulko.com>
wrote:

On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:

Hello Marek,

On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut <ma...@denx.de>
wrote:

This patch decouples U-Boot binary from the toolchain on
systems where
private libgcc is available. Instead of pulling in functions
provided
by the libgcc from the toolchain, U-Boot will use it's own set
of libgcc
functions. These functions are usually imported from Linux
kernel, which
also uses it's own libgcc functions instead of the ones
provided by the
toolchain.

This patch solves a rather common problem. The toolchain can
usually
generate code for many variants of target architecture and
often even
different endianness. The libgcc on the other hand is usually
compiled
for one particular configuration and the functions provided by
it may
or may not be suited for use in U-Boot. This can manifest in
two ways,
either the U-Boot fails to compile altogether and linker will
complain
or, in the much worse case, the resulting U-Boot will build,
but will
misbehave in very subtle and hard to debug ways.


I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix
for some
cases where a target cannot properly link with the libgcc
provided by
the (specific release of the) GCC toolchain in use. Using
private libgcc
to other cases than these does not fix or improve anything; those
other cases were working and did not require any fix in this
respect.


This isn't true, exactly.  If using clang for example everyone
needs to
enable this code.  We're also using -fno-builtin -ffreestanding
which
should limit the amount of interference from the toolchain.  And
we get
that.


You mean clang does not produce self-sustained binaries?


clang does not provide "libgcc", so there's no -lgcc providing
all of
the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S  _lshrdi3.S _modsi3.S _udivsi3.S
_umodsi3.S div0.S  _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx


There is also _udivmoddi4 pulled from libgcc for 64-bit division
since we
switched to 64-bit all around ARM. It comes from clock
calculations for
video, e.g. from drivers/video/ipu_common.c for i.MX6.


Well, this is an example of why we both don't want libgcc ever nor
do we
want to overly expand what we do offer.  In this case isn't it an
example of something that should be using lldiv/do_div/etc?


I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy
also doesn't implement the function. Which toolchain do you use and
which target did you compile?


I'm using my own armv7hl-linux-gnueabi toolchain built for hard float.
Linux
arm libgcc does have arch/arm/lib/div64.S file that provides
__do_div64()
function that is used by do_div() from include/asm/div64.h for 32-bit
ARM
platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have
div64.h
(that is totally different from what Linux provides) but no div64.S in
arch/arm/lib.


In that case, we should just import div64.S from Linux on arm32 and be
done with it ? Since we now have all the necessary macros thanks to the
first four patches in this series, that should be trivial.

What do you think? I can bake a patch real quick, so you can test it ?


Sure I'll test it, no problems. Just bake the patch :)


Done, give it a go please.


OK, it didn't work, _udivmoddi4.o is still being pulled from libgcc. I'm
analyzing it right now, will come up with more later today.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Sergey Kubushyn]

On Thu, 24 Mar 2016, Marek Vasut wrote:


On 03/24/2016 12:54 AM, Sergey Kubushyn wrote:

On Thu, 24 Mar 2016, Marek Vasut wrote:


On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:

On Thu, 24 Mar 2016, Marek Vasut wrote:


On 03/24/2016 12:08 AM, Tom Rini wrote:

On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:

On Wed, 23 Mar 2016, Tom Rini wrote:


On Wed, Mar 23, 2016 at 06:08:45PM +0100, Albert ARIBAUD wrote:

Hello Tom,

On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini <tr...@konsulko.com>
wrote:

On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:

Hello Marek,

On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut <ma...@denx.de>
wrote:

This patch decouples U-Boot binary from the toolchain on
systems where
private libgcc is available. Instead of pulling in functions
provided
by the libgcc from the toolchain, U-Boot will use it's own set
of libgcc
functions. These functions are usually imported from Linux
kernel, which
also uses it's own libgcc functions instead of the ones
provided by the
toolchain.

This patch solves a rather common problem. The toolchain can
usually
generate code for many variants of target architecture and
often even
different endianness. The libgcc on the other hand is usually
compiled
for one particular configuration and the functions provided by
it may
or may not be suited for use in U-Boot. This can manifest in
two ways,
either the U-Boot fails to compile altogether and linker will
complain
or, in the much worse case, the resulting U-Boot will build,
but will
misbehave in very subtle and hard to debug ways.


I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix
for some
cases where a target cannot properly link with the libgcc
provided by
the (specific release of the) GCC toolchain in use. Using
private libgcc
to other cases than these does not fix or improve anything; those
other cases were working and did not require any fix in this
respect.


This isn't true, exactly.  If using clang for example everyone
needs to
enable this code.  We're also using -fno-builtin -ffreestanding
which
should limit the amount of interference from the toolchain.  And
we get
that.


You mean clang does not produce self-sustained binaries?


clang does not provide "libgcc", so there's no -lgcc providing
all of
the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S  _lshrdi3.S _modsi3.S _udivsi3.S
_umodsi3.S div0.S  _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx


There is also _udivmoddi4 pulled from libgcc for 64-bit division
since we
switched to 64-bit all around ARM. It comes from clock
calculations for
video, e.g. from drivers/video/ipu_common.c for i.MX6.


Well, this is an example of why we both don't want libgcc ever nor
do we
want to overly expand what we do offer.  In this case isn't it an
example of something that should be using lldiv/do_div/etc?


I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy
also doesn't implement the function. Which toolchain do you use and
which target did you compile?


I'm using my own armv7hl-linux-gnueabi toolchain built for hard float.
Linux
arm libgcc does have arch/arm/lib/div64.S file that provides
__do_div64()
function that is used by do_div() from include/asm/div64.h for 32-bit
ARM
platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have
div64.h
(that is totally different from what Linux provides) but no div64.S in
arch/arm/lib.


In that case, we should just import div64.S from Linux on arm32 and be
done with it ? Since we now have all the necessary macros thanks to the
first four patches in this series, that should be trivial.

What do you think? I can bake a patch real quick, so you can test it ?


Sure I'll test it, no problems. Just bake the patch :)


Done, give it a go please.


Will do first thing tomorrow morning when I'm back at my work desk. Will
post the results when done.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Sergey Kubushyn]

On Thu, 24 Mar 2016, Marek Vasut wrote:


On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:

On Thu, 24 Mar 2016, Marek Vasut wrote:


On 03/24/2016 12:08 AM, Tom Rini wrote:

On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:

On Wed, 23 Mar 2016, Tom Rini wrote:


On Wed, Mar 23, 2016 at 06:08:45PM +0100, Albert ARIBAUD wrote:

Hello Tom,

On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini <tr...@konsulko.com>
wrote:

On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:

Hello Marek,

On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut <ma...@denx.de>
wrote:

This patch decouples U-Boot binary from the toolchain on
systems where
private libgcc is available. Instead of pulling in functions
provided
by the libgcc from the toolchain, U-Boot will use it's own set
of libgcc
functions. These functions are usually imported from Linux
kernel, which
also uses it's own libgcc functions instead of the ones
provided by the
toolchain.

This patch solves a rather common problem. The toolchain can
usually
generate code for many variants of target architecture and
often even
different endianness. The libgcc on the other hand is usually
compiled
for one particular configuration and the functions provided by
it may
or may not be suited for use in U-Boot. This can manifest in
two ways,
either the U-Boot fails to compile altogether and linker will
complain
or, in the much worse case, the resulting U-Boot will build,
but will
misbehave in very subtle and hard to debug ways.


I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix
for some
cases where a target cannot properly link with the libgcc
provided by
the (specific release of the) GCC toolchain in use. Using
private libgcc
to other cases than these does not fix or improve anything; those
other cases were working and did not require any fix in this
respect.


This isn't true, exactly.  If using clang for example everyone
needs to
enable this code.  We're also using -fno-builtin -ffreestanding
which
should limit the amount of interference from the toolchain.  And
we get
that.


You mean clang does not produce self-sustained binaries?


clang does not provide "libgcc", so there's no -lgcc providing all of
the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S  _lshrdi3.S _modsi3.S _udivsi3.S
_umodsi3.S div0.S  _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx


There is also _udivmoddi4 pulled from libgcc for 64-bit division
since we
switched to 64-bit all around ARM. It comes from clock calculations for
video, e.g. from drivers/video/ipu_common.c for i.MX6.


Well, this is an example of why we both don't want libgcc ever nor do we
want to overly expand what we do offer.  In this case isn't it an
example of something that should be using lldiv/do_div/etc?


I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy
also doesn't implement the function. Which toolchain do you use and
which target did you compile?


I'm using my own armv7hl-linux-gnueabi toolchain built for hard float.
Linux
arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64()
function that is used by do_div() from include/asm/div64.h for 32-bit ARM
platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have div64.h
(that is totally different from what Linux provides) but no div64.S in
arch/arm/lib.


In that case, we should just import div64.S from Linux on arm32 and be
done with it ? Since we now have all the necessary macros thanks to the
first four patches in this series, that should be trivial.

What do you think? I can bake a patch real quick, so you can test it ?


Sure I'll test it, no problems. Just bake the patch :)

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Sergey Kubushyn]

On Thu, 24 Mar 2016, Marek Vasut wrote:


On 03/24/2016 12:08 AM, Tom Rini wrote:

On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:

On Wed, 23 Mar 2016, Tom Rini wrote:


On Wed, Mar 23, 2016 at 06:08:45PM +0100, Albert ARIBAUD wrote:

Hello Tom,

On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini <tr...@konsulko.com> wrote:

On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:

Hello Marek,

On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut <ma...@denx.de> wrote:

This patch decouples U-Boot binary from the toolchain on systems where
private libgcc is available. Instead of pulling in functions provided
by the libgcc from the toolchain, U-Boot will use it's own set of libgcc
functions. These functions are usually imported from Linux kernel, which
also uses it's own libgcc functions instead of the ones provided by the
toolchain.

This patch solves a rather common problem. The toolchain can usually
generate code for many variants of target architecture and often even
different endianness. The libgcc on the other hand is usually compiled
for one particular configuration and the functions provided by it may
or may not be suited for use in U-Boot. This can manifest in two ways,
either the U-Boot fails to compile altogether and linker will complain
or, in the much worse case, the resulting U-Boot will build, but will
misbehave in very subtle and hard to debug ways.


I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some
cases where a target cannot properly link with the libgcc provided by
the (specific release of the) GCC toolchain in use. Using private libgcc
to other cases than these does not fix or improve anything; those
other cases were working and did not require any fix in this respect.


This isn't true, exactly.  If using clang for example everyone needs to
enable this code.  We're also using -fno-builtin -ffreestanding which
should limit the amount of interference from the toolchain.  And we get
that.


You mean clang does not produce self-sustained binaries?


clang does not provide "libgcc", so there's no -lgcc providing all of
the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S  _lshrdi3.S _modsi3.S _udivsi3.S
_umodsi3.S div0.S  _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx


There is also _udivmoddi4 pulled from libgcc for 64-bit division since we
switched to 64-bit all around ARM. It comes from clock calculations for
video, e.g. from drivers/video/ipu_common.c for i.MX6.


Well, this is an example of why we both don't want libgcc ever nor do we
want to overly expand what we do offer.  In this case isn't it an
example of something that should be using lldiv/do_div/etc?


I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy
also doesn't implement the function. Which toolchain do you use and
which target did you compile?


I'm using my own armv7hl-linux-gnueabi toolchain built for hard float. Linux
arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64()
function that is used by do_div() from include/asm/div64.h for 32-bit ARM
platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have div64.h
(that is totally different from what Linux provides) but no div64.S in
arch/arm/lib.

The target is a custom board based on Freescale/NXP mx6qsabresd (I'm not
ready to submit it to the main tree yet) so sabresd should produce the same
result. Just have IPU enabled.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Sergey Kubushyn]

On Wed, 23 Mar 2016, Tom Rini wrote:


On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:

On Wed, 23 Mar 2016, Tom Rini wrote:


On Wed, Mar 23, 2016 at 06:08:45PM +0100, Albert ARIBAUD wrote:

Hello Tom,

On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini <tr...@konsulko.com> wrote:

On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:

Hello Marek,

On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut <ma...@denx.de> wrote:

This patch decouples U-Boot binary from the toolchain on systems where
private libgcc is available. Instead of pulling in functions provided
by the libgcc from the toolchain, U-Boot will use it's own set of libgcc
functions. These functions are usually imported from Linux kernel, which
also uses it's own libgcc functions instead of the ones provided by the
toolchain.

This patch solves a rather common problem. The toolchain can usually
generate code for many variants of target architecture and often even
different endianness. The libgcc on the other hand is usually compiled
for one particular configuration and the functions provided by it may
or may not be suited for use in U-Boot. This can manifest in two ways,
either the U-Boot fails to compile altogether and linker will complain
or, in the much worse case, the resulting U-Boot will build, but will
misbehave in very subtle and hard to debug ways.


I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some
cases where a target cannot properly link with the libgcc provided by
the (specific release of the) GCC toolchain in use. Using private libgcc
to other cases than these does not fix or improve anything; those
other cases were working and did not require any fix in this respect.


This isn't true, exactly.  If using clang for example everyone needs to
enable this code.  We're also using -fno-builtin -ffreestanding which
should limit the amount of interference from the toolchain.  And we get
that.


You mean clang does not produce self-sustained binaries?


clang does not provide "libgcc", so there's no -lgcc providing all of
the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S  _lshrdi3.S _modsi3.S _udivsi3.S
_umodsi3.S div0.S  _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx


There is also _udivmoddi4 pulled from libgcc for 64-bit division since we
switched to 64-bit all around ARM. It comes from clock calculations for
video, e.g. from drivers/video/ipu_common.c for i.MX6.


Well, this is an example of why we both don't want libgcc ever nor do we
want to overly expand what we do offer.  In this case isn't it an
example of something that should be using lldiv/do_div/etc?


It is. However do_div does not help for some reason -- here is an excerpt
from drivers/video/ipu_common.c (one of several places where do_div() is
used) that pulls _udivmoddi4 from toolchain anyways:

=== Cut ===
static void ipu_pixel_clk_recalc(struct clk *clk)
{
u32 div;
u64 final_rate = (unsigned long long)clk->parent->rate * 16;

div = __raw_readl(DI_BS_CLKGEN0(clk->id));
debug("read BS_CLKGEN0 div:%d, final_rate:%lld, prate:%ld\n",
  div, final_rate, clk->parent->rate);

clk->rate = 0;
if (div != 0) {
do_div(final_rate, div);
clk->rate = final_rate;
}
}
=== Cut ===

Without the above hack this results in link failure:

=== Cut ===
arm-linux-gnueabi-ld.bfd: error: 
/opt/arm-linux-toolchain/lib/gcc/arm-linux-gnueabi/5.3.0/libgcc.a(_udivmoddi4.o)
 uses VFP register arguments, u-boot does not
arm-linux-gnueabi-ld.bfd: failed to merge target specific data of file 
/opt/arm-linux-toolchain/lib/gcc/arm-linux-gnueabi/5.3.0/libgcc.a(_udivmoddi4.o)
Makefile:1191: recipe for target 'u-boot' failed
make: *** [u-boot] Error 1
=== Cut ===

U-Boot built with "-mfloat-abi=hard -mfpu=vfpv3-d16" pulls whatever it
requires from toolchain libgcc and works fine, no problems.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Sergey Kubushyn]

On Wed, 23 Mar 2016, Tom Rini wrote:


On Wed, Mar 23, 2016 at 06:08:45PM +0100, Albert ARIBAUD wrote:

Hello Tom,

On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini  wrote:

On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:

Hello Marek,

On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut  wrote:

This patch decouples U-Boot binary from the toolchain on systems where
private libgcc is available. Instead of pulling in functions provided
by the libgcc from the toolchain, U-Boot will use it's own set of libgcc
functions. These functions are usually imported from Linux kernel, which
also uses it's own libgcc functions instead of the ones provided by the
toolchain.

This patch solves a rather common problem. The toolchain can usually
generate code for many variants of target architecture and often even
different endianness. The libgcc on the other hand is usually compiled
for one particular configuration and the functions provided by it may
or may not be suited for use in U-Boot. This can manifest in two ways,
either the U-Boot fails to compile altogether and linker will complain
or, in the much worse case, the resulting U-Boot will build, but will
misbehave in very subtle and hard to debug ways.


I don't think using private libgcc by default is a good idea.

U-Boot's private libgcc is not a feature of U-Boot, but a fix for some
cases where a target cannot properly link with the libgcc provided by
the (specific release of the) GCC toolchain in use. Using private libgcc
to other cases than these does not fix or improve anything; those
other cases were working and did not require any fix in this respect.


This isn't true, exactly.  If using clang for example everyone needs to
enable this code.  We're also using -fno-builtin -ffreestanding which
should limit the amount of interference from the toolchain.  And we get
that.


You mean clang does not produce self-sustained binaries?


clang does not provide "libgcc", so there's no -lgcc providing all of
the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S  _lshrdi3.S _modsi3.S _udivsi3.S
_umodsi3.S div0.S  _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx


There is also _udivmoddi4 pulled from libgcc for 64-bit division since we
switched to 64-bit all around ARM. It comes from clock calculations for
video, e.g. from drivers/video/ipu_common.c for i.MX6.

The problem is most of i.MX6 toolchains (including my own) are built with
"-mfloat-abi=hard -mfpu=vfpv3-d16" or something similar so it fails to link
with the rest of U-Boot that is unconditionally built with "-msoft-float"
for unknown reason.

We should either add 64-bit functions to private libgcc so it is built and
linked properly with whatever ABI are nailed down in arch/arm/config.mk or
somehow allow to specify specific ABI flags in board configuration or
wherever else.

I do use a hack like this

=== Cut ===
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 9af6c37..a96868c 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -16,8 +16,14 @@ endif
 LDFLAGS_FINAL += --gc-sections
 PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \
 -fno-common -ffixed-r9
-PLATFORM_RELFLAGS += $(call cc-option, -msoft-float) \
-  $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,))
+
+ifeq ($(CONFIG_SYS_HARDFP_VFP_BUILD),y)
+PLATFORM_RELFLAGS += $(call cc-option,-mfloat-abi=hard,$(call 
cc-option,-mfpu=vfpv3-d16,))
+else
+PLATFORM_RELFLAGS += $(call cc-option, -msoft-float)
+endif
+
+PLATFORM_RELFLAGS += $(call cc-option,-mshort-load-bytes,$(call 
cc-option,-malignment-traps,))
=== Cut ===

but this is not very nice so it won't go in the main tree for sure.

A smarter, more elegant way should be invented so the entire U-Boot could be
built with ABI flags matched those used for toolchain build.

Or _ALL_ libgcc functions should be made U-Boot private so no toolchain
parts are used at all.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Build failures with hard float

[Sergey Kubushyn]

There are multiple build failures with hard float toolchains caused by
switching to 64-bit data. This shows up in drivers/video among others i.e.
in ipu_common.c when building for i.MX6 with video enabled.

=== Cut ===
arm-linux-gnueabi-ld.bfd: error:
/opt/arm-linux-toolchain/lib/gcc/arm-linux-gnueabi/5.3.0/libgcc.a(_
udivmoddi4.o) uses VFP register arguments, u-boot does not
arm-linux-gnueabi-ld.bfd: failed to merge target specific data of file
/opt/arm-linux-toolchain/lib/
gcc/arm-linux-gnueabi/5.3.0/libgcc.a(_udivmoddi4.o)
Makefile:1191: recipe for target 'u-boot' failed
make: *** [u-boot] Error 1
=== Cut ===

Is something going to be done with this?

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] schmoogie: fix build error due to removal of forceenv()

[Sergey Kubushyn]

On Tue, 5 Oct 2010, Wolfgang Denk wrote:

Ack-by: Sergey Kubushyn k...@koi8.net
---

 commit 6d014adf dropped support for the forceenv() function, but failed
 to remove references to it from board/davinci/schmoogie/schmoogie.c

 Replace forceenv() by setenv() and set CONFIG_ENV_OVERWRITE instead in
 the board config file to allow overwriting the serial number.

 Signed-off-by: Wolfgang Denk w...@denx.de
 Cc: Sergey Kubushyn k...@koi8.net
 ---
 board/davinci/schmoogie/schmoogie.c |8 
 include/configs/davinci-schmoogie.h |1 +
 2 files changed, 5 insertions(+), 4 deletions(-)

 diff --git a/board/davinci/schmoogie/schmoogie.c 
 b/board/davinci/schmoogie/schmoogie.c
 index 19c9580..80a0f9f 100644
 --- a/board/davinci/schmoogie/schmoogie.c
 +++ b/board/davinci/schmoogie/schmoogie.c
 @@ -107,12 +107,12 @@ int misc_init_r(void)
   /* Set serial number from UID chip */
   if (i2c_read(CONFIG_SYS_UID_ADDR, 0, 1, buf, 8)) {
   printf(\nUID @ 0x%02x read FAILED!!!\n, CONFIG_SYS_UID_ADDR);
 - forceenv(serial#, FAILED);
 + setenv(serial#, FAILED);
   } else {
   if (buf[0] != 0x70) {
   /* Device Family Code */
   printf(\nUID @ 0x%02x read FAILED!!!\n, 
 CONFIG_SYS_UID_ADDR);
 - forceenv(serial#, FAILED);
 + setenv(serial#, FAILED);
   }
   }
   /* Now check CRC */
 @@ -122,12 +122,12 @@ int misc_init_r(void)

   if (tmp[0] != 0) {
   printf(\nUID @ 0x%02x - BAD CRC!!!\n, CONFIG_SYS_UID_ADDR);
 - forceenv(serial#, FAILED);
 + setenv(serial#, FAILED);
   } else {
   /* CRC OK, set serial env variable */
   sprintf((char *)tmp[0], %02x%02x%02x%02x%02x%02x,
   buf[6], buf[5], buf[4], buf[3], buf[2], buf[1]);
 - forceenv(serial#, (char *)tmp[0]);
 + setenv(serial#, (char *)tmp[0]);
   }

   return(0);
 diff --git a/include/configs/davinci-schmoogie.h 
 b/include/configs/davinci-schmoogie.h
 index 04cdc21..5b140fc 100644
 --- a/include/configs/davinci-schmoogie.h
 +++ b/include/configs/davinci-schmoogie.h
 @@ -83,6 +83,7 @@
 /*=*/
 #undef CONFIG_ENV_IS_IN_FLASH
 #define CONFIG_SYS_NO_FLASH
 +#define CONFIG_ENV_OVERWRITE /* instead if obsoleted forceenv() */
 #define CONFIG_NAND_DAVINCI
 #define CONFIG_SYS_NAND_CS2
 #define CONFIG_ENV_IS_IN_NAND /* U-Boot env in NAND Flash  */
 -- 
 1.7.2.3


---
**
*  k...@homeKOI8 Net The impossible we do immediately.  *
*  Las Vegas   NV, USA  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Would somebody block this please?

[Sergey Kubushyn]

It is already 5th or more same spam email in a row. Does anybody care?

---
**
*  k...@homeKOI8 Net The impossible we do immediately.  *
*  Las Vegas   NV, USA  Miracles require 24-hour notice.   *
**

-- Forwarded message --
Date: Fri, 1 Oct 2010 19:48:28
From: Kara Duggan kldug...@eagle.fgcu.edu
To: undisclosed-recipients:  ;
Subject: [U-Boot] Guaranteed loan offer**APPLY NOW**contact via
 email**bt48hrsfinancerdesk...@gmail.com**

We are currently giving out loans to any part of the world at 2% interest
rate. If interested, send your name, Resident country and Phone number to Mr.
Bernard Thompson with the email address bellow Email:
48hrsfinancerdesk...@gmail.com or call:
+447024053959

Regards
BT 48HRS FINANCE LOAN
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot