Re: [PATCH v2] arm64: compat: Implement misalignment fixups for multiword loads

2022-09-06 Thread Catalin Marinas
On Fri, 1 Jul 2022 15:53:22 +0200, Ard Biesheuvel wrote: > The 32-bit ARM kernel implements fixups on behalf of user space when > using LDM/STM or LDRD/STRD instructions on addresses that are not 32-bit > aligned. This is not something that is supported by the architecture, > but was done anyway

Re: [PATCH v2] arm64: compat: Implement misalignment fixups for multiword loads

2022-09-05 Thread Catalin Marinas
On Mon, Sep 05, 2022 at 12:04:47PM +0200, Ard Biesheuvel wrote: > On Wed, 31 Aug 2022 at 19:07, Catalin Marinas wrote: > > On Fri, Jul 01, 2022 at 03:53:22PM +0200, Ard Biesheuvel wrote: > > > +config COMPAT_ALIGNMENT_FIXUPS > > > + bool "Fix up misaligned mul

Re: [PATCH v2] arm64: compat: Implement misalignment fixups for multiword loads

2022-08-31 Thread Catalin Marinas
On Fri, Jul 01, 2022 at 03:53:22PM +0200, Ard Biesheuvel wrote: > The 32-bit ARM kernel implements fixups on behalf of user space when > using LDM/STM or LDRD/STRD instructions on addresses that are not 32-bit > aligned. This is not something that is supported by the architecture, > but was done

Re: ARMEL on low power mmu-less platforms?

2008-10-01 Thread Catalin Marinas
John Griessen [EMAIL PROTECTED] wrote: Riku Voipio wrote: On Tue, Sep 30, 2008 at 11:04:18AM -0500, John Griessen wrote: and one silicon chip from luminary has precision time protocol another great reason. You are expecting to fit debian in 256KB of flash? because that's what the luminary

Re: ARMEL on low power mmu-less platforms?

2008-10-01 Thread Catalin Marinas
John Griessen [EMAIL PROTECTED] wrote: About the Cortex-M3 port, is it ready for any of Stellaris's parts? As Riku said, you need quite a lot of memory for uClinux, so not really suited for Stellaris. I don't have any plans to submit the Cortex-M3 Linux port to the mainline kernel until we start

Re: ARMEL on low power mmu-less platforms?

2008-09-30 Thread Catalin Marinas
John Griessen [EMAIL PROTECTED] wrote: I am just wondering if any kind of debian subset even can be put on a machine without MMU? Not that easy, you would need to change the C library to uClibc since AFAIK glibc doesn't support noMMU systems. Since linux-arm has a cortex-m3 linux port (using

Re: performance comparison of ARM 266 MHz vs i386 800 MHz

2006-10-20 Thread Catalin Marinas
Bill Allombert [EMAIL PROTECTED] wrote: On Thu, Oct 19, 2006 at 10:30:29AM +0100, Catalin Marinas wrote: Bill Allombert [EMAIL PROTECTED] wrote: As far as I remember, ARM has no 32x32-32 unsigned multiply and no 32x32-64 multiply. Am I wrong ? MUL is 32x32-32 both signed and unsigned

Re: performance comparison of ARM 266 MHz vs i386 800 MHz

2006-10-19 Thread Catalin Marinas
Bill Allombert [EMAIL PROTECTED] wrote: On Wed, Oct 18, 2006 at 09:29:48AM -0400, Lennart Sorensen wrote: So the answer really becomes, that if your software does no floating point calculations, then the arm will be quite a fast chip, and otherwise it will be very slow. I would not be

Re: ARM EABI port: minimum CPU choice

2006-07-26 Thread Catalin Marinas
Dustin Harriman [EMAIL PROTECTED] wrote: I'm not a DD but I am an experienced Unix sysadmin.  And as a sysadmin I want to add my 2 cents.  Given the limited supply of effort to move Debian ARM forward, it's important to choose an easy-to-maintain, generic solution If you cut down the EABI,

Re: ARM EABI port: minimum CPU choice

2006-07-25 Thread Catalin Marinas
Martin Guy [EMAIL PROTECTED] wrote: So... is there a valid need for anyone to be able to include fragments of Thumb code in an otherwise wholly 32-bit Debian ARM system? A reason so pressing and of such widespread usefulness to outweigh the global disadvantages of including interworking?

Re: ARM EABI port: minimum CPU choice

2006-06-13 Thread Catalin Marinas
On Tue, 2006-06-13 at 10:41 +0100, Phil Blundell wrote: On Mon, 2006-06-12 at 23:54 +0200, Martin Guy wrote: Is there any reason not to make ldm the default for armv4 and above, since it seems to win most, among the various options? Two reasons: because it requires the return address to be

Re: ARM EABI port: minimum CPU choice

2006-06-12 Thread Catalin Marinas
Hi Wookey, Wookey [EMAIL PROTECTED] wrote: Debian emphasises supporting as much stuff as possible, over maximum speed. I think we should support armv4 if at all possible, and it seems that it is possible with the minor cost of a small slowdown (it would be useful to measure if it is

Re: ARM EABI port: minimum CPU choice

2006-06-12 Thread Catalin Marinas
On Mon, 2006-06-12 at 14:16 +0100, Paul Brook wrote: Martin pointed me to the AemEabiPort wiki page that suggests that the function return is tst lr, #1; moveq pc, lr; bx lr and this would work on ARMv4t as well. However, if the reason for this is to work on StrongARM (which doesn't

Re: Deciding new arm EABI port name

2006-03-30 Thread Catalin Marinas
Martin Guy [EMAIL PROTECTED] wrote: So part of the point of moving to ARM EABI is to move to an ABI that allows us to distribute binary packages that will still run on everything (well, everything down to the armv4 family anyway) ^ As I understand

Re: madplay on ARM926EJ-S versatile board

2005-08-10 Thread Catalin Marinas
Shakthi Kannan [EMAIL PROTECTED] wrote: 1. Is there any documentation on how we can build our own cramfs for the target ARM926EJ-S on a Debian system? I have Debian Sarge for x86. I can setup the CodeSourcery toolchain. How can I create the cramfs for target ARM? (I suspect you mean how to

Re: madplay on ARM926EJ-S versatile board

2005-08-04 Thread Catalin Marinas
Shakthi Kannan [EMAIL PROTECTED] wrote: --- Catalin Marinas wrote: The pre-built one doesn't have the dpkg database initialised and this is why it fails. Yes, I used the pre-built base.cramfs provided at: http://www.arm.com/linux/linux_download.html Note that this filesystem was compiled