Re: OrangePI Zero3 memory timing testing
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 accessing aliased physical memory addresses). So just having a generous delay may do the job and solve all the timing issues. Another comment is about the use of memtester program. It's actually not very sensitive to memory reliability problems as-is. Back in A10/A20 and H3 days, it was necessary to run memtester simultaneously with a Mali GPU rendered spinning textured cube animation for best results: https://github.com/ssvb/lima-memtester For example, a misconfigured H3 DRAM was showing no problems at all in the memtester test at 624MHz, but couldn't survive memtester together with the spinning textured cube until downclocked to 384MHz. Only aggressive simultaneous access from both CPU and GPU really exposes reliability problems. The other types of DMA transfers couldn't replace the GPU. It was also possible to use the G2D accelerator instead of the Mali GPU, but only when performing 90 degrees rotations. Doing simple non-rotated blits with G2D was useless and couldn't expose reliability problems. I would suggest to install 3D drivers (whatever is available for the modern kernels nowadays) and run some textured spinning cube demo together with memtester before deciding that your DRAM configuration is alright. On Thu, Nov 30, 2023 at 2:11 AM Andre Przywara wrote: > > Hi Stephen, > > On 29/11/2023 18:45, Stephen Graf wrote: > > Some testing results: > > > > With the default DRAM timing of 30x24=720, most often when my system > > boots it comes up with DRAM 2G, but I have a 1G system. Once in a while > > the boot shows 1G. When it shows 2G the linux OS also shows 2G and > > continuing does not make much sense. > > > > On one boot where u-boot reported 1G the OS agreed and I ran memtester > > successfully. > > > > If I build u-boot with CONFIG_DRAM_CLK=792 (33*24=792) I have never seen > > my system boot with anything other than DRAM 1G showing in u-boot. I ran > > Interesting, many thanks for the elaborate experiments! > To be fair, the timing parameters were from Xunlong's setup, so with 792 > MHz, but I remember that in my early testing this failed more often than > not, so I reverted back to 720MHz. But I had different parameters back > then, I believe. I will try to arrange some boot loop, to see how it > fares with the 792 MHz, though I believe you that it's more stable. > If that works, I will send a v2 with the USB and the DRAM clock fixed. > > Thanks again for testing and the report! > > Cheers, > Andre > > > memtester successfully and this system has been stable running linux 6.6.2. > > > > Andre, if you can put together a few patches I can test them to see > > which works. > > > > If anyone else with different variations of the Zero3 would test with > > the two DRAM timings and report results. > > > > I also use the Zunlong image on occasion and it consistently shows 1G > > and from my poking around I think it runs at a 792 clk. > > > > > > Console output with DRAM default: > > > > U-Boot 2024.01-rc3-00028-g43f2873fa9-dirty (Nov 28 2023 - 22:46:39 > > -0800) Allwinner Technology > > > > CPU: Allwinner H616 (SUN50I) > > Model: OrangePi Zero3 > > DRAM: 2 GiB > > > > Last login: Wed Nov 29 09:35:15 PST 2023 on ttyS0 > > root@orangepizero3:~# free -h > > totalusedfree shared buff/cache > > available > > Mem: 1.9Gi 139Mi 1.7Gi 360Ki82Mi > > 1.7Gi > > Swap: 0B 0B 0B > > > > > > U-Boot 2024.01-rc3-00028-g43f2873fa9-dirty (Nov 28 2023 - 22:46:39 > > -0800) Allwinner Technology > > > > CPU: Allwinner H616 (SUN50I) > > Model: OrangePi Zero3 > > DRAM: 1 GiB > > > > root@orangepizero3:~# free -h > > totalusedfree shared buff/cache > > available > > Mem: 917Mi 137Mi 766Mi 360Ki79Mi > > 780Mi > > Swap: 0B 0B 0B > > > > > > root@orangepizero3:~# memtester 700M 1 > > memtester version 4.6.0 (64-bit) > > Copyright (C) 2001-2020 Charles Cazabon. > > Licensed under the GNU General Public License version 2 (only). > > > > pagesize is 4096 > > pagesizemask is 0xf000 > > want 700MB (734003200 bytes) > > got 700MB (734003200 bytes), trying mlock ...locked. > > Loop 1/1: > >Stuck Address : ok > >Random Value: ok > >Compare XOR : ok > >Compare SUB : ok > >Compare MUL : ok > >Compare DIV : ok > >Compare OR : ok > >Compare AND : ok > >Sequential Increment: ok > >Solid Bits : ok > >Block Sequential: ok > >Checkerboard: ok > >Bit Spread : ok > >Bit Fl
Re: early stage debugging on a real product
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 > > > > wrote: > > > > > I think you should be more worried about the UART! > > > > > > How? There is no UART (there are ports, but all of them are occupied > > > by real devices wired up). The only connector is microB and getting > > > USB to work in a gadget mode seems to me a harder task to achieve. > > > > The board designers should be severely punished. Do you have post codes? > > > > Some boards have an FTDI chip to do the USB/serial conversion but I > > guess your one does not. > > It's not a board. As I stated in the subject line it's a real product > (tablet / phone). Does this tablet / phone have an MMC slot? For example, on all Allwinner tablets it is technically possible to use MMC pins for UART via a different non-standard pin mux setup and a breakout board: https://linux-sunxi.org/MicroSD_Breakout https://linux-sunxi.org/File:MSI_Primo81_and_MicroSD_breakout.jpg Also are you sure that there are really no UART pads on the PCB to solder some wires if you disassemble your tablet / phone?
Re: [U-Boot] [PATCH] Fix unreliable detection of DRAM size on Orange Pi 3
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 you please apply this patch to the sunxi tree, so that it
> > > doesn't get lost.
> > >
> > > thank you,
> > > Ondrej
> > >
> > > On Mon, Jul 29, 2019 at 01:39:42AM +0200, megous hlavni wrote:
> > > > From: Ondrej Jirman
> > > >
> > > > Orange Pi 3 has 2 GiB of DRAM, that sometime get misdetected
> > > > as 4 GiB, due to false negative result from mctl_mem_matches()
> > > > when detecting number of column address bits. This leads to
> > > > u-boot detecting more address bits than there are and the
> > > > boot process hangs shortly after.
> > > >
> > > > In mctl_mem_matches() we need to wait for each write to finish,
> > > > separately. Without this, the check is not reliable for some
> > > > unknown reason, probably having to do with unpredictable memory
> > > > access ordering.
> > > >
> > > > Patch was made with help from André Przywara, who noticed that
> > > > my original idea about detection failing due to read-back from
> > > > cache without involving DRAM was false, because data cache is
> > > > still of at the time of the DRAM size autodetection.
> > > >
> > > > Signed-off-by: Ondrej Jirman
> > > > Cc: André Przywara
> > > > ---
> > > > arch/arm/mach-sunxi/dram_helpers.c | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/arch/arm/mach-sunxi/dram_helpers.c
> > > > b/arch/arm/mach-sunxi/dram_helpers.c
> > > > index 239ab421a8..6dba448638 100644
> > > > --- a/arch/arm/mach-sunxi/dram_helpers.c
> > > > +++ b/arch/arm/mach-sunxi/dram_helpers.c
> > > > @@ -30,6 +30,7 @@ bool mctl_mem_matches(u32 offset)
> > > > {
> > > > /* Try to write different values to RAM at two addresses */
> > > > writel(0, CONFIG_SYS_SDRAM_BASE);
> > > > + dsb();
> > > > writel(0xaa55aa55, (ulong)CONFIG_SYS_SDRAM_BASE + offset);
> > > > dsb();
> > > > /* Check if the same value is actually observed when reading
> > > > back */
> > > > --
> >
> > Hi!
> >
> > This looks like resurfacing of the old problem, which did not get a
> > complete fix back in 2016:
> >https://lists.denx.de/pipermail/u-boot/2016-April/251803.html
> >
> > Now the main question is whether the DSB instruction's barrier
> > magic is really required here or maybe it's just a timing issue.
>
> That's certainly possible, because without this patch, the problem
> appears intermittently, and not always. I also have the same end
> result, where mctl_mem_matches returns false when it should not.
You could also try to see if the problem becomes easier or harder
to reproduce if you change the CPU or DRAM clock speed.
> > Could you please 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 this make the problem disappear?
> >
> >
> > I suspect that we may be dealing with some sort of buffering in
> > the DRAM controller itself and the only reason why DSB helps is
> > that it introduces some delay because it's a rather slow
> > instruction.
>
> Thanks for suggestions. If it's just the delay, then whatever delay
> dsb introduces seems enough. It'll probably need just a small delay,
> because most of the time it works without one.
It still would be better to estimate how long is the delay introduced
by a single DSB instruction. If it's small, then going from one DSB
instructions to two DSB instructions might be not enough to completely
eliminate the problem. Or it might fully fix the problem on your
Orange Pi 3 board, but then show up again on some other SoC with a
different CPU clock speed.
I agree that we need to ensure that the two write instructions
do not get reordered relative to each other. And also ensure
that the second write instruction and read and not reordered
relative to each other either
Re: [U-Boot] [PATCH] Fix unreliable detection of DRAM size on Orange Pi 3
On Sat, 24 Aug 2019 22:07:43 +0200
Ondřej Jirman wrote:
> Hi Jagan,
>
> can you please apply this patch to the sunxi tree, so that it
> doesn't get lost.
>
> thank you,
> Ondrej
>
> On Mon, Jul 29, 2019 at 01:39:42AM +0200, megous hlavni wrote:
> > From: Ondrej Jirman
> >
> > Orange Pi 3 has 2 GiB of DRAM, that sometime get misdetected
> > as 4 GiB, due to false negative result from mctl_mem_matches()
> > when detecting number of column address bits. This leads to
> > u-boot detecting more address bits than there are and the
> > boot process hangs shortly after.
> >
> > In mctl_mem_matches() we need to wait for each write to finish,
> > separately. Without this, the check is not reliable for some
> > unknown reason, probably having to do with unpredictable memory
> > access ordering.
> >
> > Patch was made with help from André Przywara, who noticed that
> > my original idea about detection failing due to read-back from
> > cache without involving DRAM was false, because data cache is
> > still of at the time of the DRAM size autodetection.
> >
> > Signed-off-by: Ondrej Jirman
> > Cc: André Przywara
> > ---
> > arch/arm/mach-sunxi/dram_helpers.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/mach-sunxi/dram_helpers.c
> > b/arch/arm/mach-sunxi/dram_helpers.c
> > index 239ab421a8..6dba448638 100644
> > --- a/arch/arm/mach-sunxi/dram_helpers.c
> > +++ b/arch/arm/mach-sunxi/dram_helpers.c
> > @@ -30,6 +30,7 @@ bool mctl_mem_matches(u32 offset)
> > {
> > /* Try to write different values to RAM at two addresses */
> > writel(0, CONFIG_SYS_SDRAM_BASE);
> > + dsb();
> > writel(0xaa55aa55, (ulong)CONFIG_SYS_SDRAM_BASE + offset);
> > dsb();
> > /* Check if the same value is actually observed when reading back */
> > --
Hi!
This looks like resurfacing of the old problem, which did not get a
complete fix back in 2016:
https://lists.denx.de/pipermail/u-boot/2016-April/251803.html
Now the main question is whether the DSB instruction's barrier
magic is really required here or maybe it's just a timing issue.
Could you please 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 this make the problem disappear?
I suspect that we may be dealing with some sort of buffering in
the DRAM controller itself and the only reason why DSB helps is
that it introduces some delay because it's a rather slow
instruction.
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] exynos: allow SPL to build in thumb mode
On Wed, 2 Jan 2019 14:31:41 +0100
Guillaume GARDET wrote:
> Building peach-pi smdk5420 and peach-pit with thumb mode for SPL
> ends-up in the following error:
>
> Error: Thumb encoding does not support an immediate here -- `msr
> cpsr_c,#0x13|0xC0'
>
> Use an intermediate register to be able to use thumb for exynos5 SPL.
>
>
> Signed-off-by: Guillaume GARDET
>
> Cc: Albert Aribaud
> Cc: Minkyu Kang
> Cc: Tom Rini
>
> ---
> arch/arm/mach-exynos/include/mach/system.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-exynos/include/mach/system.h
> b/arch/arm/mach-exynos/include/mach/system.h
> index 4837781957..81fa9800b4 100644
> --- a/arch/arm/mach-exynos/include/mach/system.h
> +++ b/arch/arm/mach-exynos/include/mach/system.h
> @@ -58,7 +58,8 @@ struct exynos5_sysreg {
> /* Move 0xd3 value to CPSR register to enable SVC mode */
> #define svc32_mode_en() __asm__ __volatile__ \
> ("@ I&F disable, Mode: 0x13 - SVC\n\t" \
> - "msr cpsr_c, #0x13|0xC0\n\t" : : )
> + "mov r0, #0x13|0xC0\n\t" \
> + "msr cpsr_c, r0\n\t" : : )
This line needs "r0" to be also added to the clobber list. If you
don't do this, then you may encounter 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 option is to just use something like this and give
the compiler freedom to pick any register:
"msr cpsr_c, %0\n\t" : : "r"(0x13|0xC0))
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] sunxi: support multiple memory banks
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-common.h looks like this: > > > > #define CONFIG_NR_DRAM_BANKS1 > > #define PHYS_SDRAM_0CONFIG_SYS_SDRAM_BASE > > #define PHYS_SDRAM_0_SIZE 0x8000 /* 2 GiB */ > > > > which seems to match the memory map for the a20. > > > > Question: > > While addressing 2gb ram works using one dram bank - will it work if there > > are two dram banks needed? > > These defines in U-Boot are not directly related to the DRAM > controller setup. They just allow to have multiple disconnected > DRAM areas in the physical address space, but on Allwinner > hardware the DRAM is typically (or even always?) represented > as a single contiguous chunk of memory in the address space. > > Did you actually mean support for multiple ranks? > https://en.wikipedia.org/wiki/Memory_rank > > To the best of my knowledge the A20 SoC has one chip select > pin (SCS), so it might support more than one rank. That said, > I'm not aware of any existing A10 or A20 board with a > double rank DRAM configuration. And the DRAM init code in > U-Boot for the A10/A13/A20 SoCs does not support multiple > ranks at the moment (since it was not possible to test > such configuration on real hardware). > > If somebody wants to use 2GB on an A20 board in a two ranks > configuration, then it's probably best to 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. Hmm, actually with just a single chip select pin, A20 probably only supports one rank. There was a blog post from Olimex about the differences between A10 and A20: https://olimex.wordpress.com/2013/04/05/allwinners-a10-and-a20-are-they-really-pin-to-pin-compatible-and-drop-in-replacement/ Basically, the second chip select pin (SCS1) had been replaced by an extra address line (A15) in A20, which allowed to have 2GB RAM using four x8 DRAM chips in a single rank configuration. A good example of such board is Cubietruck. It is A10 SoC that theoretically supports multiple ranks. But again, I'm not aware of any real A10 device with 2GB of RAM and using the double rank configuration. -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] sunxi: support multiple memory banks
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-common.h looks like this: > > #define CONFIG_NR_DRAM_BANKS 1 > #define PHYS_SDRAM_0 CONFIG_SYS_SDRAM_BASE > #define PHYS_SDRAM_0_SIZE 0x8000 /* 2 GiB */ > > which seems to match the memory map for the a20. > > Question: > While addressing 2gb ram works using one dram bank - will it work if there > are two dram banks needed? These defines in U-Boot are not directly related to the DRAM controller setup. They just allow to have multiple disconnected DRAM areas in the physical address space, but on Allwinner hardware the DRAM is typically (or even always?) represented as a single contiguous chunk of memory in the address space. Did you actually mean support for multiple ranks? https://en.wikipedia.org/wiki/Memory_rank To the best of my knowledge the A20 SoC has one chip select pin (SCS), so it might support more than one rank. That said, I'm not aware of any existing A10 or A20 board with a double rank DRAM configuration. And the DRAM init code in U-Boot for the A10/A13/A20 SoCs does not support multiple ranks at the moment (since it was not possible to test such configuration on real hardware). If somebody wants to use 2GB on an A20 board in a two ranks configuration, then it's probably best to 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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] configs: Lower Lamobo R1 DRAM clock rate to 384 MHz
On Fri, 15 Jun 2018 22:52:39 +0200 Paul Kocialkowski wrote: > When running at 432 MHz, the Lamobo R1 DRAM tends to get corrupted under > stressing workloads. Yes, it is well known that Allwinner devboards tend to have overclocked settings out of the box and poor reliability track record because each board vendor is trying to clock this low end hardware as high as possible in order to look more "competitive". You can find more information about this problem here: https://linux-sunxi.org/Hardware_Reliability_Tests > Reducing the clock rate to 384 MHz results in significantly-improved > stability. It would be great if we could get the reliability problems completely resolved on this board rather than just improved. > One reliable way to trigger a corruption at 432 MHz is to run > I/O-intensive operations on an attached SATA disk. The same operations > when operating the DRAM at 384 MHz typically go fine. Yes, concurrent access to the DRAM controller from more than one peripheral exposes reliability problems. That's why we have the lima-memtester tool at least for A10/A20 hardware, which does a stress test for DRAM reliability by using CPU+Mali simultaneously: https://github.com/ssvb/lima-memtester/ I also did some experiments with CPU+Mali+G2D (simultaneous access from 3 sources) and CPU+G2D (use G2D instead of Mali) and the highest reliable DRAM clock speeds under these workloads were pretty much the same. So I suspect that CPU+SATA is about as stressful as any other combination. And you can probably just run a regular memtester tool together with some SATA activity in the background (I'm assuming that you did just that when debugging this problem). Still I would suggest you to try the lima-memtester tool too. It requires a legacy 3.4 kernel. If you are really lazy, then you can even try this kernel branch from my github repository: https://github.com/ssvb/linux-sunxi/tree/20151206-embedded-lima-memtester The embedded initramfs automatically starts lima-memtester, so you only need to boot this kernel image and watch the serial console log. The only other thing is a proper script.bin file for your board (created from a fex file). If you are interested in a more advanced stuff (finding better DRAM settings rather than just downclocking DRAM until it stops failing), then you may want to check this wiki page: https://linux-sunxi.org/A10_DRAM_Controller_Calibration For example, I had to downclock DRAM from 408MHz to 360MHz in the Linksprite_pcDuino_defconfig in the past, you can find a detailed analysis in the commit log: https://lists.denx.de/pipermail/u-boot/2015-October/229567.html > For some unexplained reason, running at 408 MHz worsens the situation. > > Signed-off-by: Paul Kocialkowski > --- > configs/Lamobo_R1_defconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configs/Lamobo_R1_defconfig b/configs/Lamobo_R1_defconfig > index 92e682128c..cf60fdfaf4 100644 > --- a/configs/Lamobo_R1_defconfig > +++ b/configs/Lamobo_R1_defconfig > @@ -2,7 +2,7 @@ CONFIG_ARM=y > CONFIG_ARCH_SUNXI=y > CONFIG_SYS_TEXT_BASE=0x4a00 > CONFIG_MACH_SUN7I=y > -CONFIG_DRAM_CLK=432 > +CONFIG_DRAM_CLK=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
Re: [U-Boot] [RFC PATCH 1/3] sunxi: Extend SPL header versioning
ble.
> /* The header must be a multiple of 32 bytes (for VBAR alignment) */
> };
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 3d364c6db5..a105d0a5ab 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -631,9 +631,9 @@ static void parse_spl_header(const uint32_t spl_addr)
> return; /* signature mismatch, no usable header */
>
> uint8_t spl_header_version = spl->spl_signature[3];
> - if (spl_header_version != SPL_HEADER_VERSION) {
> + if (spl_header_version < SPL_ENV_HEADER_VERSION) {
We have already discussed this particular part of code earlier:
https://lists.denx.de/pipermail/u-boot/2015-September/227999.html
Essentially, unless we have a real use case for mixing the SPL and the
main U-Boot parts built from different U-Boot versions, I don't see any
purpose for doing anything other than just exact version check 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
Re: [U-Boot] [PATCH v3 2/2] sunxi: binman: Add U-Boot binary size check
On Tue, 01 May 2018 18:25:06 +0100
Måns Rullgård wrote:
> Maxime Ripard writes:
>
> > The U-Boot binary may trip over its actual allocated size in the storage.
> > In such a case, the environment will not be readable anymore (because
> > corrupted when the new image was flashed), and any attempt at using saveenv
> > to reconstruct the environment will result in a corrupted U-Boot binary.
> >
> > Reviewed-by: Andre Przywara
> > Signed-off-by: Maxime Ripard
> > ---
> > arch/arm/dts/sunxi-u-boot.dtsi | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi
> > index 5adfd9bca2ec..72e95afd780e 100644
> > --- a/arch/arm/dts/sunxi-u-boot.dtsi
> > +++ b/arch/arm/dts/sunxi-u-boot.dtsi
> > @@ -1,5 +1,14 @@
> > #include
> >
> > +/*
> > + * This is the maximum size the U-Boot binary can be, which is basically
> > + * the start of the environment, minus the start of the U-Boot binary in
> > + * the MMC. This makes the assumption that the MMC is using 512-bytes
> > + * blocks, but devices using something other than that remains to be
> > + * seen.
> > + */
> > +#define UBOOT_MMC_MAX_SIZE (CONFIG_ENV_OFFSET -
> > (CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512))
> > +
> > / {
> > binman {
> > filename = "u-boot-sunxi-with-spl.bin";
> > @@ -8,6 +17,9 @@
> > filename = "spl/sunxi-spl.bin";
> > };
> > u-boot-img {
> > +#ifdef CONFIG_MMC
> > + size = ;
> > +#endif
> > pos = ;
> > };
> > };
> > --
>
> This is broken in (at least) two ways:
>
> 1. It is simply nonsensical if u-boot and env are on different devices
>or not on mmc even if mmc support is enabled.
>
> 2. It causes u-boot-sunxi-with-spl.bin to be padded to the env offset.
>At best, this is useless. If the env doesn't immediately follow
>u-boot, it really breaks things.
>
> Please fix or revert, I don't really care which.
The padding is not useless. It reserves space for 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 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
Re: [U-Boot] [linux-sunxi] Re: [PATCH v2 5/6] sunxi: add code for recalculating the DRAM size in U-Boot
On Tue, 3 Apr 2018 13:43:43 +0100 Andre Przywara wrote: > Hi Icenowy, > > On 03/04/18 12:51, Icenowy Zheng wrote: > > > > > > 于 2018年4月3日 GMT+08:00 下午7:34:55, Maxime Ripard > > 写到: > >> On Tue, Apr 03, 2018 at 11:13:17AM +0100, Andre Przywara wrote: > >>>>>>> For hacking it, see my implementation in v1, which assumes the > >>>>>>> only size supported bigger than 2GiB is 3GiB (which is > >>>>>>> acceptable on sunxi, but might not work on other platforms). > >>>>>>> > >>>>>>> As Andre said, that function has another big problem -- it > >> detects > >>>>>>> memory with writing to it. This is risky. > >>>>>> > >>>>>> How is it risky when it's done by the SPL? > >>>>> > >>>>> Originally that was my confusion as well: It's not the SPL calling > >> that > >>>>> function. The DRAM controller init function in there knows very > >>>>> precisely how much DRAM we have, but we don't communicate this to > >> U-Boot > >>>>> proper. So U-Boot *proper* goes ahead and probes the DRAM. This > >> means it > >>>>> could step into secure memory, for instance. On sunxi64 we have > >> the ATF > >>>>> running between SPL and U-Boot, also all kind of secure payloads > >> could > >>>>> already have been registered. > >>>>> So I wonder if it would be easier to somehow pass on this *one* > >> word of > >>>>> information between SPL and U-Boot proper to avoid calling this > >> function > >>>>> altogether? > >>>> > >>>> That would definitely make sense yes. > >>> > >>> So since the SPL loads the DT anyway (from the FIT image) and puts it > >> at > >>> the end of the U-Boot (proper) binary, wouldn't it be the easiest to > >>> just patch the actual DRAM size in there? > >>> IIRC we don't have any FDT write code in the SPL at the moment, and > >>> pulling it in would probably push it over the edge again, but: > >> > >> That assumes that you are loading a FIT image, which might or might > >> not be the case, and on most arm32 chips, most likely won't. > >> > >> I guess we'd need to find another way (put some information in an > >> SRAM somewhere?) to try to do that for all variants. > > > > Extend the SPL header again? If we found SPL v3+, use > > the DRAM size encoded and bypass ram_get_size, > > otherwise fallback to ram_get_size? > > Yes, that would be a possibility as well. Though I believe at the moment > we don't access the SPL header from U-Boot proper, do we? We do. The boot device and also the boot.scr location (in the case of FEL boot) is read from the SPL header by the main U-Boot part. > Not a real show-stopper, but we probably need to document that the SPL > header would need to stay around. Maybe. > But if we have a fallback anyway ... Which fallback? Do you mean calling things like ram_get_size() from U-Boot? We should never do this because this is very wrong. The D-Cache may be already enabled, causing all kinds of weird effects. Also modifying data in DRAM (even temporarily) while our code is already running from DRAM is dangerous. > > (Although it will lead to some days of mess on sunxi-tools, > > this is a reasonable choice.) > > True, but actually I wonder why we have SPL_MAX_VERSION in there in the > first place. Can't we just postulate that every new SPL version stays > backwards compatible? So if sunxi-tools can deal with v2, a v3 SPL would > still be fine, you would just loose 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 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
Re: [U-Boot] [PATCH 1/1] arm: armv7: enable unaligned access
On Thu, 29 Mar 2018 23:33:50 +0200 Heinrich Schuchardt wrote: > We use the command bootefi to run UEFI executables like GRUB and iPXE. > The UEFI spec requires that unaligned access is enabled if the CPU > supports it. This is true for armv7. > > So we should not set bit 1 of the system control register, the alignment > bit. > > Without this patch iPXE snp.efi cannot be executed on the Allwinner A20. > > Signed-off-by: Heinrich Schuchardt > --- > arch/arm/cpu/armv7/start.S | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S > index 7e2695761e..1771741119 100644 > --- a/arch/arm/cpu/armv7/start.S > +++ b/arch/arm/cpu/armv7/start.S > @@ -150,7 +150,6 @@ ENTRY(cpu_init_cp15) > mrc p15, 0, r0, c1, c0, 0 > bic r0, r0, #0x2000 @ clear bits 13 (--V-) > bic r0, r0, #0x0007 @ clear bits 2:0 (-CAM) > - orr r0, r0, #0x0002 @ set bit 1 (--A-) Align > orr r0, r0, #0x0800 @ set bit 11 (Z---) BTB > #ifdef CONFIG_SYS_ICACHE_OFF > bic r0, r0, #0x1000 @ clear bit 12 (I) I-cache Can you postpone flipping this bit until the very moment when you are about to start your UEFI executable? The main reason against setting this bit for the whole U-Boot globally is that a lot of common code in U-Boot can be 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, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.
, as > x U-Boot users have possibly x different usage scenarios. > Some very actively do work on the U-Boot prompt and rely on a customized > and preserved environment, while others merely rely on some standardized > boot paths, using config_distro_bootcmd.h and PXE, DHCP and/or EFI. > > That being said I have prepared a patch to switch sunxi ARM64 boards > over to ENV_IS_IN_FAT, because I guess we will hit the wall soon there > and have no Thumb2 to get off lightly. Even without Thumb2 we still can reduce footprint by taking advantage of compression for the main U-Boot binary. For this purpose we can use at least LZO because the decompressor code is really small (was it 200-300 bytes?) and still can fit in SPL. A more sophisticated approach can involve attaching the decompressor code to the main U-Boot binary itself. To be honest, I actually expected the size overflow problem to eventually happen for the SPL, resulting in a proposal of a similar radical feature chopping "solution". And when shit actually hits the fan, I will submit an LZO/UCL runtime decompression patch for the SPL, which can save the day :-) I have already mentioned this a few times in the past and it is our strategic reserve. The size overflow for the main U-Boot binary was a bit of surprise to me, but we still have it under control. Also as already discussed in this thread, we can just move the location of the environment to reserve more space for the main U-Boot binary (yes, handling the smooth environment location move during U-Boot upgrade will be a bit tricky, but still doable if anyone is really up to it). > And I believe that the arm64 boards mostly use a standardized way of > booting, also are much less wide spread, so the number of affected > users is probably less there. I don't think that we have any significant number of U-Boot env users 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
Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.
On Thu, Oct 19, 2017 at 11:26 AM, Maxime Ripard wrote: > Hi, > > Most featureful boards, such as the Cubietruck, have been broken since > the release 2017.09. > > This is due to a size increase of the binary that will trip us across > the size we've been using in the u-boot-sunxi-with-spl.bin file. > > We would have two ways to work around it. The first one would be to > just increase the offset of the environment. However, since it would > break all the environments of our users and possibly the custom > partition scheme that they would have created, it doesn't really seem > like a smart move. > > Another one would be to start trimming down a bit our enabled options > in order to reduce the size and to gain some extra space for users > customisations. I've taken care some of the low hanging fruits, and we > should probably take another go at it in the future (and add a size > check in the image build somehow?) > > Maxime > > Maxime Ripard (3): > ARM: sunxi: Disable USB host options by default > ARM: sunxi: Disable FAT write by default > efi_loader: Do not enable it by default for sunxi > > arch/arm/Kconfig | 4 > lib/efi_loader/Kconfig | 2 +- > 2 files changed, 1 insertion(+), 5 deletions(-) We can first enable Thumb2 build by default for 32-bit sunxi boards and this should fix Cubietruck problems. $ cat .config | grep THUMB CONFIG_HAS_THUMB2=y # CONFIG_SYS_THUMB_BUILD is not set CONFIG_SPL_SYS_THUMB_BUILD=y As a test, enabling CONFIG_SYS_THUMB_BUILD=y in Cubietruck_defconfig reduces the size of the resulting U-Boot binary. == Before: == $ arm-linux-gnueabihf-size u-boot text databssdechexfilename 489398 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
Re: [U-Boot] [linux-sunxi] [PATCH v3 1/3] video: sunxi: extract simplefb match code to a new file
; if (offset < 0) {
> eprintf("Cannot setup simplefb: node not found\n");
> return 0; /* Keep older kernels working */
Here is the "git blame" output for this part of code that you are
moving around by your patch:
2dae800f drivers/video/sunxi_display.c (Hans de Goede 2014-12-21
16:28:32 +0100 1380) /* Find a prefilled simpefb node, matching out
pipeline config */
2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13
07:55:07 +0200 1381) offset = fdt_node_offset_by_compatible(blob, -1,
2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13
07:55:07 +0200 1382)
"allwinner,simple-framebuffer");
2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13
07:55:07 +0200 1383) while (offset >= 0) {
b02e4044 drivers/video/sunxi_display.c (Simon Glass 2016-10-02
17:59:28 -0600 1384) ret = fdt_stringlist_search(blob, offset,
"allwinner,pipeline",
6e67f176 drivers/video/sunxi_display.c (Masahiro Yamada 2016-10-17
20:43:01 +0900 1385) pipeline);
2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13
07:55:07 +0200 1386) if (ret == 0)
2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13
07:55:07 +0200 1387) break;
2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13
07:55:07 +0200 1388) offset =
fdt_node_offset_by_compatible(blob, offset,
2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13
07:55:07 +0200 1389)
"allwinner,simple-framebuffer");
2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13
07:55:07 +0200 1390) }
2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13
07:55:07 +0200 1391) if (offset < 0) {
2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13
07:55:07 +0200 1392) eprintf("Cannot setup simplefb: node not
found\n");
2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13
07:55:07 +0200 1393) return 0; /* Keep older kernels working */
2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13
07:55:07 +0200 1394) }
Luc Verhaegen is the real author of the sunxi DE1 simplefb code in
U-Boot. If you 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 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
[U-Boot] [PATCH 2/2] arm: Exercise v7_arch_cp15_set_acr even without errata fixups
By applying this patch, we are ensuring that the code paths
responsible for applying errata workarounds are also exercised
on CPU revisions, which actually don't need these workarounds.
Only CONFIG_ARM_ERRATA_621766, CONFIG_ARM_ERRATA_454179,
CONFIG_ARM_ERRATA_725233 and CONFIG_ARM_ERRATA_430973 are
covered by this patch (Cortex-A8).
This improves code coverage when testing U-Boot builds
on newer hardware. In particular, the problematic commit
00bbe96ebabb ("arm: omap: Unify get_device_type() function")
would break both BeageBoard and BeagleBoard XM rather than
just older BeagleBoard.
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/arch/arm/cpu/armv7/start.S
index f06fd28..1442675 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -232,55 +232,47 @@ skip_errata_801819:
#endif
#ifdef CONFIG_ARM_ERRATA_454179
+ mrc p15, 0, r0, c1, c0, 1 @ Read ACR
+
cmp r2, #0x21 @ Only on < r2p1
- bge skip_errata_454179
+ orrlt r0, r0, #(0x3 << 6) @ Set DBSM(BIT7) and IBE(BIT6) bits
- mrc p15, 0, r0, c1, c0, 1 @ Read ACR
- orr r0, r0, #(0x3 << 6) @ Set DBSM(BIT7) and IBE(BIT6) bits
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_454179:
#endif
#ifdef CONFIG_ARM_ERRATA_430973
+ mrc p15, 0, r0, c1, c0, 1 @ Read ACR
+
cmp r2, #0x21 @ Only on < r2p1
- bge skip_errata_430973
+ orrlt r0, r0, #(0x1 << 6) @ Set IBE bit
- mrc p15, 0, r0, c1, c0, 1 @ Read ACR
- orr r0, r0, #(0x1 << 6) @ 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
#ifdef CONFIG_ARM_ERRATA_621766
+ mrc p15, 0, r0, c1, c0, 1 @ Read ACR
+
cmp r2, #0x21 @ Only on < r2p1
- bge skip_errata_621766
+ orrlt r0, r0, #(0x1 << 5) @ Set L1NEON bit
- mrc p15, 0, r0, c1, c0, 1 @ Read ACR
- orr r0, r0, #(0x1 << 5) @ Set L1NEON 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_621766:
#endif
#ifdef CONFIG_ARM_ERRATA_725233
+ mrc p15, 1, r0, c9, c0, 2 @ Read L2ACR
+
cmp r2, #0x21 @ Only on < r2p1 (Cortex A8)
- bge skip_errata_725233
+ orrlt r0, r0, #(0x1 << 27)@ L2 PLD data forwarding disable
- mrc p15, 1, r0, c9, c0, 2 @ Read L2ACR
- orr r0, r0, #(0x1 << 27)@ L2 PLD data forwarding disable
push{r1-r5} @ Save the cpu info registers
bl v7_arch_cp15_set_l2aux_ctrl
pop {r1-r5} @ Restore the cpu info - fall through
-
-skip_errata_725233:
#endif
#ifdef CONFIG_ARM_ERRATA_852421
--
2.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] Fix get_device_type() problems
The comit 00bbe96ebabb ("arm: omap: Unify get_device_type()
function") does not play nice with early errata workarounds
and needs some fixes. And because it does not bring any
practical improvements anyway (other than increasing the SPL
size and introducing more lines of code), it's 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
arch/arm/cpu/armv7/start.S | 32
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 +
arch/arm/include/asm/arch-omap5/omap.h | 1 +
arch/arm/include/asm/omap_common.h | 11 +--
arch/arm/mach-omap2/Makefile| 1 -
arch/arm/mach-omap2/am33xx/Makefile | 2 --
arch/arm/mach-omap2/am33xx/board.c | 3 ---
arch/arm/mach-omap2/am33xx/hw_data.c| 19 ---
arch/arm/mach-omap2/am33xx/prcm-regs.c | 15 ---
arch/arm/mach-omap2/am33xx/sys_info.c | 10 ++
arch/arm/mach-omap2/hwinit-common.c | 9 +
arch/arm/mach-omap2/omap3/Makefile | 2 --
arch/arm/mach-omap2/omap3/board.c | 7 ---
arch/arm/mach-omap2/omap3/hw_data.c | 19 ---
arch/arm/mach-omap2/omap3/prcm-regs.c | 15 ---
arch/arm/mach-omap2/omap3/sys_info.c| 9 -
arch/arm/mach-omap2/sysinfo-common.c| 21 -
board/ti/am335x/board.c | 1 -
board/ti/am43xx/board.c | 1 -
22 files changed, 48 insertions(+), 143 deletions(-)
delete mode 100644 arch/arm/mach-omap2/am33xx/hw_data.c
delete mode 100644 arch/arm/mach-omap2/am33xx/prcm-regs.c
delete mode 100644 arch/arm/mach-omap2/omap3/hw_data.c
delete mode 100644 arch/arm/mach-omap2/omap3/prcm-regs.c
delete mode 100644 arch/arm/mach-omap2/sysinfo-common.c
--
2.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] Revert "arm: omap: Unify get_device_type() function"
This reverts commit 00bbe96ebabbc83777cd8d6c6fd2791c5c8cf619.
There were two major problems with this patch:
1. It made OMAP3530 devices non-bootable, as reported
and investigated by Derald D. Woods in
https://lists.denx.de/pipermail/u-boot/2017-August/302192.html
2. The SPL code size increased really a lot.
SPL size for omap3_beagle_defconfig build with GCC 6:
== before reverting ==
textdata bss dec hex filename
497211505 203200 254426 3e1da spl/u-boot-spl
== after reverting ==
textdata bss dec hex filename
492331501 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 +
arch/arm/include/asm/arch-omap5/omap.h | 1 +
arch/arm/include/asm/omap_common.h | 11 +--
arch/arm/mach-omap2/Makefile| 1 -
arch/arm/mach-omap2/am33xx/Makefile | 2 --
arch/arm/mach-omap2/am33xx/board.c | 3 ---
arch/arm/mach-omap2/am33xx/hw_data.c| 19 ---
arch/arm/mach-omap2/am33xx/prcm-regs.c | 15 ---
arch/arm/mach-omap2/am33xx/sys_info.c | 10 ++
arch/arm/mach-omap2/hwinit-common.c | 9 +
arch/arm/mach-omap2/omap3/Makefile | 2 --
arch/arm/mach-omap2/omap3/board.c | 7 ---
arch/arm/mach-omap2/omap3/hw_data.c | 19 ---
arch/arm/mach-omap2/omap3/prcm-regs.c | 15 ---
arch/arm/mach-omap2/omap3/sys_info.c| 9 -
arch/arm/mach-omap2/sysinfo-common.c| 21 -
board/ti/am335x/board.c | 1 -
board/ti/am43xx/board.c | 1 -
21 files changed, 36 insertions(+), 123 deletions(-)
delete mode 100644 arch/arm/mach-omap2/am33xx/hw_data.c
delete mode 100644 arch/arm/mach-omap2/am33xx/prcm-regs.c
delete mode 100644 arch/arm/mach-omap2/omap3/hw_data.c
delete mode 100644 arch/arm/mach-omap2/omap3/prcm-regs.c
delete mode 100644 arch/arm/mach-omap2/sysinfo-common.c
diff --git a/arch/arm/include/asm/arch-am33xx/cpu.h
b/arch/arm/include/asm/arch-am33xx/cpu.h
index e8d7d54..8cae291 100644
--- a/arch/arm/include/asm/arch-am33xx/cpu.h
+++ b/arch/arm/include/asm/arch-am33xx/cpu.h
@@ -36,6 +36,12 @@
#define TCFG_RESET BIT(0) /* software reset */
#define TCFG_EMUFREE BIT(1) /* behaviour of tmr on debug */
#define TCFG_IDLEMOD_SHIFT (2) /* power management */
+/* device type */
+#define DEVICE_MASK(BIT(8) | BIT(9) | BIT(10))
+#define TST_DEVICE 0x0
+#define EMU_DEVICE 0x1
+#define HS_DEVICE 0x2
+#define GP_DEVICE 0x3
/* cpu-id for AM43XX AM33XX and TI81XX family */
#define AM437X 0xB98C
diff --git a/arch/arm/include/asm/arch-am33xx/omap.h
b/arch/arm/include/asm/arch-am33xx/omap.h
index d2c5df8..0dafb9e 100644
--- a/arch/arm/include/asm/arch-am33xx/omap.h
+++ b/arch/arm/include/asm/arch-am33xx/omap.h
@@ -41,9 +41,6 @@ struct omap_boot_parameters {
unsigned char boot_device;
unsigned char reset_reason;
};
-
-#define DEVICE_TYPE_SHIFT 0x8
-#define DEVICE_TYPE_MASK (0x7 << DEVICE_TYPE_SHIFT)
#endif
#endif
diff --git a/arch/arm/include/asm/arch-omap3/omap.h
b/arch/arm/include/asm/arch-omap3/omap.h
index 8933f54..db763e4 100644
--- a/arch/arm/include/asm/arch-omap3/omap.h
+++ b/arch/arm/include/asm/arch-omap3/omap.h
@@ -91,9 +91,6 @@ struct s32ktimer {
unsigned int s32k_cr; /* 0x10 */
};
-#define DEVICE_TYPE_SHIFT 0x8
-#define DEVICE_TYPE_MASK (0x7 << DEVICE_TYPE_SHIFT)
-
#endif /* __ASSEMBLY__ */
#ifndef __ASSEMBLY__
diff --git a/arch/arm/include/asm/arch-omap4/omap.h
b/arch/arm/include/asm/arch-omap4/omap.h
index 1a3ff7d..b86a776 100644
--- a/arch/arm/include/asm/arch-omap4/omap.h
+++ b/arch/arm/include/asm/arch-omap4/omap.h
@@ -100,6 +100,7 @@ struct s32ktimer {
#define DEVICE_TYPE_SHIFT (0x8)
#define DEVICE_TYPE_MASK (0x7 << DEVICE_TYPE_SHIFT)
+#define DEVICE_GP 0x3
#endif /* __ASSEMBLY__ */
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm/include/asm/arch-omap5/omap.h
index 2f005dd..8f31da1 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -127,6 +127,7 @@ struct s32ktimer {
#define DEVICE_TYPE_SHIFT 0x6
#define DEVICE_TYPE_MASK (0x7 << DEVICE_TYPE_SHIFT)
+#define DEVICE_GP 0x3
/* Output impedance control */
#define ds_120_ohm 0x0
diff --git a/arch/arm/include/asm/omap_common.h
b/arch/arm/include/asm/omap_common.h
index ef5c481..6aaa1ba 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@
Re: [U-Boot] [PATCH 10/14] dm: mmc: sunxi: Add support for driver model
On Fri, 28 Jul 2017 18:08:31 +0200 Maxime Ripard wrote: > On Thu, Jul 27, 2017 at 10:19:44PM -0600, Simon Glass wrote: > > Hi Maxime, > > > > On 17 July 2017 at 03:26, Maxime Ripard > > wrote: > > > Hi Simon, > > > > > > On Fri, Jul 14, 2017 at 07:47:45AM -0600, Simon Glass wrote: > > >> On 5 July 2017 at 14:14, Maxime Ripard > > >> wrote: > > >> > On Wed, Jul 05, 2017 at 04:57:40PM +0200, Maxime Ripard wrote: > > >> >> On Tue, Jul 04, 2017 at 01:33:25PM -0600, Simon Glass wrote: > > >> >> > Hi Maxime, > > >> >> > > > >> >> > On 21 June 2017 at 01:31, Maxime Ripard > > >> >> > wrote: > > >> >> > > Hi Simon, > > >> >> > > > > >> >> > > On Mon, Jun 19, 2017 at 11:11:27AM -0600, Simon Glass wrote: > > >> >> > >> Add a driver-model version of this driver which mostly uses the > > >> >> > >> existing > > >> >> > >> code. The old code can be removed once all boards are switched > > >> >> > >> over. > > >> >> > >> > > >> >> > >> Signed-off-by: Simon Glass > > >> >> > > > > >> >> > > I'm not sure if you tested that, but we have some code that > > >> >> > > switches > > >> >> > > the MMC indices when using both an eMMC and an external MMC. > > >> >> > > > > >> >> > > http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/board.c#l494 > > >> >> > > > > >> >> > > This predates my time, but it seems that it was done to have a > > >> >> > > consistent boot MMC device ID. > > >> >> > > > > >> >> > > I'm not really sure we can get rid of it (even if it creates some > > >> >> > > issues of it's own), but what would be the impact of a switch to > > >> >> > > the > > >> >> > > device model on that logic? > > >> >> > > > >> >> > That is a pretty terrible hack. > > >> >> > > >> >> Yes, I know. This is especially bad when used together with other > > >> >> tools that rely on one MMC index for example (such as fastboot). > > >> >> > > >> >> I wanted to kill it for quite some time, but I'm a bit reluctant due > > >> >> to the possible side effects. > > >> >> > > >> >> > I'm not sure whether it will continue to work with DM. It does still > > >> >> > use the device number in the block device, so maybe... Do you have > > >> >> > a board would use this? > > >> >> > > >> >> I guess I do. I'll give it a try or tonight and let you know. > > >> > > > >> > I just tested. Even with an eMMC (which was the first use case for > > >> > that hack), it works, even things that are not mainline yet (fastboot, > > >> > etc). > > >> > > > >> > It obviously break the old scripts relying on the mmc index, but I > > >> > guess that's ok. > > >> > > > >> > There's one regression though. Our eMMC will always be the second one, > > >> > which means that the distro bootargs will always boot on the external > > >> > SD first (which is always going to be mmc0). > > >> > > > >> > 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 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
Re: [U-Boot] [PATCH v3 60/66] spl: moveconfig: migrate CONFIG_SPL_LDSCRIPT
On Fri, 28 Jul 2017 21:22:32 +0200 Philipp Tomsich wrote: > With SPL_LDSCRIPT defined via Kconfig, we can run moveconfig... this > will touch every configuration that uses SPL, even if there was an > implicit resolution of the SPL_LDSCRIPT: now everything is explicit. > > Signed-off-by: Philipp Tomsich > > --- > > Changes in v3: > - moveconfig.py CONFIG_SPL_LDSCRIPT > (Note: I really don't know whether this is what we want, as it's > making the SPL_LDSCRIPT resolution explicit for every board... > then again, I understood Tom's comment that moving things into > Kconfig should be the priority...) > > Changes in v2: None > > configs/A10-OLinuXino-Lime_defconfig| 1 + [...] > include/configs/zynq-common.h | 2 -- > 369 files changed, 313 insertions(+), 106 deletions(-) > > diff --git a/configs/A10-OLinuXino-Lime_defconfig > b/configs/A10-OLinuXino-Lime_defconfig > index 9143022..7d45c1d 100644 > --- a/configs/A10-OLinuXino-Lime_defconfig > +++ b/configs/A10-OLinuXino-Lime_defconfig > @@ -11,6 +11,7 @@ CONFIG_DEFAULT_DEVICE_TREE="sun4i-a10-olinuxino-lime" > CONFIG_AHCI=y > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > CONFIG_SPL=y > +CONFIG_SPL_LDSCRIPT="arch/arm/cpu/armv7/sunxi/u-boot-spl.lds" Why do we want 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 set -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: omap3: Detect boot mode very early
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
> >> the intent was to store the boot params information in a known
> >> location and pass it to SPL very early. Unfortunately it didn't
> >> account for OMAP3 boards.
> >>
> >> This patch adds adds this functionality back into OMAP3 boards.
> >>
> >> Reviewed-by: Lokesh Vutla
> >> Signed-off-by: Adam Ford
> >>
> >> diff --git a/arch/arm/mach-omap2/omap3/board.c
> >> b/arch/arm/mach-omap2/omap3/board.c
> >> index cd8e302..a61b933 100644
> >> --- a/arch/arm/mach-omap2/omap3/board.c
> >> +++ b/arch/arm/mach-omap2/omap3/board.c
> >> @@ -212,6 +212,12 @@ void board_init_f(ulong dummy)
> >> {
> >>early_system_init();
> >>mem_init();
> >> + /*
> >> + * Save the boot parameters passed from romcode.
> >> + * We cannot delay the saving further than this,
> >> + * to prevent overwrites.
> >> + */
> >> + save_omap_boot_params();
> >> }
> >> #endif
> >>
> >
> > Hello,
> >
> > Something seems to be fishy here.
> >
> > The 4bd754d8abef patch from Lokesh Vutla basically replicated the same
> > chunk of code for every OMAP variant rather than keeping it in one
> > common location. The justification for this code duplication is that
> > the boot parameters may be overwritten. Can we have a bit more details
> > about how and when this overwrite actually happens in practice?
>
> ROM stores the boot_params info in SRAM and passed this address to SPL.
> For SPL, all the dtb, malloc, stack, and scratch area are in SRAM. There
> is high probability that it might override the boot params info.
This is a somewhat vague description. We are supposed to know where
all this stuff is located and have a reasonably good control over it.
OMAP_SRAM_SCRATCH_BOOT_PARAMS appears to be a part of the 1K
scratch area in the SRAM, which is located right above the
loaded SPL image. So if something is able to unexpectedly
overwrite OMAP_SRAM_SCRATCH_BOOT_PARAMS, then there might be
a risk that some other important code or data near the end
of the SPL image may be overwritten too.
> So, we need to parse this info asap. I did see this is being overwritten on
> dra7 evm
Thanks for providing this information. You did not mention it in your
commit message before. This dra7 evm is an OMAP5 board, right? And in
'arch/arm/include/asm/arch-omap5/omap.h' I can see the following
defines:
/*
* In all cases, the TRM defines the RAM Memory Map for the processor
* and indicates the area for the downloaded image. We use all of that
* space for download and once up and running may use other parts of the
* map for our needs. We set a scratch space that is at the end of the
* OMAP5 download area, but within the DRA7xx download area (as it is
* much larger) and do not, at this time, make use of the additional
* space.
*/
#if defined(CONFIG_DRA7XX)
#define NON_SECURE_SRAM_START 0x4030
#define NON_SECURE_SRAM_END 0x4038 /* Not inclusive */
#define NON_SECURE_SRAM_IMG_END 0x4037C000
#else
#define NON_SECURE_SRAM_START 0x4030
#define NON_SECURE_SRAM_END 0x4032 /* Not inclusive */
#define NON_SECURE_SRAM_IMG_END 0x4031E000
#endif
#define SRAM_SCRATCH_SPACE_ADDR (NON_SECURE_SRAM_IMG_END - SZ_1K)
Unlike what we have in a similar header for OMAP3, LOW_LEVEL_SRAM_STACK
is not defined anywhere. Instead of it, we end up having:
#define CONFIG_SYS_INIT_SP_ADDR (NON_SECURE_SRAM_END - GENERATED_GBL_DATA_SIZE)
And it appears to be set to 0x4037FF20 in the SPL binary (at least in
my dra7xx_evm_defconfig build). So the initial stack is above the
scratch area and has size 0x3F20. The SPL code explicitly initializes
the SP register in the very beginning. Except for one glitch, which I
have reported in a separate e-mail:
https://lists.denx.de/pipermail/u-boot/2017-July/299446.html
> so I had to introduce this patch.
Still I would like to know what exactly is overwriting the boot
parameters on your dra7 evm board and why this did not happen on
other boards.
> You can always dump R0 at the beiginning of SPL and compare it
> with objdump of spl.
>
> >
> > I don't quite like the fact that we still have the code, which relies
> > on OMAP_SRAM_SCRATCH_BOOT_PARAMS in the "jump_to_image_no_args"
> > function very late in the SPL:
>
> I don't think U-Boot uses this information at all, so till now there is
> no effect. You can as well not pass anything.
If it is not used, then maybe we should remove this code?
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] CPU errata workarounds are using the SPL stack before it is initialized
Hello,
Currently the code in 'arch/arm/cpu/armv7/start.S' calls
the 'cpu_init_cp15' function before 'cpu_init_crit'. The initial
SPL stack is initialized in 'lowlevel_init', which is called
from 'cpu_init_crit'. But 'cpu_init_cp15' is already using stack
when applying errata workarounds. Here is one example:
#ifdef CONFIG_ARM_ERRATA_430973
cmp r2, #0x21 @ Only on < r2p1
bge skip_errata_430973
mrc p15, 0, r0, c1, c0, 1 @ Read ACR
orr r0, r0, #(0x1 << 6) @ 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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] 2017.05-RC3 hanging on DM3730
On Thu, 4 May 2017 18:38:39 -0500
Adam Ford wrote:
> On Thu, May 4, 2017 at 6:08 PM, Tom Rini wrote:
> > On Thu, May 04, 2017 at 05:58:47PM -0500, Adam Ford wrote:
> >> On Thu, May 4, 2017 at 4:27 PM, Tom Rini wrote:
> >> > On Thu, May 04, 2017 at 04:06:33PM -0500, Adam Ford wrote:
> >> >
> >> >> Tom,
> >> >>
> >> >> I re-synced my U-boot trunk today and did a clean build and found that
> >> >> SPL isn't able to load U-Boot.
> >> >>
> >> >> U-Boot SPL 2017.05-rc3 (May 04 2017 - 15:48:21)
> >> >>
> >> >>
> >> >> I haven't had a chance yet to bisect the issue. Do you know when you
> >> >> plan to do the 2017.05 release? I'd like to try and locate the issue
> >> >> before the final release.
> >> >
> >> > I'd like to do the release on Monday. Can you please start bisecting?
> >>
> >> I bisected it since I won't have time tomorrow or this weekend.
> >>
> >> Commit 7584f2e0fb0f ("arm: omap3: Compile clock.c with -marm option to
> >> unbreak OMAP3530") seems to break the OMAP3630 (DM3730) in that
> >> nothing boots at all:
> >>
> >>(dead)
> >>
> >>
> >> Commit 19a75b8cf8d1("arm: omap3: Bring back ARM errata workaround
> >> 725233") at least shows some activity, but not enough to do anything:
> >>
> >>U-Boot SPL 2017.03-7-g19a75b8 (May 04 2017 - 17:53:10)
> >>
> >>(dead)
> >>
> >> I am wondering if other OMAP36/37 devices have had any issues?
> >
> > My bbXM is working. Can you try and see which of the errata is breaking
> > your particular setup? Thanks!
>
> It appears to be a toolchain issue. I use Buildroot which builds
> everything from scratch. I specify some items like glibc, gcc version,
> binutils, etc.
>
> I am not sure why the removal of "CFLAGS_clock.o += -marm" causes an issue.
>
> When I built it with Linaro 2016.11 it worked, but that version is
> tuned for a corex-A9, but it proves the code is ok. Sorry for the
> noise.
Hello,
It is actually unlikely to be a toolchain issue, but more like
some racy code in U-boot, which happens to be timing sensitive. As
the commit message [1] says, it was not a proper fix but a quick and
dirty workaround. More information is 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 it).
Right now the OMAP3 clock code has some sort of a timing sensitive
latent bug and it may potentially blow up on any future toolchain
update (regardless of the use of the ARM or Thumb2 mode). So it's
best if somebody finds the root cause and fixes it. But I guess,
OMAP3 is very old and does not get much love nowadays.
1. http://git.denx.de/?p=u-boot.git;a=commit;h=7584f2e0fb0f
2. https://lists.denx.de/pipermail/u-boot/2017-March/283078.html
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: omap3: Detect boot mode very early
On Fri, 14 Jul 2017 08:53:20 -0500
Adam Ford wrote:
> Fixes 4bd754d8abef ("arm: omap: Detect boot mode very early") where
> the intent was to store the boot params information in a known
> location and pass it to SPL very early. Unfortunately it didn't
> account for OMAP3 boards.
>
> This patch adds adds this functionality back into OMAP3 boards.
>
> Reviewed-by: Lokesh Vutla
> Signed-off-by: Adam Ford
>
> diff --git a/arch/arm/mach-omap2/omap3/board.c
> b/arch/arm/mach-omap2/omap3/board.c
> index cd8e302..a61b933 100644
> --- a/arch/arm/mach-omap2/omap3/board.c
> +++ b/arch/arm/mach-omap2/omap3/board.c
> @@ -212,6 +212,12 @@ void board_init_f(ulong dummy)
> {
> early_system_init();
> mem_init();
> + /*
> + * Save the boot parameters passed from romcode.
> + * We cannot delay the saving further than this,
> + * to prevent overwrites.
> + */
> + save_omap_boot_params();
> }
> #endif
>
Hello,
Something seems to be fishy here.
The 4bd754d8abef patch from Lokesh Vutla basically replicated the same
chunk of code for every OMAP variant rather than keeping it in one
common location. The justification for this code duplication is that
the boot parameters may be overwritten. Can we have a bit more details
about how and when this overwrite actually happens in practice?
I don't quite like the fact that we still have the code, which relies
on OMAP_SRAM_SCRATCH_BOOT_PARAMS in the "jump_to_image_no_args"
function very late in the SPL:
void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
{
typedef void __noreturn (*image_entry_noargs_t)(u32 *);
image_entry_noargs_t image_entry =
(image_entry_noargs_t) spl_image->entry_point;
u32 boot_params = *((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS);
debug("image entry point: 0x%lX\n", spl_image->entry_point);
/* Pass the saved boot_params from rom code */
image_entry((u32 *)boot_params);
}
This code had been introduced by Paul Kocialkowski in the old
patch 60c7c30aa084588ef9746 ("omap-common: Common boot code
OMAP3 support and cleanup") and still exists in U-Boot. And
the commit message 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
Re: [U-Boot] [PATCH] net: Mark the ip_udp_hdr struct as packed
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.
>
> This statement seems to be poorly worded.
>
> > It seems like gcc 7.1 is a bit stricter than previous gcc versions on this,
> > and using it lead to data abort for unaligned accesses when generating
> > network traffic.
>
> Why don't we just clearly say that this patch fixes undefined behaviour
> in a buggy C code, caused by U-Boot failing to meet the 32-bit alignment
> expectations of GCC for this particular structure?
>
> > Fix this by adding the packed attribute to the ip_udp_hdr structure in
> > order to let GCC do its job.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > include/net.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/net.h b/include/net.h
> > index 997db9210a8f..7b815afffafa 100644
> > --- a/include/net.h
> > +++ b/include/net.h
> > @@ -390,7 +390,7 @@ struct ip_udp_hdr {
> > u16 udp_dst;/* UDP destination port */
> > u16 udp_len;/* Length of UDP packet */
> > u16 udp_xsum; /* Checksum */
> > -};
> > +} __attribute__ ((packed));
>
>
> Alternatively we could try to only mark the 32-bit structure fields as
> "packed" rather than marking the whole structure. Here is a test code:
>
> /***/
> #include
> #include
>
> struct a
> {
> uint32_t x;
> uint16_t y;
> } a;
>
> struct b
> {
> uint32_t x __attribute((packed));
> uint16_t y;
> };
>
> int main(void)
> {
> printf("sizeof(struct a) = %d\n", (int)sizeof(struct a));
> printf("sizeof(struct b) = %d\n", (int)sizeof(struct b));
>
> return 0;
> }
> /***/
>
> Running it produces the following output:
>
> sizeof(struct a) = 8
> sizeof(struct b) = 6
> __alignof__(struct a) = 4
> __alignof__(struct b) = 2
>
>
>
> Also as an additional safety measure, we can add something like this
> to U-Boot:
>
> assert(__alignof__(struct ip_udp_hdr) == 2);
>
>
> Maybe it can be also done as a compile-time test rather than a
> runtime test. In the example above, I can add the following code:
>
> int dummy_b[3 - __alignof__(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)];
> ^
And if we do it this way, then the compile-time test can look a bit
cleaner:
test.c:17:5: error: size of array ‘compile_test_for_struct_a_alignment’ is
negative
int compile_test_for_struct_a_alignment[(__alignof__(struct a) == 2) ? 1 : -1];
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: Mark the ip_udp_hdr struct as packed
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.
This statement seems to be poorly worded.
> It seems like gcc 7.1 is a bit stricter than previous gcc versions on this,
> and using it lead to data abort for unaligned accesses when generating
> network traffic.
Why don't we just clearly say that this patch fixes undefined behaviour
in a buggy C code, caused by U-Boot failing to meet the 32-bit alignment
expectations of GCC for this particular structure?
> Fix this by adding the packed attribute to the ip_udp_hdr structure in
> order to let GCC do its job.
>
> Signed-off-by: Maxime Ripard
> ---
> include/net.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/net.h b/include/net.h
> index 997db9210a8f..7b815afffafa 100644
> --- a/include/net.h
> +++ b/include/net.h
> @@ -390,7 +390,7 @@ struct ip_udp_hdr {
> u16 udp_dst;/* UDP destination port */
> u16 udp_len;/* Length of UDP packet */
> u16 udp_xsum; /* Checksum */
> -};
> +} __attribute__ ((packed));
Alternatively we could try to only mark the 32-bit structure fields as
"packed" rather than marking the whole structure. Here is a test code:
/***/
#include
#include
struct a
{
uint32_t x;
uint16_t y;
} a;
struct b
{
uint32_t x __attribute((packed));
uint16_t y;
};
int main(void)
{
printf("sizeof(struct a) = %d\n", (int)sizeof(struct a));
printf("sizeof(struct b) = %d\n", (int)sizeof(struct b));
return 0;
}
/***/
Running it produces the following output:
sizeof(struct a) = 8
sizeof(struct b) = 6
__alignof__(struct a) = 4
__alignof__(struct b) = 2
Also as an additional safety measure, we can add something like this
to U-Boot:
assert(__alignof__(struct ip_udp_hdr) == 2);
Maybe it can be also done as a compile-time test rather than a
runtime test. In the example above, I can add the following code:
int dummy_b[3 - __alignof__(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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: Mark the ip_udp_hdr struct as packed
On Wed, 19 Jul 2017 20:26:54 +0200
Jeroen Hofstee wrote:
> Hi,
>
>
> On 07/18/2017 08:10 PM, Joe Hershberger wrote:
> > Hi Maxime,
> >
> > On Wed, Jul 12, 2017 at 9:34 AM, 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.
> >>
> >> It seems like gcc 7.1 is a bit stricter than previous gcc versions on this,
> >> and using it lead to data abort for unaligned accesses when generating
> >> network traffic.
> >>
> >> Fix this by adding the packed attribute to the ip_udp_hdr structure in
> >> order to let GCC do its job.
> >>
> >> Signed-off-by: Maxime Ripard
> >> ---
> >> include/net.h | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/include/net.h b/include/net.h
> >> index 997db9210a8f..7b815afffafa 100644
> >> --- a/include/net.h
> >> +++ b/include/net.h
> >> @@ -390,7 +390,7 @@ struct ip_udp_hdr {
> >> u16 udp_dst;/* UDP destination port */
> >> u16 udp_len;/* Length of UDP packet */
> >> u16 udp_xsum; /* Checksum */
> >> -};
> >> +} __attribute__ ((packed));
> > Do you have an example of why this is unaligned? It seems that the
> > structure itself is naturally packed (each element is aligned to its
> > 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 __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
Re: [U-Boot] Data Abort with gcc 7.1
ct in_addr dest, struct in_addr source)
> {
> struct ip_udp_hdr *ip = (struct ip_udp_hdr *)pkt;
>
> /*
>* Construct an IP header.
>*/
> /* IP_HDR_SIZE / 4 (not including UDP) */
> ip->ip_hl_v = 0x45;
> ip->ip_tos = 0;
> ip->ip_len = htons(IP_HDR_SIZE);
> ip->ip_id= htons(net_ip_id++);
> ip->ip_off = htons(IP_FLAGS_DFRAG); /* Don't fragment */
> ip->ip_ttl = 255;
> ip->ip_sum = 0;
> /* already in network byte order */
> net_copy_ip((void *)&ip->ip_src, &source);
> /* already in network byte order */
> net_copy_ip((void *)&ip->ip_dst, &dest);
> }
>
> What's changed with gcc7 is that it now merges the writes to the first
> three fields (occupying 4 bytes) into a single 32-bit store. There is
> nothing wrong with this.
>
> Now struct ip_udp_hdr includes 32-bit fields, so it's natural alignment
> is 4 bytes. If the 'pkt' argument is not adequately aligned, the cast
> in the first line of the function becomes invalid. Judging by the
> register dump and disassembly, the pointer is indeed not thusly
> aligned, and this is an error.
Yes, your analysis appears to be the exact copy of mine up to this
point: https://lists.denx.de/pipermail/u-boot/2017-July/298016.html
> The misaligned pointer should still not cause a hardware abort, however,
> on ARMv6 or later which permits unaligned addresses with the STR
> instruction. That is unless some idiot has gone and enabled strict
> alignment checking again despite this being against all common sense.
> There was a lengthy argument about this a few years ago, ultimately
> resulting in the proper settings being put in place.
The trick is that unaligned memory accesses still need some special
setup even on ARMv6 or later hardware. And we can't always count on
having it working when running early bootloader code.
You can check sections "A3.2.2 Cases where unaligned accesses are
UNPREDICTABLE" and "B3.12.4 Alignment faults" in the ARM Architecture
Reference Manual.
Basically, the MMU has to be enabled. Also unaligned memory accesses
can't be done for the memory pages with device or strongly-ordered
attribute.
Moreover, not every ARM 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
Re: [U-Boot] Data Abort with gcc 7.1
ip->ip_len = htons(IP_HDR_SIZE); > >>>>> 4a043edc: e1c430b2strhr3, [r4, #2] > >>>>> ip->ip_id= htons(net_ip_id++); > >>>>> 4a043ee0: e59f3064ldr r3, [pc, #100] ; 4a043f4c > >>>>> > >>>>> > >>>>> And it seems like it's using an strb instruction to avoid the > >>>>> unaligned access. > >>>>> > >>>>> As far as I know, we are 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. > >>>> > >>>> Can you reduce the code into a testcase? I think the first step is > >>>> filing a bug with gcc and seeing where it goes from there as yes, we > >>>> should be passing -mno-unaligned-access. > >>> > >>> I don’t think that this is a GCC bug, as “-mno-unaligned-access” > >>> will change the behaviour for packed data-structures only. Here’s > >>> from the GCC docs: > >>> > >>>> -munaligned-access > >>>> -mno-unaligned-access > >>>> > >>>> Enables (or disables) reading and writing of 16- and 32- bit > >>>> values from addresses that are not 16- or 32- bit aligned. By > >>>> default unaligned access is disabled for all pre-ARMv6, all > >>>> ARMv6-M and for ARMv8-M Baseline architectures, and enabled for > >>>> all other architectures. If unaligned access is not enabled then > >>>> words in packed data structures are accessed a byte at a time. > >>> > >>> The key word seems to be “in packed data structures”. > >>> However, I don’t see an attribute “packed” for the 'struct ip_udp_hdr’ > >>> (in include/net.h). > >>> > >>> Could you try to verify that the error reproduces with a packed variant > >>> of the ‘struct ip_udp_hdr’? > >> > >> It indeed fixed the issue. There might just have been a subtle change > >> of behaviour in GCC, and this is probably going to bite us in other > >> areas. > >> > >> I'll send a patch to add the packed attribute. > > > > Please bear in mind that packed should be used carefully. We've had > > some discussions about this before and have > > doc/README.unaligned-memory-access.txt which may need a little more > > updating now as well, depending on what the final resolution here is as > > I seem to recall some other problem reports with gcc-7.x, but I've not > > personally been able to hit these just yet. But I need to get on that > > soon. http://toolchains.free-electrons.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
Re: [U-Boot] Data Abort with gcc 7.1
trbr3, [r0] > ip->ip_tos = 0; > ip->ip_len = htons(IP_HDR_SIZE); > 4a043ed4: e3a03b05mov r3, #5120 ; 0x1400 > ip->ip_tos = 0; > 4a043ed8: e3a0mov r0, #0 > ip->ip_len = htons(IP_HDR_SIZE); > 4a043edc: e1c430b2strhr3, [r4, #2] > ip->ip_id= htons(net_ip_id++); > 4a043ee0: e59f3064ldr r3, [pc, #100] ; 4a043f4c > > > And it seems like it's using an strb instruction to avoid the > unaligned access. > > As far as I know, we are 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 bug can be fixed by either: 1) Always ensure proper alignment of the udp packet header pointers, which are passed to the net_set_ip_header() function and similar functions. Some further investigation is necessary. or 2) Just add a "packed" attribute to the ip_udp_hdr struct. In this case the compiler will always assume the smallest 1 byte alignment. It may have some performance implications though. -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mmc: sunxi: Support the new mode
On Wed, 12 Jul 2017 16:48:37 +0200
Maxime Ripard wrote:
> Almost all of the newer Allwinner SoCs have a new operating mode for the
> eMMC clocks that needs to be enabled in both the clock and the MMC
> controller.
Can we have a bit better description in the commit message about what
is new about this mode? Does it bring us some visible improvements
for the end users? Why do we need to enable it?
>
> Add support for it through a Kconfig option
>
> Signed-off-by: Maxime Ripard
> ---
> arch/arm/include/asm/arch-sunxi/mmc.h | 9 ++---
> drivers/mmc/Kconfig | 3 +++
> drivers/mmc/sunxi_mmc.c | 26 +++---
> 3 files changed, 32 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h
> b/arch/arm/include/asm/arch-sunxi/mmc.h
> index cb52e648731c..0c2d496295ff 100644
> --- a/arch/arm/include/asm/arch-sunxi/mmc.h
> +++ b/arch/arm/include/asm/arch-sunxi/mmc.h
> @@ -35,16 +35,19 @@ struct sunxi_mmc {
> u32 cbcr; /* 0x48 CIU byte count */
> u32 bbcr; /* 0x4c BIU byte count */
> u32 dbgc; /* 0x50 debug enable */
> - u32 res0[11];
> + u32 res0; /* 0x54 reserved */
> + u32 a12a; /* 0x58 Auto command 12 argument */
> + u32 ntsr; /* 0x5c New timing set register */
> + u32 res1[8];
> u32 dmac; /* 0x80 internal DMA control */
> u32 dlba; /* 0x84 internal DMA descr list base address */
> u32 idst; /* 0x88 internal DMA status */
> u32 idie; /* 0x8c internal DMA interrupt enable */
> u32 chda; /* 0x90 */
> u32 cbda; /* 0x94 */
> - u32 res1[26];
> + u32 res2[26];
> #ifdef CONFIG_SUNXI_GEN_SUN6I
> - u32 res2[64];
> + u32 res3[64];
> #endif
> u32 fifo; /* 0x100 / 0x200 FIFO access address */
> };
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 82b8d756867c..203f59547100 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -368,6 +368,9 @@ config MMC_SUNXI
> This selects support for the SD/MMC Host Controller on
> Allwinner sunxi SoCs.
>
> +config MMC_SUNXI_HAS_NEW_MODE
> + bool
> +
> config GENERIC_ATMEL_MCI
> bool "Atmel Multimedia Card Interface support"
> depends on DM_MMC && BLK && DM_MMC_OPS && ARCH_AT91
> diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> index fd3fc2af40a0..68750f3832b6 100644
> --- a/drivers/mmc/sunxi_mmc.c
> +++ b/drivers/mmc/sunxi_mmc.c
> @@ -87,6 +87,20 @@ static int mmc_resource_init(int sdc_no)
> static int mmc_set_mod_clk(struct sunxi_mmc_host *mmchost, unsigned int hz)
> {
> unsigned int pll, pll_hz, div, n, oclk_dly, sclk_dly;
> + bool new_mode = false;
> + u32 val = 0;
> +
> +#ifdef CONFIG_MMC_SUNXI_HAS_NEW_MODE
> + if (mmchost->mmc_no == 2)
> + new_mode = true;
> +#endif
Please change this ifdef to use:
if (IS_ENABLED(CONFIG_MMC_SUNXI_HAS_NEW_MODE))
> +
> + /*
> + * The MMC clock has an extra /2 post-divider when operating in the new
> + * mode.
> + */
> + if (new_mode)
> + hz = hz * 2;
>
> if (hz <= 2400) {
> pll = CCM_MMC_CTRL_OSCM24;
> @@ -143,9 +157,15 @@ static int mmc_set_mod_clk(struct sunxi_mmc_host
> *mmchost, unsigned int hz)
> #endif
> }
>
> - writel(CCM_MMC_CTRL_ENABLE | pll | CCM_MMC_CTRL_SCLK_DLY(sclk_dly) |
> -CCM_MMC_CTRL_N(n) | CCM_MMC_CTRL_OCLK_DLY(oclk_dly) |
> -CCM_MMC_CTRL_M(div), mmchost->mclkreg);
> + if (new_mode) {
> + val = BIT(30);
Does this BIT(30) have a name?
> + writel(BIT(31), &mmchost->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
Re: [U-Boot] [PATCH] sunxi: usb_phy: Fix the phy_ctl offset on the A83T
On Wed, 12 Jul 2017 16:44:25 +0200 Maxime Ripard wrote: > The A83T, just like the A33, has a USB phy with the phy_ctl at 0x410 > instead of 0x404. > > Suggested-by: Chen-Yu Tsai > Signed-off-by: Maxime Ripard > --- > arch/arm/mach-sunxi/usb_phy.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-sunxi/usb_phy.c b/arch/arm/mach-sunxi/usb_phy.c > index 9bf0b5633d4a..1ca9739fbee3 100644 > --- a/arch/arm/mach-sunxi/usb_phy.c > +++ b/arch/arm/mach-sunxi/usb_phy.c > @@ -19,7 +19,7 @@ > #include > > #define SUNXI_USB_PMU_IRQ_ENABLE 0x800 > -#ifdef CONFIG_MACH_SUN8I_A33 > +#if defined(CONFIG_MACH_SUN8I_A33) || defined(CONFIG_MACH_SUN8I_A83T) > #define SUNXI_USB_CSR0x410 > #else > #define SUNXI_USB_CSR0x404 Is only A83T affected? Just in case, please check which SUNXI_USB_CSR value is needed for the other SoC variants and add these SoCs explicitly to the ifdef checks. It also makes a lot of sense to get rid of the default #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
Re: [U-Boot] Pull request: u-boot-sunxi/master
On Fri, 16 Jun 2017 21:54:47 +0530
Jagan Teki wrote:
> Hi Tom,
>
> Please pull this PR.
>
> thanks!
> Jagan.
>
> The following changes since commit 24796d27be0d0f403ed6ad7e3022b33e36ac08b5:
>
> Merge git://git.denx.de/u-boot-ubi (2017-06-06 07:13:39 -0400)
>
> are available in the git repository at:
>
> git://git.denx.de/u-boot-sunxi.git master
>
> for you to fetch changes up to 2b1a33213e810f43f9d7e33b9d8db99e1b80a1c0:
>
> sun50i: h5: Add initial NanoPi NEO2 support (2017-06-14 20:25:56 +0530)
>
>
> Chen-Yu Tsai (1):
> sunxi: psci: Move entry address setting to separate function
>
> Icenowy Zheng (12):
> sunxi: makes an invisible option for H3-like DRAM controllers
> sunxi: Rename bus-width related macros in H3 DRAM code
> sunxi: add option for 16-bit DW DRAM controller
> sunxi: add bank detection code to H3 DRAM initialization code
> sunxi: Add selective DRAM type and timing
> sunxi: enable dual rank detection in DesignWare-like DRAM code
> sunxi: add support for the DDR2 in V3s SoC
> sunxi: add support for V3s DRAM controller
> sunxi: enable DRAM initialization and SPL for V3s SoC
> sunxi: add LPDDR3 DRAM type support for DesignWare-like DRAM controller
> sunxi: add LPDDR3 timing from stock boot0
> sunxi: add a defconfig for SoPine w/ official baseboard
Isn't this rather invasive change (a) still under review
and (b) scheduled for the next merge window either way?
Tom, please don't merge this pull request until we clarify its status.
>
> Jagan Teki (4):
> sun8i: h3: Add initial NanoPi M1 Plus support
> sun50i: h5: Add initial Orangepi Zero Plus 2 support
> sun50i: a64: Add initial Orangepi Win/WinPlus support
> sun50i: h5: Add initial NanoPi NEO2 support
>
> arch/arm/cpu/armv7/sunxi/psci.c| 25 ++-
> arch/arm/dts/Makefile | 6 +-
> arch/arm/dts/sun50i-a64-orangepi-win.dts | 94 +++
> arch/arm/dts/sun50i-h5-nanopi-neo2.dts | 86 ++
> arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts | 97 +++
> arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts | 64 +++
> arch/arm/include/asm/arch-sunxi/dram.h | 6 +-
> .../{dram_sun8i_h3.h => dram_sunxi_dw.h} | 36 +++-
> arch/arm/mach-sunxi/Kconfig| 75 -
> arch/arm/mach-sunxi/Makefile | 5 +-
> .../{dram_sun8i_h3.c => dram_sunxi_dw.c} | 187
> +++--
> arch/arm/mach-sunxi/dram_timings/Makefile | 3 +
> arch/arm/mach-sunxi/dram_timings/ddr2_v3s.c| 84 +
> arch/arm/mach-sunxi/dram_timings/ddr3_1333.c | 87 ++
> arch/arm/mach-sunxi/dram_timings/lpddr3_stock.c| 83 +
> board/sunxi/MAINTAINERS| 25 +++
> configs/nanopi_m1_plus_defconfig | 18 ++
> configs/nanopi_neo2_defconfig | 16 ++
> configs/orangepi_win_defconfig | 16 ++
> configs/orangepi_zero_plus2_defconfig | 18 ++
> configs/sopine_baseboard_defconfig | 22 +++
> 21 files changed, 910 insertions(+), 143 deletions(-)
> create mode 100644 arch/arm/dts/sun50i-a64-orangepi-win.dts
> create mode 100644 arch/arm/dts/sun50i-h5-nanopi-neo2.dts
> create mode 100644 arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts
> create mode 100644 arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts
> rename arch/arm/include/asm/arch-sunxi/{dram_sun8i_h3.h => dram_sunxi_dw.h}
> (86%)
> rename arch/arm/mach-sunxi/{dram_sun8i_h3.c => 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/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 configs/orangepi_zero_plus2_defconfig
> create mode 100644 configs/sopine_baseboard_defconfig
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH v2 00/12] Big work on sunxi DW DRAM controllers and some new DDR type support
On Sat, 3 Jun 2017 17:10:13 +0800
Icenowy Zheng wrote:
> This patchset contains several works on the sunxi DesignWare DRAM
> controllers.
>
> The 1st patch made an option for H3-like DRAM controllers
> (DesignWare ones), which can ease further import of alike controllers.
>
> The 2nd and 3rd patches are for supporting 16-bit DW DRAM controllers,
> in order to add V3s DRAM support (The controller on V3s is 16-bit).
>
> The 4th patch adds bank detection code, in order to support some DDR2
> chips.
>
> The 5th patch adds a framework for select DRAM type and timing -- it's
> needed for boards that use DRAM chips rather than DDR3.
>
> The 6th patch enables dual rank detection in the DW DRAM code on SoCs
> except R40. For R40 the dual rank facility is still not so clear, so it's
> temporarily disabled.
>
> The 7th~9th patches enables support for DRAM initialization and SPL for
> the V3s SoC, which integrates a DDR2 chip.
>
> The 10th and 11th patches adds support for LPDDR3, with the stock boot0
> timing. (Seen in A83T boot0 source and some leaked H5/R40 libdram source)
>
> The 12th patches adds a defconfig for SoPine w/ official baseboard, which
> utilizes LPDDR3.
>
> Icenowy Zheng (12):
> sunxi: makes an invisible option for H3-like DRAM controllers
> sunxi: Rename bus-width related macros in H3 DRAM code
> sunxi: add option for 16-bit DW DRAM controller
> sunxi: add bank detection code to H3 DRAM initialization code
> sunxi: Add selective DRAM type and timing
> sunxi: enable dual rank detection in DesignWare-like DRAM code
> sunxi: add support for the DDR2 in V3s SoC
> sunxi: add support for V3s DRAM controller
> sunxi: enable DRAM initialization and SPL for V3s SoC
> sunxi: add LPDDR3 DRAM type support for DesignWare-like DRAM
> controller
> sunxi: add LPDDR3 timing from stock boot0
> sunxi: add a defconfig for SoPine w/ official baseboard
>
> arch/arm/include/asm/arch-sunxi/dram.h | 6 +-
> .../{dram_sun8i_h3.h => dram_sunxi_dw.h} | 36 +++-
> arch/arm/mach-sunxi/Kconfig| 75 -
> arch/arm/mach-sunxi/Makefile | 5 +-
> .../{dram_sun8i_h3.c => dram_sunxi_dw.c} | 187
> +++--
> arch/arm/mach-sunxi/dram_timings/Makefile | 3 +
> arch/arm/mach-sunxi/dram_timings/ddr2_v3s.c| 84 +
> arch/arm/mach-sunxi/dram_timings/ddr3_1333.c | 87 ++
> arch/arm/mach-sunxi/dram_timings/lpddr3_stock.c| 83 +
> configs/sopine_baseboard_defconfig | 22 +++
> 10 files changed, 453 insertions(+), 135 deletions(-)
> rename arch/arm/include/asm/arch-sunxi/{dram_sun8i_h3.h => dram_sunxi_dw.h}
> (86%)
> rename arch/arm/mach-sunxi/{dram_sun8i_h3.c => 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/mach-sunxi/dram_timings/lpddr3_stock.c
> create mode 100644 configs/sopine_baseboard_defconfig
>
I'll have time to review your patchset on the coming weekend. Thanks!
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Ethernet not detecting on Odroid u3
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 try to boot on your ODROID-U3 board. Check if it
> > boots and if the Ethernet is working properly. And finally report
> > the results. If it works, then I will send cleaned up versions of
> > these patches to the U-Boot mailing list.
> >
> [snip]
>
> I dont feel the hack works perfectly.
Thanks for trying it.
Yes, these patches were not supposed to be perfect yet. But at least
it's good that the ODROID-U3 board model gets detected successfully
and the Ethernet gets initialized successfully at least on the first
run.
> I compiled your u-boot tree and could not load the kernel.
Well, at least it is not a regression introduced by my patches, right?
> [0] git clone -b 20170306-unbreak-odroid https://github.com/ssvb/u-boot.git
>
>
> U-Boot 2017.03-rc3-6-g3dd6fdb (Mar 14 2017 - 13:54:08 +)
>
> CPU: Exynos4412 @ 1 GHz
> Model: Odroid based on Exynos4412
> Board: Odroid based on Exynos4412
> Type: u3
> DRAM: 2 GiB
> LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling
> LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling
> LDO21@TFLASH_2.8V: set 280 uV; enabling
> MMC: SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1
> *** Warning - bad CRC, using default environment
>
> Net: No ethernet found.
> Hit any key to stop autoboot: 0
> reading boot.scr
> 3174 bytes read in 49 ms (62.5 KiB/s)
> ## Executing script at 4200
> Found kernel image: zImage
> reading exynos4412-odroidu3.dtb
> 54561 bytes read in 23 ms (2.3 MiB/s)
> Found ramdisk image.
> reading uInitrd
> 9873974 bytes read in 679 ms (13.9 MiB/s)
> reading zImage
> 6552912 bytes read in 460 ms (13.6 MiB/s)
> Kernel image @ 0x40007fc0 [ 0x00 - 0x63fd50 ]
> ## Loading init Ramdisk from Legacy Image at 4200 ...
>Image Name: uInitrdu3
>Image Type: ARM Linux RAMDisk Image (gzip compressed)
>Data Size:9873910 Bytes = 9.4 MiB
>Load Address: 4200
>Entry Point: 4200
>Verifying Checksum ... OK
> ## Flattened Device Tree blob at 4080
>Booting using the fdt blob at 0x4080
>Loading Ramdisk to ba4d6000, end bae409f6 ... OK
>Loading Device Tree to ba4c5000, end ba4d5520 ... OK
>
> Starting kernel ...
>
> After that I had to remove my zImage and exynos4412-odroidu3.dtb to
> enter into u-boot prompt to manually test.
Have you just dropped the dtb file and zImage on the first partition
of the SD card?
Yes, I can confirm that without having a boot script there and using
scripts from the default U-Boot environment it does get stuck in
exactly this way.
You can create something like the following "boot.cmd" file (it's just
a chopped up version of something ODROID related found on the Internet):
setenv zimg_addr "0x40008000"
setenv fdt_addr "0x41f0"
setenv fdt_high "0x"
setenv zimg_file "zImage"
setenv uloadcmd "load mmc 0:1 ${zimg_addr} ${zimg_file}; fatload mmc 0:1
${fdt_addr} ${fdtfile}"
setenv bootcmd "run uloadcmd; fdt addr ${fdt_addr}; fdt resize; bootz
${zimg_addr} - ${fdt_addr}"
boot
Then create a boot script from this file using the following command:
"mkimage -C none -A arm -T script -d boot.cmd boot.scr"
Then the "boot.scr" file should be copied to the SD card. The linux
kernel should at least start booting. But you will also need to
provide a kernel cmdline with the location of your rootfs.
I think that we should review the default boot scripts in the U-Boot
environment for Exynos based ODROID bords. As you can see, the current
behaviour is very hostile to the users.
>
> U-Boot 2017.03-rc3-6-g3dd6fdb (Mar 14 2017 - 13:54:08 +)
>
> CPU: Exynos4412 @ 1 GHz
> Model: Odroid based on Exynos4412
> Board: Odroid based on Exynos4412
> Type: u3
> DRAM: 2 GiB
> LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling
> LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling
> LDO21@TFLASH_2.8V: set 280 uV; enabling
> MMC: SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1
> *** Warning - bad CRC, using default environment
>
> Net: No ethernet found.
> Hit any key to stop autoboot: 0
> reading boot.scr
> 3174 bytes read in 26 ms (119.1 KiB/s)
> ## Executing script at
Re: [U-Boot] Ethernet not detecting on Odroid u3
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: > >> > >>> Hi All, > >>> > >>> I tried to compile the latest u-boot for Odroid U3. > >>> issue is that Ethernet is not able to detected. > >>> > >>> Please let me know what need to enable USB Ethernet > >>> to support tftp boot. > >>> > >>> Best Regards > >>> -Anand > >>> > >>> -- > >>> U-Boot 2017.01-02075-g4386feb-dirty (Jan 12 2017 - 06:17:08 +) > >>> > >>> CPU: Exynos4412 @ 1 GHz > >>> Model: Odroid based on Exynos4412 > >>> Board: Odroid based on Exynos4412 > >>> Type: u3 > >>> DRAM: 2 GiB > >>> LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling > >>> LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling > >>> LDO21@TFLASH_2.8V: set 280 uV; enabling > >>> MMC: SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1 > >>> *** Warning - bad CRC, using default environment > >>> > >>> Net: No ethernet found. > >>> Hit any key to stop autoboot: 0 > >>> Odroid # > >>> Odroid # > >>> Odroid # usb start > >>> starting USB... > >>> USB0: USB EHCI 1.00 > >>> scanning bus 0 for devices... 1 USB Device(s) found > >>>scanning usb for ethernet devices... 0 Ethernet Device(s) found > >>> Odroid # > >>> Odroid # > >>> Odroid # setenv usbethaddr 02:DE:AD:BE:EF:FF > >>> Odroid # usb start > >>> Odroid # usb info > >>> 1: Hub, USB Revision 2.0 > >>> - u-boot EHCI Host Controller > >>> - Class: Hub > >>> - PacketSize: 64 Configurations: 1 > >>> - Vendor: 0x Product 0x Version 1.0 > >>>Configuration: 1 > >>>- Interfaces: 1 Self Powered 0mA > >>> Interface: 0 > >>> - Alternate Setting 0, Endpoints: 1 > >>> - Class Hub > >>> - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms > >>> > >>> Odroid # reset > >> > >> Hi Anand, > >> > >> It's an old problem and we have identified its root cause a long > >> time ago: > >> > >> https://lists.denx.de/pipermail/u-boot/2015-October/231061.html > >> > >> Basically, a voltage regulator is not getting initialized because > >> a call to the board_usb_init() function was lost during the DM > >> conversion. You can try to compile U-Boot from my branch, it contains > >> the rebased fixes which I have been using all this time on my ODROID-X > >> board: > >> > >> https://github.com/ssvb/u-boot/commits/20170306-unbreak-odroid > >> > >> I did all the initial investigation back in 2015, but tried to > >> delegate the actual bugfixing work to the ODROID board maintainer(s). > >> Apparently it did not fly and ODROID support is still broken. > >> > >> If you can 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! > > > > Hello again, > > > > Anand Moon, considering no reply to my post, do I understand it > > right that you are actually not very much interested in getting > > this particular problem resolved in U-Boot? > > > > These ODROID problems are relatively simple and don't require any > > special skills or considerable efforts to resolve. The only issue > > is that apparently almost nobody uses the mainline U-Boot on this > > hardware and nobody gives rats about having it usable out of the > > box. > > > > I only have an ODROID-X board, which is a rather early and > > short-lived revision. Again, if you or anybody else could step in > > and take care of testing the fixes on other ODROID boards (X2 and > > U3), then we could get ODROID boards working properly in the next > > U-Boot release. > > > > > > Jaehoon Chung, you seem to be listed as the current nominal ODROID > > boards maintainer. But you don't seem to be doing anything other > > than just making promises to check various things and then > >
Re: [U-Boot] Ethernet not detecting on Odroid u3
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 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. > >>>> > >>>> Please let me know what need to enable USB Ethernet > >>>> to support tftp boot. > >>>> > >>>> Best Regards > >>>> -Anand > >>>> > >>>> -- > >>>> U-Boot 2017.01-02075-g4386feb-dirty (Jan 12 2017 - 06:17:08 +) > >>>> > >>>> CPU: Exynos4412 @ 1 GHz > >>>> Model: Odroid based on Exynos4412 > >>>> Board: Odroid based on Exynos4412 > >>>> Type: u3 > >>>> DRAM: 2 GiB > >>>> LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling > >>>> LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling > >>>> LDO21@TFLASH_2.8V: set 280 uV; enabling > >>>> MMC: SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1 > >>>> *** Warning - bad CRC, using default environment > >>>> > >>>> Net: No ethernet found. > >>>> Hit any key to stop autoboot: 0 > >>>> Odroid # > >>>> Odroid # > >>>> Odroid # usb start > >>>> starting USB... > >>>> USB0: USB EHCI 1.00 > >>>> scanning bus 0 for devices... 1 USB Device(s) found > >>>>scanning usb for ethernet devices... 0 Ethernet Device(s) found > >>>> Odroid # > >>>> Odroid # > >>>> Odroid # setenv usbethaddr 02:DE:AD:BE:EF:FF > >>>> Odroid # usb start > >>>> Odroid # usb info > >>>> 1: Hub, USB Revision 2.0 > >>>> - u-boot EHCI Host Controller > >>>> - Class: Hub > >>>> - PacketSize: 64 Configurations: 1 > >>>> - Vendor: 0x Product 0x Version 1.0 > >>>>Configuration: 1 > >>>>- Interfaces: 1 Self Powered 0mA > >>>> Interface: 0 > >>>> - Alternate Setting 0, Endpoints: 1 > >>>> - Class Hub > >>>> - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms > >>>> > >>>> Odroid # reset > >>> > >>> Hi Anand, > >>> > >>> It's an old problem and we have identified its root cause a long > >>> time ago: > >>> > >>> https://lists.denx.de/pipermail/u-boot/2015-October/231061.html > >>> > >>> Basically, a voltage regulator is not getting initialized because > >>> a call to the board_usb_init() function was lost during the DM > >>> conversion. You can try to compile U-Boot from my branch, it contains > >>> the rebased fixes which I have been using all this time on my ODROID-X > >>> board: > >>> > >>> https://github.com/ssvb/u-boot/commits/20170306-unbreak-odroid > >>> > >>> I did all the initial investigation back in 2015, but tried to > >>> delegate the actual bugfixing work to the ODROID board maintainer(s). > >>> Apparently it did not fly and ODROID support is still broken. > >>> > >>> If you can 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! > >> > >> Hello again, > >> > >> Anand Moon, considering no reply to my post, do I understand it > >> right that you are actually not very much interested in getting > >> this particular problem resolved in U-Boot? > >> > >> These ODROID problems are relatively simple and don't require any > >> special skills or considerable efforts to resolve. The only issue > >> is that apparently almost nobody uses the mainline U-Boot on this > >> hardware and nobody gives rats about having it usable out of the > >> box. > >> > >> I only have an ODROID-X board, which is a rather early and > >> short-lived revision. Ag
Re: [U-Boot] Ethernet not detecting on Odroid u3
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. > > > > Please let me know what need to enable USB Ethernet > > to support tftp boot. > > > > Best Regards > > -Anand > > > > -- > > U-Boot 2017.01-02075-g4386feb-dirty (Jan 12 2017 - 06:17:08 +) > > > > CPU: Exynos4412 @ 1 GHz > > Model: Odroid based on Exynos4412 > > Board: Odroid based on Exynos4412 > > Type: u3 > > DRAM: 2 GiB > > LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling > > LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling > > LDO21@TFLASH_2.8V: set 280 uV; enabling > > MMC: SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1 > > *** Warning - bad CRC, using default environment > > > > Net: No ethernet found. > > Hit any key to stop autoboot: 0 > > Odroid # > > Odroid # > > Odroid # usb start > > starting USB... > > USB0: USB EHCI 1.00 > > scanning bus 0 for devices... 1 USB Device(s) found > >scanning usb for ethernet devices... 0 Ethernet Device(s) found > > Odroid # > > Odroid # > > Odroid # setenv usbethaddr 02:DE:AD:BE:EF:FF > > Odroid # usb start > > Odroid # usb info > > 1: Hub, USB Revision 2.0 > > - u-boot EHCI Host Controller > > - Class: Hub > > - PacketSize: 64 Configurations: 1 > > - Vendor: 0x Product 0x Version 1.0 > >Configuration: 1 > >- Interfaces: 1 Self Powered 0mA > > Interface: 0 > > - Alternate Setting 0, Endpoints: 1 > > - Class Hub > > - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms > > > > Odroid # reset > > Hi Anand, > > It's an old problem and we have identified its root cause a long > time ago: > > https://lists.denx.de/pipermail/u-boot/2015-October/231061.html > > Basically, a voltage regulator is not getting initialized because > a call to the board_usb_init() function was lost during the DM > conversion. You can try to compile U-Boot from my branch, it contains > the rebased fixes which I have been using all this time on my ODROID-X > board: > > https://github.com/ssvb/u-boot/commits/20170306-unbreak-odroid > > I did all the initial investigation back in 2015, but tried to > delegate the actual bugfixing work to the ODROID board maintainer(s). > Apparently it did not fly and ODROID support is still broken. > > If you can 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! Hello again, Anand Moon, considering no reply to my post, do I understand it right that you are actually not very much interested in getting this particular problem resolved in U-Boot? These ODROID problems are relatively simple and don't require any special skills or considerable efforts to resolve. The only issue is that apparently almost nobody uses the mainline U-Boot on this hardware and nobody gives rats about having it usable out of the box. I only have an ODROID-X board, which is a rather early and short-lived revision. Again, if you or anybody else could step in and take care of testing the fixes on other ODROID boards (X2 and U3), then we could get ODROID boards working properly in the next U-Boot release. Jaehoon Chung, you seem to be listed as the current nominal ODROID boards maintainer. But you don't seem to be doing anything other than just making promises to check various things and then disappearing for months/years: https://lists.denx.de/pipermail/u-boot/2017-January/277954.html https://lists.denx.de/pipermail/u-boot/2015-October/231023.html Could you please explain what's going on and what are your plans regarding ODROID boards support in U-Boot? -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] arm: omap3: Bring back ARM errata workaround 725233
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). Bring it back in order to avoid > > very difficult to reproduce, but actually encountered in > > the wild CPU deadlocks when running software rendered > > X11 desktop 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 > > In concept: > Reviewed-by: Tom Rini Thanks! > Do you want to v2 on top of my patch that migrates the current ARM > errata or would you rather I v2 it and apply? Thanks again! Sure, either way is fine for me. There is just one thing that is not very good yet. Setting the L2 Auxiliary Control Register is currently a no-op in my patch for the HS variants of OMAP3430/3530 because they are using a different secure monitor API. And I don't know anything about it and don't even have such hardware to run any tests. And there is not much that can be done about it there. We have no serial console yet to print any diagnostic warnings. So I wonder if it makes sense to add one more errata related patch, responsible for verifying correctness of the applied errata workarounds at a much later stage. Basically, the difference is the following. When applying errata workarounds: * Writing to coprocessor registers is restricted and may require the use of SoC-specific secure monitor API. * Errata workarounds need to be applied as early as possible and we don't have the serial console for any debugging or diagnostic messages yet. And when validating errata workarounds: * Reading coprocessor registers is not a problem and can be done via a simple MRC instruction. * The validation can be done at any time, even postponed until just before loading the OS kernel. We can print warnings if something is not right or even abort booting (after printing a comprehensive error message). So if I implement such additional errata validation patch, then anyone with a HS OMAP3430 device can notice that there is a problem and implement the missing L2 Auxiliary Control Register setup code. What do you think about this? -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: cache: exit maintenance functions when cache disabled
On Fri, 10 Mar 2017 12:26:36 +0100
Gary Bisson wrote:
> No need to check the region range and send commands when the cache
> isn't even enabled.
>
> Signed-off-by: Gary Bisson
> ---
> Hi all,
>
> This is a follow-up to this thread:
> https://lists.denx.de/pipermail/u-boot/2017-March/283423.html
>
> Although what started the conversation was the sparse-image flashing
> procedure, it appears cache maintenance functions don't check on cache
> status.
>
> Regards,
> Gary
> ---
> arch/arm/cpu/armv7/cache_v7.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
> index c4bbcc3cc3..992cdeaa6e 100644
> --- a/arch/arm/cpu/armv7/cache_v7.c
> +++ b/arch/arm/cpu/armv7/cache_v7.c
> @@ -117,6 +117,9 @@ void flush_dcache_all(void)
> */
> void invalidate_dcache_range(unsigned long start, unsigned long stop)
> {
> + if (!dcache_status())
> + return;
> +
> check_cache_range(start, stop);
>
> v7_dcache_maint_range(start, stop, ARMV7_DCACHE_INVAL_RANGE);
> @@ -131,6 +134,9 @@ void invalidate_dcache_range(unsigned long start,
> unsigned long stop)
> */
> void flush_dcache_range(unsigned long start, unsigned long stop)
> {
> + if (!dcache_status())
> + return;
> +
> check_cache_range(start, stop);
>
> v7_dcache_maint_range(start, stop, ARMV7_DCACHE_CLEAN_INVAL_RANGE);
Hello Gary,
Please be very careful with this stuff:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438i/BABHEJFF.html
"6.4.3. Cache disabled behavior
When you clear the C bit in the CP15 System Control Register for a given
processor, see System Control Register, data caching is disabled and
no new cache lines are allocated to the L1 data cache and L2 cache
because of requests from that processor. This is important when
cleaning and invalidating the caches for power down. Cache lines can
be allocated from memory requests of other processors, unless their
cache enable bits are also cleared. The effect on the L1 memory system
is that all Write-Back Read-Write-Allocate pages are treated as
Write-Back No-Allocate pages.
When you disable the cache, all Write-Back Cacheable requests still
look up the L1 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."
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
Re: [U-Boot] [PATCH 1/1] arm: Migrate SYS_THUMB_BUILD to Kconfig, introduce SPL_SYS_THUMB_BUILD
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 build all of U-Boot in Thumb2 mode > > > for > > > various reasons. We also have cases where we only build SPL in Thumb2 > > > mode due > > > to size constraints and wish to build the rest of the system in ARM mode. > > > > > > > Is there a good real world example of this particular use case? Even if > > there is enough space for having the U-Boot binary built in ARM mode, > > Thumb2 is still smaller and loads faster. And having reduced boot time > > is always nice. > > So, good question. At the moment, I'm not trying to change existing > behavior. I also seem to recall that Thumb2 being a performance win > depends on what you're doing. It would certainly be worth doing some > tests to see if on say Allwinner where today we don't do the main U-Boot > in Thumb2 mode there is a noticable change as it looked like a pretty > big size win. Hmm, you are right. Currently the 'sunxi-common.h' file has the following lines: #if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_ARM64) #define CONFIG_SYS_THUMB_BUILD /* Thumbs mode to save space in SPL */ #endif I even did not know and was not careful enough to ever notice that sunxi builds the main U-Boot binary in ARM mode. This just seems to be weird. Basically, you are introducing two separate Kconfig options just to accommodate the current sunxi configuration, right? I guess, the next step would be to fix sunxi to use Thumb2 everywhere :-) Now your patch at least makes sense and looks good to me. Acked-by: Siarhei Siamashka -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] odroid: Add support for the ODROID-X board variant
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
> > 1.4GHz revision of Exynos4412 SoC and less RAM (1GiB instead
> > of 2GiB).
> >
> > The current U-Boot code deadlocks on ODROID-X when probing the RAM
> > size via get_ram_size() function. Reducing CONFIG_NR_DRAM_BANKS
> > from 8 to 4 can fix this problem. But this constant is used in
> > a lot of places in U-Boot, while SDRAM_BANK_SIZE can be easily
> > replaced with the code which relies on runtime detection of the
> > board type. So we change 4 or 8 banks of 256MiB with just one
> > fake bank of 2GiB or 1GiB. The runtime detection check tries to
> > read the PRO_ID register in the hope that it might be different
> > between Exynos4412 and Exynos4412 Prime and enough to detect
> > the difference between X and X2 board variants.
> >
> > Signed-off-by: Siarhei Siamashka
> > ---
> >
> > I'm assuming that the X and X2 hardware is nearly identical
> > and can be supported with a common code in U-Boot, based on
> > the changelog of PCB revisions:
> > http://com.odroid.com/sigong/blog/blog_list.php?bid=132
> >
> > This is an RFC patch because I don't have an X2 board and can't
> > test if checking the PRO_ID register is good enough. If it does
> > not work, then maybe some other method could be tried (probe
> > the DRAM controller registers?).
> >
> > Also does the number of DRAM banks have any special meaning on
> > this platform in U-Boot and Linux (after the proprietary blob
> > has already initialized the DRAM controller)?
> >
> > If this approach is wrong, then what would be the best way to
> > add support for the ODROID-X board?
> >
> > Thanks.
> >
> > board/samsung/common/board.c | 21 +
> > board/samsung/odroid/odroid.c | 14 ++
> > include/configs/odroid.h | 10 ++
> > 3 files changed, 33 insertions(+), 12 deletions(-)
> >
> > diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
> > index d32c75d..ac3ed4c 100644
> > --- a/board/samsung/common/board.c
> > +++ b/board/samsung/common/board.c
> > @@ -94,14 +94,26 @@ int board_init(void)
> > return exynos_init();
> > }
> >
> > +static u32 get_sdram_bank_size(void)
> > +{
> > + u32 sdram_bank_size = SDRAM_BANK_SIZE;
> > +#ifdef CONFIG_BOARD_TYPES
> > + if (strcmp(CONFIG_SYS_BOARD, "odroid") == 0 &&
> > + strcmp(get_board_type(), "x") == 0)
> > + sdram_bank_size = SDRAM_BANK_SIZE_ODROIDX;
> > +#endif
> > + return sdram_bank_size;
> > +}
> > +
> > int dram_init(void)
> > {
> > unsigned int i;
> > u32 addr;
> > + u32 sdram_bank_size = get_sdram_bank_size();
> >
> > for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
> > - addr = CONFIG_SYS_SDRAM_BASE + (i * SDRAM_BANK_SIZE);
> > - gd->ram_size += get_ram_size((long *)addr, SDRAM_BANK_SIZE);
> > + addr = CONFIG_SYS_SDRAM_BASE + (i * sdram_bank_size);
> > + gd->ram_size += get_ram_size((long *)addr, sdram_bank_size);
> > }
> > return 0;
> > }
> > @@ -110,10 +122,11 @@ void dram_init_banksize(void)
> > {
> > unsigned int i;
> > u32 addr, size;
> > + u32 sdram_bank_size = get_sdram_bank_size();
> >
> > for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
> > - addr = CONFIG_SYS_SDRAM_BASE + (i * SDRAM_BANK_SIZE);
> > - size = get_ram_size((long *)addr, SDRAM_BANK_SIZE);
> > + addr = CONFIG_SYS_SDRAM_BASE + (i * sdram_bank_size);
> > + size = get_ram_size((long *)addr, sdram_bank_size);
> >
> > gd->bd->bi_dram[i].start = addr;
> > gd->bd->bi_dram[i].size = size;
> > diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
> > index 32155f1..e98e3be 100644
> > --- a/board/samsung/odroid/odroid.c
> > +++ b/board/samsung/odroid/odroid.c
> > @@ -30,6 +30,7 @@ DECLARE_GLOBAL_DATA_PTR;
> > enum {
> > ODROID_TYPE_U3,
> > ODROID_TYPE_X2,
> > + ODROID_TYPE_X,
> > ODROID_TYPES,
> > };
> >
> > @@ -56,15 +57,20 @@ void set_board_type(void)
> > sdelay(20);
> >
> >
Re: [U-Boot] sdhci_transfer_data: Error detected in status(0x208002) problem on Tiny4412 board
MD_SEND:16 > ARG 0x0200 > MMC_RSP_R1,5,6,7 0x0900 > *CMD_SEND:17 > ARG 0x > sdhci_transfer_data: Error detected in status(0x208002)! > RET -70* > CMD_SEND:16 > ARG 0x0200 > MMC_RSP_R1,5,6,7 0x0900 > *CMD_SEND:18 > ARG 0x0040 > sdhci_transfer_data: Error detected in status(0x208000)! > RET -70* > SD/MMC found on device 0 > *CMD_SEND:16 > ARG 0x0200 > RET -110 > CMD_SEND:16 > ARG 0x0200 > RET -110 > ** ext4fs_devread read error - block > Failed to mount ext2 filesystem... > ** Unrecognized filesystem type *** > *CMD_SEND:16 > ARG 0x0200 > RET -110 > CMD_SEND:16 > ARG 0x0200 > RET -110 > ** ext4fs_devread read error - block > Failed to mount ext2 filesystem... > ** Unrecognized filesystem type ** > CMD_SEND:16 > ARG 0x0200 > RET -110 > CMD_SEND:16 > ARG 0x0200 > RET -110 > ** ext4fs_devread read error - block > Failed to mount ext2 filesystem... > ** 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
Re: [U-Boot] [PATCH 1/1] arm: Migrate SYS_THUMB_BUILD to Kconfig, introduce SPL_SYS_THUMB_BUILD
Hi Tom, On Mon, 6 Mar 2017 13:50:10 -0500 Tom Rini wrote: > Today, we have cases where we wish to build all of U-Boot in Thumb2 mode for > various reasons. We also have cases where we only build SPL in Thumb2 mode > due > to size constraints and wish to build the rest of the system in ARM mode. Is there a good real world example of this particular use case? Even if there is enough space for having the U-Boot binary built in ARM mode, Thumb2 is still smaller and loads faster. And having reduced boot time is always nice. > So in this migration 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 [...] -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Ethernet not detecting on Odroid u3
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. > > Please let me know what need to enable USB Ethernet > to support tftp boot. > > Best Regards > -Anand > > -- > U-Boot 2017.01-02075-g4386feb-dirty (Jan 12 2017 - 06:17:08 +) > > CPU: Exynos4412 @ 1 GHz > Model: Odroid based on Exynos4412 > Board: Odroid based on Exynos4412 > Type: u3 > DRAM: 2 GiB > LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling > LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling > LDO21@TFLASH_2.8V: set 280 uV; enabling > MMC: SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1 > *** Warning - bad CRC, using default environment > > Net: No ethernet found. > Hit any key to stop autoboot: 0 > Odroid # > Odroid # > Odroid # usb start > starting USB... > USB0: USB EHCI 1.00 > scanning bus 0 for devices... 1 USB Device(s) found >scanning usb for ethernet devices... 0 Ethernet Device(s) found > Odroid # > Odroid # > Odroid # setenv usbethaddr 02:DE:AD:BE:EF:FF > Odroid # usb start > Odroid # usb info > 1: Hub, USB Revision 2.0 > - u-boot EHCI Host Controller > - Class: Hub > - PacketSize: 64 Configurations: 1 > - Vendor: 0x Product 0x Version 1.0 >Configuration: 1 >- Interfaces: 1 Self Powered 0mA > Interface: 0 > - Alternate Setting 0, Endpoints: 1 > - Class Hub > - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms > > Odroid # reset Hi Anand, It's an old problem and we have identified its root cause a long time ago: https://lists.denx.de/pipermail/u-boot/2015-October/231061.html Basically, a voltage regulator is not getting initialized because a call to the board_usb_init() function was lost during the DM conversion. You can try to compile U-Boot from my branch, it contains the rebased fixes which I have been using all this time on my ODROID-X board: https://github.com/ssvb/u-boot/commits/20170306-unbreak-odroid I did all the initial investigation back in 2015, but tried to delegate the actual bugfixing work to the ODROID board maintainer(s). Apparently it did not fly and ODROID support is still broken. If you can 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
Re: [U-Boot] BeagleBoard B7 (OMAP3530) fails to boot with the current U-Boot master branch
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 for it. Appears that > > it is broken since almost 2 years ago: > > > >https://lists.denx.de/pipermail/u-boot/2015-July/220332.html > >https://lists.denx.de/pipermail/u-boot/2016-May/253777.html > > > > And after trying to narrow it down, looks like the failure happens in > > the prcm_init() function from 'arch/arm/mach-omap2/omap3/clock.c' when > > it is compiled as Thumb2. At least the SPL can successfully boot after > > the following change (GCC6 is needed for this pragma): > > Good job sorting this out. I think it might be best to just disable > Thumb on beagleboard. Well, apparently this "disabling Thumb" plan is not moving anywhere in practice. The current situation is less than perfect and downstream (Robert Nelson) is already disabling Thumb since a while ago together with CONFIG_SPL_EXT_SUPPORT. And the mainline U-Boot keeps providing releases, which are unusable for OMAP3530 out-of-the box. Regarding Thumb2 support in general. Yes, the old r1p3 revision of Cortex A8 in OMAP3530 is affected by multiple Thumb errata. But I checked the errata list and seems like we don't have to worry about 657417 (A 32bit branch instruction that spans two 4K regions can result in an incorrect instruction fetch or processor deadlock) after all because the bug affects processors with 32KiB of L1 I-Cache, while OMAP3530 only has 16 KiB. The other Thumb errata might also have no real effect on U-Boot, because some of them involve the use of MMU and virtual addresses. In the end, we are applying them for the sake of the Linux kernel and userland software. Yes, I still don't like how errata workarounds are handled by U-Boot. This stuff looks way too complicated and frameworkish. I mean that we get the v7_arch_cp15_set_l2aux_ctrl() and v7_arch_cp15_set_acr() functions implemented in the C code, and they also do some elaborate runtime detection of the SoC variant. These functions are compiled as Thumb code, so we get quite a bit of Thumb interworking activity happening even before we have a chance to apply some relevant errata workarounds. But no matter how ugly this stuff is, it does not seem to cause real problems in practice. So I suspect that the prcm_init() function fails not because of Thumb as such, but because recompiling it as Thumb probably changes the timings of the initialization in a subtle way. Also I don't quite like the code constructs like this: /* M (CORE_DPLL_MULT): CM_CLKSEL1_PLL[16:26] */ clrsetbits_le32(&prcm_base->clksel1_pll, 0x07FF, ptr->m << 16); /* N (CORE_DPLL_DIV): CM_CLKSEL1_PLL[8:14] */ clrsetbits_le32(&prcm_base->clksel1_pll, 0x7F00, ptr->n << 8); Wouldn't it be more reasonable to change both M and N values as a single atomic operation? Maybe it's a good idea to check the the OMAP3530 errata list to see if there are any known quirks in the DPLL setup sequence. But I would prefer to leave the further investigation up to the TI people and local OMAP experts. Either way, as a quick and dirty workaround, we currently can enable ARM mode compilation for just a singe clock.c file instead of the whole SPL. And this source file can be even split into parts if we want better granularity. I have sent some OMAP3530 patches to the list: https://lists.denx.de/pipermail/u-boot/2017-March/283074.html -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] arm: omap3: Bring back ARM errata workaround 725233
The workaround for ARM errata 725233 had been lost since
commit 45bf05854bc94e (armv7: adapt omap3 to the new cache
maintenance framework). Bring it back in order to avoid
very difficult to reproduce, but actually encountered in
the wild CPU deadlocks when running software rendered
X11 desktop 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
---
arch/arm/cpu/armv7/start.S | 13 +
arch/arm/include/asm/arch-omap3/omap.h | 1 +
arch/arm/mach-omap2/omap3/board.c | 10 ++
include/configs/ti_omap3_common.h | 1 +
scripts/config_whitelist.txt | 1 +
5 files changed, 26 insertions(+)
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 7eee54b..1a6aee9 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -270,6 +270,19 @@ skip_errata_430973:
skip_errata_621766:
#endif
+#ifdef CONFIG_ARM_ERRATA_725233
+ cmp r2, #0x21 @ Only on < r2p1 (Cortex A8)
+ bge skip_errata_725233
+
+ mrc p15, 1, r0, c9, c0, 2 @ Read L2ACR
+ orr r0, r0, #(0x1 << 27)@ L2 PLD data forwarding disable
+ push{r1-r5} @ Save the cpu info registers
+ bl v7_arch_cp15_set_l2aux_ctrl
+ pop {r1-r5} @ Restore the cpu info - fall through
+
+skip_errata_725233:
+#endif
+
mov pc, r5 @ back to my caller
ENDPROC(cpu_init_cp15)
diff --git a/arch/arm/include/asm/arch-omap3/omap.h
b/arch/arm/include/asm/arch-omap3/omap.h
index 91d73c2..db763e4 100644
--- a/arch/arm/include/asm/arch-omap3/omap.h
+++ b/arch/arm/include/asm/arch-omap3/omap.h
@@ -243,6 +243,7 @@ struct gpio {
* ROM code API related flags
*/
#define OMAP3_GP_ROMCODE_API_L2_INVAL 1
+#define OMAP3_GP_ROMCODE_API_WRITE_L2ACR 2
#define OMAP3_GP_ROMCODE_API_WRITE_ACR 3
/*
diff --git a/arch/arm/mach-omap2/omap3/board.c
b/arch/arm/mach-omap2/omap3/board.c
index 5f55977..cc83cd7 100644
--- a/arch/arm/mach-omap2/omap3/board.c
+++ b/arch/arm/mach-omap2/omap3/board.c
@@ -368,6 +368,16 @@ void __weak omap3_set_aux_cr_secure(u32 acr)
(u32 *)&emu_romcode_params);
}
+void v7_arch_cp15_set_l2aux_ctrl(u32 l2auxctrl, u32 cpu_midr,
+u32 cpu_rev_comb, u32 cpu_variant,
+u32 cpu_rev)
+{
+ if (get_device_type() == GP_DEVICE)
+ omap_smc1(OMAP3_GP_ROMCODE_API_WRITE_L2ACR, l2auxctrl);
+
+ /* L2 Cache Auxiliary Control Register is not banked */
+}
+
void v7_arch_cp15_set_acr(u32 acr, u32 cpu_midr, u32 cpu_rev_comb,
u32 cpu_variant, u32 cpu_rev)
{
diff --git a/include/configs/ti_omap3_common.h
b/include/configs/ti_omap3_common.h
index 0ad3235..cbd6f98 100644
--- a/include/configs/ti_omap3_common.h
+++ b/include/configs/ti_omap3_common.h
@@ -25,6 +25,7 @@
#define CONFIG_ARM_ERRATA_454179
#define CONFIG_ARM_ERRATA_430973
#define CONFIG_ARM_ERRATA_621766
+#define CONFIG_ARM_ERRATA_725233
/* The chip has SDRC controller */
#define CONFIG_SDRC
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index f6c9101..bb5387d 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -145,6 +145,7 @@ CONFIG_ARM_ERRATA_430973
CONFIG_ARM_ERRATA_454179
CONFIG_ARM_ERRATA_621766
CONFIG_ARM_ERRATA_716044
+CONFIG_ARM_ERRATA_725233
CONFIG_ARM_ERRATA_742230
CONFIG_ARM_ERRATA_743622
CONFIG_ARM_ERRATA_751472
--
2.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] arm: omap3: Compile clock.c with -marm option to unbreak OMAP3530
Boards with OMAP3530 SoC fail to boot since commit bd2c4522c26d5
("ti: armv7: enable EXT support in SPL (using ti_armv7_common.h)")
because it enabled the use of Thumb2 for the SPL.
Experiments have shown that the deadlock happens in the
prcm_init() function from 'arch/arm/mach-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
---
arch/arm/mach-omap2/omap3/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2/omap3/Makefile
b/arch/arm/mach-omap2/omap3/Makefile
index b2fce96..06cc9f2 100644
--- a/arch/arm/mach-omap2/omap3/Makefile
+++ b/arch/arm/mach-omap2/omap3/Makefile
@@ -5,6 +5,9 @@
# SPDX-License-Identifier: GPL-2.0+
#
+# If clock.c is compiled for Thumb2, then it fails on OMAP3530
+CFLAGS_clock.o += -marm
+
obj-y := lowlevel_init.o
obj-y += board.o
--
2.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] Unbreak OMAP3530
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 arm: omap3: Bring back ARM errata workaround 725233 arch/arm/cpu/armv7/start.S | 13 + arch/arm/include/asm/arch-omap3/omap.h | 1 + arch/arm/mach-omap2/omap3/Makefile | 3 +++ arch/arm/mach-omap2/omap3/board.c | 10 ++ include/configs/ti_omap3_common.h | 1 + scripts/config_whitelist.txt | 1 + 6 files changed, 29 insertions(+) -- 2.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
[U-Boot] BeagleBoard B7 (OMAP3530) fails to boot with the current U-Boot master branch
Hello All,
I have just unexpectedly found an old Beagleboard B7 in my closet and
tried to compile the current U-Boot master branch for it. Appears that
it is broken since almost 2 years ago:
https://lists.denx.de/pipermail/u-boot/2015-July/220332.html
https://lists.denx.de/pipermail/u-boot/2016-May/253777.html
And after trying to narrow it down, looks like the failure happens in
the prcm_init() function from 'arch/arm/mach-omap2/omap3/clock.c' when
it is compiled as Thumb2. At least the SPL can successfully boot after
the following change (GCC6 is needed for this pragma):
diff --git a/arch/arm/mach-omap2/omap3/clock.c
b/arch/arm/mach-omap2/omap3/clock.c
index 006969e..8064fa6 100644
--- a/arch/arm/mach-omap2/omap3/clock.c
+++ b/arch/arm/mach-omap2/omap3/clock.c
@@ -592,6 +592,8 @@ static void iva_init_36xx(u32 sil_index, u32 clk_index)
wait_on_value(ST_IVA2_CLK, 1, &prcm_base->idlest_pll_iva2, LDELAY);
}
+#pragma GCC target ("arm")
+
/**
* prcm_init() - inits clocks for PRCM as defined in clocks.h
* called from SRAM, or Flash (using temp SRAM stack).
@@ -700,6 +702,8 @@ void prcm_init(void)
sdelay(5000);
}
+#pragma GCC target ("thumb")
+
/*
* Enable usb ehci uhh, tll clocks
*/
Now it's very interesting to figure out what exactly is wrong
there. OMAP3530 and DM3730 have different code paths in this
function, so it's not very surprising that only OMAP3530 is
broken.
Yes, I know that OMAP3530 has a very old and buggy Cortex-A8 core.
But I tried to apply all the Thumb2 related errata workarounds early
in 'arch/arm/cpu/armv7/start.S'. And also enforced single-issue
execution (bit 10 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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 05/11] tools: mksunxiboot: allow larger SPL binaries
_out = open(argv[ac], O_WRONLY | O_CREAT, 0666);
> + if (fd_out < 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);
> memcpy(img.header.magic, BOOT0_MAGIC, 8); /* no '0' termination */
> img.header.length =
> - ALIGN(file_size + sizeof(struct boot_file_head), BLOCK_SIZE);
> + ALIGN(file_size + sizeof(struct boot_file_head), block_size);
> img.header.b_instruction = cpu_to_le32(img.header.b_instruction);
> img.header.length = cpu_to_le32(img.header.length);
>
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 08/11] sunxi: SPL: add FIT config selector for Pine64 boards
On Fri, 20 Jan 2017 21:55:53 +
André Przywara wrote:
> On 20/01/17 21:35, Maxime Ripard wrote:
>
> Hi Maxime,
>
> thanks for having a look!
>
> > On Fri, Jan 20, 2017 at 01:53:28AM +, Andre Przywara wrote:
> >> For a board or platform to support FIT loading in the SPL, it has to
> >> provide a board_fit_config_name_match() routine, which helps to select
> >> one of possibly multiple DTBs contained in a FIT image.
> >> Provide a simple function to cover the two different Pine64 models,
> >> which can be easily told apart by looking at the amount of installed
> >> RAM.
> >>
> >> Signed-off-by: Andre Przywara
> >> ---
> >> board/sunxi/board.c | 13 +
> >> 1 file changed, 13 insertions(+)
> >>
> >> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> >> index 5365638..826 100644
> >> --- a/board/sunxi/board.c
> >> +++ b/board/sunxi/board.c
> >> @@ -726,3 +726,16 @@ int ft_board_setup(void *blob, bd_t *bd)
> >> #endif
> >>return 0;
> >> }
> >> +
> >> +#ifdef CONFIG_SPL_LOAD_FIT
> >> +int board_fit_config_name_match(const char *name)
> >> +{
> >> +#ifdef CONFIG_MACH_SUN50I
> >> + if ((gd->ram_size > 512 * 1024 * 1024))
> >> + return !strcmp(name, "sun50i-a64-pine64-plus");
> >> + else
> >> + return !strcmp(name, "sun50i-a64-pine64");
> >> +#endif
> >> + return -1;
> >> +}
> >
> > That looks fishy. It means that any A64 board with CONFIG_SPL_LOAD_FIT
> > enabled will be considered a pine64 board?
>
> Yes, at least for now, because that's the only A64 board we officially
> support so far.
> And yes again, it is fishy. It is more a demo or a placeholder for now,
> because you _need_ an implementation of board_fit_config_name_match()
> once you enable CONFIG_SPL_LOAD_FIT.
>
> One solution would be to have only one DTB supported per build, so
> board_fit_config_name_match() always returns 0.
>
> Another (better) solution would be to store the board name in the SPL
> header, which could be done later when flashing the image. Then this
> function would just return strcmp(name, spl_header_name) or 0 if no name
> is found for whatever reason.
Yes, this is a good solution in the case if we have some non-removable
storage on the board (SPI NOR flash, NAND, EEPROM or something else).
We can discuss it separately.
But the current generation of Pine64 boards don't have any
non-removable storage yet. My understanding is that you tried to
provide the DTB selection, which is based on circumstantial evidences,
such as the RAM size. IMHO this is also a valid selection method,
because it can reduce the number of required OS image variants.
Yes, this is not urgent and we can indeed temporarily use separate
defconfigs for different Pine64 board variants.
> Ideas welcome. To be honest, this .dtb selection is nice, but I am not
> married to it. It usefulness maybe limited at the moment.
The board specific information is normally stored either in the
defconfig file or in the device tree, rather than gets hardcoded in
the sources. We can probably add some extra constraints information
to the device tree. And these extra constraints 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 actual RAM size is wrong.
This approach is similar to what I used in
https://github.com/ssvb/sunxi-bootsetup/releases/tag/20141215-sunxi-bootsetup-prototype
http://lists.denx.de/pipermail/u-boot/2015-January/202306.html
The sunxi-bootsetup stub used the SoC type id and RAM size to filter
the list of potentially matching boards. It worked very nicely in
practice.
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH] sunxi: fix SID read on H3
On Tue, 20 Dec 2016 02:03:36 +0800
Icenowy Zheng wrote:
> H3 SID controller has some bug, which makes the initial SID value at
> SUNXI_SID_BASE wrong when boot.
>
> Change the SID retrieve code to call the SID Controller directly on H3,
> which can get the correct value, and also fix the SID value at
> SUNXI_SID_BASE, so that it can be used by further operations.
>
> Signed-off-by: Icenowy Zheng
> ---
> arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 1 +
> arch/arm/mach-sunxi/cpu_info.c | 44
> +
> 2 files changed, 45 insertions(+)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
> b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
> index 7232f6d927..3c852224e6 100644
> --- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
> +++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
> @@ -97,6 +97,7 @@
> #if defined(CONFIG_MACH_SUN8I_A83T) || defined(CONFIG_MACH_SUN8I_H3) || \
> defined(CONFIG_MACH_SUN50I)
> /* SID address space starts at 0x01c1400, but e-fuse is at offset 0x200 */
> +#define SUNXI_SIDC_BASE 0x01c14000
> #define SUNXI_SID_BASE 0x01c14200
> #else
> #define SUNXI_SID_BASE 0x01c23800
> diff --git a/arch/arm/mach-sunxi/cpu_info.c b/arch/arm/mach-sunxi/cpu_info.c
> index 76b6719d99..f1f6fd5ba4 100644
> --- a/arch/arm/mach-sunxi/cpu_info.c
> +++ b/arch/arm/mach-sunxi/cpu_info.c
> @@ -99,10 +99,54 @@ int print_cpuinfo(void)
> }
> #endif
>
> +#ifdef CONFIG_MACH_SUN8I_H3
> +
> +#define SIDC_PRCTL 0x40
> +#define SIDC_RDKEY 0x60
> +
> +#define SIDC_OP_LOCK 0xAC
> +
> +uint32_t sun8i_efuse_read(uint32_t offset)
> +{
> + uint32_t reg_val;
> +
> + reg_val = readl(SUNXI_SIDC_BASE + SIDC_PRCTL);
> + reg_val &= ~(((0x1ff) << 16) | 0x3);
> + reg_val |= (offset << 16);
> + writel(reg_val, SUNXI_SIDC_BASE + SIDC_PRCTL);
Normally clrsetbits_le32() is used for this kind of code in U-Boot.
> +
> + reg_val &= ~(((0xff) << 8) | 0x3);
> + reg_val |= (SIDC_OP_LOCK << 8) | 0x2;
> + writel(reg_val, SUNXI_SIDC_BASE + SIDC_PRCTL);
> +
> + while (readl(SUNXI_SIDC_BASE + SIDC_PRCTL) & 0x2);
> +
> + reg_val &= ~(((0x1ff) << 16) | ((0xff) << 8) | 0x3);
> + writel(reg_val, SUNXI_SIDC_BASE + SIDC_PRCTL);
Same here.
> +
> + reg_val = readl(SUNXI_SIDC_BASE + SIDC_RDKEY);
> + return reg_val;
> +}
> +#endif
> +
> int sunxi_get_sid(unsigned int *sid)
> {
> #ifdef CONFIG_AXP221_POWER
> return axp_get_sid(sid);
> +#elif defined CONFIG_MACH_SUN8I_H3
> + /*
> + * H3 SID controller has a bug, which makes the initial value of
> + * SUNXI_SID_BASE at boot 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 * 4);
> +
> + return 0;
> #elif defined SUNXI_SID_BASE
> int i;
>
Thanks for this workaround. This problem has buggered some people
since a while ago. It's good that you took time to investigate and
fix it.
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/23] SPL: tiny-printf: add "l" modifier
amp; (int)num < 0) {
> - num = -(int)num;
> - out(info, '-');
> + div = 10;
> + if (islong) {
> + num = va_arg(va, unsigned long);
> + if (sizeof(long) > 4)
> + div *= div * 10;
> + } else {
> + num = va_arg(va, unsigned int);
> + }
> +
> + if (ch == 'd') {
> + if (islong && (long)num < 0) {
> + num = -(long)num;
> + out(info, '-');
> + } else if (!islong && (int)num < 0) {
> + num = -(int)num;
> + out(info, '-');
> + }
> }
> if (!num) {
> out_dgt(info, 0);
> } else {
> - for (div = 10; div; div /= 10)
> + for (; div; div /= 10)
> div_out(info, &num, div);
> }
> break;
> case 'x':
> - num = va_arg(va, unsigned int);
> + if (islong) {
> + 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
Re: [U-Boot] [PATCH 05/24] SPL: tiny-printf: add "l" modifier
break;
> case 'x':
> - num = va_arg(va, unsigned int);
> + if (islong) {
> + 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
Re: [U-Boot] [PATCH 02/24] sun6i: Restrict some register initialization to Allwinner A31 SoC
On Sun, 20 Nov 2016 14:56:56 +
Andre Przywara wrote:
> These days many Allwinner SoCs use clock_sun6i.c, although out of them
> only the (original sun6i) A31 has a second MBUS clock register.
> Also setting up the PRCM PLL_CTLR1 register to provide the proper voltage
> seems to be an A31-only feature as well.
> So restrict the initialization to this SoC only to avoid writing bogus
> values to (undefined) registers in other chips.
>
> Signed-off-by: Andre Przywara
> Reviewed-by: Alexander Graf
> Reviewed-by: Chen-Yu Tsai
> ---
> arch/arm/mach-sunxi/clock_sun6i.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/mach-sunxi/clock_sun6i.c
> b/arch/arm/mach-sunxi/clock_sun6i.c
> index ed8cd9b..382fa94 100644
> --- a/arch/arm/mach-sunxi/clock_sun6i.c
> +++ b/arch/arm/mach-sunxi/clock_sun6i.c
> @@ -21,6 +21,8 @@ void clock_init_safe(void)
> {
> struct sunxi_ccm_reg * const ccm =
> (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
> +
> +#ifdef CONFIG_MACH_SUN6I
> struct sunxi_prcm_reg * const prcm =
> (struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
>
> @@ -31,6 +33,7 @@ void clock_init_safe(void)
> PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN |
> PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140));
> clrbits_le32(&prcm->pll_ctrl1, PRCM_PLL_CTRL_LDO_KEY_MASK);
> +#endif
PRCM is generally poorly documented, with its description sometimes
entirely missing from the Allwinner manuals (while it exists in the
hardware). But many SoC variants are sharing the same features and need
the same code. I can confirm that this code chunk is needed on my A31s
tablet (otherwise the system does not boot), so it was not entirely
useless.
What about the other SoC variants? For example, I can see that the
A23 manual documents this register in a roughly the same way as A31
(the PLLVDD voltage settings, etc.). But I don't have any A23 hardware
to test. Basically, are we sure that we will not break A23 support
with this commit?
If I understand it correctly, you primarily wanted to disable this
code on A64. But disabling it everywhere other than A31 may be a
bit too broad.
>
> clock_set_pll1(40800);
>
> @@ -41,7 +44,9 @@ void clock_init_safe(void)
> writel(AHB1_ABP1_DIV_DEFAULT, &ccm->ahb1_apb1_div);
>
> writel(MBUS_CLK_DEFAULT, &ccm->mbus0_clk_cfg);
> +#ifdef CONFIG_MACH_SUN6I
> writel(MBUS_CLK_DEFAULT, &ccm->mbus1_clk_cfg);
> +#endif
We can change this to:
if (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
Re: [U-Boot] [PATCH 08/24] armv8: add simple sdelay implementation
On Mon, 21 Nov 2016 16:52:47 +0100
Alexander Graf wrote:
> On 20/11/2016 15:57, Andre Przywara wrote:
> > The sunxi DRAM setup code needs an sdelay() implementation, which
> > wasn't defined for armv8 so far.
> > Shamelessly copy the armv7 version and adjust it to work in AArch64.
> >
> > Signed-off-by: Andre Przywara
>
> I don't think it hurts to write this in C - and I also doubt that
> inlining has any negative effect.
>
> Something along the lines of
>
> static inline void sdelay(...) {
>for (; loops; loops--)
> asm volatile("");
> }
>
> inside a header should do the trick as well and is much more readable.
Unfortunately the performance of the generated C code is very
unpredictable. Depending on the optimization settings, it may
place the counter variable in a register, or keep it on stack.
It would be much nicer to have more predictable timings for
these delays. So I like the assembly version a lot better.
Naturally, when it is implemented correctly.
>
>
> Alex
>
> > ---
> > arch/arm/cpu/armv8/cpu.c | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/arch/arm/cpu/armv8/cpu.c b/arch/arm/cpu/armv8/cpu.c
> > index e06c3cc..e82e9cf 100644
> > --- a/arch/arm/cpu/armv8/cpu.c
> > +++ b/arch/arm/cpu/armv8/cpu.c
> > @@ -16,6 +16,19 @@
> > #include
> > #include
> >
> > +/
> > + * sdelay() - simple spin loop. Will be constant time as
> > + * its generally used in bypass conditions only. This
> > + * is necessary until timers are accessible.
> > + *
> > + * not inline to increase chances its in cache when called
> > + */
> > +void sdelay(unsigned long loops)
> > +{
> > + __asm__ volatile ("1:\n" "subs %0, %1, #1\n"
> > + "b.ne 1b":"=r" (loops):"0"(loops));
> > +}
> > +
> > 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
Re: [U-Boot] [PATCH 08/24] armv8: add simple sdelay implementation
On Sun, 20 Nov 2016 14:57:02 +
Andre Przywara wrote:
> The sunxi DRAM setup code needs an sdelay() implementation, which
> wasn't defined for armv8 so far.
> Shamelessly copy the armv7 version and adjust it to work in AArch64.
>
> Signed-off-by: Andre Przywara
> ---
> arch/arm/cpu/armv8/cpu.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm/cpu/armv8/cpu.c b/arch/arm/cpu/armv8/cpu.c
> index e06c3cc..e82e9cf 100644
> --- a/arch/arm/cpu/armv8/cpu.c
> +++ b/arch/arm/cpu/armv8/cpu.c
> @@ -16,6 +16,19 @@
> #include
> #include
>
> +/
> + * sdelay() - simple spin loop. Will be constant time as
> + * its generally used in bypass conditions only. This
> + * is necessary until timers are accessible.
> + *
> + * not inline to increase chances its in cache when called
> + */
> +void sdelay(unsigned long loops)
> +{
> + __asm__ volatile ("1:\n" "subs %0, %1, #1\n"
> + "b.ne 1b":"=r" (loops):"0"(loops));
This inline assembly needs "cc" in the clobber list. Also don't we
want to just use a single register for the counter ("subs %0, %0, #1")
rather than trying to construct 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
Re: [U-Boot] [PATCH] drivers: SPI: sunxi SPL: fix warning
On Thu, 3 Nov 2016 00:58:12 +
Andre Przywara wrote:
> Somehow an int returning function without a return statement sneaked
> in. Fix it.
>
> Signed-off-by: Andre Przywara
> ---
> drivers/mtd/spi/sunxi_spi_spl.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi/sunxi_spi_spl.c b/drivers/mtd/spi/sunxi_spi_spl.c
> index 67c7edd..7502314 100644
> --- a/drivers/mtd/spi/sunxi_spi_spl.c
> +++ b/drivers/mtd/spi/sunxi_spi_spl.c
> @@ -158,9 +158,10 @@ static void spi0_disable_clock(void)
>(1 << AHB_RESET_SPI0_SHIFT));
> }
>
> -static int spi0_init(void)
> +static void spi0_init(void)
> {
> unsigned int pin_function = SUNXI_GPC_SPI0;
> +
> if (IS_ENABLED(CONFIG_MACH_SUN50I))
> pin_function = SUN50I_GPC_SPI0;
>
Thanks for spotting and fixing this compilation warning.
This was a last minute change. Originally there was also a check for
the pins state and the function returned an error code in the case if
the pins are already configured for NAND. But I removed this code
before sending the patch.
The idea is that probing the SPI flash may be useful in the future even
if booting from some other media. We may store some board-specific
configuration in the on-board SPI flash (for example, the DRAM and
CPU speed grade information). But this 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
Re: [U-Boot] [PATCH] drivers: SPI: sunxi SPL: fix warning
On Mon, 14 Nov 2016 11:56:50 -0500
Tom Rini wrote:
> On Mon, Nov 14, 2016 at 04:47:26PM +, Andre Przywara wrote:
> > Hi,
> >
> > On 14/11/16 16:30, Jagan Teki wrote:
> > > On Thu, Nov 3, 2016 at 6:28 AM, Andre Przywara
> > > wrote:
> > >> Somehow an int returning function without a return statement sneaked
> > >> in. Fix it.
> > >>
> > >> Signed-off-by: Andre Przywara
> > >> ---
> > >> drivers/mtd/spi/sunxi_spi_spl.c | 3 ++-
> > >> 1 file changed, 2 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/drivers/mtd/spi/sunxi_spi_spl.c
> > >> b/drivers/mtd/spi/sunxi_spi_spl.c
> > >> index 67c7edd..7502314 100644
> > >> --- a/drivers/mtd/spi/sunxi_spi_spl.c
> > >> +++ b/drivers/mtd/spi/sunxi_spi_spl.c
> > >> @@ -158,9 +158,10 @@ static void spi0_disable_clock(void)
> > >> (1 << AHB_RESET_SPI0_SHIFT));
> > >> }
> > >>
> > >> -static int spi0_init(void)
> > >> +static void spi0_init(void)
> > >> {
> > >> unsigned int pin_function = SUNXI_GPC_SPI0;
> > >> +
> > >
> > > Space not needed or unrelated, please remove this.
> >
> > This is Linux coding style, which U-Boot adheres to.
> > "WARNING: Missing a blank line after declarations"
> >
> > I thought I should fix this since this is was in the context of this
> > very simple patch and it improves readability.
> > 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-Support-booting-from-SPI-flash.patch
total: 0 errors, 0 warnings, 0 checks, 361 lines checked
NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX
MULTISTATEMENT_MACRO_USE_DO_WHILE NETWORKING_BLOCK_COMMENT_STYLE
PREFER_ETHER_ADDR_COPY USLEEP_RANGE
0001-sunxi-Support-booting-from-SPI-flash.patch has no obvious style problems
and is ready for submission.
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] image: Protect against overflow in unknown_msg()
On Thu, 27 Oct 2016 18:38:40 -0600 Simon Glass wrote: > Coverity complains that this can overflow. If we later increase the size > of one of the strings in the table, it could happen. > > Adjust the code to protect against this. > > Signed-off-by: Simon Glass > Reported-by: Coverity (CID: 150964) > --- > > Changes in v2: > - Drop unwanted #include > > common/image.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/common/image.c b/common/image.c > index 0e86c13..4255267 100644 > --- a/common/image.c > +++ b/common/image.c > @@ -590,7 +590,7 @@ static const char *unknown_msg(enum ih_category category) > static char msg[30]; > > strcpy(msg, "Unknown "); > - strcat(msg, table_info[category].desc); > + strncat(msg, table_info[category].desc, sizeof(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 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
Re: [U-Boot] [PATCH v3 03/29] Convert CONSOLE_PRE_CONSOLE_BUFFER options to Kconfig
; unsigned long board_type; > #endif > unsigned long have_console; /* serial_init() was called */ > -#ifdef CONFIG_PRE_CONSOLE_BUFFER > +#if CONFIG_IS_ENABLED(PRE_CONSOLE_BUFFER) > unsigned long precon_buf_idx; /* Pre-Console buffer index */ > #endif > unsigned long env_addr; /* Address of Environment struct */ > diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h > index d261fb3..c604ce2 100644 > --- a/include/configs/sunxi-common.h > +++ b/include/configs/sunxi-common.h > @@ -69,7 +69,6 @@ > #define CONFIG_SYS_SDRAM_BASE0x2000 > #define CONFIG_SYS_LOAD_ADDR 0x2200 /* default load address */ > #define CONFIG_SYS_TEXT_BASE 0x2a00 > -#define CONFIG_PRE_CON_BUF_ADDR 0x2f00 > /* Note SPL_STACK_R_ADDR is set through Kconfig, we include it here > * since it needs to fit in with the other values. By also #defining it > * we get warnings if the Kconfig value mismatches. */ > @@ -80,7 +79,6 @@ > #define CONFIG_SYS_SDRAM_BASE0x4000 > #define CONFIG_SYS_LOAD_ADDR 0x4200 /* default load address */ > #define CONFIG_SYS_TEXT_BASE 0x4a00 > -#define CONFIG_PRE_CON_BUF_ADDR 0x4f00 > /* Note SPL_STACK_R_ADDR is set through Kconfig, we include it here > * since it needs to fit in with the other values. By also #defining it > * we get warnings if the Kconfig value mismatches. */ > @@ -373,10 +371,6 @@ extern int soft_i2c_gpio_scl; > #ifndef CONFIG_SPL_BUILD > #include > > -/* Enable pre-console buffer to get complete log on the VGA console */ > -#define CONFIG_PRE_CONSOLE_BUFFER > -#define CONFIG_PRE_CON_BUF_SZ4096 /* Aprox 2 80*25 screens */ > - > #ifdef CONFIG_ARM64 > /* > * Boards seem to come with at least 512MB of DRAM. > diff --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_CONSOLE_BUFFER > -#define CONFIG_PRE_CON_BUF_SZ4096 > -#define CONFIG_PRE_CON_BUF_ADDR 0x7C00 > - > /* *** Command definition *** */ > #define CONFIG_CMD_BMODE > > diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt > index 9e2f00d..7a69be5 100644 > --- a/scripts/config_whitelist.txt > +++ b/scripts/config_whitelist.txt > @@ -3728,9 +3728,6 @@ CONFIG_PQ_MDS_PIB > CONFIG_PQ_MDS_PIB_ATM > CONFIG_PRAM > CONFIG_PREBOOT > -CONFIG_PRE_CONSOLE_BUFFER > -CONFIG_PRE_CON_BUF_ADDR > -CONFIG_PRE_CON_BUF_SZ > CONFIG_PRIMEVIEW_V16C6448AC > CONFIG_PRINTK > CONFIG_PROC_FS -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Revert "sunxi: Move the SPL stack top to 0x1A000 on Allwinner A64/A80"
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 > >> set the AHB1 clock down to 100 MHz to cope with the flaky SRAM C access > >> from the CPU. > >> However booting with boot0 (and thus not using SPL at all) we still run > >> with a 200 MHz AHB1, so any access to SRAM C is prone to fail. > >> Since this commit does _not_ only affect the SPL code, but also the > >> U-Boot proper, we fail when booting with boot0. > > > > Yes, it unfortunately affected both the SPL and the U-Boot > > proper because currently both CONFIG_SPL_STACK and > > CONFIG_SYS_INIT_SP_ADDR defines affect the SPL stack > > location and in practice this only works in a predictable > > way if they are set to the same value. I have sent a patch > > to address this problem (but the fix may be unsafe for > > v2016.09 because many ARM platforms are affected): > > > > https://patchwork.ozlabs.org/patch/665608/ > > > > After this problem is resolved, the CONFIG_SYS_INIT_SP_ADDR > > define can be decoupled from CONFIG_SPL_STACK and configured to > > even use the DRAM instead of thrashing some part of the scarce > > SRAM space (which may be already occupied by the OpenRISC > > firmware and/or the ATF at the time when the U-Boot proper is > > starting). > > > >> As the introduction of tiny-printf reduced the size of the SPL, we > >> can afford to have the SPL stack in SRAM A1. > > > > We still need to check how much space is really available. The FIT > > support is rather heavyweight and we may want to enable some other > > features too. > > Yes, I had to learn this yesterday ;-) > So 64-bit SPL works for me now with Jens' DRAM support patches (yeah!), > but enabling FIT support makes mksunxiboot barf about the file being to > big. The actual SPL code is about 31K, so maybe I can talk mksunxiboot > into relaxing its alignment requirements a bit (from 8K down to 512) and > also increase the available SRAM size - it says 0x7600 for sun4i, is > this still true to newer SoCs/BROMs? We have this information in the linux-sunxi wiki since a long time ago (at least for the SoC variants that I have and could experiment with) and it is available here: https://linux-sunxi.org/BROM#U-Boot_SPL_limitations All the new SoCs have a 32K size limit for the SPL code, which can be loaded by the BROM. Older A10/A20 SoCs artificially limit it to 24K, probably trying to forcefully encourage the users to have 8K stack in the remaining part of the SRAM A1. On A64, we have 32K of SRAM A1. Then we have 108K of SRAM C, which is a continuation of SRAM A1 in the address space thus making it look like a nice single 140K chunk. Then we also have 64K of SRAM A2, which is supposed to be used by the OpenRISC core and is the only memory area, which has a reasonable performance when used by OpenRISC: https://linux-sunxi.org/AR100#Memory_Map The idea was to let the BROM load up to 32K of the SPL code to the SRAM A1 (like it normally does) and then have 8K of stack a bit higher in the address space in SRAM C. But it turned out that the SRAM C is a bit quirky and suffers from data corruption problems if we reclock AHB1 too early. Now there are two possible ways to move forward on A64: 1) Try to use SRAM C in such a way that it does not fail (and hope that no additional quirks get discovered later). 2) Move the initial SPL stack to SRAM A2. If we move everything to SRAM A2, then we will have to make sure that all the SRAM users (the FEL storage area, the SPL stack, the ATF and the yet to be implemented OpenRISC firmware) never clash with each other. About the 31K code size. This does not look good and is very close to the BROM limit (32K). Just using a different compiler may bring us into a trouble. Or some minor code tweaks and feature additions. > Trying this in the past (with libdram) and compiling for (32-bit) Thumb2 > worked, but I need to check what the actual size with Jens' patches are > these days for Thumb2. We have already discussed this off-list a long time ago. I know that both you and Alexander Graf are generally in favour of compiling the SPL as 64-bit code. I think that this is the usual case of utility versus fashion. Everyone wants to plug every hole with 64-bit ARM code right now just because it is new and innovative. But this fad will fade away in a few years. Now just imagine an alternative reality, where ARM64 is an old and boring thing, while Thumb2 is a recent invention to improve code density in microcontrollers and other code sp
Re: [U-Boot] [PATCH 4/4] sunxi: fix 64-bit compiler warning for SPL header parsing
On Mon, 5 Sep 2016 01:32:41 +0100 Andre Przywara wrote: > Casting "int"s to pointers is only valid for 32-bit systems. > Add the appropriate pointer type cast to avoid a compiler warning > when compiling for AArch64. > > Signed-off-by: Andre Przywara > --- > board/sunxi/board.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/board/sunxi/board.c b/board/sunxi/board.c > index 209fb1c..6281c9d 100644 > --- a/board/sunxi/board.c > +++ b/board/sunxi/board.c > @@ -602,7 +602,7 @@ static void parse_spl_header(const uint32_t spl_addr) >* data is expected in uEnv.txt compatible format, so "env >* import -t" the string(s) at fel_script_address right away. >*/ > - himport_r(&env_htab, (char *)spl->fel_script_address, > + 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] Revert "sunxi: Downclock AHB1 to 100MHz on Allwinner A64"
On Mon, 5 Sep 2016 01:32:39 +0100
Andre Przywara wrote:
> Now that we don't use SRAM C for the SPL stack anymore, there is no
> need to clock down AHB1 to 100 MHz.
It's just another way to say it, but we are not clocking the AHB1
down, but rather keeping it at a failsafe default. If I understand it
correctly, reclocking the AHB1 to 200 MHz early in the SPL code is
not really necessary for the v2016.09 release and does not fix anything.
Moreover this revert affects USB FEL boot, which currently uses 8K
of SRAM C as a backup storage. Yes, we can also move the FEL backup
storage to SRAM A2, but the real question is whether we really want
to have it this way in the long run.
Is it really needed to reclock AHB1 early in the SPL? Can't ATF or
U-Boot proper do this a bit later? Also it's best to unmap the SRAM C
from the CPU address space at the same time as the AHB1 is reclocked
to 200 MHz. So that nobody can accidentally access it. There is a
special "bootmode" bit, which configures the SRAM C mapping:
https://irclog.whitequark.org/linux-sunxi/2016-06-29#16863309;
Writing 0x to 0x01c4 hides the SRAM C from the CPU. And
writing 0x0100 there enables it again. Some SRAM C experiments
can be done with the sunxi-fel tool:
$ sunxi-fel hex 0x18000 64
00018000: 32 a6 21 9a da f7 16 d7 7c 59 e9 b3 db a2 5f 9e 2.!.|Y_.
00018010: d2 0c 54 b8 79 7e 7a ff 7f 0d b5 e7 96 27 34 c8 ..T.y~z..'4.
00018020: c7 d1 66 f8 4b dc a6 cb d5 ba e3 ce 26 18 49 c4 ..f.K...&.I.
00018030: 4f f6 3f a9 56 f7 92 d4 50 b6 7f e6 73 e8 e5 69 O.?.V...P...s..i
$ sunxi-fel fill 0x18000 64 0xCC && sunxi-fel hex 0x18000 64
00018000: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
00018010: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
00018020: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
00018030: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
$ sunxi-fel writel 0x01c4 0x && sunxi-fel hex 0x18000 64
00018000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00018010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00018020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00018030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
$ sunxi-fel writel 0x01c4 0x0100 && sunxi-fel hex 0x18000 64
00018000: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
00018010: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
00018020: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
00018030: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
The commands above first show the uninitialized garbage in the SRAM C,
then initialize it to 0xCC, then disable the SRAM C access from the
CPU (it is then read as all zeros), then enable it back (it is read
as 0xCC again).
> Keeping it at the recommended 200 MHz allows faster peripherals.
I usually prefer to see some performance numbers in such commit
messages ;) Not that I doubt that something becomes faster, but it
is always interesting to know how big is the real practical effect.
> This reverts commit 5bc88cc2be3a962005b6e5768e06ca8f6ffcb88d.
>
> Signed-off-by: Andre Przywara
We are not fixing any bugs with this revert. Or do we?
> ---
> arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> index be9fcfd..f7e93b0 100644
> --- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> +++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> @@ -230,12 +230,7 @@ struct sunxi_ccm_reg {
> #define CCM_PLL5_TUN_INIT_FREQ(x)(((x) & 0x7f) << 16)
> #define CCM_PLL5_TUN_INIT_FREQ_MASK CCM_PLL5_TUN_INIT_FREQ(0x7f)
>
> -#if defined(CONFIG_MACH_SUN50I)
> -/* AHB1=100MHz failsafe setup from the FEL mode, usable with PMIC defaults */
> -#define AHB1_ABP1_DIV_DEFAULT0x3190 /*
> 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
Re: [U-Boot] [PATCH 1/4] Revert "sunxi: Move the SPL stack top to 0x1A000 on Allwinner A64/A80"
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 > set the AHB1 clock down to 100 MHz to cope with the flaky SRAM C access > from the CPU. > However booting with boot0 (and thus not using SPL at all) we still run > with a 200 MHz AHB1, so any access to SRAM C is prone to fail. > Since this commit does _not_ only affect the SPL code, but also the > U-Boot proper, we fail when booting with boot0. Yes, it unfortunately affected both the SPL and the U-Boot proper because currently both CONFIG_SPL_STACK and CONFIG_SYS_INIT_SP_ADDR defines affect the SPL stack location and in practice this only works in a predictable way if they are set to the same value. I have sent a patch to address this problem (but the fix may be unsafe for v2016.09 because many ARM platforms are affected): https://patchwork.ozlabs.org/patch/665608/ After this problem is resolved, the CONFIG_SYS_INIT_SP_ADDR define can be decoupled from CONFIG_SPL_STACK and configured to even use the DRAM instead of thrashing some part of the scarce SRAM space (which may be already occupied by the OpenRISC firmware and/or the ATF at the time when the U-Boot proper is starting). > As the introduction of tiny-printf reduced the size of the SPL, we > can afford to have the SPL stack in SRAM A1. We still need to check how much space is really available. The FIT support is rather heavyweight and we may want to 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-by: Siarhei Siamashka > --- > include/configs/sunxi-common.h | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h > index f64edd4..708ab17 100644 > --- a/include/configs/sunxi-common.h > +++ b/include/configs/sunxi-common.h > @@ -99,7 +99,7 @@ > * the 1 actually activates the mapping of the first 32 KiB to 0x. > */ > #define CONFIG_SYS_INIT_RAM_ADDR 0x1 > -#define CONFIG_SYS_INIT_RAM_SIZE 0xA000 /* 40 KiB */ > +#define CONFIG_SYS_INIT_RAM_SIZE 0x08000 /* FIXME: 40 KiB ? */ > #else > #define CONFIG_SYS_INIT_RAM_ADDR 0x0 > #define CONFIG_SYS_INIT_RAM_SIZE 0x8000 /* 32 KiB */ > @@ -220,7 +220,8 @@ > #define CONFIG_SPL_PAD_TO32768 /* decimal for 'dd' */ > > #if defined(CONFIG_MACH_SUN9I) || defined(CONFIG_MACH_SUN50I) > -#define LOW_LEVEL_SRAM_STACK 0x0001A000 > +/* FIXME: 40 KiB instead of 32 KiB ? */ > +#define LOW_LEVEL_SRAM_STACK 0x00018000 > #define CONFIG_SPL_STACK LOW_LEVEL_SRAM_STACK > #else > /* end of 32 KiB in sram */ -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: Respect CONFIG_SPL_STACK define in lowlevel_init.S
The SPL and U-Boot proper may use different initial stack locations, which are configured via CONFIG_SPL_STACK and CONFIG_SYS_INIT_SP_ADDR defines. The lowlevel_init.S code needs to handle this in the same way as crt0.S Without this fix, setting the U-Boot stack location to some place, which is 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 1872c57..658934d 100644 --- a/arch/arm/cpu/armv7/lowlevel_init.S +++ b/arch/arm/cpu/armv7/lowlevel_init.S @@ -19,7 +19,11 @@ ENTRY(lowlevel_init) /* * Setup a temporary stack. Global data is not available yet. */ +#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK) + ldr sp, =CONFIG_SPL_STACK +#else ldr sp, =CONFIG_SYS_INIT_SP_ADDR +#endif bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ #ifdef CONFIG_SPL_DM mov r9, #0 -- 2.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pine64 and "sunxi: Move the SPL stack top to 0x1A000 on Allwinner A64/A80"
On Thu, 4 Aug 2016 11:40:25 -0400 Tom Rini wrote: > On Thu, Aug 04, 2016 at 11:36:01AM -0400, Tom Rini wrote: > > On Thu, Aug 04, 2016 at 04:14:21PM +0100, Andre Przywara wrote: > > > Hi, > > > > > > On 04/08/16 16:01, Tom Rini wrote: > > > > Hey guys, > > > > > > > > I just started trying out my Pine64 1GB and mainline U-Boot and I've > > > > found that: > > > > commit 1a83fb4a17d959d7b037999ab7ed7e62429abe34 > > > > Author: Siarhei Siamashka > > > > Date: Tue May 31 01:48:06 2016 +0300 > > > > > > > > sunxi: Move the SPL stack top to 0x1A000 on Allwinner A64/A80 > > > > > > > > is breaking boot for me. boot0 seems to run fine and then the last bit > > > > of output that I get is: > > > > boot0: start load other image > > > > boot0: Loading BL3-1 > > > > Loading file 0 at address 0x4000,size 0x0200 success > > > > boot0: Loading scp > > > > Loading file 2 at address 0x0004,size 0xc200 success > > > > set arisc reset to de-assert state > > > > Ready to disable icache. > > > > Jump to secend Boot. > > > > NOTICE: BL3-1: Running in SRAM A2 (@0x44000) > > > > NOTICE: Configuring SPC Controller > > > > NOTICE: BL3-1: v1.0(debug):d697594 > > > > NOTICE: BL3-1: Built : 09:15:57, Aug 4 2016 > > > > NOTICE: Configuring AXP PMIC > > > > NOTICE: PMIC: already configured for RSB > > > > NOTICE: PMIC: setup successful > > > > INFO:BL3-1: Initializing runtime services > > > > INFO:BL3-1: Preparing for EL3 exit to normal world > > > > INFO:BL3-1: Next image address: 0x4a00, SPSR: 0x3c9 > > > > > > > > I'm using d697594 from > > > > https://github.com/apritzel/arm-trusted-firmware.git for ATF and > > > > boot0.img from the 20160701 Debian "longsleep" image. Any ideas? > > > > > > Yes, we were experiencing similar issues, basically it's stuck in > > > start.S, as far as I could quickly check. > > > Siarhei and I were doubtful that this commit (which we eyed at before) > > > could be the culprit, as it _should_ affect only SPL code, which we > > > don't use atm. Well, it does affect the main U-Boot binary too, as we checked some days ago on IRC. I was about to send some patches to address this issue. > > It's not touching SPL code tho. You're changing CONFIG_SYS_INIT_SP_ADDR > > which is the start of _main in arch/arm/lib/crt0_64.S > > > > Or to be extra clear: > @@ -100,7 +100,7 @@ > * the 1 actually activates the mapping of the first 32 KiB to 0x. > */ > #define CONFIG_SYS_INIT_RAM_ADDR 0x1 > -#define CONFIG_SYS_INIT_RAM_SIZE 0x08000 /* FIXME: 40 KiB ? */ > +#define CONFIG_SYS_INIT_RAM_SIZE 0xA000 /* 40 KiB */ > #else > #define CONFIG_SYS_INIT_RAM_ADDR 0x0 > #define CONFIG_SYS_INIT_RAM_SIZE 0x8000 /* 32 KiB */ > > is changing CONFIG_SYS_INIT_SP_ADDR which is in U-Boot proper. To > change the SPL stack pointer you use CONFIG_SPL_STACK which is what the > second hunk tweaks. Yes, except that apparently there is a bug in "arch/arm/cpu/armv7/lowlevel_init.S" and it also uses CONFIG_SYS_INIT_SP_ADDR for the SPL. It is safe to revert this patch right now and come up with a better fix later. The patch only tries to ensure the availability of more space for the SPL, because the SPL code size was bigger than 24K on Pine64 before switching to tiny printf. The root cause of all these troubles is that on Allwinner A64 the SRAM C is apparently temporarily leased from the Cedar VE accelerator during the boot time. This was a relatively recent discovery: http://irclog.whitequark.org/linux-sunxi/2016-06-29#16862925; And an ugly part of it is that accessing SRAM C directly by the CPU is unreliable if AHB1 is clocked at 200MHz (default when running the Allwinner's Linux kernel). But the SRAM C works fine with AHB1 clocked at 100MHz (which is, for example the default clock speed in the FEL mode). So after AHB1 is reclocked (by boot0), nobody can safely access SRAM C anymore. -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] sun8i: On H3 Use words 1-3 instead of just word 3 from the SID
On Fri, 29 Jul 2016 11:49:45 +0200
Hans de Goede wrote:
> It seems that bytes 13-14 of the SID / bytes 1-2 from word 3 of the SID
> are always 0 on H3 making it a poor candidate to use as source for the
> serialnr / mac-address, and the other non constant words (1 and 2) also
> have quite a few bits which are the same for some boards,
>
> This commits switches to using words 1 - 3 ex-or-ed together to get a
> more unique value for the mac-address / serialnr.
>
> Cc: Chen-Yu Tsai
> Cc: Corentin LABBE
> Cc: Amit Singh Tomar
> Signed-off-by: Hans de Goede
> ---
> Changes in v2:
> -ex-or all 3 words together instead of picking a different word
> ---
> board/sunxi/board.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index ef3fe26..e0734fb 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -623,6 +623,21 @@ static void setup_environment(const void *fdt)
>
> ret = sunxi_get_sid(sid);
> if (ret == 0 && sid[0] != 0 && sid[3] != 0) {
> +#ifdef CONFIG_MACH_SUN8I_H3
> + /*
> + * The single words 1 - 3 of the SID have quite a few bits
> + * which are the same on many models on the H3, so we ex-or
> + * them together to get a bit more unique value.
> + *
> + * Note we only do this on the H3 as we cannot change the
> + * algorithm on other SoCs since those have been using
> + * fixed mac-addresses based on only using word 3 for a
> + * a long time and changing a fixed mac-address with an
> + * u-boot update is not good.
> + */
> + 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 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
Re: [U-Boot] [PATCH 3/4] sun8i: On H3 Use word 1 instead of word 3 from the SID
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 2016 18:10:34 +0200
> >> Hans de Goede wrote:
> >>
> >>> It seems that bytes 13-14 of the SID / bytes 1-2 from word 3 of the SID
> >>> are always 0 on H3 making it a poor candidate to use as source for the
> >>> serialnr / mac-address, switch to word1 which seems to be more random.
> >>>
> >>> Cc: Chen-Yu Tsai
> >>> Cc: Corentin LABBE
> >>> Cc: Amit Singh Tomar
> >>> Signed-off-by: Hans de Goede
> >>> ---
> >>> board/sunxi/board.c | 23 ++-
> >>> 1 file changed, 14 insertions(+), 9 deletions(-)
> >>>
> >>> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> >>> index ef3fe26..bbe5340 100644
> >>> --- a/board/sunxi/board.c
> >>> +++ b/board/sunxi/board.c
> >>> @@ -620,12 +620,17 @@ static void setup_environment(const void *fdt)
> >>> uint8_t mac_addr[6];
> >>> char ethaddr[16];
> >>> int i, ret;
> >>> +#ifdef CONFIG_MACH_SUN8I_H3
> >>> + const int idx0 = 0, idx1 = 1;
> >>> +#else
> >>> + const int idx0 = 0, idx1 = 3;
> >>> +#endif
> >>>
> >>> ret = sunxi_get_sid(sid);
> >>> - if (ret == 0 && sid[0] != 0 && sid[3] != 0) {
> >>> + if (ret == 0 && sid[idx0] != 0 && sid[idx1] != 0) {
> >>> /* Ensure the NIC specific bytes of the mac are not all 0 */
> >>> - if ((sid[3] & 0xff) == 0)
> >>> - sid[3] |= 0x80;
> >>> + if ((sid[idx1] & 0xff) == 0)
> >>> + sid[idx1] |= 0x80;
> >>>
> >>> for (i = 0; i < 4; i++) {
> >>> sprintf(ethaddr, "ethernet%d", i);
> >>> @@ -642,18 +647,18 @@ static void setup_environment(const void *fdt)
> >>>
> >>> /* Non OUI / registered MAC address */
> >>> mac_addr[0] = (i << 4) | 0x02;
> >>> - mac_addr[1] = (sid[0] >> 0) & 0xff;
> >>> - mac_addr[2] = (sid[3] >> 24) & 0xff;
> >>> - mac_addr[3] = (sid[3] >> 16) & 0xff;
> >>> - mac_addr[4] = (sid[3] >> 8) & 0xff;
> >>> - mac_addr[5] = (sid[3] >> 0) & 0xff;
> >>> + mac_addr[1] = (sid[idx0] >> 0) & 0xff;
> >>> + mac_addr[2] = (sid[idx1] >> 24) & 0xff;
> >>> + mac_addr[3] = (sid[idx1] >> 16) & 0xff;
> >>> + mac_addr[4] = (sid[idx1] >> 8) & 0xff;
> >>> + mac_addr[5] = (sid[idx1] >> 0) & 0xff;
> >>>
> >>> eth_setenv_enetaddr(ethaddr, mac_addr);
> >>> }
> >>>
> >>> if (!getenv("serial#")) {
> >>> snprintf(serial_string, sizeof(serial_string),
> >>> - "%08x%08x", sid[0], sid[3]);
> >>> + "%08x%08x", sid[idx0], sid[idx1]);
> >>>
> >>> setenv("serial#", serial_string);
> >>> }
> >>
> >> Is it really a good idea trying to guess which parts of the SID are
> >> sufficiently unique, depending on the SoC generation?
>
> Probably not, but that is what we've been doing so far.
>
> >> We can calculate some kind of hash (CRC32? SHA256?) over the whole
> >> SID. This will ensure that all the SID bits are accounted for.
>
> That seems like a good idea.
>
> I'm thinking about doing the following (for H3 at least, and probably
> also for other new SoCs):
>
> sid[3] ^= sid[1] ^ sid[2];
This is not a very good idea. For example, if one of the words is a
encoding the batch number and another word is encoding the serial
number in a batch, then there will be MAC address collisions:
0x000 ^ 0x = 0x
Re: [U-Boot] [PATCH 3/4] sun8i: On H3 Use word 1 instead of word 3 from the SID
Hello Hans,
On Wed, 27 Jul 2016 18:10:34 +0200
Hans de Goede wrote:
> It seems that bytes 13-14 of the SID / bytes 1-2 from word 3 of the SID
> are always 0 on H3 making it a poor candidate to use as source for the
> serialnr / mac-address, switch to word1 which seems to be more random.
>
> Cc: Chen-Yu Tsai
> Cc: Corentin LABBE
> Cc: Amit Singh Tomar
> Signed-off-by: Hans de Goede
> ---
> board/sunxi/board.c | 23 ++-
> 1 file changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index ef3fe26..bbe5340 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -620,12 +620,17 @@ static void setup_environment(const void *fdt)
> uint8_t mac_addr[6];
> char ethaddr[16];
> int i, ret;
> +#ifdef CONFIG_MACH_SUN8I_H3
> + const int idx0 = 0, idx1 = 1;
> +#else
> + const int idx0 = 0, idx1 = 3;
> +#endif
>
> ret = sunxi_get_sid(sid);
> - if (ret == 0 && sid[0] != 0 && sid[3] != 0) {
> + if (ret == 0 && sid[idx0] != 0 && sid[idx1] != 0) {
> /* Ensure the NIC specific bytes of the mac are not all 0 */
> - if ((sid[3] & 0xff) == 0)
> - sid[3] |= 0x80;
> + if ((sid[idx1] & 0xff) == 0)
> + sid[idx1] |= 0x80;
>
> for (i = 0; i < 4; i++) {
> sprintf(ethaddr, "ethernet%d", i);
> @@ -642,18 +647,18 @@ static void setup_environment(const void *fdt)
>
> /* Non OUI / registered MAC address */
> mac_addr[0] = (i << 4) | 0x02;
> - mac_addr[1] = (sid[0] >> 0) & 0xff;
> - mac_addr[2] = (sid[3] >> 24) & 0xff;
> - mac_addr[3] = (sid[3] >> 16) & 0xff;
> - mac_addr[4] = (sid[3] >> 8) & 0xff;
> - mac_addr[5] = (sid[3] >> 0) & 0xff;
> + mac_addr[1] = (sid[idx0] >> 0) & 0xff;
> + mac_addr[2] = (sid[idx1] >> 24) & 0xff;
> + mac_addr[3] = (sid[idx1] >> 16) & 0xff;
> + mac_addr[4] = (sid[idx1] >> 8) & 0xff;
> + mac_addr[5] = (sid[idx1] >> 0) & 0xff;
>
> eth_setenv_enetaddr(ethaddr, mac_addr);
> }
>
> if (!getenv("serial#")) {
> snprintf(serial_string, sizeof(serial_string),
> - "%08x%08x", sid[0], sid[3]);
> + "%08x%08x", sid[idx0], sid[idx1]);
>
> setenv("serial#", serial_string);
> }
Is it really a good idea trying to guess which parts of the SID are
sufficiently unique, depending on 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
Re: [U-Boot] [PATCH v2] sunxi: Support booting from SPI flash
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, > >> > >> 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 SPI0 pins (port C) to make this work. More information is > >> > available at: > >> > > >> > https://linux-sunxi.org/Bootable_SPI_flash > >> > > >> > This patch adds the initial support for booting from SPI flash. > >> > The existing SPI frameworks are not used in order to reduce the > >> > SPL code size. Right now the SPL size grows by ~370 bytes when > >> > CONFIG_SPL_SPI_SUNXI option is enabled. > >> > > >> > While there are no popular Allwinner devices with SPI flash at > >> > the moment, testing can be done using a SPI flash module (it > >> > can be bought for ~2$ on ebay) and jumper wires with the boards, > >> > which expose relevant pins on the expansion header. The SPI flash > >> > chips themselves are very cheap (some prices are even listed as > >> > low as 4 cents) and should not cost much if somebody decides to > >> > design a development board with an SPI flash chip soldered on > >> > the PCB. > >> > > >> > Another nice feature of the SPI flash is that it can be safely > >> > accessed in a device-independent way (since we know that the > >> > boot ROM is already probing these pins during the boot time). > >> > And if, for example, Olimex boards opted to use SPI flash instead > >> > of EEPROM, then they would have been able to have U-Boot installed > >> > in the SPI flash now and boot the rest of the system from the SATA > >> > hard drive. Hopefully we may see new interesting Allwinner based > >> > development boards in the future, now that the software support > >> > for the SPI flash is in a better shape :-) > >> > > >> > Testing can be done by enabling the CONFIG_SPL_SPI_SUNXI option > >> > in a board defconfig, then building U-Boot and finally flashing > >> > the resulting u-boot-sunxi-with-spl.bin binary over USB OTG with > >> > a help of the sunxi-fel tool: > >> > > >> >sunxi-fel spiflash-write 0 u-boot-sunxi-with-spl.bin > >> > > >> > The device needs to be switched into FEL (USB recovery) mode first. > >> > The most suitable boards for testing are Orange Pi PC and Pine64. > >> > Because these boards are cheap, have no built-in NAND/eMMC and > >> > expose SPI0 pins on the Raspberry Pi compatible expansion header. > >> > The A13-OLinuXino-Micro board also can be used. > >> > > >> > Signed-off-by: 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 > >> > - Size reduction of the SPI transfer function > >> > - Add delay after each SPI transfer to ensure that the chip select > >> >deassert timing requirements (tSHSL) are always satisfied > >> > - More comments in the code > >> > > >> > > >> > arch/arm/include/asm/arch-sunxi/gpio.h | 3 + > >> > arch/arm/mach-sunxi/board.c| 5 + > >> > common/spl/spl.c | 4 +- > >> > drivers/mtd/spi/Kconfig| 12 ++ > >> > drivers/mtd/spi/Makefile | 1 + > >> > drivers/mtd/spi/sunxi_spi_spl.c| 283 > >> > + > >> > include/configs/sunxi-common.h | 5 + > >> > 7 files changed, 311 insertions(+), 2 deletions(-) > >> > create mode 100644 drivers/mtd/spi/sunxi_spi_spl.c > >> > >> Shouldn't this be a normal SPI driver? Then you could put this in > >> common/spl/spl_spi.c. > > > > This source file contains both a sunxi SPI controller support and a > > basic SPI flash
Re: [U-Boot] [PATCH v2] sunxi: Support booting from SPI flash
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 SPI0 pins (port C) to make this work. More information is > > available at: > > > > https://linux-sunxi.org/Bootable_SPI_flash > > > > This patch adds the initial support for booting from SPI flash. > > The existing SPI frameworks are not used in order to reduce the > > SPL code size. Right now the SPL size grows by ~370 bytes when > > CONFIG_SPL_SPI_SUNXI option is enabled. > > > > While there are no popular Allwinner devices with SPI flash at > > the moment, testing can be done using a SPI flash module (it > > can be bought for ~2$ on ebay) and jumper wires with the boards, > > which expose relevant pins on the expansion header. The SPI flash > > chips themselves are very cheap (some prices are even listed as > > low as 4 cents) and should not cost much if somebody decides to > > design a development board with an SPI flash chip soldered on > > the PCB. > > > > Another nice feature of the SPI flash is that it can be safely > > accessed in a device-independent way (since we know that the > > boot ROM is already probing these pins during the boot time). > > And if, for example, Olimex boards opted to use SPI flash instead > > of EEPROM, then they would have been able to have U-Boot installed > > in the SPI flash now and boot the rest of the system from the SATA > > hard drive. Hopefully we may see new interesting Allwinner based > > development boards in the future, now that the software support > > for the SPI flash is in a better shape :-) > > > > Testing can be done by enabling the CONFIG_SPL_SPI_SUNXI option > > in a board defconfig, then building U-Boot and finally flashing > > the resulting u-boot-sunxi-with-spl.bin binary over USB OTG with > > a help of the sunxi-fel tool: > > > >sunxi-fel spiflash-write 0 u-boot-sunxi-with-spl.bin > > > > The device needs to be switched into FEL (USB recovery) mode first. > > The most suitable boards for testing are Orange Pi PC and Pine64. > > Because these boards are cheap, have no built-in NAND/eMMC and > > expose SPI0 pins on the Raspberry Pi compatible expansion header. > > The A13-OLinuXino-Micro board also can be used. > > > > Signed-off-by: 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 > > - Size reduction of the SPI transfer function > > - Add delay after each SPI transfer to ensure that the chip select > >deassert timing requirements (tSHSL) are always satisfied > > - More comments in the code > > > > > > arch/arm/include/asm/arch-sunxi/gpio.h | 3 + > > arch/arm/mach-sunxi/board.c| 5 + > > common/spl/spl.c | 4 +- > > drivers/mtd/spi/Kconfig| 12 ++ > > drivers/mtd/spi/Makefile | 1 + > > drivers/mtd/spi/sunxi_spi_spl.c| 283 > > + > > include/configs/sunxi-common.h | 5 + > > 7 files changed, 311 insertions(+), 2 deletions(-) > > create mode 100644 drivers/mtd/spi/sunxi_spi_spl.c > > Shouldn't this be a normal SPI driver? Then you could put this in > common/spl/spl_spi.c. This source file contains both a sunxi SPI controller support and a basic SPI flash read functionality glued together for size reduction purposes. We are interested in implementing the "spl_spi_load_image()" function, because this is what gets called when handling the BOOT_DEVICE_SPI case. The "drivers/mtd/spi" directory contains the "spi_spl_load.c" file, which implements this particular function with the help of the generic SPI flash support code from "spi_flash.c" and the generic SPI bus support provided by the code from the "drivers/spi" directory. What I'm doing in this patch is an implementation of a size reduced sunxi-specific replacement for "spi_spl_load.c". But in U-Boot proper (where the code size is not a problem anymore) we will need a real sunxi SPI driver. -- Regards, Sierž ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] sunxi: Add the ability to recognize and auto-import uEnv-style data
Hi,
On Wed, 8 Jun 2016 22:13:50 +0200
Hans de Goede wrote:
> Hi,
>
> On 08-06-16 20:23, Bernhard Nortmann wrote:
> > The patch converts one of the "reserved" fields in the sunxi SPL
> > header to a fel_uEnv_length entry. When booting over USB ("FEL
> > mode"), this enables the sunxi-fel utility to pass the string
> > length of uEnv.txt compatible data; at the same time requesting
> > that this data be imported into the U-Boot environment.
> >
> > If parse_spl_header() in the sunxi board.c encounters a non-zero
> > value in this header field, it will therefore call himport_r() to
> > merge the string (lines) passed via FEL into the default settings.
> > Environment vars can be changed this way even before U-Boot will
> > attempt to autoboot - specifically, this also allows overriding
> > "bootcmd".
> >
> > With fel_script_addr set and a zero fel_uEnv_length, U-Boot is
> > safe to assume that data in .scr format (a mkimage-type script)
> > was passed at fel_script_addr, and will handle it using the
> > existing mechanism ("bootcmd_fel").
> >
> > 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 the subject line. It does not mention
FEL and may be a bit misleading.
Regarding the uEnv.txt support in general, I tried to grep U-Boot
sources and found that it's use is very much inconsistent on
different platforms. For example, there seems to be some sort
of leftover junk in sunxi-common.h:
http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/sunxi-common.h;h=b33cfb86f82e0831f5d19b1e473205f65efb5a96;hb=b104b3dc1dd90cdbf67ccf3c51b06e4f1592fe91#l481
Hardcoding the partition number and the file system type is hardly
something that the users may reasonably expect.
It also might be a good idea to do more or less uniform handling of
the uEnv.txt for both FEL boot and normal SD card boot. If Bernhard
wants to improve the uEnv.txt support in general, then could this
be possibly addressed later (not in this patch)?
Still the "doc/README.distro" mentions boot.scr but has no references
to uEnv.txt (which seems to imply that the uEnv.txt is a second class
citizen).
> >
> > ---
> > A corresponding proof-of-concept version of sunxi-fel is available
> > from my https://github.com/n1tehawk/sunxi-tools/tree/20160608_uEnv-magic
> > branch. I've picked up the suggestion to use a "#=uEnv" magic string
> > to request that a file be treated as uEnv.txt-style data.
> >
> > For example, use your text editor to save a my.env file with
> >
> > #=uEnv
> > myvar=world
> > bootcmd=echo "Hello $myvar."
> >
> > and then test it with
> > ./sunxi-fel uboot u-boot-sunxi-with-spl.bin write 0x4310 my.env
> >
> > You should see U-Boot's autoboot print the corresponding message
> > and drop you to the prompt, proving that you have successfully
> > overwritten the "bootcmd".
> >
> > Changes in v2:
> > - Patch renamed to something more suitable (was "sunxi: Add the
> > ability to pass (script) filesize in the SPL header")
> > - The data field is now named fel_uEnv_length, and comes with
> > a corresponding description in spl.h
> > - Instead of simply passing file size, fel_uEnv_length is now
> > associated with uEnv.txt format. The patch modifies U-Boot's
> > sunxi parse_spl_header() to auto-import such data.
> >
> > arch/arm/include/asm/arch-sunxi/spl.h | 9 -
> > board/sunxi/board.c | 30 ++
> > 2 files changed, 30 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/arch-sunxi/spl.h
> > b/arch/arm/include/asm/arch-sunxi/spl.h
> > index a0f33b0..a966a88 100644
> > --- a/arch/arm/include/asm/arch-sunxi/spl.h
> > +++ b/arch/arm/include/asm/arch-sunxi/spl.h
> > @@ -49,7 +49,14 @@ struct boot_file_head {
> > uint8_t spl_signature[4];
> > };
> > uint32_t fel_script_address;
> > - uint32_t reserved1[3];
> > + /*
> > +* If the fel_uEnv_length member below is set to a non-zero value,
> > +* it specifies the size (byte count) of data at fel_script_address.
> > +* At the same time this indicates that the data is in uEnv.txt
> > +* compatible format, ready to be imported via "env import -t".
> > +*/
> > + uint32_t fel_uEnv_length;
> > + uint32_t rese
Re: [U-Boot] [linux-sunxi] Re: [PATCH v2] sunxi: Support booting from SPI flash
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 used by the SPI flash chips. The SPI is just an underlying bus to send and receive data, but the higher level protocols are incompatible. > Why put sdcard in spi when i have an sdcard slot? :) > Just to solder it for bypass crappy sdcard socket pin contact You can still solder the SD card instead of plugging it into the SD card slot. In fact, that's how it is usually done with eMMC. And you can even buy some development boards with eMMC instead of experimenting with this stuff yourself. > then boot from usb. > microsd was cheap in 512mb size or less. The price difference between the Orange Pi PC and the Orange Pi PC Plus boards is not very big: http://www.aliexpress.com/store/product/Orange-Pi-PC-linux-and-android-mini-PC-Beyond-Raspberry-Pi-2/1553371_32448079125.html http://www.aliexpress.com/store/product/Orange-Pi-PC-Plus-ubuntu-linux-and-android-mini-PC-Beyond-Raspberry-Pi-2/1553371_32668618847.html For extra 4.45 EUR you get a 8GB eMMC and also some sort of WiFi. And the eMMC is also much faster than a regular SD card, so it's not a very bad deal. > Is there limitation in chip memory selection? Any SPI flash chip should be supported if it uses the right voltage (compatible with 3.3V) and supports the Read Data Bytes command (the opcode 0x03, followed by a 24-bit address). You can always check the datasheet. A suitable SPI flash chip, which seems to cost only 4 cents, is sold here: http://www.aliexpress.com/item/W25Q16BVSSIG-W25Q16BVSIG-2MB-SOP8/32660083443.html But I have no idea if this particular seller is trustworthy. One can still easily find similar chips for around 10 cents in other places. The SPI flash is cheaper than the eMMC if we look at the absolute price. But the price per megabyte is an entirely different story. For U-Boot you would need a 1 MiB (8 Mbit) chip, just check the size of the u-boot-sunxi-with-spl.bin file and ensure a bit of extra headroom. > Anyway thank for new support Thanks. -- Regards, Sierž ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: Add the ability to pass (script) filesize in the SPL header
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!
> >>
> >> [...]
> >>
> >> No, you're right and not missing anything. Setting ${filesize} alone
> >> doesn't achieve much, and would require further customization to do the
> >> actual import. Since this whole idea of having the script length didn't
> >> go down too well when I initially proposed it (back in September 2015),
> >> I stayed away from adding additional U-Boot modifications this time.
> > Maybe you can add the necessary changes to the U-Boot default
> > environment in the v2 patch? Either way, we are not going to
> > make any progress until it is feature complete and usable.
>
> Back in 2015 Hans expressed concerns about overcomplicating what is already
> an exotic use-case. That is why I wanted to keep v1 as simple and 'generic'
> as possible - working from the assumption that if a user is sufficiently
> advanced to get fel_script_length set, (s)he'd also be proficient enough to
> tailor U-Boot to make actual use of ${filesize} according to his/her needs.
>
> Changing the default environment to use the existing "import -t" command
> was just one example of what might be done - maybe there could be other
> future uses, which I currently haven't thought of. My basic goal was and is
> a way to pass a payload from sunxi-fel to U-Boot in a format-agnostic way.
> This requires a "length" / file size in addition to the memory address.
Out of curiosity, what kind of other payload are you trying to pass to
U-Boot?
> The discussion here seems to narrow down on "uEnv.txt style" usage now.
> That's okay for me - I can create a v2 which focuses on that, and fleshes
> out the needed details.
For the record, I'm personally not very much interested in uEnv.txt
support myself. I was just assuming that it was the purpose of your
patch. But now I'm a bit confused.
Again, I have no objections. But if people really want to have uEnv.txt
support (or something else), then it's better to say so instead of
beating around the bush :-)
> >> One approach would be to have a modified "bootcmd_fel" that either tests
> >> for a non-empty ${filesize}, or tries to import the script data as a
> >> fallback ("source ${fel_scriptaddr} || import -t <...>;"). Another way is
> >> to always assume "uEnv.txt style" whenever fel_script_length is set, and
> >> do a himport_r() of the script data right away (the programmatic equivalent
> >> of "import -t"). I'm doing this in an experimental branch of mine, as it
> >> allows overriding everything from the default environment - including the
> >> "bootcmd" itself.
> >>
> >> Of course, all of this also requires support from the sunxi-fel side
> >> of things (i.e. fel_script_length getting set in the first place). A
> >> quick-and-dirty solution I'm currently using is to assume a uEnv.txt
> >> script (and set fel_script_length) whenever sunxi-fel detects uploads of
> >> pure ASCII data.
> > The boot.scr file is nice because it has its own format and a magic
> > signature. The uEnv.txt is difficult to recognize automatically, but
> > maybe we can borrow the https://en.wikipedia.org/wiki/Shebang_%28Unix%29
> > approach used by scripting languages?
> >
> > I mean, we can require that the first line of uEnv.txt is a comment in a
> > special format. This can be described in the sunxi-tools documentation.
> > And also the sunxi-fel tool could print a warning if it detects upload
> > of pure ASCII data from a file with "uEnv" part in the name and ".txt"
> > as the extension.
>
> I dislike involving filename conventions here, and I'd also prefer not
> having to "tag" the uEnv-style files (which are basically =
> pairs) with a special marker.
Still that's not something that I invented myself. As I said, scripting
languages are using it quite successfully. For example, you can find
the line "#!/usr/bin/env python" in the beginning of many python
source files.
And uEnv.txt files could use something similar to make them easier to
detect. Maybe something like "#=uEnv" could be a reasonable choice?
As for the filename conventions, I only proposed this as an optional
hint for the user. As a way to help people to make the transition. If
such heuristics is correct and helpful even in 50% o
[U-Boot] [PATCH v2] sunxi: Support booting from SPI flash
Allwinner devices support SPI flash as one of the possible
bootable media type. The SPI flash chip needs to be connected
to SPI0 pins (port C) to make this work. More information is
available at:
https://linux-sunxi.org/Bootable_SPI_flash
This patch adds the initial support for booting from SPI flash.
The existing SPI frameworks are not used in order to reduce the
SPL code size. Right now the SPL size grows by ~370 bytes when
CONFIG_SPL_SPI_SUNXI option is enabled.
While there are no popular Allwinner devices with SPI flash at
the moment, testing can be done using a SPI flash module (it
can be bought for ~2$ on ebay) and jumper wires with the boards,
which expose relevant pins on the expansion header. The SPI flash
chips themselves are very cheap (some prices are even listed as
low as 4 cents) and should not cost much if somebody decides to
design a development board with an SPI flash chip soldered on
the PCB.
Another nice feature of the SPI flash is that it can be safely
accessed in a device-independent way (since we know that the
boot ROM is already probing these pins during the boot time).
And if, for example, Olimex boards opted to use SPI flash instead
of EEPROM, then they would have been able to have U-Boot installed
in the SPI flash now and boot the rest of the system from the SATA
hard drive. Hopefully we may see new interesting Allwinner based
development boards in the future, now that the software support
for the SPI flash is in a better shape :-)
Testing can be done by enabling the CONFIG_SPL_SPI_SUNXI option
in a board defconfig, then building U-Boot and finally flashing
the resulting u-boot-sunxi-with-spl.bin binary over USB OTG with
a help of the sunxi-fel tool:
sunxi-fel spiflash-write 0 u-boot-sunxi-with-spl.bin
The device needs to be switched into FEL (USB recovery) mode first.
The most suitable boards for testing are Orange Pi PC and Pine64.
Because these boards are cheap, have no built-in NAND/eMMC and
expose SPI0 pins on the Raspberry Pi compatible expansion header.
The A13-OLinuXino-Micro board also can be used.
Signed-off-by: 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
- Size reduction of the SPI transfer function
- Add delay after each SPI transfer to ensure that the chip select
deassert timing requirements (tSHSL) are always satisfied
- More comments in the code
arch/arm/include/asm/arch-sunxi/gpio.h | 3 +
arch/arm/mach-sunxi/board.c| 5 +
common/spl/spl.c | 4 +-
drivers/mtd/spi/Kconfig| 12 ++
drivers/mtd/spi/Makefile | 1 +
drivers/mtd/spi/sunxi_spi_spl.c| 283 +
include/configs/sunxi-common.h | 5 +
7 files changed, 311 insertions(+), 2 deletions(-)
create mode 100644 drivers/mtd/spi/sunxi_spi_spl.c
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index 1ace548..bff7d14 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -141,6 +141,7 @@ enum sunxi_gpio_number {
/* GPIO pin function config */
#define SUNXI_GPIO_INPUT 0
#define SUNXI_GPIO_OUTPUT 1
+#define SUNXI_GPIO_DISABLE 7
#define SUNXI_GPA_EMAC 2
#define SUN6I_GPA_GMAC 2
@@ -162,8 +163,10 @@ enum sunxi_gpio_number {
#define SUN50I_GPB_UART0 4
#define SUNXI_GPC_NAND 2
+#define SUNXI_GPC_SPI0 3
#define SUNXI_GPC_SDC2 3
#define SUN6I_GPC_SDC3 4
+#define SUN50I_GPC_SPI04
#define SUN8I_GPD_SDC1 3
#define SUNXI_GPD_LCD0 2
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index bd15b9b..025df4d 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -223,6 +223,11 @@ u32 spl_boot_device(void)
if (!is_boot0_magic(SPL_ADDR + 4)) /* eGON.BT0 */
return BOOT_DEVICE_BOARD;
+#ifdef CONFIG_SPL_SPI_SUNXI
+ if (readb(SPL_ADDR + 0x28) == SUNXI_BOOTED_FROM_SPI)
+ return BOOT_DEVICE_SPI;
+#endif
+
/* The BROM will try to boot from mmc0 first, so try that first. */
#ifdef CONFIG_MMC
mmc_initialize(gd->bd);
diff --git a/common/spl/spl.c b/common/spl/spl.c
index c8dfc14..d49ce2b 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -265,7 +265,7 @@ struct boot_device_name boot_name_table[] = {
#ifdef CONFIG_SPL_YMODEM_SUPPORT
{ BOOT_DEVICE_UART, "UART" },
#endif
-#ifdef CONFIG_SPL_SPI_SUPPORT
+#if defined(CONFIG_SPL_SPI_SUPPORT) || defined(CONFIG_SPL_SPI_FLASH_SUPPORT)
{ BOOT_DEVICE_SPI, "SPI" },
#endif
#ifdef CONFIG_SPL_ETH_SUPPORT
@@ -341,7 +341,7 @@ static int spl_load_image(u32 bo
Re: [U-Boot] [PATCH] sunxi: Add the ability to pass (script) filesize in the SPL header
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
> > cases? Could you provide a bit more detailed description?
> >
> > I mean, who is going to do "import -t ${fel_script_addr} ${filesize}"
> > invocation?
> >
> > This particular FEL feature in the SPL header is used to allow running
> > a boot script provided by the user (boot.scr). Without it, we only
> > have the default U-Boot environment. And the default U-Boot environment
> > does not have the "import -t ${fel_script_addr} ${filesize}" statement
> > yet. This looks a bit like a chicken/egg problem or am I missing
> > something?
>
> No, you're right and not missing anything. Setting ${filesize} alone
> doesn't achieve much, and would require further customization to do the
> actual import. Since this whole idea of having the script length didn't
> go down too well when I initially proposed it (back in September 2015),
> I stayed away from adding additional U-Boot modifications this time.
Maybe you can add the necessary changes to the U-Boot default
environment in the v2 patch? Either way, we are not going to
make any progress until it is feature complete and usable.
> One approach would be to have a modified "bootcmd_fel" that either tests
> for a non-empty ${filesize}, or tries to import the script data as a
> fallback ("source ${fel_scriptaddr} || import -t <...>;"). Another way is
> to always assume "uEnv.txt style" whenever fel_script_length is set, and
> do a himport_r() of the script data right away (the programmatic equivalent
> of "import -t"). I'm doing this in an experimental branch of mine, as it
> allows overriding everything from the default environment - including the
> "bootcmd" itself.
>
> Of course, all of this also requires support from the sunxi-fel side
> of things (i.e. fel_script_length getting set in the first place). A
> quick-and-dirty solution I'm currently using is to assume a uEnv.txt
> script (and set fel_script_length) whenever sunxi-fel detects uploads of
> pure ASCII data.
The boot.scr file is nice because it has its own format and a magic
signature. The uEnv.txt is difficult to recognize automatically, but
maybe we can borrow the https://en.wikipedia.org/wiki/Shebang_%28Unix%29
approach used by scripting languages?
I mean, we can require that the first line of uEnv.txt is a comment in a
special format. This can be described in the sunxi-tools documentation.
And also the sunxi-fel tool could print a warning if it detects upload
of pure ASCII data from a file with "uEnv" part in the name and ".txt"
as the extension.
> This could also be done easily with a dedicated command,
> and I can even image sunxi-fel building the uEnv.txt string itself from
> given ("env") key/value pairs.
>
> > 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"?
>
> Well... this _is_ the generic name that U-Boot itself tends to use for
> data transfers. E.g. "load" or "tftp" commands set the ${filesize} too.
So you are suggesting to pretend that there was a "load" command
executed for "uEnv.txt" right before running the code from the default
environment? This seems to be rather fragile and does not look like
it offers any real advantages over "fel_scriptsize".
> >
> > 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.
> >
>
> Our sunxi-fel utility is already testing for the script.bin format
> and can preserve the existing functionality by simply forcing
> fel_script_length to 0 in that case. And additional safeguards might
> be placed before "actively" setting that value to anything non-zero.
So it would serve both as the uEnv.txt length and also as the format
type indicator (boot.scr or uEnv.txt)? This is probably okay if it is
documented properly.
--
Regards,
Sierž
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: Add the ability to pass (script) filesize in the SPL header
Hello Bernhard,
On Sat, 4 Jun 2016 19:12:20 +0200
Bernhard Nortmann wrote:
> Convert one of the "reserved" fields in the sunxi SPL header to
> a fel_script_length entry. That enables the sunxi-fel utility
> to pass the script size when booting over USB ("FEL mode").
>
> If board.c encounters a non-zero value in this header field, it
> will set U-Boot's "filesize" environment variable accordingly.
>
> sunxi-fel currently doesn't use this field (i.e. fel_script_length
> will remain 0), but it would allow for new use cases, e.g. passing
> tweaked/additional settings via a text file (uEnv.txt style), and
> then using "import -t ${fel_script_addr} ${filesize}" on them.
How does this work in general with "boot.scr" and "uEnv.txt" use
cases? Could you provide a bit more detailed description?
I mean, who is going to do "import -t ${fel_script_addr} ${filesize}"
invocation?
This particular FEL feature in the SPL header is used to allow running
a boot script provided by the user (boot.scr). Without it, we only
have the default U-Boot environment. And the default U-Boot environment
does not have the "import -t ${fel_script_addr} ${filesize}" statement
yet. This looks a bit like a chicken/egg problem or am I missing
something?
>
> Signed-off-by: Bernhard Nortmann
>
> ---
>
> arch/arm/include/asm/arch-sunxi/spl.h | 3 ++-
> board/sunxi/board.c | 8 +++-
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/spl.h
> b/arch/arm/include/asm/arch-sunxi/spl.h
> index a0f33b0..0e18438 100644
> --- a/arch/arm/include/asm/arch-sunxi/spl.h
> +++ b/arch/arm/include/asm/arch-sunxi/spl.h
> @@ -49,7 +49,8 @@ struct boot_file_head {
> uint8_t spl_signature[4];
> };
> uint32_t fel_script_address;
> - uint32_t reserved1[3];
> + uint32_t fel_script_length;
> + uint32_t reserved1[2];
> uint32_t boot_media;/* written here by the boot ROM */
> uint32_t reserved2[5]; /* padding, align to 64 bytes */
> };
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index d09cf6d..cf0ff33 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -585,9 +585,15 @@ static void parse_spl_header(const uint32_t spl_addr)
> if (memcmp(spl->spl_signature, SPL_SIGNATURE, 3) == 0) {
> uint8_t spl_header_version = spl->spl_signature[3];
> if (spl_header_version == SPL_HEADER_VERSION) {
> - if (spl->fel_script_address)
> + if (spl->fel_script_address) {
> setenv_hex("fel_scriptaddr",
> spl->fel_script_address);
> + if (spl->fel_script_length)
> + setenv_hex("filesize",
> +spl->fel_script_length);
> + else
> + 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"?
> + }
> 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
[U-Boot] [PATCH v1] sunxi: Support booting from SPI flash
Allwinner devices support SPI flash as one of the possible
bootable media type. The SPI flash chip needs to be connected
to SPI0 pins (port C) to make this work. More information is
available at:
https://linux-sunxi.org/Bootable_SPI_flash
This patch adds the initial support for booting from 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/mach-sunxi/board.c | 176
board/sunxi/board.c | 98
2 files changed, 274 insertions(+)
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index bd15b9b..a07a0c8 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -131,13 +131,186 @@ static int gpio_init(void)
return 0;
}
+#ifdef CONFIG_SPL_BUILD
+void board_spi_init(void);
+
+static void spi_data_transfer(void *buf,
+ u32 bufsize,
+ void *spi_ctl_reg,
+ u32 spi_ctl_xch_bitmask,
+ void *spi_fifo_reg,
+ void *spi_tx_reg,
+ void *spi_rx_reg,
+ void *spi_bc_reg,
+ void *spi_tc_reg,
+ void *spi_bcc_reg)
+{
+ u32 cnt;
+ u32 rxsize = bufsize;
+ u32 txsize = bufsize;
+ u8 *rxbuf8 = buf;
+ u8 *txbuf8 = buf;
+ u32 *rxbuf;
+ u32 *txbuf;
+
+ /* sun6i uses 3 registers, sun4i only needs 2 */
+ writel(bufsize, spi_bc_reg);
+ writel(bufsize, spi_tc_reg);
+ if (spi_bcc_reg)
+ writel(bufsize, spi_bcc_reg);
+
+ /* Fill the TX buffer with some initial data */
+ cnt = (-(u32)txbuf8 & 3) + 60;
+ if (cnt > txsize)
+ cnt = txsize;
+ while (cnt-- > 0) {
+ writeb(*txbuf8++, spi_tx_reg);
+ txsize--;
+ }
+
+ /* Start the data transfer */
+ writel(readl(spi_ctl_reg) | spi_ctl_xch_bitmask, spi_ctl_reg);
+
+ /* Read the initial unaligned part of the data */
+ cnt = (-(u32)rxbuf8 & 3);
+ if (cnt > rxsize)
+ cnt = rxsize;
+ while (cnt > 0) {
+ u32 fiforeg = readl(spi_fifo_reg);
+ int rxfifo = fiforeg & 0x7F;
+ if (rxfifo > 0) {
+ *rxbuf8++ = readb(spi_rx_reg);
+ cnt--;
+ rxsize--;
+ }
+ }
+
+ /* Fast processing of the aligned part (read/write 32-bit at a time) */
+ rxbuf = (u32 *)rxbuf8;
+ txbuf = (u32 *)txbuf8;
+ while (rxsize >= 4) {
+ u32 fiforeg = readl(spi_fifo_reg);
+ int rxfifo = fiforeg & 0x7F;
+ int txfifo = (fiforeg >> 16) & 0x7F;
+ if (rxfifo >= 4) {
+ *rxbuf++ = readl(spi_rx_reg);
+ rxsize -= 4;
+ }
+ if (txfifo < 60 && txsize >= 4) {
+ writel(*txbuf++, spi_tx_reg);
+ txsize -= 4;
+ }
+ }
+
+ /* Handle the trailing part pf the data */
+ rxbuf8 = (u8 *)rxbuf;
+ txbuf8 = (u8 *)txbuf;
+ while (rxsize >= 1) {
+ u32 fiforeg = readl(spi_fifo_reg);
+ int rxfifo = fiforeg & 0x7F;
+ int txfifo = (fiforeg >> 16) & 0x7F;
+ if (rxfifo >= 1) {
+ *rxbuf8++ = readb(spi_rx_reg);
+ rxsize -= 1;
+ }
+ if (txfifo < 60 && txsize >= 1) {
+ writeb(*txbuf8++, spi_tx_reg);
+ txsize -= 1;
+ }
+ }
+}
+
+#define SUN4I_SPI0_CCTL (void *)(0x01C05000 + 0x1C)
+#define SUN4I_SPI0_CTL (void *)(0x01C05000 + 0x08)
+#define SUN4I_SPI0_RX (void *)(0x01C05000 + 0x00)
+#define SUN4I_SPI0_TX (void *)(0x01C05000 + 0x04)
+#define SUN4I_SPI0_FIFO_STA (void *)(0x01C05000 + 0x28)
+#define SUN4I_SPI0_BC (void *)(0x01C05000 + 0x20)
+#define SUN4I_SPI0_TC (void *)(0x01C05000 + 0x24)
+
+#define SUN6I_SPI0_CCTL (void *)(0x01C68000 + 0x24)
+#define SUN6I_SPI0_GCR (void *)(0x01C68000 + 0x04)
+#define SUN6I_SPI0_TCR (void *)(0x01C68000 + 0x08)
+#define SUN6I_SPI0_FIFO_STA (void *)(0x01C68000 + 0x1C)
+#define SUN6I_SPI0_MBC (void *)(0x01C68000 + 0x30)
+#define SUN6I_SPI0_MTC (void *)(0x01C68000 + 0x34)
+#define SUN6I_SPI0_BCC (void *
Re: [U-Boot] [PATCH v2] sunxi: Increase SPL header size to 64 bytes to avoid code corruption
On Mon, 16 May 2016 19:52:33 +0200
Hans de Goede wrote:
> Hi,
>
> On 16-05-16 11:56, Bernhard Nortmann wrote:
> > Given that there now are quite a few additional "reserved" entries, and
> > while we're still at SPL_HEADER_VERSION 1, I'd like to renew my request of
> > dedicating one of these fields to the script length - which would enable us
> > to set the U-Boot ${filesize} accordingly.
> >
> > i.e.
> > --- arch-arm-include-asm-arch-sunxi-spl.h
> > +++ arch-arm-include-asm-arch-sunxi-spl.new.h
> > @@ -49,7 +49,8 @@
> > uint8_t spl_signature[4];
> > };
> > uint32_t fel_script_address;
> > - uint32_t reserved1[3];
> > + uint32_t fel_script_length;
> > + uint32_t reserved1[2];
> > uint32_t boot_media;/* written here by the boot ROM */
> > uint32_t reserved2[5]; /* padding, align to 64 bytes */
> > };
> >
> >
> > I do not intend to further push my specific use cases, however I still
> > consider the (then somewhat theoretical) ability to do "import -t
> > ${fel_script_addr} ${filesize}" useful. For reference, the previous
> > discussion related to this was somewhere around
> > http://lists.denx.de/pipermail/u-boot/2015-September/227454.html
>
> Hmm, given that the boot-rom touches some of these, I wonder if
> we should be putting anything here at all.
Yes, this came as a bit of surprise because this was not clearly
documented anywhere. Still it looks like that's just a single
byte getting modified, albeit at a bit strange location.
BTW, do you remember what I said earlier about not always being in
perfect control?
http://lists.denx.de/pipermail/u-boot/2015-September/228727.html
This particular issue just serves as a very nice demonstration :-)
Anyway, I think that we are already reasonably well prepared to handle
it. The worst thing that can 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"
version change trick).
> Other then that worry, I see no problem with adding a
> fel_script_length, Siarhei what is your opinion on this ?
I personally have no objections.
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] sunxi: Store the device tree name in the SPL header
This patch updates the mksunxiboot tool to optionally add
the default device tree name string to the SPL header. This
information can be used by the firmware upgrade tools to
protect users from harming themselves by trying to upgrade
to an incompatible bootloader.
The primary use case here is a non-removable bootable media
(such as NAND, eMMC or SPI flash), which already may have
a properly working, but a little bit outdated bootloader
installed. For example, the user may download or build a
new U-Boot image for "Cubieboard", and then attemept to
install it on a "Cubieboard2" hardware by mistake as a
replacement for the already existing bootloader. If this
happens, the flash programming tool can identify this
problem and warn the user.
CONFIG_OF_LIST may provide more than one compatible device
tree name when supporting multiple boards by a single
defconfig. In such cases, the right device tree name is
getting identified at runtime from the list of multiple
options. The patch calculates a 32-bit hash value (crc32)
of this list and stores it to the SPL header too, because
this is better than nothing and still can be used to warn
about potentially incompatible 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 +++---
scripts/Makefile.spl | 3 +-
tools/Makefile| 1 +
tools/mksunxiboot.c | 71 +--
5 files changed, 98 insertions(+), 15 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/spl.h
b/arch/arm/include/asm/arch-sunxi/spl.h
index a0f33b0..f370222 100644
--- a/arch/arm/include/asm/arch-sunxi/spl.h
+++ b/arch/arm/include/asm/arch-sunxi/spl.h
@@ -10,7 +10,7 @@
#define BOOT0_MAGIC"eGON.BT0"
#define SPL_SIGNATURE "SPL" /* marks "sunxi" SPL header */
-#define SPL_HEADER_VERSION 1
+#define SPL_HEADER_VERSION 2
#if defined(CONFIG_MACH_SUN9I) || defined(CONFIG_MACH_SUN50I)
#define SPL_ADDR 0x1
@@ -49,9 +49,27 @@ struct boot_file_head {
uint8_t spl_signature[4];
};
uint32_t fel_script_address;
- uint32_t reserved1[3];
- uint32_t boot_media;/* written here by the boot ROM */
- uint32_t reserved2[5]; /* padding, align to 64 bytes */
+ uint32_t reserved1[1];
+ /*
+* Offset of an ASCIIZ string (relative to the SPL header), which
+* contains the default device tree name (CONFIG_DEFAULT_DEVICE_TREE).
+* This is optional and may be set to NULL. Is intended to be used
+* by flash programming tools for providing nice informative messages
+* to the users.
+*/
+ uint32_t offset_of_the_default_device_tree_name;
+ /*
+* A 32-bit hash value, calculated from the list of compatible device
+* tree names (CONFIG_OF_LIST or CONFIG_DEFAULT_DEVICE_TREE). Is
+* intended to be used by flash programming tools for safeguearding
+* against upgrading to an incompatible firmware.
+*/
+ uint32_t crc32_of_the_compatible_device_tree_list;
+ /* The 'boot_media' code is written here by the boot ROM */
+ uint32_t boot_media;
+ /* A padding area (may be used for storing text strings) */
+ uint32_t string_pool[13];
+ /* The header must be a multiple of 32 bytes (for VBAR alignment) */
};
#define is_boot0_magic(addr) (memcmp((void *)addr, BOOT0_MAGIC, 8) == 0)
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index b33cfb8..e184d0c 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -189,14 +189,14 @@
#define CONFIG_SPL_BOARD_LOAD_IMAGE
#if defined(CONFIG_MACH_SUN9I)
-#define CONFIG_SPL_TEXT_BASE 0x10040 /* sram start+header */
-#define CONFIG_SPL_MAX_SIZE0x5fc0 /* ? KiB on sun9i */
+#define CONFIG_SPL_TEXT_BASE 0x10060 /* sram start+header */
+#define CONFIG_SPL_MAX_SIZE0x5fa0 /* ? KiB on sun9i */
#elif defined(CONFIG_MACH_SUN50I)
-#define CONFIG_SPL_TEXT_BASE 0x10040 /* sram start+header */
-#define CONFIG_SPL_MAX_SIZE0x7fc0 /* 32 KiB on sun50i */
+#define CONFIG_SPL_TEXT_BASE 0x10060 /* sram start+header */
+#define CONFIG_SPL_MAX_SIZE0x7fa0 /* 32 KiB on sun50i */
#else
-#define CONFIG_SPL_TEXT_BASE 0x40/* sram start+header */
-#define CONFIG_SPL_MAX_SIZE0x5fc0 /* 24KB on sun4i/sun7i
*/
+#define CONFIG_SPL_TEXT_BASE 0x60/* sram start+header */
+#define CONFIG_SPL_MAX_SIZE0
Re: [U-Boot] [linux-sunxi] [PATCH v2 7/7] spl: nand: sunxi: add support for NAND config auto-detection
On Wed, 1 Jun 2016 13:23:24 +0200 Boris Brezillon wrote: > NAND chips are supposed to expose their capabilities through advanced > mechanisms like READID, ONFI or JEDEC parameter tables. While those > methods are appropriate for the bootloader itself, it's way to > complicated and takes too much space to fit in the SPL. > > Replace those mechanisms by a dumb 'trial and error' mechanism. > > With this new approach we can get rid of the fixed config list that was > used in the sunxi NAND SPL driver. > > Signed-off-by: Boris Brezillon > Acked-by: Hans de Goede We can also have these NAND parameters stored in the SPL header and added there by a NAND image builder tool. This may save some precious space in the SPL and also improve the reliability of detection. Yes, this brings the necessity of the image builder tool into the spotlight (something that converts the "u-boot-sunxi-with-spl.bin" to a NAND image) but this has always been a problem. We have some ongoing discussion about this in the linux-sunxi mailing list: https://groups.google.com/forum/#!topic/linux-sunxi/HsWRG-nuV-w It also makes a lot of sense to have the NAND support functionality enabled in the SPL for all sunxi boards by default, so the code size does matter. We still do have the runtime decompression opportunity as the strategic 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/pipermail/u-boot/2015-September/226963.html -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] sunxi: Downclock AHB1 to 100MHz on Allwinner A64
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/memcmp test).
>
> For what it's worth, the Allwinner's BSP configures AHB1
> as 200MHz, as can be verified by running the devmem2 tool
> in the system running the Allwinner's kernel 3.10.x:
>
>0x1C20028: PLL_PERIPH0_CTRL_REG = 0x90041811
>0x1C20054: AHB1_APB1_CFG_REG= 0x3180
>0x1C20058: APB2_CFG_REG = 0x100
>0x1C2005C: AHB2_CFG_REG = 0x1
>
> However the FEL mode uses more conservative settings (100MHz
> for AHB1):
>
>0x1C20028: PLL_PERIPH0_CTRL_REG = 0x90041811
>0x1C20054: AHB1_APB1_CFG_REG= 0x3180
Oops, a copy-paste issue when editing the commit message, this
should be 0x3190
>0x1C20058: APB2_CFG_REG = 0x100
>0x1C2005C: AHB2_CFG_REG = 0x0
>
> It is yet to be confirmed whether faster AHB1/AHB2 clock settings
> can be used safely if we initialize the AXP803 PMIC instead of
> using reset defaults. But in order to resolve the data corruption
> problem right now, it's best to downclock AHB1 to a safe level.
>
> Note that this issue only affects the SPL, which is not fully
> supported on Allwinner 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_sun6i.h
> b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> index f2990db..c2e72f5 100644
> --- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> +++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> @@ -222,7 +222,12 @@ struct sunxi_ccm_reg {
> #define CCM_PLL11_CTRL_UPD (0x1 << 30)
> #define CCM_PLL11_CTRL_EN(0x1 << 31)
>
> +#if defined(CONFIG_MACH_SUN50I)
> +/* AHB1=100MHz failsafe setup from the FEL mode, usable with PMIC defaults */
> +#define AHB1_ABP1_DIV_DEFAULT0x3190 /*
> 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
[U-Boot] [PATCH 1/2] sunxi: Downclock AHB1 to 100MHz on Allwinner A64
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/memcmp test).
For what it's worth, the Allwinner's BSP configures AHB1
as 200MHz, as can be verified by running the devmem2 tool
in the system running the Allwinner's kernel 3.10.x:
0x1C20028: PLL_PERIPH0_CTRL_REG = 0x90041811
0x1C20054: AHB1_APB1_CFG_REG= 0x3180
0x1C20058: APB2_CFG_REG = 0x100
0x1C2005C: AHB2_CFG_REG = 0x1
However the FEL mode uses more conservative settings (100MHz
for AHB1):
0x1C20028: PLL_PERIPH0_CTRL_REG = 0x90041811
0x1C20054: AHB1_APB1_CFG_REG= 0x3180
0x1C20058: APB2_CFG_REG = 0x100
0x1C2005C: AHB2_CFG_REG = 0x0
It is yet to be confirmed whether faster AHB1/AHB2 clock settings
can be used safely if we initialize the AXP803 PMIC instead of
using reset defaults. But in order to resolve the data corruption
problem right now, it's best to downclock AHB1 to a safe level.
Note that this issue only affects the SPL, which is not fully
supported on Allwinner 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_sun6i.h
b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
index f2990db..c2e72f5 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
@@ -222,7 +222,12 @@ struct sunxi_ccm_reg {
#define CCM_PLL11_CTRL_UPD (0x1 << 30)
#define CCM_PLL11_CTRL_EN (0x1 << 31)
+#if defined(CONFIG_MACH_SUN50I)
+/* AHB1=100MHz failsafe setup from the FEL mode, usable with PMIC defaults */
+#define AHB1_ABP1_DIV_DEFAULT 0x3190 /* AHB1=PLL6/6,APB1=AHB1/2 */
+#else
#define AHB1_ABP1_DIV_DEFAULT 0x3180 /* AHB1=PLL6/3,APB1=AHB1/2 */
+#endif
#define AXI_GATE_OFFSET_DRAM 0
--
2.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] sunxi: Fix SRAM C corruption issue on Allwinner A64
The full SPL support is not quite ready for Allwinner A64 yet, but these fixes are likely to be necessary. Of course, unless the problem is actually caused by wrong voltages and the AXP803 PMIC support magically fixes it. PS. Discovered when developing a sunxi-fel based SPI flash programmer tool 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/A80 arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 5 + include/configs/sunxi-common.h| 5 ++--- 2 files changed, 7 insertions(+), 3 deletions(-) -- 2.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] sunxi: Move the SPL stack top to 0x1A000 on Allwinner A64/A80
Since the SRAM C corruption issue is now resolved on Allwinner A64, it is possible to move the stack top to the address 0x1A000 on both A64 and A80. The boot ROM can load SPL binaries with up to 32 KiB size on A64 (the 24 KiB SPL size limitation only affects A10/A20), and this patch also ensures 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-common.h +++ b/include/configs/sunxi-common.h @@ -100,7 +100,7 @@ * the 1 actually activates the mapping of the first 32 KiB to 0x. */ #define CONFIG_SYS_INIT_RAM_ADDR 0x1 -#define CONFIG_SYS_INIT_RAM_SIZE 0x08000 /* FIXME: 40 KiB ? */ +#define CONFIG_SYS_INIT_RAM_SIZE 0xA000 /* 40 KiB */ #else #define CONFIG_SYS_INIT_RAM_ADDR 0x0 #define CONFIG_SYS_INIT_RAM_SIZE 0x8000 /* 32 KiB */ @@ -213,8 +213,7 @@ #define CONFIG_SPL_PAD_TO 32768 /* decimal for 'dd' */ #if defined(CONFIG_MACH_SUN9I) || defined(CONFIG_MACH_SUN50I) -/* FIXME: 40 KiB instead of 32 KiB ? */ -#define LOW_LEVEL_SRAM_STACK 0x00018000 +#define LOW_LEVEL_SRAM_STACK 0x0001A000 #define CONFIG_SPL_STACK LOW_LEVEL_SRAM_STACK #else /* end of 32 KiB in sram */ -- 2.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: Increase the SPL header size to 48 bytes to avoid code corruption
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.
> For example, when booting from the SD card, the magic number written
> by the boot ROM is 0. And when booting from the SPI flash, the magic
> number is 3. NAND and eMMC probably have their own special magic
> numbers too.
>
> Currently the corrupted byte is a part of one of the instructions in
> the reset vectors table:
>
> b reset
> ldr pc, _undefined_instruction
> ldr pc, _software_interrupt <- Corruption happens here
> ldr pc, _prefetch_abort
> ldr pc, _data_abort
> ldr pc, _not_used
> ldr pc, _irq
> ldr pc, _fiq
>
> In practice this does not cause any visible problems, but it's still
> better to fix it. As a bonus, the reported boot media 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 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/spl.h
> b/arch/arm/include/asm/arch-sunxi/spl.h
> index ca9a4f9..80696a8 100644
> --- a/arch/arm/include/asm/arch-sunxi/spl.h
> +++ b/arch/arm/include/asm/arch-sunxi/spl.h
> @@ -18,6 +18,10 @@
> #define SPL_ADDR 0x0
> #endif
>
> +/* The low 8-bits of the 'boot_media' field in the SPL header */
> +#define SUNXI_BOOTED_FROM_MMC0 0
> +#define SUNXI_BOOTED_FROM_SPI3
> +
> /* boot head definition from sun4i boot code */
> struct boot_file_head {
> uint32_t b_instruction; /* one intruction jumping to real code */
> @@ -45,7 +49,9 @@ struct boot_file_head {
> uint8_t spl_signature[4];
> };
> uint32_t fel_script_address;
> - uint32_t reserved; /* padding, align to 32 bytes */
> + uint32_t reserved1[3];
> + uint32_t boot_media;/* written here by the boot ROM */
> + uint32_t reserved2; /* padding, align to 48 bytes */
> };
>
> #define is_boot0_magic(addr) (memcmp((void *)addr, BOOT0_MAGIC, 8) == 0)
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> index 2406115..945ed0a 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -189,14 +189,14 @@
> #define CONFIG_SPL_BOARD_LOAD_IMAGE
>
> #if defined(CONFIG_MACH_SUN9I)
> -#define CONFIG_SPL_TEXT_BASE 0x10020 /* sram start+header */
> -#define CONFIG_SPL_MAX_SIZE 0x5fe0 /* ? KiB on sun9i */
> +#define CONFIG_SPL_TEXT_BASE 0x10030 /* sram start+header */
> +#define CONFIG_SPL_MAX_SIZE 0x5fd0 /* ? KiB on sun9i */
> #elif defined(CONFIG_MACH_SUN50I)
> -#define CONFIG_SPL_TEXT_BASE 0x10020 /* sram start+header */
> -#define CONFIG_SPL_MAX_SIZE 0x7fe0 /* 32 KiB on sun50i */
> +#define CONFIG_SPL_TEXT_BASE 0x10030 /* sram start+header */
> +#define CONFIG_SPL_MAX_SIZE 0x7fd0 /* 32 KiB on sun50i */
> #else
> -#define CONFIG_SPL_TEXT_BASE 0x20/* sram start+header */
> -#define CONFIG_SPL_MAX_SIZE 0x5fe0 /* 24KB on sun4i/sun7i
> */
> +#define CONFIG_SPL_TEXT_BASE 0x30/* sram start+header */
> +#define CONFIG_SPL_MAX_SIZE 0x5fd0 /* 24KB on sun4i/sun7i
> */
> #endif
>
> #define CONFIG_SPL_LIBDISK_SUPPORT
If we are placing the reset vectors table right after the SPL header,
then we need a 32-byte alignment. An updated v2 patch submitted (sorry
for a different summary line):
https://patchwork.ozlabs.org/patch/622173/
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] sunxi: Increase SPL header size to 64 bytes to avoid code corruption
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.
For example, when booting from the SD card, the magic number written
by the boot ROM is 0. And when booting from the SPI flash, the magic
number is 3. NAND and eMMC probably have their own special magic
numbers too.
Currently the corrupted byte is a part of one of the instructions in
the reset vectors table:
b reset
ldr pc, _undefined_instruction
ldr pc, _software_interrupt <- Corruption happens here
ldr pc, _prefetch_abort
ldr pc, _data_abort
ldr pc, _not_used
ldr pc, _irq
ldr pc, _fiq
In practice this does not cause any visible problems, but it's still
better to fix it. As a bonus, the reported boot media 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/include/asm/arch-sunxi/spl.h | 8 +++-
include/configs/sunxi-common.h| 12 ++--
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/spl.h
b/arch/arm/include/asm/arch-sunxi/spl.h
index ca9a4f9..a0f33b0 100644
--- a/arch/arm/include/asm/arch-sunxi/spl.h
+++ b/arch/arm/include/asm/arch-sunxi/spl.h
@@ -18,6 +18,10 @@
#define SPL_ADDR 0x0
#endif
+/* The low 8-bits of the 'boot_media' field in the SPL header */
+#define SUNXI_BOOTED_FROM_MMC0 0
+#define SUNXI_BOOTED_FROM_SPI 3
+
/* boot head definition from sun4i boot code */
struct boot_file_head {
uint32_t b_instruction; /* one intruction jumping to real code */
@@ -45,7 +49,9 @@ struct boot_file_head {
uint8_t spl_signature[4];
};
uint32_t fel_script_address;
- uint32_t reserved; /* padding, align to 32 bytes */
+ uint32_t reserved1[3];
+ uint32_t boot_media;/* written here by the boot ROM */
+ uint32_t reserved2[5]; /* padding, align to 64 bytes */
};
#define is_boot0_magic(addr) (memcmp((void *)addr, BOOT0_MAGIC, 8) == 0)
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 2406115..e2ee908 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -189,14 +189,14 @@
#define CONFIG_SPL_BOARD_LOAD_IMAGE
#if defined(CONFIG_MACH_SUN9I)
-#define CONFIG_SPL_TEXT_BASE 0x10020 /* sram start+header */
-#define CONFIG_SPL_MAX_SIZE0x5fe0 /* ? KiB on sun9i */
+#define CONFIG_SPL_TEXT_BASE 0x10040 /* sram start+header */
+#define CONFIG_SPL_MAX_SIZE0x5fc0 /* ? KiB on sun9i */
#elif defined(CONFIG_MACH_SUN50I)
-#define CONFIG_SPL_TEXT_BASE 0x10020 /* sram start+header */
-#define CONFIG_SPL_MAX_SIZE0x7fe0 /* 32 KiB on sun50i */
+#define CONFIG_SPL_TEXT_BASE 0x10040 /* sram start+header */
+#define CONFIG_SPL_MAX_SIZE0x7fc0 /* 32 KiB on sun50i */
#else
-#define CONFIG_SPL_TEXT_BASE 0x20/* sram start+header */
-#define CONFIG_SPL_MAX_SIZE0x5fe0 /* 24KB on sun4i/sun7i
*/
+#define CONFIG_SPL_TEXT_BASE 0x40/* sram start+header */
+#define CONFIG_SPL_MAX_SIZE0x5fc0 /* 24KB on sun4i/sun7i
*/
#endif
#define CONFIG_SPL_LIBDISK_SUPPORT
--
2.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sunxi: Increase the SPL header size to 48 bytes to avoid code corruption
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.
For example, when booting from the SD card, the magic number written
by the boot ROM is 0. And when booting from the SPI flash, the magic
number is 3. NAND and eMMC probably have their own special magic
numbers too.
Currently the corrupted byte is a part of one of the instructions in
the reset vectors table:
b reset
ldr pc, _undefined_instruction
ldr pc, _software_interrupt <- Corruption happens here
ldr pc, _prefetch_abort
ldr pc, _data_abort
ldr pc, _not_used
ldr pc, _irq
ldr pc, _fiq
In practice this does not cause any visible problems, but it's still
better to fix it. As a bonus, the reported boot media 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 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/spl.h
b/arch/arm/include/asm/arch-sunxi/spl.h
index ca9a4f9..80696a8 100644
--- a/arch/arm/include/asm/arch-sunxi/spl.h
+++ b/arch/arm/include/asm/arch-sunxi/spl.h
@@ -18,6 +18,10 @@
#define SPL_ADDR 0x0
#endif
+/* The low 8-bits of the 'boot_media' field in the SPL header */
+#define SUNXI_BOOTED_FROM_MMC0 0
+#define SUNXI_BOOTED_FROM_SPI 3
+
/* boot head definition from sun4i boot code */
struct boot_file_head {
uint32_t b_instruction; /* one intruction jumping to real code */
@@ -45,7 +49,9 @@ struct boot_file_head {
uint8_t spl_signature[4];
};
uint32_t fel_script_address;
- uint32_t reserved; /* padding, align to 32 bytes */
+ uint32_t reserved1[3];
+ uint32_t boot_media;/* written here by the boot ROM */
+ uint32_t reserved2; /* padding, align to 48 bytes */
};
#define is_boot0_magic(addr) (memcmp((void *)addr, BOOT0_MAGIC, 8) == 0)
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 2406115..945ed0a 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -189,14 +189,14 @@
#define CONFIG_SPL_BOARD_LOAD_IMAGE
#if defined(CONFIG_MACH_SUN9I)
-#define CONFIG_SPL_TEXT_BASE 0x10020 /* sram start+header */
-#define CONFIG_SPL_MAX_SIZE0x5fe0 /* ? KiB on sun9i */
+#define CONFIG_SPL_TEXT_BASE 0x10030 /* sram start+header */
+#define CONFIG_SPL_MAX_SIZE0x5fd0 /* ? KiB on sun9i */
#elif defined(CONFIG_MACH_SUN50I)
-#define CONFIG_SPL_TEXT_BASE 0x10020 /* sram start+header */
-#define CONFIG_SPL_MAX_SIZE0x7fe0 /* 32 KiB on sun50i */
+#define CONFIG_SPL_TEXT_BASE 0x10030 /* sram start+header */
+#define CONFIG_SPL_MAX_SIZE0x7fd0 /* 32 KiB on sun50i */
#else
-#define CONFIG_SPL_TEXT_BASE 0x20/* sram start+header */
-#define CONFIG_SPL_MAX_SIZE0x5fe0 /* 24KB on sun4i/sun7i
*/
+#define CONFIG_SPL_TEXT_BASE 0x30/* sram start+header */
+#define CONFIG_SPL_MAX_SIZE0x5fd0 /* 24KB on sun4i/sun7i
*/
#endif
#define CONFIG_SPL_LIBDISK_SUPPORT
--
2.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: mctl_mem_matches: Add missing memory barrier
Hello Hans, On Thu, 14 Apr 2016 18:58:04 +0200 Hans de Goede wrote: > We are running with the caches disabled when mctl_mem_matches gets called, > but the cpu's write buffer is still there and can still get in the way, This does not make much sense to me. The SPL is running with the MMU disabled, because disabling the MMU is one of the first things done by the SPL at the very start. And when the MMU is disabled, all the data accesses are treated as Strongly-ordered and are not supposed to use the write buffer. A quote from the ARMv7 Architecture Manual: "a write to Strongly-ordered memory can complete only when it reaches the peripheral or memory component accessed by the write" We can even verify whether the write buffer is actually in use by simply benchmarking something like the memset function. If the write buffer is working, then the sequential write speed will be around 1 GB/s or more. > add a memory barrier to fix this. > > This avoids mctl_mem_matches always returning false in some cases, which > was resulting in: > > U-Boot SPL 2015.07 (Apr 14 2016 - 18:47:26) > DRAM: 1024 MiB > > U-Boot 2015.07 (Apr 14 2016 - 18:47:26 +0200) Allwinner Technology > > CPU: Allwinner A23 (SUN8I) > DRAM: 512 MiB > > Where 512 MiB is the right amount, but the DRAM controller would be > initialized for 1024 MiB. Is it just a single device or board? Has anybody seen anything like this on other devices with the same SoC? I wonder if what you are observing could be possibly explained by just a usual data corruption problem? Which may be happening when the DRAM clock speed is set higher than this particular device is able to handle in a reliable way. Inserting just one or more NOP instructions instead of the barrier could possibly change some timings too. If this patch helps, then it's fine. But I wonder if it is not merely making the problem latent instead of fixing the root cause? > > Signed-off-by: Hans de Goede > --- > arch/arm/mach-sunxi/dram_helpers.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/mach-sunxi/dram_helpers.c > b/arch/arm/mach-sunxi/dram_helpers.c > index 50318d2..e0c823a 100644 > --- a/arch/arm/mach-sunxi/dram_helpers.c > +++ b/arch/arm/mach-sunxi/dram_helpers.c > @@ -7,6 +7,7 @@ > */ > > #include > +#include > #include > #include > > @@ -31,6 +32,7 @@ bool mctl_mem_matches(u32 offset) > /* Try to write different values to RAM at two addresses */ > writel(0, CONFIG_SYS_SDRAM_BASE); > 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
Re: [U-Boot] [linux-sunxi] A10 bring up and DRAM configuration procedure
mster is by far more sensitive to DRAM misconfiguration than the usual software. So the borderline unreliable DRAM settings may not exhibit any visible bad effects (the system is able to boot, the usual linux software works fine too), but easily detected by lima-memtester. Because the system is sufficiently usable at such borderline unstable DRAM settings, we can run automation scripts to do a bruteforce search, which is probing different TPR3 values without human supervision. That's what is explained at: https://linux-sunxi.org/A10_DRAM_Controller_Calibration But in your case, you can try different ZQ and TPR3 settings manually in the U-Boot defconfig and instead of running lima-memtester (which first needs a bootable userland) just monitor how far the system is able to boot as an alternative selection criteria for picking better configuration values. If you manage to boot the system up to a semi-working userland, then you can switch to using lima-memtester for the final tuning and validation. > If anyone more experienced can advise what can be done at this point I would > appreciate. Maybe ask the hardware people if they have done the DDR3 routing right? Also if it is just a single board, then it might be not misconfigured, but defective. Trying another 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/pietrushnic/ea41a4ae38b7af8a6fa456113ce19af8 > [4] http://www.denx.de/wiki/view/DULG/UBootCrashAfterRelocation > [5] https://gist.github.com/pietrushnic/d6a3d6c0b4a20a3226dfb67c4d129142 -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: fix DCDC2 output in CHIP_defconfig
On Mon, 7 Mar 2016 13:44:11 +0100 Maxime Ripard wrote: > From: Boris Brezillon > > Unlike the datasheet recommendation, the R8 SoC requires a 1.4V supply > for its CPU when operating at 1Ghz. That's interesting. Is this R8 SoC datasheet with the Allwinner recommended cpufreq operating points available in public access somewhere? Are they really recommending 1008MHz @1.3V there? > Rely on the default value specified in the Kconfig entry. > > Signed-off-by: Boris Brezillon > Signed-off-by: Maxime Ripard > --- > configs/CHIP_defconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/configs/CHIP_defconfig b/configs/CHIP_defconfig > index 78b2c511bfa2..3135d1c88e79 100644 > --- 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=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
Re: [U-Boot] [PATCH] sunxi: power: add support for sy8106a driver
config AXP_ELDO3_VOLT
> 1.2V for the SSD2828 chip (converter of parallel LCD interface
> into MIPI DSI).
>
> +config SY8106A_VOUT1_VOLT
> + int "SY8106A pmic VOUT1 voltage"
> + depends on SY8106A_POWER
> + default 1200
> + ---help---
> + Set the voltage (mV) to program the SY8106A pmic VOUT1. This
> + is typically used to power the VDD-CPU and should be 1200mV.
> + Values can range from 680mV till 1950mV.
> +
In general, I'm not a big fan of having implicit defaults for the
dangerous things such as voltages somewhere outside of defconfig
files. This makes it difficult to review the correctness of board
setup and compare it with the settings from the Allwinner's FEX file.
If the implicit defaults change, then a bunch of defconfigs have
to change too, resulting in big and error prone patches. The problem
here is that when such big patch is submitted, other patches for
defconfigs of some new boards may be also submitted concurrently.
These concurrent patches need to be merged carefully or we end up
with the wrong configs. IIRC this has already resulted in troubles
in the past.
> endmenu
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index 0fdbca3..690faa0 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_AXP221_POWER) += axp221.o
> obj-$(CONFIG_AXP818_POWER) += axp818.o
> obj-$(CONFIG_EXYNOS_TMU) += exynos-tmu.o
> obj-$(CONFIG_FTPMU010_POWER) += ftpmu010.o
> +obj-$(CONFIG_SY8106A_POWER) += sy8106a.o
> obj-$(CONFIG_TPS6586X_POWER) += tps6586x.o
> obj-$(CONFIG_TWL4030_POWER) += twl4030.o
> obj-$(CONFIG_TWL6030_POWER) += twl6030.o
> diff --git a/drivers/power/sy8106a.c b/drivers/power/sy8106a.c
> new file mode 100644
> index 000..6492ddd
> --- /dev/null
> +++ b/drivers/power/sy8106a.c
> @@ -0,0 +1,23 @@
The license/copyright notice is missing here.
> +#include
> +#include
> +#include
> +
> +#define SY8106A_I2C_ADDR 0x65
> +#define SY8106A_VOUT1_SEL 1
> +#define SY8106A_VOUT1_SEL_ENABLE (1 << 7)
> +
> +static u8 sy8106a_mvolt_to_cfg(int mvolt, int min, int max, int div)
> +{
> + if (mvolt < min)
> + mvolt = min;
> + else if (mvolt > max)
> + mvolt = max;
> +
> + return (mvolt - min) / div;
> +}
> +
> +int sy8106a_set_vout1(unsigned int mvolt)
> +{
> + u8 data = sy8106a_mvolt_to_cfg(mvolt, 680, 1950, 10) |
> SY8106A_VOUT1_SEL_ENABLE;
> + return i2c_write(SY8106A_I2C_ADDR, SY8106A_VOUT1_SEL, 1, &data, 1);
> +}
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> index b4dfb3c..40850e5 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -206,7 +206,8 @@
> #define CONFIG_SPL_STACK LOW_LEVEL_SRAM_STACK
>
> /* I2C */
> -#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;
>
> /* PMU */
> #if defined CONFIG_AXP152_POWER || defined CONFIG_AXP209_POWER || \
> -defined CONFIG_AXP221_POWER || defined CONFIG_AXP818_POWER
> +defined CONFIG_AXP221_POWER || defined CONFIG_AXP818_POWER || \
> +defined CONFIG_SY8106A_POWER
> #define CONFIG_SPL_POWER_SUPPORT
> #endif
>
> diff --git a/include/sy8106a.h b/include/sy8106a.h
> new file mode 100644
> index 000..714c314
> --- /dev/null
> +++ b/include/sy8106a.h
> @@ -0,0 +1,5 @@
> +#ifndef _SY8106A_PMIC_H_
> +
> +int sy8106a_set_vout1(unsigned int mvolt);
> +
> +#endif
Tested-by: Siarhei Siamashka
Acked-by: Siarhei Siamashka
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] Re: PSCI for H3
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, > >> > > >> > I got my Orange Pi PC booting U-boot now, using Hans' sunxi-wip branch > >> > that > >> > includes Jens' patches. > >> > > >> > For PSCI and SMP, it seems the H3 follows the structure of previous > >> > sun8i SoCs. > >> > The CPUCFG registers line up. The manual doesn't have the PRCM, so I'll > >> > have to > >> > dig through the SDK. > >> > > >> > One other thing is the SMTA, or Secure Memory Touch Arbiter, which we > >> > last > >> > encountered issues with on the A31s. This controls non-secure access to > >> > a whole > >> > bunch of peripherals, which we'll need to enable for Linux to run > >> > non-secure. > >> > >> There is also register 0x2f0 in the CCU, it defaults to disabling > >> non-secure access to all clock registers. > >> > >> Jens > >> > > > > How about just enabling SMP on Allwinner H3 in an old unfashionable way > > while all these non-secure access limiters are still being under > > investigation? > > I'm not against it, though I was considering removing the SMP code. > > BTW, without docs on the PRCM, do we know if the H3 has the same power clamps > as the A31? FYI the A23 SMP code is the same as A31, just without the power > clamps. Yes. I inspected the kernel sources from the Allwinner SDK and it looks like A31 and H3 are taking exactly the same code path (using the same ifdef guards everywhere): https://github.com/allwinner-zh/linux-3.4-sunxi/blob/55599b8209bb7150140e4d45ef460dbff6c876dd/arch/arm/mach-sunxi/include/mach/sun8i/platsmp.h#L124-L139 "SUN8IW1 = A31" and "SUN8IW7 = H3" according to http://linux-sunxi.org/Allwinner_SoC_Family#2013_naming_scheme_change I'll also try to see if I can get PSCI working on H3, but it seems to be a real PITA to debug. Also some parts of the H3 documentation are missing (PRCM is a good example) and if there happens to be an undocumented configuration knob responsible to allowing non-secure access to some important resource, then we hit a brick wall... -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] Re: PSCI for H3
On Tue, 17 Nov 2015 15:32:30 +0100
Jens Kuske wrote:
> On 16/11/15 07:26, Chen-Yu Tsai wrote:
> > Hi everyone,
> >
> > I got my Orange Pi PC booting U-boot now, using Hans' sunxi-wip branch that
> > includes Jens' patches.
> >
> > For PSCI and SMP, it seems the H3 follows the structure of previous sun8i
> > SoCs.
> > The CPUCFG registers line up. The manual doesn't have the PRCM, so I'll
> > have to
> > dig through the SDK.
> >
> > One other thing is the SMTA, or Secure Memory Touch Arbiter, which we last
> > encountered issues with on the A31s. This controls non-secure access to a
> > whole
> > bunch of peripherals, which we'll need to enable for Linux to run
> > non-secure.
>
> There is also register 0x2f0 in the CCU, it defaults to disabling
> non-secure access to all clock registers.
>
> Jens
>
How about just enabling SMP on Allwinner H3 in an old unfashionable way
while all these non-secure access limiters are still being under
investigation?
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 0faa38a..d23ed84 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -51,6 +51,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "allwinner,sun6i-a31";
cpu@0 {
compatible = "arm,cortex-a7";
@@ -591,5 +592,15 @@
interrupts = ,
;
};
+
+ prcm@01f01400 {
+ compatible = "allwinner,sun8i-h3-prcm";
+ reg = <0x01f01400 0x200>;
+ };
+
+ cpucfg@01f01c00 {
+ compatible = "allwinner,sun8i-h3-cpuconfig";
+ reg = <0x01f01c00 0x300>;
+ };
};
};
diff --git a/arch/arm/mach-sunxi/platsmp.c b/arch/arm/mach-sunxi/platsmp.c
index e8483ec..8ca4064 100644
--- a/arch/arm/mach-sunxi/platsmp.c
+++ b/arch/arm/mach-sunxi/platsmp.c
@@ -44,6 +44,9 @@ static void __init sun6i_smp_prepare_cpus(unsigned int
max_cpus)
struct device_node *node;
node = of_find_compatible_node(NULL, NULL, "allwinner,sun6i-a31-prcm");
+ if (!node)
+ node = of_find_compatible_node(NULL, NULL,
+ "allwinner,sun8i-h3-prcm");
if (!node) {
pr_err("Missing A31 PRCM node in the device tree\n");
return;
@@ -57,6 +60,9 @@ static void __init sun6i_smp_prepare_cpus(unsigned int
max_cpus)
node = of_find_compatible_node(NULL, NULL,
"allwinner,sun6i-a31-cpuconfig");
+ 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
[U-Boot] [PATCH] sunxi: clock: Set AHB1 clock frequency to 200MHz on Allwinner H3
The 3.4 kernel from the Allwinner SDK is clocking AHB1 at 200MHz
on Allwinner H3 and using PLL6 as the clock source (PLL6/3).
This can be verified by reading the value of the AHB1_APB1_CFG_REG
register via /dev/mem. It always reads as 0x3180 regardless of
the current cpufreq operating point. So this configuration should
be safe for use in U-Boot too.
PLL6 also needs to be configured before it is used as the clock
source, according to the "CCU / Programming Guidelines" section
of the Allwinner manual.
The current low AHB1 clock speed is limiting the USB transfer
speed when booting 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 is likely using the same 200MHz AHB1 setup:
https://github.com/allwinner-zh/bootloader/blob/e5ceeca21188/basic_loader/bsp/bsp_for_a83/common/common.c#L101
I can successfully boot my A31s based tablet with 200MHz AHB1 clock
speed too. And this also speeds up FEL USB transfers. However I can't
check what kind of AHB1 configuration is used by the Android firmware
without rooting it first, which I wouldn't do at the moment.
arch/arm/cpu/armv7/sunxi/clock_sun6i.c| 6 --
arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 7 ++-
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/clock_sun6i.c
b/arch/arm/cpu/armv7/sunxi/clock_sun6i.c
index 3ab3b31..916ee48 100644
--- a/arch/arm/cpu/armv7/sunxi/clock_sun6i.c
+++ b/arch/arm/cpu/armv7/sunxi/clock_sun6i.c
@@ -34,9 +34,11 @@ void clock_init_safe(void)
clock_set_pll1(40800);
- writel(AHB1_ABP1_DIV_DEFAULT, &ccm->ahb1_apb1_div);
-
writel(PLL6_CFG_DEFAULT, &ccm->pll6_cfg);
+ while (!(readl(&ccm->pll6_cfg) & CCM_PLL6_CTRL_LOCK))
+ ;
+
+ writel(AHB1_ABP1_DIV_DEFAULT, &ccm->ahb1_apb1_div);
writel(MBUS_CLK_DEFAULT, &ccm->mbus0_clk_cfg);
writel(MBUS_CLK_DEFAULT, &ccm->mbus1_clk_cfg);
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
index 584d351..09337a1 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
@@ -201,6 +201,7 @@ struct sunxi_ccm_reg {
#define CCM_PLL6_CTRL_N_MASK (0x1f << CCM_PLL6_CTRL_N_SHIFT)
#define CCM_PLL6_CTRL_K_SHIFT 4
#define CCM_PLL6_CTRL_K_MASK (0x3 << CCM_PLL6_CTRL_K_SHIFT)
+#define CCM_PLL6_CTRL_LOCK (1 << 28)
#define CCM_MIPI_PLL_CTRL_M_SHIFT 0
#define CCM_MIPI_PLL_CTRL_M_MASK (0xf << CCM_MIPI_PLL_CTRL_M_SHIFT)
@@ -219,7 +220,11 @@ struct sunxi_ccm_reg {
#define CCM_PLL11_CTRL_UPD (0x1 << 30)
#define CCM_PLL11_CTRL_EN (0x1 << 31)
-#define AHB1_ABP1_DIV_DEFAULT 0x2020
+#if defined CONFIG_MACH_SUN8I_H3
+#define AHB1_ABP1_DIV_DEFAULT 0x3180 /* AHB1=PLL6/3,APB1=AHB1/2 */
+#else
+#define AHB1_ABP1_DIV_DEFAULT 0x2020 /* AHB1=AXI/4, APB1=AHB1/2 */
+#endif
#define AXI_GATE_OFFSET_DRAM 0
--
2.4.10
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Enable DFU for RAM on Allwinner devices
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 Siamashka wrote: > > > > Hello, > > > > > > > > DFU allows to transfer large files (such as initrd images) much > > > > faster than FEL. > > > > > > > > Siarhei Siamashka (2): > > > > sunxi: Enable DFU for RAM > > > > musb: sunxi: Implement dfu_usb_get_reset() > > > > > > > > drivers/usb/musb-new/sunxi.c | 12 > > > > include/configs/sunxi-common.h | 30 +- > > > > 2 files changed, 37 insertions(+), 5 deletions(-) > > > > > > Siarhei, > > > can you give some pointers how to test those patches. I have > > > A20-OLinuXino-Micro and Cubietruck and would be glad to give them a try. > > > > Hello, > > > > I tried to provide some basic usage instructions as a part of > > the commit message: > > https://patchwork.ozlabs.org/patch/535535/ > > > > Hi Siarhei, > unfortunately I'm not able to compile even clean master with enabled > CONFIG_USB_MUSB_GADGET. I'm using Linaro toolchain and get this error: > > arm-linux-gnueabihf-ld.bfd: error: > /home/pietrushnic/storage/wdc/projects/3mdeb/cubietruck/toolchains/gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/4.9.3/libgcc.a(_udivmoddi4.o) > uses VFP register arguments, u-boot does not > arm-linux-gnueabihf-ld.bfd: failed to merge target specific data of file > /home/pietrushnic/storage/wdc/projects/3mdeb/cubietruck/toolchains/gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/4.9.3/libgcc.a(_udivmoddi4.o) > Makefile:1183: recipe for target 'u-boot' failed > make: *** [u-boot] Error 1 [...] > My steps: > make CROSS_COMPILE=arm-linux-gnueabihf- Cubietruck_defconfig > make CROSS_COMPILE=arm-linux-gnueabihf- menuconfig > # enable CONFIG_USB_MUSB_GADGET > make CROSS_COMPILE=arm-linux-gnueabihf- -j$(nproc) > > Any idea how to narrow VFP problem ? Thanks for reporting this. I have also confirmed the problem with a hardfloat toolchain and just sent a patch: https://patchwork.ozlabs.org/patch/537185/ Debugging this involved just checking all the symbols in the object files generated by a softfloat toolchain (it does not fail), then filtering out all the symbols which also exist in a successful hardfloat build (with fastboot config options disabled) and comparing the remaining symbols with libgcc.a The culprit was "__aeabi_uldivmod". > > But you also need the "sunxi: cubietruck: Enable the USB OTG > > controller" patch from Maxime Ripard to enable USB OTG on the > > Cubietruck: > > https://patchwork.ozlabs.org/patch/530656/ > > > > Cannot apply this series to master cleanly. Should I try different tree ? This whole series is not needed if you are only interested in DFU. We just need to ensure that USB OTG is eventually enabled on all sunxi boards (and also properly handles the ID pin to switch between the device and host roles). -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc: Use lldiv() for 64-bit division in write_raw_image()
This fixes compilation problems when using a hardfloat toolchain on
ARM, which manifest themselves as "libgcc.a(_udivmoddi4.o) uses
VFP register arguments, u-boot does not".
These problems have been reported in the U-Boot mailing list:
http://lists.denx.de/pipermail/u-boot/2015-October/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 changed, 2 insertions(+), 1 deletion(-)
diff --git a/common/fb_mmc.c b/common/fb_mmc.c
index 0c48cf9..f424bb8 100644
--- a/common/fb_mmc.c
+++ b/common/fb_mmc.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#ifndef CONFIG_FASTBOOT_GPT_NAME
#define CONFIG_FASTBOOT_GPT_NAME GPT_ENTRY_NAME
@@ -64,7 +65,7 @@ static void write_raw_image(block_dev_desc_t *dev_desc,
disk_partition_t *info,
/* determine number of blocks to write */
blkcnt = ((download_bytes + (info->blksz - 1)) & ~(info->blksz - 1));
- blkcnt = blkcnt / info->blksz;
+ blkcnt = lldiv(blkcnt, info->blksz);
if (blkcnt > info->size) {
error("too large for partition: '%s'\n", part_name);
--
2.4.10
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Enable DFU for RAM on Allwinner devices
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 Siamashka (2):
> > sunxi: Enable DFU for RAM
> > musb: sunxi: Implement dfu_usb_get_reset()
> >
> > drivers/usb/musb-new/sunxi.c | 12
> > include/configs/sunxi-common.h | 30 +-
> > 2 files changed, 37 insertions(+), 5 deletions(-)
>
> Siarhei,
> can you give some pointers how to test those patches. I have
> A20-OLinuXino-Micro and Cubietruck and would be glad to give them a try.
Hello,
I tried to provide some basic usage instructions as a part of
the commit message:
https://patchwork.ozlabs.org/patch/535535/
But you also need the "sunxi: cubietruck: Enable the USB OTG
controller" patch from Maxime Ripard to enable USB OTG on the
Cubietruck:
https://patchwork.ozlabs.org/patch/530656/
> I think it would be interested to combine this method with Boris NAND support
> and get much better solution then {Live,Phoenix}Suit.
At this stage I'm only interested in the DFU usage as a speed
booster for FEL. Booting over USB via FEL allows us to temporarily
run more or less complete system (kernel and rootfs on ramdisk)
on any Allwinner device without modifying existing pre-installed
software on non-volatile storage. This already works fine, but
we were not quite happy about the data transfer speed.
If you are interested in flashing NAND, then you can probably
have a look at the recent fastboot patches from Maxime.
DFU means "Device Firmware Upgrade" and it can be also used for
flashing NAND or writing images to SD cards over USB (if we
hook up this part of the DFU functionality). The main question
is how many alternative NAND flashing methods do we need?
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
