On Mon, Jun 02, 2014 at 11:06:39AM -0300, Fabio Estevam wrote:
> Bit 7 of UCR3 is described in the i.MX reference manuals (with the exception
> of i.MX1) as follows:
>
> ADNIMP: Autobaud Detection Not Improved-. Disables new features of
> autobaud detection (See Baud Rate Automatic Detection
On Mon, 2 Jun 2014 10:46:21 +0200
Sascha Hauer wrote:
> On Fri, May 30, 2014 at 01:18:33PM +0400, Antony Pavlov wrote:
> > Hi All!
> >
> > My new barebox with picotcp support brunch is pushed to github:
> >
> > https://github.com/frantony/barebox/tree/picotcp.20140530
> >
> > For this vers
Bit 7 of UCR3 is described in the i.MX reference manuals (with the exception
of i.MX1) as follows:
ADNIMP: Autobaud Detection Not Improved-. Disables new features of
autobaud detection (See Baud Rate Automatic Detection
Protocol, for more details).
0 Autobaud detection new
> On Mon, Jun 2, 2014 at 10:38 AM, Sascha Hauer wrote:
>> How I see it pico_icmp4_ping should return the cookie so that a ping
>> abort function can be implemented:
>>
>> void pico_icmp4_ping_abort(struct pico_icmp4_ping_cookie *cookie)
Hello Sascha, et al.
PicoTCP now supports abort operations
Dear Sascha and Jan,
Sascha Hauer writes:
>
> From: Jan Luebbe
>
> mk-am35xx-spi-image can only build AM35xx images. Rename
> the tool to mk-am3xxx-spi-image and add support for the AM33xx.
>
> Signed-off-by: Sascha Hauer
> ---
> arch/arm/Makefile | 7 ++-
Hi Sascha,
On Mon, Jun 2, 2014 at 4:22 AM, Sascha Hauer wrote:
>> Any comments, Sascha?
>
> No, I assumed you resend the patch without the hunk above.
The hunk was sent below the --- line, so it is not part of the original patch.
I put it below the --- line just for clarification.
> Copy&paste isn't possible due to the whitespaces.
Hm, I think that the "Parameters:" headline is transporting the same
information. Also, the the current documantion may be lacking, but at
http://wiki.barebox.org/doku.php you can read:
There is a parameter model in barebox: each device can
Hi Holger,
On Monday 02 June 2014 11:23:28 Holger Schurig wrote:
> > But parameters can be changed by the user at run-time (e.g. "prompt>
> > enable=1"), while the remaining info is just readable. That is why we
> > used different characters.
>
> I'm not getting you. Parameters are still changeabl
On Mon, 2 Jun 2014 10:31:07 +0200
Sascha Hauer wrote:
> On Mon, Jun 02, 2014 at 09:59:31AM +0200, Holger Schurig wrote:
> > Hmm, I like that it does a rescan, so that it always display the
> > currently connected USB device automatically.
>
> Note that we only scan scan the bus once during the l
On Mon, Jun 2, 2014 at 10:38 AM, Sascha Hauer wrote:
> On Fri, May 30, 2014 at 01:14:08PM +0400, Antony Pavlov wrote:
> This must be solved in the pico_icmp4.c code. The counterpart of
> pico_tree_insert (pico_tree_delete?) must be called as an response to
> ctrlc().
>
> How I see it pico_icmp4_pi
> But parameters can be changed by the user at run-time (e.g. "prompt>
> enable=1"), while the remaining info is just readable. That is why we used
> different characters.
I'm not getting you. Parameters are still changeable after this patch.
Or do you mean " = " vs. ":"? Did you chose " = " by
On Fri, May 30, 2014 at 01:18:33PM +0400, Antony Pavlov wrote:
> Hi All!
>
> My new barebox with picotcp support brunch is pushed to github:
>
> https://github.com/frantony/barebox/tree/picotcp.20140530
>
> For this version reworked content of Daniele Lacamera's push request
> is used (see h
On Fri, May 30, 2014 at 01:14:08PM +0400, Antony Pavlov wrote:
> Picotcp tends to work in an asynchronious way.
>
> E.g. for ping we have to use "pico_icmp4_ping()"
> (to start ping task) and the special icmp4 handler
> (callback function) "cb_ping()".
>
> But the ping command in barebox works in
On Mon, Jun 02, 2014 at 09:59:31AM +0200, Holger Schurig wrote:
> Hmm, I like that it does a rescan, so that it always display the
> currently connected USB device automatically.
Note that we only scan scan the bus once during the lifetime of barebox
unless the force parameter of usb_rescan is tru
On Friday 30 May 2014 11:07:17 Holger Schurig wrote:
> Example output before of "devinfo fb0":
>
> resources:
> num : 0
> start : 0x4c242000
> size : 0x0030
> driver: none
> bus: none
>
> available modes:
> hsd100pxn1 1024x768@0
>
> Parameters:
Hmm, I like that it does a rescan, so that it always display the
currently connected USB device automatically.
However, for me a usb_rescan() isn't really hardware manipulation.
Sure, the USB device will get send down it's ID during enumeration,
but it doesn't turn things on/off, erase, program it
On Wed, May 21, 2014 at 06:11:23PM +0400, Antony Pavlov wrote:
> On Wed, 21 May 2014 15:20:21 +0200
> Holger Schurig wrote:
>
> > Nice, I would just remove the extra empty lines. Linux' "lsusb -t" for
>
> Good idea! I'll take a look on Linux' lsusb too.
>
> > example produces this:
> >
> > hol
On Fri, May 30, 2014 at 11:07:26AM +0200, Holger Schurig wrote:
> The following patches mostly change the output of various commands.
>
> Holger Schurig (10):
> drvlist: factor the driver list out of 'devinfo'
> devinfo: reduce indentation
> devinfo: make the output of "devinfo DEVICE" nicer
On Wed, May 28, 2014 at 04:57:18PM -0300, Fabio Estevam wrote:
> On Thu, May 15, 2014 at 7:05 PM, Fabio Estevam wrote:
> > Hi Sascha,
> >
> > On Thu, May 15, 2014 at 6:21 PM, Sascha Hauer
> > wrote:
> >
> >>> --- a/drivers/serial/serial_imx.c
> >>> +++ b/drivers/serial/serial_imx.c
> >>> @@ -258
On Fri, May 30, 2014 at 11:07:36AM +0200, Holger Schurig wrote:
> Some device names were in the form "imx_spi", others in the form "imx-gpt".
> As most device names used the dash and not the underscore, this device
> driver harmonizes them all.
Generally ok, but you have to fix the users aswell. I
On Fri, May 30, 2014 at 11:07:35AM +0200, Holger Schurig wrote:
> Some device names where texts like "Atheros 8035 ethernet" or similar. They
> now got a prefix "phy-" and just their name and look now much more like the
> other driver names.
The names are the same as in the Linux Kernel. We could
On Thu, May 29, 2014 at 02:44:39PM +0200, Matteo Fortini wrote:
> As stated in section 29.19.32 of SAMA5D3 Series datasheet, to move
> from CS(n) to CS(n+1) the stride is 0x14 and not 0x10 as in the
> other AT91 CPUs
>
> Signed-off-by: Matteo Fortini
> ---
> arch/arm/mach-at91/sam9_smc.c | 4 +++
22 matches
Mail list logo
