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
>
economically unreasonable
to design boards with anything older.
--
Best regards,
Siarhei Siamashka
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
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 curren
period, then
go ahead.
The timeline is preliminary and we can extend the deadlines a bit if
some features need more time (but preferably by no more than one extra
week). Do you have any comments or suggestions?
--
Best regards,
Siarhei Siamashka
--
You received this message because you are
hat you are currently setting AHB1
clock speed to 576 /2 /3 = 96 MHz ?
The "7.2.5.2. SPI Module Clock Source and Frequency" section of the
A83T manual says that "The SPI_SCLK can in the range from 3Khz to 100
MHZ" and also says that there is a requirement "AHB_CL
On Fri, 13 Nov 2015 11:06:01 +0200
Siarhei Siamashka wrote:
> On Fri, 13 Nov 2015 01:12:43 +0800
> Vishnu Patekar wrote:
>
> > Hello,
> >
> > On Thu, Nov 12, 2015 at 7:03 PM, Julian Calaby
> > wrote:
> >
> > > Hi Stefan,
> > &g
With the implementation from your e-mail I get:
== ZQ calibration DONE ==
ODT pull-up ODT pull-down DRV pull-up DRV pull-down
control 20 17 15 13
DX0/DX1 6 5 15 13
DX2/DX3 6 5
On Wed, 11 Nov 2015 23:03:24 +0100
Peter Korsgaard wrote:
> >>>>> "Siarhei" == Siarhei Siamashka writes:
>
> > The BROM in newer SoC variants doesn't enable MMU by default anymore.
> > So in order to benefit from e4b3da2b17ee9d7c5cab9b80e708b
On Sat, 14 Nov 2015 04:36:16 +0800
Vishnu Patekar wrote:
> Hello,
>
> On Fri, Nov 13, 2015 at 7:52 PM, Siarhei Siamashka <
> siarhei.siamas...@gmail.com> wrote:
>
> > On Fri, 13 Nov 2015 11:06:01 +0200
> > Siarhei Siamashka wrote:
> >
> > >
roves
from ~180 KB/s to ~510 KB/s.
This means that the CPU is not a bottleneck for FEL transfers
anymore. Further performance improvements are possible by
increasing the AHB1 clock speed in the U-Boot SPL (up to
something like ~900 KB/s).
Signed-off-by: Siarhei Siamashka
---
fel.c | 1 +
1 file
, more comments, redundant aw_fel_write call removal)
* Introduced a new patch with helper functions for reading/writing ARM
coprocessor registers
Siarhei Siamashka (3):
fel: Helper functions for reading/writing ARM coprocessor registers
fel: Support for enabling MMU after running SPL on new
This helps to reduce code duplication if we want to read and write
many different kinds of coprocessor registers.
Signed-off-by: Siarhei Siamashka
---
fel.c | 70 ---
1 file changed, 46 insertions(+), 24 deletions(-)
diff --git a
e BROM reside in the same 1MB section there and we need finer
granularity. In other words, enabling the MMU on A80 and A64 is
not supported yet.
Signed-off-by: Siarhei Siamashka
---
fel.c | 124 --
1 file changed, 122 insertions(+)
rs and explains
how these parameters should be calculated (they depend on the THS clock
frequency). No magic involved.
Currently the H3 manual is available from Orange Pi people and OLIMEX.
There is also an open request about releasing it "officially":
https://github.com/allwinner-zh/d
inting that was done under the '-v'
switch. So its removal can be probably done as a part of your
patch set.
I also think that we can just tag the 0.3 release right now. And
then in a few days/weeks release the next 0.4 version with the
progressbar feature and other improvements. Do y
tests and hopefully everything is fine.
--
Best regards,
Siarhei Siamashka
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hi Bernhard,
On Thu, 19 Nov 2015 15:28:47 +0100
Bernhard Nortmann wrote:
> Hi Siarhei!
>
> Am 19.11.2015 um 09:04 schrieb Siarhei Siamashka:
> > [...]
> > My biggest concern is the command line interface. It is basically
> > stateless vs. stateful approach. Yo
tutorials:
http://www.metaltoad.com/blog/beginners-guide-git-bisect-process-elimination
--
Best regards,
Siarhei Siamashka
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving ema
ne kilo(value) ((double)value / 1000.) /* SI prefix "k" */
> +#define kibi(value) ((double)value / 1024.) /* binary prefix "Ki", "K" */
Parentheses are needed around 'value'. This is necessary to correctly
handle something like "kilo(2000 + 2000)"
(double)size / 1000., t2 - t1,
> - (double)size / (t2 - t1) / 1000.);
> + double elapsed = aw_write_buffer(handle, buf, offset,
> size);
> + if (elapsed > 0)
> + pr_info("%.1f kB writte
psed = aw_write_buffer(handle, buf, offset,
> size, true);
> if (elapsed > 0)
> pr_info("%.1f kB written in %.1f sec (speed:
> %.1f kB/s)\n",
> kilo(size), elapsed, kilo(size) /
>
t)done / total : 0;
> + int i, pos = WIDTH * ratio;
> +
> + printf("\r%3.0f%% [", ratio * 100); /* current percentage */
> + for (i = 0; i < pos; i++) putchar('=');
> + for (i = pos; i < WIDTH; i++) putchar(' ');
> + printf("
ilo(speed));
>
> - if (done >= total) putchar('\n'); /* output newline when complete */
> fflush(stdout);
> }
> diff --git a/progress.h b/progress.h
> index 6c4dc7f..5eb767f 100644
> --- a/progress.h
> +++ b/progress.h
> @@ -28,6 +28,8 @@ typed
> + if (size > 0) {
> + progress_start(pflag_active ? progress_bar :
> NULL, size);
> + file_upload(handle, argv[3], strtoul(argv[2],
> NULL, 0));
> + }
If the file does not exist
for (i = 0; i < count; i++)
> + file_upload(handle, argv[4 + i*2],
> + strtoul(argv[3 + i*2],
> NULL, 0));
> +
> + skip += count * 2;
> +
se if (strcmp(argv[1], "read") == 0 && argc > 4) {
> size_t size = strtoul(argv[3], NULL, 0);
> void *buf = malloc(size);
Thanks, this looks good. Just the description of this new command is
missing in the help message text (whe
gauge_xxx(size_t total, size_t done)
> +{
> + if (total > 0) {
> + double speed = rate(done, progress_elapsed());
> + double eta = estimate(total - done, speed);
> + printf("XXX\n");
> + printf("%.0f\n", (fl
to github, even though I'm not
completely happy about certain aspects of them. The patches 6-9 may
need some additional fixes.
Oh, by the way. The "sunxi-tools:" prefix in the commit summaries is
redundant in the github repository (because we already know that the
whole thing is "
prevent
mali drivers from building every time").
But if we try to build both 'mali' and 'ump' modules statically,
then the linker complains about duplicated functions. In order
to resolve this problem, just mark the problematic functions
as 'weak'.
Signed-off
nt to be able to include the lima-memtester
test program into an initrd image without bothering about adding
kernel modules to the initrd image too.
Signed-off-by: Siarhei Siamashka
---
arch/arm/configs/sun4i_defconfig | 8 +++-
arch/arm/configs/sun5i_defconfig | 6 +++---
arch/arm/co
all, then the Mali userland blob
still can work and is able to render 3D graphics. However this
is done by using memcpy to copy data into the framebuffer for each
frame and the performance becomes ridiculously bad.
Signed-off-by: Siarhei Siamashka
---
arch/arm/plat-sunxi/core.c
good:
https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg00492.html
https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg00678.html
http://www.cubieforums.com/index.php/topic,1413.msg8745.html#msg8745
It basically wastes a lot of performance for almost nothing.
Signe
e old patches that I have
been using for ages. They serve exactly the same purpose: make
things work out of the box in a reasonable way.
These patches are also available in the following git branch:
https://github.com/ssvb/linux-sunxi/commits/20151202-more-cma-for-sunxi-3.4
Siarhei Siamash
enabled
for sun5i because it can allow to use USB ethernet dongles.
Also different localversion identifiers are set for in the
config files to avoid a possible clash between the names of
directories with kernel modules.
Signed-off-by: Siarhei Siamashka
---
arch/arm/configs/sun4i_defconfig | 6
necessary.
Do it only when CMA is enabled. Otherwise this may be dangerous when
the user controls the size of disp framebuffer reservation via kernel
cmdline.
Signed-off-by: Siarhei Siamashka
---
drivers/video/sunxi/disp/dev_fb.c | 21 +
1 file changed, 21 insertions(+)
diff
This allows to get rid of the fragile boot time memory reservation.
Now the amount of required framebuffer memory is calculated at
runtime, depending on the screen resolution (which may come from
FEX or from EDID).
Signed-off-by: Siarhei Siamashka
---
drivers/video/Kconfig | 3
serve'
can be used to change the cedar memory buffer size to something
larger than 80MB. Since libvdpau-sunxi implemented subtitles
support, it needs more memory and 80MB may be not enough.
Signed-off-by: Siarhei Siamashka
---
drivers/media/video/sunxi/sunxi_ce
open /dev/cedar_dev just block until the current user closes it.
Signed-off-by: Siarhei Siamashka
---
drivers/media/video/sunxi/sunxi_cedar.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/sunxi/sunxi_cedar.c
b/drivers/media/video/sunxi
djustment is also done by this patch.
Signed-off-by: Siarhei Siamashka
---
sys_config/h3/xunlong_orange_pi_pc.fex | 86 --
1 file changed, 52 insertions(+), 34 deletions(-)
diff --git a/sys_config/h3/xunlong_orange_pi_pc.fex
b/sys_config/h3/xunlong_orange_pi_pc.f
This patch makes both red and green LEDs available in /sys/class/leds
instead of probably having them reserved for some special purposes
(such as a standby mode indicator?). Being able to control the state
of LEDs from applications and scripts is quite useful.
Signed-off-by: Siarhei Siamashka
improvements.
Signed-off-by: Siarhei Siamashka
---
sys_config/h3/xunlong_orange_pi_pc.fex | 814 +
1 file changed, 814 insertions(+)
create mode 100644 sys_config/h3/xunlong_orange_pi_pc.fex
diff --git a/sys_config/h3/xunlong_orange_pi_pc.fex
b/sys_config/h3
On Fri, 13 Nov 2015 18:22:10 +0100
Jens Kuske wrote:
> On 13/11/15 13:36, Siarhei Siamashka wrote:
> > On Wed, 11 Nov 2015 18:26:54 +0100
> > Jens Kuske wrote:
> >
> >> Based on some guessing and comparing with the parts I initially started
> >> disa
Hello,
On Wed, 9 Dec 2015 19:29:49 +0100
Jens Kuske wrote:
> On 09/12/15 09:40, Siarhei Siamashka wrote:
> > Thanks for the explanations. I finally got lima-memtester up and
> > running on H3 hardware (not that it was difficult, but just the amount
> > of unnecessary compat
On Mon, 7 Dec 2015 12:17:04 +0100
Bernhard Nortmann wrote:
> Hi Siarhei!
>
> Am 30.11.2015 um 12:44 schrieb Siarhei Siamashka:
> > Hello,
> >
> > I think that patches 1-5 can be pushed to github, even though I'm not
> > completely happy about certai
On Mon, 7 Dec 2015 12:03:41 +0100
Bernhard Nortmann wrote:
> Am 30.11.2015 um 12:30 schrieb Siarhei Siamashka:
> > What if "name" is, for example, a directory instead of a file?
> >
> > [...]
> > If the file does not exist, what is the "sunxi-fel"
. But looks like Hans de Goede has also
independently encountered the same bugs and already fixed them:
https://github.com/linux-sunxi/sunxi-tools/commit/55eec70ceafc4b8b25b4ddcd613c9ca10e41dcf7
--
Best regards,
Siarhei Siamashka
--
You received this message because you are subscribed to the Google
in $(TOOLS) $(FEXC_LINKS) $(TARGET_TOOLS) '*.o' '*.swp'; do \
> echo "$$x"; \
Thanks, pushed to git.
--
Best regards,
Siarhei Siamashka
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group
gt; to dump the script.bin blob from RAM via reading /dev/mem.
> + To build this, get a toolchain, and run:
> + make CROSS_COMPILE=arm-linux-gnueabihf- sunxi-script_extractor
>
> This software is licensed under the terms of GPLv2+ as defined by the
> Free Software Foundation, d
ould like to go into
> sunxi-tools, possibly before you tag a 1.3 release. It's not urgent
> (could be postponed to a later point in time), but I think it would
> be nice to include these into a "release point".
Well, last minute changes are always a sort of a lottery. It would
t more test results in a few days which radically change
the statistics, probably using 624 MHz for DRAM on Orange Pi PC would
be reasonable.
--
Best regards,
Siarhei Siamashka
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To u
On Thu, 10 Dec 2015 10:29:52 +0100
Jens Kuske wrote:
> On 10/12/15 03:13, Siarhei Siamashka wrote:
> > Hello,
> >
> > On Wed, 9 Dec 2015 19:29:49 +0100
> > Jens Kuske wrote:
> >
> >> On 09/12/15 09:40, Siarhei Siamashka wrote:
> >> Th
On Wed, 16 Dec 2015 12:14:10 +0100
Bernhard Nortmann wrote:
> Am 16.12.2015 um 08:16 schrieb Siarhei Siamashka:
> > [...]
> > After this change, now both "spl" and "uboot" commands always execute
> > U-Boot in the end :-(
> >
> > Right now
On Wed, 9 Dec 2015 00:40:18 -0800 (PST)
Thomas Kaiser wrote:
> Siarhei Siamashka:
>
> > Extracted from the Lubuntu_1404_For_OrangePiPC_v0_8_0_.img.xz image:
> >
> > http://www.orangepi.org/downloadresources/orangepipc/oragepipc_4a0e8d960f7f0a52606dfaba58.html
> >
On Sat, 19 Dec 2015 22:18:28 +0100
Thomas Kaiser wrote:
> Siarhei Siamashka wrote:
>
> > It's likely that the credit for "unlocking" the 1.5 GHz clock speed
> > actually belongs to third-party modders.
>
> Thanks for clarifying this (and all the
Hi,
On Wed, 16 Dec 2015 10:11:38 +0100
Hans de Goede wrote:
> Hi,
>
> On 16-12-15 08:35, Siarhei Siamashka wrote:
> > On Thu, 10 Dec 2015 04:31:05 -0800 (PST)
> > Thomas Kaiser wrote:
> >
> >> Hi,
> >>
> >> Hans de Goede wrote:
>
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
--
B
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
r0
`-> 0x002008402de9 push {r3, lr}
0x002408309fe5 ldr r3, [pc, 8] ; [:4]=0x0020 ; '4'
0x00280fe0a0e1 mov lr, pc
,==< 0x002c13ff2fe1 bx r3
|0x00300880bde8 pop {r3, pc}
My r
y be still problematic though. Because even
after artificially adding -mthumb option when using my toolchain, I
get a much more reasonable short thumb2 code without any junk in the
beginning:
$ r2 -a arm -b 16 fel-sdboot.sunxi
[0x]> s 0x20
[0x0020]> pd
0x002008b5 push {r
a20/superpi.fex b/sys_config/a20/superpi.fex
Hi,
Thanks. Would it be probably better to push it to sunxi-boards
as "foxconn_superpi.fex" in order to avoid any potential namespace
clashes with LeMaker, SinoVoip and any other possible contenders?
--
Best regards,
Siarhei Siamashka
--
f bin2fex or fex2bin appear in
> its executable name to select its mode, no longer an exact match).
>
> Since theses changes ended up with something very different than the
> current tools, and after a little chat with Siarhei Siamashka, i think
> the best thing to do is just kee
.
Thanks!
--
Best regards,
Siarhei Siamashka
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more opti
inner H3 support and everyone is welcome to try it on the
boards like Orange Pi PC. I also have some sunxi-tools improvements
in the queue, which are going to make developing code for the
OpenRISC core and debugging it much easier. Wanted to make an
announcement when everything is ready, but you are ki
e.
New readl/writel commands for reading/writing hardware registers,
which can be used for various useful things (a more advanced OpenRISC
support will need this functionality).
The last patch (unrelated to the OpenRISC core) adds USB FEL boot
support for Allwinner A64.
Siarhei Siamashka (7)
0x24000-0x2 and have
48 KiB of available space there.
Signed-off-by: Siarhei Siamashka
---
fel.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/fel.c b/fel.c
index 419f16a..71b12b5 100644
--- a/fel.c
+++ b/fel.c
@@ -479,6 +479,19 @@ sram_swap_buffers
This allows the SRAM section A2 to be exclusively used by
the OpenRISC core.
There are no substantial differences between H3 and A10/A13/A20.
It just has 64 KiB of SRAM starting at the address 0x0 instead
of 48 KiB.
Signed-off-by: Siarhei Siamashka
---
fel.c | 6 +++---
1 file changed, 3
1c23800: 87 00 00 00 __ __ __ __ __ __ __ __ __ __ __ __
Apparently, FEL tries to read data one byte at a time and this does
not always work correctly. Introducing new commands to explicitly
do 32-bit reads and writes helps:
$ sunxi-fel readl 0x01c23800
0x16254187
Signed-off-by: Siarhei Siamas
-Boot releases do not use them yet.
Signed-off-by: Siarhei Siamashka
---
fel.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/fel.c b/fel.c
index 59f0f72..0da3dc7 100644
--- a/fel.c
+++ b/fel.c
@@ -464,13 +464,17 @@ typedef struct {
* at 0x2000 (and gr
That would be a more appropriate name. And A31 is going to
implement this in a different way and give the SRAM back to
OpenRISC.
Signed-off-by: Siarhei Siamashka
---
fel.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/fel.c b/fel.c
index 0da3dc7
The SCTLR bits are somewhat different because the V bit is set
to 0 on A64 (Low exception vectors, base address 0x) and
the UNK bit (Reads of this bit return an UNKNOWN value) is also not
the same as on the other SoCs. So the SCTLR check can be relaxed.
Signed-off-by: Siarhei Siamashka
the lower
part of it is reserved for internal use by the sunxi-fel
tool). The 0x-0x1FFF addresses range is reserved for
passing data from the SPL to the main U-Boot binary (via
the SPL header) and is also off limits.
Signed-off-by: Siarhei Siamashka
---
fel.c | 16
1 file chan
On Mon, 25 Jan 2016 06:50:54 +0200
Siarhei Siamashka wrote:
> The SCTLR bits are somewhat different because the V bit is set
> to 0 on A64 (Low exception vectors, base address 0x) and
> the UNK bit (Reads of this bit return an UNKNOWN value) is also not
> the same as on th
willing to step up as the 3.4
kernel maintainer for Allwinner H3?
--
Best regards,
Siarhei Siamashka
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
er sources from Allwinner are also referring to A64 as
AW1689, which makes some sense because it is the chip id number that
is accessible for runtime identification via reading the SRAM_VER_REG
hardware register:
http://linux-sunxi.org/SRAM_Controller_Register_Guide#SRAM_VER_REG
So would it
nto the
> l2 cache.
The original discussion thread has more than enough hints about what
can be tried to implement this. So feel free to start coding and share
your findings with us.
Or are you actually trying to hire somebody to do this job for you?
--
Best regards,
Siarhei Siamashka
--
Yo
d-lima-memtester
Also compile the right mainline U-Boot binary for your board and
generate the right script.bin from your FEX file.
--
Best regards,
Siarhei Siamashka
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe
'.\n", dev_arg);
exit(1);
}
> + } else
> + break; /* no valid (prefix) option detected, exit loop
> */
> + argc -= 1;
> + argv += 1;
> }
> +
> + request_libusb_handle(&handle, busnum, d
;
> + exit(1);
> + }
> + } else
> + break; /* no valid (prefix) option detected, exit loop
> */
> + argc -= 1;
> + argv += 1;
> }
> +
> + handle = open_fe
On Thu, 17 Mar 2016 13:55:25 +0100
Bernhard Nortmann wrote:
> Am Montag, 25. Januar 2016 05:51:02 UTC+1 schrieb Siarhei Siamashka:
> > The read/write operations done by FEL are not suitable for accessing
> > hardware registers. For example, trying to read a SID value using
&g
On Thu, 17 Mar 2016 18:31:42 +0100
Bernhard Nortmann wrote:
> Am Montag, 25. Januar 2016 05:51:02 UTC+1 schrieb Siarhei Siamashka:
> > Doing certain operations may need uploading and executing code
> > on the device. For example, such operations right now are
> > rea
libusb_attach_kernel_driver(handle, iface_detached);
Reviewed-by: Siarhei Siamashka
--
Best regards,
Siarhei Siamashka
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emai
ort 40KiB SPL size for making future improvements
possible, avoid clashing with the SRAM area reserved for the OpenRISC
firmware).
Regarding the SRAM memory layout in the FEL mode, the following wiki
page provides some information:
https://linux-sunxi.org/SRAM_dumps_from_A13_in_FEL_mode
--
On Sun, 20 Mar 2016 14:03:24 +0100
Bernhard Nortmann wrote:
> Am 20.03.2016 um 13:53 schrieb Siarhei Siamashka:
> > Thanks, also adding an extra
> >
> >|| busnum < 0 || devnum < 0
> >
> > check here would make it perfect.
> >
> &g
mands
with caution!" warnings (which many people will miss or ignore anyway),
it's better to do a proper job in the first place.
> By now it has received a bit of testing on various hardware (during the
> course of https://github.com/linux-sunxi/sunxi-tools/issues/37), so feel
On Sun, 20 Mar 2016 16:09:40 +0100
Bernhard Nortmann wrote:
> Hi Siarhei!
>
> Am 20.03.2016 um 15:49 schrieb Siarhei Siamashka:
> > This patch is just unsafe if pushed alone, that's why it implicitly
> > depends on the other "fel: Move the temporary scratch buffer
00) {
> fprintf(stderr, "Unexpected TTBCR (%08X)\n", ttbcr);
> exit(1);
> }
>
> + ttbr0 = aw_get_ttbr0(usb, sram_info);
> if (ttbr0 & 0x3FFF) {
> fprintf(stderr, "Unexpected TTBR0 (%08X)\n", ttb
ally, ignore M/Z/I bits and expect no TEX remap */
> + /* Basically, ignore M/Z/I/V bits and expect no TEX remap */
> sctlr = aw_get_sctlr(usb, sram_info);
> - if ((sctlr & ~((1 << 12) | (1 << 11) | 1)) != 0x00C52078) {
> + if ((sctlr & ~((0x7 <
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
> [3] https://gist.github.com/pietrushnic/
% sure until somebody confirms this.
Why are you asking this question?
--
Best regards,
Siarhei Siamashka
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an emai
On Thu, 21 Apr 2016 16:14:13 -0400
"jonsm...@gmail.com" wrote:
> On Thu, Apr 21, 2016 at 4:09 PM, Siarhei Siamashka
> wrote:
> > On Thu, 21 Apr 2016 13:38:19 -0400
> > "jonsm...@gmail.com" wrote:
> >
> >> On Thu, Apr 21, 2016 at 1
On Thu, 21 Apr 2016 19:56:10 -0400
"jonsm...@gmail.com" wrote:
> On Thu, Apr 21, 2016 at 7:45 PM, jonsm...@gmail.com
> wrote:
> > On Thu, Apr 21, 2016 at 6:01 PM, Siarhei Siamashka
> > wrote:
> >> As for designing an A64 board, unless you really want a
ed information and too many SD card
images to try actually does more harm than good.
--
Best regards,
Siarhei Siamashka
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it,
On Mon, 30 May 2016 17:12:53 +0200
Boris Brezillon wrote:
> Generating raw NAND images is particularly useful for boot0 images
> creation since the mainline driver is not supporting the funky layout
> used by Allwinner's ROM code to load the boot0 binary from NAND.
>
> This tools also allows one
ter we can also have digital signatures
verification built into the sunxi-fel, and other nice things.
Boris, I think that your NAND use case is not very much different in
principle. You can't expect the users to desolder the NAND chip and
use an external NAND programmer tool when they
On Mon, 30 May 2016 19:02:13 +0200
Boris Brezillon wrote:
> On Mon, 30 May 2016 19:46:17 +0300
> Siarhei Siamashka wrote:
>
> > On Mon, 30 May 2016 17:24:16 +0200
> > Boris Brezillon wrote:
> >
> > > Hi Hans,
> > >
> > > On Mon, 3
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
--
You received this me
(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
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,
ompletely independent and can be
resolved independently at their own pace.
--
Best regards,
Siarhei Siamashka
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it,
running the code in u-boot from SRAM and the L1 cache is not
enabled, then the instructions fetch may become a bottleneck.
> Does anyone knows how higher performance can be achieved?
Maybe buy a different higher performance SoC or better optimize the
software?
--
Best regards,
Siarhei Siamashka
1 - 100 of 550 matches
Mail list logo
