• Home
  • Help
  • Search
  • Login
  • Register
Pages: 1 ... 6 7 [8] 9 10
 71 
 on: September 24, 2013, 01:30:47 PM 
Started by kemrit - Last post by kemrit
I checked printenv and debian installation for both the SD card used for installation is listed in SDB. So SDA is obviously wrong. Does anybody know how i can fix this? Or does the debian installation only support the installation to the dreamplug microSD which would be SDA?

Thanks for any hints

kemrit

 72 
 on: September 24, 2013, 12:56:04 PM 
Started by PeniWize - Last post by kemrit
Hi,

my dreamplug is a 003-DS2001 and i dared to upgrade my self installed Debian System (http://blog.davideaves.com/archives/2011/03/21/installing_debian_gnulinux_6_0_1_squeeze_on_the_dreamplug/). As the uImage hasn't been upgraded as well the whole system wasn't useable anymore. I started from the beginning in order to have a debian system which generates uImage for itself --> Upgrades will be possible.

1. Upgrading uBoot worked, takes some time, uBoot start up configuration needs to be altered :               http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade/ 
2. Installing Debian still ongoing (posted here in the forum:        http://www.cyrius.com/debian/kirkwood/sheevaplug/install/

Question 1: I doubt that! Did you try the images of NewIT already? http://downloadsnewit.co.uk/SD-images/Dreamplug/NewIT-Dreamplug-v0901-v1001-multibootSD-Wheezy/

Question 2: The images of NewIT should work. Can't test myself asi don't want to touch uBoot script again ;-)  Still trying to install Debian Wheezy...

Hope that helps...

kemrit

 73 
 on: September 24, 2013, 12:40:26 PM 
Started by kemrit - Last post by kemrit
Enclosed is a snippet of the /var/log/installer/syslog related to uImage:

Sep 23 21:57:20 in-target: Unpacking u-boot-tools (from .../u-boot-tools_2012.04.01-2_armel.deb) ...
Sep 23 21:57:20 in-target: Processing triggers for man-db ...
Sep 23 21:57:24 in-target: Setting up u-boot-tools (2012.04.01-2) ...
Sep 23 21:57:28 in-target: update-initramfs: Generating /boot/initrd.img-3.2.0-4-kirkwood
Sep 23 21:57:38 in-target: flash-kernel: installing version 3.2.0-4-kirkwood
Sep 23 21:57:39 in-target: Generating kernel u-boot image...
Sep 23 21:57:39 in-target: done.
Sep 23 21:57:39 kernel: [ 5519.167084] EXT2-fs (sda1): error: can't find an ext2 filesystem on dev sda1.
Sep 23 21:57:39 kernel: [ 5519.167713] FAT-fs (sda1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
Sep 23 21:57:39 in-target: Taking backup of uImage.
Sep 23 21:57:39 in-target: Installing new uImage.
Sep 23 21:57:39 in-target: Generating initramfs u-boot image...
Sep 23 21:57:40 in-target: done.
Sep 23 21:57:40 in-target: Taking backup of uInitrd.
Sep 23 21:57:40 in-target: Installing new uInitrd.
Sep 23 21:57:40 in-target: Taking backup of dtb.
Sep 23 21:57:40 in-target: Installing new dtb.

The only error seems to be that the system can't find an ext2 filesystem on /dev/sda1...
Does anybody has an idea why?

Thanks in advance for any hint

kemrit

 74 
 on: September 24, 2013, 12:11:47 PM 
Started by kemrit - Last post by kemrit
Hallo,

i followed Cyrius Guide for Debian installation on dreamplug:

http://www.cyrius.com/debian/kirkwood/sheevaplug/install/

I have used an USB-stick to provide installation uImage and uInitrd in order to install debian to an SD card. A /boot ext2 partition has been created but remains empty after finishing installation. I would expect the new generated uImage and uInitrd to be copied there... At least that is implied in the guide.

Is there any log file which i could check for a root cause?

Thanks in advance

kemrit

 75 
 on: September 24, 2013, 01:55:36 AM 
Started by cbxbiker61 - Last post by marcus11
This is my latest script for building my cross-compilers.
When it finishes it will create CrossArm-* which you can extract
in the root directory...that will place the cross compiler in
/opt/cross/armv*.

http://www.xilka.com/xilka/source/BuildCrossArm-4.8-2013.09.sh


It's not happy on Debian 7 x64:
Code:
--2013-09-24 18:53:40--  http://www.xilka.com/xilka/source/patches/Gcc-4.8.2-arm                                                                                                                                                              -thumb2-CASE_VECTOR_SHORTEN_MODE.patch
Resolving www.xilka.com (www.xilka.com)... 108.62.185.77
Connecting to www.xilka.com (www.xilka.com)|108.62.185.77|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2013-09-24 18:53:41 ERROR 404: Not Found.

There are a serious number of patches in that directory!!! Smiley

 76 
 on: September 24, 2013, 12:49:37 AM 
Started by erpel - Last post by erpel


Hey guys.

my repo (crichton.homelinux.org) turned dark about a month ago due to the !#$% policy changes of dyndns.

I changed my hostname to crichton.supercomputerrobot.com (from the hostname pool afraid.org). From what I can make out, this one is more reliable than dyndns.org; so I hope that it will remain up....

Code:
deb-src http://crichton.supercomputerrobot.com/debian {lenny|squeeze|wheezy} main contrib non-free

 77 
 on: September 23, 2013, 02:47:32 PM 
Started by cbxbiker61 - Last post by apemberton
Finally, after much swearing, cussing and almost losing the will to live, I have repaired my development Sheevaplug (new eSata disk drive) and am now in a position to start compiling a kernel natively. I will look at the above config elements tomorrow time permitting and see what is what. It really didn't help repairs with no console output. I also need to mirror disks so a SATA multiplexor to create a RAID array would be nice.

I think you are on the point of cracking the problem. Hopefully someone will confirm the cure!  Cheesy

 78 
 on: September 21, 2013, 08:05:06 AM 
Started by cbxbiker61 - Last post by cbxbiker61


If someone can point me to a suitable cross-compiling toolchain for an Intel x86_64 host, I'm happy to try building some kernels to find out what change makes the difference.


This is my latest script for building my cross-compilers.
When it finishes it will create CrossArm-* which you can extract
in the root directory...that will place the cross compiler in
/opt/cross/armv*.

http://www.xilka.com/xilka/source/BuildCrossArm-4.8-2013.09.sh

 79 
 on: September 20, 2013, 03:04:07 PM 
Started by cbxbiker61 - Last post by birdman
If someone can point me to a suitable cross-compiling toolchain for an Intel x86_64 host, I'm happy to try building some kernels to find out what change makes the difference.
I have the while thing set up for my Plug by using qemu in a VirtualBox host running Debian (which is all on my Linux Mint workstation, so I can run with multiple cores, and lots of memory, if I wish...).
That's quite simple to set-up.  (I have qemu setups there for my Raspberry Pi and Asus66 also..)

 80 
 on: September 20, 2013, 03:59:23 AM 
Started by cbxbiker61 - Last post by pqa
Regarding the console problem, I have identified the following so far:

The Fedora 3.10.10 kernel with device tree, with the working console, reports the following in dmesg at boot time:
[   19.249385] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[   19.250677] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
[   19.775383] console [ttyS0] enabled

The Cbxbiker 3.10.10 kernel reports:
[   12.563947] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
and then a few lines later:
[   12.691809] Warning: unable to open an initial console.

so it's clearly not finding the serial port.
The obvious difference here, other than not reporting the hardward, is that the Fedora kernel has interrupt sharing enabled.

Looking at the device trees, the main differences are:
Cbxbiker:
clocks = <0x03, 0xn>          # throughout the device tree
phandle for core-clocks = 0x02
phandle for clock-gating-control = 0x03

Fedora:
clocks = <0x02, 0xn>
phandle for core-clocks = 0x03
phandle for clock-gating-control = 0x02

The clocks value is specified in the source file as &gate_clk, and I haven't found how the device tree compiler translates that to 0x02 or 0x03.
The phandle entries are generated by the DT compiler.

Also, Cbxbiker has applied the following patches:
Added cpus section
patched address of crypto engine
but neither of these would appear to affect the console.

There are lots of differences in the kernel configuration, but I've tried to pick out the ones relevant to the UART:
Cbxbiker:
CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=2
# CONFIG_SERIAL_8250_EXTENDED is not set
CONFIG_USB_SERIAL=m

Fedora:
# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
CONFIG_SERIAL_8250_CS=m
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y
CONFIG_USB_SERIAL=y
CONFIG_USB_SERIAL_CONSOLE=y

Since the working console output is referencing MMIO, I have also had a look at the kernel config relating to that.

Cbxbiker:
# CONFIG_MDIO_BUS_MUX_MMIOREG is not set
# CONFIG_VIRTIO_MMIO is not set

Fedora:
CONFIG_REGMAP_MMIO=y
CONFIG_SCSI_SYM53C8XX_MMIO=y
CONFIG_TULIP_MMIO=y
CONFIG_VIA_RHINE_MMIO=y
CONFIG_MDIO_BUS_MUX_MMIOREG=m
CONFIG_RT2X00_LIB_MMIO=m
CONFIG_SPI_DW_MMIO=m
CONFIG_VIRTIO_MMIO=m

I'm guessing here, but I wonder if CONFIG_REGMAP_MMIO=y needs to be set for the serial port hardware to be found.

If someone can point me to a suitable cross-compiling toolchain for an Intel x86_64 host, I'm happy to try building some kernels to find out what change makes the difference.

Pages: 1 ... 6 7 [8] 9 10