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.
--
Best regards,
Lukasz Majewski
Samsung Poland RD Center
Hi everybody,
this is to let you know that the v2012.07-rc3 prerelease is out.
Please help testing, so we can fix any remaining issues before the
release, which is scheduled for July 30.
Please also note that you can send pull requests for the next
branch.
Thanks to all.
Best regards,
With the code that skips the 5 msecond delay if the device is ready, my fat
load time went from 80 seconds to 8 seconds. This is actually fairly close
to what it takes to do the same transfer in Linux (5 seconds). So I assume
the 5 msdelay when the device is already ready is not necessary.
On
make would spit out a message like
Generating /tmp/build/include/generated/asm-offsets.h
even when running with option -s. Fix this.
Signed-off-by: Wolfgang Denk w...@denx.de
---
Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
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 to commit
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:
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 I'm going
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 possible, I did
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 stathis.voukela...@linn.co.uk
Cc:
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 using
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
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
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 they not be
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_page
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
christian.rie...@omicron.at wrote:
[cc'd Prabhakar Lad, Tom Rini, and Scott Wood]
Tyler,
On Thu, Jul 26, 2012 at 5:37 PM, Tyler Olmstead
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 the need to
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
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 routines
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.
[PATCH 4/7]
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 that might
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 in any way.
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. We
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 discussion about DFU
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 %x %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 allocate
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
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 missing
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're loading a
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
Bill,
On Fri, Jul 27, 2012 at 10:07 AM, Bill bsou...@techsi.com 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
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, but I know
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 it for a while ...
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
DFU
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 ...
Given that they have
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);
}
int
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 should
work
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 one, as
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
exactly
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 image size.
This
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 linux/compat.h 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
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 you asking me to
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(struct QH));
-
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
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 work these into V2 of
Dear Mike,
On Sat, Jul 21, 2012 at 07:23:57 PM, Mike Frysinger wrote:
Acked-by: Mike Frysinger vap...@gentoo.org
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
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 consuming. But
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 Voukelatos
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 vap...@gentoo.org
If it's ack'ed, why does nobody apply it? What is the normal
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 are board specific init
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;
+ }
+
memset(qh, 0,
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 linux/compat.h 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.
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 because the patch
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
Those files aren't drivers. Those
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
board/samsung/universal_c210/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 this
From: Holger Brunck holger.bru...@keymile.com
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 holger.bru...@keymile.com
---
board/keymile/common/common.c |3 ---
1 files changed, 0 insertions(+), 3
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 opinion shall stay
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're loading a
From: Holger Brunck holger.bru...@keymile.com
Signed-off-by: Holger Brunck holger.bru...@keymile.com
---
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
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,
Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com
---
include/configs/mgcoge.h| 34 +-
include/configs/mgcoge3ne.h | 34 +-
2 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/include/configs/mgcoge.h
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 gerlando.fala...@keymile.com
---
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 gerlando.fala...@keymile.com
---
boards.cfg |4 +-
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
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 gerlando.fala...@keymile.com
Signed-off-by: Holger Brunck
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
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
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
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 gerlando.fala...@keymile.com
---
This patch starts series of patches adding support for USB support on
PXA255 chips.
Signed-off-by: Łukasz Dałek luk0...@gmail.com
---
arch/arm/include/asm/arch-pxa/pxa-regs.h | 247 ++
1 files changed, 247 insertions(+), 0 deletions(-)
diff --git
Compile USB ttyACM and Ethernet drivers on pxa255.
Signed-off-by: Łukasz Dałek luk0...@gmail.com
---
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
---
Signed-off-by: Łukasz Dałek luk0...@gmail.com
---
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
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
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’
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Daniel Hellstrom dan...@gaisler.com
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
-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 : [47fa74f0] lr
On Fri, Jul 27, 2012 at 12:35 PM, Bill bsou...@techsi.com 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
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:
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 See
= 3343968 (330660 hex)
## Booting kernel from Legacy Image at 4200 ...
Image Name: Linux-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
Hi Marek,
On Fri, Jul 27, 2012 at 3:39 PM, Marek Vasut ma...@denx.de 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
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 ma...@denx.de
Cc: Daniel z...@ingenic.cn
Cc: Shinya Kuribayashi skuri...@pobox.com
Cc: Xiangfu Liu
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]
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:
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 behind
1 - 100 of 126 matches
Mail list logo
