* arm: Kernel failures when several memory banks are used with starting address above 128MB @ 2013-01-22 19:18 Michal Simek 2013-01-22 20:36 ` Nicolas Pitre 2013-01-23 9:15 ` Russell King - ARM Linux 0 siblings, 2 replies; 5+ messages in thread From: Michal Simek @ 2013-01-22 19:18 UTC (permalink / raw) To: linux-arm-kernel Hi, I have a question regarding to the case where DTS specify one memory bank for example <0x0 0x40000000> with CONFIG_ARM_PATCH_PHYS_VIRT=y where the kernel can be loaded at a 16MB boundary. I was testing it on the 3.8-rc4 on arm zynq. 1. If the kernel is loaded within 0 - 127MB memory then the kernel can work with the whole 1GB memory. It shows that the memory in front of the kernel is also available for the kernel. 2. If the kernel is loaded on the higher addresses then it fails by these error messages. "Ignoring RAM at 00000000-3fffffff (vmalloc region overlap). Memory policy: ECC disabled, Data cache writeback Kernel panic - not syncing: ERROR: Failed to allocate 0x1000 bytes below 0x0." 3. If I use several memory banks solution for example reg = <0 0x10000000 0x10000000 0x30000000>; and the kernel is loaded to 0x10008000 then the first memory bank is ignored and kernel will boot. "Ignoring RAM at 00000000-0fffffff (vmalloc region overlap)." with 768MB of memory. 4. The next interesting example is description with 3 memory banks. reg = <0 0x10000000 0x10000000 0x20000000 0x30000000 0x10000000>; which behaves as point 3. It means the first 128MB is ignored and only 768MB of ram is available. The real question is how the kernel should behave for these situations. I would expect that if the kernel is within one memory bank then it will use this whole bank Or I would expect that the memory which is in front of the kernel start address will be simple ignored and the kernel will find out which memory bank is used and will use it. Not just caused kernel panic. Or Is there any expectation that you have to run the relocatable kernel in the first 128MB of the memory or changing DTS depending on the kernel position where it is loaded? For me is important to solve the case 2 above which can be easily solved in mm/mmu.c in sanity_check_meminfo where bank->start and bank->size will be setup depends on kernel position. Another interesting case is to enable highmem. Kernel starts from 0x10008000 with one memory bank reg = <0x10000000 0x30000000>; which works without any problem But for the same case (enable highmem. Kernel starts from 0x10008000.) with two memory banks. reg = <0 0x10000000 0x10000000 0x30000000>; is failing with this error. "Machine: Xilinx Zynq Platform, model: Zynq ZC702 Development Board bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback Kernel panic - not syncing: ERROR: Failed to allocate 0x1000 bytes below 0x0." Also this is the case which quite weird because kernel with higmem on wants to use the first memory bank and then failed. My proposed solution is to ignore all memory banks which are in front of the kernel which ensure that these Thanks for your comments, Michal ^ permalink raw reply [flat|nested] 5+ messages in thread
* arm: Kernel failures when several memory banks are used with starting address above 128MB 2013-01-22 19:18 arm: Kernel failures when several memory banks are used with starting address above 128MB Michal Simek @ 2013-01-22 20:36 ` Nicolas Pitre 2013-01-25 10:36 ` Michal Simek 2013-01-23 9:15 ` Russell King - ARM Linux 1 sibling, 1 reply; 5+ messages in thread From: Nicolas Pitre @ 2013-01-22 20:36 UTC (permalink / raw) To: linux-arm-kernel On Tue, 22 Jan 2013, Michal Simek wrote: > Hi, > > I have a question regarding to the case where DTS specify one memory bank > for example <0x0 0x40000000> with CONFIG_ARM_PATCH_PHYS_VIRT=y > where the kernel can be loaded at a 16MB boundary. > I was testing it on the 3.8-rc4 on arm zynq. > > 1. If the kernel is loaded within 0 - 127MB memory then the kernel can > work with the whole > 1GB memory. It shows that the memory in front of the kernel is also > available for the kernel. > > 2. If the kernel is loaded on the higher addresses then it fails by > these error messages. > "Ignoring RAM at 00000000-3fffffff (vmalloc region overlap). > Memory policy: ECC disabled, Data cache writeback > Kernel panic - not syncing: ERROR: Failed to allocate 0x1000 bytes below 0x0." > > 3. If I use several memory banks solution > for example > reg = <0 0x10000000 0x10000000 0x30000000>; > and the kernel is loaded to 0x10008000 then the first memory bank is > ignored and kernel will boot. > "Ignoring RAM at 00000000-0fffffff (vmalloc region overlap)." with > 768MB of memory. > > 4. The next interesting example is description with 3 memory banks. > reg = <0 0x10000000 0x10000000 0x20000000 0x30000000 0x10000000>; > which behaves as point 3. It means the first 128MB is ignored and only > 768MB of ram is available. > > > The real question is how the kernel should behave for these situations. > I would expect that if the kernel is within one memory bank > then it will use this whole bank > Or > I would expect that the memory which is in front of the kernel start address > will be simple ignored and the kernel will find out which memory bank > is used and will use it. > Not just caused kernel panic. > Or > Is there any expectation that you have to run the relocatable kernel > in the first 128MB of the memory > or changing DTS depending on the kernel position where it is loaded? There are two kernel config symbols influencing this: config AUTO_ZRELADDR bool "Auto calculation of the decompressed kernel image address" depends on !ZBOOT_ROM && !ARCH_U300 help ZRELADDR is the physical address where the decompressed kernel image will be placed. If AUTO_ZRELADDR is selected, the address will be determined at run-time by masking the current IP with 0xf8000000. This assumes the zImage being placed in the first 128MB from start of memory. config ARM_PATCH_PHYS_VIRT bool "Patch physical to virtual translations at runtime" if EMBEDDED default y depends on !XIP_KERNEL && MMU depends on !ARCH_REALVIEW || !SPARSEMEM help Patch phys-to-virt and virt-to-phys translation functions at boot and module load time according to the position of the kernel in system memory. This can only be used with non-XIP MMU kernels where the base of physical memory is at a 16MB boundary. Only disable this option if you know that you do not require this feature (eg, building a kernel for a single machine) and you need to shrink the kernel to the minimal size. Of course, the kernel must be loaded at some address within the provided RAM information in DT as well. If you cannot meet those restrictions then the corresponding features have to be disabled in your build. Nicolas ^ permalink raw reply [flat|nested] 5+ messages in thread
* arm: Kernel failures when several memory banks are used with starting address above 128MB 2013-01-22 20:36 ` Nicolas Pitre @ 2013-01-25 10:36 ` Michal Simek 0 siblings, 0 replies; 5+ messages in thread From: Michal Simek @ 2013-01-25 10:36 UTC (permalink / raw) To: linux-arm-kernel Hi Nicolas, 2013/1/22 Nicolas Pitre <nicolas.pitre@linaro.org>: > On Tue, 22 Jan 2013, Michal Simek wrote: > >> Hi, >> >> I have a question regarding to the case where DTS specify one memory bank >> for example <0x0 0x40000000> with CONFIG_ARM_PATCH_PHYS_VIRT=y >> where the kernel can be loaded at a 16MB boundary. >> I was testing it on the 3.8-rc4 on arm zynq. >> >> 1. If the kernel is loaded within 0 - 127MB memory then the kernel can >> work with the whole >> 1GB memory. It shows that the memory in front of the kernel is also >> available for the kernel. >> >> 2. If the kernel is loaded on the higher addresses then it fails by >> these error messages. >> "Ignoring RAM at 00000000-3fffffff (vmalloc region overlap). >> Memory policy: ECC disabled, Data cache writeback >> Kernel panic - not syncing: ERROR: Failed to allocate 0x1000 bytes below 0x0." >> >> 3. If I use several memory banks solution >> for example >> reg = <0 0x10000000 0x10000000 0x30000000>; >> and the kernel is loaded to 0x10008000 then the first memory bank is >> ignored and kernel will boot. >> "Ignoring RAM at 00000000-0fffffff (vmalloc region overlap)." with >> 768MB of memory. >> >> 4. The next interesting example is description with 3 memory banks. >> reg = <0 0x10000000 0x10000000 0x20000000 0x30000000 0x10000000>; >> which behaves as point 3. It means the first 128MB is ignored and only >> 768MB of ram is available. >> >> >> The real question is how the kernel should behave for these situations. >> I would expect that if the kernel is within one memory bank >> then it will use this whole bank >> Or >> I would expect that the memory which is in front of the kernel start address >> will be simple ignored and the kernel will find out which memory bank >> is used and will use it. >> Not just caused kernel panic. >> Or >> Is there any expectation that you have to run the relocatable kernel >> in the first 128MB of the memory >> or changing DTS depending on the kernel position where it is loaded? > > There are two kernel config symbols influencing this: > > config AUTO_ZRELADDR > bool "Auto calculation of the decompressed kernel image address" > depends on !ZBOOT_ROM && !ARCH_U300 > help > ZRELADDR is the physical address where the decompressed kernel > image will be placed. If AUTO_ZRELADDR is selected, the address > will be determined at run-time by masking the current IP with > 0xf8000000. This assumes the zImage being placed in the first 128MB > from start of memory. > > config ARM_PATCH_PHYS_VIRT > bool "Patch physical to virtual translations at runtime" if EMBEDDED > default y > depends on !XIP_KERNEL && MMU > depends on !ARCH_REALVIEW || !SPARSEMEM > help > Patch phys-to-virt and virt-to-phys translation functions at > boot and module load time according to the position of the > kernel in system memory. > > This can only be used with non-XIP MMU kernels where the base > of physical memory is at a 16MB boundary. > > Only disable this option if you know that you do not require > this feature (eg, building a kernel for a single machine) and > you need to shrink the kernel to the minimal size. ok. This is on zynq platform which enables ARCH_MULTIPLATFORM. It means that both these options are enabled by default and > Of course, the kernel must be loaded at some address within the provided > RAM information in DT as well. If you cannot meet those restrictions > then the corresponding features have to be disabled in your build. Does it mean what Russel mention that within means from ram start address + 16MB (from my test that limit is 128MB - but maybe memory tests can find some bugs but the kernel boots) The fact is that I can't disabled these options because of ARCH_MULTIPLATFORM option. I am running AMP which means on the second ARM runs rtos. Rtos on the second cpu needs to access vectors started at 0x0 that's why I need to move the kernel to higher addresses. As I see from the exynos4210-origen.dts they use 4 memory banks memory { reg = <0x40000000 0x10000000 0x50000000 0x10000000 0x60000000 0x10000000 0x70000000 0x10000000>; }; I expect that kernel starting address is 0x40000000 (+0x8000) and everything works as expected but if they will try to use( without changing dts which describe exact and real hardware configuration) 0x50000000 starting address than kernel won't boot. What it is interesting on this is that Linux can work with all memory banks which are in DTS on higher addresses than starting address but can't work with memory banks which are on lower addresses. That's why I have created these patches (it is just c&p just to see what I am talking about) which ensure that kernel will boot not failed in these two cases. Case 1: The kernel starting address is at 0x10008000 dts memory reg = <0x0 0x40000000>; which ensure that kernel will work only with 0x10000000 - 0x40000000 address space Kernel bootlog will contain: "Change memory bank to 10000000-3fffffff" diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c index 9f06102..377d600 100644 --- a/arch/arm/mm/mmu.c +++ b/arch/arm/mm/mmu.c @@ -936,7 +936,26 @@ void __init sanity_check_meminfo(void) if (bank->start > ULONG_MAX) highmem = 1; + if (bank->start < __pa(PAGE_OFFSET) && + __pa(PAGE_OFFSET) <= (bank->start + bank->size - 1)) { + int offset = __pa(PAGE_OFFSET) - bank->start; + bank->start += offset; + bank->size -= offset; + pr_crit("Change memory bank to %.8llx-%.8llx\n", + (unsigned long long)bank->start, + (unsigned long long)bank->start + + bank->size - 1); + } + Case 2: In two bank solution with the kernel starting address at 0x10008000 will be the first bank ignored which ensure that HIGHMEM will work and kernel will boot reg = <0x0 0x10000000 0x10000000 0x30000000>; Kernel bootlog will contain: "Ignoring RAM at 00000000-0fffffff (CONFIG_HIGHMEM)." diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c index 048a199..377d600 100644 --- a/arch/arm/mm/mmu.c +++ b/arch/arm/mm/mmu.c @@ -948,6 +948,14 @@ void __init sanity_check_meminfo(void) } #ifdef CONFIG_HIGHMEM + if (__va(bank->start + bank->size - 1) < (void *)PAGE_OFFSET) { + pr_notice("Ignoring RAM@%.8llx-%.8llx " + "(CONFIG_HIGHMEM).\n", + (unsigned long long)bank->start, + (unsigned long long)bank->start + bank->size - 1); + continue; + } + if (__va(bank->start) >= vmalloc_min || __va(bank->start) < (void *)PAGE_OFFSET) highmem = 1; Also these two patches ensure that kernel can be placed to any memory location and will work with the rest of memory which is defined in the dts without changing dts to reflect different loading address. Thanks, Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian ^ permalink raw reply related [flat|nested] 5+ messages in thread
* arm: Kernel failures when several memory banks are used with starting address above 128MB 2013-01-22 19:18 arm: Kernel failures when several memory banks are used with starting address above 128MB Michal Simek 2013-01-22 20:36 ` Nicolas Pitre @ 2013-01-23 9:15 ` Russell King - ARM Linux 2013-01-25 7:56 ` Michal Simek 1 sibling, 1 reply; 5+ messages in thread From: Russell King - ARM Linux @ 2013-01-23 9:15 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jan 22, 2013 at 08:18:13PM +0100, Michal Simek wrote: > I have a question regarding to the case where DTS specify one memory bank > for example <0x0 0x40000000> with CONFIG_ARM_PATCH_PHYS_VIRT=y > where the kernel can be loaded at a 16MB boundary. That's where you're going wrong. We assume that the kernel is loaded within the 16MB of memory _always_. Can't get around this on a multiplatform kernel. ^ permalink raw reply [flat|nested] 5+ messages in thread
* arm: Kernel failures when several memory banks are used with starting address above 128MB 2013-01-23 9:15 ` Russell King - ARM Linux @ 2013-01-25 7:56 ` Michal Simek 0 siblings, 0 replies; 5+ messages in thread From: Michal Simek @ 2013-01-25 7:56 UTC (permalink / raw) To: linux-arm-kernel 2013/1/23 Russell King - ARM Linux <linux@arm.linux.org.uk>: > On Tue, Jan 22, 2013 at 08:18:13PM +0100, Michal Simek wrote: >> I have a question regarding to the case where DTS specify one memory bank >> for example <0x0 0x40000000> with CONFIG_ARM_PATCH_PHYS_VIRT=y >> where the kernel can be loaded at a 16MB boundary. > > That's where you're going wrong. We assume that the kernel is loaded > within the 16MB of memory _always_. Can't get around this on a > multiplatform kernel. Then please mentor me if why the case below also works without any visible problem. Loading address is 0x7008000. If there is requirement that the kernel should be loaded within the 16MB of memory why this case also works. What am I doing wrong? Thanks, Michal U-Boot 2013.01-00473-g4669149 (Jan 25 2013 - 08:46:13) I2C: ready DRAM: 1 GiB WARNING: Caches not enabled MMC: SDHCI: 0 SF: Detected N25Q128A with page size 64 KiB, total 16 MiB In: serial Out: serial Err: serial Net: Gem.e000b000 Hit any key to stop autoboot: 0 TFTPing Linux to RAM... Gem.e000b000 Waiting for PHY auto negotiation to complete... done Using Gem.e000b000 device TFTP from server 192.168.0.101; our IP address is 192.168.0.99 Filename 'uImage'. Load address: 0x3000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################ 2.4 MiB/s done Bytes transferred = 6420088 (61f678 hex) Gem.e000b000:7 is connected to Gem.e000b000. Reconnecting to Gem.e000b000 Gem.e000b000 Waiting for PHY auto negotiation to complete... done Using Gem.e000b000 device TFTP from server 192.168.0.101; our IP address is 192.168.0.99 Filename 'devicetree.dtb'. Load address: 0x2a00000 Loading: # 789.1 KiB/s done Bytes transferred = 3232 (ca0 hex) Gem.e000b000:7 is connected to Gem.e000b000. Reconnecting to Gem.e000b000 Gem.e000b000 Waiting for PHY auto negotiation to complete... done Using Gem.e000b000 device TFTP from server 192.168.0.101; our IP address is 192.168.0.99 Filename 'uramdisk.image.gz'. Load address: 0x2000000 Loading: ################################################################# ################################################################# ################################################################# ################################## 1.9 MiB/s done Bytes transferred = 3352699 (33287b hex) ## Booting kernel from Legacy Image at 03000000 ... Image Name: Linux-3.8.0-rc4+ Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 6420024 Bytes = 6.1 MiB Load Address: 07008000 Entry Point: 07008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 02000000 ... Image Name: Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 3352635 Bytes = 3.2 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02a00000 Booting using the fdt blob at 0x02a00000 Loading Kernel Image ... OK OK Loading Ramdisk to 1fccd000, end 1ffff83b ... OK Loading Device Tree to 1fcc9000, end 1fcccc9f ... OK Starting kernel ... Booting Linux on physical CPU 0x0 Linux version 3.8.0-rc4+ (monstr at monstr-desktop) (gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-50) ) #159 PREEMPT Fri Jan 25 08:20:25 CET 2013 CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine: Xilinx Zynq Platform, model: Zynq ZC702 Development Board bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096 Kernel command line: console=ttyPS0,115200 earlyprintk PID hash table entries: 4096 (order: 2, 16384 bytes) Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) __ex_table already sorted, skipping sort Memory: 1024MB = 1024MB total Memory: 1019804k/1019804k available, 28772k reserved, 270336K highmem Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) vmalloc : 0xf0000000 - 0xff000000 ( 240 MB) lowmem : 0xc0000000 - 0xef800000 ( 760 MB) pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) .text : 0xc0008000 - 0xc0681f24 (6632 kB) .init : 0xc0682000 - 0xc0fd3594 (9542 kB) .data : 0xc0fd4000 - 0xc0ff5360 ( 133 kB) .bss : 0xc0ff5360 - 0xc100bf40 ( 91 kB) NR_IRQS:16 nr_irqs:16 16 sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 4294967286ms Console: colour dummy device 80x30 Calibrating delay loop... 666.41 BogoMIPS (lpj=3332096) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok Setting up static identity map for 0x2f0db0 - 0x2f0de4 devtmpfs: initialized NET: Registered protocol family 16 DMA: preallocated 256 KiB pool for atomic coherent allocations L310 cache controller enabled l2x0: 8 ways, CACHE_ID 0x000000c0, AUX_CTRL 0x72360000, Cache size: 524288 B bio: create slab <bio-0> at 0 SCSI subsystem initialized Switching to clocksource ttc0.0 NET: Registered protocol family 2 TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP: reno registered UDP hash table entries: 512 (order: 1, 8192 bytes) UDP-Lite hash table entries: 512 (order: 1, 8192 bytes) NET: Registered protocol family 1 RPC: Registered named UNIX socket transport module. RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Trying to unpack rootfs image as initramfs... rootfs image is not initramfs (no cpio magic); looks like an initrd Freeing initrd memory: 3272K bounce pool size: 64 pages msgmni has been set to 1470 Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) io scheduler noop registered io scheduler deadline registered io scheduler cfq registered (default) e00^[??????[ttyPS0] enabled, bootconsole disabled console [ttyPS0] enabled, bootconsole disabled e0000000.uart: ttyPS1 at MMIO 0xe0000000 (irq = 59) is a xuartps brd: module loaded loop: module loaded st: Version 20101219, fixed bufsize 32768, s/g segs 256 osst :I: Tape driver with OnStream support version 0.99.4 osst :I: $Id: osst.c,v 1.73 2005/01/01 21:13:34 wriede Exp $ SCSI Media Changer driver v0.25 mousedev: PS/2 mouse device common for all mice sdhci: Secure Digital Host Controller Interface driver sdhci: Copyright(c) Pierre Ossman sdhci-pltfm: SDHCI platform and OF driver helper TCP: cubic registered NET: Registered protocol family 10 sit: IPv6 over IPv4 tunneling driver NET: Registered protocol family 17 VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4 Registering SWP/SWPB emulation handler Freeing init memory: 9540K Mounting proc: Mounting var: Populating /var: Running local start scripts. Mounting debugfs: Mounting sysfs: mdev: initialising /dev mdev: Registering hotplug handler /proc/mtd doesn't exist. Will not create /dev/flash/* device nodes Mounting devpts: Mounting all filesystem Setting hostname: Bringing up network interfaces: ip: SIOCGIFFLAGS: No such device Starting portmap: Starting uWeb server: Welcome to _____ _ _ _ | ___ \ | | | | (_) | |_/ / ___ | |_ __ _ | | _ _ __ _ _ __ __ | __/ / _ \| __| / _` || | | || '_ \ | | | |\ \/ / | | | __/| |_ | (_| || |____| || | | || |_| | > < \_| \___| \__| \__,_|\_____/|_||_| |_| \__,_|/_/\_\ on EDK_2D3D_FMC EDK_2D3D_FMC login: root Password: ~ # hexdump /proc/device-tree/memory/reg 0000000 0000 0000 0040 0000 0000008 ~ # Defconfig for this platform. CONFIG_EXPERIMENTAL=y # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SYSVIPC=y CONFIG_HIGH_RES_TIMERS=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="rootfs.cpio" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS_ALL=y CONFIG_EMBEDDED=y CONFIG_SLAB=y CONFIG_PARTITION_ADVANCED=y # CONFIG_EFI_PARTITION is not set CONFIG_ARCH_ZYNQ=y CONFIG_SWP_EMULATE=y CONFIG_PREEMPT=y CONFIG_AEABI=y # CONFIG_OABI_COMPAT is not set CONFIG_HIGHMEM=y CONFIG_HIGHPTE=y # CONFIG_COMPACTION is not set CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_CMDLINE="console=ttyPS0,115200n8 root=/dev/ram rw initrd=0x00800000,16M earlyprintk mtdparts=physmap-flash.0:512K(nor-fsbl),512K(nor-u-boot),5M(nor-linux),9M(nor-user),1M(nor-scratch),-(nor-rootfs)" CONFIG_VFP=y CONFIG_NEON=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set # CONFIG_SUSPEND is not set CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_INET=y # CONFIG_WIRELESS is not set CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_EXTRA_FIRMWARE="test" CONFIG_PROC_DEVICETREE=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=16384 CONFIG_SCSI=y CONFIG_SCSI_TGT=y CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y CONFIG_CHR_DEV_OSST=y CONFIG_BLK_DEV_SR=y CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=y CONFIG_CHR_DEV_SCH=y CONFIG_NETDEVICES=y # CONFIG_NET_VENDOR_BROADCOM is not set # CONFIG_NET_VENDOR_FARADAY is not set # CONFIG_NET_VENDOR_INTEL is not set # CONFIG_NET_VENDOR_MARVELL is not set # CONFIG_NET_VENDOR_MICREL is not set # CONFIG_NET_VENDOR_MICROCHIP is not set # CONFIG_NET_VENDOR_NATSEMI is not set # CONFIG_NET_VENDOR_SEEQ is not set # CONFIG_NET_VENDOR_SMSC is not set # CONFIG_NET_VENDOR_STMICRO is not set CONFIG_PHYLIB=y # CONFIG_WLAN is not set # CONFIG_LEGACY_PTYS is not set CONFIG_SERIAL_XILINX_PS_UART=y CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y # CONFIG_HW_RANDOM is not set CONFIG_I2C=y CONFIG_SPI=y # CONFIG_HWMON is not set CONFIG_WATCHDOG=y CONFIG_WATCHDOG_CORE=y CONFIG_FB=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FONTS=y CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y CONFIG_LOGO=y # CONFIG_USB_SUPPORT is not set CONFIG_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_PLTFM=y CONFIG_UIO=y CONFIG_UIO_PDRV_GENIRQ=y # CONFIG_IOMMU_SUPPORT is not set CONFIG_VIRT_DRIVERS=y CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT3_FS=y CONFIG_EXT4_FS=y # CONFIG_DNOTIFY is not set CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_TMPFS=y CONFIG_NFS_FS=y CONFIG_NFS_V3_ACL=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_737=y CONFIG_NLS_CODEPAGE_775=y CONFIG_NLS_CODEPAGE_850=y CONFIG_NLS_CODEPAGE_852=y CONFIG_NLS_CODEPAGE_855=y CONFIG_NLS_CODEPAGE_857=y CONFIG_NLS_CODEPAGE_860=y CONFIG_NLS_CODEPAGE_861=y CONFIG_NLS_CODEPAGE_862=y CONFIG_NLS_CODEPAGE_863=y CONFIG_NLS_CODEPAGE_864=y CONFIG_NLS_CODEPAGE_865=y CONFIG_NLS_CODEPAGE_866=y CONFIG_NLS_CODEPAGE_869=y CONFIG_NLS_CODEPAGE_936=y CONFIG_NLS_CODEPAGE_950=y CONFIG_NLS_CODEPAGE_932=y CONFIG_NLS_CODEPAGE_949=y CONFIG_NLS_CODEPAGE_874=y CONFIG_NLS_ISO8859_8=y CONFIG_NLS_CODEPAGE_1250=y CONFIG_NLS_CODEPAGE_1251=y CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_ISO8859_2=y CONFIG_NLS_ISO8859_3=y CONFIG_NLS_ISO8859_4=y CONFIG_NLS_ISO8859_5=y CONFIG_NLS_ISO8859_6=y CONFIG_NLS_ISO8859_7=y CONFIG_NLS_ISO8859_9=y CONFIG_NLS_ISO8859_13=y CONFIG_NLS_ISO8859_14=y CONFIG_NLS_ISO8859_15=y CONFIG_NLS_KOI8_R=y CONFIG_NLS_KOI8_U=y CONFIG_NLS_UTF8=y # CONFIG_ENABLE_WARN_DEPRECATED is not set # CONFIG_ENABLE_MUST_CHECK is not set CONFIG_DEBUG_FS=y # CONFIG_SCHED_DEBUG is not set # CONFIG_DEBUG_PREEMPT is not set CONFIG_DEBUG_INFO=y CONFIG_DEBUG_SG=y # CONFIG_FTRACE is not set CONFIG_SAMPLES=y CONFIG_DEBUG_USER=y CONFIG_DEBUG_LL=y CONFIG_DEBUG_ZYNQ_UART1=y CONFIG_EARLY_PRINTK=y -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-01-25 10:36 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-01-22 19:18 arm: Kernel failures when several memory banks are used with starting address above 128MB Michal Simek 2013-01-22 20:36 ` Nicolas Pitre 2013-01-25 10:36 ` Michal Simek 2013-01-23 9:15 ` Russell King - ARM Linux 2013-01-25 7:56 ` Michal Simek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).