VMWare crashes with U-boot EFI Payload
Hi, As described in the subject. We have an x86 image with U-boot as a EFI Payload. It crashes the VM in VMware (Player 16) with a x86 triple fault. I have tried with a clean U-boot build with efi-x86_payload64_defconfig. I can see in the VM it prints U-boot EFI Payload and then throws the triple fault. Both a clean and our modified U-boot is working fine in qemu and on our real x86 hardware. Any idea's how to proceed with debuging this? /Sean
Re: [PATCH] fs/squashfs: use do_div function for math
On Thu, May 12, 2022 at 08:41:15PM +0200, Pali Rohár wrote:
> On Thursday 12 May 2022 20:02:33 Sean Nyekjaer wrote:
> > On Thu, May 12, 2022 at 12:24:01PM +0200, Pali Rohár wrote:
> > > On Thursday 12 May 2022 12:19:01 Pali Rohár wrote:
> > > > On Monday 09 May 2022 15:08:15 Miquel Raynal wrote:
> > > > > Hello,
> > > > >
> > > > > tr...@konsulko.com wrote on Thu, 5 May 2022 09:15:00 -0400:
> > > > >
> > > > > > On Thu, May 05, 2022 at 11:26:37AM +0200, Sean Nyekjaer wrote:
> > > > > >
> > > > > > > From: Sean Nyekjaer
> > > > > > >
> > > > > > > When compling for x86:
> > > > > > > ld.bfd: fs/squashfs/sqfs.o: in function `sqfs_read':
> > > > > > > u-boot/fs/squashfs/sqfs.c:1443: undefined reference to
> > > > > > > `__udivmoddi4'
> > > > > > > ld.bfd: u-boot/fs/squashfs/sqfs.c:1521: undefined reference to
> > > > > > > `__udivmoddi4'
> > > > > > >
> > > > > > > Signed-off-by: Sean Nyekjaer
> > > > > > > ---
> > > > > > > fs/squashfs/sqfs.c | 5 +++--
> > > > > > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > > > > > >
> > > > > > > diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
> > > > > > > index 5d9c52af80..6405db4ff3 100644
> > > > > > > --- a/fs/squashfs/sqfs.c
> > > > > > > +++ b/fs/squashfs/sqfs.c
> > > > > > > @@ -8,6 +8,7 @@
> > > > > > > */
> > > > > > >
> > > > > > > #include
> > > > > > > +#include
> > > > > > > #include
> > > > > > > #include
> > > > > > > #include
> > > > > > > @@ -1440,7 +1441,7 @@ int sqfs_read(const char *filename, void
> > > > > > > *buf, loff_t offset, loff_t len,
> > > > > > > }
> > > > > > >
> > > > > > > for (j = 0; j < datablk_count; j++) {
> > > > > > > - start = data_offset / ctxt.cur_dev->blksz;
> > > > > > > + start = do_div(data_offset, ctxt.cur_dev->blksz);
> > > > > > > table_size = SQFS_BLOCK_SIZE(finfo.blk_sizes[j]);
> > > > > > > table_offset = data_offset - (start *
> > > > > > > ctxt.cur_dev->blksz);
> > > > > > > n_blks = DIV_ROUND_UP(table_size + table_offset,
> > > > > > > @@ -1516,7 +1517,7 @@ int sqfs_read(const char *filename, void
> > > > > > > *buf, loff_t offset, loff_t len,
> > > > > > > goto out;
> > > > > > > }
> > > > > > >
> > > > > > > - start = frag_entry.start / ctxt.cur_dev->blksz;
> > > > > > > + start = do_div(frag_entry.start, ctxt.cur_dev->blksz);
> > > > > > > table_size = SQFS_BLOCK_SIZE(frag_entry.size);
> > > > > > > table_offset = frag_entry.start - (start * ctxt.cur_dev->blksz);
> > > > > > > n_blks = DIV_ROUND_UP(table_size + table_offset,
> > > > > > > ctxt.cur_dev->blksz);
> > > > > >
> > > > > > Adding maintainers...
> > > > >
> > > > > I guess that's a correct fix, so
> > > > >
> > > > > Reviewed-by: Miquel Raynal
> > > > >
> > > > > Thanks,
> > > > > Miquèl
> > > >
> > > > Hello! do_div() macro modifies its first argument. It is correct?
> > > > Because previous code did not modify anything.
> > >
> > > * The semantics of do_div() are:
> > > *
> > > * u32 do_div(u64 *n, u32 base)
> > > * {
> > > *u32 remainder = *n % base;
> > > **n = *n / base;
> > > *return remainder;
> > > * }
> > >
> > > And this patch replaced:
> > >
> > > start = data_offset / ctxt.cur_dev->blksz;
> > >
> > > by:
> > >
> > > start = do_div(data_offset, ctxt.cur_dev->blksz);
> > >
> > > which expands to:
> > >
> > > start = data_offset % ctxt.cur_dev->blksz;
> > > data_offset = data_offset / ctxt.cur_dev->blksz;
> > >
> > > Which is wrong as it calculates something totally different.
> > >
> > > So this patch is incorrect.
> >
> > Hi Pali,
> >
> > Yes I agree, I got tricked by some wrong cache from Yocto :/
> > I have tried lldiv(), and that works on our x86 target.
> >
> > Do you have an opinion on that?
> > Or do you have another idea to avoid the
> > "undefined reference to `__udivmoddi4'" error?
> >
> > /Sean
>
> Hello! You really should not use C division operator for 64-bit integers
> as gcc still is not able to generate assembler code for such division
> on many 32-bit platforms.
>
> You should use some function or macro from linux/math64.h or div64.h
> header file. For every combination of types, pairs and required
> operation there is specific function/macro (e.g. u64/u32, u64%u32,
> u64/u64, etc...).
>
> I think that lldiv() is the correct call here. This function expects u64
> as dividend, u32 as divisor and returns u64 result.
Thank you for the explanation :)
Updated patch should be on the list.
/Sean
[PATCH v2] fs/squashfs: use lldiv function for math
From: Sean Nyekjaer
When compling for x86:
ld.bfd: fs/squashfs/sqfs.o: in function `sqfs_read':
u-boot/fs/squashfs/sqfs.c:1443: undefined reference to `__udivmoddi4'
ld.bfd: u-boot/fs/squashfs/sqfs.c:1521: undefined reference to `__udivmoddi4'
Signed-off-by: Sean Nyekjaer
Reviewed-by: Miquel Raynal
---
Changes since v1:
- switched to the correct lldiv() instead of do_div()
fs/squashfs/sqfs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
index 5d9c52af80..08414571fc 100644
--- a/fs/squashfs/sqfs.c
+++ b/fs/squashfs/sqfs.c
@@ -8,6 +8,7 @@
*/
#include
+#include
#include
#include
#include
@@ -1440,7 +1441,7 @@ int sqfs_read(const char *filename, void *buf, loff_t
offset, loff_t len,
}
for (j = 0; j < datablk_count; j++) {
- start = data_offset / ctxt.cur_dev->blksz;
+ start = lldiv(data_offset, ctxt.cur_dev->blksz);
table_size = SQFS_BLOCK_SIZE(finfo.blk_sizes[j]);
table_offset = data_offset - (start * ctxt.cur_dev->blksz);
n_blks = DIV_ROUND_UP(table_size + table_offset,
@@ -1516,7 +1517,7 @@ int sqfs_read(const char *filename, void *buf, loff_t
offset, loff_t len,
goto out;
}
- start = frag_entry.start / ctxt.cur_dev->blksz;
+ start = lldiv(frag_entry.start, ctxt.cur_dev->blksz);
table_size = SQFS_BLOCK_SIZE(frag_entry.size);
table_offset = frag_entry.start - (start * ctxt.cur_dev->blksz);
n_blks = DIV_ROUND_UP(table_size + table_offset, ctxt.cur_dev->blksz);
--
2.35.1
Re: [PATCH] fs/squashfs: use do_div function for math
On Thu, May 12, 2022 at 12:24:01PM +0200, Pali Rohár wrote:
> On Thursday 12 May 2022 12:19:01 Pali Rohár wrote:
> > On Monday 09 May 2022 15:08:15 Miquel Raynal wrote:
> > > Hello,
> > >
> > > tr...@konsulko.com wrote on Thu, 5 May 2022 09:15:00 -0400:
> > >
> > > > On Thu, May 05, 2022 at 11:26:37AM +0200, Sean Nyekjaer wrote:
> > > >
> > > > > From: Sean Nyekjaer
> > > > >
> > > > > When compling for x86:
> > > > > ld.bfd: fs/squashfs/sqfs.o: in function `sqfs_read':
> > > > > u-boot/fs/squashfs/sqfs.c:1443: undefined reference to `__udivmoddi4'
> > > > > ld.bfd: u-boot/fs/squashfs/sqfs.c:1521: undefined reference to
> > > > > `__udivmoddi4'
> > > > >
> > > > > Signed-off-by: Sean Nyekjaer
> > > > > ---
> > > > > fs/squashfs/sqfs.c | 5 +++--
> > > > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
> > > > > index 5d9c52af80..6405db4ff3 100644
> > > > > --- a/fs/squashfs/sqfs.c
> > > > > +++ b/fs/squashfs/sqfs.c
> > > > > @@ -8,6 +8,7 @@
> > > > > */
> > > > >
> > > > > #include
> > > > > +#include
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > @@ -1440,7 +1441,7 @@ int sqfs_read(const char *filename, void *buf,
> > > > > loff_t offset, loff_t len,
> > > > > }
> > > > >
> > > > > for (j = 0; j < datablk_count; j++) {
> > > > > - start = data_offset / ctxt.cur_dev->blksz;
> > > > > + start = do_div(data_offset, ctxt.cur_dev->blksz);
> > > > > table_size = SQFS_BLOCK_SIZE(finfo.blk_sizes[j]);
> > > > > table_offset = data_offset - (start *
> > > > > ctxt.cur_dev->blksz);
> > > > > n_blks = DIV_ROUND_UP(table_size + table_offset,
> > > > > @@ -1516,7 +1517,7 @@ int sqfs_read(const char *filename, void *buf,
> > > > > loff_t offset, loff_t len,
> > > > > goto out;
> > > > > }
> > > > >
> > > > > - start = frag_entry.start / ctxt.cur_dev->blksz;
> > > > > + start = do_div(frag_entry.start, ctxt.cur_dev->blksz);
> > > > > table_size = SQFS_BLOCK_SIZE(frag_entry.size);
> > > > > table_offset = frag_entry.start - (start * ctxt.cur_dev->blksz);
> > > > > n_blks = DIV_ROUND_UP(table_size + table_offset,
> > > > > ctxt.cur_dev->blksz);
> > > >
> > > > Adding maintainers...
> > >
> > > I guess that's a correct fix, so
> > >
> > > Reviewed-by: Miquel Raynal
> > >
> > > Thanks,
> > > Miquèl
> >
> > Hello! do_div() macro modifies its first argument. It is correct?
> > Because previous code did not modify anything.
>
> * The semantics of do_div() are:
> *
> * u32 do_div(u64 *n, u32 base)
> * {
> *u32 remainder = *n % base;
> **n = *n / base;
> *return remainder;
> * }
>
> And this patch replaced:
>
> start = data_offset / ctxt.cur_dev->blksz;
>
> by:
>
> start = do_div(data_offset, ctxt.cur_dev->blksz);
>
> which expands to:
>
> start = data_offset % ctxt.cur_dev->blksz;
> data_offset = data_offset / ctxt.cur_dev->blksz;
>
> Which is wrong as it calculates something totally different.
>
> So this patch is incorrect.
Hi Pali,
Yes I agree, I got tricked by some wrong cache from Yocto :/
I have tried lldiv(), and that works on our x86 target.
Do you have an opinion on that?
Or do you have another idea to avoid the
"undefined reference to `__udivmoddi4'" error?
/Sean
[PATCH] fs/squashfs: use do_div function for math
From: Sean Nyekjaer
When compling for x86:
ld.bfd: fs/squashfs/sqfs.o: in function `sqfs_read':
u-boot/fs/squashfs/sqfs.c:1443: undefined reference to `__udivmoddi4'
ld.bfd: u-boot/fs/squashfs/sqfs.c:1521: undefined reference to `__udivmoddi4'
Signed-off-by: Sean Nyekjaer
---
fs/squashfs/sqfs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
index 5d9c52af80..6405db4ff3 100644
--- a/fs/squashfs/sqfs.c
+++ b/fs/squashfs/sqfs.c
@@ -8,6 +8,7 @@
*/
#include
+#include
#include
#include
#include
@@ -1440,7 +1441,7 @@ int sqfs_read(const char *filename, void *buf, loff_t
offset, loff_t len,
}
for (j = 0; j < datablk_count; j++) {
- start = data_offset / ctxt.cur_dev->blksz;
+ start = do_div(data_offset, ctxt.cur_dev->blksz);
table_size = SQFS_BLOCK_SIZE(finfo.blk_sizes[j]);
table_offset = data_offset - (start * ctxt.cur_dev->blksz);
n_blks = DIV_ROUND_UP(table_size + table_offset,
@@ -1516,7 +1517,7 @@ int sqfs_read(const char *filename, void *buf, loff_t
offset, loff_t len,
goto out;
}
- start = frag_entry.start / ctxt.cur_dev->blksz;
+ start = do_div(frag_entry.start, ctxt.cur_dev->blksz);
table_size = SQFS_BLOCK_SIZE(frag_entry.size);
table_offset = frag_entry.start - (start * ctxt.cur_dev->blksz);
n_blks = DIV_ROUND_UP(table_size + table_offset, ctxt.cur_dev->blksz);
--
2.35.1
SquashFS not compiling due to missing __udivmoddi4 (x86)
Hi, I'm trying to build Squashfs for u-boot for x86. Looks like we are missing some libgcc helper function. ld.bfd: fs/squashfs/sqfs.o: in function `sqfs_read': /home/sean/development/siemens/u-boot/fs/squashfs/sqfs.c:1443: undefined reference to `__udivmoddi4' ld.bfd: /home/sean/development/siemens/u-boot/fs/squashfs/sqfs.c:1521: undefined reference to `__udivmoddi4' I can fix this by adding the function from arch/arc/lib/libgcc2.c to arch/x86/lib/div64.c, but I'm not sure it's the right way to do it :) Any hints? /Sean
Re: [PATCH v2] mtd: gpmi: fix the bch setting backward compatible issue
Hi Han, On Wed, Mar 23, 2022 at 04:24:54PM -0500, Han Xu wrote: > Previous u-boot code changed the default bch setting behavior and caused > backward compatible issue. This fix choose the legacy bch geometry back > again as the default option. If the minimum ecc strength that NAND chips > required need to be chosen, it can be enabled by either adding DT flag > "fsl,use-minimum-ecc" or CONFIG_NAND_MXS_USE_MINIMUM_ECC in configs. The > unused flag "fsl,legacy-bch-geometry" get removed. > > Fixes: 51cdf83eea mtd: gpmi: provide the option to use legacy bch geometry > Fixes: 616f03daba mtd: gpmi: change the BCH layout setting for large oob NAND > Tested-by: Tim Harvey Tested-by: Sean Nyekjaer > Signed-off-by: Han Xu > > Changes in v2: > -- change the commit log about backward compatible issue is in u-boot > -- removed the unused flag > -- add fixes and test tag > --- Changes ^ should be below the --- in order to be skipped from the commit msg. > drivers/mtd/nand/raw/mxs_nand.c| 71 ++ > drivers/mtd/nand/raw/mxs_nand_dt.c | 2 - > include/mxs_nand.h | 2 - > 3 files changed, 62 insertions(+), 13 deletions(-) > [ ... ] I have only tested this with the legacy option. It seem to work :) Thanks for finally fixing the Linux vs. U-boot unalignment. /Sean
Re: [PATCH] mtd: gpmi: fix the gpmi bch setting unalignment issue
Hi Han, On Mon, Mar 21, 2022 at 03:18:34PM -0500, Han Xu wrote: > The code change fixed the kernel gpmi bch setting not aligned with > u-boot settings issue. It still uses the legacy bch geometry as the AFAIK there is no merged changes in the kernel regarding this. The breaking change was done in u-boot. > default option. If users need to choose the minimum ecc strength that > NAND chips required, it can be enabled by either adding DT flag > "fsl,use-minimum-ecc" or CONFIG_NAND_MXS_USE_MINIMUM_ECC in configs. Cool, then remember to remove the non used "fsl,legacy-bch-geometry" option. > > Fixes: 51cdf83eea mtd: gpmi: provide the option to use legacy bch geometry > Signed-off-by: Han Xu I will have time to test this on thursday... /Sean
Re: GPMI NAND Regression on i.MX6S
Hi Frieder, On Thu, Mar 17, 2022 at 01:59:07PM +0100, Frieder Schrempf wrote: > Am 17.03.22 um 09:06 schrieb Frieder Schrempf: > > Hi Tim, > > > > Am 16.03.22 um 17:34 schrieb Tim Harvey: > >> On Wed, Mar 16, 2022 at 7:09 AM Fabio Estevam wrote: > >>> > >>> Adding Han Xu's NXP email on Cc. > >>> > >>> On Mon, Mar 14, 2022 at 10:31 AM Frieder Schrempf > >>> wrote: > > Hello everyone, > > sorry to dig out an old thread, but the below patch which was applied > upstream as 616f03dabacb causes a regression for me when trying to > attach an UBI volume with U-Boot 2022.01 on a board with i.MX6 Solo and > AMD/Spansion parallel NAND. > > The failure looks like this: > > ubi0: attaching mtd2 > ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes > from PEB 0:0, read 64 bytes > ubi0 error: ubi_io_read: error -74 (ECC error) while reading 2048 bytes > from PEB 0:2048, read 2048 bytes > ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes > from PEB 1:0, read 64 bytes > ubi0 error: ubi_io_read: error -74 (ECC error) while reading 2048 bytes > from PEB 1:2048, read 2048 bytes > > The NAND as reported by Linux is: > > nand: device found, Manufacturer ID: 0x01, Chip ID: 0xdc > nand: AMD/Spansion S34ML04G1 > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 > > A different revision of the same board with a different NAND from > manufacturer ESMT doesn't show the issue: > > nand: device found, Manufacturer ID: 0xc8, Chip ID: 0xdc > nand: ESMT NAND 512MiB 3,3V 8-bit > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 > > When I revert the mentioned commit (see patch here: [1]), the UBI boot > starts working again. > > Does anyone know what the problem is and how to properly solve it? > > Thanks for any help! > Frieder > > [1] > https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fzerobin.net%2F%3F57a57a322bbdcf3c%23rZa3vHlWi%2BRxtRomoljtrngqWwiv6v4Js%2F2LNfdV10o%3Ddata=04%7C01%7Cfrieder.schrempf%40kontron.de%7C978979eaf1fa48171bab08da076aea84%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637830453031595997%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=NGl%2FrFnffV2oC90js0aHyTvoZjnrzW%2FD830lOnR4TbQ%3Dreserved=0 > > >> > >> Frieder, > >> > >> I see the same issue here with IMX6Q/DL GPMI NAND. > >> > >> If I re-flash the ubi within U-Boot (tftpboot $loadaddr rootfs.ubi && > >> nand erase.part rootfs && nand write $loadaddr rootfs $filesize) I > >> find that U-Boot can attach and mount the ubi fine but Linux will have > >> issues > > > > Interesting! This sounds like U-Boot and Linux somehow diverge in how > > they handle the ECC data in OOB. I'm pretty confident that Linux does > > things "correctly" and U-Boot should match what Linux does in this case. > > > > Does the patch (revert of 616f03dabacb) I mentioned before "solve" the > > issue for your case, too? > > > > @Han, Ye, Peng: As you signed-off the mentioned commit, do you have any > > ideas for a fix? > > So the proper fix seems to be to revert to the "legacy" BCH layout that > is used by Linux. Sean already tried to get this fixed almost a year ago > [1] but Han turned the change down in favor of changing the layout on > the kernel side. But this series [2] never made it upstream and it > doesn't look like it will anytime soon. > > I will try to resurrect Sean's fix. > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210510100043.449294-1-s...@geanix.com/ > [2] > https://patchwork.ozlabs.org/project/linux-mtd/patch/20210522205136.19465-1-han...@nxp.com/ > Thanks for bringing this up again. I have only had time to send Han a ping a few times. I would still prefer that we added the new(correct) metod as a option. /Sean
Re: [EXT] [PATCH] mtd: mxs_nand: default to legacy bch and rename to modern bch option
On 13/05/2021 22.02, han.xu wrote:
> On 21/05/11 07:08AM, Sean Nyekjaer wrote:
>> Caution: EXT Email
>>
>> On 11/05/2021 04.49, han.xu wrote:
>>> On 21/05/10 12:00PM, Sean Nyekjaer wrote:
>>>> Caution: EXT Email
>>>>
>>>> Linux kernel defaults to use legacy bch setting, this was creating a
>>>> mismatch between U-boot and Linux default settings.
>>> Kernel uses the NAND chip specified minimum ecc strength and steps by
>>> default
>>> not the legacy bch setting, unless users enable it in DT file.
>>>
>>
>> Hi,
>>
>> Adding, mtd-list and Miquel
>>
>> With u-boot dtb:
>> {
>> pinctrl-names = "default";
>> pinctrl-0 = <_gpmi_nand1>;
>> compatible = "fsl,imx7d-gpmi-nand";
>> nand-on-flash-bbt;
>> status = "okay";
>> };
>>
>> With linux dtb (mainline 5.10):
>> {
>> pinctrl-names = "default";
>> pinctrl-0 = <_gpmi_nand1>;
>> nand-on-flash-bbt;
>> status = "okay";
>> };
>>
>> U-boot prior to commit 51cdf83eea selected 18 bit ECC, after that commit it
>> selects 8 bits.
>> With legacy option it selects 18.
>> Linux is selecting 18 bits ;) So now we have a mismatch.
>>
>> I have been searching for the legacy option in the mainline kernel can't
>> find it ;)
>> Please show me where it is (is it in the NXP fork?)
>
> You are right, it's only fixed in NXP fork, with kernel driver modification.
> We
> prefer the current u-boot bch geometry, so I will send out a kernel patch to
> make them align.
>
Any progress on this?
I see your patch in:
https://source.codeaurora.org/external/imx/linux-imx/commit/drivers/mtd/nand/raw/gpmi-nand?h=imx_5.4.70_2.3.0=ae980dccc6189956fab047958ad0a70ec4951439
But I can't find the option for selecting legacy mode in the devicetree...
/Sean
Re: [EXT] [PATCH] mtd: mxs_nand: default to legacy bch and rename to modern bch option
On 11/05/2021 04.49, han.xu wrote:
> On 21/05/10 12:00PM, Sean Nyekjaer wrote:
>> Caution: EXT Email
>>
>> Linux kernel defaults to use legacy bch setting, this was creating a
>> mismatch between U-boot and Linux default settings.
> Kernel uses the NAND chip specified minimum ecc strength and steps by default
> not the legacy bch setting, unless users enable it in DT file.
>
Hi,
Adding, mtd-list and Miquel
With u-boot dtb:
{
pinctrl-names = "default";
pinctrl-0 = <_gpmi_nand1>;
compatible = "fsl,imx7d-gpmi-nand";
nand-on-flash-bbt;
status = "okay";
};
With linux dtb (mainline 5.10):
{
pinctrl-names = "default";
pinctrl-0 = <_gpmi_nand1>;
nand-on-flash-bbt;
status = "okay";
};
U-boot prior to commit 51cdf83eea selected 18 bit ECC, after that commit it
selects 8 bits.
With legacy option it selects 18.
Linux is selecting 18 bits ;) So now we have a mismatch.
I have been searching for the legacy option in the mainline kernel can't find
it ;)
Please show me where it is (is it in the NXP fork?)
/Sean
[PATCH] mtd: mxs_nand: default to legacy bch and rename to modern bch option
Linux kernel defaults to use legacy bch setting, this was creating a
mismatch between U-boot and Linux default settings.
Fixes: 51cdf83eea ("mtd: gpmi: provide the option to use legacy bch geometry")
Signed-off-by: Sean Nyekjaer
---
drivers/mtd/nand/raw/mxs_nand.c| 2 +-
drivers/mtd/nand/raw/mxs_nand_dt.c | 2 +-
include/mxs_nand.h | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/raw/mxs_nand.c b/drivers/mtd/nand/raw/mxs_nand.c
index e6bbfac4d6..49795e20d2 100644
--- a/drivers/mtd/nand/raw/mxs_nand.c
+++ b/drivers/mtd/nand/raw/mxs_nand.c
@@ -1119,7 +1119,7 @@ static int mxs_nand_set_geometry(struct mtd_info *mtd,
struct bch_geometry *geo)
}
if ((!(chip->ecc_strength_ds > 0 && chip->ecc_step_ds > 0) &&
-mtd->oobsize < 1024) || nand_info->legacy_bch_geometry) {
+mtd->oobsize < 1024) || !nand_info->modern_bch_geometry) {
dev_warn(mtd->dev, "use legacy bch geometry\n");
return mxs_nand_legacy_calc_ecc_layout(geo, mtd);
}
diff --git a/drivers/mtd/nand/raw/mxs_nand_dt.c
b/drivers/mtd/nand/raw/mxs_nand_dt.c
index 878796d555..bbb7396324 100644
--- a/drivers/mtd/nand/raw/mxs_nand_dt.c
+++ b/drivers/mtd/nand/raw/mxs_nand_dt.c
@@ -92,7 +92,7 @@ static int mxs_nand_dt_probe(struct udevice *dev)
info->use_minimum_ecc = dev_read_bool(dev, "fsl,use-minimum-ecc");
- info->legacy_bch_geometry = dev_read_bool(dev,
"fsl,legacy-bch-geometry");
+ info->modern_bch_geometry = dev_read_bool(dev,
"fsl,modern-bch-geometry");
if (IS_ENABLED(CONFIG_CLK) && IS_ENABLED(CONFIG_IMX8)) {
/* Assigned clock already set clock */
diff --git a/include/mxs_nand.h b/include/mxs_nand.h
index c0cefaca90..7e254d6b31 100644
--- a/include/mxs_nand.h
+++ b/include/mxs_nand.h
@@ -43,8 +43,8 @@ struct mxs_nand_info {
struct udevice *dev;
unsigned intmax_ecc_strength_supported;
booluse_minimum_ecc;
- /* legacy bch geometry flag */
- boollegacy_bch_geometry;
+ /* modern bch geometry flag */
+ boolmodern_bch_geometry;
int cur_chip;
uint32_tcmd_queue_len;
--
2.31.0
Re: gpmi-nand ecc
On 19/04/2021 09.32, Miquel Raynal wrote: Hi Sean, + u-boot ML Sean Nyekjaer wrote on Wed, 14 Apr 2021 15:13:39 +0200: Hi, I have two boards with a iMX6ULL SoC one attached to a Micron NAND flash (MT29F4G08ABAFAWP) and one a Toshiba (TC58BVG2S0HTAI0). After updating the boards from u-boot 2018.07 -> 2020.01, the Micron fitted boards is having ECC problems(in u-boot). U-boot 2018.07 selects ecc_strength to 18. U-boot 2020.01 selects ecc_strength to 8, but if I hardcode u-boot to run the mxs_nand_legacy_calc_ecc_layout() it selects 18 bits. The Toshiba boards always selects 8 bit ecc_strength so they have no issues. The kernel driver (gpmi-nand.c) seems to also use the legacy method (Resulting 18 bits in ecc strength for the Micron NAND). In common_nfc_set_geometry(): Both chip->ecc.strength and chip->ecc.size are 0. I would expect ecc.strength to be set to 8, earlier but cannot find the spot where it should be set. Is the gpmi-nand driver missing a call to nand_ecc_choose_conf()? Maybe we need a legacy option for the kernel like u-boot. We have +10K boards deployed so it's not so easy to switch from 18 -> 8 bits. I can explicit fix this in U-boot by forcing the legacy mode via a dt flag, but the gut feeling says this will come back to haunt us :) /Sean I honestly don't know about such issue on U-Boot side, maybe you can try to be more specific on what commit broke the logic for you as there are not so many of them between the two versions: $ git l v2018.07..v2020.01 -- drivers/mtd/nand/raw/mxs_nand.c 1eb69ae4985 common: Move ARM cache operations out of common.h 9ab5f221a5e nand: mxs_nand: add API for switching different BCH layouts 1d43e24b946 i.MX6: nand: add nandbcb command for imx 1001502545f CONFIG_SPL_SYS_[DI]CACHE_OFF: add 04568bd0b6d MTD: nand: mxs_nand: Allow driver to auto setup ECC in SPL 5645df9e00a MTD: NAND: mxs_nand_init_dma: Make mxs_nand_init_dma static 5ae585ba3a8 MTD: mxs_nand: Fix BCH read timeout error on boards requiring ECC a430fa06a4a mtd: move NAND files into a raw/ subdirectory Hi Miquel, Thanks for CC'ing the u-boot list :) commit 616f03dabacb6c500e8a7ceb920cd08554c9fcae Author: Ye Li Date: Mon May 4 22:08:50 2020 +0800 mtd: gpmi: change the BCH layout setting for large oob NAND This commit ^^ introduced the legacy function that was the "primary" before. Guess we can say, that u-boot broke compatibility with the kernel. I have fixed my setup by enabling the legacy option via dt, in u-boot. /Sean
Re: [U-Boot] [RFC] cmd: add bootslot command to select/boot slot based on boot counts
On 13/07/2018 14.34, Martin Hundebøll wrote:
The existing bootcount feature is targeted systems with a primary, and a
rescue boot setup, where the number of boot tries to the primary boot is
tracked. If the number exceeds the limit, the alternative/rescue is
booted.
This patch adds support for a more sophisticated setup, where more than
two boot slots can exist, and the order of slots can be configured.
The 'bootcommand' command reads the configured slots (and their
priority/order) from a configured environment variable ("bootslots" by
default). For each conifgured slot, a remaining boot count is maintained
in an evnironment variable ("bootcount_" by default). If the first
boot slot has positive boot count, it is booted using the slot specific
boot command ("bootcmd_" by default). Otherwise the next slot is
checked.
An example environment when using the bootslot command with two slots
("a" and "b"):
bootslots=a b
bootcount_a=3
bootcount_b=3
bootcmd_a=setenv bootargs $bootargs root=/dev/mmcblk0p1; booti $loadaddr
bootcmd_b=setenv bootargs $bootargs root=/dev/mmcblk0p2; booti $loadaddr
Once linux is booted, it resets the bootcount variable for the booted
slot using "fw_setenv":
fw_setenv bootcount_a 3
When the non-booted slot is updated, the order is updated by setting the
bootslots variable with "fw_setenv":
fw_setenv bootslots=b a
Signed-off-by: Martin Hundebøll
Tested-by: Sean Nyekjaer
We have used this for the past 1.5 years.
Will you post this as a patch?
/Sean
Re: [U-Boot] [PATCH] arm: stm32mp1: deploy spl in root folder
On 28.01.2019 11.13, Patrick Delaunay wrote: Update generation of spl binaries - continue to generate all SPL files in spl sub-directory - copy in root folder the needed file for user (YOCTO, buildroot): u-boot-spl.stm32 Signed-off-by: Patrick Delaunay --- Hi, This patch update http://patchwork.ozlabs.org/patch/1020706 already merged in u-boot/master. In fact, it is my v2 proposal to avoid to change the current behavior: I prefer to keep all the spl generation in spl directory but I agree to copy the generated file in root folder: it can be easier for end-user. This patch avoid to break current behavior, and current upstream effort of stm32mp1 bsp in YOCTO. Patrick Just ask Tom to revert the change or have him remove the commit before pushing :-) /Sean ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCHv1] arm: stm32mp1: deploy spl in root folder
Hi Patrick I checked with Patrice the other boards and most of the cases the modified spl binay (u-boot-spl.bin/ u-boot-spl.ais / u-boot-spl.img / u-boot-spl.pbl / u-boot-spl.gph) are generated in spl directory. So I done the same for u-boot-spl.stm32. All the NXP iMX6 variant boards deploy the SPL to the root folder :-) The only case where it is populated in u-boot directory it is when it is concatenated with u-boot image (so the generated files depends on u-boot.bin) , but is not the case for us. Perhaps I miss so other cases ? Moreover I am working with YOCTO and using a sub-directory is not issue with latest version and with patch in poky/meta/recipes-bsp/u-boot/u-boot.inc -- commit c6ab82882cd49be5510d1f8c967d0dc2da2490c2 Author: Nathan Rossi Fri Mar 25 10:07:12 2016 Committer: Richard Purdie Mon Mar 28 16:55:48 2016 u-boot.inc: Add sub-dir support for SPL_BINARY Add support for the SPL_BINARY variable to handle sub directories. In some cases the SPL binary that needs to be deployed is only built to the spl/ directory in U-Boot. So that a sub directory can be specified in the SPL_BINARY variable, handle the case so that the deploy code uses the basename of the path specified in SPL_BINARY. (From OE-Core rev: eb90d1c8fc7b82ca2593185930b3bf175f40ae13) Signed-off-by: Nathan Rossi Signed-off-by: Richard Purdie -- So, I don't understood the blocking point, and other platform do the same (the reason of the patch). Even I agree that copy the generated u-boot-spl.stm32 in u-boot build directory could be easier (for BUILDROOT ?), I want keep the file spl/u-boot-spl.stm32 to avoid to break the current upstream effort of YOCTO BSP support for STM32MP157 board (which expect spl file in spl directory). I got a new job (therefore new email address), so i don't have access to the Yocto source where I got into troubles with this. If i recall correctly we where using the SPI_BINARY variable when deploying the SPL and we should have been using the SPL_BINARYNAME. So no need for this patch. /Sean ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] cmd: fastboot: handle watchdog while waiting for fastboot commands.
Watchdog is not handled while waiting for fastboot commands. Tested on a i.MX6 ULL EVK board. Signed-off-by: Sean Nyekjaer --- cmd/fastboot.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/cmd/fastboot.c b/cmd/fastboot.c index e6ae0570d5..f520d907ff 100644 --- a/cmd/fastboot.c +++ b/cmd/fastboot.c @@ -13,6 +13,7 @@ #include #include #include +#include static int do_fastboot_udp(int argc, char *const argv[], uintptr_t buf_addr, size_t buf_size) @@ -69,6 +70,7 @@ static int do_fastboot_usb(int argc, char *const argv[], break; if (ctrlc()) break; + WATCHDOG_RESET(); usb_gadget_handle_interrupts(controller_index); } -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCHv1] arm: stm32mp1: deploy spl in root folder
Hi Patrice What about keeping spl binary in /spl directory and copying it in root directory instead ? It would avoid us to update our environment regarding your proposal. You didn't answer to the above question. Patrice Sorry. I really don't care how it's done :-) But the I think the best solution is the I one posted, it's better to align things with other boards in u-boot. /Sean ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCHv1] arm: stm32mp1: deploy spl in root folder
ping On 04.01.2019 16.18, Patrice CHOTARD wrote: Hi Sean +Patrick Delaunay What about keeping spl binary in /spl directory and copying it in root directory instead ? It would avoid us to update our environment regarding your proposal. Just a minor remark, don't forget to add maintainers in copy when sending your patch. Either use ./scripts/get_maintainer.pl which give you the people list to send your patch to or patman which adds automatically right people in cc. For example ./scripts/get_maintainer.pl arch/arm/mach-stm32mp/config.mk gives you : Patrick Delaunay (maintainer:ARM STM STM32MP) Christophe Kerello (maintainer:ARM STM STM32MP) Patrice Chotard (maintainer:ARM STM STM32MP) Albert Aribaud (maintainer:ARM) uboot-st...@st-md-mailman.stormreply.com (moderated list:ARM STM STM32MP) u-boot@lists.denx.de (open list) Patrice On 1/4/19 12:37 PM, Sean Nyekjær wrote: Deploy u-boot-spl.stm32 binary in u-boot root folder like the rest of the boards. This makes it more streamlined when building in Yocto, Buildroot etc.. Signed-off-by: Sean Nyekjaer --- arch/arm/mach-stm32mp/config.mk | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-stm32mp/config.mk b/arch/arm/mach-stm32mp/config.mk index cde5850e934..124729cd839 100644 --- a/arch/arm/mach-stm32mp/config.mk +++ b/arch/arm/mach-stm32mp/config.mk @@ -3,11 +3,11 @@ # Copyright (C) 2018, STMicroelectronics - All Rights Reserved # -ALL-$(CONFIG_SPL_BUILD) += spl/u-boot-spl.stm32 +ALL-$(CONFIG_SPL_BUILD) += u-boot-spl.stm32 MKIMAGEFLAGS_u-boot-spl.stm32 = -T stm32image -a $(CONFIG_SPL_TEXT_BASE) -e $(CONFIG_SPL_TEXT_BASE) -spl/u-boot-spl.stm32: MKIMAGEOUTPUT = spl/u-boot-spl.stm32.log +u-boot-spl.stm32: MKIMAGEOUTPUT = u-boot-spl.stm32.log -spl/u-boot-spl.stm32: spl/u-boot-spl.bin FORCE +u-boot-spl.stm32: spl/u-boot-spl.bin FORCE $(call if_changed,mkimage) -- Kind regards, Sean Nyekjær Embedded Linux Consultant +45 42427326 s...@geanix.com Geanix IVS https://geanix.com DK39600706 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] imx: mx6: add is_boot_from_usb define
This enables us to detect if the i.MX6 SoC
is booting from USB.
Signed-off-by: Sean Nyekjaer <sean.nyekj...@prevas.dk>
---
arch/arm/include/asm/arch-mx6/imx-regs.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index 095eb74195..10da611968 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -998,4 +998,11 @@ struct pwm_regs {
u32 cnr;
};
#endif /* __ASSEMBLER__*/
+
+/*
+ * If ROM fail back to USB recover mode, USBPH0_PWD will be clear to use USB
+ * If boot from the other mode, USB0_PWD will keep reset value
+ */
+#define is_boot_from_usb(void) (!(readl(USB_PHY0_BASE_ADDR) & (1 << 20)))
+
#endif /* __ASM_ARCH_MX6_IMX_REGS_H__ */
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] sf: Add Spansion s25fl208k entry
Add entry for Spansion s25fl208k part.
Signed-off-by: Sean Nyekjaer <sean.nyekj...@prevas.dk>
---
drivers/mtd/spi/spi_flash_ids.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi/spi_flash_ids.c b/drivers/mtd/spi/spi_flash_ids.c
index b789219e4e..8d07d7ad7f 100644
--- a/drivers/mtd/spi/spi_flash_ids.c
+++ b/drivers/mtd/spi/spi_flash_ids.c
@@ -94,6 +94,7 @@ const struct spi_flash_info spi_flash_ids[] = {
{"s25fl016a", INFO(0x010214, 0x0, 64 * 1024,32, 0) },
{"s25fl032a", INFO(0x010215, 0x0, 64 * 1024,64, 0) },
{"s25fl064a", INFO(0x010216, 0x0, 64 * 1024, 128, 0) },
+ {"s25fl208k", INFO(0x014014, 0x0, 64 * 1024,16, 0) },
{"s25fl116k", INFO(0x014015, 0x0, 64 * 1024,32, 0) },
{"s25fl164k", INFO(0x014017, 0x0140, 64 * 1024, 128, 0) },
{"s25fl128p_256k", INFO(0x012018, 0x0300, 256 * 1024,64, RD_FULL |
WR_QPP) },
--
2.16.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] Allow providing default environment from file
On 24-01-2018 10:55, Rasmus Villemoes wrote:
It is sometimes useful to be able to define the entire default
environment in an external file. This implements a Kconfig option for
allowing that.
It is somewhat annoying to have two visible Kconfig options; it would
probably be more user-friendly to just have the string option (with
empty string obviously meaning not to use this feature). But then we'd
also need a hidden CONFIG that we can use in the #ifdef in
env_default.h, and I don't think one can set a def_bool based on
whether a string-valued config is empty or not.
I've tried to make the accepted format the same as the one the
mkenvimage tool accepts. I have no idea how portable the sed script
implementing the "allow embedded newlines in values" is. Nor do I know
if one can expect xxd to be available.
Signed-off-by: Rasmus Villemoes <rasmus.villem...@prevas.dk>
Tested-by: Sean Nyekjaer <sean.nyekj...@prevas.dk>
---
Makefile | 16
env/Kconfig | 18 ++
include/env_default.h | 4
3 files changed, 38 insertions(+)
diff --git a/Makefile b/Makefile
index 4981a2ed6f..e5ba5213fd 100644
--- a/Makefile
+++ b/Makefile
@@ -423,6 +423,7 @@ endif
version_h := include/generated/version_autogenerated.h
timestamp_h := include/generated/timestamp_autogenerated.h
+defaultenv_h := include/generated/defaultenv_autogenerated.h
no-dot-config-targets := clean clobber mrproper distclean \
help %docs check% coccicheck \
@@ -1366,6 +1367,10 @@ ifeq ($(wildcard $(LDSCRIPT)),)
@/bin/false
endif
+ifeq ($(CONFIG_DEFAULT_ENV_FROM_FILE),y)
+prepare1: $(defaultenv_h)
+endif
+
archprepare: prepare1 scripts_basic
prepare0: archprepare FORCE
@@ -1413,12 +1418,23 @@ define filechk_timestamp.h
fi)
endef
+define filechk_defaultenv.h
+ (grep -v '^#' | \
+grep -v '^$$' | \
+tr '\n' '\0' | \
+sed -e 's/\\\x0/\n/' | \
+xxd -i ; echo ", 0x00" ; )
+endef
+
$(version_h): include/config/uboot.release FORCE
$(call filechk,version.h)
$(timestamp_h): $(srctree)/Makefile FORCE
$(call filechk,timestamp.h)
+$(defaultenv_h): $(CONFIG_DEFAULT_ENV_FILE:"%"=%) FORCE
+ $(call filechk,defaultenv.h)
+
# ---
quiet_cmd_cpp_lds = LDS $@
cmd_cpp_lds = $(CPP) -Wp,-MD,$(depfile) $(cpp_flags) $(LDPPFLAGS) \
diff --git a/env/Kconfig b/env/Kconfig
index a24370786b..1baebd743b 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -482,4 +482,22 @@ config ENV_SIZE
endif
+config DEFAULT_ENV_FROM_FILE
+ bool "Create default environment from file"
+ help
+ Normally, the default environment is automatically generated
+ based on the settings of various CONFIG_* options, as well
+ as the CONFIG_EXTRA_ENV_SETTINGS. By selecting this option,
+ you can instead define the entire default environment in an
+ external file.
+
+config DEFAULT_ENV_FILE
+ string "Path to default environment file"
+ depends on DEFAULT_ENV_FROM_FILE
+ help
+ The path containing the default environment. The format is
+ the same as accepted by the mkenvimage tool: lines
+ containing key=value pairs, blank lines and lines beginning
+ with # are ignored.
+
endmenu
diff --git a/include/env_default.h b/include/env_default.h
index b574345af2..656d202cc7 100644
--- a/include/env_default.h
+++ b/include/env_default.h
@@ -22,6 +22,7 @@ static char default_environment[] = {
#else
const uchar default_environment[] = {
#endif
+#ifndef CONFIG_DEFAULT_ENV_FROM_FILE
#ifdefCONFIG_ENV_CALLBACK_LIST_DEFAULT
ENV_CALLBACK_VAR "=" CONFIG_ENV_CALLBACK_LIST_DEFAULT "\0"
#endif
@@ -108,6 +109,9 @@ const uchar default_environment[] = {
CONFIG_EXTRA_ENV_SETTINGS
#endif
"\0"
+#else /* CONFIG_DEFAULT_ENV_FROM_FILE */
+#include "generated/defaultenv_autogenerated.h"
+#endif
#ifdef DEFAULT_ENV_INSTANCE_EMBEDDED
}
#endif
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mtd/spi: fix block count for is25lq040b
This spi-nor is 4Mbit/512KB
Fixes: b4fbcbc5a5 ("mtd/spi: add support for is25lq040b")
Signed-off-by: Sean Nyekjaer <sean.nyekj...@prevas.dk>
---
drivers/mtd/spi/spi_flash_ids.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/spi_flash_ids.c b/drivers/mtd/spi/spi_flash_ids.c
index 32c6123a03..262d81e98d 100644
--- a/drivers/mtd/spi/spi_flash_ids.c
+++ b/drivers/mtd/spi/spi_flash_ids.c
@@ -67,10 +67,10 @@ const struct spi_flash_info spi_flash_ids[] = {
{"gd25lq32", INFO(0xc86016, 0x0, 64 * 1024,64, SECT_4K) },
#endif
#ifdef CONFIG_SPI_FLASH_ISSI /* ISSI */
+ {"is25lq040b", INFO(0x9d4013, 0x0, 64 * 1024,8, 0) },
{"is25lp032", INFO(0x9d6016, 0x0, 64 * 1024,64, 0) },
{"is25lp064", INFO(0x9d6017, 0x0, 64 * 1024, 128, 0) },
{"is25lp128", INFO(0x9d6018, 0x0, 64 * 1024, 256, 0) },
- {"is25lq040b", INFO(0x9d4013, 0x0, 64 * 1024,64, 0) },
#endif
#ifdef CONFIG_SPI_FLASH_MACRONIX /* MACRONIX */
{"mx25l2006e", INFO(0xc22012, 0x0, 64 * 1024, 4, 0) },
--
2.15.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: mvebu: enable boot from NAND
Check if we are booting from NAND and let the bootrom
continue to load the rest of the bootloader
Signed-off-by: Sean Nyekjaer <sean.nyekj...@prevas.dk>
---
arch/arm/mach-mvebu/include/mach/soc.h | 1 +
arch/arm/mach-mvebu/spl.c | 16 ++--
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h
b/arch/arm/mach-mvebu/include/mach/soc.h
index 4f81285bb5..1a06a1e876 100644
--- a/arch/arm/mach-mvebu/include/mach/soc.h
+++ b/arch/arm/mach-mvebu/include/mach/soc.h
@@ -147,6 +147,7 @@
#define BOOT_DEV_SEL_OFFS 4
#define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
+#define BOOT_FROM_NAND 0x0A
#define BOOT_FROM_UART 0x28
#define BOOT_FROM_UART_ALT 0x3f
#define BOOT_FROM_SPI 0x32
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 2fd6c62589..d16a62d2dd 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -45,6 +45,10 @@ static u32 get_boot_device(void)
boot_device = (val & BOOT_DEV_SEL_MASK) >> BOOT_DEV_SEL_OFFS;
debug("SAR_REG=0x%08x boot_device=0x%x\n", val, boot_device);
switch (boot_device) {
+#if defined(CONFIG_ARMADA_38X)
+ case BOOT_FROM_NAND:
+ return BOOT_DEVICE_NAND;
+#endif
#ifdef CONFIG_SPL_MMC_SUPPORT
case BOOT_FROM_MMC:
case BOOT_FROM_MMC_ALT:
@@ -128,7 +132,15 @@ void board_init_f(ulong dummy)
* SPL has no chance to receive this information. So we
* need to return to the BootROM to enable this xmodem
* UART download.
+*
+* If booting from NAND lets let the BootROM load the
+* rest of the bootloader.
*/
- if (get_boot_device() == BOOT_DEVICE_UART)
- return_to_bootrom();
+ switch (get_boot_device()) {
+ case BOOT_DEVICE_UART:
+#if defined(CONFIG_ARMADA_38X)
+ case BOOT_DEVICE_NAND:
+#endif
+ return_to_bootrom();
+ }
}
--
2.15.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: mvebu: fix boot from UART when in fallback mode
It's the first 8 bits of the bootrom error register that
contains the boot error/fallback error code. Lets check that
and continue to boot from UART.
Signed-off-by: Sean Nyekjaer <sean.nyekj...@prevas.dk>
---
arch/arm/mach-mvebu/include/mach/soc.h | 6 ++
arch/arm/mach-mvebu/spl.c | 9 +
2 files changed, 15 insertions(+)
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h
b/arch/arm/mach-mvebu/include/mach/soc.h
index 1d302761f0..4f81285bb5 100644
--- a/arch/arm/mach-mvebu/include/mach/soc.h
+++ b/arch/arm/mach-mvebu/include/mach/soc.h
@@ -111,10 +111,16 @@
#define COMPHY_REFCLK_ALIGNMENT(MVEBU_REGISTER(0x182f8))
/* BootROM error register (also includes some status infos) */
+#if defined(CONFIG_ARMADA_38X)
+#define CONFIG_BOOTROM_ERR_REG (MVEBU_REGISTER(0x182d0))
+#define BOOTROM_ERR_MODE_OFFS 0
+#define BOOTROM_ERR_MODE_MASK (0xf << BOOTROM_ERR_MODE_OFFS)
+#else
#define CONFIG_BOOTROM_ERR_REG (MVEBU_REGISTER(0x182d0))
#define BOOTROM_ERR_MODE_OFFS 28
#define BOOTROM_ERR_MODE_MASK (0xf << BOOTROM_ERR_MODE_OFFS)
#define BOOTROM_ERR_MODE_UART 0x6
+#endif
#if defined(CONFIG_ARMADA_375)
/* SAR values for Armada 375 */
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index a72a769f7c..2fd6c62589 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -26,7 +26,16 @@ static u32 get_boot_device(void)
val = readl(CONFIG_BOOTROM_ERR_REG);
boot_device = (val & BOOTROM_ERR_MODE_MASK) >> BOOTROM_ERR_MODE_OFFS;
debug("BOOTROM_REG=0x%08x boot_device=0x%x\n", val, boot_device);
+#if defined(CONFIG_ARMADA_38X)
+ /*
+* If the bootrom error register contains any else than zeros
+* in the first 8 bits it's an error condition. And in that case
+* try to boot from UART.
+*/
+ if (boot_device)
+#else
if (boot_device == BOOTROM_ERR_MODE_UART)
+#endif
return BOOT_DEVICE_UART;
/*
--
2.15.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: mvebu: add nand pins
Signed-off-by: Sean Nyekjaer <sean.nyekj...@prevas.dk>
---
arch/arm/dts/armada-38x.dtsi | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/armada-38x.dtsi b/arch/arm/dts/armada-38x.dtsi
index dc8a1a66c1..5e5a158551 100644
--- a/arch/arm/dts/armada-38x.dtsi
+++ b/arch/arm/dts/armada-38x.dtsi
@@ -258,6 +258,19 @@
marvell,function = "i2c0";
};
+ nand_pins: nand-pins {
+ marvell,pins = "mpp22", "mpp34",
"mpp23", "mpp33",
+ "mpp38", "mpp28",
"mpp40", "mpp42",
+ "mpp35", "mpp36",
"mpp25", "mpp30",
+ "mpp32";
+ marvell,function = "dev";
+ };
+
+ nand_rb: nand-rb {
+ marvell,pins = "mpp41";
+ marvell,function = "nand";
+ };
+
mdio_pins: mdio-pins {
marvell,pins = "mpp4", "mpp5";
marvell,function = "ge";
@@ -545,7 +558,7 @@
};
flash@d {
- compatible = "marvell,armada370-nand";
+ compatible =
"marvell,armada370-nand","marvell,mvebu-pxa3xx-nand";
reg = <0xd 0x54>;
#address-cells = <1>;
#size-cells = <1>;
--
2.15.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] fix: nand: pxa3xx: fix defined but not used warnings
bbt_mirror_descr and bbt_main_descr is defined but not used
when compiling without CONFIG_SYS_NAND_USE_FLASH_BBT set.
Signed-off-by: Sean Nyekjaer <sean.nyekj...@prevas.dk>
---
drivers/mtd/nand/pxa3xx_nand.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index 6ab3c8a25a..cedbb239b6 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -233,6 +233,7 @@ static struct pxa3xx_nand_flash builtin_flash_types[] = {
{ 0xba20, 16, 16, [3] },
};
+#ifdef CONFIG_SYS_NAND_USE_FLASH_BBT
static u8 bbt_pattern[] = {'M', 'V', 'B', 'b', 't', '0' };
static u8 bbt_mirror_pattern[] = {'1', 't', 'b', 'B', 'V', 'M' };
@@ -255,6 +256,7 @@ static struct nand_bbt_descr bbt_mirror_descr = {
.maxblocks = 8, /* Last 8 blocks in each chip */
.pattern = bbt_mirror_pattern
};
+#endif
static struct nand_ecclayout ecc_layout_2KB_bch4bit = {
.eccbytes = 32,
--
2.15.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1] mtd/spi: add support for is25lq040b
Signed-off-by: Sean Nyekjaer <sean.nyekj...@prevas.dk>
---
v1:
1: removed SECT_4K as the chip are supporting 32K and bulk erase
drivers/mtd/spi/spi_flash_ids.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi/spi_flash_ids.c b/drivers/mtd/spi/spi_flash_ids.c
index 13f64e773f..32c6123a03 100644
--- a/drivers/mtd/spi/spi_flash_ids.c
+++ b/drivers/mtd/spi/spi_flash_ids.c
@@ -70,6 +70,7 @@ const struct spi_flash_info spi_flash_ids[] = {
{"is25lp032", INFO(0x9d6016, 0x0, 64 * 1024,64, 0) },
{"is25lp064", INFO(0x9d6017, 0x0, 64 * 1024, 128, 0) },
{"is25lp128", INFO(0x9d6018, 0x0, 64 * 1024, 256, 0) },
+ {"is25lq040b", INFO(0x9d4013, 0x0, 64 * 1024,64, 0) },
#endif
#ifdef CONFIG_SPI_FLASH_MACRONIX /* MACRONIX */
{"mx25l2006e", INFO(0xc22012, 0x0, 64 * 1024, 4, 0) },
--
2.15.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mtd/spi: add support for is25lq040b
Signed-off-by: Sean Nyekjaer <sean.nyekj...@prevas.dk>
---
drivers/mtd/spi/spi_flash_ids.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi/spi_flash_ids.c b/drivers/mtd/spi/spi_flash_ids.c
index 13f64e773f..2cb0196065 100644
--- a/drivers/mtd/spi/spi_flash_ids.c
+++ b/drivers/mtd/spi/spi_flash_ids.c
@@ -70,6 +70,7 @@ const struct spi_flash_info spi_flash_ids[] = {
{"is25lp032", INFO(0x9d6016, 0x0, 64 * 1024,64, 0) },
{"is25lp064", INFO(0x9d6017, 0x0, 64 * 1024, 128, 0) },
{"is25lp128", INFO(0x9d6018, 0x0, 64 * 1024, 256, 0) },
+ {"is25lq040b", INFO(0x9d4013, 0x0, 64 * 1024,64, SECT_4K) },
#endif
#ifdef CONFIG_SPI_FLASH_MACRONIX /* MACRONIX */
{"mx25l2006e", INFO(0xc22012, 0x0, 64 * 1024, 4, 0) },
--
2.14.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH] pcf2127: add watchdog support
Signed-off-by: Sean Nyekjaer <sean.nyekj...@prevas.dk>
---
- I have just noticed that the RTC driver for this device have been merged,
should the watchdog part be included in the rtc driver or standalone?
- The hw_watchdog_reset is called far too often the device here is on i2c,
with what i have done the reset is written every 1s
- What should be the default delay? I have chosen 20?
drivers/watchdog/Kconfig | 11 +++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/pcf2127_wdt.c | 69 ++
include/pcf2127_wdt.h | 3 ++
4 files changed, 84 insertions(+)
create mode 100644 drivers/watchdog/pcf2127_wdt.c
create mode 100644 include/pcf2127_wdt.h
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index e69de29bb2..957f2f3a87 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -0,0 +1,11 @@
+#
+# Watchdog drivers configuration
+#
+
+menu "Watchdog"
+
+config PCF2127_WATCHDOG
+ depends on DM_I2C
+ bool "Enable pcf2127 i2c watchdog"
+
+endmenu
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index a007ae8234..3c573de016 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -15,3 +15,4 @@ obj-$(CONFIG_XILINX_TB_WATCHDOG) += xilinx_tb_wdt.o
obj-$(CONFIG_BFIN_WATCHDOG) += bfin_wdt.o
obj-$(CONFIG_OMAP_WATCHDOG) += omap_wdt.o
obj-$(CONFIG_DESIGNWARE_WATCHDOG) += designware_wdt.o
+obj-$(CONFIG_PCF2127_WATCHDOG) += pcf2127_wdt.o
diff --git a/drivers/watchdog/pcf2127_wdt.c b/drivers/watchdog/pcf2127_wdt.c
new file mode 100644
index 00..f9276e3ea5
--- /dev/null
+++ b/drivers/watchdog/pcf2127_wdt.c
@@ -0,0 +1,69 @@
+#include
+#include
+#include
+#include
+
+#define PCF2127_REG_WDT_CTRL 0x10
+#define PCF2127_REG_WDT_TIM0x11
+
+#define PCF2127_WDT_MODE(wdt_mode) (wdt_mode << 6)
+#define PCF2127_WDT_DISABLED 0b00/* watchdog timer disabled */
+#define PCF2127_WDT_ENABLED_RST0b11/* watchdog timer enabled,
+ rst activated when timeout */
+
+#define PCF2127_WDT_TIMER_SRC(src) (src)
+#define PCF2127_WDT_4096HZ 0b00
+#define PCF2127_WDT_64HZ 0b01
+#define PCF2127_WDT_1HZ0b10
+#define PCF2127_WDT_16mHZ 0b11
+
+#define DCNT 4194304
+
+static uchar timeout = 20;
+static bool wdt_active = false;
+static uint32_t cnt = DCNT-1; /* minus one to ensure the reset is called in
SPL */
+
+int pcf2127_reg_read(const uchar reg, uchar *val)
+{
+ return i2c_read(PCF2127_I2C_ADDR, reg, 1, val, 1);
+}
+
+int pcf2127_reg_write(const uchar reg, uchar val)
+{
+ return i2c_write(PCF2127_I2C_ADDR, reg, 1, , 1);
+}
+
+static int pcf2127_wdt_setup(uchar mode, uchar tim_src)
+{
+ pcf2127_reg_write(PCF2127_REG_WDT_CTRL,
+ PCF2127_WDT_MODE(mode) | PCF2127_WDT_TIMER_SRC(tim_src));
+ return 0;
+}
+
+static int pcf2127_wdt_settimeout(uchar t_out)
+{
+ timeout = (uchar)t_out;
+ pcf2127_reg_write(PCF2127_REG_WDT_TIM, timeout);
+ return 0;
+}
+
+void pcf2127_wdt_enable(void)
+{
+ wdt_active = true;
+}
+
+void hw_watchdog_reset(void)
+{
+ if(wdt_active == true) {
+ if (cnt++ % DCNT == 0)
+ pcf2127_wdt_settimeout(20);
+ }
+}
+
+void hw_watchdog_init(void)
+{
+ if(wdt_active == true) {
+ pcf2127_wdt_setup(PCF2127_WDT_ENABLED_RST, PCF2127_WDT_1HZ);
+ pcf2127_wdt_settimeout(20);
+ }
+}
diff --git a/include/pcf2127_wdt.h b/include/pcf2127_wdt.h
new file mode 100644
index 00..3f293b2348
--- /dev/null
+++ b/include/pcf2127_wdt.h
@@ -0,0 +1,3 @@
+#define PCF2127_I2C_ADDR 0x51
+
+void pcf2127_wdt_enable(void);
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
