* Re: Need help adding platform UIO devices to board
From: Nicholas Mc Guire @ 2012-11-28 19:03 UTC (permalink / raw)
To: Alexander Varnin; +Cc: linux-embedded
In-Reply-To: <50B65DA3.9000707@mail.ru>
On Wed, 28 Nov 2012, Alexander Varnin wrote:
> Hello!
> I'm trying to add UIO device to my system to handle interrupt. But i'm
> facing following problem. Docs says, on reading device /dev/uio0 it will
> block until interrupt occurs. I've made simple program for test. It
> tries to write 1 to enable interrupts.
>
> #include <unistd.h>
> #include <errno.h>
> #include <fcntl.h>
> #include <stdio.h>
>
> int main()
> {
> int fd;
> char c = 1;
> fd = open("/dev/uio0", O_RDONLY);
> if (fd<0) {
> printf("open error: %d\n", errno);
> return 0;
> }
> printf("fd == %d\n", fd);
> int res = write(fd, &c, 1);
> if(res<0) {
> printf("write error: %d\n", errno);
> }
> return 0;
> }
>
open O_RDONLY and then write to it ?
return of 9 == EBADF
man 2 write
EBADF fd is not a valid file descriptor or is not open for writing.
hofrat
^ permalink raw reply
* Need help adding platform UIO devices to board
From: Alexander Varnin @ 2012-11-28 18:53 UTC (permalink / raw)
To: linux-embedded
Hello!
I'm trying to add UIO device to my system to handle interrupt. But i'm
facing following problem. Docs says, on reading device /dev/uio0 it will
block until interrupt occurs. I've made simple program for test. It
tries to write 1 to enable interrupts.
#include <unistd.h>
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
int main()
{
int fd;
char c = 1;
fd = open("/dev/uio0", O_RDONLY);
if (fd<0) {
printf("open error: %d\n", errno);
return 0;
}
printf("fd == %d\n", fd);
int res = write(fd, &c, 1);
if(res<0) {
printf("write error: %d\n", errno);
}
return 0;
}
And as the output i get
fd ==
3
write error: 9
error 9 means "bad file descriptor". File /dev/uio0 is here.
/sys/class/uio/uio0 folder i also. Reading are fails the same way.
Here is how i add device to the system in board specific code
static struct uio_info cross_uio_info = {
.name = "uio_mcross",
.version = "0.1",
.irq = IRQ_EINT14,
.irq_flags = 0,
};
static struct platform_device minipos_cross_device = {
.name = "uio_pdrv_genirq",
.id = -1,
.dev = {
.platform_data = &cross_uio_info,
}
};
and then add platform device.
Please, help.
^ permalink raw reply
* [FOSDEM] Embedded and mobile devroom CFP
From: Geert Uytterhoeven @ 2012-11-13 17:54 UTC (permalink / raw)
To: CE Linux Developers List, Linux Embedded
Every year there is a special dedicated track for embedded and mobile
projects at Fosdem (see: http://www.fosdem.org/). If you are interested to
highlight or give a talk about your project check out the cfp.
FOSDEM will be held the 2nd and 3th of February 2013 in Brussels,
Belgium. As usual and for the 10th time there will be an embedded and
mobile room.
For this years program we are looking for people who would like to do
a presentation about their or their community's projects in this area.
These projects must be Free Software or Open Source.
For example involvement and experiences with projects like Arduino,
Tizen, Jolla, Mer, Beagleboard, Openembedded, Android, OpenWrt, Yocto,
Linaro... Kernel hacks for maximising memory usage, using filesystems
on flash, power management, ...
We are also interested in short tutorials, project overviews,
achievements, ports to new hardware and hardware hacking, real life
deployments, ... all are welcome and all submissions will be reviewed
by our panel.
Submissions require a small abstract and short speaker presentation
and should be submitted to fosdem.embedded at gmail.com before the 25th
of December 2012
The panel consists of:
Philippe De Swert
Peter De Schrijver
Thomas Petazzoni
Geert Uytterhoeven
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* no console prompt after booting kernel
From: herve bourricaud @ 2012-10-02 15:00 UTC (permalink / raw)
To: linux-embedded
hello,
I'am new to linux and try to add a new board based on AT91SAM9263 cpu on a linux
kernel (last stable version 3.5.4-rc5
I' compiled at91loader and u-boot 2012-07
adding a new board IACA_122101 with MACH_ID 4173
I clone last stable kernel
and start adding a new board IACA_122101
(design is based on an EMBEST sam6300i forthose who know this boards...)
kernel compile OK
I clone buildroot 2012 in order to generate the rootfs
for my kernel ! I add a new board IACA_122101
all seems ok for me...
my problem is that after booting
the system do not prompt for the login
it just echo back the key I send using my terminal !
here are my inittab and a copy of my console output !
hope someone can help !
////////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////
# /etc/inittab
#
# Copyright (C) 2001 Erik Andersen <andersen@codepoet.org>
#
# Note: BusyBox init doesn't support runlevels. The runlevels field is
# completely ignored by BusyBox init. If you want runlevels, use
# sysvinit.
#
# Format for each entry: <id>:<runlevels>:<action>:<process>
#
# id == tty to run on, or empty for /dev/console
# runlevels == ignored
# action == one of sysinit, respawn, askfirst, wait, and once
# process == program to run
# Startup the system
null::sysinit:/bin/mount -t proc proc /proc
null::sysinit:/bin/mount -o remount,rw / # REMOUNT_ROOTFS_RW
null::sysinit:/bin/mkdir -p /dev/pts
null::sysinit:/bin/mkdir -p /dev/shm
null::sysinit:/bin/mount -a
null::sysinit:/bin/hostname -F /etc/hostname
# now run any rc scripts
::sysinit:/etc/init.d/rcS
# Put a getty on the serial port
ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100 # GENERIC_SERIAL
# Stuff to do for the 3-finger salute
::ctrlaltdel:/sbin/reboot
# Stuff to do before rebooting
null::shutdown:/etc/init.d/rcK
null::shutdown:/bin/umount -a -r
null::shutdown:/sbin/swapoff -a
////////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////
IACA U-Boot> boot
NAND read: device 0 offset 0x1a0000, size 0x400000
4194304 bytes read: OK
## Current stack ends at 0x23eb36f8 * kernel: default image load address =
0x22000000
## Booting kernel from Legacy Image at 22000000 ...
Image Name: LINUX-3.6.0-rc5
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2425224 Bytes = 2.3 MiB
Load Address: 20008000
Entry Point: 20008000
Verifying Checksum ... OK
kernel data at 0x22000040, len = 0x00250188 (2425224)
## No init Ramdisk
ramdisk start = 0x00000000, ramdisk end = 0x00000000
Loading Kernel Image ... OK
OK
kernel loaded at 0x20008000, end = 0x20258188
using: ATAGS
## Transferring control to Linux (at address 20008000)...
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0
[ 0.000000] Linux version 3.6.0-rc5-00003-g4bebd05-dirty (iaca@linux1) (gcc
version 4.5.2 (Sourcery G++ Lite 2011.03-41) ) #27 Tue Oct 2 15:44:50 CEST 2012
[ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] Machine: IACA 122101
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] AT91: Detected soc type: at91sam9263
[ 0.000000] AT91: Detected soc subtype: Unknown
[ 0.000000] AT91: sram at 0x300000 of 0x14000 mapped at 0xfef64000
[ 0.000000] AT91: sram at 0x500000 of 0x4000 mapped at 0xfef60000
[ 0.000000] Clocks: CPU 198 MHz, master 99 MHz, main 18.432 MHz
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 16256
[ 0.000000] Kernel command line: console=ttyS0,115200 root=ubi0:rootfs
ubi.mtd=6 rootfstype=ubifs
[ 0.000000] PID hash table entries: 256 (order: -2, 1024 bytes)
[ 0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.000000] Memory: 64MB = 64MB total
[ 0.000000] Memory: 60808k/60808k available, 4728k reserved, 0K highmem
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
[ 0.000000] vmalloc : 0xc4800000 - 0xff000000 ( 936 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xc4000000 ( 64 MB)
[ 0.000000] .text : 0xc0008000 - 0xc03a77a0 (3710 kB)
[ 0.000000] .init : 0xc03a8000 - 0xc03c7068 ( 125 kB)
[ 0.000000] .data : 0xc03c8000 - 0xc03f1080 ( 165 kB)
[ 0.000000] .bss : 0xc03f10a4 - 0xc04058a8 ( 83 kB)
[ 0.000000] NR_IRQS:16 nr_irqs:16 16
[ 0.000000] AT91: 160 gpio irqs in 5 banks
[ 0.000000] sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps
every 4294967286ms
[ 0.000000] Console: colour dummy device 80x30
[ 0.090000] Calibrating delay loop... 98.71 BogoMIPS (lpj=493568)
[ 0.090000] pid_max: default: 32768 minimum: 301
[ 0.090000] Mount-cache hash table entries: 512
[ 0.090000] CPU: Testing write buffer coherency: ok
[ 0.090000] Setting up static identity map for 0x20302ba0 - 0x20302bf8
[ 0.100000] NET: Registered protocol family 16
[ 0.100000] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.110000] Console: colour dummy device 80x30
[ 0.120000] AT91: Power Management
[ 0.120000] AT91: Starting after user reset
[ 0.180000] usbcore: registered new interface driver usbfs
[ 0.180000] usbcore: registered new interface driver hub
[ 0.180000] usbcore: registered new device driver usb
[ 0.190000] Switching to clocksource tcb_clksrc
[ 0.260000] NET: Registered protocol family 2
[ 0.260000] TCP established hash table entries: 2048 (order: 2, 16384 bytes)
[ 0.260000] TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.260000] TCP: Hash tables configured (established 2048 bind 2048)
[ 0.260000] TCP: reno registered
[ 0.260000] UDP hash table entries: 256 (order: 0, 4096 bytes)
[ 0.260000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[ 0.260000] NET: Registered protocol family 1
[ 0.260000] RPC: Registered named UNIX socket transport module.
[ 0.260000] RPC: Registered udp transport module.
[ 0.260000] RPC: Registered tcp transport module.
[ 0.260000] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.270000] NFS: Registering the id_resolver key type
[ 0.270000] Key type id_resolver registered
[ 0.270000] Key type id_legacy registered
[ 0.270000] msgmni has been set to 118
[ 0.280000] atmel_lcdfb atmel_lcdfb.0: 255KiB frame buffer at 23940000
(mapped at c484d000)
[ 0.340000] Console: switching to colour frame buffer device 60x34
[ 0.360000] atmel_lcdfb atmel_lcdfb.0: fb0: Atmel LCDC at 0x00700000 (mapped
at c4846000), irq 42
[ 0.380000] atmel_usart.0: ttyS0 at MMIO 0xffffee00 (irq = 17) is a
ATMEL_SERIAL
[ 0.700000] console [ttyS0] enabled
[ 0.740000] atmel_nand: Use On Flash BBT
[ 0.740000] atmel_nand atmel_nand: No DMA support for NAND access.
[ 0.750000] NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND
128MiB 3,3V 8-bit), page size: 2048, OOB size: 64
[ 0.760000] Bad block table found at page 65472, version 0x01
[ 0.770000] Bad block table found at page 65408, version 0x01
[ 0.770000] Creating 7 MTD partitions on "atmel_nand":
[ 0.780000] 0x000000000000-0x000000020000 : "AT91Bootstrap"
[ 0.790000] 0x000000020000-0x000000060000 : "U-Boot"
[ 0.800000] 0x000000060000-0x000000080000 : "U-Boot Env 1"
[ 0.810000] 0x000000080000-0x0000000a0000 : "U-Boot Env 2"
[ 0.820000] 0x0000000a0000-0x0000001a0000 : "Logo"
[ 0.830000] 0x0000001a0000-0x0000005a0000 : "Kernel"
[ 0.840000] 0x0000005a0000-0x0000045a0000 : "Rootfs"
[ 0.850000] UBI: attaching mtd6 to ubi0
[ 0.850000] UBI: physical eraseblock size: 131072 bytes (128 KiB)
[ 0.860000] UBI: logical eraseblock size: 129024 bytes
[ 0.870000] UBI: smallest flash I/O unit: 2048
[ 0.870000] UBI: sub-page size: 512
[ 0.880000] UBI: VID header offset: 512 (aligned 512)
[ 0.880000] UBI: data offset: 2048
[ 1.000000] atmel_lcdfb atmel_lcdfb.0: FIFO underflow 0x10
[ 1.010000] UBI: max. sequence number: 92
[ 1.030000] UBI: attached mtd6 to ubi0
[ 1.030000] UBI: MTD device name: "Rootfs"
[ 1.040000] UBI: MTD device size: 64 MiB
[ 1.040000] UBI: number of good PEBs: 512
[ 1.050000] UBI: number of bad PEBs: 0
[ 1.050000] UBI: number of corrupted PEBs: 0
[ 1.060000] UBI: max. allowed volumes: 128
[ 1.060000] UBI: wear-leveling threshold: 4096
[ 1.070000] UBI: number of internal volumes: 1
[ 1.070000] UBI: number of user volumes: 1
[ 1.080000] UBI: available PEBs: 0
[ 1.080000] UBI: total number of reserved PEBs: 512
[ 1.090000] UBI: number of PEBs reserved for bad PEB handling: 10
[ 1.090000] UBI: max/mean erase counter: 2/0
[ 1.100000] UBI: image sequence number: 2141504005
[ 1.100000] UBI: background thread "ubi_bgt0d" started, PID 275
[ 1.140000] libphy: MACB_mii_bus: probed
[ 1.140000] macb macb: eth0: Cadence MACB at 0xfffbc000 irq 37
(de:ad:be:ef:01:01)
[ 1.150000] macb macb: eth0: attached PHY driver [Davicom DM9161A]
(mii_bus:phy_addr=macb-ffffffff:00, irq=-1)
[ 1.160000] PPP generic driver version 2.4.2
[ 1.170000] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 1.180000] at91_ohci at91_ohci: can't request overcurrent gpio 0
[ 1.180000] at91_ohci at91_ohci: can't request overcurrent gpio 0
[ 1.190000] at91_ohci at91_ohci: can't request overcurrent gpio 0
[ 1.200000] at91_ohci at91_ohci: AT91 OHCI
[ 1.210000] at91_ohci at91_ohci: new USB bus registered, assigned bus number
1
[ 1.210000] at91_ohci at91_ohci: irq 45, io mem 0x00a00000
[ 1.290000] hub 1-0:1.0: USB hub found
[ 1.290000] hub 1-0:1.0: 2 ports detected
[ 1.300000] usbcore: registered new interface driver usbserial
[ 1.310000] usbcore: registered new interface driver usbserial_generic
[ 1.320000] USB Serial support registered for generic
[ 1.320000] usbserial: USB Serial Driver core
[ 1.330000] usbcore: registered new interface driver ftdi_sio
[ 1.330000] USB Serial support registered for FTDI USB Serial Device
[ 1.340000] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver
[ 1.350000] usbcore: registered new interface driver pl2303
[ 1.360000] USB Serial support registered for pl2303
[ 1.360000] mousedev: PS/2 mouse device common for all mice
[ 1.370000] rtc-at91sam9 rtc-at91sam9.0: rtc core: registered rtc-at91sam9 as
rtc0
[ 1.380000] rtc-at91sam9 rtc-at91sam9.0: rtc0: SET TIME!
[ 1.390000] at91sam9_wdt: sorry, watchdog is disabled
[ 1.390000] at91_wdt: probe of at91_wdt failed with error -5
[ 1.410000] usbcore: registered new interface driver usbhid
[ 1.420000] usbhid: USB HID core driver
[ 1.430000] IPv4 over IPv4 tunneling driver
[ 1.440000] TCP: cubic registered
[ 1.440000] NET: Registered protocol family 10
[ 1.450000] sit: IPv6 over IPv4 tunneling driver
[ 1.460000] NET: Registered protocol family 17
[ 1.470000] NET: Registered protocol family 15
[ 1.470000] Key type dns_resolver registered
[ 1.490000] input: gpio-keys as /devices/platform/gpio-keys/input/input0
[ 1.500000] rtc-at91sam9 rtc-at91sam9.0: hctosys: unable to read the hardware
clock
[ 1.580000] UBIFS: recovery needed
[ 1.900000] atmel_lcdfb atmel_lcdfb.0: FIFO underflow 0x10
[ 1.910000] atmel_lcdfb atmel_lcdfb.0: FIFO underflow 0x10
[ 1.920000] UBIFS: recovery completed
[ 1.920000] UBIFS: mounted UBI device 0, volume 0, name "rootfs"
[ 1.930000] UBIFS: file system size: 62834688 bytes (61362 KiB, 59 MiB, 487
LEBs)
[ 1.940000] UBIFS: journal size: 9033728 bytes (8822 KiB, 8 MiB, 71
LEBs)
[ 1.940000] UBIFS: media format: w4/r0 (latest is w4/r0)
[ 1.950000] UBIFS: default compressor: none
[ 1.950000] UBIFS: reserved for root: 0 bytes (0 KiB)
[ 1.960000] VFS: Mounted root (ubifs filesystem) on device 0:8.
[ 1.970000] Freeing init memory: 124K
Starting logging: OK
Starting mdev...
[ 3.040000] atmel_lcdfb atmel_lcdfb.0: FIFO underflow 0x10
[ 3.320000] atmel_lcdfb atmel_lcdfb.0: FIFO underflow 0x10
Starting network...
Generating RSA Key...
[ 4.530000] atmel_lcdfb atmel_lcdfb.0: FIFO underflow 0x10
PRNG is not seeded
Generating RSA Key...
[ 4.680000] atmel_lcdfb atmel_lcdfb.0: FIFO underflow 0x10
[ 4.690000] atmel_lcdfb atmel_lcdfb.0: FIFO underflow 0x10
PRNG is not seeded
Generating DSA Key...
THIS CAN TAKE A MINUTE OR TWO DEPENDING ON YOUR PROCESSOR!
[ 4.770000] atmel_lcdfb atmel_lcdfb.0: FIFO underflow 0x10
PRNG is not seeded
Generating ECDSA Key...
THIS CAN TAKE A MINUTE OR TWO DEPENDING ON YOUR PROCESSOR!
PRNG is not seeded
Starting sshd: [ 4.920000] atmel_lcdfb atmel_lcdfb.0: FIFO underflow 0x10
PRNG is not seeded
OK
[ 17.040000] atmel_lcdfb atmel_lcdfb.0: FIFO underflow 0x10
[ 27.040000] atmel_lcdfb atmel_lcdfb.0: FIFO underflow 0x10
^ permalink raw reply
* LDT - Linux Driver Template
From: Constantine Shulyupin @ 2012-10-01 12:18 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <CAGZ04WWmsoXCt0nfYMz5qYFLSLutiWUEMKc7b4Esjpzv4k0kNA@mail.gmail.com>
Hi,
I develop LDT - Linux Driver Template. It can be used as starting
point of development custom device driver and for learning development
of Linux device drivers.
Documentation: https://github.com/makelinux/ldt/blob/master/README.md
The driver uses following Linux facilities: module, platform driver,
file operations (read/write, mmap, ioctl, blocking and nonblocking
mode, polling), kfifo, completion, interrupt, tasklet, work, kthread,
timer, misc device, proc fs, UART 0x3f8, HW loopback, SW loopback,
ftracer.
To test the driver just run
git clone git://github.com/makelinux/ldt.git && cd ldt && ./ldt-test
You feedback, suggestions, discussions, recommendations patched will
be greatly appreciated!
Thanks
--
Constantine Shulyupin
http://www.MakeLinux.com/
Embedded Linux Systems,
Device Drivers, TI DaVinci
^ permalink raw reply
* Re: History of embedded Linux
From: Jeff Osier-Mixon @ 2012-09-04 17:28 UTC (permalink / raw)
To: chris; +Cc: linux-embedded
In-Reply-To: <500D66F5.5030906@2net.co.uk>
Looks like an excellent start. I think it would be good to add
OpenEmbedded and the Yocto Project - I'll try to get some key dates
together.
On Mon, Jul 23, 2012 at 8:00 AM, Chris Simmonds
<chris.simmonds@2net.co.uk> wrote:
> Hi,
>
> This is a little off-topic, but I have a bee in my bonnet about documenting
> where "embedded Linux" came from. As a starting point, I have written up a
> time line of key events, which is here
>
> http://embedded-linux.co.uk/embedded-history
>
> I am aware that there is a lot that I have missed, or misunderstood, so if
> you have a few minutes to spare perhaps you could have a look at it and tell
> me what I have got wrong. I am not sure where I am going with this, but I
> would like to use it as the basis of a longer document/web site/garden shed
> on the topic of the evolution of Linux as an embedded operating system.
>
> Oh, one last thing. If someone has some reasonably reliable figures of the
> numbers of Linux products shipped, that would be nice. Ideally I would like
> a graph that goes from zero in 1995 to NNN million in 2012. I know, its a
> dream, can't be done...
>
> Bye for now,
> Chris Simmonds
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org
^ permalink raw reply
* [PATCH] lib/decompress.c adding __init to decompress_method and data
From: Hein Tibosch @ 2012-08-31 6:24 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux-embedded, Linux Kernel Mailing List, Andrew Morton,
Albin Tonnerre, Phillip Lougher, hpa
Every time when compiling a new Linux kernel, I'm surprised that
this warning still occurs:
WARNING: vmlinux.o(.text+0x14cfd8): Section mismatch in
reference from the variable compressed_formats to the function
.init.text:gunzip()
The function compressed_formats() references
the function __init gunzip().
etc..
This patch should solve it:
Within decompress.c, compressed_formats[] needs 'a __initdata annotation', because
some of it's data members refer to functions which will be unloaded after init.
Consequently, it's user decompress_method() will get the __init prefix.
Signed-off-by: Hein Tibosch <hein_tibosch@yahoo.es>
---
lib/decompress.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/lib/decompress.c b/lib/decompress.c
index 3d766b7..31a8042 100644
--- a/lib/decompress.c
+++ b/lib/decompress.c
@@ -14,6 +14,7 @@
#include <linux/types.h>
#include <linux/string.h>
+#include <linux/init.h>
#ifndef CONFIG_DECOMPRESS_GZIP
# define gunzip NULL
@@ -31,11 +32,13 @@
# define unlzo NULL
#endif
-static const struct compress_format {
+struct compress_format {
unsigned char magic[2];
const char *name;
decompress_fn decompressor;
-} compressed_formats[] = {
+};
+
+static const struct compress_format compressed_formats[] __initdata = {
{ {037, 0213}, "gzip", gunzip },
{ {037, 0236}, "gzip", gunzip },
{ {0x42, 0x5a}, "bzip2", bunzip2 },
@@ -45,7 +48,7 @@ static const struct compress_format {
{ {0, 0}, NULL, NULL }
};
-decompress_fn decompress_method(const unsigned char *inbuf, int len,
+decompress_fn __init decompress_method(const unsigned char *inbuf, int len,
const char **name)
{
const struct compress_format *cf;
--
1.7.8.0
^ permalink raw reply related
* Re: Expose system Serial Number to userspace.
From: Nicolas Pitre @ 2012-08-29 20:52 UTC (permalink / raw)
To: Brad Arnold; +Cc: linux-embedded
In-Reply-To: <CADoavCcgYy_PrGkiO3rGZNvg6C1uKFQtqHffR=BviPKiWjdgvQ@mail.gmail.com>
On Wed, 29 Aug 2012, Brad Arnold wrote:
> On Wed, Aug 29, 2012 at 9:50 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> >
> > On Wed, 29 Aug 2012, Brad Arnold wrote:
> >
> > > Hi,
> > >
> > > I'm working on an embedded board which uses u-boot + linux. At
> > > manufacturing time, the device serial number will be programmed into OTP
> > > memory on NAND (probably from within u-boot). We'd like the linux kernel
> > > to make this serial number available to be read from userspace. Is there
> > > an accepted method to do this sort of thing?
> >
> > A serial number field is available from /proc/cpuinfo already. you just
> > have to initialize it through the system_serial_high and
> > system_serial_low global variables.
> >
> >
> > Nicolas
>
> Actually, I guess even better than initializing through the two
> variables is to pass the serial directly from u-boot using the tag.
Yes, if you are still using ATAGs.
Nicolas
^ permalink raw reply
* Re: Expose system Serial Number to userspace.
From: Brad Arnold @ 2012-08-29 20:47 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: linux-embedded
In-Reply-To: <alpine.LFD.2.02.1208291143101.1784@xanadu.home>
On Wed, Aug 29, 2012 at 9:50 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
>
> On Wed, 29 Aug 2012, Brad Arnold wrote:
>
> > Hi,
> >
> > I'm working on an embedded board which uses u-boot + linux. At
> > manufacturing time, the device serial number will be programmed into OTP
> > memory on NAND (probably from within u-boot). We'd like the linux kernel
> > to make this serial number available to be read from userspace. Is there
> > an accepted method to do this sort of thing?
>
> A serial number field is available from /proc/cpuinfo already. you just
> have to initialize it through the system_serial_high and
> system_serial_low global variables.
>
>
> Nicolas
Actually, I guess even better than initializing through the two
variables is to pass the serial directly from u-boot using the tag.
Brad
^ permalink raw reply
* Re: Expose system Serial Number to userspace.
From: Marco Stornelli @ 2012-08-29 17:07 UTC (permalink / raw)
To: Brad Arnold; +Cc: linux-embedded
In-Reply-To: <75d49b059819c35d03995bd86e72d6fb@mail.gmail.com>
Il 29/08/2012 18:57, Brad Arnold ha scritto:
> That'll help me move along. I'm currently storing the mac and serial in
> the u-boot environment, but I was thinking I might want to move those two
> to the OTP. But at least having some level of write protection in u-boot
> is nice. I wasn't aware that this existed, because it's disabled by
> default in the config for Marvell boards.
>
> I'll have to look at that example program futher...
>
> Brad
>
>
(Please no top-posting). Of course, if you have got a separate flash
partition for the uboot env, you can map it read-only in linux, it's safer.
Marco
^ permalink raw reply
* RE: Expose system Serial Number to userspace.
From: Brad Arnold @ 2012-08-29 16:57 UTC (permalink / raw)
To: Marco Stornelli; +Cc: linux-embedded
In-Reply-To: <503E3DDB.8050708@gmail.com>
That'll help me move along. I'm currently storing the mac and serial in
the u-boot environment, but I was thinking I might want to move those two
to the OTP. But at least having some level of write protection in u-boot
is nice. I wasn't aware that this existed, because it's disabled by
default in the config for Marvell boards.
I'll have to look at that example program futher...
Brad
-----Original Message-----
From: Marco Stornelli [mailto:marco.stornelli@gmail.com]
Sent: August-29-12 10:06 AM
To: Brad Arnold
Cc: linux-embedded@vger.kernel.org
Subject: Re: Expose system Serial Number to userspace.
Il 29/08/2012 17:18, Brad Arnold ha scritto:
> Hi,
>
> I'm working on an embedded board which uses u-boot + linux. At
> manufacturing time, the device serial number will be programmed into
> OTP memory on NAND (probably from within u-boot). We'd like the linux
> kernel to make this serial number available to be read from userspace.
> Is there an accepted method to do this sort of thing?
>
> One idea I had was to make the serial number available as a device
> node
> (ie: you can simply read the serial number from "/dev/serialnumber").
> Then there's the question of how the kernel learns the serial in the
> first place (a kernel boot command like parameter passed from u-boot?).
>
> Does this sound sane, or is there a better way to do something like
this?
>
> Thanks,
>
> Brad
U-Boot manage a serial number via env variable "serial#". It provides
several tools. You'll find under tools/env applications to read/write env
variable of uboot, so reading from Linux is very simple. You should use a
dedicated little space of flash to store the env variables.
Regards,
Marco
^ permalink raw reply
* RE: Expose system Serial Number to userspace.
From: Brad Arnold @ 2012-08-29 16:53 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: linux-embedded
In-Reply-To: <alpine.LFD.2.02.1208291143101.1784@xanadu.home>
That's perfect, thanks!
Brad
-----Original Message-----
From: Nicolas Pitre [mailto:nico@fluxnic.net]
Sent: August-29-12 9:51 AM
To: Brad Arnold
Cc: linux-embedded@vger.kernel.org
Subject: Re: Expose system Serial Number to userspace.
On Wed, 29 Aug 2012, Brad Arnold wrote:
> Hi,
>
> I'm working on an embedded board which uses u-boot + linux. At
> manufacturing time, the device serial number will be programmed into
> OTP memory on NAND (probably from within u-boot). We'd like the linux
> kernel to make this serial number available to be read from userspace.
> Is there an accepted method to do this sort of thing?
A serial number field is available from /proc/cpuinfo already. you just
have to initialize it through the system_serial_high and system_serial_low
global variables.
Nicolas
^ permalink raw reply
* Re: Expose system Serial Number to userspace.
From: Marco Stornelli @ 2012-08-29 16:05 UTC (permalink / raw)
To: Brad Arnold; +Cc: linux-embedded
In-Reply-To: <09ee18b0d2e3d7f34a9e510b3f8d7702@mail.gmail.com>
Il 29/08/2012 17:18, Brad Arnold ha scritto:
> Hi,
>
> I'm working on an embedded board which uses u-boot + linux. At
> manufacturing time, the device serial number will be programmed into OTP
> memory on NAND (probably from within u-boot). We'd like the linux kernel
> to make this serial number available to be read from userspace. Is there
> an accepted method to do this sort of thing?
>
> One idea I had was to make the serial number available as a device node
> (ie: you can simply read the serial number from "/dev/serialnumber"). Then
> there's the question of how the kernel learns the serial in the first
> place (a kernel boot command like parameter passed from u-boot?).
>
> Does this sound sane, or is there a better way to do something like this?
>
> Thanks,
>
> Brad
U-Boot manage a serial number via env variable "serial#". It provides
several tools. You'll find under tools/env applications to read/write
env variable of uboot, so reading from Linux is very simple. You should
use a dedicated little space of flash to store the env variables.
Regards,
Marco
^ permalink raw reply
* Re: Expose system Serial Number to userspace.
From: Nicolas Pitre @ 2012-08-29 15:50 UTC (permalink / raw)
To: Brad Arnold; +Cc: linux-embedded
In-Reply-To: <09ee18b0d2e3d7f34a9e510b3f8d7702@mail.gmail.com>
On Wed, 29 Aug 2012, Brad Arnold wrote:
> Hi,
>
> I'm working on an embedded board which uses u-boot + linux. At
> manufacturing time, the device serial number will be programmed into OTP
> memory on NAND (probably from within u-boot). We'd like the linux kernel
> to make this serial number available to be read from userspace. Is there
> an accepted method to do this sort of thing?
A serial number field is available from /proc/cpuinfo already. you just
have to initialize it through the system_serial_high and
system_serial_low global variables.
Nicolas
^ permalink raw reply
* Expose system Serial Number to userspace.
From: Brad Arnold @ 2012-08-29 15:18 UTC (permalink / raw)
To: linux-embedded
Hi,
I'm working on an embedded board which uses u-boot + linux. At
manufacturing time, the device serial number will be programmed into OTP
memory on NAND (probably from within u-boot). We'd like the linux kernel
to make this serial number available to be read from userspace. Is there
an accepted method to do this sort of thing?
One idea I had was to make the serial number available as a device node
(ie: you can simply read the serial number from "/dev/serialnumber"). Then
there's the question of how the kernel learns the serial in the first
place (a kernel boot command like parameter passed from u-boot?).
Does this sound sane, or is there a better way to do something like this?
Thanks,
Brad
^ permalink raw reply
* Re: NCD, a light scripting language for network configs and much more
From: Stephen Hemminger @ 2012-08-17 16:22 UTC (permalink / raw)
To: Ambroz Bizjak
Cc: linux-embedded, linux-hotplug, netfilter, linux-admin, torvalds
In-Reply-To: <CAOA3yKKmuAi=CPE=4-hyoGJJ7D7Oa_Bug5G=1Z3xif-5iFGeOw@mail.gmail.com>
On Fri, 17 Aug 2012 12:03:55 +0200
Ambroz Bizjak <ambrop7@gmail.com> wrote:
> Hi. I'm developing a special kind of scripting language which many
> might find useful: http://code.google.com/p/badvpn/wiki/NCD
>
> It was (originally) designed for programming dynamic configuration of
> network interfaces, iptables etc. For example, there are commands that
> observe the presence and link status of network interfaces. Many
> commands are reversible, which makes it very easy to do cleanup
> automatically and implicitly, like removing IP addresses or routes
> when the link goes down on an interface.
>
> The major advantage of this language compared to existing systems like
> NetworkManager and wicd is that it's extremely hackable; you can fine
> tune almost any part of the process. For example, this simple script
> will create a network bridge, ensure that interfaces eth0 and eth1 are
> in the bridge whenever they exist (consider hotplugging USB
> interfaces), and only after eth0 (!) is up and running will it obtain
> an IP address on br0 (!) using DHCP (since we know DHCP server is on
> eth0 not eth1).
>
> process bridge {
> # Choose name of bridge.
> var("br6") bridge_dev;
>
> # Create the bridge (and destroy it on deinit).
> run({"/sbin/brctl", "addbr", bridge_dev},
> {"/sbin/brctl", "delbr", bridge_dev});
>
> # Set bridge up.
> net.up(bridge_dev);
>
> # Wake up ports.
> provide("BRIDGE");
FYI - you can use ip commands now to control bridge.
For all the new features planned, they won't be controllable via brctl.
^ permalink raw reply
* NCD, a light scripting language for network configs and much more
From: Ambroz Bizjak @ 2012-08-17 10:03 UTC (permalink / raw)
To: linux-embedded, linux-hotplug, netfilter, linux-admin, torvalds
Hi. I'm developing a special kind of scripting language which many
might find useful: http://code.google.com/p/badvpn/wiki/NCD
It was (originally) designed for programming dynamic configuration of
network interfaces, iptables etc. For example, there are commands that
observe the presence and link status of network interfaces. Many
commands are reversible, which makes it very easy to do cleanup
automatically and implicitly, like removing IP addresses or routes
when the link goes down on an interface.
The major advantage of this language compared to existing systems like
NetworkManager and wicd is that it's extremely hackable; you can fine
tune almost any part of the process. For example, this simple script
will create a network bridge, ensure that interfaces eth0 and eth1 are
in the bridge whenever they exist (consider hotplugging USB
interfaces), and only after eth0 (!) is up and running will it obtain
an IP address on br0 (!) using DHCP (since we know DHCP server is on
eth0 not eth1).
process bridge {
# Choose name of bridge.
var("br6") bridge_dev;
# Create the bridge (and destroy it on deinit).
run({"/sbin/brctl", "addbr", bridge_dev},
{"/sbin/brctl", "delbr", bridge_dev});
# Set bridge up.
net.up(bridge_dev);
# Wake up ports.
provide("BRIDGE");
# Wait for port eth0 where we expect to have the DHCP server.
depend("BRIDGE-link");
# Obtain IP address.
net.ipv4.dhcp(bridge_dev) dhcp;
# Sanity check IP address.
ip_in_network(dhcp.addr, "127.0.0.0", "8") test_local;
ifnot(test_local);
# Assign IP address (and remove it when anything goes wrong,
# e.g. lease times out, eth0 disappears or loses link...).
net.ipv4.addr(bridge_dev, dhcp.addr, dhcp.prefix);
println("Got address: ", dhcp.addr, "/", dhcp.prefix);
rprintln("Lost address");
}
process bridge_port_eth0 {
depend("BRIDGE") br;
# Choose name of device.
var("eth0") dev;
# Wait for device to start existing (and trigger deinit
# when it stops existing).
net.backend.waitdevice(dev);
# Add it to the bridge (and remove it when it stops
# existing or we're quitting).
run({"/sbin/brctl", "addif", br.bridge_dev, dev},
{"/sbin/brctl", "delif", br.bridge_dev, dev});
# Set device up.
net.up(dev);
# Wait for link.
net.backend.waitlink(dev);
# Wake up bridge process so it can start DHCP.
provide("BRIDGE-link");
}
# other ports: same as above, just no need to wait for link
process bridge_port_eth1 {
depend("BRIDGE") br;
var("eth1") dev;
net.backend.waitdevice(dev);
run({"/sbin/brctl", "addif", br.bridge_dev, dev},
{"/sbin/brctl", "delif", br.bridge_dev, dev});
net.up(dev);
}
Note that nothing is ever leaked here. When the NCD interpreter
receives SIGTERM, it automatically cleans up everything (removes IP
addresses, destroys bridge...).
The language is suitable for much more than network configs. For
instance, it allows receiving input/evdev events from a single device
with only a few lines of code:
process main {
sys.evdev("/dev/input/by-id/usb-BTC_USB_Multimedia_Keyboard-event-kbd")
evdev;
println("Event: ", evdev.type, " ", evdev.value, " ", evdev.code);
val_equal(evdev.code, "KEY_ENTER") is_enter;
If (is_enter) {
println("You pressed enter!");
};
evdev->nextevent();
}
With some more code it's possible to automatically listen on all event
devices as they come and go.
I think it would also make a great base to build an init system upon
(implement init process in NCD language). I've toyed a little with
this and got something very simple working, see
http://code.google.com/p/ncdinit/ .
Best regards,
Ambroz Bizjak
^ permalink raw reply
* Re: [PATCH 1/2] mmc: block: mmcblkN: use slot index instead of dynamic name index
From: Dirk Behme @ 2012-08-08 6:12 UTC (permalink / raw)
To: Chris Ball
Cc: linux-mmc@vger.kernel.org, linaro-dev@lists.linaro.org,
linux-embedded@vger.kernel.org, Jassi Brar
In-Reply-To: <8739402g1m.fsf@octavius.laptop.org>
Hi Chris,
On 06.08.2012 17:31, Chris Ball wrote:
> Hi,
>
> On Mon, Aug 06 2012, Dirk Behme wrote:
>> On embedded devices, often there is a combination of removable mmc
>> devices (e.g. MMC/SD cards) and hard wired ones (e.g. eMMC).
>> Depending on the hardware configuration, the 'mmcblkN' node might
>> change if the removable device is available or not at boot time.
>>
>> E.g. if the removable device is attached at boot time, it might
>> become mmxblk0. And the hard wired one mmcblk1. But if the removable
>> device isn't there at boot time, the hard wired one will become
>> mmcblk0. This makes it somehow difficult to hard code the root device
>> to the non-removable device and boot fast.
>>
>> This change does simply associate 'N' of 'mmcblkN' with the slot index
>> instead of the dynamic name index. The slot index is always the same,
>> ensuring that the non-removable mmc device is associated always
>> with the same mmcblkN. Independent of the availability of the removable
>> one.
>
> I like this change in principle,
Thanks :)
> but doesn't it break boot for everyone
> currently using e.g. root=/dev/mmcblk0p1 on slot index 2? That doesn't
> sound like an acceptable regression.
I'm not really an expert of the code in block.c. Could you imagine a
change which has the same result we'd like to get with the proposed
patch but doesn't have the regression you mention?
Many thanks and best regards
Dirk
^ permalink raw reply
* Re: [PATCH 1/2] mmc: block: mmcblkN: use slot index instead of dynamic name index
From: Jassi Brar @ 2012-08-06 16:15 UTC (permalink / raw)
To: Chris Ball; +Cc: Dirk Behme, linux-mmc, linaro-dev, linux-embedded
In-Reply-To: <8739402g1m.fsf@octavius.laptop.org>
On 6 August 2012 21:01, Chris Ball <cjb@laptop.org> wrote:
> Hi,
>
> On Mon, Aug 06 2012, Dirk Behme wrote:
>> On embedded devices, often there is a combination of removable mmc
>> devices (e.g. MMC/SD cards) and hard wired ones (e.g. eMMC).
>> Depending on the hardware configuration, the 'mmcblkN' node might
>> change if the removable device is available or not at boot time.
>>
>> E.g. if the removable device is attached at boot time, it might
>> become mmxblk0. And the hard wired one mmcblk1. But if the removable
>> device isn't there at boot time, the hard wired one will become
>> mmcblk0. This makes it somehow difficult to hard code the root device
>> to the non-removable device and boot fast.
>>
>> This change does simply associate 'N' of 'mmcblkN' with the slot index
>> instead of the dynamic name index. The slot index is always the same,
>> ensuring that the non-removable mmc device is associated always
>> with the same mmcblkN. Independent of the availability of the removable
>> one.
>
> I like this change in principle, but doesn't it break boot for everyone
> currently using e.g. root=/dev/mmcblk0p1 on slot index 2? That doesn't
> sound like an acceptable regression.
>
It shouldn't break boot for any user already doing the right thing.
If the user's platform probes only slot-2, it will still be 'mmcblk0'
If the platform probes slot-1 & 2, it is fundamentally unsafe to count
upon the card in slot-2 to be enumerated before the one in slot-1.
^ permalink raw reply
* Re: [PATCH 1/2] mmc: block: mmcblkN: use slot index instead of dynamic name index
From: Chris Ball @ 2012-08-06 15:31 UTC (permalink / raw)
To: Dirk Behme; +Cc: linux-mmc, linaro-dev, linux-embedded, Jassi Brar
In-Reply-To: <1344237900-14815-1-git-send-email-dirk.behme@de.bosch.com>
Hi,
On Mon, Aug 06 2012, Dirk Behme wrote:
> On embedded devices, often there is a combination of removable mmc
> devices (e.g. MMC/SD cards) and hard wired ones (e.g. eMMC).
> Depending on the hardware configuration, the 'mmcblkN' node might
> change if the removable device is available or not at boot time.
>
> E.g. if the removable device is attached at boot time, it might
> become mmxblk0. And the hard wired one mmcblk1. But if the removable
> device isn't there at boot time, the hard wired one will become
> mmcblk0. This makes it somehow difficult to hard code the root device
> to the non-removable device and boot fast.
>
> This change does simply associate 'N' of 'mmcblkN' with the slot index
> instead of the dynamic name index. The slot index is always the same,
> ensuring that the non-removable mmc device is associated always
> with the same mmcblkN. Independent of the availability of the removable
> one.
I like this change in principle, but doesn't it break boot for everyone
currently using e.g. root=/dev/mmcblk0p1 on slot index 2? That doesn't
sound like an acceptable regression.
Thanks,
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* [PATCH 2/2] mmc: block: remove unused name_idx
From: Dirk Behme @ 2012-08-06 7:25 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA
Cc: linaro-dev-cunTk1MwBs8s++Sfvej+rw,
linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1344237900-14815-1-git-send-email-dirk.behme-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
With the previous patch "mmc: block: mmcblkN: use slot index instead of
dynamic name index" name_idx is not needed any more.
Signed-off-by: Dirk Behme <dirk.behme-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
CC: Jassi Brar <jaswinder.singh-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
CC: Chris Ball <cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org>
---
drivers/mmc/card/block.c | 16 ----------------
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index a01d306..555d840 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -74,7 +74,6 @@ static int max_devices;
/* 256 minors, so at most 256 separate devices */
static DECLARE_BITMAP(dev_use, 256);
-static DECLARE_BITMAP(name_use, 256);
/*
* There is one mmc_blk_data per slot.
@@ -92,7 +91,6 @@ struct mmc_blk_data {
unsigned int usage;
unsigned int read_only;
unsigned int part_type;
- unsigned int name_idx;
unsigned int reset_done;
#define MMC_BLK_READ BIT(0)
#define MMC_BLK_WRITE BIT(1)
@@ -1458,19 +1456,6 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card,
goto out;
}
- /*
- * !subname implies we are creating main mmc_blk_data that will be
- * associated with mmc_card with mmc_set_drvdata. Due to device
- * partitions, devidx will not coincide with a per-physical card
- * index anymore so we keep track of a name index.
- */
- if (!subname) {
- md->name_idx = find_first_zero_bit(name_use, max_devices);
- __set_bit(md->name_idx, name_use);
- } else
- md->name_idx = ((struct mmc_blk_data *)
- dev_to_disk(parent)->private_data)->name_idx;
-
md->area_type = area_type;
/*
@@ -1660,7 +1645,6 @@ static void mmc_blk_remove_parts(struct mmc_card *card,
struct list_head *pos, *q;
struct mmc_blk_data *part_md;
- __clear_bit(md->name_idx, name_use);
list_for_each_safe(pos, q, &md->part) {
part_md = list_entry(pos, struct mmc_blk_data, part);
list_del(pos);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] mmc: block: mmcblkN: use slot index instead of dynamic name index
From: Dirk Behme @ 2012-08-06 7:24 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA
Cc: linaro-dev-cunTk1MwBs8s++Sfvej+rw,
linux-embedded-u79uwXL29TY76Z2rM5mHXA
On embedded devices, often there is a combination of removable mmc
devices (e.g. MMC/SD cards) and hard wired ones (e.g. eMMC).
Depending on the hardware configuration, the 'mmcblkN' node might
change if the removable device is available or not at boot time.
E.g. if the removable device is attached at boot time, it might
become mmxblk0. And the hard wired one mmcblk1. But if the removable
device isn't there at boot time, the hard wired one will become
mmcblk0. This makes it somehow difficult to hard code the root device
to the non-removable device and boot fast.
This change does simply associate 'N' of 'mmcblkN' with the slot index
instead of the dynamic name index. The slot index is always the same,
ensuring that the non-removable mmc device is associated always
with the same mmcblkN. Independent of the availability of the removable
one.
This issue has a long history. One prominent one is e.g. from the
Maemo based Nokia N810 device:
https://bugs.maemo.org/show_bug.cgi?id=2747
Signed-off-by: Dirk Behme <dirk.behme-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
CC: Jassi Brar <jaswinder.singh-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
CC: Chris Ball <cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org>
---
drivers/mmc/card/block.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index f1c84de..a01d306 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1517,7 +1517,7 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card,
*/
snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
- "mmcblk%d%s", md->name_idx, subname ? subname : "");
+ "mmcblk%d%s", card->host->index, subname ? subname : "");
if (mmc_card_mmc(card))
blk_queue_logical_block_size(md->queue.queue,
--
1.7.0.4
^ permalink raw reply related
* History of embedded Linux
From: Chris Simmonds @ 2012-07-23 15:00 UTC (permalink / raw)
To: linux-embedded
Hi,
This is a little off-topic, but I have a bee in my bonnet about
documenting where "embedded Linux" came from. As a starting point, I
have written up a time line of key events, which is here
http://embedded-linux.co.uk/embedded-history
I am aware that there is a lot that I have missed, or misunderstood, so
if you have a few minutes to spare perhaps you could have a look at it
and tell me what I have got wrong. I am not sure where I am going with
this, but I would like to use it as the basis of a longer document/web
site/garden shed on the topic of the evolution of Linux as an embedded
operating system.
Oh, one last thing. If someone has some reasonably reliable figures of
the numbers of Linux products shipped, that would be nice. Ideally I
would like a graph that goes from zero in 1995 to NNN million in 2012. I
know, its a dream, can't be done...
Bye for now,
Chris Simmonds
^ permalink raw reply
* Help with testing "flash-kernel" for stable release update (SRU)
From: David Cullen @ 2012-07-13 17:30 UTC (permalink / raw)
To: linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
ubuntu-devel-discuss-nLRlyDuq1AZFpShjVBNYrg@public.gmane.org,
linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Hello,
I submitted a patch for "flash-kernel" to Ubuntu to solve this problem:
> Kernel /boot/vmlinuz-3.4.0-1-linaro-lt-omap does not match your subarchitecture
> omap4, therefore not writing it to flash.
The problem has been reported as
https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/1023952
I submitted a patch, but for the patch to be included in a "stable
release update" (aka SRU), it needs to be tested on a BeagleBoard-xM.
If you are running Ubuntu on a BeagleBoard-xM, will you help me test
this patch?
--
Thank you,
David Cullen
^ permalink raw reply
* [announce] Embedded Linux Conference Call for Presentations
From: Tim Bird @ 2012-07-12 18:21 UTC (permalink / raw)
To: linux-embedded
Hello everyone,
I'm writing to remind you all that the ELC Europe 2012
Call for Presentations is currently open. The conference
is in November (5-7) this year, in Barcelona Spain.
We are again co-located with LinuxCon Europe.
We're very excited for this opportunity once again to get
together as an industry and community, to talk about embedded
Linux. If you have been working on some aspect of embedded
Linux, such as security, audio, video, graphics, system size,
bootup time, power management, distribution, build systems
or tools, please consider submitting a proposal for the event.
The deadline for proposal submissions is August 1, which is
coming up in just a few weeks. It's right during vacation
season in Europe, so please don't forget!
For details on submitting a presentation proposal, please see:
http://events.linuxfoundation.org/events/embedded-linux-conference-europe/cfp
We had a great time last year. For examples of previous
presentations, see: http://elinux.org/ELCE_2011_Presentations
or look at last year's schedule:
http://events.linuxfoundation.org/archive/2011/embedded-linux-conference-europe/schedule
I look forward to hearing about the interesting things you're
working on, and to seeing you at the event.
Thanks and regards,
-- Tim Bird
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox