[U-Boot] [PATCH 2/2] buildman: Don't default to -e when building current source
We probably don't need to enable this option by default. It is useful to display only failure boards (not errors) and it is easy to add -e if it is required. Also update the docs. Signed-off-by: Simon Glass s...@chromium.org Reported-by: Albert Aribaud albert.u.b...@aribaud.net --- tools/buildman/README | 25 - tools/buildman/control.py | 1 - 2 files changed, 12 insertions(+), 14 deletions(-) diff --git a/tools/buildman/README b/tools/buildman/README index 8ba19ec..bfb2f18 100644 --- a/tools/buildman/README +++ b/tools/buildman/README @@ -85,10 +85,10 @@ branch. Put all your commits in a branch, set the branch's upstream to a valid value, and all will be well. Otherwise buildman will perform random actions. Use -n to check what the random actions might be. -If you just want to build the current source tree, leave off the -b flag. -This will display results and errors as they happen. You can still look -at them later using -s. Note that buildman will assume that the source -has changed, and will build all specified boards in this case. +If you just want to build the current source tree, leave off the -b flag +and add -e. This will display results and errors as they happen. You can +still look at them later using -se. Note that buildman will assume that the +source has changed, and will build all specified boards in this case. Buildman is optimised for building many commits at once, for many boards. On multi-core machines, Buildman is fast because it uses most of the @@ -693,9 +693,9 @@ Quick Sanity Check == If you have made changes and want to do a quick sanity check of the -currently-checked-out source, run buildman without the -b flag. This will -build the selected boards and display build status and errors as it runs -(i.e. -v amd -e are enabled automatically). +currently checked-out source, run buildman without the -b flag. This will +build the selected boards and display build status as it runs (i.e. -v is +enabled automatically). Use -e to see errors/warnings as well. Other options @@ -752,7 +752,7 @@ an error and green indicating that a commit fixed an error. Use the -e flag to see the full errors and -l to see which boards caused which errors. If you really want to see build results as they happen, use -v when doing a -build (-e will be enabled automatically). +build (and -e to see the errors/warnings too). You don't need to stick around on that branch while buildman is running. It checks out its own copy of the source code, so you can change branches, @@ -816,11 +816,10 @@ TODO This has mostly be written in my spare time as a response to my difficulties in testing large series of patches. Apart from tidying up there is quite a -bit of scope for improvement. Things like better error diffs, easier access -to log files, error display while building. Also it would be nice it buildman -could 'hunt' for problems, perhaps by building a few boards for each arch, -or checking commits for changed files and building only boards which use -those files. +bit of scope for improvement. Things like better error diffs and easier +access to log files. Also it would be nice it buildman could 'hunt' for +problems, perhaps by building a few boards for each arch, or checking +commits for changed files and building only boards which use those files. Credits diff --git a/tools/buildman/control.py b/tools/buildman/control.py index 8b8c826..c8dc217 100644 --- a/tools/buildman/control.py +++ b/tools/buildman/control.py @@ -188,7 +188,6 @@ def DoBuildman(options, args, toolchains=None, make_func=None, boards=None, else: series = None options.verbose = True -options.show_errors = True # By default we have one thread per CPU. But if there are not enough jobs # we can have fewer threads and use a high '-j' value for make. -- 2.1.0.rc2.206.gedb03e5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] buildman: Fix repeating board list with -l
Ensure that we don't print duplicate board names when -l is used. Signed-off-by: Simon Glass s...@chromium.org Reported-by: Albert Aribaud albert.u.b...@aribaud.net --- tools/buildman/builder.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py index 8155c16..7002034 100644 --- a/tools/buildman/builder.py +++ b/tools/buildman/builder.py @@ -918,7 +918,8 @@ class Builder: if self._list_error_boards: names = [] for board in line_boards[line]: -names.append(board.target) +if not board.target in names: +names.append(board.target) names_str = '(%s) ' % ','.join(names) else: names_str = '' -- 2.1.0.rc2.206.gedb03e5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] x86: Fix rom version build with CONFIG_X86_RESET_VECTOR
When building U-Boot with CONFIG_X86_RESET_VECTOR, the linking process misses the resetvec.o and start16.o so it cannot generate the rom version of U-Boot. The top level Makefile is updated to pull them into the final linking process. Signed-off-by: Bin Meng bmeng...@gmail.com --- Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile b/Makefile index 8657417..b23a3a1 100644 --- a/Makefile +++ b/Makefile @@ -598,6 +598,7 @@ c_flags := $(KBUILD_CFLAGS) $(cpp_flags) head-y := $(CPUDIR)/start.o head-$(CONFIG_4xx) += arch/powerpc/cpu/ppc4xx/resetvec.o head-$(CONFIG_MPC85xx) += arch/powerpc/cpu/mpc85xx/resetvec.o +head-$(CONFIG_X86_RESET_VECTOR) += arch/x86/cpu/resetvec.o arch/x86/cpu/start16.o HAVE_VENDOR_COMMON_LIB = $(if $(wildcard $(srctree)/board/$(VENDOR)/common/Makefile),y,n) -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] x86: Fix GDT limit in start16.S
GDT limit should be one less than an integral multiple of eight. Signed-off-by: Bin Meng bmeng...@gmail.com --- arch/x86/cpu/start16.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/cpu/start16.S b/arch/x86/cpu/start16.S index 8b9b327..6968fda 100644 --- a/arch/x86/cpu/start16.S +++ b/arch/x86/cpu/start16.S @@ -70,7 +70,7 @@ idt_ptr: * GDT is setup in a safe location in RAM */ gdt_ptr: - .word 0x20/* limit (32 bytes = 4 GDT entries) */ + .word 0x1f/* limit (31 bytes = 4 GDT entries - 1) */ .long BOOT_SEG + gdt /* base */ /* Some CPUs are picky about GDT alignment... */ -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert sunxi: dram: Use divisor P=1 for PLL5
Hi, On 10/15/2014 12:34 PM, Siarhei Siamashka wrote: On Wed, 15 Oct 2014 12:12:11 +0200 Hans de Goede hdego...@redhat.com wrote: This change breaks various hardcoded assumptions in the linux-sunxi-3.4 kernels, causing a divide by 0 error in the linux-sunxi-3.4 nand driver, rendering 3.4 kernels unbootable. Besides this problem, it also breaks LCD output (on devices without nand). Fixes for these issues are being added to the linux-sunxi-3.4 kernel, but for now it seems better to revert this. This reverts commit 013f2d746955147439215a4939655c9ed6bdd866. As mentioned in the commit message https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg07884.html the hardcoded assumptions in the sunxi-3.4 kernel are still bad with or without this revert if somebody tries to use higher DRAM clock speeds. The patch in question just smokes out bugs, which are otherwise still there. Going forward, the mainline kernel needs the G2D driver and it needs to run at a decent clock speed to be provide reasonable performance. Low PLL5P clock speed is limiting our options. This revert does not do anyone any favour and only postpones the resolution of the problem. I agree that we need to fix the linux-sunxi-3.4 kernels to work properly with different pll5 settings, which is why I've actually send a fix for some pll5 issues to the linux-sunxi list and acked your patches which fix other bits. I can understand you want to have optimal settings for the G2D stuff, and I'm not against that. But getting the G2D stuff upstream is something which is still far in the future. I really want people to be able to start using upstream u-boot, starting today. And it will take some time for the sunxi-3.4 fixes to trickle down to users. So for now I believe we really should revert the PLL5 u-boot changes as they break some kernels from booting. Then once getting G2D support upstream really comes into the picture (e.g. upstream kernel patches are posted and being reviewed), then we can talk about re-applying the PLL5 changes, but for now I believe that reverting them is best. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: Add CONFIG_MACH_TYPE defines to sun4i, sun5i and sun7i
Hi, On 10/15/2014 12:48 PM, Siarhei Siamashka wrote: On Mon, 13 Oct 2014 14:55:35 +0200 Hans de Goede hdego...@redhat.com wrote: Many people are still using old linux-sunxi-3.4 kernels on sunxi devices, adding the proper MACH_TYPE defines for this allows people to switch to upstream u-boot, so that we can stop maintaining the linux-sunxi u-boot fork. These machine-ids are all properly registered at: http://www.arm.linux.org.uk/developer/machines/ Signed-off-by: Hans de Goede hdego...@redhat.com --- include/configs/sun4i.h | 1 + include/configs/sun5i.h | 1 + include/configs/sun7i.h | 1 + 3 files changed, 3 insertions(+) diff --git a/include/configs/sun4i.h b/include/configs/sun4i.h index 5611ecc..d0191a3 100644 --- a/include/configs/sun4i.h +++ b/include/configs/sun4i.h @@ -15,6 +15,7 @@ #define CONFIG_CLK_FULL_SPEED 100800 #define CONFIG_SYS_PROMPT sun4i# +#define CONFIG_MACH_TYPE4104 #ifdef CONFIG_USB_EHCI #define CONFIG_USB_EHCI_SUNXI diff --git a/include/configs/sun5i.h b/include/configs/sun5i.h index 6066371..7b683e9 100644 --- a/include/configs/sun5i.h +++ b/include/configs/sun5i.h @@ -15,6 +15,7 @@ #define CONFIG_CLK_FULL_SPEED 100800 #define CONFIG_SYS_PROMPT sun5i# +#define CONFIG_MACH_TYPE4138 #ifdef CONFIG_USB_EHCI #define CONFIG_USB_EHCI_SUNXI diff --git a/include/configs/sun7i.h b/include/configs/sun7i.h index a902b84..966cbd8 100644 --- a/include/configs/sun7i.h +++ b/include/configs/sun7i.h @@ -16,6 +16,7 @@ #define CONFIG_CLK_FULL_SPEED 91200 #define CONFIG_SYS_PROMPT sun7i# +#define CONFIG_MACH_TYPE4283 #ifdef CONFIG_USB_EHCI #define CONFIG_USB_EHCI_SUNXI This patch is just trying to remove the safety guards (which exist there for a reason!) without addressing the real compatibility issues. Erm, no the mach_type-s are not safety-guards, they are absolutely necessary to get old non devicetree kernels to work at all. With just this single patch, sunxi-3.4 kernels with fixed PLL5 support, will happily boot on sun4i and sun5i. And with the bootm_boot_mode patch + env setting sun7i will boot fine too. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: Add CONFIG_MACH_TYPE defines to sun4i, sun5i and sun7i
Hello Hans, On 16-10-14 10:50, Hans de Goede wrote: [...] Erm, no the mach_type-s are not safety-guards, they are absolutely necessary to get old non devicetree kernels to work at all. fyi: That is not strictly true, you should be able to do: setenv machid 4283 and it should work as well. Anyway I have no problem with the patch. Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] video: ipo: fix debug and comment
Hi Jeroen, On Tue, 14 Oct 2014 20:37:14 +0200 Jeroen Hofstee jer...@myspectrum.nl wrote: - fix debug pixel clk display and add unit - fix some comments Cc: Stefano Babic sba...@denx.de Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl --- drivers/video/ipu_disp.c | 2 +- drivers/video/mxc_ipuv3_fb.c | 7 +++ 2 files changed, 4 insertions(+), 5 deletions(-) Applied to u-boot-video/master. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] video: ipu_disp: remove pixclk fixup
On Tue, 14 Oct 2014 20:37:15 +0200 Jeroen Hofstee jer...@myspectrum.nl wrote: The ipu display insists on having a lower_margin smaller then 2. If this is not the case it will attempt to force it and adjust the pixclk accordingly. This multiplies pixclk in Hz with the width and height, since this is typically a * 10^7 * b * 10^2 * c * 10^2 this will overflow the uint_32 and make things even worse. Since this is a bootloader and the adjustment is neglectible, just force it to two and warn about it. Cc: Stefano Babic sba...@denx.de Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl --- drivers/video/ipu_disp.c | 31 ++- 1 file changed, 6 insertions(+), 25 deletions(-) Applied to u-boot-video/master. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lcd: Fix build error with CONFIG_LCD_BMP_RLE8
Hi Simon, On Wed, 15 Oct 2014 04:53:04 -0600 Simon Glass s...@chromium.org wrote: Add a block to avoid a build error with the variable declaration. Enable the option on sandbox to prevent an error being introduced in future. Signed-off-by: Simon Glass s...@chromium.org --- common/lcd.c | 4 ++-- include/configs/sandbox.h | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) Applied to u-boot-video/master. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Hi all, Can not start the latest version of uboot on Foundation platform on ARM v8 (vexpress_aemv8a_config)
Hi all This week I downloaded the latest version of U-Boot and tested on ARM v8 platform, My boot environment was based on ARM trusted firmware: arm trusted firmware + Uboot + Linux. Few weeks ago I did the same job on old U-Boot version, and it worked well. I even tried FIT image on old version with verified boot, it also success. I checked my operation steps and configure many times, and I can't find any problem within it. For I still have the old version of U-boot, So I checked the same operation and configures on old version again, it's fine! So I think there may exist some problems with vexpress_aemv8a_config and vexpress_aemv8a_semi_config in the latest version of U-Boot, or my operation need to do some adjustment on new version. Can anyone give me some suggestions? Below is my configure and operations. 1) Build Uboot For arm trusted firmware's default address for BL33(U-boot) 0x8800, so macro CONFIG_SYS_TEXT_BASE which locate in file vexpress_aemv8a.h should be modified from 0x8000 to 0x8800 Compile Uboot as bellow: $cd uboot $make vexpress_aemv8a_config $ make CROSS_COMPILE= all 2) Make uImage $cd linux_kernel_path/arch/arm64/boot $/uboot_path/tools/mkimage -A arm64 -O linux -T kernel -C none -a 0x8008 -e 0x8008 -n 'linux-3.15' -d Image uImage Both load address and link address are 0x8008. 3) Make firmware Package Firmware package includes: bl1.bin/ bl2.bin/ bl31.bin/ bl33.bin(uboot.bin) Set variable BL33 as path/uboot.bin $cd firmware_path $make CROSS_COMPILE=path/bin/aarch64-none-elf- PLAT=fvp BL33=path_bl33/uboot.bin all fip 4) Running system Copy all of the images to a directory and start FVP as $/path_to_fvp/Foundation_v8 \ --cores=4 \ --no-secure-memory\ --visualization \ --gicv3 \ --data=bl1.bin@0x0mailto:--data=bl1.bin@0x0\ --data=fip.bin@0x800mailto:--data=fip.bin@0x800 \ --data=uImage@0x9000 \ --data=ramdisk_file@0xa100 \ --data=fdt.dtb@0xa000mailto:--data=fdt.dtb@0xa000 0x9000 is kernel's address, 0xa000 is device tree dtb's address, and 0xa100 is ramdisk's address, we also need to fill in ramdisk's size Once firmware successfully started, System will stop at uboot's shell environment. But there seems system halted before enter Uboot. Logs as below: Connected to localhost. Escape character is '^]'. NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.0(release): NOTICE: BL1: Built : 16:00:48, Oct 16 2014 NOTICE: BL1: Booting BL2 NOTICE: BL2: v1.0(release): NOTICE: BL2: Built : 16:00:49, Oct 16 2014 NOTICE: BL1: Booting BL3-1 NOTICE: BL3-1: v1.0(release): NOTICE: BL3-1: Built : 16:00:51, Oct 16 2014 System stopped here, may not enter Uboot. Thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot Sunxi breaks LCD output on Olimex Lime A10
On Fri, 03 Oct 2014 11:19:47 +0200 Hans de Goede hdego...@redhat.com wrote: Hi, On 10/03/2014 10:49 AM, Siarhei Siamashka wrote: On Fri, 03 Oct 2014 10:04:29 +0200 Hans de Goede hdego...@redhat.com wrote: Hi, On 10/01/2014 07:43 PM, Hendrik wrote: I have always been using the sunxi u-boot from 'https://github.com/linux-sunxi/u-boot-sunxi' and that works fine, but now I want to boot the kernel from USB. That is not possible in that u-boot branch. Therefore I switched to the latest U-Boot 'git://git.denx.de/u-boot.git' for the Olimex Allwinner A10 Lime as this one does have a working USB mass storage implementation. But when the kernel and root filesystem is booted and my application (using DirectFB) starts, the LCD screen is flickering between a correct image and an incorrect image as if sometimes random image data is displayed to the screen. Although it looks more like a clock or timing issue because the colors of the faulty screen resemble the colors of the correct screen. Also: when the cpu is inactive the screen is more or less ok but when doing a lot of work the screen starts to flicker. Then it is stable for a while and after some time it starts flickering again. I am using the exact same kernel, root filesystem, U-boot environment, SD-card and 'script.bin' (which defines the hardware layout, I am not using a device tree file). The only difference is the version (and origin) of U-boot. Can anybody shine some light on this? Maybe Hans de Goede? I have seen his name pop-up a lot of times with the Sunxi branch. Hmm, the only thing I can think of which may have caused this are the recent DRAM controller code cleanups which are in upstream u-boot and not in https://github.com/linux-sunxi/u-boot-sunxi Can you try copying these 2 files: arch/arm/cpu/armv7/sunxi/dram.c arch/arm/include/asm/arch-sunxi/dram.h From https://github.com/linux-sunxi/u-boot-sunxi over into upstream u-boot, essentially reverting the DRAM cleanup patches, and see if that fixes things ? It is most definitely the PLL5P clock speed problem and it can be resolved by either reverting the following patch in u-boot http://git.denx.de/?p=u-boot.git;a=commit;h=013f2d746955147439215a4939655c9ed6bdd866 or by fixing a bunch of hardcoded divisors in the sunxi-3.4 kernel (for which I'll send a patch to the linux-sunxi mailing list later today). Thanks, that is good to know. I'm tempted to revert that patch then for now. I say tempted, as I'm not 100% sure on this. I do want mainline u-boot to work eventually with the sunxi-3.4, so that we can stop maintaining https://github.com/linux-sunxi/u-boot-sunxi There is no real need to maintain u-boot in this repository since a long time ago. Just please don't fix something that is not broken. And also don't break it unnecessarily by pushing there some unreviewed submarine patches and doing reckless merges. But this will requires some sunxi-3.4 kernel changes for A20 anyways, so if you've a sunxi-3.4 patch fixing things, then maybe Please note that you can't use the sunxi-3.4 kernel with the unmodified mainline u-boot anyway because of the missing machine id definitions and the new PSCI code (but this is a problem only on Allwinner A20 hardware). A few minor patches are needed here and there. Right, I plan to fix the missing machine ids ASAP, we did not add them because we thought they were not properly registered, but I've checked and they actually are properly registered. I welcome a patch adding them, and unless someone beats me to it I hope to write one myself real soon. With the machine ids added upstream u-boot will work fine for sun4i and sun5i with existing sunxi-3.4 kernels, which is why I'm tempted to revert the commit you mention above if that breaks that (in some scenarios). The (missing) machine id acts as a safety guard and prevents loading incompatible kernel. But as soon as you add the machine id, the users will assume that any old kernel is supposed to be supported the u-boot will effectively have to be compatible with old bugs. This is not a very nice situation, but there are a few possible scenarios: 1) A bureaucratic way. Try to register a new set of machine identifiers, something like sun4i_v2, sun5i_v2, sun7i_v2. Then patch the sunxi-3.4 kernel to support both old and new machine identifiers, so that both old u-boot-sunxi and the mainline u-boot can be used with the updated kernels. But the old kernels will refuse to load from the mainline u-boot. There is already a garbage (?) entry in the machine id database, a few more would not hurt too much: 3931 AllWinner A1x Developer Board lichee_sun4i_devbd 2) A hackish way. Similar to 1), but don't register anything. Just treat a few high bits of the machine id as some kind of a version number. So the current machine ids have version 0, the next set can have version 1 and so
Re: [U-Boot] [PATCH 01/10] video: Add S3C24xx framebuffer support
Hi Marek, On Sat, 11 Oct 2014 18:42:49 +0200 Marek Vasut ma...@denx.de wrote: Add basic framebuffer driver for the S3C24xx family of CPUs. Signed-off-by: Marek Vasut ma...@denx.de Cc: Anatolij Gustschin ag...@denx.de Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Lukasz Majewski l.majew...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com Cc: Vladimir Zapolskiy v...@mleia.com V2: Keep the Makefile sorted. --- drivers/video/Makefile | 1 + drivers/video/cfb_console.c | 2 +- drivers/video/s3c-fb.c | 172 3 files changed, 174 insertions(+), 1 deletion(-) create mode 100644 drivers/video/s3c-fb.c Acked-by: Anatolij Gustschin ag...@denx.de Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: bootm: Allow booting in secure mode on hyp capable systems
Hi, On Oct. 15, 2014, 10:25 a.m., Albert ARIBAUD wrote: Hi Marc, Hans, On Wed, 15 Oct 2014 11:18:28 +0100, Marc Zyngier marc.zyng...@arm.com wrote: On Wed, Oct 15 2014 at 11:13:05 AM, Hans de Goede hdego...@redhat.com wrote: Older Linux kernels will not properly boot in hype mode, add support for a bootm_boot_mode environment variable, which when set to sec will cause u-boot to boot in secure mode even when build with non-sec (and hyp) support. Signed-off-by: Hans de Goede hdego...@redhat.com Looks good to me. Acked-by: Marc Zyngier marc.zyng...@arm.com M. Should we consider this a bugfix? This is not really a bug fix, this adds a mechanism to select between secure / non secure boot on non-secure boot capable systems, as some older kernels do not work in non-secure mode. Even with this in place old (broken) kernels will still not magically work. Some sunxi specific patches are needed for that, as well as the user actually setting the environment variable. I'm targetting the next u-boot release for getting old sunxi kernels to work for people who prefer using those kernels. For instance, hHow old are these older kernels? The linux-sunxi kernel I'm specifically targetting is a 3.4 kernel, but this should be useful in general on all platforms which support booting in non-secure mode. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert sunxi: dram: Use divisor P=1 for PLL5
On Thu, 2014-10-16 at 10:48 +0200, Hans de Goede wrote: So for now I believe we really should revert the PLL5 u-boot changes as they break some kernels from booting. This seems reasonable to me. Acked-by: Ian Campbell i...@hellion.org.uk Then once getting G2D support upstream really comes into the picture (e.g. upstream kernel patches are posted and being reviewed), then we can talk about re-applying the PLL5 changes, but for now I believe that reverting them is best. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert sunxi: dram: Use divisor P=1 for PLL5
On Thu, 16 Oct 2014 10:48:34 +0200 Hans de Goede hdego...@redhat.com wrote: Hi, On 10/15/2014 12:34 PM, Siarhei Siamashka wrote: On Wed, 15 Oct 2014 12:12:11 +0200 Hans de Goede hdego...@redhat.com wrote: This change breaks various hardcoded assumptions in the linux-sunxi-3.4 kernels, causing a divide by 0 error in the linux-sunxi-3.4 nand driver, rendering 3.4 kernels unbootable. Besides this problem, it also breaks LCD output (on devices without nand). Fixes for these issues are being added to the linux-sunxi-3.4 kernel, but for now it seems better to revert this. This reverts commit 013f2d746955147439215a4939655c9ed6bdd866. As mentioned in the commit message https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg07884.html the hardcoded assumptions in the sunxi-3.4 kernel are still bad with or without this revert if somebody tries to use higher DRAM clock speeds. The patch in question just smokes out bugs, which are otherwise still there. Going forward, the mainline kernel needs the G2D driver and it needs to run at a decent clock speed to be provide reasonable performance. Low PLL5P clock speed is limiting our options. This revert does not do anyone any favour and only postpones the resolution of the problem. I agree that we need to fix the linux-sunxi-3.4 kernels to work properly with different pll5 settings, which is why I've actually send a fix for some pll5 issues to the linux-sunxi list and acked your patches which fix other bits. I can understand you want to have optimal settings for the G2D stuff, and I'm not against that. But getting the G2D stuff upstream is something which is still far in the future. The future is happening right now ;-) Luc has implemented the HDMI support in u-boot and ensured that it works with the simplefb driver, providing framebuffer in the mainline kernel. This has code has been available for several months for any geeks, willing to fish out and cherry pick the patches. But right now this needs to be more easily available for the users and developers. The mainline kernel got all the basic essentials and has been ready for the graphics and multimedia since around version 3.16 As anyone can see, the sunxi-3.4 kernel provides a rather rotten foundation. And even though we have a reasonably good support for both proprietary and free reverse engineered drivers with sunxi-3.4, it still makes a lot of sense to get the graphics drivers in the mainline kernel ASAP. I really want people to be able to start using upstream u-boot, starting today. And it will take some time for the sunxi-3.4 fixes to trickle down to users. So for now I believe we really should revert the PLL5 u-boot changes as they break some kernels from booting. Then once getting G2D support upstream really comes into the picture (e.g. upstream kernel patches are posted and being reviewed), then we can talk about re-applying the PLL5 changes, but for now I believe that reverting them is best. You are the boss. We are all free to have our own private branches anyway. -- 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] x86: Fix rom version build with CONFIG_X86_RESET_VECTOR
Hi Bin, On 16 October 2014 10:26, Bin Meng bmeng...@gmail.com wrote: When building U-Boot with CONFIG_X86_RESET_VECTOR, the linking process misses the resetvec.o and start16.o so it cannot generate the rom version of U-Boot. The top level Makefile is updated to pull them into the final linking process. Signed-off-by: Bin Meng bmeng...@gmail.com --- Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile b/Makefile index 8657417..b23a3a1 100644 --- a/Makefile +++ b/Makefile @@ -598,6 +598,7 @@ c_flags := $(KBUILD_CFLAGS) $(cpp_flags) head-y := $(CPUDIR)/start.o head-$(CONFIG_4xx) += arch/powerpc/cpu/ppc4xx/resetvec.o head-$(CONFIG_MPC85xx) += arch/powerpc/cpu/mpc85xx/resetvec.o +head-$(CONFIG_X86_RESET_VECTOR) += arch/x86/cpu/resetvec.o arch/x86/cpu/start16.o Can we please do this in rch/x86/cpu/Makefile instead? Something like: extra-y = start.o obj-$(CONFIG_X86_RESET_VECTOR) += resetvec.o start16.o obj-y += interrupts.o cpu.o obj-$(CONFIG_PCI) += pci.o Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] x86: Fix GDT limit in start16.S
On 16 October 2014 10:26, Bin Meng bmeng...@gmail.com wrote: GDT limit should be one less than an integral multiple of eight. Signed-off-by: Bin Meng bmeng...@gmail.com --- arch/x86/cpu/start16.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/cpu/start16.S b/arch/x86/cpu/start16.S index 8b9b327..6968fda 100644 --- a/arch/x86/cpu/start16.S +++ b/arch/x86/cpu/start16.S @@ -70,7 +70,7 @@ idt_ptr: * GDT is setup in a safe location in RAM */ gdt_ptr: - .word 0x20/* limit (32 bytes = 4 GDT entries) */ + .word 0x1f/* limit (31 bytes = 4 GDT entries - 1) */ .long BOOT_SEG + gdt /* base */ /* Some CPUs are picky about GDT alignment... */ -- 1.8.2.1 Acked-by: Simon Glass s...@chromium.org Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Hi all, Can not start the latest version of uboot on Foundation platform on ARM v8 (vexpress_aemv8a_config)
Dear Duxiaoqiang, In message 1c178fd3e32fb24c8b1881fdcc155d8f8faaa...@szxema502-mbx.china.huawei.com you wrote: This week I downloaded the latest version of U-Boot and tested on ARM v8 platform, My boot environment was based on ARM trusted firmware: arm trusted firmware + Uboot + Linux. What exactly do you mean by latest version? Latest version is v2014.10 = git commit ID c43fd23 Compile Uboot as bellow: $cd uboot $make vexpress_aemv8a_config This does not look like recent code to me. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The software required `Windows 95 or better', so I installed Linux. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot:arm:Boot MLO and U-boot img from nand flash for omap4460
Hi , i interfaced nand flash-(MT29F4G08ABBDAH4-IT) with omap4460. I able to boot uboot and kernel from SD Card. Now, i want boot uboot and kernel from Nand Flash. for that purpose,i copied MLO and u-boot image to Nand partition. but problem is,if i tried boot from nand,it shows that MLO is unknown image type. without sd card ,i am not able to boot from nand. as concern of hardware, processor tries to fetch instruction from nand ,verify using CRO. i want to know. that in which file, i have to change or config for booting for nand. plz help me.. -- Regards, Anand Kumar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] exynos: Enable config_distro_defaults.h
From: Ian Campbell ian.campb...@citrix.com ...and remove explicit setting of things which this implies. This is done for all exynos platforms (4 5) so it is added to exynos-common.h I'm mainly interested in CONFIG_CMD_BOOTZ and CONFIG_SUPPORT_RAW_INITRD I have build tested on all exynos platforms (MAKEALL -s exynos), but only boot tested on arndale. Signed-off-by: Ian Campbell ian.campb...@citrix.com --- v2: This patch was previously arndale: Enable config_distro_defaults.h. It required significant rebasing. --- include/configs/arndale.h| 2 -- include/configs/exynos-common.h | 13 ++--- include/configs/exynos5-common.h | 11 --- 3 files changed, 2 insertions(+), 24 deletions(-) diff --git a/include/configs/arndale.h b/include/configs/arndale.h index f9ee40f..a87806d 100644 --- a/include/configs/arndale.h +++ b/include/configs/arndale.h @@ -17,8 +17,6 @@ /* allow to overwrite serial and ethaddr */ #define CONFIG_ENV_OVERWRITE -#define CONFIG_CMD_EXT2 - /* USB */ #define CONFIG_USB_EHCI #define CONFIG_USB_EHCI_EXYNOS diff --git a/include/configs/exynos-common.h b/include/configs/exynos-common.h index 371f32d..ea40bb6 100644 --- a/include/configs/exynos-common.h +++ b/include/configs/exynos-common.h @@ -23,9 +23,6 @@ #define CONFIG_SKIP_LOWLEVEL_INIT #define CONFIG_BOARD_EARLY_INIT_F -/* Enable fdt support */ -#define CONFIG_OF_LIBFDT - /* Keep L2 Cache Disabled */ #define CONFIG_CMD_CACHE @@ -35,7 +32,6 @@ #define CONFIG_SETUP_MEMORY_TAGS #define CONFIG_CMDLINE_TAG #define CONFIG_INITRD_TAG -#define CONFIG_CMDLINE_EDITING #define CONFIG_ENV_OVERWRITE /* Size of malloc() pool before and after relocation */ @@ -54,7 +50,6 @@ #define CONFIG_EXYNOS_DWMMC #define CONFIG_BOUNCE_BUFFER -#define CONFIG_BOOTDELAY 3 #define CONFIG_ZERO_BOOTDELAY_CHECK /* PWM */ @@ -64,19 +59,13 @@ #include config_cmd_default.h #define CONFIG_CMD_MMC -#define CONFIG_CMD_EXT4 #define CONFIG_CMD_EXT4_WRITE -#define CONFIG_CMD_FAT #define CONFIG_FAT_WRITE -#define CONFIG_DOS_PARTITION -#define CONFIG_EFI_PARTITION #define CONFIG_CMD_PART #define CONFIG_PARTITION_UUIDS /* Miscellaneous configurable options */ -#define CONFIG_SYS_LONGHELP/* undef to save memory */ -#define CONFIG_SYS_HUSH_PARSER /* use hush command parser*/ #define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ #define CONFIG_SYS_PBSIZE 384 /* Print Buffer Size */ #define CONFIG_SYS_MAXARGS 16 /* max number of command args */ @@ -88,4 +77,6 @@ #define CONFIG_SYS_NO_FLASH #undef CONFIG_CMD_IMLS +#include config_distro_defaults.h + #endif /* __CONFIG_H */ diff --git a/include/configs/exynos5-common.h b/include/configs/exynos5-common.h index ba591e7..b03966d 100644 --- a/include/configs/exynos5-common.h +++ b/include/configs/exynos5-common.h @@ -55,9 +55,6 @@ #define CONFIG_EXTRA_ENV_SETTINGS \ EXYNOS_DEVICE_SETTINGS -#define CONFIG_CMD_PING -#define CONFIG_CMD_ELF -#define CONFIG_CMD_NET #define CONFIG_CMD_HASH /* Thermal Management Unit */ @@ -174,12 +171,6 @@ #define CONFIG_ENV_SROM_BANK 1 #endif /*CONFIG_CMD_NET*/ -/* Enable PXE Support */ -#ifdef CONFIG_CMD_NET -#define CONFIG_CMD_PXE -#define CONFIG_MENU -#endif - /* SHA hashing */ #define CONFIG_CMD_HASH #define CONFIG_HASH_VERIFY @@ -189,8 +180,6 @@ /* Enable Time Command */ #define CONFIG_CMD_TIME -#define CONFIG_CMD_BOOTZ - #define CONFIG_CMD_GPIO /* USB boot mode */ -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] exynos5: Use config_distro_bootcmd.h
From: Ian Campbell ian.campb...@citrix.com This replaces the existing CONFIG_BOOTCOMMAND for exynos5250 and 5420. exynos4 platforms seem to have existing complex extra env configuration for booting and so are excluded here. Hence the bootcmd.h is added to exynos5-common.h. I have build tested on all exynos platforms (MAKEALL -s exynos), but only boot tested on arndale. Signed-off-by: Ian Campbell ian.campb...@citrix.com --- v2: This was previously arndale: Use config_distro_bootcmd.h but required significant rebasing. Is replacing the existing bootcommand in this way acceptable? The distro_bootcmd.h infrastructure does not seem to provide a way to integrate the raw style of booting. --- include/configs/arndale.h | 3 +++ include/configs/exynos5-common.h| 45 ++--- include/configs/exynos5-dt-common.h | 17 ++ include/configs/exynos5250-common.h | 2 -- include/configs/exynos5420-common.h | 2 -- 5 files changed, 47 insertions(+), 22 deletions(-) diff --git a/include/configs/arndale.h b/include/configs/arndale.h index a87806d..919729d 100644 --- a/include/configs/arndale.h +++ b/include/configs/arndale.h @@ -9,6 +9,9 @@ #ifndef __CONFIG_ARNDALE_H #define __CONFIG_ARNDALE_H +#define EXYNOS_FDTFILE_SETTING \ + fdtfile=exynos5250-arndale.dtb\0 + #include exynos5250-common.h /* SD/MMC configuration */ diff --git a/include/configs/exynos5-common.h b/include/configs/exynos5-common.h index b03966d..8f9b780 100644 --- a/include/configs/exynos5-common.h +++ b/include/configs/exynos5-common.h @@ -47,14 +47,6 @@ #define CONFIG_SYS_CONSOLE_IS_IN_ENV #define CONFIG_CONSOLE_MUX -#define EXYNOS_DEVICE_SETTINGS \ - stdin=serial\0 \ - stdout=serial\0 \ - stderr=serial\0 - -#define CONFIG_EXTRA_ENV_SETTINGS \ - EXYNOS_DEVICE_SETTINGS - #define CONFIG_CMD_HASH /* Thermal Management Unit */ @@ -192,4 +184,41 @@ #define CONFIG_FIT #define CONFIG_FIT_BEST_MATCH + +#define BOOT_TARGET_DEVICES(func) \ + func(MMC, mmc, 1) \ + func(MMC, mmc, 0) \ + func(PXE, pxe, na) \ + func(DHCP, dhcp, na) + +#include config_distro_bootcmd.h + +#ifndef MEM_LAYOUT_ENV_SETTINGS +/* 2GB RAM, bootm size of 256M, load scripts after that */ +#define MEM_LAYOUT_ENV_SETTINGS \ + bootm_size=0x1000\0 \ + kernel_addr_r=0x4200\0 \ + fdt_addr_r=0x4300\0 \ + ramdisk_addr_r=0x4330\0 \ + scriptaddr=0x5000\0 \ + pxefile_addr_r=0x5100\0 +#endif + +#ifndef EXYNOS_DEVICE_SETTINGS +#define EXYNOS_DEVICE_SETTINGS \ + stdin=serial\0 \ + stdout=serial\0 \ + stderr=serial\0 +#endif + +#ifndef EXYNOS_FDTFILE_SETTING +#define EXYNOS_FDTFILE_SETTING +#endif + +#define CONFIG_EXTRA_ENV_SETTINGS \ + EXYNOS_DEVICE_SETTINGS \ + EXYNOS_FDTFILE_SETTING \ + MEM_LAYOUT_ENV_SETTINGS \ + BOOTENV + #endif /* __CONFIG_EXYNOS5_COMMON_H */ diff --git a/include/configs/exynos5-dt-common.h b/include/configs/exynos5-dt-common.h index 66547fa..9cef0b0 100644 --- a/include/configs/exynos5-dt-common.h +++ b/include/configs/exynos5-dt-common.h @@ -9,6 +9,13 @@ #ifndef __CONFIG_EXYNOS5_DT_COMMON_H #define __CONFIG_EXYNOS5_DT_COMMON_H +/* Console configuration */ +#undef EXYNOS_DEVICE_SETTINGS +#define EXYNOS_DEVICE_SETTINGS \ + stdin=serial,cros-ec-keyb\0 \ + stdout=serial,lcd\0 \ + stderr=serial,lcd\0 + #include exynos5-common.h /* PMIC */ @@ -22,14 +29,4 @@ #define CONFIG_CMD_CROS_EC #define CONFIG_KEYBOARD -/* Console configuration */ -#undef EXYNOS_DEVICE_SETTINGS -#define EXYNOS_DEVICE_SETTINGS \ - stdin=serial,cros-ec-keyb\0 \ - stdout=serial,lcd\0 \ - stderr=serial,lcd\0 - -#define CONFIG_EXTRA_ENV_SETTINGS \ - EXYNOS_DEVICE_SETTINGS - #endif diff --git a/include/configs/exynos5250-common.h b/include/configs/exynos5250-common.h index 713614f..a0107e8 100644 --- a/include/configs/exynos5250-common.h +++ b/include/configs/exynos5250-common.h @@ -29,8 +29,6 @@ #define CONFIG_SPL_TEXT_BASE 0x02023400 -#define CONFIG_BOOTCOMMAND mmc read 40007000 451 2000; bootm 40007000 - #define CONFIG_IRAM_STACK 0x0205 #define CONFIG_SYS_INIT_SP_ADDRCONFIG_IRAM_STACK diff --git a/include/configs/exynos5420-common.h b/include/configs/exynos5420-common.h index b0f940c..3cf9f01 100644 --- a/include/configs/exynos5420-common.h +++ b/include/configs/exynos5420-common.h @@ -44,8 +44,6 @@ #define CONFIG_BOARD_REV_GPIO_COUNT2 -#define CONFIG_BOOTCOMMAND mmc read 20007000 451 2000; bootm 20007000 - #define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS 2 /* -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] x86: Fix rom version build with CONFIG_X86_RESET_VECTOR
Hi Simon, On Thu, Oct 16, 2014 at 6:13 PM, Simon Glass s...@chromium.org wrote: Can we please do this in rch/x86/cpu/Makefile instead? Something like: extra-y = start.o obj-$(CONFIG_X86_RESET_VECTOR) += resetvec.o start16.o obj-y += interrupts.o cpu.o obj-$(CONFIG_PCI) += pci.o Regards, Simon Yes, will send v2. Thanks. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] x86: Fix GDT limit in start16.S
GDT limit should be one less than an integral multiple of eight. Signed-off-by: Bin Meng bmeng...@gmail.com --- arch/x86/cpu/start16.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/cpu/start16.S b/arch/x86/cpu/start16.S index 8b9b327..6968fda 100644 --- a/arch/x86/cpu/start16.S +++ b/arch/x86/cpu/start16.S @@ -70,7 +70,7 @@ idt_ptr: * GDT is setup in a safe location in RAM */ gdt_ptr: - .word 0x20/* limit (32 bytes = 4 GDT entries) */ + .word 0x1f/* limit (31 bytes = 4 GDT entries - 1) */ .long BOOT_SEG + gdt /* base */ /* Some CPUs are picky about GDT alignment... */ -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] x86: Fix rom version build with CONFIG_X86_RESET_VECTOR
When building U-Boot with CONFIG_X86_RESET_VECTOR, the linking process misses the resetvec.o and start16.o so it cannot generate the rom version of U-Boot. The arch/x86/cpu/Makefile is updated to pull them into the final linking process. Signed-off-by: Bin Meng bmeng...@gmail.com --- arch/x86/cpu/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/cpu/Makefile b/arch/x86/cpu/Makefile index 415bc24..e7bb3e3 100644 --- a/arch/x86/cpu/Makefile +++ b/arch/x86/cpu/Makefile @@ -9,5 +9,5 @@ # extra-y= start.o -extra-$(CONFIG_X86_RESET_VECTOR) += resetvec.o start16.o -obj-y = interrupts.o cpu.o +obj-$(CONFIG_X86_RESET_VECTOR) += resetvec.o start16.o +obj-y += interrupts.o cpu.o -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
On Saturday, October 11, 2014 at 11:04:58 PM, Fabio Estevam wrote: On Sat, Oct 11, 2014 at 11:21 AM, Sean Cross x...@kosagi.com wrote: Ok, understood. Just curious: which Ethernet PHY is used on the novena board? It's the same Micrel PHY used on the Sabrelite, the KSZ9021. nitrogen/sabrelite holds Ethernet PHY reset low for 10ms, which is in accordance with ksz9021 datasheet. Shouldn't we wait 10ms here as well? I checked the novena_spl.c and we do wait in novena_spl_setup_iomux_enet(). Is this what you have in mind ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
On Thu, Oct 16, 2014 at 7:21 AM, Marek Vasut ma...@denx.de wrote: I checked the novena_spl.c and we do wait in novena_spl_setup_iomux_enet(). Is this what you have in mind ? Nikolay added the delay in this patch: https://patchwork.ozlabs.org/patch/398920/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] tools-only build broken
Hello, On Wed, Sep 3, 2014 at 6:25 AM, Marek Vasut ma...@denx.de wrote: On Wednesday, September 03, 2014 at 03:44:35 AM, Otavio Salvador wrote: On Tue, Sep 2, 2014 at 8:14 PM, Simon Glass s...@chromium.org wrote: On 2 September 2014 15:44, Otavio Salvador ota...@ossystems.com.br wrote: On Tue, Sep 2, 2014 at 4:19 PM, Simon Glass s...@chromium.org wrote: ... We are using tools-only as part of the Debian packaging, what we are trying to build is a usable generic version of mkimage (and potentially other tools in the future) which can be placed in a generic u-boot-tools package which is separate from the u-boot package(s) which contain(s) u-boot binaries. mkimage has additional support for verified/secure boot, but only if enabled at build time. It is enabled for sandbox. So if you want full functionality you should use that build. However there are exceptions for it. For example MX28 has special mxsimage support when it is in use. Yes, I see the '#ifdef CONFIG_MXS' at the top of tools/mksimage.c. That seem wrong to me - do you know the reason for it? This is to avoid linking with SSL library[1]. 1. http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=tools/Makefile;h=90e9 66d893e64e0508718127766d76286c4b8c6e;hb=HEAD#l115 No, you're wrong. It is not because of linking against SSL library, but to make sure this MXSimage support can be disabled easily. However now we have FIT signature I think we can enable it and drop the MXS special usage. This claim is wrong too, the signed fitImage support was in U-Boot before the MXSimage support. (I remember I looked at this fitImage signature when I was integrating the mxsimage into U-Boot ;-)) Do you agree? I agree this -DCONFIG_MXS and the ifdef can be removed from Makefile and mxsimage.c respectively, but make sure the result won't break on various platforms. I have looked at this and I am unsure I still think removing it is a good idea. I think the way to go is to change CONFIG_MXS to CONFIG_MXSIMAGE and enable this in sandbox defconfig. What you think? We would maintain the possibility to disable it if needed. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: Add CONFIG_MACH_TYPE defines to sun4i, sun5i and sun7i
On Thu, 16 Oct 2014 10:50:42 +0200 Hans de Goede hdego...@redhat.com wrote: Hi, On 10/15/2014 12:48 PM, Siarhei Siamashka wrote: On Mon, 13 Oct 2014 14:55:35 +0200 Hans de Goede hdego...@redhat.com wrote: Many people are still using old linux-sunxi-3.4 kernels on sunxi devices, adding the proper MACH_TYPE defines for this allows people to switch to upstream u-boot, so that we can stop maintaining the linux-sunxi u-boot fork. These machine-ids are all properly registered at: http://www.arm.linux.org.uk/developer/machines/ Signed-off-by: Hans de Goede hdego...@redhat.com --- include/configs/sun4i.h | 1 + include/configs/sun5i.h | 1 + include/configs/sun7i.h | 1 + 3 files changed, 3 insertions(+) diff --git a/include/configs/sun4i.h b/include/configs/sun4i.h index 5611ecc..d0191a3 100644 --- a/include/configs/sun4i.h +++ b/include/configs/sun4i.h @@ -15,6 +15,7 @@ #define CONFIG_CLK_FULL_SPEED 100800 #define CONFIG_SYS_PROMPT sun4i# +#define CONFIG_MACH_TYPE 4104 #ifdef CONFIG_USB_EHCI #define CONFIG_USB_EHCI_SUNXI diff --git a/include/configs/sun5i.h b/include/configs/sun5i.h index 6066371..7b683e9 100644 --- a/include/configs/sun5i.h +++ b/include/configs/sun5i.h @@ -15,6 +15,7 @@ #define CONFIG_CLK_FULL_SPEED 100800 #define CONFIG_SYS_PROMPT sun5i# +#define CONFIG_MACH_TYPE 4138 #ifdef CONFIG_USB_EHCI #define CONFIG_USB_EHCI_SUNXI diff --git a/include/configs/sun7i.h b/include/configs/sun7i.h index a902b84..966cbd8 100644 --- a/include/configs/sun7i.h +++ b/include/configs/sun7i.h @@ -16,6 +16,7 @@ #define CONFIG_CLK_FULL_SPEED 91200 #define CONFIG_SYS_PROMPT sun7i# +#define CONFIG_MACH_TYPE 4283 #ifdef CONFIG_USB_EHCI #define CONFIG_USB_EHCI_SUNXI This patch is just trying to remove the safety guards (which exist there for a reason!) without addressing the real compatibility issues. Erm, no the mach_type-s are not safety-guards, they are absolutely necessary to get old non devicetree kernels to work at all. If it looks like a safety-guard, swims like a safety-guard, and quacks like a safety-guard, then it probably is a safety-guard. The users of the u-boot from the v2014.10 tag can't easily hurt themselves, because the old non-mainline 3.4 kernel will just refuse to boot. Yes, the users can easily patch the sources to add the machine id or provide it via the environment variable. But it requires some action from the user. This is kind of like a no trespassing tape, which can be easily stepped over. But a certain level of protection is still there. With just this single patch, sunxi-3.4 kernels with fixed PLL5 support, will happily boot on sun4i and sun5i. And with the bootm_boot_mode patch + env setting sun7i will boot fine too. Yes, it's a very simple problem. And multiple simple solutions are available. You just hastily picked one of them. And it has some unfortunate practical implications related to DRAM configuration opportunities, which I have already explained to you. As a custodian, you take full responsibility for your actions. If you think that this was the best choice, then so be it. -- 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: imx6: fix typos in CCM_ANALOG_PLL_VIDEO_DENOM register name
Fix name for Video PLL denominator register.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
arch/arm/include/asm/arch-mx6/crm_regs.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h
b/arch/arm/include/asm/arch-mx6/crm_regs.h
index 7202073..c00fc86 100644
--- a/arch/arm/include/asm/arch-mx6/crm_regs.h
+++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
@@ -89,7 +89,7 @@ struct mxc_ccm_reg {
u32 analog_pll_video_tog;
u32 analog_pll_video_num; /* 0x40b0 */
u32 analog_reserved6[3];
- u32 analog_pll_vedio_denon; /* 0x40c0 */
+ u32 analog_pll_video_denom; /* 0x40c0 */
u32 analog_reserved7[7];
u32 analog_pll_enet;/* 0x40e0 */
u32 analog_pll_enet_set;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert sunxi: dram: Use divisor P=1 for PLL5
Hi Hans, On 16-10-14 10:48, Hans de Goede wrote: [snip] So for now I believe we really should revert the PLL5 u-boot changes as they break some kernels from booting. U-boot and the kernel should be independent. Hence u-boot cannot break kernels from booting or the kernel is bugged and should be fixed. Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch v2 3/4] keystone2: ecc: add ddr3 error detection and correction support
From: Vitaly Andrianov vita...@ti.com
This patch adds the DDR3 ECC support to enable ECC in the DDR3
EMIF controller for Keystone II devices.
By default, ECC will only be enabled if RMW is supported in the
DDR EMIF controller. The entire DDR memory will be scrubbed to
zero using an EDMA channel after ECC is enabled and before
u-boot is re-located to DDR memory.
An ecc_test environment variable is added for ECC testing.
If ecc_test is set to 0, a detection of 2-bit error will reset
the device, if ecc_test is set to 1, 2-bit error detection
will not reset the device, user can still boot the kernel to
check the ECC error handling in kernel.
Signed-off-by: Hao Zhang hzh...@ti.com
Signed-off-by: Vitaly Andrianov vita...@ti.com
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
arch/arm/cpu/armv7/keystone/ddr3.c | 244 +
arch/arm/include/asm/arch-keystone/ddr3.h | 6 +
arch/arm/include/asm/arch-keystone/hardware-k2hk.h | 4 +
arch/arm/include/asm/arch-keystone/hardware.h | 46
board/ti/ks2_evm/board.c | 3 +
board/ti/ks2_evm/ddr3_k2hk.c | 16 ++
6 files changed, 319 insertions(+)
diff --git a/arch/arm/cpu/armv7/keystone/ddr3.c
b/arch/arm/cpu/armv7/keystone/ddr3.c
index 2eabec1..923906a 100644
--- a/arch/arm/cpu/armv7/keystone/ddr3.c
+++ b/arch/arm/cpu/armv7/keystone/ddr3.c
@@ -9,9 +9,19 @@
#include asm/io.h
#include common.h
+#include asm/arch/msmc.h
#include asm/arch/ddr3.h
#include asm/arch/psc_defs.h
+#include asm/ti-common/ti-edma3.h
+
+#define DDR3_EDMA_BLK_SIZE_SHIFT 10
+#define DDR3_EDMA_BLK_SIZE (1 DDR3_EDMA_BLK_SIZE_SHIFT)
+#define DDR3_EDMA_BCNT 0x8000
+#define DDR3_EDMA_CCNT 1
+#define DDR3_EDMA_XF_SIZE (DDR3_EDMA_BLK_SIZE * DDR3_EDMA_BCNT)
+#define DDR3_EDMA_SLOT_NUM 1
+
void ddr3_init_ddrphy(u32 base, struct ddr3_phy_config *phy_cfg)
{
unsigned int tmp;
@@ -70,6 +80,240 @@ void ddr3_init_ddremif(u32 base, struct ddr3_emif_config
*emif_cfg)
__raw_writel(emif_cfg-sdrfc, base + KS2_DDR3_SDRFC_OFFSET);
}
+int ddr3_ecc_support_rmw(u32 base)
+{
+ u32 value = __raw_readl(base + KS2_DDR3_MIDR_OFFSET);
+
+ /* Check the DDR3 controller ID reg if the controllers
+ supports ECC RMW or not */
+ if (value == 0x40461C02)
+ return 1;
+
+ return 0;
+}
+
+static void ddr3_ecc_config(u32 base, u32 value)
+{
+ u32 data;
+
+ __raw_writel(value, base + KS2_DDR3_ECC_CTRL_OFFSET);
+ udelay(10); /* delay required to synchronize across clock domains */
+
+ if (value KS2_DDR3_ECC_EN) {
+ /* Clear the 1-bit error count */
+ data = __raw_readl(base + KS2_DDR3_ONE_BIT_ECC_ERR_CNT_OFFSET);
+ __raw_writel(data, base + KS2_DDR3_ONE_BIT_ECC_ERR_CNT_OFFSET);
+
+ /* enable the ECC interrupt */
+ __raw_writel(KS2_DDR3_1B_ECC_ERR_SYS | KS2_DDR3_2B_ECC_ERR_SYS |
+KS2_DDR3_WR_ECC_ERR_SYS,
+base + KS2_DDR3_ECC_INT_ENABLE_SET_SYS_OFFSET);
+
+ /* Clear the ECC error interrupt status */
+ __raw_writel(KS2_DDR3_1B_ECC_ERR_SYS | KS2_DDR3_2B_ECC_ERR_SYS |
+KS2_DDR3_WR_ECC_ERR_SYS,
+base + KS2_DDR3_ECC_INT_STATUS_OFFSET);
+ }
+}
+
+static void ddr3_reset_data(u32 base, u32 ddr3_size)
+{
+ u32 mpax[2];
+ u32 seg_num;
+ u32 seg, blks, dst, edma_blks;
+ struct edma3_slot_config slot;
+ struct edma3_channel_config edma_channel;
+ u32 edma_src[DDR3_EDMA_BLK_SIZE/4] __aligned(16) = {0, };
+
+ /* Setup an edma to copy the 1k block to the entire DDR */
+ puts(\nClear entire DDR3 memory to enable ECC\n);
+
+ /* save the SES MPAX regs */
+ msmc_get_ses_mpax(8, 0, mpax);
+
+ /* setup edma slot 1 configuration */
+ slot.opt = EDMA3_SLOPT_TRANS_COMP_INT_ENB |
+ EDMA3_SLOPT_COMP_CODE(0) |
+ EDMA3_SLOPT_STATIC | EDMA3_SLOPT_AB_SYNC;
+ slot.bcnt = DDR3_EDMA_BCNT;
+ slot.acnt = DDR3_EDMA_BLK_SIZE;
+ slot.ccnt = DDR3_EDMA_CCNT;
+ slot.src_bidx = 0;
+ slot.dst_bidx = DDR3_EDMA_BLK_SIZE;
+ slot.src_cidx = 0;
+ slot.dst_cidx = 0;
+ slot.link = EDMA3_PARSET_NULL_LINK;
+ slot.bcntrld = 0;
+ edma3_slot_configure(KS2_EDMA0_BASE, DDR3_EDMA_SLOT_NUM, slot);
+
+ /* configure quik edma channel */
+ edma_channel.slot = DDR3_EDMA_SLOT_NUM;
+ edma_channel.chnum = 0;
+ edma_channel.complete_code = 0;
+ /* event trigger after dst update */
+ edma_channel.trigger_slot_word = EDMA3_TWORD(dst);
+ qedma3_start(KS2_EDMA0_BASE, edma_channel);
+
+ /* DDR3 size in segments (4KB seg size) */
+ seg_num = ddr3_size (30 - KS2_MSMC_SEG_SIZE_SHIFT);
+
+
[U-Boot] [U-boot] [Patch v2 1/4] dma: ti-edma3: introduce edma3 driver
The EDMA3 controller’s primary purpose is to service data transfers
that you program between two memory-mapped slave endpoints on the device.
Typical usage includes, but is not limited to the following:
- Servicing software-driven paging transfers (e.g., transfers from external
memory, such as SDRAM to internal device memory, such as DSP L2 SRAM)
- Servicing event-driven peripherals, such as a serial port
- Performing sorting or sub-frame extraction of various data structures
- Offloading data transfers from the main device DSP(s)
- See the device-specific data manual for specific peripherals that are
accessible via the EDMA3 controller
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
arch/arm/include/asm/ti-common/ti-edma3.h | 121 ++
drivers/dma/Makefile | 1 +
drivers/dma/ti-edma3.c| 384 ++
3 files changed, 506 insertions(+)
create mode 100644 arch/arm/include/asm/ti-common/ti-edma3.h
create mode 100644 drivers/dma/ti-edma3.c
diff --git a/arch/arm/include/asm/ti-common/ti-edma3.h
b/arch/arm/include/asm/ti-common/ti-edma3.h
new file mode 100644
index 000..5adc1da
--- /dev/null
+++ b/arch/arm/include/asm/ti-common/ti-edma3.h
@@ -0,0 +1,121 @@
+/*
+ * Enhanced Direct Memory Access (EDMA3) Controller
+ *
+ * (C) Copyright 2014
+ * Texas Instruments Incorporated, www.ti.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef _EDMA3_H_
+#define _EDMA3_H_
+
+#include linux/stddef.h
+
+#define EDMA3_PARSET_NULL_LINK 0x
+
+/*
+ * All parameter RAM set options
+ * opt field in edma3_param_set_config structure
+ */
+#define EDMA3_SLOPT_PRIV_LEVEL BIT(31)
+#define EDMA3_SLOPT_PRIV_ID(id)((0xf (id)) 24)
+#define EDMA3_SLOPT_INTERM_COMP_CHAIN_ENB BIT(23)
+#define EDMA3_SLOPT_TRANS_COMP_CHAIN_ENB BIT(22)
+#define EDMA3_SLOPT_INTERM_COMP_INT_ENBBIT(21)
+#define EDMA3_SLOPT_TRANS_COMP_INT_ENB BIT(20)
+#define EDMA3_SLOPT_COMP_CODE(code)((0x3f (code)) 12)
+#define EDMA3_SLOPT_FIFO_WIDTH_8 0
+#define EDMA3_SLOPT_FIFO_WIDTH_16 (1 8)
+#define EDMA3_SLOPT_FIFO_WIDTH_32 (2 8)
+#define EDMA3_SLOPT_FIFO_WIDTH_64 (3 8)
+#define EDMA3_SLOPT_FIFO_WIDTH_128 (4 8)
+#define EDMA3_SLOPT_FIFO_WIDTH_256 (5 8)
+#define EDMA3_SLOPT_FIFO_WIDTH_SET(w) ((w 0x7) 8)
+#define EDMA3_SLOPT_STATIC BIT(3)
+#define EDMA3_SLOPT_AB_SYNCBIT(2)
+#define EDMA3_SLOPT_DST_ADDR_CONST_MODEBIT(1)
+#define EDMA3_SLOPT_SRC_ADDR_CONST_MODEBIT(0)
+
+enum edma3_address_mode {
+ INCR = 0,
+ FIFO = 1
+};
+
+enum edma3_fifo_width {
+ W8BIT = 0,
+ W16BIT = 1,
+ W32BIT = 2,
+ W64BIT = 3,
+ W128BIT = 4,
+ W256BIT = 5
+};
+
+enum edma3_sync_dimension {
+ ASYNC = 0,
+ ABSYNC = 1
+};
+
+/* PaRAM slots are laid out like this */
+struct edma3_slot_layout {
+ u32 opt;
+ u32 src;
+ u32 a_b_cnt;
+ u32 dst;
+ u32 src_dst_bidx;
+ u32 link_bcntrld;
+ u32 src_dst_cidx;
+ u32 ccnt;
+} __packed;
+
+/*
+ * Use this to assign trigger word number of edma3_slot_layout struct.
+ * trigger_word_name - is the exact name from edma3_slot_layout.
+ */
+#define EDMA3_TWORD(trigger_word_name)\
+ (offsetof(struct edma3_slot_layout, trigger_word_name) / 4)
+
+struct edma3_slot_config {
+ u32 opt;
+ u32 src;
+ u32 dst;
+ int bcnt;
+ int acnt;
+ int ccnt;
+ int src_bidx;
+ int dst_bidx;
+ int src_cidx;
+ int dst_cidx;
+ int bcntrld;
+ int link;
+};
+
+struct edma3_channel_config {
+ int slot;
+ int chnum;
+ int complete_code; /* indicate pending complete interrupt */
+ int trigger_slot_word; /* only used for qedma */
+};
+
+void qedma3_start(u32 base, struct edma3_channel_config *cfg);
+void qedma3_stop(u32 base, struct edma3_channel_config *cfg);
+void edma3_slot_configure(u32 base, int slot, struct edma3_slot_config *cfg);
+int edma3_check_for_transfer(u32 base, struct edma3_channel_config *cfg);
+void edma3_write_slot(u32 base, int slot, struct edma3_slot_layout *param);
+void edma3_read_slot(u32 base, int slot, struct edma3_slot_layout *param);
+
+void edma3_set_dest(u32 base, int slot, u32 dst, enum edma3_address_mode mode,
+ enum edma3_fifo_width width);
+void edma3_set_dest_index(u32 base, unsigned slot, int bidx, int cidx);
+void edma3_set_dest_addr(u32 base, int slot, u32 dst);
+
+void edma3_set_src(u32 base, int slot, u32 src, enum edma3_address_mode mode,
+ enum edma3_fifo_width width);
+void edma3_set_src_index(u32 base, unsigned slot, int bidx, int cidx);
+void edma3_set_src_addr(u32 base, int slot, u32 src);
+
+void
[U-Boot] [U-boot] [Patch v2 0/4] keystone2: ecc: add ddr3 error detection and correction support
This series adds the DDR3 ECC support to enable ECC in the DDR3 EMIF controller for Keystone II devices. Based on [U-boot] [Patch 0/5] keystone2: add network support for K2E SoC and EVM https://www.mail-archive.com/u-boot@lists.denx.de/msg148985.html v2..v1: - nothing changed just rebased Hao Zhang (1): ARM: keystone: cmd_ddr3: add ddr3 commands to test ddr Ivan Khoronzhuk (1): dma: ti-edma3: introduce edma3 driver Vitaly Andrianov (2): ARM: keystone: msmc: extend functionality of SES keystone2: ecc: add ddr3 error detection and correction support arch/arm/cpu/armv7/keystone/Makefile | 2 +- arch/arm/cpu/armv7/keystone/cmd_ddr3.c | 247 + arch/arm/cpu/armv7/keystone/ddr3.c | 244 + arch/arm/cpu/armv7/keystone/msmc.c | 26 ++ arch/arm/include/asm/arch-keystone/ddr3.h | 6 + arch/arm/include/asm/arch-keystone/hardware-k2hk.h | 4 + arch/arm/include/asm/arch-keystone/hardware.h | 52 +++ arch/arm/include/asm/arch-keystone/msmc.h | 28 ++ arch/arm/include/asm/ti-common/ti-edma3.h | 121 +++ board/ti/ks2_evm/board.c | 3 + board/ti/ks2_evm/ddr3_k2hk.c | 16 + drivers/dma/Makefile | 1 + drivers/dma/ti-edma3.c | 384 + include/configs/ks2_evm.h | 4 - 14 files changed, 1133 insertions(+), 5 deletions(-) create mode 100644 arch/arm/cpu/armv7/keystone/cmd_ddr3.c create mode 100644 arch/arm/include/asm/ti-common/ti-edma3.h create mode 100644 drivers/dma/ti-edma3.c -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch v2 2/4] ARM: keystone: msmc: extend functionality of SES
From: Vitaly Andrianov vita...@ti.com
Add functions to set/get SES PMAX values of Pivilege ID pair.
Also add msmc module definitions.
Acked-by: Murali Karicheri m-kariche...@ti.com
Signed-off-by: Hao Zhang hzh...@ti.com
Signed-off-by: Vitaly Andrianov vita...@ti.com
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
arch/arm/cpu/armv7/keystone/msmc.c| 26 +
arch/arm/include/asm/arch-keystone/hardware.h | 6 ++
arch/arm/include/asm/arch-keystone/msmc.h | 28 +++
3 files changed, 60 insertions(+)
diff --git a/arch/arm/cpu/armv7/keystone/msmc.c
b/arch/arm/cpu/armv7/keystone/msmc.c
index 7d8e597..7899141 100644
--- a/arch/arm/cpu/armv7/keystone/msmc.c
+++ b/arch/arm/cpu/armv7/keystone/msmc.c
@@ -66,3 +66,29 @@ void msmc_share_all_segments(int priv_id)
msmc-ses[priv_id][j].mpaxh = 0xff7ful;
}
}
+
+void msmc_map_ses_segment(int priv_id, int ses_pair,
+ u32 src_pfn, u32 dst_pfn, enum mpax_seg_size size)
+{
+ struct msms_regs *msmc = (struct msms_regs *)KS2_MSMC_CTRL_BASE;
+
+ msmc-ses[priv_id][ses_pair].mpaxh = src_pfn 12 |
+(size 0x1f) | 0x80;
+ msmc-ses[priv_id][ses_pair].mpaxl = dst_pfn 8 | 0x3f;
+}
+
+void msmc_get_ses_mpax(int priv_id, int ses_pair, u32 *mpax)
+{
+ struct msms_regs *msmc = (struct msms_regs *)KS2_MSMC_CTRL_BASE;
+
+ *mpax++ = msmc-ses[priv_id][ses_pair].mpaxl;
+ *mpax = msmc-ses[priv_id][ses_pair].mpaxh;
+}
+
+void msmc_set_ses_mpax(int priv_id, int ses_pair, u32 *mpax)
+{
+ struct msms_regs *msmc = (struct msms_regs *)KS2_MSMC_CTRL_BASE;
+
+ msmc-ses[priv_id][ses_pair].mpaxl = *mpax++;
+ msmc-ses[priv_id][ses_pair].mpaxh = *mpax;
+}
diff --git a/arch/arm/include/asm/arch-keystone/hardware.h
b/arch/arm/include/asm/arch-keystone/hardware.h
index 6788001..d2bd6cb 100644
--- a/arch/arm/include/asm/arch-keystone/hardware.h
+++ b/arch/arm/include/asm/arch-keystone/hardware.h
@@ -165,6 +165,12 @@ typedef volatile unsigned int *dv_reg_p;
#define KS2_MSMC_CTRL_BASE 0x0bc0
#define KS2_MSMC_DATA_BASE 0x0c00
+/* MSMC segment size shift bits */
+#define KS2_MSMC_SEG_SIZE_SHIFT12
+#define KS2_MSMC_MAP_SEG_NUM (2 (30 - KS2_MSMC_SEG_SIZE_SHIFT))
+#define KS2_MSMC_DST_SEG_BASE (CONFIG_SYS_LPAE_SDRAM_BASE \
+ KS2_MSMC_SEG_SIZE_SHIFT)
+
/* USB */
#define KS2_USB_SS_BASE0x0268
#define KS2_USB_HOST_XHCI_BASE (KS2_USB_SS_BASE + 0x1)
diff --git a/arch/arm/include/asm/arch-keystone/msmc.h
b/arch/arm/include/asm/arch-keystone/msmc.h
index c320db5..083f5ba 100644
--- a/arch/arm/include/asm/arch-keystone/msmc.h
+++ b/arch/arm/include/asm/arch-keystone/msmc.h
@@ -12,6 +12,34 @@
#include asm/arch/hardware.h
+enum mpax_seg_size {
+ MPAX_SEG_4K = 0x0b,
+ MPAX_SEG_8K,
+ MPAX_SEG_16K,
+ MPAX_SEG_32K,
+ MPAX_SEG_64K,
+ MPAX_SEG_128K,
+ MPAX_SEG_256K,
+ MPAX_SEG_512K,
+ MPAX_SEG_1M,
+ MPAX_SEG_2M,
+ MPAX_SEG_4M,
+ MPAX_SEG_8M,
+ MPAX_SEG_16M,
+ MPAX_SEG_32M,
+ MPAX_SEG_64M,
+ MPAX_SEG_128M,
+ MPAX_SEG_256M,
+ MPAX_SEG_512M,
+ MPAX_SEG_1G,
+ MPAX_SEG_2G,
+ MPAX_SEG_4G
+};
+
void msmc_share_all_segments(int priv_id);
+void msmc_get_ses_mpax(int priv_id, int ses_pair, u32 *mpax);
+void msmc_set_ses_mpax(int priv_id, int ses_pair, u32 *mpax);
+void msmc_map_ses_segment(int priv_id, int ses_pair,
+ u32 src_pfn, u32 dst_pfn, enum mpax_seg_size size);
#endif
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch v2 4/4] ARM: keystone: cmd_ddr3: add ddr3 commands to test ddr
From: Hao Zhang hzh...@ti.com
Add ddr3 commands:
test start_addr in hex end_addr in hex - test DDR from start\n
address to end address\n
ddr compare start_addr in hex end_addr in hex size in hex -\n
compare DDR data of (size) bytes from start address to end
address\n
ddr ecc_err addr in hex bit_err in hex - generate bit errors\n
in DDR data at addr, the command will read a 32-bit data\n
from addr, and write (data ^ bit_err) back to addr\n
Delete CONFIG_MAX_UBOOT_MEM_SIZE, as it was supposed to be used
for ddr3 commands and for now it's not needed any more.
Signed-off-by: Hao Zhang hzh...@ti.com
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
arch/arm/cpu/armv7/keystone/Makefile | 2 +-
arch/arm/cpu/armv7/keystone/cmd_ddr3.c | 247 +
include/configs/ks2_evm.h | 4 -
3 files changed, 248 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/cpu/armv7/keystone/cmd_ddr3.c
diff --git a/arch/arm/cpu/armv7/keystone/Makefile
b/arch/arm/cpu/armv7/keystone/Makefile
index 57f6ea6..ed030db 100644
--- a/arch/arm/cpu/armv7/keystone/Makefile
+++ b/arch/arm/cpu/armv7/keystone/Makefile
@@ -14,5 +14,5 @@ obj-$(CONFIG_SOC_K2L) += clock-k2l.o
obj-y += cmd_clock.o
obj-y += cmd_mon.o
obj-y += msmc.o
-obj-y += ddr3.o
+obj-y += ddr3.o cmd_ddr3.o
obj-y += keystone.o
diff --git a/arch/arm/cpu/armv7/keystone/cmd_ddr3.c
b/arch/arm/cpu/armv7/keystone/cmd_ddr3.c
new file mode 100644
index 000..e85027b
--- /dev/null
+++ b/arch/arm/cpu/armv7/keystone/cmd_ddr3.c
@@ -0,0 +1,247 @@
+/*
+ * Keystone2: DDR3 test commands
+ *
+ * (C) Copyright 2012-2014
+ * Texas Instruments Incorporated, www.ti.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include asm/arch/hardware.h
+#include asm/arch/ddr3.h
+#include common.h
+#include command.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define DDR_MIN_ADDR CONFIG_SYS_SDRAM_BASE
+
+#define DDR_REMAP_ADDR 0x8000
+#define ECC_START_ADDR1((DDR_MIN_ADDR - DDR_REMAP_ADDR) 17)
+
+#define ECC_END_ADDR1 (((gd-start_addr_sp - DDR_REMAP_ADDR - \
+CONFIG_STACKSIZE) 17) - 2)
+
+#define DDR_TEST_BURST_SIZE1024
+
+static int ddr_memory_test(u32 start_address, u32 end_address, int quick)
+{
+ u32 index_start, value, index;
+
+ index_start = start_address;
+
+ while (1) {
+ /* Write a pattern */
+ for (index = index_start;
+ index index_start + DDR_TEST_BURST_SIZE;
+ index += 4)
+ __raw_writel(index, index);
+
+ /* Read and check the pattern */
+ for (index = index_start;
+ index index_start + DDR_TEST_BURST_SIZE;
+ index += 4) {
+ value = __raw_readl(index);
+ if (value != index) {
+ printf(ddr_memory_test: Failed at address
index = 0x%x value = 0x%x *(index) = 0x%x\n,
+ index, value, __raw_readl(index));
+
+ return -1;
+ }
+ }
+
+ index_start += DDR_TEST_BURST_SIZE;
+ if (index_start = end_address)
+ break;
+
+ if (quick)
+ continue;
+
+ /* Write a pattern for complementary values */
+ for (index = index_start;
+index index_start + DDR_TEST_BURST_SIZE;
+index += 4)
+ __raw_writel((u32)~index, index);
+
+ /* Read and check the pattern */
+ for (index = index_start;
+index index_start + DDR_TEST_BURST_SIZE;
+index += 4) {
+ value = __raw_readl(index);
+ if (value != ~index) {
+ printf(ddr_memory_test: Failed at address
index = 0x%x value = 0x%x *(index) = 0x%x\n,
+ index, value, __raw_readl(index));
+
+ return -1;
+ }
+ }
+
+ index_start += DDR_TEST_BURST_SIZE;
+ if (index_start = end_address)
+ break;
+
+ /* Write a pattern */
+ for (index = index_start;
+index index_start + DDR_TEST_BURST_SIZE;
+index += 2)
+ __raw_writew((u16)index, index);
+
+ /* Read and check the pattern */
+ for (index = index_start;
+index index_start + DDR_TEST_BURST_SIZE;
+index += 2) {
+ value = __raw_readw(index);
+ if (value != (u16)index) {
+
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
On Thursday, October 16, 2014 at 07:17:36 PM, Fabio Estevam wrote: On Thu, Oct 16, 2014 at 7:21 AM, Marek Vasut ma...@denx.de wrote: I checked the novena_spl.c and we do wait in novena_spl_setup_iomux_enet(). Is this what you have in mind ? Nikolay added the delay in this patch: https://patchwork.ozlabs.org/patch/398920/ So this discussion is related to a different thread ? I see ... Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] tools-only build broken
On Thursday, October 16, 2014 at 08:24:21 PM, Otavio Salvador wrote: Hello, On Wed, Sep 3, 2014 at 6:25 AM, Marek Vasut ma...@denx.de wrote: On Wednesday, September 03, 2014 at 03:44:35 AM, Otavio Salvador wrote: On Tue, Sep 2, 2014 at 8:14 PM, Simon Glass s...@chromium.org wrote: On 2 September 2014 15:44, Otavio Salvador ota...@ossystems.com.br wrote: On Tue, Sep 2, 2014 at 4:19 PM, Simon Glass s...@chromium.org wrote: ... We are using tools-only as part of the Debian packaging, what we are trying to build is a usable generic version of mkimage (and potentially other tools in the future) which can be placed in a generic u-boot-tools package which is separate from the u-boot package(s) which contain(s) u-boot binaries. mkimage has additional support for verified/secure boot, but only if enabled at build time. It is enabled for sandbox. So if you want full functionality you should use that build. However there are exceptions for it. For example MX28 has special mxsimage support when it is in use. Yes, I see the '#ifdef CONFIG_MXS' at the top of tools/mksimage.c. That seem wrong to me - do you know the reason for it? This is to avoid linking with SSL library[1]. 1. http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=tools/Makefile;h=90 e9 66d893e64e0508718127766d76286c4b8c6e;hb=HEAD#l115 No, you're wrong. It is not because of linking against SSL library, but to make sure this MXSimage support can be disabled easily. However now we have FIT signature I think we can enable it and drop the MXS special usage. This claim is wrong too, the signed fitImage support was in U-Boot before the MXSimage support. (I remember I looked at this fitImage signature when I was integrating the mxsimage into U-Boot ;-)) Do you agree? I agree this -DCONFIG_MXS and the ifdef can be removed from Makefile and mxsimage.c respectively, but make sure the result won't break on various platforms. I have looked at this and I am unsure I still think removing it is a good idea. I think the way to go is to change CONFIG_MXS to CONFIG_MXSIMAGE and enable this in sandbox defconfig. What you think? We would maintain the possibility to disable it if needed. Nonsense, we should have as little amount of configurations as possible when it comes to mkimage. I would be all for enabling both signed fitImage and MXS image format by default and be done with it. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
On Thu, Oct 16, 2014 at 8:02 PM, Marek Vasut ma...@denx.de wrote: So this discussion is related to a different thread ? I see ... We are talking about the need for the delay in the Ethernet PHY. Nikolay sent a patch adding such delay as a standard patch. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
On Wed, Oct 15, 2014 at 11:38 PM, Sean Cross x...@kosagi.com wrote: My opinion is that, following the principle of least surprise, we should leave the delay in. If, sometime in the future, someone were to micro-optimize the boot sequence, they can strip it out then, but in that case it'd make more sense to load Linux directly from SPL. I say leave it in. Yes, I agree. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] drivers : usb: fsl: Implement usb Erratum A007798 workaround
Set TXFIFOTHRESH to adjust ddr pipeline delay for successful large
usb writes
Signed-off-by: Nikhil Badola nikhil.bad...@freescale.com
---
Depends on patch https://patchwork.ozlabs.org/patch/394797/
arch/powerpc/cpu/mpc85xx/cmd_errata.c | 4
arch/powerpc/include/asm/config_mpc85xx.h | 1 +
drivers/usb/host/ehci-fsl.c | 3 +--
include/fsl_usb.h | 11 +++
4 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
index 349ce52..fe3eb06 100644
--- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
+++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
@@ -294,6 +294,10 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
if (has_erratum_a007075())
puts(Work-around for Erratum A007075 enabled\n);
#endif
+#ifdef CONFIG_SYS_FSL_ERRATUM_A007798
+ if (has_erratum_a007798())
+ puts(Work-around for Erratum A007798 enabled\n);
+#endif
#ifdef CONFIG_SYS_FSL_ERRATUM_I2C_A004447
if ((SVR_SOC_VER(svr) == SVR_8548 IS_SVR_REV(svr, 3, 1)) ||
(SVR_REV(svr) = CONFIG_SYS_FSL_A004447_SVR_REV))
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
b/arch/powerpc/include/asm/config_mpc85xx.h
index 712f2ef..486bc53 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -677,6 +677,7 @@
#define CONFIG_SYS_FSL_ERRATUM_A006379
#define CONFIG_SYS_FSL_ERRATUM_A007186
#define CONFIG_SYS_FSL_ERRATUM_A006593
+#define CONFIG_SYS_FSL_ERRATUM_A007798
#define CONFIG_SYS_CCSRBAR_DEFAULT 0xfe00
#define CONFIG_SYS_FSL_SFP_VER_3_0
#define CONFIG_SYS_FSL_PCI_VER_3_X
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index c125e2c..7101202 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -131,8 +131,7 @@ int ehci_hcd_init(int index, enum usb_init_type init,
in_le32(ehci-usbmode);
- if (SVR_SOC_VER(get_svr()) == SVR_T4240
- IS_SVR_REV(get_svr(), 2, 0))
+ if (has_erratum_a007798())
set_txfifothresh(ehci, TXFIFOTHRESH);
return 0;
diff --git a/include/fsl_usb.h b/include/fsl_usb.h
index 66f8934..e4902aa 100644
--- a/include/fsl_usb.h
+++ b/include/fsl_usb.h
@@ -139,6 +139,12 @@ static inline bool has_erratum_a007075(void)
}
return false;
}
+
+static inline bool has_erratum_a007798(void)
+{
+ return SVR_SOC_VER(get_svr()) == SVR_T4240
+ IS_SVR_REV(get_svr(), 2, 0);
+}
#else
static inline bool has_erratum_a006261(void)
{
@@ -150,5 +156,10 @@ static inline bool has_erratum_a007075(void)
return false;
}
+static inline bool has_erratum_a007798(void)
+{
+ return false;
+}
+
#endif
#endif /*_ASM_FSL_USB_H_ */
--
1.7.11.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] image: Fix Android boot image support
This patch makes the following changes:
- Set kernel entry point correctly
- Append bootargs from image to global bootargs instead
of replacing them
- Return end address instead of size from android_image_get_end()
- Give correct parameter to genimg_get_format() in boot_get_ramdisk()
Signed-off-by: Ahmad Draidi ar200...@gmail.com
Cc: Tom Rini tr...@ti.com
---
common/bootm.c | 4 ++--
common/image-android.c | 34 +++---
common/image.c | 3 ++-
3 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/common/bootm.c b/common/bootm.c
index ff81a27..c04a3b0 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -144,11 +144,11 @@ static int bootm_find_os(cmd_tbl_t *cmdtp, int flag, int
argc,
images.os.type = IH_TYPE_KERNEL;
images.os.comp = IH_COMP_NONE;
images.os.os = IH_OS_LINUX;
- images.ep = images.os.load;
- ep_found = true;
images.os.end = android_image_get_end(os_hdr);
images.os.load = android_image_get_kload(os_hdr);
+ images.ep = images.os.load;
+ ep_found = true;
break;
#endif
default:
diff --git a/common/image-android.c b/common/image-android.c
index 6ded7e2..badaa7e 100644
--- a/common/image-android.c
+++ b/common/image-android.c
@@ -7,6 +7,7 @@
#include common.h
#include image.h
#include android_image.h
+#include malloc.h
static char andr_tmp_str[ANDR_BOOT_ARGS_SIZE + 1];
@@ -25,12 +26,30 @@ int android_image_get_kernel(const struct andr_img_hdr
*hdr, int verify,
printf(Kernel load addr 0x%08x size %u KiB\n,
hdr-kernel_addr, DIV_ROUND_UP(hdr-kernel_size, 1024));
+
strncpy(andr_tmp_str, hdr-cmdline, ANDR_BOOT_ARGS_SIZE);
andr_tmp_str[ANDR_BOOT_ARGS_SIZE] = '\0';
if (strlen(andr_tmp_str)) {
printf(Kernel command line: %s\n, andr_tmp_str);
- setenv(bootargs, andr_tmp_str);
+ char *bootargs = getenv(bootargs);
+ if (bootargs == NULL) {
+ setenv(bootargs, andr_tmp_str);
+ } else {
+ char *newbootargs = malloc(strlen(bootargs) +
+ strlen(andr_tmp_str) + 1);
+ if (newbootargs == NULL) {
+ puts(Error: malloc in android_image_get_kernel
failed!\n);
+ return -1;
+ }
+
+ strcpy(newbootargs, bootargs);
+ strcat(newbootargs, );
+ strncat(newbootargs, andr_tmp_str, ANDR_BOOT_ARGS_SIZE);
+
+ setenv(bootargs, newbootargs);
+ }
}
+
if (hdr-ramdisk_size)
printf(RAM disk load addr 0x%08x size %u KiB\n,
hdr-ramdisk_addr,
@@ -52,17 +71,18 @@ int android_image_check_header(const struct andr_img_hdr
*hdr)
ulong android_image_get_end(const struct andr_img_hdr *hdr)
{
- u32 size = 0;
+ ulong end;
/*
* The header takes a full page, the remaining components are aligned
* on page boundary
*/
- size += hdr-page_size;
- size += ALIGN(hdr-kernel_size, hdr-page_size);
- size += ALIGN(hdr-ramdisk_size, hdr-page_size);
- size += ALIGN(hdr-second_size, hdr-page_size);
+ end = (ulong)hdr;
+ end += hdr-page_size;
+ end += ALIGN(hdr-kernel_size, hdr-page_size);
+ end += ALIGN(hdr-ramdisk_size, hdr-page_size);
+ end += ALIGN(hdr-second_size, hdr-page_size);
- return size;
+ return end;
}
ulong android_image_get_kload(const struct andr_img_hdr *hdr)
diff --git a/common/image.c b/common/image.c
index 085771c..e21c848 100644
--- a/common/image.c
+++ b/common/image.c
@@ -1009,7 +1009,8 @@ int boot_get_ramdisk(int argc, char * const argv[],
bootm_headers_t *images,
image_multi_getimg(images-legacy_hdr_os, 1, rd_data, rd_len);
}
#ifdef CONFIG_ANDROID_BOOT_IMAGE
- else if ((genimg_get_format(images) == IMAGE_FORMAT_ANDROID)
+ else if ((genimg_get_format((void *)images-os.start)
+ == IMAGE_FORMAT_ANDROID)
(!android_image_get_ramdisk((void *)images-os.start,
rd_data, rd_len))) {
/* empty */
--
2.1.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] imx: iomux: fix incorrect reference of pad names in macros
MX6 reference pad names MX6Q_PAD_xx/MX6DL_PAD_xx when CONFIG_MX6QDL,
while other cases reference MX6_PAD_xx only.
Cc: Tim Harvey thar...@gateworks.com
Signed-off-by: Edward Lin tungyilin1...@gmail.com
---
arch/arm/include/asm/imx-common/iomux-v3.h | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/imx-common/iomux-v3.h
b/arch/arm/include/asm/imx-common/iomux-v3.h
index 70ee86c..00c7eeb 100644
--- a/arch/arm/include/asm/imx-common/iomux-v3.h
+++ b/arch/arm/include/asm/imx-common/iomux-v3.h
@@ -192,16 +192,17 @@ if (is_cpu_type(MXC_CPU_MX6Q)) {
\
}
#define SETUP_IOMUX_PADS(x)\
imx_iomux_v3_setup_multiple_pads(x, ARRAY_SIZE(x)/2)
-#elif defined(CONFIG_MX6Q) || defined(CONFIG_MX6D)
-#define IOMUX_PADS(x) MX6Q_##x
+#elif defined(CONFIG_MX6Q) || defined(CONFIG_MX6D) \
+ || defined(CONFIG_MX6DL) || defined(CONFIG_MX6S)
+#define IOMUX_PADS(x) MX6_##x
#define SETUP_IOMUX_PAD(def) \
- imx_iomux_v3_setup_pad(MX6Q_##def);
+ imx_iomux_v3_setup_pad(MX6_##def);
#define SETUP_IOMUX_PADS(x)\
imx_iomux_v3_setup_multiple_pads(x, ARRAY_SIZE(x))
#else
-#define IOMUX_PADS(x) MX6DL_##x
+#define IOMUX_PADS(x) MX6_##x
#define SETUP_IOMUX_PAD(def) \
- imx_iomux_v3_setup_pad(MX6DL_##def);
+ imx_iomux_v3_setup_pad(MX6_##def);
#define SETUP_IOMUX_PADS(x)\
imx_iomux_v3_setup_multiple_pads(x, ARRAY_SIZE(x))
#endif
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
