linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

u-boot + Android 'fastboot' protocol/commands support (was: [Android: device/linaro/common] Rename the kernel to uImage for Linaro Android build)

by Jim Huang

On 19 April 2011 14:28, Amit Pundir <pundiramit(a)gmail.com> wrote: > On Mon, Apr 18, 2011 at 8:31 PM, Alexander Sack <asac(a)linaro.org> wrote: >> On Mon, Apr 18, 2011 at 3:51 PM, Zach Pfeffer <pfefferz(a)gmail.com> wrote: >>> That would be very nice. There's actually some documentation in u-boot >>> about fastboot (a README). I wonder if there's some support already? >> Yes, I was told that someone (TI?) had a public tree with it. If all >> goes well, John (CCed) would review those, clean the patches up, >> upstream and integrate then into our u-boot branches so we can have >> them for our LEB builds as well. > > Rowboat also has a decent Fastboot support in u-boot for OMAP3 > http://gitorious.org/rowboat/u-boot-omap3 > Not all the Fastboot commands are supported though > http://wiki.tiprocessors.com/index.php/TI-Android-GingerBread-2.3-DevKit-1.… Hi Amit, Zach, and Alexander, Thanks for your sharing about u-boot + Android 'fastboot' protocol/commands support. At least, patched u-boot works out of box on TI OMAP platforms. Can we define the basic boot loader requirements of Linaro Evaluation Build (LEB) for Android at present? I think it would be essential for validation and Android platform verification purpose. My idea is that we require abstract 'bootloader' component in Android device/linaro/common, and (patched) 'u-boot' would be the provider of 'bootloader' component in device/linaro/Linaro-Evaluation-Build-Hardware. Also, supporting firmware upgrade through 'fastboot' protocol is the recommend feature for LEB boot loader. Does it sound reasonable? Thanks, -jserv

15 years, 1 month

Testing IGEP DT support (was: Device Tree on ARM status report - Mar 20)

by Grant Likely

Hi Mounir, Took me a while, but here are the instructions for testing DT support on IGEP: The current nightly u-boot builds should work out-of-the-box with device tree support. You can use the prebuilt binaries >From what I can tell, the kernel build doesn't yet have DT enabled for any of the platforms. I need to follow up with John Rigby about this to make sure I'm looking in the right place. You'll need to build the kernel. Pull the linaro 2.6.38 kernel tree: git://git.linaro.org/kernel/linux-linaro-2.6.38.git then: $ make omap2plus_defconfig $ vim .config /* turn on CONFIG_USE_OF and CONFIG_PROC_DEVICETREE */ $ make oldconfig uImage dtbs Copy the uImage and igep dtb files to the sdcard Make sure the old boot method still works Reboot and modify the boot command to load the dtb into ram about 64k below the initrd image and to use "bootm <kernel-addr> <initrd-addr> <dtb-addr>" to boot the kernel. Make sure stuff shows up in /proc/devicetree/. Also, send me your boot log. And that's it! On Mon, Mar 21, 2011 at 3:25 AM, Grant Likely <grant.likely(a)secretlab.ca> wrote: > I had great hopes of doing these status reports once a week; but it > turns out to take more effort to get together that I estimated. > Here's the status of ARM device tree support as of today. As always, > let me know if you have any corrections or additional information. > > 1 - Latest news > --------------- > - The last vestiges of of_platform_bus_type are gone from Linus' tree > as of the 2.6.39 merge window. Everything should be using > platform_device now. > - devicetree/arm on git://git.secretlab.ca/git/linux-2.6 has > everything needed to turn on basic device tree support for any > platform. > - Support has been added for Versatile and Tegra in devicetree/arm > - Support for Samsung s5pv310 and Freescale mx5 are in devicetree/test > - Similarly, u-boot needs to have the CONFIG_OF_LIBFDT and > CONFIG_SYS_BOOTMAPSZ defined to turn on device tree support. > - I've also got patches that eliminate the need for > CONFIG_SYS_BOOTMAPSZ which I'll post shortly, but they're not quite > working yet. > - I've also got a trivial patch that should enabled CONFIG_OF_LIBFDT > on a large set of boards, but it has had pretty much zero testing. > :-) > - Jason Hui has been making awesome progress on mx5, and some of their > patches are in devicetree/test. Hopefully to move over to > devicetree/arm soon. > - Shawn Guo has also been making good progress on adding the clock > bindings to the mx5 support. There are still questions up in the air > about the best way to handle clocks though. While all the clocks > /can/ be converted to device tree data, there is also value in sharing > clock initialization data between DT and non-DT board support. The > of_platform_device_prepare() work mentioned below will help with that. > It will also be easier to work on the clock support when the common > struct clk patch series from Jeremy gets merged. Until then there > ends up being a lot of duplication of code. > - Lennert has a series of virq patches for ARM patches completed. He > is currently working on cleaning them up to get them posted. > - Patches posted for of_platform_prepare() which makes it easier for > static platform_device registrations to co-exist with device tree > data. Patches are currently in devicetree/test, and will move to > devicetree/arm shortly. > - Basic DT support has been merged into Nicolas' Linaro kernel tree. > - DT is also working on Versatile Express, OMAP, and the new Xilinx > platform, but I don't have patches for either of those platforms in my > tree. > - Rob Herring's work on the early dtb mmu maping is mainlined and > makes it much nicer to work with dtbs. > > Next steps: > -------------- > At this point I'm putting on my Linaro hat. Feel free to tune out > past this point if you're not interested how DT support will > materialize in the next release. > > There are a number of very specific tasks that need to be completed > for the 11.05 release. The goal is to have basic device tree support > turned on and working on all of the platforms supported in the > release. There isn't a lot of time to get this pulled together, but > all the infrastructure is in places, so most of the work is turning on > the configuration options and testing the platforms. > > For each board, I need an engineer to do the following: > > 1) Enable CONFIG_OF_LIBFDT and CONFIG_SYS_BOOTMAPSZ against the Linaro > u-boot tree. > 2) Enable CONFIG_OF and CONFIG_PROC_DEVICETREE in the kernel > 3) Add something like the following to the *existing* machine > definition. For initial basic support, you don't need to create a > separate <soc>-dt.c board support file yet. > > +static const char *omap4_panda_dt_match[] __initdata = { > + "ti,omap4-panda", > + NULL > +}; > + > MACHINE_START(OMAP4_PANDA, "OMAP4 Panda board") > [...] > + .dt_compat = omap4_panda_dt_match, > MACHINE_END > > The string in the match table should be in the form "<vendor>,<board-name>" > > 4) Add a template .dts file for the board in > arch/arm/boot/dts/<board>.dts. The following should be sufficient: > > /dts-v1/; > > / { > model = "TI OMAP4 PandaBoard"; > compatible = "ti,omap4-panda"; > #address-cells = <1>; > #size-cells = <1>; > > aliases { > }; > > memory { > device_type = "memory"; > reg = <0x80000000 0x08000000>; > }; > > chosen { > }; > }; > 5) test it :-) > 6) send patches to me for inclusion in the Linaro U-Boot and Kernel > trees. I'll collect them to start and ask John and Nicolas to pull > them into their trees when they're ready. > > This is enough for very basic device tree support and I expect it will > only take a day or so of effort to get completed. It won't be > particularly useful, but it ensures that the infrastructure is enabled > and working. > > Bonus points if you're also able to provide patches that add > of_platform_device_probe() and of_platform_bus_populate() calls to the > board support so that device nodes get attached to the devices and can > be used for attaching things like gpios, spi devices, and i2c devices. > This is a nice to have for 11.05, but it isn't a requirement to have > it working on all boards. > > Here is the list of hwpacks that should be supported to the best of my > knowledge. Please reply with the hwpacks you can take responsibility > for: > > efikamx > igep > imx51 > omap3-x11-base > omap3 > overo > panda > s5pv310 > vexpress > > There are also some specific cross-platform tasks that need some love. > Let me know if you can take responsibility for any of these items. > - Eliminate CONFIG_SYS_BOOTMAPSZ dependency from U-Boot. I've got a > patch series that does this, but it is untested. I'll post the series > tomorrow. > - Add packaging of .dtb files into linux-image-linaro-* packages. > Loic and I discussed putting them under /lib/dtb/`uname -r`/, but > thinking about it more, it might make more sense to share the modules > directory and use /lib/modules/`uname -r`/dtbs. The dtc tool needed > to build the .dtbs is included with the kernel tree. > - Add relevant dtb files to boot partition in linaro-image tools > - Add boot script which passes dtb as 3rd argument to 'bootm' > > For purposes of tracking, I'll register bugs for the above items in > the Linaro bug tracker tomorrow. > > Cheers, > g. > > -- > Grant Likely, B.Sc., P.Eng. > Secret Lab Technologies Ltd. > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.

15 years, 1 month

[Android: device/linaro/common] Rename the kernel to uImage for Linaro Android build

by patrik.ryd＠linaro.org

From: Patrik Ryd <patrik.ryd(a)linaro.org> In the Linaro set up u-boot will look for uImage (and not for kernel). --- tasks/kernel.mk | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tasks/kernel.mk b/tasks/kernel.mk index a016d6e..f0ebb93 100644 --- a/tasks/kernel.mk +++ b/tasks/kernel.mk @@ -3,5 +3,5 @@ android_kernel: make ARCH=arm CROSS_COMPILE=../$(TARGET_TOOLS_PREFIX) defconfig $(KERNEL_CONFIG) &&\ make ARCH=arm CROSS_COMPILE=../$(TARGET_TOOLS_PREFIX) uImage -$(PRODUCT_OUT)/kernel: android_kernel - ln -sf ../../../../kernel/arch/arm/boot/uImage $(PRODUCT_OUT)/kernel \ No newline at end of file +$(PRODUCT_OUT)/uImage: android_kernel + ln -sf ../../../../kernel/arch/arm/boot/uImage $(PRODUCT_OUT)/uImage \ No newline at end of file -- 1.7.1

15 years, 1 month

[PATCH v2 Android: build.git 1/2] Rename the kernel to uImage for Linaro Android build

by Patrik Ryd

In the Linaro set up u-boot will look for uImage (and not for kernel). This patch is Linaro specific and should not be contibuted to AOSP. --- target/board/Android.mk | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/target/board/Android.mk b/target/board/Android.mk index 82dee3c..f3e4729 100644 --- a/target/board/Android.mk +++ b/target/board/Android.mk @@ -15,7 +15,7 @@ else endif # TARGET_NO_BOOTLOADER ifneq ($(strip $(TARGET_NO_KERNEL)),true) - INSTALLED_KERNEL_TARGET := $(PRODUCT_OUT)/kernel + INSTALLED_KERNEL_TARGET := $(PRODUCT_OUT)/uImage else INSTALLED_KERNEL_TARGET := endif -- 1.7.1

15 years, 1 month

[Android: build.git] Create uInitrd instead of ramdisk.img

by Patrik Ryd

In the Linaro set up u-boot will look for uImage and uInitrd. This patch is Linaro specific and should not be contibuted to AOSP. --- core/Makefile | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/core/Makefile b/core/Makefile index 857dd20..f75832a 100644 --- a/core/Makefile +++ b/core/Makefile @@ -309,13 +309,14 @@ INTERNAL_RAMDISK_FILES := $(filter $(TARGET_ROOT_OUT)/%, \ $(ALL_GENERATED_SOURCES) \ $(ALL_DEFAULT_INSTALLED_MODULES)) -BUILT_RAMDISK_TARGET := $(PRODUCT_OUT)/ramdisk.img +BUILT_RAMDISK_TARGET := $(PRODUCT_OUT)/uInitrd # We just build this directly to the install location. INSTALLED_RAMDISK_TARGET := $(BUILT_RAMDISK_TARGET) $(INSTALLED_RAMDISK_TARGET): $(MKBOOTFS) $(INTERNAL_RAMDISK_FILES) | $(MINIGZIP) $(call pretty,"Target ram disk: $@") - $(hide) $(MKBOOTFS) $(TARGET_ROOT_OUT) | $(MINIGZIP) > $@ + $(hide) $(MKBOOTFS) $(TARGET_ROOT_OUT) | $(MINIGZIP) > $(PRODUCT_OUT)/obj/temp_ramdisk.img + mkimage -A arm -O linux -T ramdisk -n "Android Ramdisk Image" -d $(PRODUCT_OUT)/obj/temp_ramdisk.img $@ ifneq ($(strip $(TARGET_NO_KERNEL)),true) -- 1.7.1

15 years, 1 month

[PATCH v2] S5P: GPIO Macro Values Corrected.

by Chander Kashyap

S5PC2XX: Macro values for Pull Up and Driver Strength were wrong. S5PC1XX: Macro values for Driver Strength were wrong. Signed-off-by: Chander Kashyap <chander.kashyap(a)linaro.org> --- Changes for V2: - Macro value order fixed. - Added Changes for S5PC1XX. arch/arm/include/asm/arch-s5pc1xx/gpio.h | 4 ++-- arch/arm/include/asm/arch-s5pc2xx/gpio.h | 7 +++---- 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/arch/arm/include/asm/arch-s5pc1xx/gpio.h b/arch/arm/include/asm/arch-s5pc1xx/gpio.h index 2df33a6..485b9bf 100644 --- a/arch/arm/include/asm/arch-s5pc1xx/gpio.h +++ b/arch/arm/include/asm/arch-s5pc1xx/gpio.h @@ -149,8 +149,8 @@ void gpio_set_rate(struct s5p_gpio_bank *bank, int gpio, int mode); /* Drive Strength level */ #define GPIO_DRV_1X 0x0 -#define GPIO_DRV_2X 0x1 -#define GPIO_DRV_3X 0x2 +#define GPIO_DRV_3X 0x1 +#define GPIO_DRV_2X 0x2 #define GPIO_DRV_4X 0x3 #define GPIO_DRV_FAST 0x0 #define GPIO_DRV_SLOW 0x1 diff --git a/arch/arm/include/asm/arch-s5pc2xx/gpio.h b/arch/arm/include/asm/arch-s5pc2xx/gpio.h index 05e5b3e..38303e4 100644 --- a/arch/arm/include/asm/arch-s5pc2xx/gpio.h +++ b/arch/arm/include/asm/arch-s5pc2xx/gpio.h @@ -99,14 +99,13 @@ void gpio_set_rate(struct s5p_gpio_bank *bank, int gpio, int mode); /* Pull mode */ #define GPIO_PULL_NONE 0x0 #define GPIO_PULL_DOWN 0x1 -#define GPIO_PULL_UP 0x2 +#define GPIO_PULL_UP 0x3 /* Drive Strength level */ #define GPIO_DRV_1X 0x0 -#define GPIO_DRV_2X 0x1 -#define GPIO_DRV_3X 0x2 +#define GPIO_DRV_3X 0x1 +#define GPIO_DRV_2X 0x2 #define GPIO_DRV_4X 0x3 #define GPIO_DRV_FAST 0x0 #define GPIO_DRV_SLOW 0x1 - #endif -- 1.7.1

15 years, 1 month

Working around a Tegra 2 errata for Natty

by Michael Hope

Hi there. There's a problem with the thread local storage register in the Tegra 2 which is exposed by Ubuntu switching to GCC 4.5. The fault is quite serious and causes many applications to segfault. There's more details in LP: #739374. The problem is Tegra 2 specific and is caused by bit 20 of the CP15 thread pointer register always reading as zero. With GCC 4.4, access to the thread pointer always goes through the GLIBC helper function '__aeabi_read_tp' which calls into the kernel which then reads and returns CP15. Either GLIBC or the kernel[1] itself swaps bit 20 and bit 0 which works around the problem. This doesn't work in GCC 4.5 as it reads CP15 directly instead. There are a few solutions: Change GCC to swap bits 20 and 0 as well. This is a hack and requires rebuilding the archive. The performance should be small. Change GCC to always call the helper function. The helper function can detect the processor and call into the kernel on Tegra devices, or return CP15 directly on others. IFUNC could be used to reduce the overhead. The archive would have to be rebuilt. Worse performance than above, but still better than 4.4. Change GLIBC to allocate thread local storage on a 2 M boundary. Bit 20 would always be zero. The thread pointer is a base address so the thread could still have more than 2 M of thread local data. GLIBC would have to be rebuilt and this limits the maximum number of threads. No runtime performance hit. I prefer changing GLIBC. Any thoughts? Linaro doesn't support this chip. Who should do the work? Linaro? Ubuntu? The EGLIBC community? -- Michael [1] Dave and I disagree where it is but neither have tracked it down

15 years, 1 month

[NOTES] 4/13 Linaro Developer Platform Weekly Status Meeting

by Tom Gall

Enclosed you'll find a link to the agenda, notes and actions from the Linaro Developer Platforms Weekly Status meeting held on April 13th in #linaro-meeting on irc.freenode.net at 15:00 UTC. https://wiki.linaro.org/Platform/DevPlatform/Meetings/2011-04-13 Actions from the meeting where as follows: * tgall_foo to check with GrueMaster for recommendations on checking minimal audio functionality on armel * fturgis to ask linaro-dev whether systemtap support for probing kernel modules is wanted * slangasek to check why armel-cross-toolchain-base FTBFS wasn't caught in lucas's archive rebuild * slangasek to review/merge/upload armel-cross-toolchain-base 1.62 Regards, Tom (tgall_foo) Developer Platforms Team "We want great men who, when fortune frowns will not be discouraged." - Colonel Henry Knox w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com

15 years, 1 month

Embedded memory management interest group list

by Jesse Barker

Hi all, One of the big issues we've been faced with at Linaro is around GPU and multimedia device integration, in particular the memory management requirements for supporting them on ARM. This next cycle, we'll be focusing on driving consensus around a unified memory management solution for embedded systems that support multiple architectures and SoCs. This is listed as part of our working set of requirements for the next six-month cycle (in spite of the URL, this is not being treated as a graphics-specific topic - we also have participation from multimedia and kernel working group folks): https://wiki.linaro.org/Cycles/1111/TechnicalTopics/Graphics I am working on getting the key technical decision makers to provide input and participate in the requirements collection and design for a unified solution. We had an initial birds-of-a-feather discussion at the Embedded Linux Conference in San Francisco this past week to kick off the effort in preparation for the first embedded-memory-management mini-sprint in Budapest week of May 9th at Linaro@UDS. One of the outcomes of the BoF was the need for a mailing list to coordinate ideas, planning, etc. The subscription management for the list is located at http://lists.linaro.org/mailman/listinfo/linaro-mm-sig. The mini-summit in Budapest will have live audio and an IRC channel for those that want to participate (details to go out on the list). We expect to have additional summits over the course of the cycle, with the next one likely at Linux Plumbers in September (though, I would like to try for one more before then). cheers, Jesse

15 years, 1 month

Embedded memory management interest group list

by Jesse Barker

15 years, 1 month

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev