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
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
> > > >
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,
> > >
> > >
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 this make the
0 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 option is to just
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
gn 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
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
here.
If this particular check fails (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
users might be tempted to fit some of
their data into this gap. Yay, ~200K of storage space for free! Except
that the next U-Boot release may grow up to 900K without any warning
and if the users are not careful enough, then their data would be
corrupted during upgrade.
Could you please tell us what is your problem and why reverting this
patch would fix it?
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
the v3 features (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
e run on
different CPU architectures, including those 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,
Si
re 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
hexfilename
489398 26492 249240 765130 baccau-boot.orig
== After: ==
$ arm-linux-gnueabihf-size u-boot
text databssdechexfilename
366314 26492 249232 642038 9cbf6u-boot
--
Best regards,
Siarhei Siamashk
u need to pick only one copyright line from the old code,
then you should mention Luc instead of Hans. Hans de Goede surely
has done a lot of massaging for this code later (plus added EDID and
LCD support). But it was Luc, who made it happen back in 2014 by
providing a usable graphics support for t
eagleBoard.
As an additional bonus, we need fewer instructins and the SPL
size is reduced.
Signed-off-by: Siarhei Siamashka <siarhei.siamas...@gmail.com>
---
arch/arm/cpu/armv7/start.S | 32
1 file changed, 12 insertions(+), 20 deletions(-)
diff --git a/ar
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
arch/a
203200 253934 3dfee spl/u-boot-spl
Signed-off-by: Siarhei Siamashka <siarhei.siamas...@gmail.com>
Reported-by: Derald D. Woods <woods.techni...@gmail.com>
---
arch/arm/include/asm/arch-am33xx/cpu.h | 6 ++
arch/arm/include/asm/arch-am33xx/omap.h | 3 ---
arch/arm/include/asm/arch-
gt;> >
> > >> > That's due to the fact that the eMMC controller is the third one, and
> > >> > is thus probed last. We obviously want something deterministic for
> > >> > fastboot for example, but booting partitions of the medi
to clutter board-specific config files with this
information?
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 se
On Tue, 25 Jul 2017 12:00:05 +0530
Lokesh Vutla <lokeshvu...@ti.com> wrote:
> On 7/25/2017 7:38 AM, Siarhei Siamashka wrote:
> > On Fri, 14 Jul 2017 08:53:20 -0500
> > Adam Ford <aford...@gmail.com> wrote:
> >
> >> Fixes 4bd754d8abef ("
e 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
___
U-Boot mailing list
U-Boot@lists.denx
also available in the mailing
list archive [2].
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
from that patch implied that no overwrite 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 <siarhei.siamas...@gmail.com> wrote:
> On Wed, 12 Jul 2017 16:34:50 +0200
> Maxime Ripard <maxime.rip...@free-electrons.com> wrote:
>
> > The -mno-unaligned-access flag used on ARM to prevent GCC from genera
of__(struct b)];
int dummy_a[3 - __alignof__(struct a)];
And then GCC 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
> access size). It seems the only time this would hit a dabort is if the
> > head of the buffer is not 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 __
M instruction supports unaligned memory accesses
too. For example, LDM/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
> 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
e passing --wno-unaligned-access, so the broken
> situation should not arise, and yet 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
), >reg->ntsr);
The same question here.
> + } else {
> + 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
efault #else
clause, because having it there is very error prone when adding
support for new SoCs. One may 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
arm/mach-sunxi/dram_timings/ddr3_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 1006
gt; dram_sunxi_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/ma
On Tue, 14 Mar 2017 20:06:42 +0530
Anand Moon <linux.am...@gmail.com> wrote:
> On 14 March 2017 at 15:24, Siarhei Siamashka <siarhei.siamas...@gmail.com>
> wrote:
> > You can just clone my git branch:
> >
> >git clone -b 20170306-unbreak-odroi
On Tue, 14 Mar 2017 18:01:11 +0900
Jaehoon Chung <jh80.ch...@samsung.com> wrote:
> On 03/14/2017 04:52 PM, Siarhei Siamashka wrote:
> > On Mon, 6 Mar 2017 12:18:50 +0200
> > Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:
> >
> >> On Thu,
On Tue, 14 Mar 2017 14:44:26 +0530
Anand Moon <linux.am...@gmail.com> wrote:
> Hi Siarhei/Jaehoon
>
> On 14 March 2017 at 14:31, Jaehoon Chung <jh80.ch...@samsung.com> wrote:
> > On 03/14/2017 04:52 PM, Siarhei Siamashka wrote:
> >> On Mon, 6 Mar 2017 1
On Mon, 6 Mar 2017 12:18:50 +0200
Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:
> On Thu, 12 Jan 2017 14:02:48 +0530
> Anand Moon <linux.am...@gmail.com> wrote:
>
> > Hi All,
> >
> > I tried to compile the latest u-boot for Odroid U3.
> > i
On Wed, 8 Mar 2017 09:30:07 -0500
Tom Rini <tr...@konsulko.com> 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
&
coherent with the L2
cache and the other L1 data caches."
Basically, disabling cache only disables allocation of new cache
lines. We still need to do proper cache maintenance.
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
On Mon, 6 Mar 2017 17:54:17 -0500
Tom Rini <tr...@konsulko.com> 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 <tr...@konsulko.com> wrote:
> >
> >
Hello,
On Fri, 23 Oct 2015 19:53:28 +0900
Minkyu Kang <mk7.k...@samsung.com> 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 modul
.
> ** 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
on we introduce a new 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 <tr...@konsulko.com>
[...]
--
Best regards,
Siarhei Siamashka
___
test my branch and confirm 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 <tr...@konsulko.com> 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
on 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 <siarhei.siamas...@gmail.com>
---
arch/arm/cpu
map2/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 <s
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
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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://l
AT, 0666);
> + if (fd_out < 0) {
> + perror("Open output file");
> + return EXIT_FAILURE;
> + }
> }
>
> /* read file to buffer to calculate checksum */
> @@ -115,7 +140,7
s can be passed to the
board_fit_config_name_match() 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
t wrong.
> + * Read the value directly from SID 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 *
div = 1UL << (sizeof(long) * 8 - 4);
> + } else {
> + num = va_arg(va, unsigned int);
> + div = 0x1000;
> + }
> if (!num) {
>
num = va_arg(va, unsigned int);
> + div = 0x1000;
> + }
> if (!num) {
> out_dgt(info, 0);
> } else {
> -
1_clk_cfg);
> +#endif
We can change this to:
if (IS_ENABLED(CONFIG_MACH_SUN6I))
writel(MBUS_CLK_DEFAULT, >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
mers are accessible.
> > + *
> > + * not inline to increase chances its in cache when called
> > + */
> > +void sdelay(unsigned long loops)
> > +{
> > + __asm__ volatile ("1:\n" "subs
uct something excessively complicated
and possibly fragile?
The 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
s functionality definitely belongs
to a separate patch and can 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
.
> > If this is too much, then please remove the 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-Suppo
null byte). Therefore,
the size of dest must be at least strlen(dest)+n+1.
>
> return msg;
> }
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
ff --git 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_PRE_CON
On Mon, 5 Sep 2016 09:23:00 +0100
Andre Przywara <andre.przyw...@arm.com> wrote:
> Hi,
>
> On 05/09/16 05:12, Siarhei Siamashka wrote:
> > On Mon, 5 Sep 2016 01:32:38 +0100
> > Andre Przywara <andre.przyw...@arm.com> wrote:
> >
> >> This comm
mport_r(_htab, (char *)spl->fel_script_address,
> + himport_r(_htab, (char *)(uintptr_t)spl->fel_script_address,
> spl->fel_uEnv_length, '\n', H_NOCLEAR, 0, 0, NULL);
> return;
> }
Reviewed-by: Siarhei Siamashka <siarhei.si
ine AHB1_ABP1_DIV_DEFAULT0x3190 /*
> AHB1=PLL6/6,APB1=AHB1/2 */
> -#else
> #define AHB1_ABP1_DIV_DEFAULT 0x00003180 /*
> 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
his patch is a reasonable
solution for v2016.09, so it is
Reviewed-by: Siarhei Siamashka <siarhei.siamas...@gmail.com>
> ---
> include/configs/sunxi-common.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/include/configs/sunxi-common.h b/include/config
is not safely accessible by the SPL (such as
the DRAM), causes a very early SPL deadlock.
Signed-off-by: Siarhei Siamashka <siarhei.siamas...@gmail.com>
---
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/a
te:
> > > > Hey guys,
> > > >
> > > > I just started trying out my Pine64 1GB and mainline U-Boot and I've
> > > > found that:
> > > > commit 1a83fb4a17d959d7b037999ab7ed7e62429abe34
> > > > Author: Siarhei Siamashka <
e not all 0 */
> if ((sid[3] & 0xff) == 0)
> sid[3] |= 0x80;
Using XOR is not a good idea, see my reply in the v1 patch discussion:
http://lists.denx.de/pipermail/u-boot/2016-July/262298.html
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi,
On Thu, 28 Jul 2016 20:35:21 +0200
Hans de Goede <hdego...@redhat.com> wrote:
> Hi,
>
> On 28-07-16 05:13, Chen-Yu Tsai wrote:
> > Hi,
> >
> > On Thu, Jul 28, 2016 at 3:14 AM, Siarhei Siamashka
> > <siarhei.siamas...@gmail.com> wrote:
> &g
the SoC generation?
We can calculate some kind of hash (CRC32? SHA256?) over the whole
SID. This will ensure that all the SID bits are 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 <s...@chromium.org> wrote:
> Hi,
>
> On 9 June 2016 at 18:33, Siarhei Siamashka <siarhei.siamas...@gmail.com>
> wrote:
> > Hi Simon,
> >
> > On Thu, 9 Jun 2016 17:36:10 -0700
> > Simon Glass <s...
Hi Simon,
On Thu, 9 Jun 2016 17:36:10 -0700
Simon Glass <s...@chromium.org> wrote:
> Hi,
>
> On 7 June 2016 at 05:28, Siarhei Siamashka <siarhei.siamas...@gmail.com>
> wrote:
> > Allwinner devices support SPI flash as one of the possible
> > bootable
mechanism ("bootcmd_fel").
> >
> > Signed-off-by: Bernhard Nortmann <bernhard.nortm...@web.de>
>
> 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
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
Hello,
On Tue, 7 Jun 2016 16:09:58 +0200
Bernhard Nortmann <bernhard.nortm...@web.de> wrote:
> Hello Siarhei!
>
> Am 06.06.2016 um 11:20 schrieb Siarhei Siamashka:
> > On Sun, 5 Jun 2016 15:01:30 +0200
> > Bernhard Nortmann <bernhard.nortm...@web.de
-by: Siarhei Siamashka <siarhei.siamas...@gmail.com>
---
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 un
On Sun, 5 Jun 2016 15:01:30 +0200
Bernhard Nortmann <bernhard.nortm...@web.de> 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 "
el_scriptsize"?
> + }
> return;
> }
> printf("sunxi SPL version mismatch: expected %u, got %u\n",
That said, I have no objections to supporting "uEnv.txt" for FEL boot,
as long as it works correctly and does not regress the existing
"boot.scr" support.
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
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 <siarhei.sia
n happen is that 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"
versio
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 <siarhei.siamas...@gmail.com>
---
arch/arm/include/asm/arch-sunxi/spl.h | 26 +++--
include/configs/
reserve [1], which should provide additional 4 or
5 KiB of space for the code. Still we need to be very careful 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/piperm
On Tue, 31 May 2016 01:48:05 +0300
Siarhei Siamashka <siarhei.siamas...@gmail.com> 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
> detec
not affect the boot0
usage (unless somebody can confirm SRAM C corruption with the
boot0 too).
Signed-off-by: Siarhei Siamashka <siarhei.siamas...@gmail.com>
---
arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/include/asm/arch
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 <siarhei.siamas...@gmail.com>
---
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
On Sat, 14 May 2016 03:14:25 +0300
Siarhei Siamashka <siarhei.siamas...@gmail.com> 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
ter used in the 'spl_boot_device' function, but this is out of
the scope of this patch.
Signed-off-by: Siarhei Siamashka <siarhei.siamas...@gmail.com>
---
Changes in v2:
- Increase the header size to 64 bytes instead of 48 bytes in order
to satisfy the VBAR alignment requirements.
arch/ar
ter used in the 'spl_boot_device' function, but this is out of
the scope of this patch.
Signed-off-by: Siarhei Siamashka <siarhei.siamas...@gmail.com>
---
arch/arm/include/asm/arch-sunxi/spl.h | 8 +++-
include/configs/sunxi-common.h| 12 ++--
2 files changed, 13 inserti
writel(0xaa55aa55, (ulong)CONFIG_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
other sample 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
> [3] https://gist.github.com/pietrus
0644
> --- a/configs/CHIP_defconfig
> +++ b/configs/CHIP_defconfig
> @@ -9,7 +9,6 @@ CONFIG_SPL=y
> CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=2"
> # CONFIG_CMD_IMLS is not set
> CONFIG_CMD_GPIO=y
> -CONFIG_AXP_DCDC2_VOLT=1300
> CONFIG_AXP_ALDO3_VOLT
gt; -#if defined CONFIG_AXP152_POWER || defined CONFIG_AXP209_POWER
> +#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;
>
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
On Wed, 23 Dec 2015 22:36:19 +0800
Chen-Yu Tsai <w...@csie.org> wrote:
> On Wed, Dec 23, 2015 at 6:14 PM, Siarhei Siamashka
> <siarhei.siamas...@gmail.com> wrote:
> > On Tue, 17 Nov 2015 15:32:30 +0100
> > Jens Kuske <jensku...@gmail.com> wrote:
> >
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 <siarhei.siamas...@gmail.com>
---
This is intended to be used together with the Allwinner H3 patches
from Jens Kuske:
http://lists.denx.de/pipermail/u-boot/2015-Nove
ber/230314.html
http://lists.denx.de/pipermail/u-boot/2015-October/231908.html
Signed-off-by: Siarhei Siamashka <siarhei.siamas...@gmail.com>
---
I have only tested that the compilation problem disappears for
me. It would be best if somebody could confirm whether the fix
is correct.
On Wed, 28 Oct 2015 00:27:48 +0100
Piotr Król <piotr.k...@3mdeb.com> 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 <piotr.k...@3mdeb.com> wrote:
> >
> > > On Sun,
On Mon, 26 Oct 2015 12:18:35 +0100
Piotr Król <piotr.k...@3mdeb.com> 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.
> >
1 - 100 of 372 matches
Mail list logo
