On Tue Jul 03, 2012 at 12:54:04AM +0530, Sughosh Ganu wrote:
> hi,
> While testing on hawkboard with the latest commit, i hit an issue of
> commands not being accepted.
>
> hawkboard > reset
> Unknown command '�' - try 'help'
> hawkboard >
>
> Running git bisect showed that this is caused due
New abstraction layer for performing MMC and FAT operations has been added.
It is necessary for using MMC and FAT operations from other subsystems without
the need to call "sprintf" and "run_command" afterwards.
MMC/FAT function call allows for better type checking during compilation time.
For FAT
The new do_mmcops_safe function has been added to the mmc subsystem.
It is necessary to decouple the core mmc read/write operation from
code responsible for parsing user input.
The do_mmcops_safe function shall be used from other subsystems to
read/write data to MMC devices.
Signed-off-by: Lukasz
The new do_fat_safe function has been added to the FAT handling command.
It is necessary to decouple the core fat command read/write operation from
code responsible for parsing user input.
The do_fat_safe function shall be used from other subsystems willing to
read/write data to FAT file system.
Dear Wolfgang Denk,
> Dear Marek Vasut,
>
> In message <201207270118.19524.ma...@denx.de> you wrote:
> > Check the following list, it's the list of drivers scattered (misplaced)
> > across the tree. The list is not complete and might be inaccurate. But
> > it should give a good impression of what
Dear Lukasz Majewski,
> Dear Marek Vasut,
>
> > board/samsung/goni/onenand.c
> > board/samsung/smdkc100/onenand.c
> > board/samsung/universal_c210/onenand.c
>
> Those files aren't drivers. Those are board specific init functions and
> in my opinion shall stay where they are.
That's fairy possib
Fixed some typos in the i.MX28 PMU code that sets up the VDDD and VDDIO power
rails. In addition the VDDD and VDDIO brownout offset values should be divided
by a step size before being programmed to the corresponding registers.
Signed-off-by: Stathis Voukelatos
Cc: Stefano Babic
Cc: Marek Vasu
On Tue, Jul 24, 2012 at 05:43:28PM +0200, Markus Hubig wrote:
> I looked at every single byte on the internet an I found some information
> that in order to get this bad-ass relocation to work, one needs to adapt
> at91bootstrap to work with u-boot. Could this be my problem? At the moment
> I'm usi
Hawkboard was using the wrong nand_read_page version for SPL image.
As a side effect, the u-boot image loaded by the SPL from nand
was getting corrupted.
Enable CONFIG_SYS_NAND_HW_ECC_OOBFIRST to select the correct nand_read_page
algorithm for SPL.
Signed-off-by: Linu Cherian
---
include/config
Hi @all,
one minor Problem I often read about in this list is some crappy / unreadable
console output at beginning of the U-Boot start procedure. Now I have the same
"visual" Problem.
| H�NAND: 128 MiB
| *** Warning - bad CRC, using default environment
|
| In:serial
| Out: serial
| Err:
Dear Jim Lin,
> Wolfgang,
> Is there any chance to get this feature in after Stephen explained to you?
>
> Thanks.
[...]
I'll poke into it. Can we not get rid of the added ifdef, eg. by setting up the
controller number to 1 for those that don't define CONFIG_USB_MULTI now
(everyone) and adding
Dear Lukasz Majewski,
In message <1343378116-5569-1-git-send-email-l.majew...@samsung.com> you wrote:
> New abstraction layer for performing MMC and FAT operations has been added.
> It is necessary for using MMC and FAT operations from other subsystems without
> the need to call "sprintf" and "run
Dear Marek Vasut,
In message <201207271042.48099.ma...@denx.de> you wrote:
>
> > All these are either
> >
> > 1) old versions of flash drivers that predate the cfi flash
> >implementation, so they could be replaced by the CFI driver (if
> >there was someone to test this)
>
> Well, can t
On Fri Jul 27, 2012 at 01:51:53PM +0530, Linu Cherian wrote:
> Hawkboard was using the wrong nand_read_page version for SPL image.
> As a side effect, the u-boot image loaded by the SPL from nand
> was getting corrupted.
>
> Enable CONFIG_SYS_NAND_HW_ECC_OOBFIRST to select the correct nand_read_pa
Hi Tyler/Christian,
On Fri, Jul 27, 2012 at 00:24:20, Tyler Olmstead wrote:
> Hi Christian,
>
> On Thu, Jul 26, 2012 at 10:03 AM, Christian Riesch
> wrote:
> >
> > [cc'd Prabhakar Lad, Tom Rini, and Scott Wood]
> >
> > Tyler,
> >
> > On Thu, Jul 26, 2012 at 5:37 PM, Tyler Olmstead
> > wrote:
>
Dear Wolfgang Denk,
> Dear Lukasz Majewski,
>
> In message <1343378116-5569-1-git-send-email-l.majew...@samsung.com>
> you wrote:
> > New abstraction layer for performing MMC and FAT operations has
> > been added. It is necessary for using MMC and FAT operations from
> > other subsystems without
For the DA8xx family of SoCs, the set_cpu_clk_info() function was not
initialising the DSP frequency, leading to 'bdinfo' command output such as:
[...snip...]
ARM frequency = 300 MHz
DSP frequency = -536870913 MHz
DDR frequency = 300 MHz
This commit provides a separate implementation of s
Dear Lukasz Majewski,
In message <20120727123832.69195dcd@amdc308.digital.local> you wrote:
>
> > Sorry if I don't understand, but what exactly is special with MMC and
> > FAT here?
>
> Those patches are a follow up of a discussion about DFU support in
> u-boot.
> "[PATCH 4/7] dfu: MMC specific
Dear Wolfgang Denk,
> Dear Lukasz Majewski,
>
> In message <20120727123832.69195dcd@amdc308.digital.local> you wrote:
> > > Sorry if I don't understand, but what exactly is special with MMC and
> > > FAT here?
> >
> > Those patches are a follow up of a discussion about DFU support in
> > u-boot.
Dear Marek,
In message <201207271330.46967.ma...@denx.de> you wrote:
>
> > This makes no sense to me. MMC is just one of the storagte devices we
> > support, and especially with the upcoming support of a clean device
> > model it makes no sense to handle it special in any way.
>
> Sure, but tha
Dear Wolfgang Denk,
> Dear Marek,
>
> In message <201207271330.46967.ma...@denx.de> you wrote:
> > > This makes no sense to me. MMC is just one of the storagte devices we
> > > support, and especially with the upcoming support of a clean device
> > > model it makes no sense to handle it special
Dear Lukasz Majewski,
In message <1341416922-13792-4-git-send-email-l.majew...@samsung.com> you wrote:
> New, separate driver at ./drivers/dfu has been added. It allows platform
> and storage independent operation of DFU.
Sorry for a probably stupid question, but I know basicly zero about
DFU.
Dear Marek Vasut,
> Dear Wolfgang Denk,
>
> > Dear Lukasz Majewski,
> >
> > In message <20120727123832.69195dcd@amdc308.digital.local> you
> > wrote:
> > > > Sorry if I don't understand, but what exactly is special with
> > > > MMC and FAT here?
> > >
> > > Those patches are a follow up of a di
Dear Lukasz Majewski,
In message <1341416922-13792-5-git-send-email-l.majew...@samsung.com> you wrote:
> Support for MMC storage devices to work with DFU framework.
Sorry for jumping in late.
> + switch (dfu->layout) {
> + case RAW_ADDR:
> + sprintf(cmd_buf, "mmc write 0x%x
Dear Wolfgang Denk,
> Dear Lukasz Majewski,
>
> In message <1341416922-13792-5-git-send-email-l.majew...@samsung.com> you
wrote:
> > Support for MMC storage devices to work with DFU framework.
>
> Sorry for jumping in late.
>
> > + switch (dfu->layout) {
> > + case RAW_ADDR:
> > +
Dear Benoît Thébaudeau,
> This patch takes advantage of the hardware EHCI qTD queuing mechanism to
> avoid software overhead and to make transfers as fast as possible.
>
> The only drawback is a call to memalign. However, this is fast compared to
> the transfer timings, and the heap size to alloc
Dear Benoît Thébaudeau,
> The commit 5dd95cf made the MSC driver EHCI-specific. This patch restores a
> basic support of non-EHCI HCDs, like before that commit.
>
> The fallback transfer size is certainly not optimal, but at least it should
> work like before.
[...]
Please merge this with 3/5 or
Dear Benoît Thébaudeau,
> Adjust time-out value for the new EHCI mechanism.
>
[...]
Ok, I really like this set. I believe it's only one or two reposts away from
upstream and I'd love to have it in next release (not this one, as we can't
test
it in 3 days). I admit I'm not the easiest and fast
Dear Marek Vasut,
In message <201207271443.45189.ma...@denx.de> you wrote:
>
> > For this shim layer I would actually prefer the original approach
> > (shown above) to use sprintf() to build commands based on the existing
> > command interface
>
> We discussed it for a while ... figure out the mi
Dear Benoît Thébaudeau,
> Hi Jim,
>
> On Thu, Jul 26, 2012 at 10:20:48 PM, Jim Shimer wrote:
> > I'm seeing a 5ms delay in usb_stor_BBB_transport, which occurs every
> > 10K of
> > data for fatload usb or 500ms of delay per 1MB of image size. This
> > adds up
> > to quite a bit of delay if you'r
Thanks. That did it!
However, now my new U-boot built from the mainstream Uboot runs and also
loads and unpacks the Linux kernel - but it dies after that. However,
my original U-boot from tlib works fine. Are there some patches and/or
settings I am missing?
Thanks,
Bills
On 7/26/2012
Bill,
On Fri, Jul 27, 2012 at 10:07 AM, Bill wrote:
> Thanks. That did it!
>
>
> However, now my new U-boot built from the mainstream Uboot runs and also
> loads and unpacks the Linux kernel - but it dies after that. However, my
> original U-boot from tlib works fine. Are there some patches an
Dear Wolfgang Denk,
> Dear Lukasz Majewski,
>
> In message <1341416922-13792-4-git-send-email-l.majew...@samsung.com>
> you wrote:
> > New, separate driver at ./drivers/dfu has been added. It allows
> > platform and storage independent operation of DFU.
>
> Sorry for a probably stupid question,
Dear Wolfgang Denk,
> Dear Marek Vasut,
>
> In message <201207271443.45189.ma...@denx.de> you wrote:
> > > For this shim layer I would actually prefer the original approach
> > > (shown above) to use sprintf() to build commands based on the existing
> > > command interface
> >
> > We discussed i
Dear Wolfgang Denk,
> Dear Lukasz Majewski,
>
> In message <1341416922-13792-5-git-send-email-l.majew...@samsung.com>
> you wrote:
> > Support for MMC storage devices to work with DFU framework.
>
> Sorry for jumping in late.
>
>
> > + switch (dfu->layout) {
> > + case RAW_ADDR:
> > +
Dear Lukasz,
In message <20120727151523.41406989@amdc308.digital.local> you wrote:
>
> Some clarification is needed. I've divided DFU support (PATCH v2) to
> three separate parts:
> 1. DFU transmission handling (via USB)
...
> 2. Generic DFU functions ./drivers/dfu/dfu.c - which try to abstract
>
Dear Marek Vasut,
In message <201207271515.36085.ma...@denx.de> you wrote:
>
> > sprintf(cmd_buf, "%s %s %d:%d 0x%x %s %lx",
> > command, device, ...
> >
> > and set command as needed to "fatread" or "ext2load" or whatever, and
> > device can be set to "mmc" or "usb" or ...
>
>
Dear Wolfgang Denk,
> Correct. And adaption for other devices (say, NAND or USB mass
> storage) should be trivial as well.
USB Mass Storage is also under development. It is supposed to be a
function (f_ums.c) for g_dnl.c composite gadget.
I will postpone posting it to ML until we agree for the
Dear Lukasz,
In message <20120727153345.008fde41@amdc308.digital.local> you wrote:
>
> So I suppose, that you are proposing something like this (pseudo code):
Yes, very close.
> int mmc_block_write() {
> sprintf(cmd_buf, "mmc write 0x%x %x %x")
> run_command(cmd_buf, 0);
> }
>
> in
Dear Marek Vasut,
On Fri, Jul 27, 2012 at 02:54:07 PM, Marek Vasut wrote:
> > This patch takes advantage of the hardware EHCI qTD queuing
> > mechanism to
> > avoid software overhead and to make transfers as fast as possible.
> >
> > The only drawback is a call to memalign. However, this is fast
Pins and clocks was misconfigured. It works well now.
Bye.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Dear Marek,
On Fri, Jul 27, 2012 at 02:55:38 PM, Marek Vasut wrote:
> > The commit 5dd95cf made the MSC driver EHCI-specific. This patch
> > restores a
> > basic support of non-EHCI HCDs, like before that commit.
> >
> > The fallback transfer size is certainly not optimal, but at least
> > it sho
Dear Marek,
On Fri, Jul 27, 2012 at 02:56:50 PM, Marek Vasut wrote:
> > Adjust time-out value for the new EHCI mechanism.
> >
> [...]
>
> Ok, I really like this set.
Nice to read.
> I believe it's only one or two reposts
> away from
> upstream and I'd love to have it in next release (not this
Dear Benoît Thébaudeau,
[...]
> > Ok, maybe you can please elaborate on this crazy calculation in here?
> > Or somehow
> > clarify it? Also, won't the macros in include/common.h help in a way?
> > (like
> > ROUND() etc).
>
> I have already posted a v2 for this specific patch (only 2/5) that does
Dear Marek,
On Fri, Jul 27, 2012 at 02:59:29 PM, Marek Vasut wrote:
> > Hi Jim,
> >
> > On Thu, Jul 26, 2012 at 10:20:48 PM, Jim Shimer wrote:
> > > I'm seeing a 5ms delay in usb_stor_BBB_transport, which occurs
> > > every
> > > 10K of
> > > data for fatload usb or 500ms of delay per 1MB of imag
Dear Benoît Thébaudeau,
[...]
> @@ -229,8 +230,23 @@ ehci_submit_async(struct usb_device *dev, unsigned
> long pipe, void *buffer, le16_to_cpu(req->value), le16_to_cpu(req->value),
> le16_to_cpu(req->index));
>
> + if (req != NULL)/* SETUP + ACK */
Dear Marek,
On Fri, Jul 27, 2012 at 04:01:11 PM, Marek Vasut wrote:
> > Do you think
> > using PAGE_SIZE from would be fine since these
> > 4096 are
> > nothing more than page sizes?
>
> Isn't that intel-specific?
I don't know. The code does not say so. What is sure is that page sizes should
be
Dear Benoמt Thיbaudeau,
[...]
> > > Your suggestion is interesting and might be a complement to my
> > > series. I
> > > don't have time to check its correctness right now, but I'll try
> > > soon.
> >
> > Will you two have time to work these into V2 of your series somehow
> > please?
>
> Are yo
Dear Marek,
On Fri, Jul 27, 2012 at 04:07:01 PM, Marek Vasut wrote:
> > + qtd = memalign(USB_DMA_MINALIGN, qtd_count * sizeof(struct qTD));
> > + if (qtd == NULL) {
> > + printf("unable to allocate TDs\n");
> > + return -1;
> > + }
> > +
> > memset(qh, 0, sizeof(struc
Hi all,
On 03/09/2011 02:21 PM, Detlev Zundel wrote:
Hi Heiko,
Maybe a way to go ... more comments?
Below a patch, which introduces a function, which checks for
"protection bugfixes", and if no bugfix is found the old code is
executed. Just a fast RFC patch.
bye,
Heiko
[...]
Can't we int
Dear Marek,
On Fri, Jul 27, 2012 at 04:09:42 PM, Marek Vasut wrote:
> [...]
> > > > Your suggestion is interesting and might be a complement to my
> > > > series. I
> > > > don't have time to check its correctness right now, but I'll
> > > > try
> > > > soon.
> > >
> > > Will you two have time to
Dear Mike,
On Sat, Jul 21, 2012 at 07:23:57 PM, Mike Frysinger wrote:
> Acked-by: Mike Frysinger
If it's ack'ed, why does nobody apply it? What is the normal life cycle of
patches like these that don't have a custodian?
Regards,
Benoît
___
U-Boot mail
Dear Tom Rini,
> On Mon, Jul 23, 2012 at 08:16:12AM +0200, Wolfgang Denk wrote:
>
> [snip]
>
> > Running a full MAKEALL for all architectures and boards, for all
> > (> 40) repositories, every 24 hours, requires more CPU and I/O cycles
> > that we can currently afford.
>
> MAKEALL is indeed con
Dear Stathis Voukelatos,
> Fixed some typos in the i.MX28 PMU code that sets up the VDDD and VDDIO
> power rails. In addition the VDDD and VDDIO brownout offset values should
> be divided by a step size before being programmed to the corresponding
> registers.
>
> Signed-off-by: Stathis Voukelato
Dear =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=,
In message <845266616.705298.1343398892482.javamail.r...@advansee.com> you
wrote:
>
> On Sat, Jul 21, 2012 at 07:23:57 PM, Mike Frysinger wrote:
> > Acked-by: Mike Frysinger
>
> If it's ack'ed, why does nobody apply it? What is the normal life cycl
Dear Igor Grinberg,
> Hi Marek,
>
> On 07/27/12 11:43, Marek Vasut wrote:
> > Dear Lukasz Majewski,
> >
> >> Dear Marek Vasut,
> >>
> >>> board/samsung/goni/onenand.c
> >>> board/samsung/smdkc100/onenand.c
> >>> board/samsung/universal_c210/onenand.c
> >>
> >> Those files aren't drivers. Those
Dear Benoît Thébaudeau,
> Dear Marek,
>
> On Fri, Jul 27, 2012 at 04:07:01 PM, Marek Vasut wrote:
> > > + qtd = memalign(USB_DMA_MINALIGN, qtd_count * sizeof(struct qTD));
> > > + if (qtd == NULL) {
> > > + printf("unable to allocate TDs\n");
> > > + return -1;
> > > + }
> > > +
>
Dear Benoît Thébaudeau,
> Dear Marek,
>
> On Fri, Jul 27, 2012 at 04:01:11 PM, Marek Vasut wrote:
> > > Do you think
> > > using PAGE_SIZE from would be fine since these
> > > 4096 are
> > > nothing more than page sizes?
> >
> > Isn't that intel-specific?
>
> I don't know. The code does not sa
On 07/27/2012 12:18:48 AM, Prafulla Wadaskar wrote:
>
> >
> > The appended patch is to the latest U-Boot
> > release, 2012-04. I'll see about sending
> > a patch with git as described in the
> > FAQ if I get something working.
> >
> > This patch is not to apply, but I'm
> > having a problem bec
On 07/27/12 17:30, Marek Vasut wrote:
> Dear Igor Grinberg,
>
>> Hi Marek,
>>
>> On 07/27/12 11:43, Marek Vasut wrote:
>>> Dear Lukasz Majewski,
>>>
Dear Marek Vasut,
> board/samsung/goni/onenand.c
> board/samsung/smdkc100/onenand.c
> board/samsung/universal_c210/onenand.c
>>
Dear Igor Grinberg,
> On 07/27/12 17:30, Marek Vasut wrote:
> > Dear Igor Grinberg,
> >
> >> Hi Marek,
> >>
> >> On 07/27/12 11:43, Marek Vasut wrote:
> >>> Dear Lukasz Majewski,
> >>>
> Dear Marek Vasut,
>
> > board/samsung/goni/onenand.c
> > board/samsung/smdkc100/onenand.c
On 07/26/2012 11:15:32 PM, Karl O. Pinc wrote:
> Hi,
>
> I'm looking into the kirkwood docs and found some typos.
>
> I'm not proficent in git. If there's a problem with my
> git-age, or anything else, please let me know.
I used git send-mail to send the above and it sent 2
emails (?), of which
From: Holger Brunck
This code will also be used before reallocation and during this time we
are not allowed to do these printings.
Signed-off-by: Holger Brunck
---
board/keymile/common/common.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/board/keymile/common/comm
Hi Marek,
On 07/27/12 11:43, Marek Vasut wrote:
> Dear Lukasz Majewski,
>
>> Dear Marek Vasut,
>>
>>> board/samsung/goni/onenand.c
>>> board/samsung/smdkc100/onenand.c
>>> board/samsung/universal_c210/onenand.c
>>
>> Those files aren't drivers. Those are board specific init functions and
>> in my
Dear Benoît Thébaudeau,
> Hi Jim,
>
> On Thu, Jul 26, 2012 at 10:20:48 PM, Jim Shimer wrote:
> > I'm seeing a 5ms delay in usb_stor_BBB_transport, which occurs every
> > 10K of
> > data for fatload usb or 500ms of delay per 1MB of image size. This
> > adds up
> > to quite a bit of delay if you'r
From: Holger Brunck
Signed-off-by: Holger Brunck
---
include/configs/mgcoge3ne.h |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/include/configs/mgcoge3ne.h b/include/configs/mgcoge3ne.h
index 6fa1584..43d14ba 100644
--- a/include/configs/mgcoge3ne.h
+++ b/include/con
Hello,
this patch series does a bit of housekeeping on our mgcogeXxx boards.
First we do some due code cleanups which just move code around,
then we introduce dynamic SDRAM detection so the same u-boot binary
can be used on different boards.
Gerlando Falauto (6):
powerpc/82xx: move mgcoge, mgco
Signed-off-by: Gerlando Falauto
---
include/configs/mgcoge.h| 34 +-
include/configs/mgcoge3ne.h | 34 +-
2 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/include/configs/mgcoge.h b/include/configs/mgcoge.h
in
The only file including km82xx-common.h is km82xx.h.
So there is no need to have it as a separate file.
Signed-off-by: Gerlando Falauto
---
include/configs/km/km82xx-common.h | 317
include/configs/km82xx.h | 290 -
Since mgcoge and mgcoge3ne are the only km82xx boards, there is no need
to keep them as separate .h config files.
Therefore, make mgcoge3ne.h and mgcoge.h converge into a single km82xx.h
file.
Signed-off-by: Gerlando Falauto
---
boards.cfg |4 +-
include/configs/km82xx.h
This patch adds SDRAM detection feature to km82xx boards.
To enable this feature, define CONFIG_SYS_SDRAM_LIST as the initializer
for an array of struct sdram_conf_s.
These structs will expose the bitfields within registers PSDMR and OR1 which
have to be different between configurations; common bit
mgcoge2ne was an intermediate step towards mgcoge3ne. One difference is the
smaller SDRAM on mgcoge2ne (128MB). To support both boards with the same
u-boot we use here the SDRAM detection.
This patch enables SDRAM detection between 256MB and 128MB.
So in addition to the existing 256MB geometry:
The HW guys suggested to change these two values. And these values are
now identical to the values we use on mgcoge.
PSDMR_WRC was set to 1C as it should lead to better performance.
Signed-off-by: Gerlando Falauto
Signed-off-by: Holger Brunck
---
include/configs/km82xx.h |6 --
1 files
Thanks. I tried that and got the same results. Are there any
debug/logging that I can use to see what's going on?
Also, I'm not sure which console parameters are passed to the kernel.
I've seen console, console_mainline, console_fsl, etc... Which one is
actually passed as command line pa
Feel free to merge it into your work. Thanks.
On Fri, Jul 27, 2012 at 10:17 AM, Benoît Thébaudeau <
benoit.thebaud...@advansee.com> wrote:
> Dear Marek,
>
> On Fri, Jul 27, 2012 at 04:09:42 PM, Marek Vasut wrote:
> > [...]
> > > > > Your suggestion is interesting and might be a complement to my
I agree with everything, its up to you how to apply the change.
I did see a flags field but thought having a new one was conservative (I
had no real reason to have a new field). As for the typecasts I was
following the API which tests for device ready (Monkey See Monkey Do).
Also I have no compe
Dear Gerlando Falauto,
In message <1343402200-32020-4-git-send-email-gerlando.fala...@keymile.com> you
wrote:
> Since mgcoge and mgcoge3ne are the only km82xx boards, there is no need
> to keep them as separate .h config files.
> Therefore, make mgcoge3ne.h and mgcoge.h converge into a single km8
Dear Gerlando Falauto,
In message <1343402200-32020-5-git-send-email-gerlando.fala...@keymile.com> you
wrote:
> The only file including km82xx-common.h is km82xx.h.
> So there is no need to have it as a separate file.
>
> Signed-off-by: Gerlando Falauto
> ---
> include/configs/km/km82xx-common
This patch starts series of patches adding support for USB support on
PXA255 chips.
Signed-off-by: Łukasz Dałek
---
arch/arm/include/asm/arch-pxa/pxa-regs.h | 247 ++
1 files changed, 247 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-pxa/pxa-r
Compile USB ttyACM and Ethernet drivers on pxa255.
Signed-off-by: Łukasz Dałek
---
drivers/usb/gadget/Makefile |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 87d1918..7307595 100644
--- a/drivers/usb/gadge
Signed-off-by: Łukasz Dałek
---
drivers/serial/usbtty.h |2 +
drivers/usb/gadget/pxa25x_udc.c | 939 +++
include/usb/pxa25x_udc.h| 65 +++
3 files changed, 1006 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/gadget/pxa25x_u
PXA25X chips don't support alternate settings so code in ether.c
disables usage of CDC.
But only code defined between DEV_CONFIG_CDC signals that network is up.
This patch is fixing this bug by addding pxa_connect_gadget() which on
pxa25x chips signals that network is up and do nothing on any other
cmd_bdinfo.c: In function ‘do_bdinfo’:
cmd_bdinfo.c:220:9: warning: format ‘%lx’ expects argument of type ‘long
unsigned int’, but argument 2 has type ‘int’ [-Wformat]
cmd_bdinfo.c:222:9: warning: format ‘%lx’ expects argument of type ‘long
unsigned int’, but argument 2 has type ‘int’ [-Wformat]
greth.c: In function ‘greth_recv’:
greth.c:507:3: warning: format ‘%lx’ expects argument of type ‘long unsigned
int’, but argument 2 has type ‘unsigned int’ [-Wformat]
greth.c:507:3: warning: format ‘%lx’ expects argument of type ‘long unsigned
int’, but argument 3 has type ‘unsigned int’ [-Wform
Signed-off-by: Marek Vasut
Cc: Daniel Hellstrom
Cc: u-boot...@lists.denx.de
---
arch/sparc/cpu/leon2/interrupts.c |6 +++---
arch/sparc/cpu/leon3/interrupts.c |6 +++---
arch/sparc/lib/board.c|1 -
3 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/sparc/
inux-3.5.0-next-20120727+
Created: 2012-07-27 17:27:30 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:3343904 Bytes = 3.2 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... data abort
pc : [<47fa
On Fri, Jul 27, 2012 at 12:35 PM, Bill wrote:
> Thanks. I tried that and got the same results. Are there any debug/logging
> that I can use to see what's going on?
I just tried it here and 2012.07-rc3 does not boot for me too.
I started another thread on that.
I suggest you to use 2012.04.01.
Import ashldr3, ashrdi3 and lshrdi3 to squash possible libgcc fp mismatch,
resulting in the following warning:
mips-linux-gnu-ld: Warning:
/usr/lib/gcc/mips-linux-gnu/4.7/libgcc.a(_lshrdi3.o) uses hard float, u-boot
uses soft float
mips-linux-gnu-ld: Warning:
/usr/lib/gcc/mips-linux-gnu/4.7/lib
Dear Jim Shimer,
> I agree with everything, its up to you how to apply the change.
Heh ;-)
> I did see a flags field but thought having a new one was conservative (I
> had no real reason to have a new field). As for the typecasts I was
> following the API which tests for device ready (Monkey S
###
> #
>
> done
> Bytes transferred = 3343968 (330660 hex)
> ## Booting kernel from Legacy Image at 4200 ...
>Image Name: Linux-3.5.0-next-20120727+
&g
Hi Marek,
On Fri, Jul 27, 2012 at 3:39 PM, Marek Vasut wrote:
> I'm stuck at 20120723 for a bit ... I'll need to resync. Do you suspect uboot
> issue or kernel bug?
Looks like a U-boot issue, as even the kernel from linux-stable is not
booting with 2012.07-rc3
Regards,
Fabio Estevam
_
Write the TSCR register via 32bit write instead of 16bit one.
The register is 32bit wide and bit 16 is being set, triggering
gcc overflow error and making the code broken.
Signed-off-by: Marek Vasut
Cc: Daniel
Cc: Shinya Kuribayashi
Cc: Xiangfu Liu
---
arch/mips/cpu/xburst/cpu.c |2 +-
1
The timer code contains more halfword writes which trigger gcc errors.
The registers are again 32bit, yet written by 16bit writes, fix this:
timer.c: In function ‘reset_timer_masked’:
timer.c:37:2: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
tim
The lb60 board accesses the clkgr register, which is 32bit via
16bit IO ops. This causes malfunction. Fix this.
qi_lb60.c: In function ‘cpm_init’:
qi_lb60.c:72:2: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
qi_lb60.c:84:2: warning: dereferencing
On Friday 27 July 2012 14:35:25 Marek Vasut wrote:
> --- a/arch/mips/lib/Makefile
> +++ b/arch/mips/lib/Makefile
> @@ -34,6 +34,8 @@ else
> COBJS-y += bootm.o
> endif
>
> +COBJS-y += ashldi3.o ashrdi3.o lshrdi3.o
pretty sure this belongs behind USE_PRIVATE_LIBGCC
-mike
signature.asc
Dear Mike Frysinger,
> On Friday 27 July 2012 14:35:25 Marek Vasut wrote:
> > --- a/arch/mips/lib/Makefile
> > +++ b/arch/mips/lib/Makefile
> > @@ -34,6 +34,8 @@ else
> >
> > COBJS-y+= bootm.o
> > endif
> >
> > +COBJS-y+= ashldi3.o ashrdi3.o lshrdi3.o
>
> pretty sure this belongs behi
Dear Fabio Estevam,
> Hi Marek,
>
> On Fri, Jul 27, 2012 at 3:39 PM, Marek Vasut wrote:
> > I'm stuck at 20120723 for a bit ... I'll need to resync. Do you suspect
> > uboot issue or kernel bug?
>
> Looks like a U-boot issue, as even the kernel from linux-stable is not
> booting with 2012.07-rc
Hi Marek,
On Fri, Jul 27, 2012 at 4:11 PM, Marek Vasut wrote:
> I see, we need to bisect this then. Can you please take care of it? Ping me
> via
> jabber/googlecrap once you have time to poke into this.
Yes, I will bisect it and will let you know. Hopefully I will be able
to work on this some
Import ashldr3, ashrdi3 and lshrdi3 to squash possible libgcc fp mismatch,
resulting in the following warning:
mips-linux-gnu-ld: Warning:
/usr/lib/gcc/mips-linux-gnu/4.7/libgcc.a(_lshrdi3.o) uses hard float, u-boot
uses soft float
mips-linux-gnu-ld: Warning:
/usr/lib/gcc/mips-linux-gnu/4.7/lib
This caused namespace clash with same macro defined in include/config.h:
cmd_bc3450.c:55:0: warning: "CONFIG_SYS_CPU" redefined [enabled by default]
In file included from /tmp/u-boot-marex/include/command.h:30:0,
from /tmp/u-boot-marex/include/image.h:49,
from /tm
1 - 100 of 122 matches
Mail list logo
