On Mon, May 30, 2011 at 02:17, Andreas Färber wrote:
> Am 16.05.2011 um 12:57 schrieb Ben Leslie:
>
>> On Wed, May 11, 2011 at 23:54, Peter Maydell
>> wrote:
>>>
>>> On 7 May 2011 12:40, Alexander Graf wrote:
>>>>
>>>> So I sup
Hi all,
I'm new to the list, so hopefully I'm not retracing old ground (I did
try to search the
archives, but maybe I missed something).
The problem I have is that when using the Stellarris ARMv7M target if I load an
ELF file as my kernel, and some of the ELF segments are outside the range of
mem
Hi all,
For some current software development I'm doing I've found it most easy
to use Qemu in the following manner
qemu-system-arm -M lm3s811evb -s -S & arm-eabi-gdb
>From GDB I then load any code I want to debug and test and run it.
For this to work however, I needed to make a small change t
On Thu, May 5, 2011 at 19:56, Peter Maydell wrote:
> On 5 May 2011 09:23, Ben Leslie wrote:
>> FWIW, the reason why I'm not using -kernel is that the current
>> way the armv7m code works, it expects the provided kernel to
>> be a full flash image including appropr
Hi all,
Are there any objections to adding a --disable-cocoa configure option?
For simulating ARM microcontrollers I have no desire or need for graphics.
Thanks,
Benno
On Wed, May 11, 2011 at 23:54, Peter Maydell wrote:
> On 7 May 2011 12:40, Alexander Graf wrote:
>> So I suppose the only thing missing is a --disable-cocoa option, yup.
>
> I've just noticed that some of the code in block/raw-posix.c
> uses the CONFIG_COCOA #define to gate whether to do MacOSX
>
Abort on attempts to load out-of-range ROMs
Change ROM loading behaviour so that attempts to load ROMs that fall outside
valid memory ranges causing an abort with a useful error message, rather
than silently ignoring the problem.
Signed-off-by: Ben Leslie
---
exec.c |2 +-
1 files changed
I have encountered a number of devices (mostly mobile phones) which seem to
get very confused if a "SET CONFIGURATION" control transfer (for the same
interface) is performed twice.
Specifically, after receiving a 2nd SET CONFIGURATION (for the same
interface) the device times out on future bulk ou
On Fri, 5 Mar 2021 at 01:31, Gerd Hoffmann wrote:
> Hi,
>
> > Would adding support to host-libusb to use these
> > ioctl to claim the port be beneficial?
>
> I don't feel like side-stepping libusb. That is asking for trouble
> because usbdevfs might behave differently then and confuse libusb.
When usb_host_get_port is called for a root-hub device what string should
be output in the port parameter?
The current behaviour writes a string with whatever stack value happened to
be in the paths stack array.
Possible behaviours that I can see being useful are:
1: Don't modify the port parame
On Tue, 9 Mar 2021 at 18:24, Gerd Hoffmann wrote:
> On Tue, Mar 09, 2021 at 10:54:15AM +1100, Ben Leslie wrote:
> > When usb_host_get_port is called for a root-hub device what string should
> > be output in the port parameter?
>
> Just the port number, as string.
>
>
On Fri, 5 Mar 2021 at 11:50, Ben Leslie wrote:
> On Fri, 5 Mar 2021 at 01:31, Gerd Hoffmann wrote:
>
>> Hi,
>>
>> > Would adding support to host-libusb to use these
>> > ioctl to claim the port be beneficial?
>>
>> I don't feel like side-st
12 matches
Mail list logo
