Re: [beagleboard] enabling the BBxM to start in 'ro' mode
Thank you. Could you post here the scripts (or send me them to me?). I fear the problem is not with the script but with the need of creating a initrd image with aufs to allow for temporary storage of information on the RAM, as it is done with Live CDs. Would mounting rootfs read-only be possible without compromising functioning of the system? I'm sure there must be someone expert out there... L On Tuesday, July 15, 2014 4:41:58 PM UTC+2, WB8TKL wrote: > > Greetings, > There is a Linux distro called "Voyage Linux" that runs read-only. > There are scripts that can be run as root called 'remountrw' and remoutro' > to change modes as neccessary. > > Sadly, Voyage Linux is written to run on the x86 andis not available > for the ARM processor. But if someone ever converts it to ARM I will > switch in a heartbeat! I have several Voyage boxes being used for data > collection and love them! It would certainly be sweet to have Voyage on > the BBB :) > > See: http://linux.voyage.hk > > Enjoy! >--- Jay Nugent WB8TKL >Ypsilanti, Michigan > > > > On Fri, 11 Jul 2014, Leonardo Gabrielli wrote: > > > Hello, > > I'd need the SD image I prepared for the xM to be supplied to people > > without them changing a single bit in it. Also, this avoids write > failure > > with power supply failures and increases the life of the SD. > >> From my understanding this can be done by mounting the rootfs as > read-only > > at some point in the boot and writing any change to the RAM without > making > > them persistent. But I'm not expert in the bootstrap process with Linux. > > > > The only similar case I know in detail so far is with Ubuntu 10.10 > > https://ccrma.stanford.edu/~eberdahl/satellite/ and it has two uInitrd > > images for boot, one with aufs enable and the other without. They only > > differ in a couple of scripts and if one wants changes to be persistents > it > > is enough to mv files in the boot partition in order for the bootloader > to > > pick the right one. > > > > Now, I'm using debian and the rcn-ee builds. Here the boot partition is > > different it uses initrd.img and zImage. I'm not sure what to do here > since > > it is a different boot method. > > Are there any suggestions on how to reach my goal? Any simple solution, > > even performed with an init script after bootstrap would be fine as a > > starter. > > > > Regards > > > > > > -- > > () ascii ribbon campaign in > /\ support of plain text e-mail > > o Averaging at least 3 days of MTBWTF!?!?!? > o The solution for long term Internet growth is IPv6. > o "To compel a man to furnish funds for the propagation of ideas he > disbelieves and abhors is sinful and tyrannical." -Thomas Jefferson > ++ > | Jay Nugent j...@nuge.com (734)484-5105 > (734)649-0850/Cell | > | Nugent Telecommunications [www.nuge.com] > | > | Internet Consulting/Linux SysAdmin/Engineering & Design | > | ISP Monitoring [www.ispmonitor.org] ISP & Modem Performance Monitoring > | > ++ > 10:01:01 up 8 days, 2:17, 1 user, load average: 0.82, 0.73, 0.99 > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] enabling the BBxM to start in 'ro' mode
Hello, I'd need the SD image I prepared for the xM to be supplied to people without them changing a single bit in it. Also, this avoids write failure with power supply failures and increases the life of the SD. >From my understanding this can be done by mounting the rootfs as read-only at some point in the boot and writing any change to the RAM without making them persistent. But I'm not expert in the bootstrap process with Linux. The only similar case I know in detail so far is with Ubuntu 10.10 https://ccrma.stanford.edu/~eberdahl/satellite/ and it has two uInitrd images for boot, one with aufs enable and the other without. They only differ in a couple of scripts and if one wants changes to be persistents it is enough to mv files in the boot partition in order for the bootloader to pick the right one. Now, I'm using debian and the rcn-ee builds. Here the boot partition is different it uses initrd.img and zImage. I'm not sure what to do here since it is a different boot method. Are there any suggestions on how to reach my goal? Any simple solution, even performed with an init script after bootstrap would be fine as a starter. Regards -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: multiple kernel oops at every boot, at random points in the sequence
Oops I haven't been notified of your reply... Which one of the twl4030 patches? At line 247 I can't see any... L On Wednesday, June 25, 2014 6:20:09 PM UTC+2, RobertCNelson wrote: > > On Wed, Jun 25, 2014 at 11:07 AM, Leonardo Gabrielli > wrote: > > The obvious question: what did I do wrong? I don't know, one day > everything > > worked consistently, then this started out. I thought the SD was > corrupted > > and reflashed it with a dd image I previously made, but the problem is > still > > there. I tried with different boards, no way. It seems like a virus ;) > > Does it help if you disable this patch: > > > https://github.com/RobertCNelson/armv7-multiplatform/blob/v3.15.x/patch.sh#L247 > > > Regards, > > -- > Robert Nelson > http://www.rcn-ee.com/ > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] multiple kernel oops at every boot, at random points in the sequence
Dear group, before going into a thorough research I ask you if you ever experienced this: 8 out of 10 reboots of the BBxM stop due to kernel oops at totally random moments in the boot process. I have tested it on multiple BB and I get always Oops. At some times the boot sequence can get to the login without oops, but rarely. Pasting here a few examples gathered from the console at boot (just the beginning of the oops message): [4.951324] udevd[85]: starting version 175 [5.144683] usb 2-2: new high-speed USB device number 2 using ehci-omap [5.222869] Unable to handle kernel paging request at virtual address 1edf8026 [5.230438] pgd = de3e4000 [5.233276] [1edf8026] *pgd= [5.236999] Internal error: Oops: 805 [#1] SMP ARM [5.242004] Modules linked in: [5.245208] CPU: 0 PID: 118 Comm: udevd Not tainted 3.15.1-armv7-x2 #1 etc... [9.412963] omap-twl4030 sound.5: twl4030-hifi <-> 49022000.mcbsp mapping ok done. [9.878204] Unable to handle kernel NULL pointer dereference at virtual address 0004 [9.886810] pgd = df414000 [9.889617] [0004] *pgd=9e06b831, *pte=, *ppte= [9.896240] Internal error: Oops: 17 [#1] SMP ARM [9.901153] Modules linked in: leds_pwm snd_soc_omap_twl4030 snd_soc_omap gpio_keys snd_soc_omap_mcbsp snd_soc_twl4030 snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_seq omap_aes snd_seq_device snd_timer snd smsc95xx usbnet evdev soundcore rtc_twl twl4030_keypad matrix_keymap etc... fsck from util-linux 2.20.1 rootfs was not cleanly unmounted, check forced. rootfs: 55636/232464 files (0.1% non-contiguous), 335295/942848 blocks fsck died with exit status 1 failed (code 1). [ 13.743408] EXT4-fs (mmcblk0p2): re-mounted. Opts: errors=remount-ro [ ok ] Cleaning up temporary files... /tmp. [ 14.735748] Unable to handle kernel paging request at virtual address 1edf8026 [ 14.743316] pgd = db77c000 [ 14.746154] [1edf8026] *pgd= [ 14.749877] Internal error: Oops: 805 [#3] SMP ARM [ 14.754882] Modules linked in: etc... [ 11.426849] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null) [] Checking root file system...fsck from util-linux 2.20.1 rootfs was not cleanly unmounted, check forced. [ 13.818634] Internal error: Oops - undefined instruction: 0 [#2] SMP ARM [ 13.825653] Modules linked in: snd_soc_omap_twl4030 leds_pwm snd_soc_omap gpio_keys snd_soc_omap_mcbsp omap_aes snd_soc_twl4030 snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_seq snd_seq_device snd_timer snd rtc_twl smsc95xx usbnet evdev soundcore twl4030_keypad matrix_keymap [ 13.852111] CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: G D 3.15.1-armv7-x2 #1 Just FYI, the first serial print: U-Boot 2014.01-00014-gcc58fc1 (Feb 10 2014 - 16:24:52) OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz OMAP3 Beagle board + LPDDR/NAND I2C: ready DRAM: 512 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0 *** Warning - readenv() failed, using default environment In:serial Out: serial Err: serial Beagle xM Rev C No EEPROM on expansion board No EEPROM on expansion board Die ID #60b29ff80160a7450701e011 Net: usb_ether Hit any key to stop autoboot: 0 mmc0 is current device gpio: pin 173 (gpio 173) value is 0 gpio: pin 4 (gpio 4) value is 0 SD/MMC found on device 0 reading uEnv.txt 807 bytes read in 3 ms (262.7 KiB/s) Loaded environment from uEnv.txt Importing environment from mmc ... Checking if lcdcmd is set ... Checking if uenvcmd is set ... Running uenvcmd ... reading zImage 4737144 bytes read in 292 ms (15.5 MiB/s) reading initrd.img 3019480 bytes read in 188 ms (15.3 MiB/s) reading /dtbs/omap3-beagle-xm.dtb 61643 bytes read in 13 ms (4.5 MiB/s) ## Error: "expansion_args" not defined Kernel image @ 0x8030 [ 0x00 - 0x484878 ] ## Flattened Device Tree blob at 815f Booting using the fdt blob at 0x815f Using Device Tree in place at 815f, end 816020ca Starting kernel ... -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: multiple kernel oops at every boot, at random points in the sequence
The obvious question: what did I do wrong? I don't know, one day everything worked consistently, then this started out. I thought the SD was corrupted and reflashed it with a dd image I previously made, but the problem is still there. I tried with different boards, no way. It seems like a virus ;) On Wednesday, June 25, 2014 6:06:11 PM UTC+2, Leonardo Gabrielli wrote: > > Dear group, > before going into a thorough research I ask you if you ever experienced > this: > 8 out of 10 reboots of the BBxM stop due to kernel oops at totally random > moments in the boot process. > I have tested it on multiple BB and I get always Oops. At some times the > boot sequence can get to the login without oops, but rarely. > > Pasting here a few examples gathered from the console at boot (just the > beginning of the oops message): > > [4.951324] udevd[85]: starting version 175 > [5.144683] usb 2-2: new high-speed USB device number 2 using ehci-omap > [5.222869] Unable to handle kernel paging request at virtual address > 1edf8026 > [5.230438] pgd = de3e4000 > [5.233276] [1edf8026] *pgd= > [5.236999] Internal error: Oops: 805 [#1] SMP ARM > [5.242004] Modules linked in: > [5.245208] CPU: 0 PID: 118 Comm: udevd Not tainted 3.15.1-armv7-x2 #1 > > etc... > > [9.412963] omap-twl4030 sound.5: twl4030-hifi <-> 49022000.mcbsp > mapping ok > done. > [9.878204] Unable to handle kernel NULL pointer dereference at virtual > address 0004 > [9.886810] pgd = df414000 > [9.889617] [0004] *pgd=9e06b831, *pte=, *ppte= > [9.896240] Internal error: Oops: 17 [#1] SMP ARM > [9.901153] Modules linked in: leds_pwm snd_soc_omap_twl4030 > snd_soc_omap gpio_keys snd_soc_omap_mcbsp snd_soc_twl4030 snd_soc_core > snd_compress snd_pcm_dmaengine snd_pcm snd_seq omap_aes snd_seq_device > snd_timer snd smsc95xx usbnet evdev soundcore rtc_twl twl4030_keypad > matrix_keymap > > etc... > > fsck from util-linux 2.20.1 > rootfs was not cleanly unmounted, check forced. > rootfs: 55636/232464 files (0.1% non-contiguous), 335295/942848 blocks > fsck died with exit status 1 > failed (code 1). > [ 13.743408] EXT4-fs (mmcblk0p2): re-mounted. Opts: errors=remount-ro > [ ok ] Cleaning up temporary files... /tmp. > [ 14.735748] Unable to handle kernel paging request at virtual address > 1edf8026 > [ 14.743316] pgd = db77c000 > [ 14.746154] [1edf8026] *pgd= > [ 14.749877] Internal error: Oops: 805 [#3] SMP ARM > [ 14.754882] Modules linked in: > > etc... > > [ 11.426849] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null) > [] Checking root file system...fsck from util-linux 2.20.1 > rootfs was not cleanly unmounted, check forced. > [ 13.818634] Internal error: Oops - undefined instruction: 0 [#2] SMP ARM > [ 13.825653] Modules linked in: snd_soc_omap_twl4030 leds_pwm > snd_soc_omap gpio_keys snd_soc_omap_mcbsp omap_aes snd_soc_twl4030 > snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_seq snd_seq_device > snd_timer snd rtc_twl smsc95xx usbnet evdev soundcore twl4030_keypad > matrix_keymap > [ 13.852111] CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: G D > 3.15.1-armv7-x2 #1 > > > Just FYI, the first serial print: > > U-Boot 2014.01-00014-gcc58fc1 (Feb 10 2014 - 16:24:52) > > OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz > OMAP3 Beagle board + LPDDR/NAND > I2C: ready > DRAM: 512 MiB > NAND: 0 MiB > MMC: OMAP SD/MMC: 0 > *** Warning - readenv() failed, using default environment > > In:serial > Out: serial > Err: serial > Beagle xM Rev C > No EEPROM on expansion board > No EEPROM on expansion board > Die ID #60b29ff80160a7450701e011 > Net: usb_ether > Hit any key to stop autoboot: 0 > mmc0 is current device > gpio: pin 173 (gpio 173) value is 0 > gpio: pin 4 (gpio 4) value is 0 > SD/MMC found on device 0 > reading uEnv.txt > 807 bytes read in 3 ms (262.7 KiB/s) > Loaded environment from uEnv.txt > Importing environment from mmc ... > Checking if lcdcmd is set ... > Checking if uenvcmd is set ... > Running uenvcmd ... > reading zImage > 4737144 bytes read in 292 ms (15.5 MiB/s) > reading initrd.img > 3019480 bytes read in 188 ms (15.3 MiB/s) > reading /dtbs/omap3-beagle-xm.dtb > 61643 bytes read in 13 ms (4.5 MiB/s) > ## Error: "expansion_args" not defined > Kernel image @ 0x8030 [ 0x00 - 0x484878 ] > ## Flattened Device Tree blob at 815f >Booting using the fdt blob at 0x815f >Using Device Tree in place at 815f, end 816020ca > > Starting kernel ... > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] kernel 3.14 upgrade in debian, BeagleBoard xM
Ok, so the first part is just the vanilla kernel versioning, while the -x is your own numbering, correct? Regards On Wednesday, June 25, 2014 4:09:14 PM UTC+2, RobertCNelson wrote: > > On Wed, Jun 25, 2014 at 9:04 AM, Leonardo Gabrielli > wrote: > > Dear Robert, > > could you explain how are the tags and branches generated in your repo? > > Maybe it's a silly question but could you elaborate a bit on the naming > > convention? > > How is e.g. the tag 3.15-rc8-armv7-x1 related to the branch > 3.15.1-armv7-x2? > > The x1 -> x2 means it was more then just a kernel jump. > > I added 3 kernel patches + a config change between those versions: > > https://github.com/RobertCNelson/armv7-multiplatform/commits/v3.15.x > > I usually (if i remember) bump the (y) portion of the build number: > x.y between commits: > > > https://github.com/RobertCNelson/armv7-multiplatform/commit/c70c034e9cb75083f59d0559552cc605bbe3b8b0 > > > Regards, > > -- > Robert Nelson > http://www.rcn-ee.com/ > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] kernel 3.14 upgrade in debian, BeagleBoard xM
Dear Robert, could you explain how are the tags and branches generated in your repo? Maybe it's a silly question but could you elaborate a bit on the naming convention? How is e.g. the tag 3.15-rc8-armv7-x1 related to the branch 3.15.1-armv7-x2? Thanks On Friday, June 6, 2014 5:08:11 PM UTC+2, RobertCNelson wrote: > > On Fri, Jun 6, 2014 at 9:54 AM, Leonardo Gabrielli > wrote: > > Hello group, > > a rather newbie-ish question. I created my own customized Debian Wheezy > > system for a Beagleboard xM from armhf builds at rcn-ee.net > (specifically: > > debian-7.4-console-armhf). > > > > Now I am happy with all the tweaks I've done so far in the last months > but > > I'd like to upgrade the kernel to a 3.14 release, in order to make use > of > > the new SCHED_DEADLINE. > > > > There are no backports of linux 3.14 for Wheezy but there are Jessie > > packages for linux-headers-3.14-1-all linux-headers-3.14-1-common > > linux-headers-3.14-1-all-armhf etc. > > What's the best option to upgrade the kernel? Tweeak > /etc/apt/sources.list > > to add Jessie repos or trying compile it natively (I'm too lazy for > setting > > up a cross-compile chain). > > I don't think Jessie's 3.14-1 will boot the xm.. > > or just use this branch: > https://github.com/RobertCNelson/armv7-multiplatform/tree/v3.14.x > > with your config tweak and really easy to copy the kernel files: > > > http://eewiki.net/display/linuxonarm/BeagleBoard#BeagleBoard-CopyKernelFiles > > > > > Also, once I've got them compiled, I guess I should modify the BOOT > > partition of my uSD card to point to the proper image? An outline of the > > steps would be immensely appreciated! > > Pretty straight forward: > > zImage/vmlinux -> /boot/uboot/zImage > dtbs -> /boot/uboot/dtbs > modules -> /lib/modules/ > > Regards, > > -- > Robert Nelson > http://www.rcn-ee.com/ > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] kernel oops related to omap_i2c 48060000.i2c
Alright, it worked like a charm. Now the system got back working fine. You saved my day. I'm wondering what could possibly break my system... BTW: the user button moved from /dev/input/event0 to /dev/input/event1 Regards LG On Thursday, June 12, 2014 7:04:57 PM UTC+2, RobertCNelson wrote: > > On Thu, Jun 12, 2014 at 11:17 AM, Leonardo Gabrielli > wrote: > > Dear all, > > I'm looking for suggestions for this kernel oops. > > I recently discovered that when pushing the CPU too high > (scaling_governor > > set to performance, audio processes taking 100%) I often encounter a > kernel > > oops (reported on bottom) after several lines of: > > > > omap_i2c 4806.i2c: controller timed out > > > > Looking at sysfs I see that 4806.i2c is related to the SD card slot. > Am > > I right? > > So maybe the problem with my system is that the I2C controller gets > crazy > > (maybe because of delays caused by the high CPU load? Or maybe because > of > > the heat? One month ago the same configuration did work well, but even > > putting a fan in front of the board doesn't help now). > > > > I'm working on a debian Wheezy version from Robert Nelson rcn-ee: > > Linux debian-BB1 3.13.3-armv7-x10 #1 SMP Sat Feb 15 01:03:40 UTC 2014 > armv7l > > GNU/Linux > > BeagleBoard xM, rev.c > > any improvement with v3.15.x? > > wget http://rcn-ee.net/deb/wheezy-armhf/v3.15.0-armv7-x2/install-me.sh > sudo /bin/bash install-me.sh > (reboot) > > Regards, > > -- > Robert Nelson > http://www.rcn-ee.com/ > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] kernel oops related to omap_i2c 48060000.i2c
Dear all,
I'm looking for suggestions for this kernel oops.
I recently discovered that when pushing the CPU too high (scaling_governor
set to performance, audio processes taking 100%) I often encounter a kernel
oops (reported on bottom) after several lines of:
omap_i2c 4806.i2c: controller timed out
Looking at sysfs I see that 4806.i2c is related to the SD card slot. Am
I right?
So maybe the problem with my system is that the I2C controller gets crazy
(maybe because of delays caused by the high CPU load? Or maybe because of
the heat? One month ago the same configuration did work well, but even
putting a fan in front of the board doesn't help now).
I'm working on a debian Wheezy version from Robert Nelson rcn-ee:
Linux debian-BB1 3.13.3-armv7-x10 #1 SMP Sat Feb 15 01:03:40 UTC 2014
armv7l GNU/Linux
BeagleBoard xM, rev.c
The kern.log output. At 193 the jack is started and ALSA allocates the
buffers. After some time the controller timed out messages start. I can
reproduce the bug by forcing a bit the CPU (e.g. running top and cat from a
big file).
Jun 12 15:44:00 debian-BB1 kernel: [ 193.192321] omap-dma-engine
48056000.dma-controller: allocating channel for 33
Jun 12 15:44:00 debian-BB1 kernel: [ 193.214355] omap-dma-engine
48056000.dma-controller: allocating channel for 34
Jun 12 15:44:24 debian-BB1 kernel: [ 216.959320] [sched_delayed] sched: RT
throttling activated
Jun 12 15:44:33 debian-BB1 kernel: [ 225.959625] omap_i2c 4806.i2c:
controller timed out
Jun 12 15:44:44 debian-BB1 kernel: [ 236.979858] omap_i2c 4806.i2c:
controller timed out
Jun 12 15:44:56 debian-BB1 kernel: [ 248.949737] omap_i2c 4806.i2c:
controller timed out
Jun 12 15:45:04 debian-BB1 kernel: [ 256.098236] Unhandled fault: external
abort on non-linefetch (0x1028) at 0xfa060004
Jun 12 15:45:04 debian-BB1 kernel: [ 256.106933] Internal error: : 1028
[#1] SMP ARM
Jun 12 15:45:04 debian-BB1 kernel: [ 256.112091] Modules linked in:
leds_pwm smsc95xx usbnet gpio_keys rtc_twl omap_aes uio_pdrv_genirq uio
Jun 12 15:45:04 debian-BB1 kernel: [ 256.122863] CPU: 0 PID: 25 Comm:
irq/77-4806 Not tainted 3.13.3-armv7-x10 #1
Jun 12 15:45:04 debian-BB1 kernel: [ 256.131225] task: df1bcb00 ti:
df1c6000 task.ti: df1c6000
Jun 12 15:45:04 debian-BB1 kernel: [ 256.137359] PC is at
omap_i2c_isr_thread+0x38/0x378
Jun 12 15:45:04 debian-BB1 kernel: [ 256.142913] LR is at
omap_i2c_isr_thread+0x10/0x378
Jun 12 15:45:04 debian-BB1 kernel: [ 256.148437] pc : []lr :
[]psr: 6093
Jun 12 15:45:04 debian-BB1 kernel: [ 256.148437] sp : df1c7f08 ip :
fp : 0001
Jun 12 15:45:04 debian-BB1 kernel: [ 256.161376] r10: 0010 r9 :
0004 r8 : 0266
Jun 12 15:45:04 debian-BB1 kernel: [ 256.167297] r7 : df1c6000 r6 :
6013 r5 : 0065 r4 : df1b1410
Jun 12 15:45:04 debian-BB1 kernel: [ 256.174652] r3 : fa060004 r2 :
fa06 r1 : 0001 r0 : 6013
Jun 12 15:45:04 debian-BB1 kernel: [ 256.182037] Flags: nZCv IRQs off
FIQs on Mode SVC_32 ISA ARM Segment kernel
Jun 12 15:45:04 debian-BB1 kernel: [ 256.190399] Control: 10c5387d Table:
9e7e4019 DAC: 0015
Jun 12 15:45:04 debian-BB1 kernel: [ 256.196899] Process irq/77-4806
(pid: 25, stack limit = 0xdf1c6248)
Jun 12 15:45:04 debian-BB1 kernel: [ 256.204376] Stack: (0xdf1c7f08 to
0xdf1c8000)
Jun 12 15:45:04 debian-BB1 kernel: [ 256.209320] 7f00:
df1a74c0 df007a80 df1c6000 df1c6000 df1a74e0
Jun 12 15:45:04 debian-BB1 kernel: [ 256.218597] 7f20: c007d78c c007d7a8
df007a80 df1a74c0 df1c6000 c007d524 c007d6d4
Jun 12 15:45:04 debian-BB1 kernel: [ 256.227844] 7f40: df1c7f50 df1a7500
df1a74c0 c007d48c
Jun 12 15:45:04 debian-BB1 kernel: [ 256.237091] 7f60: c0058bd4
00900800 02e02408 df1a74c0
Jun 12 15:45:04 debian-BB1 kernel: [ 256.246337] 7f80: df1c7f80 df1c7f80
df1c7f90 df1c7f90 df1c7fac df1a7500
Jun 12 15:45:04 debian-BB1 kernel: [ 256.255584] 7fa0: c0058b0c
c000db98
Jun 12 15:45:04 debian-BB1 kernel: [ 256.264831] 7fc0:
Jun 12 15:45:04 debian-BB1 kernel: [ 256.274108] 7fe0:
0013 80200800 00050040
Jun 12 15:45:04 debian-BB1 kernel: [ 256.283386] []
(omap_i2c_isr_thread+0x38/0x378) from [] (irq_thread_fn+0x1c/0x40)
Jun 12 15:45:04 debian-BB1 kernel: [ 256.293823] []
(irq_thread_fn+0x1c/0x40) from [] (irq_thread+0x98/0x160)
Jun 12 15:45:04 debian-BB1 kernel: [ 256.303405] []
(irq_thread+0x98/0x160) from [] (kthread+0xc8/0xdc)
Jun 12 15:45:04 debian-BB1 kernel: [ 256.312377] []
(kthread+0xc8/0xdc) from [] (ret_from_fork+0x14/0x3c)
Jun 12 15:45:04 debian-BB1 kernel: [ 256.321533] Code: e5942008 e5d31001
e5943010 e0823311 (e1d320b0)
Jun 12 15:45:04 debian-BB1 kernel: [ 256.32843
Re: [beagleboard] kernel 3.14 upgrade in debian, BeagleBoard xM
Thank you I've been trying out this option. Actually I started this project with your custom images, so thumbs up ;) I've opted for a native compile on the BBxm with your scripts (on an additional SD card to have enough space). When git fetches from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable and tags, e.g.: * [new tag] v3.9.9 -> v3.9.9 I get: error: Your local changes to the following files would be overwritten by checkout: tools/testing/selftests/rcutorture/configs/rcu/v3.12/P7-4-T-NH-SD-SMP-HP Please, commit your changes or stash them before you can switch branches. Aborting I'm not very familiar with git, but I'll try to follow the script step by step to find this out. However if you have an insight or quick suggestion please let me know. Also: when I first tried the script, on the root file system microSD the compile process started and I didn't have git problems. I had to stop unfortunately, since the uSD space was almost over. I'm wondering whether I screwed up something with git. Regards On Friday, June 6, 2014 5:08:11 PM UTC+2, RobertCNelson wrote: > > On Fri, Jun 6, 2014 at 9:54 AM, Leonardo Gabrielli > wrote: > > Hello group, > > a rather newbie-ish question. I created my own customized Debian Wheezy > > system for a Beagleboard xM from armhf builds at rcn-ee.net > (specifically: > > debian-7.4-console-armhf). > > > > Now I am happy with all the tweaks I've done so far in the last months > but > > I'd like to upgrade the kernel to a 3.14 release, in order to make use > of > > the new SCHED_DEADLINE. > > > > There are no backports of linux 3.14 for Wheezy but there are Jessie > > packages for linux-headers-3.14-1-all linux-headers-3.14-1-common > > linux-headers-3.14-1-all-armhf etc. > > What's the best option to upgrade the kernel? Tweeak > /etc/apt/sources.list > > to add Jessie repos or trying compile it natively (I'm too lazy for > setting > > up a cross-compile chain). > > I don't think Jessie's 3.14-1 will boot the xm.. > > or just use this branch: > https://github.com/RobertCNelson/armv7-multiplatform/tree/v3.14.x > > with your config tweak and really easy to copy the kernel files: > > > http://eewiki.net/display/linuxonarm/BeagleBoard#BeagleBoard-CopyKernelFiles > > > > > Also, once I've got them compiled, I guess I should modify the BOOT > > partition of my uSD card to point to the proper image? An outline of the > > steps would be immensely appreciated! > > Pretty straight forward: > > zImage/vmlinux -> /boot/uboot/zImage > dtbs -> /boot/uboot/dtbs > modules -> /lib/modules/ > > Regards, > > -- > Robert Nelson > http://www.rcn-ee.com/ > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] kernel 3.14 upgrade in debian, BeagleBoard xM
Hello group, a rather newbie-ish question. I created my own customized Debian Wheezy system for a Beagleboard xM from armhf builds at rcn-ee.net (specifically: debian-7.4-console-armhf). Now I am happy with all the tweaks I've done so far in the last months but I'd like to upgrade the kernel to a 3.14 release, in order to make use of the new SCHED_DEADLINE. There are no backports of linux 3.14 for Wheezy but there are Jessie packages for linux-headers-3.14-1-all linux-headers-3.14-1-common linux-headers-3.14-1-all-armhf etc. What's the best option to upgrade the kernel? Tweeak /etc/apt/sources.list to add Jessie repos or trying compile it natively (I'm too lazy for setting up a cross-compile chain). Also, once I've got them compiled, I guess I should modify the BOOT partition of my uSD card to point to the proper image? An outline of the steps would be immensely appreciated! Regards Leonardo -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: How to reliably cross-compile Ralink drivers (CFLAGS, ccflags-y etc)
Hello, just wanted to bump this topic. I think this is of general use: how to compile modules for your beagle against a specific kernel version without messing with the CFLAGS? On Thursday, September 26, 2013 12:31:29 PM UTC+2, Leonardo Gabrielli wrote: > > Hello, > I've browsed the group looking for cross-compiling Ralink WIFI drivers for > the BeagleBoard xM or other Beagle platforms, but couldn't find a good > guide on this. > > I need to cross-compile the Ralink 5370 staging drivers > (DPO_RT5572_LinuxSTA_2.6.1.3_20121022) from a Ubuntu host on a BBxM with > custom Kernel (this: https://ccrma.stanford.edu/~eberdahl/Satellite/). > I've been given the kernel sources (it's 3.2.30-x4) and I already succeeded > in compiling a Realtek USB dongle kernel module (based on rtl8192cu). My > toolchain is based on code sourcery arm-none-linux-gnueabi > > However, differently from the Realtek one, the Ralink package has a ugly > makefile and thus: > 1- if I leave the CFLAGS to the default it will go for normal x86 compile > and the arm gcc toolchain won't recognize x86 related flags (of course) > 2- If I attempt to change the CFLAGS, I get the following error: > > make[1]: Entering directory > `/mnt/DATA/UNIVPM/TECHNICAL/beagleboard/SatelliteCCRMA/SatelliteCCRMA-Berdahl-Kernel-3.2.30-x14_img1.0.1' > scripts/Makefile.build:49: *** CFLAGS was changed in > "/mnt/DATA/UNIVPM/TECHNICAL/beagleboard/ZZRALINK2012/DPO_RT5572_LinuxSTA_2.6.1.3_20121022/os/linux/Makefile". > > Fix it to use ccflags-y. Stop. > > > I've gone through reading about ccflags-y on the kernel docs, but couldn't > figure out how to apply this here, and on the other side, I can just guess > what gcc flags are good to compile this driver on the beagle (e.g. > march=armv7-a) but I'm not expert enough to guess them all right. It will > take months to guess them ok. > > Some insight on this or past experience would be helpful. > Thanks, L > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
