Re: [U-Boot] [PATCH] board: amlogic: document alternative libretech-cc installation methods
On Tue, Aug 6, 2019 at 4:31 PM Remi Pommarel wrote: > I don't know if it worth being mentioned here, but there is also a > reverse engineered effort on bl31 for gxl. > > Thus it should be possible to use a bl31 built from mainline branch of > https://github.com/ARM-software/arm-trusted-firmware. That's really cool! I think I'll leave it for another day though, and leave this patch just about the alternative/easier installation of the existing blobs. Separately, it would be great to have an arm-trusted-firmware release that includes this new gxl work so that distros like Debian pick it up. Daniel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] board: amlogic: document alternative libretech-cc installation methods
As already documented in this README, several binaries must be glued together in order to boot the device. Extend the documentation to cover the prebuilt binaries (saving you the hassle of installing ancient cross-compilers), and also mention the open source replacements for the encryption tool (which is especially useful if you want to avoid requiring 32-bit x86 binaries in your build system). Signed-off-by: Daniel Drake Cc: Neil Armstrong --- board/amlogic/p212/README.libretech-cc | 41 +++--- 1 file changed, 37 insertions(+), 4 deletions(-) diff --git a/board/amlogic/p212/README.libretech-cc b/board/amlogic/p212/README.libretech-cc index d007f58764..6af7de3cfa 100644 --- a/board/amlogic/p212/README.libretech-cc +++ b/board/amlogic/p212/README.libretech-cc @@ -38,9 +38,28 @@ U-Boot compilation Image creation == -Amlogic doesn't provide sources for the firmware and for tools needed -to create the bootloader image, so it is necessary to obtain them from -the git tree published by the board vendor: +To boot the system, u-boot must be combined with several earlier stage +bootloaders: + +* bl2.bin: vendor-provided binary blob +* bl21.bin: built from vendor u-boot source +* bl30.bin: vendor-provided binary blob +* bl301.bin: built from vendor u-boot source +* bl31.bin: vendor-provided binary blob +* acs.bin: built from vendor u-boot source + +These binaries and the tools required below have been collected and prebuilt +for convenience at <https://github.com/BayLibre/u-boot/releases/> + +Download and extract the libretech-cc release from there, and set FIPDIR to +point to the `fip` subdirectory. + + > export FIPDIR=/path/to/extracted/fip + +Alternatively, you can obtain the original vendor u-boot tree which +contains the required blobs and sources, and build yourself. +Note that old compilers are required for this to build. The compilers here +are suggested by Amlogic, and they are 32-bit x86 binaries. > wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz > wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz @@ -53,7 +72,10 @@ the git tree published by the board vendor: > make > export FIPDIR=$PWD/fip -Go back to mainline U-Boot source tree then : +Once you have the binaries available (either through the prebuilt download, +or having built the vendor u-boot yourself), you can then proceed to glue +everything together. Go back to mainline U-Boot source tree then : + > mkdir fip > cp $FIPDIR/gxl/bl2.bin fip/ @@ -100,3 +122,14 @@ and then write the image to SD with: > DEV=/dev/your_sd_device > dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1 > dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444 + +Note that Amlogic provides aml_encrypt_gxl as a 32-bit x86 binary with no +source code. Should you prefer to avoid that, there are open source reverse +engineered versions available: + +1. gxlimg <https://github.com/repk/gxlimg>, which comes with a handy + Makefile that automates the whole process. +2. meson-tools <https://github.com/afaerber/meson-tools> + +However, these community-developed alternatives are not endorsed by or +supported by Amlogic. -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ODROID dynamic memory initialization
On Tue, Jul 22, 2014 at 2:08 PM, Daniel Drake dr...@endlessm.com wrote: While looking at the old uboot from hardkernel, I'm curious about CONFIG_CLK_BUS_DMC_220_440, which is set by default. This appears to run the memory at a high speed, by writing certain registers in the Dynamic Memory Controller (e.g. TIMINGROW), and clocking MPLL to 880MHz. Your uboot patches don't seem to touch DMC regs like TIMINGROW, and also clock the MPLL at 800MHz. I looked in more detail, and now understand better the SPL vs uboot division. The vendor code I was referring to above is SPL code. Since we are still using the same SPL as before, it means that MPLL and memory is already set up by the time the real/new uboot loads. So I think there should be no need to modify MPLL, and I wonder if most of the other clock configuration code in your patches is also unnecessary. Thoughts? Thanks Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ODROID dynamic memory initialization
Hi Przemyslaw, While looking at the old uboot from hardkernel, I'm curious about CONFIG_CLK_BUS_DMC_220_440, which is set by default. This appears to run the memory at a high speed, by writing certain registers in the Dynamic Memory Controller (e.g. TIMINGROW), and clocking MPLL to 880MHz. Your uboot patches don't seem to touch DMC regs like TIMINGROW, and also clock the MPLL at 800MHz. I'm wondering if there is any reason for this? Wouldn't it be better to run at the faster speed like the vendor code does? Thanks Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] uboot/odroid test report
Hi, Thanks a lot for working on getting ODROID support upstream in uboot. I'm testing with v4 of your patches on uboot 2014.07 and ODROID-U2. I'd like to understand the SPL/BL2 situation a bit better. README.odroid says that we should use the blob from hardkernel. However, as far as I can see, this blob is generated by taking the first 14kb of hardkernel's u-boot.bin from 2012 and signing it. So, the suggestion of using hardkernel's bl2 (which I am following) seems odd. That means we run some early code from hardkernel's 2012 uboot and then magically jump into uboot-2014.07? That sounds fragile, unless this magic 14kb division is somehow represented in the output uboot binary too? I'm also curious that these patches run the SoC at 1000MHz. Isn't the SoC on these boards clocked at 1.7GHz? Does this 1000MHz carry over into Linux once booted, or does Linux re-clock it at a faster speed? Onto the testing - uboot loads and detects my u2 as a u3 (good). Booting into Linux, works but not quite - loads of memory corruption is detected during early boot. Easiest way to reproduce this is to take linux-next from today, then: # make exynos_defconfig Now enable CONFIG_DEBUG_PAGEALLOC and CONFIG_BLK_DEV_DRBD. Boot with exynos4412-odroidu3.dtb from the same kernel tree. During boot this happens: 1380.serial: ttySAC0 at MMIO 0x1380 (irq = 84, base_baud = 0) is a S3C6400/10 1381.serial: ttySAC1 at MMIO 0x1381 (irq = 85, base_baud = 0) is a S3C6400/10 console [ttySAC1] enabled brd: module loaded loop: module loaded pagealloc: memory corruption ffc1: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffc10010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 snip long memory dump CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.16.0-rc5-next-20140716-dirty #310 [c0013f14] (unwind_backtrace) from [c00111f8] (show_stack+0x10/0x14) [c00111f8] (show_stack) from [c043c938] (dump_stack+0x80/0xc0) [c043c938] (dump_stack) from [c00b5314] (kernel_map_pages+0x18c/0x1a0) [c00b5314] (kernel_map_pages) from [c0086134] (get_page_from_freelist.isra.73+0x27c/0x5d0) [c0086134] (get_page_from_freelist.isra.73) from [c0086f8c] (__alloc_pages_nodemask+0x128/0x978) [c0086f8c] (__alloc_pages_nodemask) from [c05f1c28] (drbd_init+0x278/0x418) [c05f1c28] (drbd_init) from [c00088b0] (do_one_initcall+0x8c/0x1c4) I don't think this is a DRBD problem because: - same kernel binary works on hardkernel uboot - with my actual product kernel, with DRBD disabled, I still get a load of memory corruption during early boot coming from other areas Any ideas? Can you reproduce? Thanks! Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] uboot/odroid test report
On Thu, Jul 17, 2014 at 2:00 PM, Marek Szyprowski m.szyprow...@samsung.com wrote: Frankly right now I'm using the bl1, bl2 and secure firmware which came on eMMC together with my Odroid (I've just replaced uboot with fastload flasher). We will check if binaries differ from those linked by Przemyslaw. They probably don't. The only idea I have is that V4 of uboot patches reported whole 2GiB of memory, while the last 1MiB is not really accessible. Although I've fixed total memory in DTS files, but similar fixes are needed in ATAGS passed from uboot to kernel. Not sure if this would be expected even in that case, but it also reproduces with mem=256m passed as a kernel arg. Przemyslaw will send updated v5 patches soon. Great! Please CC me. Thanks Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] uboot/odroid test report
On Thu, Jul 17, 2014 at 2:20 PM, Daniel Drake dr...@endlessm.com wrote: On Thu, Jul 17, 2014 at 2:00 PM, Marek Szyprowski m.szyprow...@samsung.com wrote: Frankly right now I'm using the bl1, bl2 and secure firmware which came on eMMC together with my Odroid (I've just replaced uboot with fastload flasher). We will check if binaries differ from those linked by Przemyslaw. They probably don't. The only idea I have is that V4 of uboot patches reported whole 2GiB of memory, while the last 1MiB is not really accessible. Although I've fixed total memory in DTS files, but similar fixes are needed in ATAGS passed from uboot to kernel. Not sure if this would be expected even in that case, but it also reproduces with mem=256m passed as a kernel arg. Przemyslaw will send updated v5 patches soon. Great! Please CC me. Thanks Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] uboot/odroid test report
Hi, Sorry for last blank mail. On Thu, Jul 17, 2014 at 2:20 PM, Daniel Drake dr...@endlessm.com wrote: Not sure if this would be expected even in that case, but it also reproduces with mem=256m passed as a kernel arg. With v5 there are no more corruption errors, thanks! I'm getting some new errors though, and my initramfs fails to switch to real root, I'll get back to you with more details if this is something other than a problem this side. Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] uboot/odroid test report
On Thu, Jul 17, 2014 at 2:38 PM, Daniel Drake dr...@endlessm.com wrote:
I'm getting some new errors though, and my initramfs fails to switch
to real root, I'll get back to you with more details if this is
something other than a problem this side.
Silly error this side. Now things are fine. Thanks, great work!
I'm still curious to understand how this SPL/BL2 thing works, given
that with our setup it is basically running the first 14kb of an old
uboot version during early boot? If either of you know..
Also, I didn't manage to get the initramfs to be loaded in the v5
patch, which does:
setenv image_addr ${kerneladdr} - ${fdtaddr}
bootz ${image_addr} ${ramdisk_addr}
Guessing, but I think the problem here is that we end up passing 4
args to bootz, which is not how it is documented. Instead the ramdisk
addr should be passed where the - is in image_addr.
Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] uboot/odroid test report
On Thu, Jul 17, 2014 at 3:59 PM, Przemyslaw Marczak
p.marc...@samsung.com wrote:
So BL1, BL2 are running in iRAM(required small size), and u-boot is running
from a RAM.
The main reason for using existing BL1 and BL2 binaries is
that bl1 and bl2 are just working proper.
Fair enough, I was just a bit worried/curious that bl2 is only working
by accident, and we have some strange mashup of 2 uboot versions
involved in the boot process.
I will check it tomorrow but it has works on Ubuntu.
The bootz command takes only 2 arguments here - ${image_addr}
${ramdisk_addr} which are the numbers set by:
run check_dtb and run check_ramdisk
Maybe I made a mistake in my testing then, either way I've moved onto
a custom boot script now.
But just to clarify the bootz usage..
image_addr is defined as:
setenv image_addr ${kerneladdr} - ${fdtaddr};
so with
bootz ${image_addr} ${ramdisk_addr};
you are actually passing
bootz ${kerneladdr} - ${fdtaddr} ${ramdisk_addr};
Maybe it works for you, although the documentation suggests its usage
is not quite like that:
static char bootz_help_text[] =
[addr [initrd[:size]] [fdt]]\n
- boot Linux zImage stored in memory\n
\tThe argument 'initrd' is optional and specifies the address\n
\tof the initrd in memory. The optional argument ':size' allows\n
\tspecifying the size of RAW initrd.\n
#if defined(CONFIG_OF_LIBFDT)
\tWhen booting a Linux kernel which requires a flat device-tree\n
\ta third argument is required which is the address of the\n
\tdevice-tree blob. To boot that kernel without an initrd image,\n
\tuse a '-' for the second argument. If you do not pass a third\n
\ta bd_info struct will be passed instead\n
#endif
;
#endif
Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
