Re: The state of Arm64 on Raspberry Pi (and its Documentation
On Thu, 2020-04-16 at 17:01 +0200, deloptes wrote: > Tixy wrote: > > > AArch64 is the abbreviation used by ARM for their 64-bit ISA, and is > > also used used by projects like GCC. > > I read this, but it said that the naming was merged to arm64 which initiated > from Apple. I am confused, cause the article said you can use both in GCC > for same thing Yeh they're probably interchangeable. AArch64/32 are Arm's 'official' ISA names and Linux kernel engineers mostly thought they sucked [1]. Don't know what this has to do with Apple, unless it's an LLVM arch naming thing? -- Tixy
Re: The state of Arm64 on Raspberry Pi (and its Documentation
On Wed, 2020-04-15 at 20:09 +0200, deloptes wrote: > basti wrote: > > > can please someone share a minimal image to boot aarch64 on rpi4? > > Why using the term aarch64 and what is wrong with kernel8.img? I was > told it is the arm64 one and I think I tried it AArch64 is the abbreviation used by ARM for their 64-bit ISA, and is also used used by projects like GCC. -- Tixy
Re: Debain on a Buffalo TeraStation Live (HS-DHTGL/R5)
On Fri, 2020-03-27 at 14:57 +0100, Gilles Risch wrote: > On 26/03/2020 18:25, Arnd Bergmann wrote: > > > On Thu, Mar 26, 2020 at 1:15 PM Gilles Risch < > > > gilles.ri...@gmail.com> wrote: > > > > > > Hello, > > > > > > During these days of isolation I reanimated my old TeraStation > > > Live > > > (HS-DHTGL/R5), equipped it with some new disks and installed the > > > latest > > > official firmware (2.14). This firmware is based on a quiet old > > > Linux > > > kernel: > > > #uname -a > > > Linux TS-LIVE 2.6.16.16-arm1 #9 Fri Aug 31 13:42:57 JST 2007 > > > armv5tejl > > > unknown > > > > > > So I decided to look for something newer. Is it possible to > > > install and > > > run a recent version of Debian on this Marvell Orion based NAS? > > > > There is still minimal kernel support for this platform in the old > > board > > files (not in the .dts format), and the armel kernel enables > > support, but > > as far as I can tell, it only has 128MB of RAM, and the official > > minimum > > for a Debian installation is now 256MB, so this may be a rough > > ride. > > > > Using OpenWRT instead of Debian would better fit into the RAM, but > > they have removed support for all Marvell Orion5x based platforms > > a few months ago, making that also a bit hard, though depending on > > how motivated you are, you could add back OpenWRT support by > > creating a dts file for their "Kirkwood" port. > > > >Arnd > > > > Thanks, > > I'll have a look at OpenWRT. Don't let RAM requirements put you off Debian. I run the latest Debian on a SheevaPlug (Kirkwood CPU), which whilst it does have 512MB RAM, 'free' reports 458MB availble. So that's 54MB used by the kernel, openssh daemon, exim4 email daemon, a bash shell, dnsmasq, chrony, fail2ban, and other odds and ends. Obviously, the more spare RAM for caches the better. -- Tixy
Re: making debs for u-boot kernels
On Thu, 2019-07-25 at 12:49 -0400, Gene Heskett wrote: > Possibly good to know, but is not at all helpfull when you "make uImage" > in a kernel src tree's top level directory and it terminates with a > missing numerical argument, which I'm, assuming is the offset from lsn0 > in the dos /boot partition of the u-sd card No idea where you get these sort of ideas. I'd assume the missing number is the value for the image load address, a header field to tell U-Boot whereabouts in RAM to load the kernel. I suggest you do some more research. Googling for "linux make uimage" throws up lots of stack exchange questions which may help get you started. Here's one about setting what I think your missing numeric argument is... https://stackoverflow.com/questions/31725605/building-kernel-uimage-using-loadaddr -- Tixy
Re: Todays update
On Tue, 2019-07-09 at 21:20 -0400, Gene Heskett wrote: > On Tuesday 09 July 2019 16:16:32 Rainer Dorsch wrote: > > > Hi Gene, > > > > which hardware did you use? > > A std pi-3b+ running buster. The kernel and all the video libs have > been > replaced since the initial release on the 6th. He's running the Raspian OS which is based on Debian buster, so I assumed those updates are specific to Raspian. -- Tixy
Re: loss of synaptic due to wayland
On Mon, 2019-07-08 at 06:40 -0400, Gene Heskett wrote: > So, synaptic is gone. What do or can we use for a replacement? Wasn't that discussed at length in april...? https://lists.debian.org/debian-user/2019/04/threads.html#00103 Anyway, synaptic isn't gone, it may be not usable on your Raspian system if the people that put that image together used wayland rather than X (if my memory of that discussion is correct). Personally, I've always used aptitude for package management with a visual UI, being text console based it also works over ssh or other remote terminal connections. You'd have to get use to using a keyboard rather than a mouse though. -- Tixy
Re: rock64, date is UTC, how to make EST (s/b UTC-5)
On Mon, 2018-07-23 at 18:53 -0400, Gene Heskett wrote: > > When you said you had isses with ssh -Y not allow X connections... > > > > Check that /etc/ssh/sshd_config on the rock64 has these settings: > > > > X11Forwarding yes > > X11UseLocalhost no > > > > And that the package 'xauth' is installed. > > > > Either of those missing will prevent ssh from forwarding X > > connections. > > > > Do I have to reboot it (the rock64) after makeing everything as > above? > Logging out, and back in does not shut the error message off. I expect you'll need to restart the ssh daemon, e.g as root: # service ssh restart Not sure if that works on machines with systemd. You could just reboot in either case. -- Tixy
Re: "external abort on linefetch (0x814)" on Kirkwood 6282 SoC
On Tue, 2018-05-29 at 13:51 +0200, Andrew Lunn wrote: > On Tue, May 29, 2018 at 06:50:16AM +0100, Jonathan Medhurst wrote: > > On Mon, 2018-05-28 at 18:00 +0200, Andrew Lunn wrote: > > > Hi Rob > > > > > > Since my QNAP only has 512M, there is not too much > > > experimentation i > > > can do. > > > > > > Could you try changing "Memory split" to "3G/1G user/kernel split > > > (for > > > full 1G low memory)". > > > > Don't you mean change it to 2G/2G? That's what would be needed to > > let > > the kernel map the whole 1GB of physical RAM in it's address region > > and > > so not need the high memory mechanism. > > Hi Jonathan > > The comment says: > > config VMSPLIT_3G_OPT > depends on !ARM_LPAE > bool "3G/1G user/kernel split (for full 1G low > memory)" > > So i'm thinking that means it should support up to 1G of RAM using > this split. It puts the split at 0xB000, so it is more like > 2.75G/1.25G. Ah, you are right, I thought you were suggesting VMSPLIT_3G. I didn't notice that the kernel had sprouted an extra VMSPLIT_3G_OPT option a couple of years ago. -- Tixy
Re: Bug#881846: rustc: FTBFS on armel
On Wed, 2017-11-15 at 18:37 +, Tixy wrote: > On Wed, 2017-11-15 at 19:21 +0100, John Paul Adrian Glaubitz wrote: > > On 11/15/2017 07:16 PM, Tixy wrote: > > > On Wed, 2017-11-15 at 18:53 +0100, John Paul Adrian Glaubitz wrote: > > >> As for the atomics: What strikes me odd is that upstream claims that > > >> ARMv6 is supported. But to my current knowledge, proper atomics were > > >> only introduced with ARMv7. > > > > > > ARMv6 has 32-bit atomics (LDREX and STREX instructions), and ARMv6K adds > > > 8-, 16-, and 64-bit versions. > > > > Ah, I guess my memory is wrong then. Were there any changes regarding > > atomics in ARMv7 > > Not that I know of. Actually, just been refreshing my memory with the help of Google and the memory barriers instruction DMB was new in ARMv7. Before then, the same operations was done with a co-processor instructions instead. These memory barriers would be required in any kind of locking operation; which may, or may not, be relevant to $subject. -- Tixy
Re: Bug#881846: rustc: FTBFS on armel
On Wed, 2017-11-15 at 19:21 +0100, John Paul Adrian Glaubitz wrote: > On 11/15/2017 07:16 PM, Tixy wrote: > > On Wed, 2017-11-15 at 18:53 +0100, John Paul Adrian Glaubitz wrote: > >> As for the atomics: What strikes me odd is that upstream claims that > >> ARMv6 is supported. But to my current knowledge, proper atomics were > >> only introduced with ARMv7. > > > > ARMv6 has 32-bit atomics (LDREX and STREX instructions), and ARMv6K adds > > 8-, 16-, and 64-bit versions. > > Ah, I guess my memory is wrong then. Were there any changes regarding > atomics in ARMv7 Not that I know of. -- Tixy
Re: Bug#881846: rustc: FTBFS on armel
On Wed, 2017-11-15 at 18:53 +0100, John Paul Adrian Glaubitz wrote: > As for the atomics: What strikes me odd is that upstream claims that > ARMv6 is supported. But to my current knowledge, proper atomics were > only introduced with ARMv7. ARMv6 has 32-bit atomics (LDREX and STREX instructions), and ARMv6K adds 8-, 16-, and 64-bit versions. -- Tixy
Re: Anyone using stretch/buster/sid on ARMv4t ?
On Tue, 2017-11-07 at 02:49 -0800, Rick Thomas wrote: > How do I know if a machine is ARMv4t? I have a sheevaplug and a > couple of openrd machines (one “client”, the other “ultimate”) that > are still doing useful work. Are they v4t? They're ARMv5 (so still need armel). I too have similar devices running Debian and in constant use. -- Tixy
Re: Which port for armv4l?
On Wed, 2016-08-17 at 14:34 +0200, Adam Wysocki wrote: [...] > I don't see why using MOV PC,reg would prevent interworking with binaries > built using Thumb, as this code executes in ARM state anyway... it could > use BX only to switch to Thumb (and when it doesn't use Thumb at all, it > would never use it)... If ARM code is called from Thumb code, it must return using something like BX LR. Mov PC, LR won't return to Thumb mode. E.g. /* Thumb code... */ BLX func /* ARM code... */ BL func ... func: ... BX LR The above 'func' can be called OK from both the ARM and Thumb state. If it returned with MOV PC, LR instead, then when called from Thumb it wouldn't work (for ARMv6 and earlier that is - ARMv7 changed behaviour of MOV and similar). Of course, ARM4T has original Thumb not Thumb-2, so doesn't have BLX. Instead, it would have some trampoline code which uses BX. (It's been almost 20 years since I worked on ARM4T systems, and memory is a bit fuzzy as to details, though I do remember that it was a complete pain in the arse. :-) -- Tixy
Re: Which port for armv4l?
On Wed, 2016-08-17 at 11:19 +0200, Adam Wysocki wrote: > On Wed, 17 Aug 2016, Tixy wrote: > > > BX is the only ARM state instruction on ARMv4 that exists for Thumb > > interworking. > > What about other (conditional) branch exchange instructions (BXCC, BXNE > etc.)? That's a BX instruction with condition checks, I was treating that as the same instruction (all older ARM instructions supported conditional execution, it's the top 4 bits of the instruction encoding). > > > Why would the code be trying to enter Thumb state if it isn't compiled > > for Thumb? > > Is it possible for a compiler to generate BX instructions without Thumb > code (for example to return from a function with bx lr, where lr will > always be even - no Thumb)? I believe so. If my memory serves me "BX reg" was recommended over "MOV PC,reg" so binaries built for ARM4T would likely use it even when they are built for ARM code rather than Thumb. (It makes sense as it means that code can be interwork happily with binaries built using Thumb instructions) > Correct me if I'm wrong, but I thought that BX patch (to emulate BX > instruction in kernel) was supposed to allow running code with BX > instructions on a processor that lacks it, and that's why I want to use it > (to run Debian for armel on StrongARM SA-1100, which has ARMv4 core, so > without Thumb). Code in Debian for armel architecture doesn't use Thumb? Correct. I run armel on ARMv5 devices that doesn't have Thumb (Marvel Kirkwood SoCs) though it does have support for BX (which was added to ARMv5 as a mandatory instruction even if Thumb is not supported). > > > Shouldn't the patch handle addresses with bit0=1 differently? > > > > I haven't looked at the patch so don't see what it does, I have looked now. > It just copies contents of the register specified in the last nibble of > the instruction to PC. > > int reg = instr & 0xf; > regs->ARM_pc = regs->uregs[reg]; Yes, and when the exception returns, the register values will be restored from that 'regs' structure. This will use an LDM (load multiple) instruction and the fact that PC has bit zero set or not won't matter on ARM4 devices (even ARM4T devices). And anyway, if the binary is compiled for ARM code not Thumb it won't be calling BX to load a value with bit 0 set anyway, because on ARM4T CPUs that would switch to Thumb mode and things would go horribly wrong if the binaries in the system were build for ARM not Thumb. -- Tixy
Re: Which port for armv4l?
On Wed, 2016-08-17 at 00:18 +0200, Adam Wysocki wrote: > On Tue, 16 Aug 2016, Adam Wysocki wrote: > > > I tested it with a small test program and it generates code with BX > > instruction (and other BXxx instructions, which - judging from the code - > > don't seem to be emulated by patch - aren't they needed?). BX is the only ARM state instruction on ARMv4 that exists for Thumb interworking. > Also a small question about BX emulation. Maybe it's a silly question, > because I don't know much about Thumb, but I googled that the least > significant bit of the branch address determines the state (whether > execution continues in ARM state or Thumb state). > > What will happen if the code tries to enter Thumb state with BX and the > patch just sets the PC to the odd address (with bit0=1)? An exception, as > PC can't be odd? Why would the code be trying to enter Thumb state if it isn't compiled for Thumb? Anyway, the bit will be ignored on old architectures without Thumb support. Indeed, even with Thumb support, BX was the only way to switch to Thumb on ARMv4. It was ARMv5 that added support for things like LDM and LDR to change state. > Shouldn't the patch handle addresses with bit0=1 differently? I haven't looked at the patch so don't see what it does, but if a system is ARMv4 then trying to load PC with an odd number is fine, that bit will be ignored and appear as zero if you look at PC. (Likely hardware doesn't even exist to store bit0 of PC) -- Tixy
Re: Broadcom BCM2709, ARMv8, and missing CPU features
On Thu, 2016-07-28 at 02:38 -0400, Jeffrey Walton wrote: [...] > >> // AES (aese) > >> ".byte 0x4e, 0x28, 0x48, 0x20;\n" > > > > So as instructions are little-endian that's 0x2048284e for a 32-bit > > instruction, or 0x284e2048 if it's a Thumb2 instruction (I'm showing > > that the same way as the ARM ARM does). > > I pulled the encodings from a known good machine that used intrinsics. > I did not hand encode them (too much work). > > > According to my copy of the ARM ARM, the AESE instruction has these > > encodings: > > > > For Thumb: > > > > 1 1 1 1 1 1 1 1 1 D 1 1 size 0 0 Vd 0 0 1 1 0 0 M 0 Vm > > > > For ARM > > > > 1 1 1 1 0 0 1 1 1 D 1 1 size 0 0 Vd 0 0 1 1 0 0 M 0 Vm > > > > For AArch64 > > > > 0 1 0 0 1 1 1 0 size 1 0 1 0 0 0 0 1 0 0 1 0 Rn Rd > > > > So it looks like you've used the AArch64 encoding (for something > > compiled and presumably run as AArch32?!) and gotten the byte order the > > wrong way around. > > I'm not sure if it matters, but this is an ARMv8 device running a 32-bit OS. So it's running in AArch32 mode, and you want the encodings for that, not the AArch64 version. I.e. the second encoding I mentioned, which would be .inst 0xf3b00300 or better, find a compiler version and options that knows about the instructions you want to test (which I see you already asked about below). Sorry I can't help with that, I know little about toolchains, and have also never used the newer ARM instruction features like VFP, SIMD, crytpo etc. > I'm still trying to figure out how to build test cases for an Aarch32 > execution on Aarch64. Eventually it will go into an open source > library's test script. Also see > https://gcc.gnu.org/ml/gcc-help/2016-06/msg00097.html. -- Tixy
Re: Broadcom BCM2709, ARMv8, and missing CPU features
On Thu, 2016-07-28 at 00:48 -0400, Jeffrey Walton wrote:
> Using '.byte' below rather than '.inst' or '.inst.w' is another can of
> worms...
And if I'm not mistaken, the part of the reason why you got the
instructions wrong...
> $ gcc -g3 -O0 -march=armv7-a -mfpu=neon test.cc -o test.exe
> $ ./test.exe
> $
Does the tool-chain default to ARM or Thumb? I assume ARM code.
> $ cat test.cc
> #include
> int main(int argc, char* argv[])
> {
> __asm__ __volatile__
> (
> ".code 32"
BTW, above selects ARM code generation, but won't have any affect
because you don't specify any labels or instruction mnemonics to
assemble.
> // AES (aese)
> ".byte 0x4e, 0x28, 0x48, 0x20;\n"
So as instructions are little-endian that's 0x2048284e for a 32-bit
instruction, or 0x284e2048 if it's a Thumb2 instruction (I'm showing
that the same way as the ARM ARM does).
According to my copy of the ARM ARM, the AESE instruction has these
encodings:
For Thumb:
1 1 1 1 1 1 1 1 1 D 1 1 size 0 0 Vd 0 0 1 1 0 0 M 0 Vm
For ARM
1 1 1 1 0 0 1 1 1 D 1 1 size 0 0 Vd 0 0 1 1 0 0 M 0 Vm
For AArch64
0 1 0 0 1 1 1 0 size 1 0 1 0 0 0 0 1 0 0 1 0 Rn Rd
So it looks like you've used the AArch64 encoding (for something
compiled and presumably run as AArch32?!) and gotten the byte order the
wrong way around.
Disclaimer, I'm only on my first coffee of the morning, so quite likely
not 100% accurate in my statements above. ;-)
--
Tixy
Re: Debian on RPi
On Wed, 2016-07-20 at 13:59 +0800, Paul Wise wrote: > On Wed, Jul 20, 2016 at 6:07 AM, Mark Morgan Lloyd wrote: [...] > > pukka Debian > > What is pukka Debian? Typo? Pukka is colloquial UK English meaning 'genuine'. -- Tixy
Re: Thinking about a "jessie and a half" release
On Wed, 2016-07-06 at 08:55 +0100, Steve McIntyre wrote: > On Wed, Jul 06, 2016 at 07:33:38AM +, Holger Levsen wrote: [...] > > I'd like to suggest *not* to call it jessie+half, as we have used > >that term already (for etch+half) and there we had a frozen/stable kernel, > >not a moving target like bpo. > > ACK - I'm not wedded to the name in the slightest. And it could be misleading, I'm already running Jessie and a half $ cat /etc/debian_version 8.5 :-) -- Tixy
Re: SD card device name changed on wandboard quad.
On Sat, 2016-06-25 at 05:38 +0200, Paul Wise wrote:
> On Sat, Jun 25, 2016 at 1:48 AM, peter green wrote:
>
> > While upgrading a wandboard quad from 4.4 to 4.6 (debian armmp kernels) I
> > got a boot failure. I tracked this down to the device name for the SD card
> > changing from mmcblk0 to mmcblk2
>
> I would suggest using filesystem UUIDs if that is possible in this
> scenario, since that will avoid caring about where the kernel decides
> to put the block device within its block device namespace.
>
> > Any idea why this has changed? There don't seem to be any other
> > lower-numbered mmcblk devices.
>
> Any interesting differences in dmesg before/after?
>
> Did the DeviceTree file change?
There was a heated discussion [1] I remembered and in there it points
out change that fixed a regression in this area: commit 9aaf3437aa72
("mmc: block: Use the mmc host device index as the mmcblk device index")
I don't is that's directly relevant to this issue reported above by
Peter.
[1] http://www.gossamer-threads.com/lists/linux/kernel/2429438
--
Tixy
Re: modprobe fuse fails after upgrade to Jessie 8.3 on Dreamplug (Kirkwood)
On Tue, 2016-02-16 at 10:53 +, Ian Campbell wrote: > On Tue, 2016-02-16 at 08:11 +0000, Tixy wrote: > > On Tue, 2016-02-16 at 00:28 +0100, Martin Granehäll wrote: > > [...] > > > When I ran flash-kernel tool manually I saw that new uImage and > > > uInitrd files were generated, but not in /boot. It says > > > "using /dev/sda1 as boot device", but that is and internal sd card, > > > not used. > > > > I have the same setup and so edited flash-kernel to match, here's my > > notes... > > > > Edit /usr/share/flash-kernel/db/all.db > > FYI you can do all of the following in /etc/flash-kernel/db and it will > override the /usr/share version. Thanks, that's useful to know. (I sorta knew editing files in /usr was wrong, at the very least prone to getting overwritten if the Debian package got updated). -- Tixy
Re: modprobe fuse fails after upgrade to Jessie 8.3 on Dreamplug (Kirkwood)
On Tue, 2016-02-16 at 00:28 +0100, Martin Granehäll wrote: [...] > When I ran flash-kernel tool manually I saw that new uImage and > uInitrd files were generated, but not in /boot. It says > "using /dev/sda1 as boot device", but that is and internal sd card, > not used. I have the same setup and so edited flash-kernel to match, here's my notes... Edit /usr/share/flash-kernel/db/all.db For entry under "Machine: Globalscale Technologies Dreamplug" Replace Boot-Device: /dev/sda1 Boot-Kernel-Path: uImage Boot-Initrd-Path: uInitrd Boot-DTB-Path: dtb with Boot-Kernel-Path: /boot/uImage Boot-Initrd-Path: /boot/uInitrd My /boot is the first partition on my external SD card, and where I configured U-Boot to boot from. -- Tixy
Re: Odd messages booting Cubox-i4 Pro "imx-gpc 20dc000.gpc: failed to get pu regulator: -517" and "ERROR: could not get clock /usdhc1_pwrseq:ext_clock(0)"
On Thu, 2016-02-04 at 14:44 +0100, John Holland wrote: > > On 04.02.2016, at 14:04, Nigel Sollars <nsoll...@gmail.com> wrote: > > > > There seems to be a good explanation here, > > > > https://lists.debian.org/debian-arm/2013/12/msg00038.html > > > >> On Wed, Feb 3, 2016 at 12:56 PM, Rick Thomas <rbtho...@pobox.com> wrote: > >> Does anyone know what the error messages > >> > >> Does anybody know what is causing the subject error messages? > >> ... > >> > [0.098389] imx-gpc 20dc000.gpc: failed to get pu regulator: -517 > Personally, I'm more worried about this, -517 is the error EPROBE_DEFER which is used when a driver can't get it's resources (probably) due to a dependant driver not being initialised yet. The device driver framework will retry later any driver that returns that error value, so -517 errors may be normal for a system and not true 'errors'. Of course, if the dependant driver is never successfully loaded then it would be a true error. -- Tixy
Re: Cannot boot jessie kernel on qemu armhf VM
On Fri, 2016-01-29 at 14:15 -0500, Lennart Sorensen wrote: > > /usr/bin/qemu-system-arm -monitor stdio -M vexpress-a15 -k de -m 512 > > -no-acpi -drive file=/localhome/cpleger/armhf/jessie-armhf.img,if=sd > -net > > none -kernel /localhome/cpleger/armhf/vmlinuz -initrd > > /localhome/cpleger/armhf/initrd.gz -append root=/dev/ram -name > > "jessie-armhf" > -dtb /localhome/cpleger/armhf/vexpress-v2p-ca15-tc1.dtb > > > > This, like all attempts before, just results in a blank VM screen. > > You have to use a serial console. These systems you are emulating do > not have graphics at all as far as I know. Speaking of the real hardware QEMU is emulating... The a9 vexpress has a 'CLCD' display, and it looks like QEMU supports that: https://wiki.linaro.org/PeterMaydell/QemuVersatileExpress For the a15-tc1 vexpress, that has a 'HDLCD' display and that quite probably isn't emulated. Actually, the vexpress hardware consists of a CPU CoreTile (a9, a15-tc1, etc) plugged into a motherboard, and the motherboard also has it's own display of the 'CLCD' type, don't know how much of that setup QEMU emulates. So, it's possible that removing HDLCD from the a15-tc1 device-tree and leaving the CLCD of the motherboard might get that working. -- Tixy
Re: Cannot boot jessie kernel on qemu armhf VM
On Fri, 2016-01-29 at 09:07 +0100, Christoph Pleger wrote: > Hello, > > I created a qemu armhf virtual machine, with machine type vexpress-a9 and > CPU cortex-a9. I first attempted to install the VM by using the jessie > debian-installer, but the VM did not boot. As is was not sure if I had the > correct files vmlinuz and initrd for jessie, I tried wheezy instead, and > that worked. After wheezy installation was completed, I upgraded to > jessie, installed vmlinuz-3.16.0-4-armmp kernel, halted the VM, copied > /boot/vmlinuz-3.16.0-4-armmp and /boot/initrd.img-3.16.0-4-armmp from the > VM to the real machine and, in my qemu GUI aqemu, changed the entries for > direct kernel boot accordingly. But again, the VM does not boot with > jessie kernel - the qemu window opens, but then, nothing happens any more. > With the wheezy kernel, the VM still boots fine. > > Any suggesting how to make the jessie kernel work on my VM? I've never used a QEMU VM, just real hardware, so don't know the boot process for QEMU works. But for real hardware, on more recent kernels, you need to pass the kernel a device-tree (dtb) file for the hardware you're booting and that is passed to the kernel at boot, along with any ramdisk (if that's needed). So, perhaps that's what you're missing? Googling 'qemu vexpress dtb' leads me to https://wiki.ubuntu.com/Kernel/Dev/QemuARMVexpress and that shows a dtb file being passed (in the example it's for the a15-tc1 'hardware' not a9. -- Tixy
Re: What is in the U-boot default environment?
On Mon, 2015-08-24 at 17:39 -0700, Rick Thomas wrote: [...] Watching the (USB) serial console output during booting, I notice the following: resetting ... U-Boot SPL 2014.10+dfsg1-5 (Apr 07 2015 - 22:16:43) U-Boot 2014.10+dfsg1-5 (Apr 07 2015 - 22:16:43) CPU: Freescale i.MX6Q rev1.5 at 792 MHz Reset cause: WDOG Board: MX6-CuBox-i DRAM: 2 GiB MMC: FSL_SDHC: 0 *** Warning - bad CRC, using default environment I understand the “bad CRC” as I’ve never done a “saveenv” so there is no environment for it to read. But that begs the question: What is in the default environment? Interrupt boot by pressing a key on the serial console (assuming it gives you a countdown to do that in) then enter the command 'printenv' which will list the environment. -- Tixy
Re: Debian on the Ionics Stratus plug computer
On Fri, 2014-11-28 at 10:20 +, Nick wrote: A related question... I have created a kernel package with the procedure described before; installing this on the plug gets an error saying that the packages arch (arm) doesn't match the system's (armel). The plug runs Debian Squeeze, I am suspecting the arch names have simply changed and were this Wheezy the system would also be armel, but I am not certain. 'arm' and 'armel' are different incompatible Debian architectures. 'arm' is no more (last used in Debian Lenny) and there are two current architectures for 32-bit ARM chips, 'armel' is for older ARM CPU (ARM v6 and earlier) and 'armhf' is for newer ones (ARM v7). So you definitely want 'armel', though I don't know how to actually help with what you are trying, sorry. -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1417547725.1389.3.ca...@yxit.co.uk
Re: Updating the installation guide, arm platform support
On Thu, 2014-03-20 at 08:38 +, Ian Campbell wrote: On Wed, 2014-03-19 at 20:33 +0100, Karsten Merker wrote: Another system question - the d-i alpha 1 announcement states: Hardware support changes [snip] * armhf: The armmp flavour has been added; it covers both mx5 and vexpress. Because of this I was going to list the versatile express as supported platform in the installation guide, but I have stumbled over the fact that it is not listed in the flash-kernel machine database, which makes me wonder about its status. Can anybody shed some light on this? AFAIU vexpress does not boot via u-boot and has it's own special firmware. Therefore I don't think flash-kernel support is possible/needed. On booting vexpress... There is an upstream U-Boot for vexpress when its fitted with an A9x4 CoreTile (pluggable CPU module) and various out-of-tree hacks for other CoreTiles, but it's best to consider vexpress as 'special' as the vendor (ARM Ltd) supplies it's own simple custom bootloader with the board and is promoting UEFI as a the boot-loader of the future. Basically, there are many constantly evolving variables of possible firmware version and configurations its best not to try and support any particular one. However, having the kernel, initrd and dtbs available in an easily discoverable place in the generated Debian filesystem would be good. For Linaro file system images (based on Open Embedded, Ubuntu and Android) we try and put the initrd, zImage and dtbs in the boot partition, so at least it's fairly simple to point whatever bootloader the user uses at the right bits, or can find them to put into flash memory or wherever else they need to go. -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1395343818.3060.24.ca...@computer5.home
Re: g++/armel: std::future and std::exception_ptr are missing
On Sun, 2013-12-01 at 18:24 +0200, Eugene V. Lyubimkin wrote: 2013-11-16 15:05, Eugene V. Lyubimkin: For some reason, on armel architecture exclusively [1], g++ has problems compiling seemingly any program which uses std::future [2]. std::future is actually defined in libstdc++'s headers only if: #if defined(_GLIBCXX_HAS_GTHREADS) defined(_GLIBCXX_USE_C99_STDINT_TR1) (ATOMIC_INT_LOCK_FREE 1) On armel porterbox, ATOMIC_INT_LOCK_FREE == 1, which according to the libstdc++ documentation means that, unlike every other Debian architecture, operations on atomic ints are not guaranteed to be lock-free there. I don't know is this a shortcoming in libstdc++ configuration/implementation or armel doesn't provide atomic incrementing/decrementing facilities. General atomic operations aren't available until version 6 of the ARM architecture, armel also supports version 5 which only has an atomic swap instruction; so I would guess libstdc++ is configured correctly. armhf targets ARM architecture version 7. -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1386060520.3368.7.ca...@computer5.home
Re: Kirkwood kernel installation
On Sat, 2013-08-31 at 20:51 +0200, Paul Kocialkowski wrote:
Le samedi 31 août 2013 à 19:24 +0100, Tixy a écrit :
I did notice when I first got the Dreamplug that the supplied U-Boot was
very slow, especially enumerating the USB devices. With the Debian
U-Boot that takes about 3 or 4 seconds, then a second to load the kernel
and initrd.
I'm using the Debian u-boot too. Can you provide me with the exact
version you have installed? Also, it would be nice if you could post
your bootcmd as well.
I got it from [1] and when it boots it says U-Boot 2013.01.01 (May 10
2013 - 06:32:54).
[1]
http://ftp.debian.org/debian/pool/main/u/u-boot/u-boot_2013.01.01-4_armel.deb
From my notes, I set it up the U-Boot environment with the following...
setenv ethaddr F0:AD:xx:xx:xx:xx
setenv eth1addr F0:AD:xx:xx:xx:xx
setenv boot_device 1
setenv bootargs 'console=ttyS0,115200n8'
setenv bootcmd_usb 'usb start; ext2load usb ${boot_device} 0x0080
uImage; ext2load usb ${boot_device} 0x0110 uInitrd'
setenv bootcmd 'setenv bootargs $(bootargs); run bootcmd_usb; bootm
0x0080 0x0110'
saveenv
And also from my notes, I hacked flash-kernel so it doesn't assume that
the kernel lives on the internal card.
For entry under Machine: Globalscale Technologies Dreamplug
Replace
Boot-Device: /dev/sda1
Boot-Kernel-Path: uImage
Boot-Initrd-Path: uInitrd
Boot-DTB-Path: dtb
with
Boot-Kernel-Path: /boot/uImage
Boot-Initrd-Path: /boot/uInitrd
Boot-DTB-Path: /boot/dtb
And, when installing Wheezy I created an ext2 boot partition on the SD
card as well as a root filesystem partition.
--
Tixy
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1378027409.3541.14.ca...@computer5.home
Re: Kirkwood kernel installation
On Sun, 2013-09-01 at 10:34 +0100, Ian Campbell wrote: On Sun, 2013-09-01 at 10:23 +0100, Tixy wrote: On Sat, 2013-08-31 at 20:51 +0200, Paul Kocialkowski wrote: Le samedi 31 août 2013 à 19:24 +0100, Tixy a écrit : I did notice when I first got the Dreamplug that the supplied U-Boot was very slow, especially enumerating the USB devices. With the Debian U-Boot that takes about 3 or 4 seconds, then a second to load the kernel and initrd. I'm using the Debian u-boot too. Can you provide me with the exact version you have installed? Also, it would be nice if you could post your bootcmd as well. I got it from [1] and when it boots it says U-Boot 2013.01.01 (May 10 2013 - 06:32:54). [1] http://ftp.debian.org/debian/pool/main/u/u-boot/u-boot_2013.01.01-4_armel.deb That's the version currently in sid. I hacked flash-kernel so it doesn't assume that the kernel lives on the internal card. For entry under Machine: Globalscale Technologies Dreamplug FYI the version of flash-kernel in sid (3.10) allows you to override db entries by placing them in /etc/flash-kernel/db. That's useful to know. I tried it and it didn't work but then realised I'm running Wheezy and you said the version in sid supported that :-) -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1378032719.3541.18.ca...@computer5.home
Re: Kirkwood kernel installation
On Sat, 2013-08-31 at 19:05 +0100, Ian Campbell wrote: On Sat, 2013-08-31 at 19:58 +0200, Paul Kocialkowski wrote: When I got the dreamplug to finally boot Wheezy, during the expert mode installation on which I skipped making the system bootable, I noticed that it takes u-boot a very long time to load the uImage and uInitrd (about 2 minutes for loading both) from the internal micro sdcard while tftp takes like 20 seconds. It takes around that long here too, I think the MMC is just slow... I use an external MMC and it looked fairly instant, and I see U-Boot shows 1609040 bytes read in 222 ms (6.9 MiB/s) 7448684 bytes read in 765 ms (9.3 MiB/s) so less than a second :-) I did notice when I first got the Dreamplug that the supplied U-Boot was very slow, especially enumerating the USB devices. With the Debian U-Boot that takes about 3 or 4 seconds, then a second to load the kernel and initrd. -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1377973454.4000.3.ca...@computer5.home
Re: Anyone got Wheezy running on a Dreamplug?
On Thu, 2013-08-01 at 12:18 +0800, Adam Ward wrote: On Fri, 26 Jul 2013 06:05:07 PM Tixy wrote: The instructions look correct. The Dreamplug u-boot.kwb file linked from the site seems to be a older than the one I used from u-boot_2013.01.01-4_armel.deb [1]. There is absolutely no reason to suspect that there is anything wrong with the one on Martin's site, I just can't say I've personally used it. [1] http://ftp.debian.org/debian/pool/main/u/u-boot/u-boot_2013.01.01-4_armel.d eb Ok, looks like I can get this to work. After updating the u-boot version, Is it safe to do a dist-upgrade to get things like the current kernel etc ? I expect so, but it's not something I did as I ran the Debian installer to install a system from scratch rather than upgrade what the plug shipped with. I also didn't follow the defaults and installed to a removable SD card rather than the internal one, and modified U-Boot and flash-kernel accordingly. I like my systems on removable media so it's easy to clone a system image as a backup and swap hardware out if it goes faulty. -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1375367009.3219.13.ca...@computer5.home
Re: Anyone got Wheezy running on a Dreamplug?
On Fri, 2013-07-26 at 18:00 +0800, Adam Ward wrote: I have a Dreamplug shipped from spinnifex in Australia. The u-boot version is as follows: Marvell version U-Boot 2011.06-02334-g8f495d9-dirty (Aug 18 2011 - 02:09:07) Marvell-DreamPlug Is it safe to change to the DENX version given the instructions on Martin's site [1] [1] http://cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade/ The instructions look correct. The Dreamplug u-boot.kwb file linked from the site seems to be a older than the one I used from u-boot_2013.01.01-4_armel.deb [1]. There is absolutely no reason to suspect that there is anything wrong with the one on Martin's site, I just can't say I've personally used it. [1] http://ftp.debian.org/debian/pool/main/u/u-boot/u-boot_2013.01.01-4_armel.deb -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1374858307.3304.9.ca...@computer5.home
Re: Anyone got Wheezy running on a Dreamplug?
On Sun, 2013-06-16 at 10:48 +0100, Martin Michlmayr wrote: * Tixy t...@yxit.co.uk [2013-05-19 16:37]: Seems that Martin Michlmayr's otherwise excellent pages have just had the DreamPlug added to the list of supported devices without any indication that you need a different uImage and that the process for updating U-Boot is different. That's correct. I donn't have a DreamPlug, so I wasn't aware that other changes were required for the documentation. Thanks to your feedback, I've now updated the instructions (see attached patch). If anything else is missing, please let me know. Those changes look good to me. One thing though, the USB device numbers for GuruPlug and DreamPlug will be different that zero, as zero would be the internally fitted microSD. E.g. on a Dreamplug with the U-Boot from Debian (think stock U-Boot was same) the external MMC card is device 1, so we would need: fatload usb 1:1 ... and a USB stick would require: fatload usb 2:1 ... -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1371379596.3266.10.ca...@computer5.home
Re: Upgrading u-boot on Dreamplug
On Wed, 2013-06-12 at 07:06 -0400, Philippe Clérié wrote: On 06/11/2013 02:18 PM, Tixy wrote: On Tue, 2013-06-11 at 10:49 -0400, Philippe Clérié wrote: On 06/11/2013 09:56 AM, Eric Cooper wrote: On Tue, Jun 11, 2013 at 08:46:01AM -0400, Philippe Clérié wrote: [...] Help does not list a _nand_ command and there does not seem to be a likely replacement. Are there other options? You should be able to do the equivalent from Linux, using nandwrite from mtd-utils. Maybe I panicked to soon. There are other instructions that seem closer to the mark, notably at: http://freedomboxfoundation.org/ubootUpgradeInstructions/index.en.html. It seems that the correct command to use is _sf_. Right now, I am trying to figure out where to load the new u-boot image. It looks something like this: usb start fatload usb 2:1 0x640 u-boot.kwb sf probe 0:0 sf erase 0x0 0x10 sf write 0x640 0x0 (length of u-boot.kwb in Hex) Now if I could get confirmation that this set of commands will in fact work... :-) I went through this pain a few weeks ago, see the archives [1] for the full saga and the help I got from this list. The upshot is that the commands you quote above from the FreedomBox site should work. I managed to brick my plug when I first tried so might have mistyped something, but those same commands worked after I eventually de-brucked the DreamPlug. I do note the size to erase is twice that mentioned by one of the respondents to my thread [2], and I'm not sure what I used in the end. Not sure that it would make much difference, unless the bigger value also makes sure any on U-Boot environment is erased. To add to the confusion, at boot, U-Boot shows SF: Detected MX25L1606 with page size 256, total 1 MiB and 1MiB is 0x10, but the datasheet for the MX25L1606 says it's 16Mib i.e. 2MiB. [1] http://lists.debian.org/debian-arm/2013/05/msg00091.html [2] http://lists.debian.org/debian-arm/2013/05/msg00103.html Yes! That works. But now, the kernel gets loaded but does not boot. I tried to install Wheezy following Martin Mychlmayr's guide with the same results. One problem might be that Martin's guide loads the kernel at 0x0080 while most other instructions give 0x0640. I'd like to try loading at that address but I also need the address at which to load the initrd. You wouldn't know it by any luck? :-) I use 0x0080 for kernel and 0x0110 for initrd. Perhaps you'll have better luck once you have the right kernel+initrd, see Martin's reply. -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1371039838.3254.3.ca...@computer5.home
Re: Anyone got Wheezy running on a Dreamplug?
On Sat, 2013-05-18 at 22:07 +0100, Mike Howard wrote: u-boot update process I've used on both older and newer versions of the DP is as follows; # Following 3 steps can be done on or off the DP # Modify to suit the u-boot you require wget http://fav mirror/debian/pool/main/u/u-boot/u-boot_2013.01.01-3_armel.deb # Modify dest dir as you like dpkg-deb -x u-boot_2013.01.01-3_armel.deb u-boot_2013.01.01-3_armel # /mnt here is on any media that you will have access to when booting the DP cp -r u-boot_2013.01.01-3_armel/usr/lib/u-boot/dreamplug /mnt # On the DP usb start # Modify to ext2load if req and modify dev:part as req fatload usb 0:3 0x640 dreamplug/u-boot.kwb sf probe 0 sf erase 0x0 0x8 # 0x3AB9C = size of u-boot.kwb sf write 0x640 0x0 0x3AB9C That's it. If it didn't work for you then possible user error? File size error? Possible/probable user error, but as I've already bricked one DreamPlug and had to buy a replacement I'm very reluctant to give it another go. But you don't need to update u-boot specifically for Wheezy. You don't need FDT support either. If you have squeeze you could just upgrade. Or am I missing something? I wanted to run the stock Debian kernel, that requires a fixed U-Boot or to add a shim to flush the L2 cache like Ian Campbell showed. I also want to do a fresh install with my own choice of packages and config rather than upgrade what the plug ships with. Installing is no problem, I've done it dozens of times on various machines, I was just struggling with getting the kernel booting. Also, a U-Boot that supports FDT would be required should I want to run Testing which will have the multi-platform kernel. Unless they are going to build that with CONFIG_ARM_APPENDED_DTB, which I hope they don't as that's a hack and isn't completely robust (I believe) for people who don't append an FDT. -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1368951867.3276.17.ca...@computer5.home
Re: Anyone got Wheezy running on a Dreamplug?
On Sun, 2013-05-19 at 12:33 +0100, Ian Campbell wrote:
On Sat, 2013-05-18 at 19:00 +0100, Tixy wrote:
On Sat, 2013-05-18 at 11:40 +0100, Ian Campbell wrote:
Hi Tixy,
On Fri, 2013-05-17 at 09:24 +0100, Tixy wrote:
Does anyone know of any foolproof method of getting Wheezy running on a
Dreamplug?
I believe this requires upgrading U-Boot (to get device-tree support/fix
L2 cache issue?) but when I tried upgrading U-Boot by flashing it from
U-Boot I ended up with an expensive brick. Now this may have been user
error, but I don't want to risk bricking the new DreamPlug I bought
without instructions which are known to work. Or, perhaps the safest
thing is to load a new U-Boot from the old one if that's possible? And
in desperation I may even resort to writing a shim to make the Wheezy
kernel load with the stock U-Boot.
You can do this with devio. My NOTES file says (I've not tried this
recently, but I'm reasonably sure it worked when I made the notes):
$ (
# disable l2 caches
devio wl 0xee3f3f11,4 # mrc 15, 1, r3, cr15, cr1,
{0}
devio wl 0xe3c33501,4 # bic r3, r3, #4194304
; 0x40
devio wl 0xee2f3f11,4 # mcr 15, 1, r3, cr15, cr1,
{0}
# flush caches
devio wl 0xe3a03000,4 # mov r3, #0
devio wl 0xee073f17,4 # mcr 15, 0, r3, cr7, cr7, {0}
cat vmlinuz-3.2.0-3-kirkwood
) vmlinuz.devio
$ mkimage -A arm -O linux -T kernel -C none -a 0x8000 -e
0x8000 \
-n kernel 3.2.0-3-kirkwood -d vmlinuz.devio myuImage
This ought to work equally well with the kernel file provided by the
installer.
If does if you append the device-tree to the kernel as well. I ended up
trying to extend the devio shim for device-tree and was having problems,
then saw the Debian Kirkwood image has CONFIG_ARM_APPENDED_DTB :-)
So for others finding this thread, I ended up with this method to
convert the installer uImage into one which will boot on the DreamPlug
with the stock U-Boot which ships on the DreamPlug...
(
# disable l2 caches
devio wl 0xee3f3f11,4 # mrc 15, 1, r3, cr15, cr1, {0}
devio wl 0xe3c33501,4 # bic r3, r3, #4194304; 0x40
devio wl 0xee2f3f11,4 # mcr 15, 1, r3, cr15, cr1, {0}
# flush caches
devio wl 0xe3a03000,4 # mov r3, #0
devio wl 0xee073f17,4 # mcr 15, 0, r3, cr7, cr7, {0}
# remove uboot header from the uImage we want to boot
dd if=original-uImage bs=1 skip=64
# append dtb to kernel image
cat kirkwood-dreamplug.dtb
) vmlinuz.devio
mkimage -A arm -O linux -T kernel -C none -a 0x8000 -e
0x8000 \
-n kernel 3.2.0-4-kirkwood -d vmlinuz.devio
new-uImage
I got the dtb file from linux-image-3.2.0-4-kirkwood_3.2.41-2_armel.deb
You may have (harmlessly) ended up appending the DTB twice since I think
the installer uImage has it already there...
It doesn't, I just checked, and if it did have the DreamPlug dtb it
wouldn't work on the iconnect which also has a dtb in the kirkwood
kernel package and so I assume is also supported.
--
Tixu
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1368970873.4213.8.ca...@computer5.home
Re: Anyone got Wheezy running on a Dreamplug?
On Sun, 2013-05-19 at 15:12 +0100, Ian Campbell wrote: On Sun, 2013-05-19 at 14:41 +0100, Tixy wrote: On Sun, 2013-05-19 at 12:33 +0100, Ian Campbell wrote: You may have (harmlessly) ended up appending the DTB twice since I think the installer uImage has it already there... It doesn't, I just checked, and if it did have the DreamPlug dtb it wouldn't work on the iconnect which also has a dtb in the kirkwood kernel package and so I assume is also supported. Which kernel were you using? I was using the one linked to from http://www.cyrius.com/debian/kirkwood/sheevaplug/install/ which I now see is the SheevaPlug one. ftp://ftp.uk.debian.org/debian/dists/wheezy/main/installer-armel/current/images/kirkwood/netboot/marvell/dreamplug/ should have the device tree appended. Yes, it does. Seems that Martin Michlmayr's otherwise excellent pages have just had the DreamPlug added to the list of supported devices without any indication that you need a different uImage and that the process for updating U-Boot is different. Sitting here looking at the DreamPlug with it's ugly and fragile module taped to it so I've got a serial port, and cut'n'pasting commands 8 characters at a time because said serial doesn't have hardware flow control and will drop character otherwise, I can't help but suspect that the plug is going to get put pack in the cupboard and not see the light of day again. Now if only I had bought a couple of OpenRD Ultimates when they were available. The certainly look the business. -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1368977858.3441.32.ca...@computer5.home
Re: Anyone got Wheezy running on a Dreamplug?
On Sat, 2013-05-18 at 11:40 +0100, Ian Campbell wrote: On Fri, 2013-05-17 at 09:24 +0100, Tixy wrote: My attempts to debrick using openocd and the JTAG module were the same as another user [3] even when I scripted power cycling and openocd to run in a loop a to try and get the timing right (which was one of the suggested remedies). I gave up after 1000's of cycles in a overnight run. It does seem to be a bit of a dice roll if it works. FWIW I use: sudo openocd -f /usr/share/openocd/scripts/board/sheevaplug.cfg -s /usr/share/openocd/scripts Then telnet to localhost port and: reset;sheevaplug_init;load_image [path]/u-boot;resume 0x0060 The openocd version is the Debian package 0.5.0-1, running on amd64. Sadly based on that forum thread I don't expect that will help you. I do remember having problems with loose cables between the DP and the UART/JTAG module early on, but a firm reseating helped there. Well, what do you know... I thought I'd give this one last try, I took my bricked plug out of its case, to get better access, rammed the connectors home, then tried JTAG connection whilst pulling the cables in different directions and after about 10 tries got a U-Boot loaded into RAM :-) And I've successfully loaded and flashed the Debian U-Boot using the instructions that everyone says works. Now all I need to do is get my soldering iron out. The separate SD card board in the box had connectors which are glue in so I cut the cables, thinking it was only for the internal micro SD (which I don't need) and not realising it's needed for the external SD card as well. DOH! -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1368985793.6618.13.ca...@computer5.home
Re: Anyone got Wheezy running on a Dreamplug?
On Sat, 2013-05-18 at 11:40 +0100, Ian Campbell wrote:
Hi Tixy,
On Fri, 2013-05-17 at 09:24 +0100, Tixy wrote:
Does anyone know of any foolproof method of getting Wheezy running on a
Dreamplug?
I believe this requires upgrading U-Boot (to get device-tree support/fix
L2 cache issue?) but when I tried upgrading U-Boot by flashing it from
U-Boot I ended up with an expensive brick. Now this may have been user
error, but I don't want to risk bricking the new DreamPlug I bought
without instructions which are known to work. Or, perhaps the safest
thing is to load a new U-Boot from the old one if that's possible? And
in desperation I may even resort to writing a shim to make the Wheezy
kernel load with the stock U-Boot.
You can do this with devio. My NOTES file says (I've not tried this
recently, but I'm reasonably sure it worked when I made the notes):
$ (
# disable l2 caches
devio wl 0xee3f3f11,4 # mrc 15, 1, r3, cr15, cr1, {0}
devio wl 0xe3c33501,4 # bic r3, r3, #4194304;
0x40
devio wl 0xee2f3f11,4 # mcr 15, 1, r3, cr15, cr1, {0}
# flush caches
devio wl 0xe3a03000,4 # mov r3, #0
devio wl 0xee073f17,4 # mcr 15, 0, r3, cr7, cr7, {0}
cat vmlinuz-3.2.0-3-kirkwood
) vmlinuz.devio
$ mkimage -A arm -O linux -T kernel -C none -a 0x8000 -e
0x8000 \
-n kernel 3.2.0-3-kirkwood -d vmlinuz.devio myuImage
This ought to work equally well with the kernel file provided by the
installer.
If does if you append the device-tree to the kernel as well. I ended up
trying to extend the devio shim for device-tree and was having problems,
then saw the Debian Kirkwood image has CONFIG_ARM_APPENDED_DTB :-)
So for others finding this thread, I ended up with this method to
convert the installer uImage into one which will boot on the DreamPlug
with the stock U-Boot which ships on the DreamPlug...
(
# disable l2 caches
devio wl 0xee3f3f11,4 # mrc 15, 1, r3, cr15, cr1, {0}
devio wl 0xe3c33501,4 # bic r3, r3, #4194304; 0x40
devio wl 0xee2f3f11,4 # mcr 15, 1, r3, cr15, cr1, {0}
# flush caches
devio wl 0xe3a03000,4 # mov r3, #0
devio wl 0xee073f17,4 # mcr 15, 0, r3, cr7, cr7, {0}
# remove uboot header from the uImage we want to boot
dd if=original-uImage bs=1 skip=64
# append dtb to kernel image
cat kirkwood-dreamplug.dtb
) vmlinuz.devio
mkimage -A arm -O linux -T kernel -C none -a 0x8000 -e 0x8000 \
-n kernel 3.2.0-4-kirkwood -d vmlinuz.devio new-uImage
I got the dtb file from linux-image-3.2.0-4-kirkwood_3.2.41-2_armel.deb
Of course, I will need to do similar processing of the image the
installer puts in the boot partition, and repeat each time we get a
kernel update.
Thanks Ian for your help.
--
Tixy
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1368900026.3277.25.ca...@computer5.home
Anyone got Wheezy running on a Dreamplug?
Does anyone know of any foolproof method of getting Wheezy running on a Dreamplug? I believe this requires upgrading U-Boot (to get device-tree support/fix L2 cache issue?) but when I tried upgrading U-Boot by flashing it from U-Boot I ended up with an expensive brick. Now this may have been user error, but I don't want to risk bricking the new DreamPlug I bought without instructions which are known to work. Or, perhaps the safest thing is to load a new U-Boot from the old one if that's possible? And in desperation I may even resort to writing a shim to make the Wheezy kernel load with the stock U-Boot. The method I was following which created a brick was to use the U-Boot binary linked from Martin Michlmayr's page [1] and flash it using the the sf probe/erase/write commands from the FreedomBox site [2]. My attempts to debrick using openocd and the JTAG module were the same as another user [3] even when I scripted power cycling and openocd to run in a loop a to try and get the timing right (which was one of the suggested remedies). I gave up after 1000's of cycles in a overnight run. I then found kwuartboot [4] and thought I was saved, however both my old and new DreamPlugs die after the first xmodem packet is sent. I verified that the boot ROM is version 1.21 by sending the debug pattern to the boards and seeing the response. After sending the boot pattern I see byte 0x15 being sent from the plug every second on the serial port, which is the correct behaviour for waiting for an xmodem. However after sending the first xmodem packet the board don't send an ACK, and any further packet retries result in the packet being echoed back. I've tried sending different U-Boot files as well (e.g. the one in the Debian U-Boot package). And just in case I have a new incompatible DreamPlug variant I compared the kwbimage header from the NOR of my new stock plug with those in the images I was trying to load via UART; the header contents are the same apart from the length and CRC fields as we would expect. So that lead me to this plea for help :-) [1] http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade/ [2] http://freedomboxfoundation.org/ubootUpgradeInstructions/index.en.html [3] http://www.newit.co.uk/forum/index.php?PHPSESSID=qqriddgo7r3fqce3pj1f08f5t7topic=2619.0 [4] http://www.solinno.co.uk/public/kwuartboot/ -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1368779043.3270.39.ca...@computer5.home
Re: Bug#703209: linux: Please Add multiplatform flavour to armhf
On Thu, 2013-03-21 at 12:52 +0900, Nobuhiro Iwamatsu wrote: Hi, On Wed, Mar 20, 2013 at 12:17 AM, Paul Wise p...@debian.org wrote: On Tue, 2013-03-19 at 15:05 +, Ian Campbell wrote: I think the question here is what the `uname -r` bit should be. Specifically the $FLAVOUR in 3.x.y-z-$FLAVOUR. Woops, I missed that uname -r includes the flavour bit. I think there is an argument for making the multiplatform case be the default no-flavour flavour i.e. $FLAVOUR is armhf/arm64 etc. Or maybe that's what you are suggesting having not realised that `uname -r` currently includes the -$FLAVOUR suffix. Hrm, I think we may actually be talking about the same thing ;-) Right, my suggestion is just to use the architecture for the flavour, as is done on the other architectures. Thank you for your comment. In ARM ((but may be used on other architectures as well) ) all architectures, flavor with the name of the CPU do is that it is multiplatform? For example, armv7 flavor is multiplatform support in armhf. A single multiplatform kernel can support both armv6 and armv7 (or armv4 + armv5). I don't know if Debian plans to have separate versions for each architecture version - there may be performance benefits to this - in which case using armv6 -v7 etc sounds like a good idea. Also, a multiplatform kernel can't support armv5 and armv6, so there may need to be more than one 'mp' version anyway. -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1363855369.3242.5.ca...@computer5.home
Re: Bug#703209: linux: Please Add multiplatform flavour to armhf
On Tue, 2013-03-19 at 03:46 +, Ben Hutchings wrote: On Mon, 2013-03-18 at 08:41 +0900, Nobuhiro Iwamatsu wrote: On Sun, Mar 17, 2013 at 10:23 AM, Ben Hutchings b...@decadent.org.uk wrote: [...] In future all ARM kernels should be multi-platform, but I expect there will still be different flavours, such as for LPAE or the RT featureset. I would much prefer a name that will provide a more useful distinction in future (and not be too long!). Perhaps it should refer to the CPU requirement like the flavours for some other architectures. I see. Although it is very simple, how is armmp? [...] Sounds alright to be, but let's allow the other ARM porters a few more days to comment. 'MP' has some history as meaning multi-processor, so might be confusing. (But perhaps not confusing to many.) -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1363680223.3247.8.ca...@computer5.home
Re: arm build hardware
On Thu, 2013-03-14 at 10:40 -0400, Lennart Sorensen wrote: On Thu, Mar 14, 2013 at 09:26:45AM +0100, Sander wrote: Issues with usb-to-sata don't affect usb-to-serial, do they? FWIW, I use a handful of http://www.aten.com/products/productItem.php?model_no=UC232A and they've never failed me, with arm and x86 as both source and destination. I have an openrd-client (7x usb) in use as a consoleserver. Well that's pl2303 based. Those are not known to be the most reliable things around (and some of the comments in the linux driver are not encouraging either). For a reliable working USB serial adapter, something based on FTDI tends to just work. That is my experience too, even from the days my work PC was Windows. Most are PL2303 based though since it is much cheaper. And of course they almost never tell you what they are based on. That's why I always buy from a place that explicitly advertises as FTDI based... http://www.usbnow.co.uk/p48/USB_to_RS232_with_FTDI_Chipset_(1.8M_Cable)/product_info.html -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1363293200.3260.2.ca...@computer5.home
Re: pb with sheeva plug and usb/sd memory cards
On Thu, 2012-08-23 at 06:10 -0700, John Reiser wrote: I thought using an SD-card was faster than using a USB-stick? It can be, except that many times an SD-socket is USB internally. The USB circuitry merely moved from inside the flash memory stick, across the plug/socket boundary, and onto the main circuit board. Sheevaplug is a real MMC, the newer Guru- and Dream-plugs from GlobalScale are USB :-( -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1345743173.2586.9.ca...@computer5.home
Re: pb with sheeva plug and usb/sd memory cards
On Wed, 2012-08-22 at 15:55 +0200, Laurent Lesage wrote: I'm using sheeva plugs as asterisk servers wit debian armel ports. I've used the instructions on MArtin's site (http://www.cyrius.com/debian/kirkwood/sheevaplug/) to get the plugs run. I used SD cards at the beginning, but I found that USB keys were quicker to read/write and used usb keys. snip I tried to revert to SD card. I tried a SDHC sony (not a recent one bu a new one). I restored the system on it and it worked ... during one or 2weeks. After that, the system could not write on the card any more. the system was stil running but with lots of write errors. I restored the system once more. One day later, same problem. It seems that the SD card is not suited for that usage. I've been using a eSata Sheevaplug running Debain for a couple of years as a router/DNS/NAS/MTA system with the root filesystem on an SD card. I've never had any problem with this setup. That doesn't help solve you problems but is an indication that using and SD card isn't fundamentally flaky. -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1345664229.2706.9.ca...@computer5.home
Re: modern cheap NAS fully supported by Debian?
On Thu, 2012-07-26 at 22:16 +0100, mick wrote: On Thu, 26 Jul 2012 21:47:47 +0100 Tixy t...@yxit.co.uk allegedly wrote: On Thu, 2012-07-26 at 20:39 +0100, mick wrote: Depends what you mean by fast. But in real world usage (pulling a video file from store) it is about three times faster than an NSLU2. Consider the following tests using scp to grab a 1.1 GB video file (so some overhead in the encryption as opposed to a straight wire copy) In my experience the encryption and other overheads from ssh are a bit more than 'some'. Just tested a big file copy from my Sheevaplug and I get 6MB/s from scp, and 38MB/s over nfs. :-) Yep - but both devices were treated the same. The point is the comparison between the two devices. The slug has a slow CPU, little memory and slow networking hardware. The DNS is faster (but not, I'll concede, fast). True. I guess the point I was thinking of is that when using ssh things may well be limited by CPU performance, which, if the usecase you care about is a NAS using say nfa, then something with a slower CPU but better i/o (disk, network) may be more suitable. I'm not saying that this is the case for the devices under discussion, just putting it forward as a consideration. -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1343374461.3088.4.ca...@computer2.home
Re: modern cheap NAS fully supported by Debian?
On Thu, 2012-07-26 at 20:39 +0100, mick wrote: Depends what you mean by fast. But in real world usage (pulling a video file from store) it is about three times faster than an NSLU2. Consider the following tests using scp to grab a 1.1 GB video file (so some overhead in the encryption as opposed to a straight wire copy) In my experience the encryption and other overheads from ssh are a bit more than 'some'. Just tested a big file copy from my Sheevaplug and I get 6MB/s from scp, and 38MB/s over nfs. -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1343335667.3042.6.ca...@computer2.home
Re: armel qualification for Wheezy
On Thu, 2012-05-24 at 15:36 -0400, Lennart Sorensen wrote: On Thu, May 24, 2012 at 07:12:25PM +0100, Tixy wrote: On Thu, 2012-05-24 at 12:22 -0400, Lennart Sorensen wrote: How are you doing the build using qemu's cpu emulator? I remember last I played with it I had issues with shared libraries where the command i wanted to run needed to find its shared libraries, but if I set the LD_LIBRARY_PATH, then qemu tried to use the other CPUs libraries and wouldn't run. Has this been fixed somehow? Static binaries were fine of course. Here is the crib sheet I wrote when I set this up, it was on a Debian Wheezy system, but my ARM chroot contains Ubuntu Precise as that is what I am targeting in my day job. (Hopefully Debian will work too.) # in these instructions /arm is the directory where I installed my # chroot and tixy is my linux username, replace as appropriate... # # /data is where I have all my source code and other files so I add that # to schroot fstab below, do similar with directories where you have # files you want to access inside the chroot. (Note, home directories # are already available.) su apt-get install debootstrap qemu-user-static binfmt-support schroot debootstrap --foreign --arch=armhf --variant=buildd precise /arm \ http://ports.ubuntu.com/ubuntu-ports cp /usr/bin/qemu-arm-static /arm/usr/bin chroot /arm /debootstrap/debootstrap --second-stage exit # Add to /etc/schroot/schroot.conf [arm] description=ARM Chroot type=directory directory=/arm users=tixy groups=tixy root-groups=root aliases=default # Edit /etc/schroot/default/fstab to add /data /data nonerw,bind 0 0 /run/runnonerw,bind 0 0 # Edit /arm/etc/apt/sources.list to have deb http://ports.ubuntu.com/ precise main universe deb-src http://ports.ubuntu.com/ precise main universe deb http://ports.ubuntu.com/ precise-security main universe deb-src http://ports.ubuntu.com/ precise-security main universe deb http://ports.ubuntu.com/ precise-updates main universe deb-src http://ports.ubuntu.com/ precise-updates main universe schroot -c arm adduser tixy usermod -a -G sudo tixy # As above doesn't seem to work, edit /etc/sudoes to add tixyALL=(ALL:ALL) ALL exit exit # Any time you want to enter the chroot do schroot -c arm OK, so the qemu is actually static. That probably solves the problem I had with it a few years ago. Where does anything tell the system to use qemu to run stiff? I could understand if binmisc was setup for it, but I see nothing that should make it get used. Magic? ;-) Something in the packaging of binfmt-support and/or qemu-user-static? I was just following instructions I picked up on the web. I can assure you the work because I had a disk crash a while back and did a system re-install including following these instructions to setup my ARM chroot again. (That's one of the reasons I write my own crib sheets when I do a task like this :-) -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337927699.2953.7.ca...@computer2.home
Re: armel qualification for Wheezy
On Wed, 2012-05-23 at 17:45 -0400, Lennart Sorensen wrote: On Wed, May 23, 2012 at 09:02:33PM +0100, Tixy wrote: I may be being naive, but could an X86 PC be used with an ARM chroot and qemu-arm-static to emulate ARM instructions? Or is qemu not stable enough, or the emulated environment different enough that package building would fail (e.g. through use of uname)? It is _horribly_ slow. Not that horrible. I just did a kernel build on my laptop in an ARM chroot and it took 19m43s, doing it as a cross-build took 1m14s. I haven't got my Pandaboard setup to do a comparison, but I suspect it wouldn't be much faster than my emulated ARM run. PCs have the advantage of RAM (assuming QEMU can handle 2GB+), fast hardware and multiple cores. Yes, but qemu doesn't really use more than one cpu, can't (last I checked) emulate more than one cpu core, and since it is emulating is rather slow (although it is fast as emulators go). I'm not talking about using QEMU as a system emulator, just an instruction set emulator. So ARM processes are running and scheduled as native X86 PC processes, just using QEMU to interpret the instructions in ARM ELF files. (There may be other magic going on, all I really know about QEMU is how to make use of it following cut'n'paste instruction from the web). In the kernel building example I mentioned I was using make -j8 and that went a _lot_ faster than -j1; I didn't wait to get final timings for a single threaded build. -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337846397.2859.4.ca...@computer2.home
Re: armel qualification for Wheezy
On Thu, 2012-05-24 at 12:22 -0400, Lennart Sorensen wrote: How are you doing the build using qemu's cpu emulator? I remember last I played with it I had issues with shared libraries where the command i wanted to run needed to find its shared libraries, but if I set the LD_LIBRARY_PATH, then qemu tried to use the other CPUs libraries and wouldn't run. Has this been fixed somehow? Static binaries were fine of course. Here is the crib sheet I wrote when I set this up, it was on a Debian Wheezy system, but my ARM chroot contains Ubuntu Precise as that is what I am targeting in my day job. (Hopefully Debian will work too.) # in these instructions /arm is the directory where I installed my # chroot and tixy is my linux username, replace as appropriate... # # /data is where I have all my source code and other files so I add that # to schroot fstab below, do similar with directories where you have # files you want to access inside the chroot. (Note, home directories # are already available.) su apt-get install debootstrap qemu-user-static binfmt-support schroot debootstrap --foreign --arch=armhf --variant=buildd precise /arm \ http://ports.ubuntu.com/ubuntu-ports cp /usr/bin/qemu-arm-static /arm/usr/bin chroot /arm /debootstrap/debootstrap --second-stage exit # Add to /etc/schroot/schroot.conf [arm] description=ARM Chroot type=directory directory=/arm users=tixy groups=tixy root-groups=root aliases=default # Edit /etc/schroot/default/fstab to add /data /data nonerw,bind 0 0 /run/runnonerw,bind 0 0 # Edit /arm/etc/apt/sources.list to have deb http://ports.ubuntu.com/ precise main universe deb-src http://ports.ubuntu.com/ precise main universe deb http://ports.ubuntu.com/ precise-security main universe deb-src http://ports.ubuntu.com/ precise-security main universe deb http://ports.ubuntu.com/ precise-updates main universe deb-src http://ports.ubuntu.com/ precise-updates main universe schroot -c arm adduser tixy usermod -a -G sudo tixy # As above doesn't seem to work, edit /etc/sudoes to add tixyALL=(ALL:ALL) ALL exit exit # Any time you want to enter the chroot do schroot -c arm -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337883145.2945.12.ca...@computer2.home
Re: armel qualification for Wheezy
On Mon, 2012-05-21 at 17:15 +0300, Riku Voipio wrote: If we really want to replace ancina quickly, we could get some i.mx53 quick start boards like the ones currently used as armhf buildd's. I'd like not to introduce new hardware models as buildd's unless they are significantly faster as the old ones. I may be being naive, but could an X86 PC be used with an ARM chroot and qemu-arm-static to emulate ARM instructions? Or is qemu not stable enough, or the emulated environment different enough that package building would fail (e.g. through use of uname)? PCs have the advantage of RAM (assuming QEMU can handle 2GB+), fast hardware and multiple cores. -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337803353.2862.7.ca...@computer2.home
Re: armel qualification for Wheezy
On Mon, 2012-05-21 at 16:39 +0100, Steve McIntyre wrote: Then again, the imx53s are not as stable as I had hoped. Of the 9 I set up, 1 is just about dead and another is dying. They're also really unhappy with the pl2303 USB serial adapters I've got, which is a PITA. I've always had trouble with Prolific serial adaptors but FTDI based ones have always worked a treat on my ARM boards and PCs. Now I've found a convenient source for those [1] I stick with them. -- Tixy [1] http://www.usbnow.co.uk/p48/USB_to_RS232_with_FTDI_Chipset_(1.8M_Cable)/product_info.html -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337674594.2845.5.ca...@computer2.home
Re: My progress on armhf: xf86-video-msm for armhf attempt. Please test.
On Tue, 2011-08-30 at 23:34 -0400, Lennart Sorensen wrote: My changes were to remove -mfpu=softfp and -mthumb-interworking, since as far as I can tell armhf uses -mfpu=hardfp and -mno-thumbinterworking by default. Is that true? For ARMv7, interworking is essentially free and Thumb code would likely be faster due to its smaller memory footprint. So I would have thought that not only should Thumb code be catered for, but actively encouraged. Or am I missing something? -- Tixy -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1314771798.25591.7.camel@computer2
Re: Suggestions for a SheevaPlug replacement
On Tue, 2011-03-29 at 14:42 +0200, Arnaud Patard wrote: David Given d...@cowlark.com writes: [...] I also note that there's a SheevaPlug with eSATA, and it's at about the same price as the original SheevaPlug. Now, if only this had two ethernet ports... you have guruplugs server which has 2 ethernets and esata. One can nearly say that dreamplug is some kind of evolution of guruplug servers. I wouldn't recommend the Guruplug, the fan sounds like an electric razor and too loud and annoying to want to be in the same room as it. I removed the fan and power supply, but ended up junking it anyway as I couldn't get it to boot reliably from the MMC card. (The MMC controller is on the end of a USB bus.) I stuck to using my eSata SheevaPlug when I realised I could run a firewall with only one ethernet port. [1] [1] http://lists.debian.org/debian-user/2011/02/msg01207.html -- Tixy () The ASCII Ribbon Campaign (www.asciiribbon.org) /\ Against HTML e-mail and proprietary attachments -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1301406178.2519.141.ca...@computer2.home
Re: LEDs on a Sheevaplug
On Mon, 2011-02-07 at 23:12 +0100, Sven Radde wrote: Hi fellows, this is a question partly out of cusiosity: What do the LEDs on a Sheevaplug mean? It's an eSata model and running Debian Squeeze, if that matters. I'm ever-so-slightly worried since I have red and blue lighted now and I think I remember that it used to be blue and green when I was still just toying around with the preinstalled Ubuntu. Debian appears to work fine, though. [...] My eSata Sheevaplug running Squeeze has a blue and a green LED. I don't know what they mean either though. -- Tixy () The ASCII Ribbon Campaign (www.asciiribbon.org) /\ Against HTML e-mail and proprietary attachments -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1297148602.2288.2.ca...@computer2.home
Latest testing/sid kernel crashes on SheevaPlug
Just a warning to SheevaPlug users, after upgrading the kernel to 2.6.32-23, I found my plug crashes on boot. I'm not alone, I found this has already been reported as a bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597302 -- Tixy () The ASCII Ribbon Campaign (www.asciiribbon.org) /\ Against HTML e-mail and proprietary attachments -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1285097792.12910.5.ca...@computer2.home
Re: SheevaPlug install hangs at Configuring linux-image-2.6.32-5-kirkwood
On Wed, 2010-09-15 at 09:56 +0200, Gandalf wrote: Le 15/09/2010 08:34, Tixy a écrit : On Wed, 2010-09-15 at 08:05 +0200, Gandalf wrote: Le 14/09/2010 23:52, Martin Michlmayr a écrit : * Tixy debianu...@tixy.myzen.co.uk [2010-09-11 22:09]: When installing [1] Squeeze to an SD Card on a eSata SheevaPlug, the installer hangs at 83% done with it saying Configuring linux-image-2.6.32-5-kirkwood. What version of D-I was used ? I used: http://www.cyrius.com/tmp/beta1/marvell/sheevaplug/uImage Then give a try to the daily built one. ftp://ftp.nl.debian.org/debian/dists/testing/main/installer-armel/current/images/kirkwood/netboot/marvell/sheevaplug/ I've now tried that build and it worked fine (images were dated 2010-09-13). There was also no signs of the USB related kernel panic, though I didn't have any USB devices attached during install so that may have made a difference. -- Tixy () The ASCII Ribbon Campaign (www.asciiribbon.org) /\ Against HTML e-mail and proprietary attachments -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1284821082.2351.6.ca...@computer2.home
Re: SheevaPlug install hangs at Configuring linux-image-2.6.32-5-kirkwood
On Wed, 2010-09-15 at 08:05 +0200, Gandalf wrote: Le 14/09/2010 23:52, Martin Michlmayr a écrit : * Tixy debianu...@tixy.myzen.co.uk [2010-09-11 22:09]: When installing [1] Squeeze to an SD Card on a eSata SheevaPlug, the installer hangs at 83% done with it saying Configuring linux-image-2.6.32-5-kirkwood. What version of D-I was used ? I used: http://www.cyrius.com/tmp/beta1/marvell/sheevaplug/uImage With the beta1 of D-I, I just got a kernel panic with disk detect. I also got something like that, a backtrace on screen with something USB hci? related near the start. (I may even have also had that on the Lenny install, not sure though.) -- Tixy () The ASCII Ribbon Campaign (www.asciiribbon.org) /\ Against HTML e-mail and proprietary attachments -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1284532473.2191.9.ca...@computer2.home
Re: SheevaPlug install hangs at Configuring linux-image-2.6.32-5-kirkwood
Putting this back on the list... On Sun, 2010-09-12 at 09:45 +0200, Bob Smeets wrote: I had the same issue 2 days back on the standard Sheevaplug. When installing Squeeze, I ran into exactly the same issue. Then I installed Lenny (which installs the same linux-image-2.6.32-5-kirkwood) according to the same instructions http://www.cyrius.com/debian/kirkwood/sheevaplug/install.html and this was succesful. Thanks. Did you then upgrade to Squeeze? If there is a bug in the Squeeze version of initramfs-tools, or some other package, then I'm worried that I'll hit the same bug when I upgrade Lenny to Squeeze. Still, I might give this a go, it will help track down where the bug lies... -- Tixy () The ASCII Ribbon Campaign (www.asciiribbon.org) /\ Against HTML e-mail and proprietary attachments -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1284280574.2232.16.ca...@computer2.home
Re: SheevaPlug install hangs at Configuring linux-image-2.6.32-5-kirkwood
On Sun, 2010-09-12 at 09:36 +0100, Tixy wrote: On Sun, 2010-09-12 at 09:45 +0200, Bob Smeets wrote: I had the same issue 2 days back on the standard Sheevaplug. When installing Squeeze, I ran into exactly the same issue. Then I installed Lenny (which installs the same linux-image-2.6.32-5-kirkwood) according to the same instructions http://www.cyrius.com/debian/kirkwood/sheevaplug/install.html and this was succesful. snip I might give this a go, it will help track down where the bug lies... Trying to install Lenny didn't work either: The installer cannot find a suitable kernel package to install. I tried both and arcNumber=2678 and arcNumber=2097 in case that made any difference. (As I did with the Squeeze attempt.) I haven't updated my uboot, (it still reports 3.4.16), but I assume that doesn't make any difference once the Debian installer is running? -- Tixy () The ASCII Ribbon Campaign (www.asciiribbon.org) /\ Against HTML e-mail and proprietary attachments -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1284289204.2812.24.ca...@computer2.home
Re: SheevaPlug install hangs at Configuring linux-image-2.6.32-5-kirkwood
On Sun, 2010-09-12 at 14:15 +0200, Martin Michlmayr wrote: * Tixy debianu...@tixy.myzen.co.uk [2010-09-12 12:00]: Trying to install Lenny didn't work either: The installer cannot find a suitable kernel package to install. You probably didn't pass the right parameters when booting or used the wrong image. Thanks for making me look at the obvious :-) I checked my log files and you are correct, the repository argument was missing the double-quotes. This happened because I used echo from the command line to send the arguments to the sheevaplug. (Pasting text in puTTY seems to require a middle mouse button, which I don't have.) I've now booted Lenny, changed sources.list to squeeze and updated kernel and initrams-tools without problem; am busy updating everything else now... -- Tixy () The ASCII Ribbon Campaign (www.asciiribbon.org) /\ Against HTML e-mail and proprietary attachments -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1284315517.2364.46.ca...@computer2.home
SheevaPlug install hangs at Configuring linux-image-2.6.32-5-kirkwood
Hello all When installing [1] Squeeze to an SD Card on a eSata SheevaPlug, the installer hangs at 83% done with it saying Configuring linux-image-2.6.32-5-kirkwood. Looking at the SD card I notice that the /boot partition has a zero length file called initrd.img-2.6.32-5-kirkwood.new, so I'm guessing that it's hanging creating the RAM disk. Does anyone have any ideas as to what the problem might be? [1] http://www.cyrius.com/debian/kirkwood/sheevaplug/install.html Thanks for any help. -- Tixy () The ASCII Ribbon Campaign (www.asciiribbon.org) /\ Against HTML e-mail and proprietary attachments -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1284239377.4617.30.ca...@computer2.home
