On 7 Apr 2015, scottw...@freescale.com wrote:
> On Tue, 2015-04-07 at 10:06 -0400, Bill Pringlemeir wrote:
>> In any case the document has,
>> If the NAND flash supports sub-pages, then what can be done is ECC
>> codes can be calculated on per-sub-page basis, instead of p
On 7 Apr 2015, ste...@agner.ch wrote:
> On 2015-04-07 16:24, Bill Pringlemeir wrote:
>> The OOB patch also significantly decreases UbiFS mounting time in
>> Linux. I load Linux itself via tftp/network and not using u-boot
>> with nand. I guess I should try that.
> I
On 7 Apr 2015, ste...@agner.ch wrote:
> On 2015-04-02 22:30, Bill Pringlemeir wrote:
>> On 2 Apr 2015, ste...@agner.ch wrote:
>> [snip]
>> I also measured 'write performance' with the mtd_speedtest
>> (performing similar patch to the Linux driver) and I s
writes less than a full page, the entire page must be read to
calculate the hw-ecc to be written. I am pretty sure that all
controllers that support hw-ecc will need to do this.
Fwiw,
Bill Pringlemeir.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
nagement in the driver is most simple in it's current form.
The other versions that I found seemed to be buggy to me. However, the
current driver doesn't use all of the NFC SRAM buffer space.
Btw, the READ_OOB is very nice for Linux as well. It is a much faster
mount of UBI/UbiFs as wel
to the Linux driver) and I see no difference. I think a
write benchmark is more appropriate to test this functionality? While
at least it seems that neither read nor write is affected by the
simplification.
Fwiw,
Bill Pringlemeir.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
h speed bus -> DDR
CPU - Low speed bus -> NFC
So, I don't think that this is Vybrid specific. The PPC, ColdFire, etc
will probably have similar issues. DMA has the same limitations as the
CPU, with setup overhead. Of course, you can parallel the main CPU with
DMA but many systems want the NAND to complete synchronously; especially
u-boot.
Fwiw,
Bill Pringlemeir.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
think it would be worthwhile to benchmark without the cache. Or maybe
Stefan already has some numbers? Upper layers doing partial pages will
definitely benefit with the 'cache'; we would also need more DDR memory
as the NFC controller memory is being used as a scratch buffer.
Fwiw,
Bill
the updates since sub-pages were
removed to see if this is worth it. I think it was only ~10-20% in some
benchmark I was doing with the 'caching'.
At least in the small, this is a minimal change that is correct.
Ack-by: Bill Pringlemeir
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
It would probably be nice if the Vybrid followed
the same pattern; but maybe they are different? From reading the RMs
they seem the same.
Regards,
Bill Pringlemeir.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
> On 02/05/2015 03:58 PM, Eric Nelson wrote:
>> The cause of a reset is generally useful, and shouldn't be
>> blindly cleared in the process of displaying it as a part
>> of the boot announcement.
>>
>>
>>
>> diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
>> index 28ccd29..4a5
I favor hex.
I also prefer the hex. I have had very weird values in this register.
For a normal user, we can guess and display a string. Sometimes in the
case of double/triple resets, there can be very strange values. You can
get these when DMA goes crazy (because of bad code or otherwise).
F
r other U-Boot users. Unless you wanted to read this from
an OS? I think both files should behave the same, all else equal.
Fwiw,
Bill Pringlemeir.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
into the middle of an unrolled loop with 'add pc, rn<<2,
#constant'). The size/iteration can be easily tweaked (8/16/32 bytes).
At least in principal *if* there is some size alignment on BSS it is
fairly easy to write some generic ARM to quickly clear the BSS that will
be just as competitive as any ARCH memset version. The above code is
adding about 13 words of code.
Fwiw,
Bill Pringlemeir.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
wlevel_init.S and don't want anyone else to be
using floating point.
... but I am not sure what exactly is going on so maybe it is not a good
fit here?
Fwiw,
Bill Pringlemeir.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
t + * Don't save
>>> anything to stack even if compiled with -O0 + * +
>>> */
>>> +ENTRY(soc_init)
>>> + mov r9, lr
>>> + bl cpu_init_cp15
>>> + mov pc, r9 @
On 21 Jan 2015, hdego...@redhat.com wrote:
> On some SoCs / ARMv7 CPU cores we need to do some setup before
> enabling the icache, etc. Add a soc_init hook with a weak default
> which just calls cpu_init_cp15.
>
> This way different implementations can be provided to do some extra
> work before or
t see this symbol
besides a 'Kconfig'. There are three versions on the Cortex, but the
VBAR (whether secure or not) is the the correct one.
At least in theory, this code if activated should work for the iMx6 and
an override of the 'weak' relocate vectors is not needed.
.infradead.org/pipermail/linux-mtd/2014-July/054712.html
They might be useful to identify injured blocks/pages. Obviously, the
'recovery needed' shows that fixing some partial write/erase is the
issue. If UBI passes a damaged page/info to UbiFS, then it will act on
bad info.
Fwiw,
Bill P
it.
Whatever the issue is, this fixes it for me as well. I would guess that
NAND boot is also not possible or probably anything but serial-download
modes.
Thanks,
Bill Pringlemeir.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
> +
> +/* We boot from the gfxRAM area of the OCRAM. */
> +#define CONFIG_SYS_TEXT_BASE 0x3f408000
> +#define CONFIG_BOARD_SIZE_LIMIT 524288
>
> #define CONFIG_EXTRA_ENV_SETTINGS \
> "script=boot.scr\0" \
Acked-by: Bill Pringlemeir
See also:
http://lists.den
nd why this is more
> right than not just relocating the vectors as v1 did, I see both boot
> to a U-Boot prompt but shouldn't we do a bit more testing to confirm
> that we don't need to relocate these exception vectors or have we now
> introduced some subtle breakage (or perhaps
On 7 Jan 2015, yamad...@jp.panasonic.com wrote:
> Thanks for your patch.
>
> I think this works but could it be more simplified?
>
> In your commit-log, you mentioned only some of tools provide
> additional information surrounded by brackets.
>
> If so, we can
> [1] remove blackets
> [2] and then
#x27; to the version.
Strip out the '(package version text)' and then look for a ##.## string.
Signed-off-by: Bill Pringlemeir
---
scripts/binutils-version.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/binutils-version.sh b/scripts/binutils-version.sh
#x27; to the version.
Run a 2nd pass on the 'version_string' to strip off any leading characters when
a package is not provided in brackets.
Signed-off-by: Bill Pringlemeir
---
scripts/binutils-version.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts
#x27; to the version.
Run a 2nd pass on the 'version_string' to strip off any leading characters when
a package is not provided in brackets.
Signed-off-by: Bill Pringlemeir
---
scripts/binutils-version.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts
>> On Tue, Jan 06, 2015 at 11:27:43AM +0100, Hans de Goede wrote:
>>> ping ? current master still has this regression, it is not fatal,
>>> but it is not
>>> pretty either.
> On 6 Jan 2015, tr...@ti.com wrote:
>> Did you see my earlier reply? It's OK with vanilla toolchains (see
>> ELDK) and L
On 6 Jan 2015, tr...@ti.com wrote:
> On Tue, Jan 06, 2015 at 11:27:43AM +0100, Hans de Goede wrote:
>> Hi all,
>>
>> ping ? current master still has this regression, it is not fatal,
>> but it is not
>> pretty either.
>
> Did you see my earlier reply? It's OK with vanilla toolchains (see
> ELDK)
in the
IRAM at 0x7801, where I guess the ROM code (at address zero)
branches too.
Fwiw,
Bill Pringlemeir.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Without the second patch, U-Boot will not boot on the Vybrid
tower systems for me. A better mechanism would be to use the
SPL to load direct to DDR3. However, the gfxRAM is large enough
to fit the current (~400KB) image for initial load. U-Boot is
relocated to DDR3 when initialized, so the life
by default.
As U-Boot relocates to DDR3 the gfxRAM is probably reliable enough.
However, an SPL framework would be better.
Signed-off-by: Bill Pringlemeir
---
include/configs/vf610twr.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/vf610twr.h b/include
Some MTD defines are repeated twice; once with UBI and then with MTD.
Remove the duplicate MTD defines from the UBI grouping.
Signed-off-by: Bill Pringlemeir
---
include/configs/vf610twr.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/configs/vf610twr.h b/include/configs
d output. I guess this is copy/paste from a Linux
Makefile as I don't even see where it is set in U-Boot.
> -mthumb-interwork,\ $(call cc-option,-marm,)\ $(call
> cc-option,-mno-thumb-interwork,)\ ) diff --git
> a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
&
> On Fri, Nov 28, 2014 at 06:56:32PM -0500, Bill Pringlemeir wrote:
>> Sorry, both trees behave the same. I will switch to separate
>> binaries.
On 28 Nov 2014, tr...@ti.com wrote:
> This is not intentional. I suspect I know what commit did this. Can
> you please
On 28 Nov 2014, bpringlem...@nbsps.com wrote:
>
> I tried to update the new u-boot I get,
>
> Bytes transferred = 3413041 (341431 hex)
> Kernel image @ 0x8600 [ 0x00 - 0x33e150 ]
> Could not find a valid device tree
[snip]
> Is the imx just using newer patches to be merged to the main tr
I tried to update the new u-boot I get,
Bytes transferred = 3413041 (341431 hex)
Kernel image @ 0x8600 [ 0x00 - 0x33e150 ]
Could not find a valid device tree
The 'bootcmd' is,
tftp ${loadaddr} zImage.dtb; bootz ${loadaddr}
has the syntax changed and I am not up to date? I think
de'; so this
solved it?
I think it is a very nice feature to have Thumb2 on Vybrid. Many boot
devices may have limited bandwidth compared to the running system.
Thanks for your work.
Regards,
Bill Pringlemeir
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
sions are here,
http://ftp.mirrorservice.org/sites/sourceware.org/pub/binutils/old-releases/
Who knows if some vendor patched things to mess something up? Probably
grabbing an older 'gas' version and verifying it was the same binary
before/after the patch would probably be fair confirma
> On Wed, 19 Nov 2014 13:34:34 -0500, Bill Pringlemeir
> wrote:
>>>>> In message <20141119074214.3d414ce6@lilith> Albert wrote:
>>>>>> For -mauto-it, it is not documented in the gas documentation
>>>>>> online or in my current as
> On 20-11-14 13:15, Stefan Agner wrote:
>> No particular reason, I did not know how to fix this without digging
>> into it. Hence, after I discovered this, I checked why those warnings
>> do not happen for the kernel, then I applied just the AFLAGS the
>> kernel is using. I guess fixing the under
y scream from me, the change above is fine globally in
>>>> U-Boot.
>> On 19 Nov 2014, w...@denx.de wrote:
>>> Apparently this [1] is where it is coming from; no further
>>> documentation there, though.
>>
>>> [1] https://sourceware.org/ml/binut
The 'bar'
above ends up with '11' in r1 if the value is zero, but it temporarily
'7'. The 2nd bar will only place 11 in r1.
Fwiw,
Bill Pringlemeir.
Ref: https://wiki.ubuntu.com/ARM/Thumb2PortingHowto#Conditional_Execution
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
the IRAM.
This is nice if you have L1 (primary 1M/4M MMU section entries) and need
to have non-cached entries for DMA (ethernet, usb, etc). But that is
probably not relevant for the SPL?
Fwiw,
Bill Pringlemeir.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
ion.
For non-secure boots, the SPL seems equivalent. With secondary image
verification in the SPL, then I think it would be equivalent to the
'plug-in'. The SPL would be supported in all HAB versions. I don't
know if the 'plug-in' is supported with earlier iMx ser
og below this patch seems sensible.
http://www.airs.com/blog/archives/189
I assume u-boot has no MMU enabled, then all the relocations should be
similar. This would be for all architectures though?
Fwiw,
Bill Pringlemeir.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
/17/14 11:18, Masahiro Yamada wrote:
>>
>>> Well, I'm not an expert in s/w security, but I'll try to explain...
>>
>> [snip]
>>
>>> But, again, I'm not an expert in this area, so its only a
>>> suggestion.
>>
> On 09/17/14 18
.
[snip]
> But, again, I'm not an expert in this area, so its only a suggestion.
I thought it was fairly apparent that the current code supports passing
a string that is *NOT* null terminated. This can be convenient if you
extract a sub-string from a command line and do not need to m
supported by the driver.
>
> Signed-off-by: Stefan Agner
Acked-by: Bill Pringlemeir
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
ted on Vybrid.
>>> On Wed, 2014-08-13 at 22:32, Scott Wood wrote:
>>>> raw_writel() is itself something that should only be used for
>>>> hand-optimized sections. For non-performance-critical code you
>>>> should use normal writel() so that you d
On 18 Aug 2014, ste...@agner.ch wrote:
> Am 2014-08-14 23:12, schrieb Bill Pringlemeir:
>>> On 14 Aug 2014, ste...@agner.ch wrote:
>>>
>>> This adds initial support for Freescale NFC (NAND Flash Controller)
>>> found in ARM Vybrid SoC's, Power Archit
le.com/webapp/sps/site/prod_summary.jsp?code=VF6xx
There is an app note, AN4947 'Understanding Vybrid Architecture', which
describes some timing details for the AHB bus (where this flash
controller is connected). Pg21 Table 7 of that document gives some
measurements. The QSPI i
re-read on an error in case of un-stable bits?
It is very little code to ensure a re-read in case of ECC failure. The
2nd physical read may pass whereas the first failed. This path is rare,
but maybe important? A higher layer may migrate the data in this case;
just as with a corrected bits.
On 13 Aug 2014, scottw...@freescale.com wrote:
> On Wed, 2014-08-13 at 17:44 -0400, Bill Pringlemeir wrote:
>> Regarding "can't know in advance", I think that some of the register
>> values maybe set by the boot rom. This might make more sense for
>> Li
On 13 Aug 2014, scottw...@freescale.com wrote:
> On Tue, 2014-08-12 at 18:58 -0400, Bill Pringlemeir wrote:
>> On 12 Aug 2014, scottw...@freescale.com wrote:
>>
>>> On Tue, 2014-08-12 at 23:13 +0200, Stefan Agner wrote:
>>>> Am 2014-08-12 00:33, schrieb Sc
expect the size to
get bigger if they are not inlined. Especially, gcc can recognize that
the same memory location is being operated on and collapse the
accesses.
Anyways, thanks for showing that the previous code was depending too
much on compiler knowledge. Your current plan sounds promisi
On 13 Aug 2014, ste...@agner.ch wrote:
> Am 2014-08-13 00:58, schrieb Bill Pringlemeir:
> [snip]
>>>>>> +static u32 nfc_read(struct mtd_info *mtd, uint reg)
>>>>>> +{
>>>>>> +struct fsl_nfc *nfc = mtd_to_nfc
On 12 Aug 2014, scottw...@freescale.com wrote:
> On Tue, 2014-08-12 at 23:13 +0200, Stefan Agner wrote:
>> Am 2014-08-12 00:33, schrieb Scott Wood:
>>> On Wed, 2014-08-06 at 10:59 +0200, Stefan Agner wrote:
This adds initial support for Freescale NFC (NAND Flash
Controller). The IP is u
);
> + ecc_count = ecc_status & ECC_ERR_COUNT;
> + if (!(ecc_status & ECC_STATUS_MASK))
> + return ecc_count;
[snip]
> +static void nfc_enable_hwecc(struct mtd_info *mtd, int mode)
> +{
> +}
> +
> +struct nfc_config {
> + int hardware_ec
58 matches
Mail list logo
