Hello,
Please try to insert udelay() calls in addition to dsb() in the
mctl_mem_matches()
and see if this helps. I suspect that there's just no way to do
perfectly reliable
synchronization all the way from the CPU to DRAM and back in this particular
scenario (which involves wacky things, such as a
On Wed, Nov 25, 2020 at 5:36 PM Andy Shevchenko
wrote:
>
> On Wed, Nov 25, 2020 at 5:23 PM Simon Glass wrote:
> > On Wed, 25 Nov 2020 at 08:07, Andy Shevchenko
> > wrote:
> > > On Wed, Nov 25, 2020 at 4:50 PM Simon Glass wrote:
> > > > On Wed, 25 Nov 2020 at 06:26, Andy Shevchenko
> > > > wr
On Sun, 25 Aug 2019 18:12:22 +0200
Ondřej Jirman wrote:
> Hello,
>
> On Sun, Aug 25, 2019 at 05:41:55PM +0300, Siarhei Siamashka wrote:
> > On Sat, 24 Aug 2019 22:07:43 +0200
> > Ondřej Jirman wrote:
> >
> > > Hi Jagan,
> > >
> > > can
ease experiment with this problem a little bit more?
1. What if you just move this second DSB instruction after the
second write and have two of them there? Does this also make
the problem disappear?
2. What if you just replace DSB with udelay(1) / udelay(10) /
udelay(100)? Does
ter sporadic r0 corruption
problem depending on the compiler version or optimization settings.
This would be:
"msr cpsr_c, r0\n\t" : : : "r0")
See https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html for more
details.
An even better opt
On Fri, 20 Jul 2018 04:13:24 +0300
Siarhei Siamashka wrote:
> On Wed, 18 Jul 2018 23:42:07 +0200
> michael vogt wrote:
>
> > Hi
> >
> > I would like to support 4 memory chips for a sunxi board (a20).
> >
> > the current configuration in the sunxi-com
o design such board
using the boot0 bootloader from the Allwinner's BSP for the
initial testing. And then after everything works correctly,
add the necessary changes to the DRAM init code in U-boot.
I could provide some help with getting this done.
--
Best regards,
Siarhei Siamashka
_
K=384
> CONFIG_MACPWR="PH23"
> CONFIG_MMC0_CD_PIN="PH10"
> CONFIG_SATAPWR="PB3"
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
the SPL part does not match the main
U-Boot part), then something is already very wrong.
> printf("sunxi SPL version mismatch: expected %u, got %u\n",
> -SPL_HEADER_VERSION, spl_header_version);
> +SPL_ENV_HEADER_VERSION, spl_header_version);
> return;
> }
> if (!spl->fel_script_address)
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
future size expansions
and makes it harder for the users to hurt themselves.
For example, if the padded U-Boot size is 1024K while the actual size
is only ~800K, then adventurous users might be tempted to fit some of
their data into this gap. Yay, ~200K
(if at all)?
> We can just put a warning in there, to ask users to upgrade.
> That would have worked already with the v1/v2 transition, I believe.
Yes, that's more or less how this was supposed to work in sunxi-tools
from the very beginning. Except that we unfortunately got a bug in
this code, which has been reported back in July 2017 and is still not
resolved due to various reasons:
https://github.com/linux-sunxi/sunxi-tools/issues/104
But hopefully it can be fixed sooner or later.
> Probably worth a separate discussion with some sunxi-tools stakeholders.
On the U-Boot side we can just increase the version number as long as
the new header is a backwards compatible superset of the old one.
In the unlikely case if we suddenly have to introduce a compatibility
breaking change to the SPL header format, we can always change the SPL
header signature from 'SPL' to something else.
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
se which don't
support unaligned memory accesses (ARMv5, MIPS, ...). This
is a maintenance nightmare. Because the people, who test their
patches only on ARMv7 hardware, will unintentionally keep
breaking other architectures.
--
Best regards,
Siarhei Siamashka
rs
on 32-bit sunxi hardware either. For example, we can do a search in
the linux-sunxi wiki to compare the usage of environment vs. boot.scr
and uEnv.txt:
https://linux-sunxi.org/index.php?search=saveenv
https://linux-sunxi.org/index.php?search=boot.scr
https://linux-sunxi.org/index.php?search=uenv.txt
Using saveenv is justified only in very rare exceptional cases. They do
exist, otherwise Maxime would not have encountered the problem in the
first place. But I think that we should encourage Maxime to migrate
away from it. I would really like to know a bit more about his use case.
The Linux distributions don't seem to rely on the U-Boot environment
(if I understood their feedback correctly). Our tutorials at the
linux-sunxi wiki encourage the use of boot.scr since a very long
time ago. Anyone is free to deviate from good practices, but they
should really know what they are doing and understand that they are
expected to take care of their problems themselves.
> I am just thinking of whether it's worthwhile to have some transition
> code, which tries multiple environment locations (first FAT, then MMC,
> for instance), or even contains code to migrate from one to another.
Ugh. I think that this is a very bad idea. It makes the U-Boot
environment handling even more convoluted and dangerous than it is
now. I would prefer to keep the U-Boot environment (when its use is
justified) tightly coupled with the bootloader itself and always
stored on the same boot media. We do have the boot media id passed
to us from the boot ROM, so this is pretty much straightforward.
Allowing to move the environment to a different media is a recipe
for disaster.
Currently boot.scr or uEnv.txt is loaded from FAT or other
partitions as part of distro boot. Is this really not enough?
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
98 26492 249240 765130 baccau-boot.orig
== After: ==
$ arm-linux-gnueabihf-size u-boot
text databssdec hexfilename
366314 26492 249232 642038 9cbf6u-boot
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
er (plus added EDID and
LCD support). But it was Luc, who made it happen back in 2014 by
providing a usable graphics support for the mainline kernel users
and laid down the foundation for all the further incremental
improvements.
If not for Luc Verhaegen, we don't even know what would be the current
state of the graphics support on sunxi hardware. And the number of
commits does not matter, what matters is having the job done. And Luc
did just that. So let's give credit where it is due.
With a proper copyright notice, this patch is
Acked-by: Siarhei Siamashka
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
eagleBoard.
As an additional bonus, we need fewer instructins and the SPL
size is reduced.
Signed-off-by: Siarhei Siamashka
---
arch/arm/cpu/armv7/start.S | 32
1 file changed, 12 insertions(+), 20 deletions(-)
diff --git a/arch/arm/cpu/armv7/start.S b/arc
best to revert
it for now.
The second patch in this series improves testing coverage
and should prevent similar regressions in the future.
Siarhei Siamashka (2):
Revert "arm: omap: Unify get_device_type() function"
arm: Exercise v7_arch_cp15_set_acr even without errata fixups
a
203200 253934 3dfee spl/u-boot-spl
Signed-off-by: Siarhei Siamashka
Reported-by: Derald D. Woods
---
arch/arm/include/asm/arch-am33xx/cpu.h | 6 ++
arch/arm/include/asm/arch-am33xx/omap.h | 3 ---
arch/arm/include/asm/arch-omap3/omap.h | 3 ---
arch/arm/include/asm/arch-omap4/omap.h | 1
ed last. We obviously want something deterministic for
> > >> > fastboot for example, but booting partitions of the media you started
> > >> > from make sense I guess. And this is what this hack was trying to
> > >> > address.
> > >>
> > >> OK...so what should we do here?
> > >
> > > I guess we should just drop the hack. We'll have to at some point
> > > anyway. But I guess we should also find a way to tweak the distro
> > > bootcmd at boot time to search for the medium that we booted on first.
> > >
> > > I'm not really sure how to do this though.
You can check how this is done for USB FEL boot. Basically, we set an
environment variable if we see that the boot source is FEL:
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=af654d14613f22f4910601d86e584030ee392b94
And then check this environment variable from bootcmd:
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=f3b589c09b43a231706f11ab391e5ea7f9670f12
This can be done in a pretty much the same way for eMMC. Or maybe even
generalized to also use this for different boot sources and non-sunxi
SoCs.
> >
> > Well in that case let's drop the hack and someone will pick it up when
> > it hits them.
>
> That works for me.
Deliberately breaking something just to see if some end user runs into
troubles, wastes time to bisect the problem and comes up with a fix
looks like a dick move.
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
If this is migrated to Kconfig, then we probably want to have
reasonable SoC-specific defaults there and leave defconfigs alone.
> CONFIG_SPL_I2C_SUPPORT=y
> # CONFIG_CMD_IMLS is not set
> # CONFIG_CMD_FLASH is not set
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
On Tue, 25 Jul 2017 12:00:05 +0530
Lokesh Vutla wrote:
> On 7/25/2017 7:38 AM, Siarhei Siamashka wrote:
> > On Fri, 14 Jul 2017 08:53:20 -0500
> > Adam Ford wrote:
> >
> >> Fixes 4bd754d8abef ("arm: omap: Detect boot mode very early") where
>
@ Set IBE bit
push{r1-r5} @ Save the cpu info registers
bl v7_arch_cp15_set_acr
pop {r1-r5} @ Restore the cpu info - fall through
skip_errata_430973:
#endif
--
Best regards,
Siarhei Siamashka
_
Anyway, thanks a lot for your feedback. It's good to know that DM3730
is also affected. Because this clearly rules out any possible impact
of some Thumb2 errata (OMAP3530 had an old bug ridden Cortex-A8, but
DM3730 has the latest revision of it).
Right now the OMAP3 clock code has some sort
write of
this OMAP_SRAM_SCRATCH_BOOT_PARAMS data happens during the whole
SPL lifetime:
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=60c7c30aa084588ef974663be3d22a1de7f66cbb
So what's going on? Can Lokesh or Paul comment?
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
On Fri, 21 Jul 2017 22:15:37 +0300
Siarhei Siamashka wrote:
> On Wed, 12 Jul 2017 16:34:50 +0200
> Maxime Ripard wrote:
>
> > The -mno-unaligned-access flag used on ARM to prevent GCC from generating
> > unaligned accesses (obviously) will only do so on packed structures.
C complains at compile time, even though the error
message is not exactly intuitive:
test.c:17:5: error: size of array ‘dummy_a’ is too large
int dummy_a[3 - __alignof__(struct a)];
^
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
ot 32-bit aligned. Maybe we should address the
> > place where that is the case instead of forcing byte-wise accesses in
> > general for this structure?
>
> |Perhaps __attribute__((aligned(2))) can prevent byte wise accesses?
> Regards, Jeroen |
https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html
It says that "The aligned attribute can only increase alignment".
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
STM instructions don't work with unaligned memory
addresses regardless of the SCTLR.A bit. And if the compiler thinks
that the pointer is supposed to be properly aligned, then it may
use such instructions. A very good testcase is a simple function
like this:
int f(int *x)
{
return x[0] + x[1];
}
The compiler will rightfully generate the following instructions:
:
0: e899ldm r0, {r0, r3}
4: e083add r0, r3, r0
8: e12fff1ebx lr
If the pointer is misaligned, then it will surely fail.
> What hardware did this happen on? If it was on ARMv5, adding the packed
> attribute is probably the correct fix. If it was ARMv6 or later,
> something else is broken as well.
It does not matter if this was ARMv6+ hardware or not. The current
U-Boot code is wrong and we need to fix it.
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
ons.com/ is awesome and I eagerly
> > await gcc-7.x toolchains there if I can't get something else spun up in
> > a chroot soon :)
>
> So there’s the remaining question of how to fix this permanently:
> — with my compiler engineering hat on, I’d recommend to mark this
> as a packed struct, as that’s what it is: the compiler needs to keep it
> packed, because that is how it is received/sent on the wire
> — rereading the doc/README.unaligned-memory-access.txt, the
> preferred solution in U-Boot would be to use put/get_unaligned to
> access these fields (although I have concerns with this—see below).
>
> I honestly wonder if the recommendation (to avoid ‘packed’) from the
> README is appropriate for many of the data structure declarations in
> U-Boot which deal with the external representation of data (i.e. DMA
> descriptors, memory-mapped register files and data sent on a wire):
> the C language does not offer any protection against a compiler adding
> patting between structure members, as it sees fit. The original wording
> from the standard is:
> 14Each non-bit-field member of a structure or union object is aligned in
> an implementation-defined manner appropriate to its type.
> 15Within a structure object, the non-bit-field members and the units in
> which bit-fields reside have addresses that increase in the order in which
> they are declared. A pointer to a structure object, suitably converted,
> points to its initial member (or if that member is a bit-field, then to the
> unit in which it resides), and vice versa. There may be unnamed padding
> within a structure object, but not at its beginning.
>
> In other words: there’s nothing in the standard from stopping a compiler
> to insert additional padding within structures, unless the ‘packed’ attribute
> is added.
I would strongly advise against adding the "packed" attribute
everywhere unnecessarily. This just makes the code bigger and
slower.
The ANSI/ISO C language standard indeed leaves a lot up to the
implementation. But we also have ABI documents for each platform,
which cover all of these details. We just need to use them.
In the case of 32-bit ARM, it is
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf
In the case of 64-bit ARM, it is
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
it does, so I'm a bit confused,
> and not really sure what to do from there.
The --wno-unaligned-access option does not help because the
compiler assumes that the struct pointer is properly aligned.
This bug can be fixed by either:
1) Always ensure proper alignment of the udp pa
gt; + val = CCM_MMC_CTRL_OCLK_DLY(oclk_dly) |
> CCM_MMC_CTRL_SCLK_DLY(sclk_dly);
> + }
> +
> + writel(CCM_MMC_CTRL_ENABLE| pll | CCM_MMC_CTRL_N(n) |
> CCM_MMC_CTRL_M(div) | val,
> +mmchost->mclkreg);
>
> debug("mmc %u set mod-clk req %u parent %u n %u m %u rate %u\n",
> mmchost->mmc_no, hz, pll_hz, 1u << n, div,
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
ay end up with a wrong default without
noticing.
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
dr3_1333.c
> create mode 100644 arch/arm/mach-sunxi/dram_timings/lpddr3_stock.c
> create mode 100644 configs/nanopi_m1_plus_defconfig
> create mode 100644 configs/nanopi_neo2_defconfig
> create mode 100644 configs/orangepi_win_defconfig
> create mode 100644 con
dw.c} (84%)
> create mode 100644 arch/arm/mach-sunxi/dram_timings/Makefile
> create mode 100644 arch/arm/mach-sunxi/dram_timings/ddr2_v3s.c
> create mode 100644 arch/arm/mach-sunxi/dram_timings/ddr3_1333.c
> create mode 100644 arch/arm/mach-sunxi/dram_timings/lpddr3_stock.c
> cre
On Tue, 14 Mar 2017 20:06:42 +0530
Anand Moon wrote:
> On 14 March 2017 at 15:24, Siarhei Siamashka
> wrote:
> > You can just clone my git branch:
> >
> >git clone -b 20170306-unbreak-odroid https://github.com/ssvb/u-boot.git
> >
> > Then compile it and
On Tue, 14 Mar 2017 18:01:11 +0900
Jaehoon Chung wrote:
> On 03/14/2017 04:52 PM, Siarhei Siamashka wrote:
> > On Mon, 6 Mar 2017 12:18:50 +0200
> > Siarhei Siamashka wrote:
> >
> >> On Thu, 12 Jan 2017 14:02:48 +0530
> >> Anand Moon wrote:
>
On Tue, 14 Mar 2017 14:44:26 +0530
Anand Moon wrote:
> Hi Siarhei/Jaehoon
>
> On 14 March 2017 at 14:31, Jaehoon Chung wrote:
> > On 03/14/2017 04:52 PM, Siarhei Siamashka wrote:
> >> On Mon, 6 Mar 2017 12:18:50 +0200
> >> Siarhei Siamashka wrote:
> >
On Mon, 6 Mar 2017 12:18:50 +0200
Siarhei Siamashka wrote:
> On Thu, 12 Jan 2017 14:02:48 +0530
> Anand Moon wrote:
>
> > Hi All,
> >
> > I tried to compile the latest u-boot for Odroid U3.
> > issue is that Ethernet is not able to detected.
> >
> &g
On Wed, 8 Mar 2017 09:30:07 -0500
Tom Rini wrote:
> On Mon, Mar 06, 2017 at 03:16:53AM +0200, Siarhei Siamashka wrote:
>
> > The workaround for ARM errata 725233 had been lost since
> > commit 45bf05854bc94e (armv7: adapt omap3 to the new cache
> > maintenance framework)
cache. If there is a cache hit, the cache is read or
updated in the same way as if the cache is enabled. This enables
Cacheable memory to remain fully coherent while the cache is disabled.
While the cache is disabled, it remains fully coherent with the L2
cache and the other L1 data caches."
On Mon, 6 Mar 2017 17:54:17 -0500
Tom Rini wrote:
> On Tue, Mar 07, 2017 at 12:44:59AM +0200, Siarhei Siamashka wrote:
> > Hi Tom,
> >
> > On Mon, 6 Mar 2017 13:50:10 -0500
> > Tom Rini wrote:
> >
> > > Today, we have cases where we wish to bui
Hello,
On Fri, 23 Oct 2015 19:53:28 +0900
Minkyu Kang wrote:
> Dear Siarhei Siamashka,
>
> On 20/10/15 08:39, Siarhei Siamashka wrote:
> > ODROID-X uses a slightly older revision of the same base board
> > as the ODROID-X2. But the CPU module in ODROID-X uses an older
&
tem...
> ** Unrecognized filesystem type **
> Wrong Image Format for bootm command
> ERROR: can't get kernel image!*
>
> If someone knows how to fix this bug, please help me!
>
> Thanks a lot!
Hello,
Yes, it's a known problem. You could even easily find the information
about it in google. This was posted to the U-Boot mailing list some
years ago:
https://lists.denx.de/pipermail/u-boot/2015-October/230749.html
Jaehoon Chung promised to have a look at it, but we haven't
heard anything back since then. Right now you can try to apply
this patch and check if it helps (essentially a revert of
a276172cf32386c211c75638f6bf3c0d59ba03ba):
https://github.com/ssvb/u-boot/commit/3dd6fdb016c088953f5f293d62d6df03a0f48d54
BTW, I can't seem to find any Tiny4412 board support code in the
current U-Boot git master branch. Are you using a patched U-Boot?
And if yes, then do you have plans to contribute these patches?
Thanks.
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
symbol as well, SPL_SYS_THUMB_BUILD to
> control if we build everything or just SPL (or in theory, just U-Boot) in
> Thumb2 mode.
>
> Signed-off-by: Tom Rini
[...]
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
htt
nfirm that it works on your ODROID-U3,
then I can maybe spend some time on making cleaner patches and ensuring
that they reach the U-Boot git repository.
Thanks!
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
On Sun, 5 Mar 2017 09:27:44 -0500
Tom Rini wrote:
> On Sun, Mar 05, 2017 at 02:51:54PM +0200, Siarhei Siamashka wrote:
> > Hello All,
> >
> > I have just unexpectedly found an old Beagleboard B7 in my closet and
> > tried to compile the current U-Boot master branch
OMAP3530 hardware.
This patch adds the new errata define to the whitelist instead
of introducing a new Kconfig option. It's probably best to
convert all ARM errata to Kconfig in one go via a separate
patch.
Signed-off-by: Siarhei Siamashka
---
arch/arm/cpu/armv7/start.S
ach-omap2/omap3/clock.c'.
This patch enforces the compilation of clock.c source file in
ARM mode and makes the deadlock disappear. We are yet to figure
out the root cause of the problem. Still this is somewhat
better than having non-bootable boards for years.
Signed-off-by: Siarhei Siamashka
---
OMAP3530 lost the erratum 725233 workaround since 2011 and even
became completely non-bootable since 2015. These two patches make
it usable again. The most notable hardware is the original
BeagleBoard.
Siarhei Siamashka (2):
arm: omap3: Compile clock.c with -marm option to unbreak OMAP3530
in the AUXCR) as a workaround for the most nasty
erratum (657417: A 32-bit branch instruction that spans two 4K regions
can result in an incorrect operation) just because I don't fully trust
the linker.
--
Best regards,
Siarhei Siamashka
___
< 0) {
> + perror("Open output file");
> + return EXIT_FAILURE;
> + }
> }
>
> /* read file to buffer to calculate checksum */
> @@ -115,7 +140,7 @@ int main(int argc, char *argv[])
>& 0x00FF);
atch() function in some way.
Then the sun50i-a64-pine64 device tree file can specify that this board
is expected to have exactly 512 MiB of RAM. Having this information,
the board_fit_config_name_match() function will fail to match it if
the actual RAM size is wrong.
This approach is similar to wh
ID controller, in order to get
> + * the correct value, and also refresh the wrong value at
> + * SUNXI_SID_BASE.
> + */
> + int i;
> +
> + for (i = 0; i< 4; i++)
> + sid[i] = sun8i_efuse_read(i * 4);
> +
> + return 0;
> #elif defined
num = va_arg(va, unsigned long);
> + div = 1UL << (sizeof(long) * 8 - 4);
> + } else {
> + num = va_arg(va, unsigned int);
> + div = 0x1000;
> + }
> if (!num) {
> out_dgt(info, 0);
> } else {
> - for (div = 0x1000; div; div /= 0x10)
> + for (; div; div /= 0x10)
> div_out(info, &num, div);
> }
> break;
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
} else {
> + num = va_arg(va, unsigned int);
> + div = 0x1000;
> + }
> if (!num) {
> out_dgt(info, 0);
> } else {
> - for (div = 0x1000; div; div /= 0x10)
> + for (; div; div /= 0x10)
> div_out(info, &num, div);
> }
> break;
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
f (IS_ENABLED(CONFIG_MACH_SUN6I))
writel(MBUS_CLK_DEFAULT, &ccm->mbus1_clk_cfg);
This saves one line of code and also looks a bit less ugly.
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
t; + * not inline to increase chances its in cache when called
> > + */
> > +void sdelay(unsigned long loops)
> > +{
> > + __asm__ volatile ("1:\n" "subs %0, %1, #1\n"
> > +
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html page provides
some information.
> +}
> +
> int cleanup_before_linux(void)
> {
> /*
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
n be always contributed later. There is also
the SPL size concern and we don't want to unnecessarily increase the
code size.
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
line before committing.
>
> Making things checkpatch clean is good, in the future please also
> mention that in commit messages. Thanks!
How can I get this checkpatch warning?
$ scripts/checkpatch.pl 0001-sunxi-Support-booting-from-SPI-flash.patch
total: 0 errors, 0 warnings, 0 checks, 361 lines checked
NO
(msg) - 1);
"man strncat" on my system says:
char *strncat(char *dest, const char *src, size_t n);
...
If src contains n or more bytes, strncat() writes n+1 bytes to
dest (n from src plus the terminating null byte). Therefore,
the size of dest must be
t a/include/configs/tbs2910.h b/include/configs/tbs2910.h
> index 85501bc..ddd53dd 100644
> --- a/include/configs/tbs2910.h
> +++ b/include/configs/tbs2910.h
> @@ -50,10 +50,6 @@
> #define CONFIG_CONSOLE_MUX
> #define CONFIG_CONS_INDEX1
>
> -#define CONFIG_
On Mon, 5 Sep 2016 09:23:00 +0100
Andre Przywara wrote:
> Hi,
>
> On 05/09/16 05:12, Siarhei Siamashka wrote:
> > On Mon, 5 Sep 2016 01:32:38 +0100
> > Andre Przywara wrote:
> >
> >> This commit moved the SPL stack into SRAM C, which worked when the SPL
,
> + himport_r(&env_htab, (char *)(uintptr_t)spl->fel_script_address,
> spl->fel_uEnv_length, '\n', H_NOCLEAR, 0, 0, NULL);
> return;
> }
Reviewed-by: Siarhei Siamashka
--
Best regards,
Siarhei Siamashka
_
3190 /*
> AHB1=PLL6/6,APB1=AHB1/2 */
> -#else
> #define AHB1_ABP1_DIV_DEFAULT0x3180 /*
> AHB1=PLL6/3,APB1=AHB1/2 */
> -#endif
>
> #define AXI_GATE_OFFSET_DRAM 0
>
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
enable some other
features too.
> This reverts commit 1a83fb4a17d959d7b037999ab7ed7e62429abe34
> and fixes booting the Pine64 when using boot0.
>
> Signed-off-by: Andre Przywara
But as discussed earlier, reverting this patch is a reasonable
solution for v2016.09, so it is
Reviewed-b
not safely accessible by the SPL (such as
the DRAM), causes a very early SPL deadlock.
Signed-off-by: Siarhei Siamashka
---
arch/arm/cpu/armv7/lowlevel_init.S | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/cpu/armv7/lowlevel_init.S
b/arch/arm/cpu/armv7/lowlevel_init.S
index
Hey guys,
> > > >
> > > > I just started trying out my Pine64 1GB and mainline U-Boot and I've
> > > > found that:
> > > > commit 1a83fb4a17d959d7b037999ab7ed7e62429abe34
> > > > Author: Siarhei Siamashka
> > > &
ood.
> + */
> + sid[3] ^= sid[1] ^ sid[2];
> +#endif
> +
> /* Ensure the NIC specific bytes of the mac are not all 0 */
> if ((sid[3] & 0xff) == 0)
> sid[3] |= 0x800000;
Using XOR is
Hi,
On Thu, 28 Jul 2016 20:35:21 +0200
Hans de Goede wrote:
> Hi,
>
> On 28-07-16 05:13, Chen-Yu Tsai wrote:
> > Hi,
> >
> > On Thu, Jul 28, 2016 at 3:14 AM, Siarhei Siamashka
> > wrote:
> >> Hello Hans,
> >>
> >> On Wed, 27 Jul 20
e accounted for.
Also changing the MAC address generation algorithm is an invasive
change, which is affecting the end users. So IMHO it's best to have
it implemented properly right from the start, rather than evolving
via a trial and error method. What if it turns out that word1
from the SID is actually not sufficiently random on H3? How large
was your sample set?
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
On Thu, 9 Jun 2016 19:42:55 -0700
Simon Glass wrote:
> Hi,
>
> On 9 June 2016 at 18:33, Siarhei Siamashka
> wrote:
> > Hi Simon,
> >
> > On Thu, 9 Jun 2016 17:36:10 -0700
> > Simon Glass wrote:
> >
> >> Hi,
> >>
Hi Simon,
On Thu, 9 Jun 2016 17:36:10 -0700
Simon Glass wrote:
> Hi,
>
> On 7 June 2016 at 05:28, Siarhei Siamashka
> wrote:
> > Allwinner devices support SPI flash as one of the possible
> > bootable media type. The SPI flash chip needs to be connected
> > to S
l").
> >
> > Signed-off-by: Bernhard Nortmann
>
> This patch looks good to me.
>
> Siarhei any comments from your side ? If not then I'll add this to
> u-boot-sunxi/next.
Yes, it also looks good to me:
Acked-by: Siarhei Siamashka
The only nitpick is about
Hello,
On Wed, 8 Jun 2016 02:56:41 -0700 (PDT)
boob...@gmail.com wrote:
> Hello
>
> Nice to see new entry to boot.
> I would like to know if sdcard wired in spi mode can working with
> this spi boot support.
No, it can't. The SPI protocol used by the SD card is different
from the SPI protocol u
Hello,
On Tue, 7 Jun 2016 16:09:58 +0200
Bernhard Nortmann wrote:
> Hello Siarhei!
>
> Am 06.06.2016 um 11:20 schrieb Siarhei Siamashka:
> > On Sun, 5 Jun 2016 15:01:30 +0200
> > Bernhard Nortmann wrote:
> >
> >> Hi Siarhei!
> >>
> >
: Siarhei Siamashka
---
Changes in v2:
- Add Kconfig option (CONFIG_SPL_SPI_SUNXI) and move the SPI flash
support code into a separate source file
- Use CONFIG_SYS_SPI_U_BOOT_OFFS instead of the hardcoded constant
- Deinitialize the SPI controller and undo pin muxing after the job
is done
On Sun, 5 Jun 2016 15:01:30 +0200
Bernhard Nortmann wrote:
> Hi Siarhei!
>
> Am 05.06.2016 um 13:44 schrieb Siarhei Siamashka:
> > Hello Bernhard,
> >
> > [...]
> > How does this work in general with "boot.scr" and "uEnv.txt" use
> &g
setenv("filesize", NULL);
I have no real opinion about this, but "filesize" looks like a
rather generic name for this environment variable. Are there some
advantages/disadvantages picking this particular name instead
of something like "fel_scriptsize"?
> +
SPI flash.
The offset of the main U-Boot binary is assumed to be 0x8000.
The existing SPI frameworks are not used in order to reduce the
code size in the SPL.
Tested on the Orange Pi PC (Allwinner H3) and A13-OLinuXino-Micro
(Allwinner A13) boards.
Signed-off-by: Siarhei Siamashka
---
arch/arm
hat the boot ROM in the future
Allwinner SoCs starts patching even more bytes in the header or moves
this boot device id variable to some other address. If/when this
happens, we can always update the SPL header format (do the "major"
version change trick).
> Other then that worry, I see no
upgrades.
The size of the SPL header is also increased from 64 bytes
to 96 bytes to provide enough space for the device tree name
string.
Signed-off-by: Siarhei Siamashka
---
arch/arm/include/asm/arch-sunxi/spl.h | 26 +++--
include/configs/sunxi-common.h| 12 +++---
areful about
using up this reserve, to ensure that it is well spent on something
useful (such as NAND support) instead of being just wasted by the
bloatware cultists :-)
[1] http://lists.denx.de/pipermail/u-boot/2015-September/226963.html
--
Best regards,
Siarhei Siamashka
_
On Tue, 31 May 2016 01:48:05 +0300
Siarhei Siamashka wrote:
> Currently the AHB1 clock speed is configured as 200MHz by
> the SPL, but this causes a subtle and hard to reproduce data
> corruption in SRAM C (for example, this can't be easily
> detected with a trivial memset/memcm
A64 yet and it should not affect the boot0
usage (unless somebody can confirm SRAM C corruption with the
boot0 too).
Signed-off-by: Siarhei Siamashka
---
arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/include/asm/arch-sunxi/clock_su
and trying to use the SRAM C on A64 as a temporary buffer (after
loading the U-Boot SPL with the hope to gain more speed from the
higher CPU and AHB clock speeds).
Siarhei Siamashka (2):
sunxi: Downclock AHB1 to 100MHz on Allwinner A64
sunxi: Move the SPL stack top to 0x1A000 on Allwinner A64
the availability
of 8 KiB stack.
Signed-off-by: Siarhei Siamashka
---
include/configs/sunxi-common.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index b33cfb8..94275a7 100644
--- a/include/configs/sunxi
On Sat, 14 May 2016 03:14:25 +0300
Siarhei Siamashka wrote:
> The current SPL header, created by the 'mksunxiboot' tool, has size
> 32 bytes. But the code in the boot ROM stores the information about
> the boot media at the offset 0x28 before passing control to the SPL.
type can be
later used in the 'spl_boot_device' function, but this is out of
the scope of this patch.
Signed-off-by: Siarhei Siamashka
---
Changes in v2:
- Increase the header size to 64 bytes instead of 48 bytes in order
to satisfy the VBAR alignment requirements.
arch/arm/inclu
type can be
later used in the 'spl_boot_device' function, but this is out of
the scope of this patch.
Signed-off-by: Siarhei Siamashka
---
arch/arm/include/asm/arch-sunxi/spl.h | 8 +++-
include/configs/sunxi-common.h| 12 ++--
2 files changed, 13 insertions(+), 7 del
FIG_SYS_SDRAM_BASE + offset);
> + DSB;
> /* Check if the same value is actually observed when reading back */
> return readl(CONFIG_SYS_SDRAM_BASE) ==
> readl((ulong)CONFIG_SYS_SDRAM_BASE + offset);
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
le could be a good idea.
> [1]
> http://www.micron.com/~/media/Documents/Products/Data%20Sheet/DRAM/DDR3/1Gb_DDR3_SDRAM.pdf
> [2]
> http://git.denx.de/?p=u-boot.git;a=blob;f=lib/crc32.c;h=97592124867abb815d576899f8789545c3aef1aa;hb=HEAD#l200
> [
NS_INDEX=2"
> # CONFIG_CMD_IMLS is not set
> CONFIG_CMD_GPIO=y
> -CONFIG_AXP_DCDC2_VOLT=1300
> CONFIG_AXP_ALDO3_VOLT=3300
> CONFIG_AXP_ALDO4_VOLT=3300
> CONFIG_USB_MUSB_GADGET=y
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
gt; +#if defined CONFIG_AXP152_POWER || defined CONFIG_AXP209_POWER || \
> +defined CONFIG_SY8106A_POWER
> #define CONFIG_SPL_I2C_SUPPORT
> #endif
>
> @@ -240,7 +241,8 @@ extern int soft_i2c_gpio_scl;
>
> /* PMU */
> #if defined CONFIG_AXP152_POWER || defined CONFI
On Wed, 23 Dec 2015 22:36:19 +0800
Chen-Yu Tsai wrote:
> On Wed, Dec 23, 2015 at 6:14 PM, Siarhei Siamashka
> wrote:
> > On Tue, 17 Nov 2015 15:32:30 +0100
> > Jens Kuske wrote:
> >
> >> On 16/11/15 07:26, Chen-Yu Tsai wrote:
> >> > Hi everyone
if (!node)
+ node = of_find_compatible_node(NULL, NULL,
+ "allwinner,sun8i-h3-cpuconfig");
if (!node) {
pr_err("Missing A31 CPU config node in the device tree\n");
return;
--
2.4.10
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
ng via FEL. This patch can increase the FEL USB
transfer speed from ~510 KB/s to ~950 KB/s.
Signed-off-by: Siarhei Siamashka
---
This is intended to be used together with the Allwinner H3 patches
from Jens Kuske:
http://lists.denx.de/pipermail/u-boot/2015-November/234589.html
Allwinner A83T
On Wed, 28 Oct 2015 00:27:48 +0100
Piotr Król wrote:
> On Tue, Oct 27, 2015 at 06:31:24AM +0200, Siarhei Siamashka wrote:
> > On Mon, 26 Oct 2015 12:18:35 +0100
> > Piotr Król wrote:
> >
> > > On Sun, Oct 25, 2015 at 06:44:45AM +0200, Siarhei
ber/230314.html
http://lists.denx.de/pipermail/u-boot/2015-October/231908.html
Signed-off-by: Siarhei Siamashka
---
I have only tested that the compilation problem disappears for
me. It would be best if somebody could confirm whether the fix
is correct.
common/fb_mmc.c | 3 ++-
1 file
On Mon, 26 Oct 2015 12:18:35 +0100
Piotr Król wrote:
> On Sun, Oct 25, 2015 at 06:44:45AM +0200, Siarhei Siamashka wrote:
> > Hello,
> >
> > DFU allows to transfer large files (such as initrd images) much
> > faster than FEL.
> >
> > Siarhei Siamash
1 - 100 of 372 matches
Mail list logo
