On Tue, 13 Dec 2011, John O'Donnell wrote:
> On 12/13/2011 04:56 AM, Ottavio wrote:
> > I see these two options in the qemu manual:
> >
> > -mem-path path
> > Allocate guest RAM from a temporarily created file in path.
> > -mem-prealloc
> > Preallocate memory when using -mem-path.
> >
On Tue, 26 Apr 2011, Andrzej Telszewski wrote:
> My installation procedure looked like this:
> - mounted remote NFS on /mnt,
> - used SD/MMC so the setup finally didn't complain about lack of partition,
> - in TARGET menu I selected 'Continue' without setting any target partition.
>
> Any suggest
On Mon, 28 Feb 2011, Stuart Winter wrote:
> > # INSTALL_MOD_PATH="/mnt/sd/1/" make modules_install
> > cp: cannot stat `/home/me/pandora/pandora-kernel/modules.builtin': No such
> > file or directory
> > make: *** [_modinst_] Error 1
>
> I don't know what that's about but you can search for the e
On Fri, 7 Jan 2011, Stuart Winter wrote:
> > > If this works well can you upload the .bin to bourbon please and
> > > I'll distribute that instead of the one we have atm.
> >
> > Why not compile your own u-boot binaries? I need to tidy up my
> > changes, but I can give you my patches.
>
> Becau
On Fri, 7 Jan 2011, Stuart Winter wrote:
> > The spin-up timeout in u-boot is set to 5 seconds, which seems a bit
> > low - the specs for my drive say the typical drive ready time is 13s.
> > I've increased the timeout to 30s and now it seems to work reliably.
>
> If this works well can you upl
On Thu, 6 Jan 2011, Stuart Winter wrote:
> I just tried rebooting one of the SPs and the drive times out and u-boot
> reboots, then it works.
The spin-up timeout in u-boot is set to 5 seconds, which seems a bit low -
the specs for my drive say the typical drive ready time is 13s. I've
increase
On Thu, 6 Jan 2011, Stuart Winter wrote:
> > I did have a look actually, but I think I've run into an
> > initialisation issue. It works intermittently - if you run up a
> > kernel, halt and then reset via JTAG, it will detect the drive, but
> > fail when trying to access it. If you reset the p
On Thu, 6 Jan 2011, Stuart Winter wrote:
> > When I've got some time I'll look into making it work more reliably.
>
> Have you looked into it yet ? :-)
I did have a look actually, but I think I've run into an initialisation
issue. It works intermittently - if you run up a kernel, halt and then
On Tue, 4 Jan 2011, John O'Donnell wrote:
> On 01/04/2011 07:03 AM, Stuart Winter wrote:
> >
> > > > It looks like Zipit uses an Xscale which is armv5, so it would work, as
> > > > far as I can tell.
> > >
> > > Zipit uses ARM720T (ARMv4T), the same as my GP2X primary processor (GP2X
> > > has a
On Mon, 29 Nov 2010, Stuart Winter wrote:
> On Sun, 28 Nov 2010, John O'Donnell wrote:
>
> > You are booting from ext. It is HIDEOUSLY slow. I make a small FAT partition
> > and boot from that on the guru usb.
>
> This must be something to do with the Guruplug. I boot from an ext2
> partition o
On Tue, 23 Nov 2010, Stuart Winter wrote:
> Jawkins - do you have the u-boot binary you built from the Marvell
> sources? does it have ext2 & eSATA support?
I never actually got round to building it in the end, but looking at the
latest u-boot git repo, it looks like the GuruPlug should have ext
On Fri, 8 Oct 2010, Stuart Winter wrote:
> There were a number of patches to the 13.1 kernel:
> armedslack-13.1/source/k/sources/patches/esata_sheevaplug_and_guruplug-patchset
> but as far as I knew, all of the guru plug stuff was merged into
> the upstream kernel:
>
> At present, I don't apply *
On Fri, 8 Oct 2010, John O'Donnell wrote:
> On 10/08/2010 03:19 AM, Stuart Winter wrote:
> > I know Jim on this list has received his guruplug a week ago, and they've
> > added a whopping fan to it which makes itself known in the room.
> > Perhaps you shoud send yours back for a swap.
>
> Oh I ha
On Fri, 21 May 2010, John O'Donnell wrote:
> Jim Hawkins wrote:
> > $ grep guruplug arch/arm/tools/mach-types
> > guruplugMACH_GURUPLUG GURUPLUG2659
> >
> > Try arcNumber=2659 instead.
>
> [snip]
>
> It sti
On Wed, 15 Sep 2010, Stuart Winter wrote:
> I don't see anything about the "Dockstar" in the "kirkwood
> implementations" in the Kernel armedslack ships. There might be support
> in linux 2.6.36, in which case I'll add it in when I next update the
> kernel.
Someone just posted a patch for the
On Wed, 21 Jul 2010, Stuart Winter wrote:
> I'm not too familiar with why the kernel firmware stuff gets built but I
> suspect it's just because support for a specific driver is compiled in,
> or is compiled as a module, so the corresponding fw is built and
> packaged/installed when "make modul
On Tue, 20 Jul 2010, Stuart Winter wrote:
> I am not a toolchain or architecture wizard, so I might be wrong here;
> but I think it's not just compiling it for armv4t that matters (compared
> with -march=armv4 which is what AS 12.2 used).
I have to admit to having no experience of Thumb, but I
$ grep guruplug arch/arm/tools/mach-types
guruplugMACH_GURUPLUG GURUPLUG2659
Try arcNumber=2659 instead.
Cheers,
Jim
On Fri, 21 May 2010, Stuart Winter wrote:
>
> Hi John
>
> > arcNumber=2097
>
> This value is correct for a SheevaPlug, but looking a
On Tue, 18 May 2010, Stuart Winter wrote:
> I'd guess that the right order would be numerical since the patches are
> numbered in numerical order, but junk 3 of patch 0003 doesn't apply. I
> haven't tried alternating the order yet.
You're not trying to do a patch --dry-run are you? Hunk #3 of p
19 matches
Mail list logo
