Re: [U-Boot] Pull request u-boot-blackfin.git
On Wednesday, January 12, 2011 18:47:53 Wolfgang Denk wrote: Mike Frysinger wrote: that's crap. the whole point of the summary message is to *summarize* the patchset and give an overview of what's going on. Right. But (links to) patches are NOT posted in a summary message but sperately, with appropriate subject and full commit message. And a link to some git repo is NOT accepted. Please (re-) read http://www.denx.de/wiki/U-Boot/Patches you mean re-read after you just updated it to ban things i was doing -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support Asix's AX88783 ethernet chip v1.00
On Friday, February 04, 2011 14:56:42 Joe Xue wrote:
+static int ax88783_init(struct eth_device *dev, bd_t * bd)
+{
+ ...
+ /* set mac address*/
+ mactmp[0] = dev-enetaddr[5];
+ mactmp[1] = dev-enetaddr[4];
+ mactmp[2] = dev-enetaddr[3];
+ mactmp[3] = dev-enetaddr[2];
+ writel(*mac, reg-p0mac0);
+
+ mactmp[0] = dev-enetaddr[1];
+ mactmp[1] = dev-enetaddr[0];
+ writel(*mac, reg-p0mac1);
+
+ /* write mac to forward entry */
+ mactmp[0] = dev-enetaddr[3];
+ mactmp[1] = dev-enetaddr[2];
+ mactmp[2] = dev-enetaddr[1];
+ mactmp[3] = dev-enetaddr[0];
+ writel(*mac, reg-ftdata);
+
+ tmp = dev-enetaddr[4] | (dev-enetaddr[5]8) | \
+ FTCMD_FT_PORT(0x2) | FTCMD_FT_STATIC | \
+ FTCMD_WRITE_FT;
+ writel(tmp, reg-ftcmd);
implement eth_device-write_hwaddr rather than inlining the code in the init
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-BOOT] [PATCH V2] bootm: replace blob_start with image_start
On Thursday, February 03, 2011 21:32:10 Lei Wen wrote:
On Mon, Jan 10, 2011 at 6:21 PM, Lei Wen wrote:
For uImage always has a 64 bytes header, we couldn't expect to do
the xip from the header but should xip from the image start.
The latter logic in that section is also move the image from image_start
to the load address, so sync this logic to the xip operation.
Signed-off-by: Lei Wen lei...@marvell.com
---
V2: keep the original XIP setting to compare with blob_start.
This would make original uImage still could works, since
it modify the make uImage Makefile in the kernel.
common/cmd_bootm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 18019d6..778f6a4 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -344,7 +344,7 @@ static int bootm_load_os(image_info_t os, ulong
*load_end, int boot_progress)
switch (comp) {
case IH_COMP_NONE:
- if (load == blob_start) {
+ if (load == blob_start || load == image_start) {
printf ( XIP %s ... , type_name);
} else {
printf ( Loading %s ... , type_name);
How about merge this patch into arm git tree?
this is not an arm patch and so is not appropriate for that repo. it needs to
go through Wolfgang.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-BOOT] [PATCH V2] bootm: replace blob_start with image_start
On Saturday, February 05, 2011 02:57:42 Albert ARIBAUD wrote: Did you re-test patch V2? i didnt test either ... v2 looks pretty straight forward though Acked-by: Mike Frysinger vap...@gentoo.org -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] spi subystem maintainer?
On Tuesday, February 01, 2011 11:00:39 Kumar Gala wrote: Do we have one? someone else asked me that and the answer i gave was that arch-drivers should go through arch trees, but common code changes i can help run through my tree. but in this case i guess you're not asking about how to get a patch merged ... -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] write to mcBsp address space
Albert ARIBAUD albert.aribaud at free.fr writes: Hi Ran, Le 15/02/2011 07:35, Ran Shalit a écrit : Hello, I'm working on OMAPL138 EVM board, with the U-BOOT. I'm trying to access and write into the register (which have write bits), but I always read 0 in all the map space of the mcBSP0 and mcBSP1. (0x01d1 - 0x1d10800, 0x01d11000 - 0x1d11800). I wonder what I missed here. any ideas are welcomed. Many SoCs have base address registers that allow remapping internal or peripheral registers anywhere in the address space, which means the actual address you're trying to get at might not be the right one. Did you check the BAR(s) and make sure the mcBsp address you're targetting is the right one for your board? Thank you very much, Ran Amicalement, Hello Albert, Thank you very much for your reply. I've checked the datasheet but I see no reference to base address registers for the mcBSP. mcBSP: http://www.ti.com/litv/pdf/sprugj6c OMAPL138: http://www.ti.com/lit/gpn/omap-l138 thanks again, Ran ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] spi subystem maintainer?
On Thursday, February 03, 2011 05:36:38 Kumar Gala wrote:
On Feb 2, 2011, at 3:30 AM, Reinhard Meyer wrote:
Dear Stefano Babic:
On 02/02/2011 08:23 AM, Kumar Gala wrote:
Wanted to see if anyone had input on how to deal with the SPI
controller on some of our newer parts. It expects command data
xfer's to happen together. However our current code does not call
spi_xfer() that way.
Which is your concrete case ? spi_xfer is responsible to setup the
controller and to start the transfer, and everything could be done
inside this function. What do you mean exactly with command and data ?
Regards,
Stefano
I think he refers to the common problem that many SPI devices
require CS to stay low during both phases of issuing the
read/write command and transfering the actual data.
Current u-boot code calls spi_xfer() two times.
Hardware controlled CS often go high between both calls, which
requires you to (at least) use GPIO controlled CS, or, even worse,
use bitbang SPI (in cases where the SPI pin assignment is in groups,
not individually).
That's correct, and with the newer FSL controller's we dont have direct
control over the CS. I'm thinking we need to have the command and
response dealt with in a single call to spi_xfer instead of what we seem
to do all over the place today:
ret = spi_xfer(spi, 8, cmd, NULL, flags);
if (ret) {
debug(SF: Failed to send command %02x: %d\n, cmd, ret);
return ret;
}
if (len) {
ret = spi_xfer(spi, len * 8, NULL, response, SPI_XFER_END);
if (ret)
debug(SF: Failed to read response (%zu bytes):
%d\n, len, ret);
}
Needs to turn into something like:
ret = spi_xfer(spi, 8 + len * 8, cmd, response, flags | SPI_XFER_END)
this should be easier in my sf branch as i unified a bunch of the functions.
but while this will probably work for the main commands, how is this supposed
to work for the status polling ? that function is fundamentally based around
setting up a transfer/command and then continuously shifting out a single
result and checking it before shifting out another. for your controller, the
only way to make it work is to do the full transaction every time.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPI flash protection
On Saturday, January 29, 2011 12:00:48 Simon Guinot wrote: It is not clear for me how to proceed. Disable the write protection from the board setup code could be an idea but a problem is that the SPI flash API don't export any helpful method... Maybe I should add one ? An another idea is disabling the write protection anyway while initializing the flash (from the low level macronix driver). It is quite straightforward but I don't know if a flash driver is allowed to do that. After all, a flash could be protected for some good reasons. current behavior is for SPI flash drivers to clear all protection bits during init. sst.c does exactly this. if you wanted to extend the SPI flash API to include protect support as well as add a protect subcommand to sf (all of this would be behind a define like CONFIG_SPI_FLASH_PROTECTION), that'd be great. otherwise, in the short term, i'd suggest you implement something like sst_unlock in the macronix driver. i can take care of merging that. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BSS footprint of FAT very high - SPL issues
On Tuesday, February 01, 2011 00:23:46 Aneesh V wrote: BSS footprint of fat.c is very high. It has three buffers each of size 64KB. To workaround this problem I have done something like below(The way x-loader works around this problem today). CONFIG_SYS_SPL_FAT_BUFFER_BASE is in SDRAM.Is this ok? Also, I was wondering why we need 3 such scratch buffers in this implementation. I do not understand this code. But I was wondering if we could work with just one 64K buffer? i'd be pretty surprised if these couldnt be cleaned up in some way. sucking up 64KiB * 3 just for vfat is pretty f-in crazy. no other FS code needs this. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] disk/part.c: fix potential stack overflow bug
If the param pass to get_dev is not the one defined in the block_drvr,
it could make uboot becomes unstable, for it would continue run after
search complete the block_drvr table.
Signed-off-by: Lei Wen lei...@marvell.com
---
disk/part.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/disk/part.c b/disk/part.c
index 13723f2..f07a17f 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -84,7 +84,7 @@ block_dev_desc_t *get_dev(char* ifname, int dev)
#ifdef CONFIG_NEEDS_MANUAL_RELOC
name += gd-reloc_off;
#endif
- while (name) {
+ while (drvr-name) {
name = drvr-name;
reloc_get_dev = drvr-get_dev;
#ifdef CONFIG_NEEDS_MANUAL_RELOC
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
On Tuesday, February 01, 2011 15:40:13 Scott Wood wrote: Before 8aba9dc, the flags for the final link were produced by taking the existing LDFLAGS, and adding: -Bstatic -T linkerscript $(PLATFORM_LDFLAGS) -Ttext addr. i think you're skipping a fairly large piece of the picture -- the whole reason for 8aba9dc commit in the first place: commit 6d8962e814 (introduction of partial linking). before that commit, the linker was only used in one place: the final u-boot link. because of that, LDFLAGS was only used in one place. so people put both target-specific (u-boot) and linker-specific (ld) flags into the same place (LDFLAGS). but with partial linking, that was no longer possible. we needed a way to differentiate between the two and thus LDFLAGS_$@ was born. so commit 8aba9dc is not something made for fun, but to fix real bugs people were seeing while building with bi-endian toolchains (arm/superh/mips/probably others), or bi-abi toolchains (blackfin/arm/probably others). This included anything that cpu/board code added to LDFLAGS -- some architectures added --gc-sections, x86 added --cref, etc. Since the above flags are added to LDFLAGS, rather than replacing them, these flags got used in the final link. Commit 8aba9dc introduces LDFLAGS_u-boot, so that LDFLAGS is no longer the source for the flags for the final link. It generates LDFLAGS_u-boot using PLATFORM_LDFLAGS, not LDFLAGS. It converts most of the board/cpu updates to LDFLAGS into LDFLAGS_u-boot, but it missed --cref. err, i dont think this is correct. LDFLAGS is no longer the *only* source for the final link. if you look at the actual target, you'll see it using $(LDFLAGS) $(LDFLAGS_$(@F)). I don't see any other LDFLAGS changes in board/cpu code, so the distinction between using LDFLAGS and PLATFORM_LDFLAGS should have no other impact on current boards. However, the patch appears to be intended to support platform linker flags that need to be used during partial link, which would involve board/cpu additions to LDFLAGS. This change would break that only if those options need to be used for partial link *only*, and cannot be used in the final link. In such a case I'd suggest using something like LDFLAGS_PARTIAL to make this explicit. But I'd be surprised if that were actually the case. if Linux hasnt had an issue with flags that are valid only during partial linking, then i dont think u-boot will either. If you're looking to cut down on the number of variables, it's not clear to me what PLATFORM_LDFLAGS is supposed to mean distinct from adding to LDFLAGS. historically, ive never really seen much (any?) value in the split between PLATFORM_XXX and XXX. i say we kill all the PLATFORM_XXX cruft. ultimately, LDFLAGS_FINAL makes sense to me. we cant override LD, nor can we override LDFLAGS, and it sucks if people have to duplicate flags in multiple variables when all they care about is the final link. it's unavoidable pain imo born of attempting to build finally link multiple applications in a single tree. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CONFIG_ENV_IS_EMBEDDED problems
On Saturday, January 29, 2011 07:58:37 Michael Schwingen wrote: I am wondering how CONFIG_ENV_IS_EMBEDDED is supposed to work. the embedded env stuff is kind of a mess. anyone will to waste/spend time on cleaning it up would be nice. As far as I understand the code, it is set automatically by environment.h in case the environment is in a sector in NOR flash that overlaps with the u-boot code. historically, i think that's what the code attempted to do. However, I see two problems: - CONFIG_ENV_IS_EMBEDDED does not end up in autoconf.mk - however, it is used in common/Makefile. This does not cause problems as long as CONFIG_ENV_IS_IN_FLASH is also set, but the switch in the Makefile is either useless or broken. well, the former cant really show up if the latter isnt defined - include/common.h also contains #ifdef CONFIG_ENV_IS_EMBEDDED without including environment.h, so that the definitions inside that block are never reached. common.h has historically been a dumping ground for crap. relocating that malloc-specific code to a better header would probably be a good idea. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [RFC] SF: Add sf erase offset +len command handler.
On Wednesday, February 09, 2011 16:16:12 Richard Retanubun wrote:
From hints by Wolfgang, this patch adds the ability to handle +len
argument for spi flash erase, which will round up the length to the
nearest [sector|page|block]_size.
this should be split up into two patches. one that unifies the erase sizes
and one that modifies cmd_sf.c to use the new field.
ive already mostly unified the erase functions here:
git://git.denx.de/u-boot-blackfin.git sf
but the one piece missing is what you're proposing. so i'll want to merge the
unification part you have here into that patch. if you could test out that sf
branch now to see if it works for you, that'd be nice ;).
This is done by adding a new member to
struct spi_flash::u32 block_size
The name 'block_size' is chosen to mean:
the smallest unit erase commands will check against.
let's use sector_size as this is what Linux already uses
+static int sf_parse_len_arg(char *arg, ulong *len)
constify arg
+
+
one new line only
+ if (arg *arg == '+'){
NULL check is useless as the caller already took care of it
+ if (round_up_len) {
+ /* Get sector size from flash and round up */
+ sector_size = flash-block_size;
+ if (sector_size 0) {
+ *len = len_arg -1)/sector_size) + 1) * sector_size);
we have a DIV_ROUND_UP macro already
+ if (*len flash-size) {
+ return -1;
+ }
+ } else {
+ return -1;
+ }
+ } else {
+ *len = len_arg;
+ }
pretty much all these braces can be punted
@@ -149,6 +204,7 @@ static int do_spi_flash_erase(int argc, char * const
argv[])
usage:
puts(Usage: sf erase offset len\n);
+ puts( sf erase offset +len\n);
return 1;
}
hrm, a sep patch should be written and sent out before yours that drops this
usage label and converts all goto usage to return cmd_usage(cmdtp).
--- a/drivers/mtd/spi/macronix.c
+++ b/drivers/mtd/spi/macronix.c
i'll ignore all the spi flash changes per my earlier highlight of rewrites
pending in this area.
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -38,6 +38,8 @@ struct spi_flash {
u32 size;
+ u32 block_size;
not sure what it'll do to code size, but a u16 should be large enough to hold
the base erase size.
@@ -67,5 +69,4 @@ static inline int spi_flash_erase(struct spi_flash
*flash, u32 offset, {
return flash-erase(flash, offset, len);
}
-
#endif /* _SPI_FLASH_H_ */
please avoid useless whitespace changes
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] write to mcBsp address space
Le 15/02/2011 09:21, Ran a écrit : Albert ARIBAUDalbert.aribaudat free.fr writes: Hi Ran, Le 15/02/2011 07:35, Ran Shalit a écrit : Hello, I'm working on OMAPL138 EVM board, with the U-BOOT. I'm trying to access and write into the register (which have write bits), but I always read 0 in all the map space of the mcBSP0 and mcBSP1. (0x01d1 - 0x1d10800, 0x01d11000 - 0x1d11800). I wonder what I missed here. any ideas are welcomed. Many SoCs have base address registers that allow remapping internal or peripheral registers anywhere in the address space, which means the actual address you're trying to get at might not be the right one. Did you check the BAR(s) and make sure the mcBsp address you're targetting is the right one for your board? Thank you very much, Ran Amicalement, Hello Albert, Thank you very much for your reply. I've checked the datasheet but I see no reference to base address registers for the mcBSP. mcBSP: http://www.ti.com/litv/pdf/sprugj6c OMAPL138: http://www.ti.com/lit/gpn/omap-l138 Evidently the mcBsp specs won't tell you how the device is mapped within a given SoC. As for the OMAPL138 SoC, it looks more like an overview. You would need to refer to a detailed spec, one with register level description of the module. thanks again, Ran Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] write to mcBsp address space
Albert ARIBAUD albert.aribaud at free.fr writes: Evidently the mcBsp specs won't tell you how the device is mapped within a given SoC. As for the OMAPL138 SoC, it looks more like an overview. You would need to refer to a detailed spec, one with register level description of the module. the mcBSP link above has a detailed description of the registers in the mcBSP module, but it does not refer to base address register. it is interesting to note that in the UART case I have no suce problem. The UART's and mcBSP are quite similiar. Regards, Ran ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] at91 spi bus speed
Hi, I'm experiencing some strange spi behaviour with an at91sam9g20. I changed the spi_xfer code (atmel_spi.c) to make use of the PDC that the at91sam9g20 offers. This works fine, but only up to an spi bus speed of 10 to 12 MHz. After that I see the CS going down sometimes before the transfer is complete. When the frequency is increased the issue starts appearing more often. I saw that in env_sf.c that the spi bus speed is set at 10 MHz and was wondering if there was a specific reason for that? 10 MHz is acceptible but I would like to understand what is happening, so if anybody experienced and maybe even investigated the problem, please let me know. Wouter Moors -- there's only 10 kinds of people. The ones that understand binary and the ones that don't. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] write to mcBsp address space
Le 15/02/2011 12:50, Ran a écrit : Albert ARIBAUDalbert.aribaudat free.fr writes: Evidently the mcBsp specs won't tell you how the device is mapped within a given SoC. As for the OMAPL138 SoC, it looks more like an overview. You would need to refer to a detailed spec, one with register level description of the module. the mcBSP link above has a detailed description of the registers in the mcBSP module, but it does not refer to base address register. Yes, that's what I wrote above. The base address register mapping the mcBsp at a given address would be described in the detailed spec of the SoC, the one with all registers. it is interesting to note that in the UART case I have no suce problem. The UART's and mcBSP are quite similiar. Indeed, but this does not mean they are mapped the same way. You can only tell by looking at the detailed register map of the SoC. Regards, Ran Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] itest: fix result of string compares
Hi Wolfgang, The implementation of the string compare function of the itest command was weird, as only the length of the shortest argument was included in the compare, with the result that something like itest.s abd == abddef would return TRUE. Fix this. Signed-off-by: Wolfgang Denk w...@denx.de Acked-by: Detlev Zundel d...@denx.de Cheers Detlev -- The Buddha, the Godhead, resides quite as comfortably in the circuits of a digital computer or the gears of a cycle transmission as he does at the top of a mountain or in the petals of a flower. To think otherwise is to demean the Buddha - which is to demean oneself. -- Robert M. Pirsig -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request - microblaze
Dear Wolfgang, please pull the following two bug fixes for Microblaze. Thanks, Michal The following changes since commit c65715de780945950d570e2b69f94e0b186f04b4: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-mips are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git master Michal Simek (2): microblaze: Fix systems with MSR=0 microblaze: Fix msr handling in interrupt_handler arch/microblaze/cpu/irq.S | 19 +-- arch/microblaze/include/asm/asm.h |2 +- 2 files changed, 2 insertions(+), 19 deletions(-) -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] write to mcBsp address space
On Tuesday, February 15, 2011 12:05 PM, Ran Shalit wrote: Hello, I'm working on OMAPL138 EVM board, with the U-BOOT. I'm trying to access and write into the register (which have write bits), but I always read 0 in all the map space of the mcBSP0 and mcBSP1. (0x01d1 - 0x1d10800, 0x01d11000 - 0x1d11800). I wonder what I missed here. any ideas are welcomed. Thank you very much, Ran Only the modules which are necessary are enabled in U-Boot. Most likely McBSP is not one of those. You can check how other modules are enabled for da8xx and modify the code appropriately for experimentation. If you have further queries on the McBSP in specific please post them on the TI E2E community http://e2e.ti.com in the appropriate forum. Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] need your help
hello ,everyone, Please help.I have a custom board with a mpc8641d processer, I compiled the u-boot using the configuration of sbc8641d board , then I flashed the u-boot.bin into flash, everything seems to be fine so far. Then I compiled the kernel image and dts file with the configuration of sbc8641d board, and download the kernel image and dtb file to the ram. However, when I start the kernel, it died when uncompressing the kernel image. The output from serial port is as follows: U-Boot 2010.12-rc1 (Jan 30 2011 - 09:32:35) CPU: 8641D, Version: 2.1, (0x80900121) Core: E600 Core 0, Version: 2.2, (0x80040202) Clock Configuration: CPU:1200 MHz, MPX:400 MHz DDR:200 MHz (400 MT/s data rate), LBC:25 MHz L1:D-cache 32 KB enabled I-cache 32 KB enabled L2:512 KB enabled Board: Wind River SBC8641D I2C: ready DRAM: DDR: 512 MiB FLASH: ERROR: too many flash sectors 32 MiB *** Warning - bad CRC, using default environment PCIE1: disabled PCIE2 connected as Root Complex (base addr f8009000) PCIE2 on bus 00 - 00 In:serial Out: serial Err: serial Net: eTSEC2: No support for PHY id ; assuming generic eTSEC3: No support for PHY id ; assuming generic eTSEC4: No support for PHY id ; assuming generic eTSEC1, eTSEC2, eTSEC3, eTSEC4 Hit any key to stop autoboot: 0 = run nfsboot Speed: 100, full duplex Using eTSEC1 device TFTP from server 192.168.0.2; our IP address is 192.168.0.50 Filename 'uImage'. Load address: 0x100 Loading: # # # # # # ### done Bytes transferred = 2109796 (203164 hex) Speed: 100, full duplex Using eTSEC1 device TFTP from server 192.168.0.2; our IP address is 192.168.0.50 Filename 'sbc8641d.dtb'. Load address: 0x40 Loading: ## done Bytes transferred = 7633 (1dd1 hex) ## Booting kernel from Legacy Image at 0100 ... Image Name: Linux-2.6.35 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:2109732 Bytes = 2 MiB Load Address: Entry Point: Verifying Checksum ... OK ## Flattened Device Tree blob at 0040 Booting using the fdt blob at 0x40 Uncompressing Kernel Image ... Machine check in kernel mode. Caused by (from msr): regs 1fea4818 MSS error. MSSSR0: 1000 NIP: 1FECB744 XER: LR: 1FECB56C REGS: 1fea4818 TRAP: 0200 DAR: MSR: 00101030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11 GPR00: 0016 1FEA4908 1FEA4F48 01000203 01B4 009E GPR08: 3A00 00C1 0003 01FF F7FF 1FEF695C GPR16: 01FF 003F 1FEA73A8 1FEA7D78 GPR24: 007FFEFE 0120315E 1FEA49E0 1FEA6E78 0DBF 1FEFEB0C 000D Call backtrace: 001A001A 1FECD4D0 1FEE9E98 1FEE9FC4 1FED9600 1FED99E4 1FEE5AB0 1FEE51C4 1FEE5410 1FEE59EC 1FEE51C4 1FEE53E4 1FEE6AF0 1FEE5AB0 1FEE51C4 1FEE5334 1FEE6F80 1FED0CC8 1FEC957C Machine check in kernel mode. Caused by (from msr): regs 1fea4568 MSS error. MSSSR0: 1000 NIP: 1FEE1A58 XER: 2000 LR: 1FEC98AC REGS: 1fea4568 TRAP: 0200 DAR: MSR: 00101030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11 GPR00: 0001 1FEA4658 1FEA4F48 1FEF446C 0001 0004 GPR08: 8000 0030 42044024 F7FF 1FEF695C GPR16: 01FF 003F 1032 1FEA4808 1FEC92C0 GPR24: 1FEC9A20 0120315E 1FEF446C 1FEEE430 1FEA466C 1FEFEA24 7BE7FF6F Call backtrace: 1FEE1AA8 1FEC98AC 1FEC9B10 1FEC92C0 001A001A 1FECD4D0 1FEE9E98 1FEE9FC4 1FED9600 1FED99E4 1FEE5AB0 1FEE51C4 1FEE5410 1FEE59EC 1FEE51C4 1FEE53E4 1FEE6AF0 1FEE5AB0 1FEE51C4 1FEE5334 1FEE6F80 1FED0CC8 1FEC957C machine check and the enviroment variables are shown as below: = printenv baudrate=115200 bootcmd=setenv bootargs root=/dev/ram rw ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostna0 bootdelay=10 bootfile=uImage consoledev=ttyS0 dis-wd=mw.b f8100010 0x00; echo -expect:- 00; md.b f8100010 1 dtbaddr=40 dtbfile=sbc8641d.dtb en-wd=mw.b f8100010 0x08; echo -expect:- 08; md.b f8100010 1 eth1addr=02:E0:0C:00:01:FD eth2addr=02:E0:0C:00:02:FD eth3addr=02:E0:0C:00:03:FD ethact=eTSEC1 ethaddr=02:E0:0C:00:00:01 gatewayip=192.168.0.1 hostname=sbc8641d ipaddr=192.168.0.50 loadaddr=100 loads_echo=1 maxcpus=1 netdev=eth0 netmask=255.255.255.0 nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serveripr ramboot=setenv bootargs root=/dev/ram rw ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostnar ramdiskaddr=200 ramdiskfile=uRamdisk
Re: [U-Boot] need your help
Dear nice, In message 44e92e.98dc.12e2a003bb1.coremail.hua...@163.com you wrote: Please help.I have a custom board with a mpc8641d processer, I compiled the u-boot using the configuration of sbc8641d board , You cannot use one configuration for a completely different bord - not even when you think they are pretty similar. This does not work. then I flashed the u-boot.bin into flash, everything seems to be fine so far. Then I compiled the kernel image and dts file with Everything seems to be fine, but only because you close both your eyes and ignore all the errors. U-Boot 2010.12-rc1 (Jan 30 2011 - 09:32:35) This is old code. Why don't you use current one. CPU: 8641D, Version: 2.1, (0x80900121) Core: E600 Core 0, Version: 2.2, (0x80040202) Clock Configuration: CPU:1200 MHz, MPX:400 MHz DDR:200 MHz (400 MT/s data rate), LBC:25 MHz L1:D-cache 32 KB enabled I-cache 32 KB enabled L2:512 KB enabled Board: Wind River SBC8641D I2C: ready DRAM: DDR: 512 MiB FLASH: ERROR: too many flash sectors Here is a clear error message. Why do you say everything seems to be fine ? Net: eTSEC2: No support for PHY id ; assuming generic eTSEC3: No support for PHY id ; assuming generic eTSEC4: No support for PHY id ; assuming generic Here are more errors. ## Flattened Device Tree blob at 0040 This is a pretty low address. Eventyally the device tree blob gets overwritten during uncompression. Call backtrace: 001A001A 1FECD4D0 1FEE9E98 1FEE9FC4 1FED9600 1FED99E4 1FEE5AB0 1FEE51C4 1FEE5410 1FEE59EC 1FEE51C4 1FEE53E4 1FEE6AF0 1FEE5AB0 1FEE51C4 1FEE5334 1FEE6F80 1FED0CC8 1FEC957C Machine check in kernel mode. Did you attempt to decode the backtrace? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de This isn't brain surgery; it's just television. - David Letterman ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] updates for DFU and atmel usba udc
Hi,
2011/2/13 Marcel Janssen korg...@home.nl:
From: Marcel korg...@home.nl
Signed-off-by: Marcel korg...@home.nl
---
arch/arm/cpu/arm926ejs/at91/led.c | 119 +-
Why is this part if this patch?
It does not seem to be related to USB stuff. Please make it a seperate patch.
common/Makefile | 1 +
common/update_dfu.c | 2 -
drivers/usb/gadget/atmel_usba_udc.c | 8 +-
drivers/usb/gadget/usbdfu.c | 14 +++--
5 files changed, 128 insertions(+), 16 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/at91/led.c
b/arch/arm/cpu/arm926ejs/at91/led.c
index 0a315c4..0638a2e 100644
--- a/arch/arm/cpu/arm926ejs/at91/led.c
+++ b/arch/arm/cpu/arm926ejs/at91/led.c
@@ -28,38 +28,149 @@
#include asm/arch/gpio.h
#include asm/arch/io.h
+static unsigned int saved_state[4] = {STATUS_LED_OFF, STATUS_LED_OFF,
+ STATUS_LED_OFF, STATUS_LED_OFF};
+
+void coloured_LED_init(void)
+{
+ /* Enable clock */
+ at91_sys_write(AT91_PMC_PCER, 1 AT91SAM9G45_ID_PIODE);
at91_sys_write is deprecated, please use register access by struct
Why is modification of the generic at91 led code required? It is not clear.
Please, only make a patch series with only USB-DFU stuff in it, drop
the add-board code from this series. The board code is not acceptable
for mainstream since it does not follow the new
u-boot-atmel-rework110202 tree style of adding at91 boards. It will
take you a huge amount of effort to make it suitable.
Further, both parts of the patch series are not related and you are
now creating a link between the Atmel tree and the USB tree, which
makes it even more difficult.
Kind regards,
Remy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] Add In-Circuit sam9g45_oem board
Hi,
2011/2/13 Marcel Janssen korg...@home.nl:
From: Marcel korg...@home.nl
sam9g45_oem cleanup phase1
sam9g45_oem cleanup phase2
sam9g45_oem cleanup phase3
Not a very descriptive patch header...
Please fix.
Signed-off-by: Marcel korg...@home.nl
---
board/in-circuit/icnova/Makefile | 50 ++
board/in-circuit/icnova/icnova_sam9g45.c | 242
boards.cfg | 1 +
include/configs/icnova_sam9g45.h | 253
++
4 files changed, 546 insertions(+), 0 deletions(-)
create mode 100644 board/in-circuit/icnova/Makefile
create mode 100644 board/in-circuit/icnova/icnova_sam9g45.c
create mode 100644 include/configs/icnova_sam9g45.h
diff --git a/board/in-circuit/icnova/Makefile
b/board/in-circuit/icnova/Makefile
new file mode 100644
index 000..bf64680
--- /dev/null
+++ b/board/in-circuit/icnova/Makefile
@@ -0,0 +1,50 @@
+# (C) Copyright 2011 Marcel Janssen, Admesy B.V.
+# (C) Copyright 2001-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# Copyright (C) 2005-2006 Atmel Corporation
+#
+# (C) 2008 - 2010 Benjamin Tietz, In-Circuit benjamin.ti...@in-circuit.de
+# (C) 2011 Marcel Janssen, Admesy B.V.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+
+include $(TOPDIR)/config.mk
+include $(TOPDIR)/include/config.mk
+
+LIB := $(obj)lib$(BOARD).o
+
+COBJS := icnova_sam9g45.o
+
+COBJS-y += $(COBJS)
+SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS-y))
+
+# $(obj).depend
+$(LIB): $(OBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS)
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/in-circuit/icnova/icnova_sam9g45.c
b/board/in-circuit/icnova/icnova_sam9g45.c
new file mode 100644
index 000..8407b0b
--- /dev/null
+++ b/board/in-circuit/icnova/icnova_sam9g45.c
@@ -0,0 +1,242 @@
+/*
+ * (C) 2010 Benjamin Tietz, In-Circuit benjamin.ti...@in-circuit.de
+ *
+ * (C) Copyright 2007-2008
+ * Stelian Pop stelian@leadtechdesign.com
+ * Lead Tech Design www.leadtechdesign.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include exports.h
+#include asm/sizes.h
+#include asm/arch/at91sam9g45.h
+#include asm/arch/at91sam9_matrix.h
+#include asm/arch/at91sam9_smc.h
+#include asm/arch/at91_common.h
+#include asm/arch/at91_pmc.h
+#include asm/arch/at91_rstc.h
+#include asm/arch/clk.h
+#include asm/arch/gpio.h
+#include asm/arch/io.h
+#include asm/arch/hardware.h
+#include usb/atmel_usba_udc.h
+#ifdef CONFIG_USBD_DFU
+#include usb_dfu.h
+#endif
+
+#if defined(CONFIG_RESET_PHY_R) defined(CONFIG_MACB)
+#include net.h
+#endif
+#include netdev.h
+
+#if defined(CONFIG_USB_GADGET_ATMEL_USBA) !defined(CONFIG_USB_GADGET)
+#error Need CONFIG_USB_GADGET when CONFIG_USB_GADGET_ATMEL_USBA enabled
+#endif
+
+
+DECLARE_GLOBAL_DATA_PTR;
+char bootbuf[20];
+
+#ifdef CONFIG_USB_GADGET_ATMEL_USBA
+struct platform_data brd = {
+ .board = {
+ .vbus_pin = AT91_PIN_PC0,
+ .pullup_pin = 1,
+ },
+ .udc_clk = AT91SAM9G45_ID_UDPHS,
+};
+#endif
+
+#ifdef CONFIG_CMD_NAND
Re: [U-Boot] IXP42x patch series version 3
Am 02/14/2011 01:00 PM, schrieb Albert ARIBAUD: Le 14/02/2011 00:38, Michael Schwingen a écrit : Am 02/13/2011 11:03 PM, schrieb Wolfgang Denk: Dear Graeme Russ, In messageAANLkTikxv+ATsYAP5ismLo5pj=TrFV_oQNk=8qvh1...@mail.gmail.com you wrote: For multi-patch series, you only need to put the revision history in the [00/nn] file - No need to individually annotate each and every patch This is *wrong*. See the Note at bullet 2 at http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions (I plead guilty, then. I, too, did put patchset history only in the summary post, and never commented others who did it too) Do you have any advise *how* to do that using git? Any pointer is fine, I can RTFM if I know where to start. Git itself won't give you a way to do this. What I do is: - when I create a V2 patchset I edit the patch messages manually to add history (in the summary so far, I'll fix this for future patchsets) and keep the patch messages around; - when I create a V3-or-later patchset, I copy-paste the history from the previous set then add the new history entry. Being a creature of habit, I am used to launching two instances of nedit with the V(n-1) and V(n) patch sets for this. So in my case, I would need 2*17 editor instances (or more likely 17 sessions with 2 editor instances each), for each patch version. That add quite a lot of work just to prepare otherwise working patches for patchwork. I will see when I find time to re-do the patch series that way, however, I need to say that maintaining patches out-of-tree seems less work than getting the patches into mainline using this procedure. cu Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] Add In-Circuit sam9g45_oem board
On Tuesday, February 15, 2011 07:45:36 pm Remy Bohmer wrote: Hi, 2011/2/13 Marcel Janssen korg...@home.nl: From: Marcel korg...@home.nl sam9g45_oem cleanup phase1 sam9g45_oem cleanup phase2 sam9g45_oem cleanup phase3 Not a very descriptive patch header... Please fix. Basically cleaning a lot of whitespaces only and some other things checkpatch complained about. Since it where so many, I needed a few times to clean all. Anyway, When I post new patches I hope to be able to skip the cleaning of whitespaces. regards, Marcel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] updates for DFU and atmel usba udc
On Tuesday, February 15, 2011 07:43:34 pm Remy Bohmer wrote:
Hi,
2011/2/13 Marcel Janssen korg...@home.nl:
From: Marcel korg...@home.nl
Signed-off-by: Marcel korg...@home.nl
---
arch/arm/cpu/arm926ejs/at91/led.c | 119
+-
Why is this part if this patch?
It does not seem to be related to USB stuff. Please make it a seperate
patch.
I optionally use the LED's in DFU mode so that there's interaction while
upgrading the board. You might believe the host could handle this, but I like
the device to indicate activity as well.
Somehow I couldn't get it working without changing led.c I think, but I may
have missed something.
common/Makefile |1 +
common/update_dfu.c |2 -
drivers/usb/gadget/atmel_usba_udc.c |8 +-
drivers/usb/gadget/usbdfu.c | 14 +++--
5 files changed, 128 insertions(+), 16 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/at91/led.c
b/arch/arm/cpu/arm926ejs/at91/led.c index 0a315c4..0638a2e 100644
--- a/arch/arm/cpu/arm926ejs/at91/led.c
+++ b/arch/arm/cpu/arm926ejs/at91/led.c
@@ -28,38 +28,149 @@
#include asm/arch/gpio.h
#include asm/arch/io.h
+static unsigned int saved_state[4] = {STATUS_LED_OFF, STATUS_LED_OFF,
+ STATUS_LED_OFF, STATUS_LED_OFF};
+
+void coloured_LED_init(void)
+{
+ /* Enable clock */
+ at91_sys_write(AT91_PMC_PCER, 1 AT91SAM9G45_ID_PIODE);
at91_sys_write is deprecated, please use register access by struct
Already noticed that.
Why is modification of the generic at91 led code required? It is not clear.
Please, only make a patch series with only USB-DFU stuff in it, drop
the add-board code from this series. The board code is not acceptable
for mainstream since it does not follow the new
u-boot-atmel-rework110202 tree style of adding at91 boards. It will
take you a huge amount of effort to make it suitable.
Further, both parts of the patch series are not related and you are
now creating a link between the Atmel tree and the USB tree, which
makes it even more difficult.
I'm actually busy fixing the board code for u-boot-atmel-rework110202
Most of it is working so I hope I can create the patches as you like them.
best regards,
Marcel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] USB DFU driver added
Hi, 2011/2/13 Marcel Janssen korg...@home.nl: From: Marcel korg...@home.nl USB DFU driver cleaning phase1 USB DFU driver cleaning phase2 USB DFU driver cleaning phase3 USB DFU driver cleaning phase4 Not a very descriptive patch header. Please fix this. Signed-off-by: Marcel korg...@home.nl --- common/update_dfu.c | 89 +++ doc/README.dfu | 129 drivers/usb/gadget/Makefile | 9 + drivers/usb/gadget/usbdfu.c | 1336 + include/usb_dfu.h | 128 include/usb_dfu_descriptors.h | 100 +++ 6 files changed, 1791 insertions(+), 0 deletions(-) create mode 100644 common/update_dfu.c create mode 100644 doc/README.dfu create mode 100644 drivers/usb/gadget/usbdfu.c create mode 100644 include/usb_dfu.h create mode 100644 include/usb_dfu_descriptors.h diff --git a/doc/README.dfu b/doc/README.dfu new file mode 100644 index 000..363c7a2 --- /dev/null +++ b/doc/README.dfu @@ -0,0 +1,129 @@ +USBD DFU mode + +Initially written by Marcel Janssen, Admesy B.V. +Based on parts from OpenMoko, ether.c and update.c + + No useless double empty lines (globally) + + +This describes the DFU implementation in u-boot. + +The implementation works with dfu-utils to upgrade NAND partitions defined by +mtdparts. +The board configuration file needs serveral CONFIG options to be set. +DFU is implemented to be executed as a command dfu (common/update_dfu.c). +This command should start the USB device controller and the DFU driver. +A typical implementation would be that a script is executed, that will check +whether DFU should be started. If so, it can execute 'dfu and the device will +announce itself to the host as a DFU capable device. +dfu-util can than be used to upgrade the partitions defined by mtdparts. + +Description of flow : +dfu-utils sets the alternate interface which corresponds to the selected +partition. +The file (uImage, rootfs.arm.jffs2) is loaded fully to RAM first. +U-boot nand routines are used to write from RAM to NAND. + +LED usage : +Status LED's can be defined to show DFU action. +Define the RED and GREEN leds to make this happen. LEDs are board specific, please do not use that in generic driver code. + +Initial testing example : +This was done on the in-circuit icnova_sam9g45 board. +This board uses atmel_usbd_udc.c + + + + + useles empty lines +To make DFU work you need a working USB controller, for example at91_udc or +atmel_usba_udc. Make sure to set it in the board config file. + + +USBD CONFIG options + + +#define CONFIG_USB_GADGET +#define CONFIG_USB_GADGET_ATMEL_USBA (or #define CONFIG_USB_GADGET_AT91_UDC ) +#define CONFIG_USB_GADGET_DUALSPEED + + +USBD CONFIG options end + + + empty lines + +DFU CONFIG options + + +#define CONFIG_USBD_DFU 1 +#ifdef CONFIG_USBD_DFU +#define CONFIG_USBD_VENDORID 0x23CF /* Admesy */ +#define CONFIG_USBD_PRODUCTID_DFU 0x0100 /* donated number */ +#define CONFIG_USBD_MANUFACTURER Admesy +#define CONFIG_USBD_PRODUCT_NAME Admesy DFU 001 +#define CONFIG_USBD_DFU_XFER_SIZE 4096 /* Buffer size */ +#define CONFIG_USBD_DFU_INTERFACE 0 +#define DFU_NUM_ALTERNATES 3 /* 3 partitions */ +#define LOAD_ADDR ((unsigned char *)0x7040) /* RAM address to use */ +#endif + + +DFU CONFIG options end + + + + empty lines +In order to make DFU work with dfu-utils, mtdparts need to be defined. +See the example futher below on how to do this. + + +mtdparts example with dfu-utils + + +mtdparts add nand0 0x200 kernel +mtdparts add nand0 0x100@0x0020 root +mtdparts add nand0 0xEE0@0x0120 data +saveenv + +Your mtdparts than should look like this : + +board mtdparts +device nand0 nand.0, # parts = 3 + #: name size offset mask_flags + 0: kernel 0x0020 0x 0 + 1: root 0x0100 0x0020 0 + 2: data 0x0ee0 0x0120 0 + +active partition: nand0,0 - (kernel) 0x0020 @ 0x + + +After the mtdparts have been defined, dfu-utils can be used to upgrade the +kernel and root partition. +Make sure you have read/write access to the DFU device ! + +cd dfu-utils/src +./dfu-util -a0 -D uImage +./dfu-util -a1 -D rootfs.arm.jffs2 -R +
Re: [U-Boot] [PATCH v2 4/4] updates for DFU and atmel usba udc
Hi, 2011/2/15 Marcel Janssen korg...@home.nl: On Tuesday, February 15, 2011 07:43:34 pm Remy Bohmer wrote: Hi, 2011/2/13 Marcel Janssen korg...@home.nl: From: Marcel korg...@home.nl Signed-off-by: Marcel korg...@home.nl --- arch/arm/cpu/arm926ejs/at91/led.c | 119 +- Why is this part if this patch? It does not seem to be related to USB stuff. Please make it a seperate patch. I optionally use the LED's in DFU mode so that there's interaction while upgrading the board. U-boot has a terminal/monitor. It is not up to the driver to control LEDs that might or might not be on a board. You might believe the host could handle this, but I like the device to indicate activity as well. Somehow I couldn't get it working without changing led.c I think, but I may have missed something. The problem is here that you mix up sub-systems. Modifying LED code should be independent from USB driver code, and really not in the same patch. common/Makefile | 1 + common/update_dfu.c | 2 - drivers/usb/gadget/usbdfu.c | 14 +++-- These files should be completely generic code, that even would work on X86, PowerPC and so on. drivers/usb/gadget/atmel_usba_udc.c |8 +- Only this driver file should be Atmel USBA specific, but NOT SoC specific, and absolutely not board or board config related. Please, only make a patch series with only USB-DFU stuff in it, drop the add-board code from this series. The board code is not acceptable for mainstream since it does not follow the new u-boot-atmel-rework110202 tree style of adding at91 boards. It will take you a huge amount of effort to make it suitable. Further, both parts of the patch series are not related and you are now creating a link between the Atmel tree and the USB tree, which makes it even more difficult. I'm actually busy fixing the board code for u-boot-atmel-rework110202 Most of it is working so I hope I can create the patches as you like them. Hmm, Let's make it even more black/white: I do not have to like the board code. ;-) Reinhard is the Atmel maintainer. He needs to pull in the Board code. I only care about generic USB code... ;-))) Please make 2 unrelated patch series (1 series for USB DFU support, 1 series for board support), or it will never hit mainline... AND: I would really recommend to build a decent USB/DFU patch series first. Forget the board for now. The board seems to depend on DFU support, not the other way around. If generic DFU code is really generic and acceptable, I will pull it in my tree. I am willing to fix small issues in the series to assist you, but I will not do major redesigns... Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] Add Atmel USBA UDC
Hi, Continuing producing some remarks: 2011/2/13 Marcel Janssen korg...@home.nl: From: Marcel korg...@home.nl Atmel USBA UDC cleanup Atmel USBA UDC cleanup more cleanup of Atmel USBA UDC Some more cleaning of Atmel USBA UDC further cleaning of Atmel USBA UDC Strange header. Signed-off-by: Marcel korg...@home.nl --- drivers/usb/gadget/Makefile | 1 + drivers/usb/gadget/atmel_usba_udc.c | 1438 +++ include/usb/atmel_usba_udc.h | 398 ++ 3 files changed, 1837 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/gadget/atmel_usba_udc.c create mode 100644 include/usb/atmel_usba_udc.h diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile index 0846233..024844d 100644 --- a/drivers/usb/gadget/Makefile +++ b/drivers/usb/gadget/Makefile @@ -29,6 +29,7 @@ LIB := $(obj)libusb_gadget.o ifdef CONFIG_USB_ETHER COBJS-y += ether.o epautoconf.o config.o usbstring.o COBJS-$(CONFIG_USB_GADGET_AT91) += at91_udc.o +COBJS-$(CONFIG_USB_GADGET_ATMEL_USBA) += atmel_usba_udc.o else # Devices not related to the new gadget layer depend on CONFIG_USB_DEVICE ifdef CONFIG_USB_DEVICE diff --git a/drivers/usb/gadget/atmel_usba_udc.c b/drivers/usb/gadget/atmel_usba_udc.c new file mode 100644 index 000..6d02de6 --- /dev/null +++ b/drivers/usb/gadget/atmel_usba_udc.c @@ -0,0 +1,1438 @@ +/* + * Driver for the Atmel USBA high speed USB device controller + * + * Copyright (C) 2011 Marcel Janssen, Admesy B.V. + * Copyright (C) 2005-2007 Atmel Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ Is this GPLv2 only from its origin? I thought only GPLv2+ code was acceptable. See http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sign + if (!(ptr-in_use)) + debug(%s: ptr not marked as \in_use\\n, __func__); + + hang(); Is hang required? Is there no recovery to the terminal possible? + if (!ptr) + DBG(panic: no more free req buffers\n); Cool. A panic in a debug printf that is removed by the preprocessor. Is it really panic? + udc-regs = (unsigned *) AT91SAM9G45_BASE_UDPHS; + udc-fifo = (unsigned *) AT91SAM9G45_UDPHS_FIFO; Is at91sam9g45 the only SoC that has this UDP-USBA controller? Make it a generic define. Globally. Please fix the double empty lines globally as well. This patch looks relatively clean compared to the reset of the series. Please rework comments. Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] at91 spi bus speed
On Tuesday, February 15, 2011 06:56:42 wouter moors wrote: I saw that in env_sf.c that the spi bus speed is set at 10 MHz and was wondering if there was a specific reason for that? you mean it defaults to 10 MHz. boards can freely pick anything they want. some speed needed to be arbitrarily picked, and 10 MHz should work with every spi flash out there. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] updates for DFU and atmel usba udc
Hi Remy, 2011/2/15 Marcel Janssen korg...@home.nl: On Tuesday, February 15, 2011 07:43:34 pm Remy Bohmer wrote: Hi, 2011/2/13 Marcel Janssen korg...@home.nl: From: Marcel korg...@home.nl Signed-off-by: Marcel korg...@home.nl --- arch/arm/cpu/arm926ejs/at91/led.c | 119 +- Why is this part if this patch? It does not seem to be related to USB stuff. Please make it a seperate patch. I optionally use the LED's in DFU mode so that there's interaction while upgrading the board. U-boot has a terminal/monitor. It is not up to the driver to control LEDs that might or might not be on a board. OK, good to know. I'll check that out, but not today. For now I can remove the LED code I think. Than in a couple of months I can can check how to use the monitor code. You might believe the host could handle this, but I like the device to indicate activity as well. Somehow I couldn't get it working without changing led.c I think, but I may have missed something. The problem is here that you mix up sub-systems. Modifying LED code should be independent from USB driver code, and really not in the same patch. common/Makefile |1 + common/update_dfu.c |2 - drivers/usb/gadget/usbdfu.c | 14 +++-- These files should be completely generic code, that even would work on X86, PowerPC and so on. Agree on that. It would be optiomal. Not everything is, the first time :-) drivers/usb/gadget/atmel_usba_udc.c |8 +- Only this driver file should be Atmel USBA specific, but NOT SoC specific, and absolutely not board or board config related. ok. Please, only make a patch series with only USB-DFU stuff in it, drop the add-board code from this series. The board code is not acceptable for mainstream since it does not follow the new u-boot-atmel-rework110202 tree style of adding at91 boards. It will take you a huge amount of effort to make it suitable. Further, both parts of the patch series are not related and you are now creating a link between the Atmel tree and the USB tree, which makes it even more difficult. I'm actually busy fixing the board code for u-boot-atmel-rework110202 Most of it is working so I hope I can create the patches as you like them. Hmm, Let's make it even more black/white: I do not have to like the board code. ;-) Reinhard is the Atmel maintainer. He needs to pull in the Board code. I only care about generic USB code... ;-))) hmmm. The black and white this is that after today I don't have a single hour to spend on this code :-) Please make 2 unrelated patch series (1 series for USB DFU support, 1 series for board support), or it will never hit mainline... AND: I would really recommend to build a decent USB/DFU patch series first. Forget the board for now. The board seems to depend on DFU support, not the other way around. If generic DFU code is really generic and acceptable, I will pull it in my tree. I am willing to fix small issues in the series to assist you, but I will not do major redesigns... Well, the board does not depend on DFU. Not even the USBD controller is activated in the board config. It is left up to a script to handle that though update_dfu.c which defines a command for that. I may have left some parts in that don't really belong there, I haven't check it yet. Best regards, Marcel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] Add Atmel USBA UDC
Hi Remy, Continuing producing some remarks: 2011/2/13 Marcel Janssen korg...@home.nl: From: Marcel korg...@home.nl Atmel USBA UDC cleanup Atmel USBA UDC cleanup more cleanup of Atmel USBA UDC Some more cleaning of Atmel USBA UDC further cleaning of Atmel USBA UDC Strange header. Signed-off-by: Marcel korg...@home.nl --- drivers/usb/gadget/Makefile |1 + drivers/usb/gadget/atmel_usba_udc.c | 1438 +++ include/usb/atmel_usba_udc.h | 398 ++ 3 files changed, 1837 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/gadget/atmel_usba_udc.c create mode 100644 include/usb/atmel_usba_udc.h diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile index 0846233..024844d 100644 --- a/drivers/usb/gadget/Makefile +++ b/drivers/usb/gadget/Makefile @@ -29,6 +29,7 @@ LIB := $(obj)libusb_gadget.o ifdef CONFIG_USB_ETHER COBJS-y += ether.o epautoconf.o config.o usbstring.o COBJS-$(CONFIG_USB_GADGET_AT91) += at91_udc.o +COBJS-$(CONFIG_USB_GADGET_ATMEL_USBA) += atmel_usba_udc.o else # Devices not related to the new gadget layer depend on CONFIG_USB_DEVICE ifdef CONFIG_USB_DEVICE diff --git a/drivers/usb/gadget/atmel_usba_udc.c b/drivers/usb/gadget/atmel_usba_udc.c new file mode 100644 index 000..6d02de6 --- /dev/null +++ b/drivers/usb/gadget/atmel_usba_udc.c @@ -0,0 +1,1438 @@ +/* + * Driver for the Atmel USBA high speed USB device controller + * + * Copyright (C) 2011 Marcel Janssen, Admesy B.V. + * Copyright (C) 2005-2007 Atmel Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ Is this GPLv2 only from its origin? I thought only GPLv2+ code was acceptable. See http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Si gn Wow, there's something I completely missed. I would need to check on that. The original code comes from kernel 2.6.33 and I didn't change that part. + if (!(ptr-in_use)) + debug(%s: ptr not marked as \in_use\\n, __func__); + + hang(); Is hang required? Is there no recovery to the terminal possible? I guess not. + if (!ptr) + DBG(panic: no more free req buffers\n); Cool. A panic in a debug printf that is removed by the preprocessor. Is it really panic? Actually I think this should never be hit unless someone calls it wrong. + udc-regs = (unsigned *) AT91SAM9G45_BASE_UDPHS; + udc-fifo = (unsigned *) AT91SAM9G45_UDPHS_FIFO; Is at91sam9g45 the only SoC that has this UDP-USBA controller? Make it a generic define. Globally. So far I haven't seen others than the at91sam9g45 and at91sam9g45m10 Please fix the double empty lines globally as well. This patch looks relatively clean compared to the reset of the series. Please rework comments. I see what I can do. Best regards, Marcel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request - microblaze
Dear Michal Simek, In message 4d5a8b38.5030...@monstr.eu you wrote: Dear Wolfgang, please pull the following two bug fixes for Microblaze. Thanks, Michal The following changes since commit c65715de780945950d570e2b69f94e0b186f04b4: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-mips are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git master Michal Simek (2): microblaze: Fix systems with MSR=0 microblaze: Fix msr handling in interrupt_handler arch/microblaze/cpu/irq.S | 19 +-- arch/microblaze/include/asm/asm.h |2 +- 2 files changed, 2 insertions(+), 19 deletions(-) Which branch should I pull from? I guess you mean u-boot-microblaze.git #master ? Pulled - hope that was OK. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de This restaurant was advertising breakfast any time. So I ordered french toast in the renaissance.- Steven Wright, comedian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] itest: fix result of string compares
Dear Wolfgang Denk, In message 1297180565-23763-1-git-send-email...@denx.de you wrote: The implementation of the string compare function of the itest command was weird, as only the length of the shortest argument was included in the compare, with the result that something like itest.s abd == abddef would return TRUE. Fix this. Signed-off-by: Wolfgang Denk w...@denx.de --- common/cmd_itest.c |7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) Applied. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Experience is what causes a person to make new mistakes instead of old ones. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] unzip: return uncompressed size in `filesize', and print it.
Dear Wolfgang Denk, In message 1297452051-18532-1-git-send-email...@denx.de you wrote: The unzip command did not provide a way for the caller to get any information about the uncompressed size. To make it better usable in scripts, we now store the uncompressed size in the `filesize' variable, like we do when for example loading a file over the network or when reading it from a file system. Following that analogy, it is only consequent to also print the size. Signed-off-by: Wolfgang Denk w...@denx.de --- v2: return early in case of errors, set 'filesize' only on success. This also avoids the new 'rc' variable. Courtesy to Peter Tyser for pointing out. common/cmd_mem.c | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Real computer scientists despise the idea of actual hardware. Hard- ware has limitations, software doesn't. It's a real shame that Turing machines are so poor at I/O. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] add icnova sam9g45 board
On Tuesday, February 15, 2011 01:00:50 am Reinhard Meyer wrote: Dear Marcel Janssen, Hi Remy and Reinhard, To make it easy for you: It is up to you if you choose ' rework_110202' ... It looks like if at91sam9g45.h has not been updated. Is that right ? If so, should all be changed to ATMEL_ID and ATMEL_BASE ? That is correct. Only 9260/1/3 are reworked so far. If someone would rework the 9g45 in the spirit of the 9260 it would be great. Please as a separate patch. Same goes for the other SoCs ;) I did most of that. I just hit this : drivers/mtd/cfi_flash.c:576: undefined reference to `reset_timer' Any idea how to fix it ? regards, Marcel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] add icnova sam9g45 board
Dear Marcel Janssen,
On Tuesday, February 15, 2011 01:00:50 am Reinhard Meyer wrote:
If someone would rework the 9g45 in the spirit of the 9260 it would be
great. Please as a separate patch. Same goes for the other SoCs ;)
I did most of that. I just hit this :
drivers/mtd/cfi_flash.c:576: undefined reference to `reset_timer'
Any idea how to fix it ?
Basically the same way I fixed nand_base.c a while ago:
void nand_wait_ready(struct mtd_info *mtd)
{
struct nand_chip *chip = mtd-priv;
u32 timeo = (CONFIG_SYS_HZ * 20) / 1000;
u32 time_start;
time_start = get_timer(0);
/* wait until command is processed or timeout occures */
while (get_timer(time_start) timeo) {
if (chip-dev_ready)
if (chip-dev_ready(mtd))
break;
}
}
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: ne2000: Add spport RTL-8019AS
Dear Nobuhiro Iwamatsu, In message 1288092720-7421-1-git-send-email-iwama...@nigauri.org you wrote: Add infomation of RTL-8016AS to hw_info. Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org CC: Ben Warren biggerbadder...@gmail.com --- drivers/net/ne2000.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Landru! Guide us! -- A Beta 3-oid, The Return of the Archons, stardate 3157.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] add checking the CONFIG_ENV_IS_IN_SPI_FLASH in Enbedded env
Dear Yoshihiro Shimoda, In message 4d3e1923.3060...@renesas.com you wrote: Fix the problem which cannot build the U-boot, if we only set the CONFIG_ENV_IS_IN_SPI_FLASH. Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com --- about V2: - list sorted include/environment.h |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It's not an optical illusion, it just looks like one. -- Phil White ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc: clean up DIU macro definitions for the MPC8610HPCD and MPC5121ADS
Clean up the macro defintions used to enable DIU (video) support on the MPC8610HPCD and the MPC5121ADS so that they look more like the P1022DS, which is newer. Signed-off-by: Timur Tabi ti...@freescale.com --- include/configs/MPC8610HPCD.h | 12 include/configs/mpc5121ads.h |8 2 files changed, 8 insertions(+), 12 deletions(-) diff --git a/include/configs/MPC8610HPCD.h b/include/configs/MPC8610HPCD.h index 03ee394..d28e29b 100644 --- a/include/configs/MPC8610HPCD.h +++ b/include/configs/MPC8610HPCD.h @@ -21,12 +21,13 @@ #defineCONFIG_SYS_TEXT_BASE0xfff0 -#define CONFIG_FSL_DIU_FB 1 /* FSL DIU */ /* video */ -#undef CONFIG_VIDEO +#undef CONFIG_FSL_DIU_FB -#ifdef CONFIG_VIDEO +#ifdef CONFIG_FSL_DIU_FB +#define CONFIG_SYS_DIU_ADDR(CONFIG_SYS_CCSRBAR + 0x2c000) +#define CONFIG_VIDEO #define CONFIG_CMD_BMP #define CONFIG_CFB_CONSOLE #define CONFIG_VGA_AS_SINGLE_DEVICE @@ -88,8 +89,6 @@ #define CONFIG_SYS_CCSRBAR_PHYS_HIGH 0x0 #define CONFIG_SYS_CCSRBAR_PHYSCONFIG_SYS_CCSRBAR_PHYS_LOW -#define CONFIG_SYS_DIU_ADDR(CONFIG_SYS_CCSRBAR+0x2c000) - /* DDR Setup */ #define CONFIG_FSL_DDR2 #undef CONFIG_FSL_DDR_INTERACTIVE @@ -494,9 +493,6 @@ #define CONFIG_WATCHDOG/* watchdog enabled */ #define CONFIG_SYS_WATCHDOG_FREQ 5000/* Feed interval, 5s */ -/*DIU Configuration*/ -#define DIU_CONNECT_TO_DVI /* DIU controller connects to DVI encoder*/ - /* * Miscellaneous configurable options */ diff --git a/include/configs/mpc5121ads.h b/include/configs/mpc5121ads.h index f966325..72c8e3f 100644 --- a/include/configs/mpc5121ads.h +++ b/include/configs/mpc5121ads.h @@ -46,14 +46,15 @@ */ #define CONFIG_E3001 /* E300 Family */ #define CONFIG_MPC512X 1 /* MPC512X family */ -#define CONFIG_FSL_DIU_FB 1 /* FSL DIU */ #defineCONFIG_SYS_TEXT_BASE0xFFF0 /* video */ -#undef CONFIG_VIDEO +#undef CONFIG_FSL_DIU_FB -#ifdef CONFIG_VIDEO +#ifdef CONFIG_FSL_DIU_FB +#define CONFIG_SYS_DIU_ADDR(CONFIG_SYS_IMMR + 0x2100) +#define CONFIG_VIDEO #define CONFIG_CMD_BMP #define CONFIG_CFB_CONSOLE #define CONFIG_VGA_AS_SINGLE_DEVICE @@ -74,7 +75,6 @@ #define CONFIG_MISC_INIT_R #define CONFIG_SYS_IMMR0x8000 -#define CONFIG_SYS_DIU_ADDR(CONFIG_SYS_IMMR+0x2100) #define CONFIG_SYS_MEMTEST_START 0x0020 /* memtest region */ #define CONFIG_SYS_MEMTEST_END 0x0040 -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: clean up DIU macro definitions for the MPC8610HPCD and MPC5121ADS
Dear Timur Tabi, In message 1297804966-21532-1-git-send-email-ti...@freescale.com you wrote: Clean up the macro defintions used to enable DIU (video) support on the MPC8610HPCD and the MPC5121ADS so that they look more like the P1022DS, which is newer. Signed-off-by: Timur Tabi ti...@freescale.com --- include/configs/MPC8610HPCD.h | 12 include/configs/mpc5121ads.h |8 2 files changed, 8 insertions(+), 12 deletions(-) diff --git a/include/configs/MPC8610HPCD.h b/include/configs/MPC8610HPCD.h index 03ee394..d28e29b 100644 --- a/include/configs/MPC8610HPCD.h +++ b/include/configs/MPC8610HPCD.h @@ -21,12 +21,13 @@ #define CONFIG_SYS_TEXT_BASE0xfff0 -#define CONFIG_FSL_DIU_FB1 /* FSL DIU */ /* video */ -#undef CONFIG_VIDEO +#undef CONFIG_FSL_DIU_FB Please do not undef what is not defiend anyway. ... diff --git a/include/configs/mpc5121ads.h b/include/configs/mpc5121ads.h index f966325..72c8e3f 100644 --- a/include/configs/mpc5121ads.h +++ b/include/configs/mpc5121ads.h @@ -46,14 +46,15 @@ */ #define CONFIG_E300 1 /* E300 Family */ #define CONFIG_MPC512X 1 /* MPC512X family */ -#define CONFIG_FSL_DIU_FB1 /* FSL DIU */ #define CONFIG_SYS_TEXT_BASE0xFFF0 /* video */ -#undef CONFIG_VIDEO +#undef CONFIG_FSL_DIU_FB Ditto. And please put the respective arch custodians on Cc: Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something. - Franklin D. Roosevelt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: clean up DIU macro definitions for the MPC8610HPCD and MPC5121ADS
Wolfgang Denk wrote: -#undef CONFIG_VIDEO +#undef CONFIG_FSL_DIU_FB Please do not undef what is not defiend anyway. Would you be okay with this: /* video */ /* #define CONFIG_FSL_DIU_FB */ #ifdef CONFIG_FSL_DIU_FB And please put the respective arch custodians on Cc: I did CC: Kumar. He's the PowerPC arch custodian. I don't consider this to be a patch for the video repository, so I didn't CC: Anatolij. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: clean up DIU macro definitions for the MPC8610HPCD and MPC5121ADS
Dear Timur Tabi, In message 4d5af2c9.10...@freescale.com you wrote: And please put the respective arch custodians on Cc: I did CC: Kumar. He's the PowerPC arch custodian. No. There is no such thing as a PowerPC custodian. Kumar is responsible for 85xx/86xx. This patch also affects 5xxx. For details please see http://www.denx.de/wiki/U-Boot/Custodians Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de For every problem there is one solution which is simple, neat, and wrong.- H. L. Mencken ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [v2] powerpc: clean up DIU macro definitions for the MPC8610HPCD and MPC5121ADS
Clean up the macro defintions used to enable DIU (video) support on the MPC8610HPCD and the MPC5121ADS so that they look more like the P1022DS, which is newer. Signed-off-by: Timur Tabi ti...@freescale.com --- include/configs/MPC8610HPCD.h | 12 include/configs/mpc5121ads.h |8 2 files changed, 8 insertions(+), 12 deletions(-) diff --git a/include/configs/MPC8610HPCD.h b/include/configs/MPC8610HPCD.h index 03ee394..8022895 100644 --- a/include/configs/MPC8610HPCD.h +++ b/include/configs/MPC8610HPCD.h @@ -21,12 +21,13 @@ #defineCONFIG_SYS_TEXT_BASE0xfff0 -#define CONFIG_FSL_DIU_FB 1 /* FSL DIU */ /* video */ -#undef CONFIG_VIDEO +/* #define CONFIG_FSL_DIU_FB */ -#ifdef CONFIG_VIDEO +#ifdef CONFIG_FSL_DIU_FB +#define CONFIG_SYS_DIU_ADDR(CONFIG_SYS_CCSRBAR + 0x2c000) +#define CONFIG_VIDEO #define CONFIG_CMD_BMP #define CONFIG_CFB_CONSOLE #define CONFIG_VGA_AS_SINGLE_DEVICE @@ -88,8 +89,6 @@ #define CONFIG_SYS_CCSRBAR_PHYS_HIGH 0x0 #define CONFIG_SYS_CCSRBAR_PHYSCONFIG_SYS_CCSRBAR_PHYS_LOW -#define CONFIG_SYS_DIU_ADDR(CONFIG_SYS_CCSRBAR+0x2c000) - /* DDR Setup */ #define CONFIG_FSL_DDR2 #undef CONFIG_FSL_DDR_INTERACTIVE @@ -494,9 +493,6 @@ #define CONFIG_WATCHDOG/* watchdog enabled */ #define CONFIG_SYS_WATCHDOG_FREQ 5000/* Feed interval, 5s */ -/*DIU Configuration*/ -#define DIU_CONNECT_TO_DVI /* DIU controller connects to DVI encoder*/ - /* * Miscellaneous configurable options */ diff --git a/include/configs/mpc5121ads.h b/include/configs/mpc5121ads.h index f966325..01dd096 100644 --- a/include/configs/mpc5121ads.h +++ b/include/configs/mpc5121ads.h @@ -46,14 +46,15 @@ */ #define CONFIG_E3001 /* E300 Family */ #define CONFIG_MPC512X 1 /* MPC512X family */ -#define CONFIG_FSL_DIU_FB 1 /* FSL DIU */ #defineCONFIG_SYS_TEXT_BASE0xFFF0 /* video */ -#undef CONFIG_VIDEO +/* #define CONFIG_FSL_DIU_FB */ -#ifdef CONFIG_VIDEO +#ifdef CONFIG_FSL_DIU_FB +#define CONFIG_SYS_DIU_ADDR(CONFIG_SYS_IMMR + 0x2100) +#define CONFIG_VIDEO #define CONFIG_CMD_BMP #define CONFIG_CFB_CONSOLE #define CONFIG_VGA_AS_SINGLE_DEVICE @@ -74,7 +75,6 @@ #define CONFIG_MISC_INIT_R #define CONFIG_SYS_IMMR0x8000 -#define CONFIG_SYS_DIU_ADDR(CONFIG_SYS_IMMR+0x2100) #define CONFIG_SYS_MEMTEST_START 0x0020 /* memtest region */ #define CONFIG_SYS_MEMTEST_END 0x0040 -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: clean up DIU macro definitions for the MPC8610HPCD and MPC5121ADS
Dear Timur Tabi, In message 20110215215557.8f4c2151...@gemini.denx.de I wrote: In message 4d5af2c9.10...@freescale.com you wrote: And please put the respective arch custodians on Cc: To make myself more clear: Normally, you should put the respective board maintainer(s) on Cc:. Only in cases like here, where the boards are orphaned and without registered maintainers, the respective arch custodians should be Cc:ed. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Die ganzen Zahlen hat der liebe Gott geschaffen, alles andere ist Menschenwerk... Leopold Kronecker ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [v2] powerpc: clean up DIU macro definitions for the MPC8610HPCD and MPC5121ADS
Dear Timur Tabi, In message 1297807109-21948-1-git-send-email-ti...@freescale.com you wrote: Clean up the macro defintions used to enable DIU (video) support on the MPC8610HPCD and the MPC5121ADS so that they look more like the P1022DS, which is newer. Signed-off-by: Timur Tabi ti...@freescale.com --- include/configs/MPC8610HPCD.h | 12 include/configs/mpc5121ads.h |8 2 files changed, 8 insertions(+), 12 deletions(-) diff --git a/include/configs/MPC8610HPCD.h b/include/configs/MPC8610HPCD.h index 03ee394..8022895 100644 --- a/include/configs/MPC8610HPCD.h +++ b/include/configs/MPC8610HPCD.h @@ -21,12 +21,13 @@ #define CONFIG_SYS_TEXT_BASE0xfff0 -#define CONFIG_FSL_DIU_FB1 /* FSL DIU */ /* video */ -#undef CONFIG_VIDEO +/* #define CONFIG_FSL_DIU_FB */ Please do not add dead code. diff --git a/include/configs/mpc5121ads.h b/include/configs/mpc5121ads.h index f966325..01dd096 100644 --- a/include/configs/mpc5121ads.h +++ b/include/configs/mpc5121ads.h @@ -46,14 +46,15 @@ */ #define CONFIG_E300 1 /* E300 Family */ #define CONFIG_MPC512X 1 /* MPC512X family */ -#define CONFIG_FSL_DIU_FB1 /* FSL DIU */ #define CONFIG_SYS_TEXT_BASE0xFFF0 /* video */ -#undef CONFIG_VIDEO +/* #define CONFIG_FSL_DIU_FB */ Ditto. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de No man knows what true happiness is until he gets married. By then, of course, its too late. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [v2] powerpc: clean up DIU macro definitions for the MPC8610HPCD and MPC5121ADS
Wolfgang Denk wrote: /* video */ -#undef CONFIG_VIDEO +/* #define CONFIG_FSL_DIU_FB */ Please do not add dead code. It's not dead code. It's a comment that tells people how to enable video support. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [v2] powerpc: clean up DIU macro definitions for the MPC8610HPCD and MPC5121ADS
Dear Timur Tabi, In message 4d5af8a8.2010...@freescale.com you wrote: Wolfgang Denk wrote: /* video */ -#undef CONFIG_VIDEO +/* #define CONFIG_FSL_DIU_FB */ Please do not add dead code. It's not dead code. It's a comment that tells people how to enable video support. It is dead code. Please remove it. Documentation is already present in the README, isn't it? Ouch - gotcha! Please fix _that_. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The high cost of living hasn't affected its popularity. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] updates for DFU and atmel usba udc
Dear Remy and Reinhard, Hmm, Let's make it even more black/white: I do not have to like the board code. ;-) Reinhard is the Atmel maintainer. He needs to pull in the Board code. I only care about generic USB code... ;-))) Please make 2 unrelated patch series (1 series for USB DFU support, 1 series for board support), or it will never hit mainline... AND: I would really recommend to build a decent USB/DFU patch series first. Forget the board for now. The board seems to depend on DFU support, not the other way around. If generic DFU code is really generic and acceptable, I will pull it in my tree. I am willing to fix small issues in the series to assist you, but I will not do major redesigns... I tried compiling everything against the rework tree. Unfortunately I don't know how to solve the reset_timer issue and my NAND won't work. Although Reinhard just commented on that, I have no clue yet how to fix it. I can't finish this work today and really have no time left for it, so I have to quit on the code for now. I will have to thank you for you assistance for now and have to get back on this in a couple of months if I do find the time again. Hopefully someone picks up the v2 patch and continues from there. It's not very difficult to make it work in Reinhard's tree I think. Best regards, Marcel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [v3] powerpc: clean up DIU macro definitions for the MPC8610HPCD and MPC5121ADS
Clean up the macro defintions used to enable DIU (video) support on the MPC8610HPCD and the MPC5121ADS so that they look more like the P1022DS, which is newer. Signed-off-by: Timur Tabi ti...@freescale.com --- doc/README.mpc5121ads | 18 ++ doc/README.mpc8610hpcd|7 +++ include/configs/MPC8610HPCD.h | 12 +++- include/configs/mpc5121ads.h |8 +++- 4 files changed, 31 insertions(+), 14 deletions(-) create mode 100644 doc/README.mpc5121ads diff --git a/doc/README.mpc5121ads b/doc/README.mpc5121ads new file mode 100644 index 000..78fc3c9 --- /dev/null +++ b/doc/README.mpc5121ads @@ -0,0 +1,18 @@ +Freescale MPC5121ADS board +=== + + +Building U-Boot +--- + +$ make mpc5121ads_config +Configuring for mpc5121ads board... + +$ make + + +Video Support +- +To enable DIU video support (console on a video display), define the macro +CONFIG_FSL_DIU_FB in the board header file (mpc5121ads.h) and set the +'monitor' environment variable appropriately. diff --git a/doc/README.mpc8610hpcd b/doc/README.mpc8610hpcd index 31a9af3..8f878c4 100644 --- a/doc/README.mpc8610hpcd +++ b/doc/README.mpc8610hpcd @@ -71,3 +71,10 @@ DIP Switch Settings --- To manually switch the flash banks using the DIP switch settings, toggle both SW6:1 and SW6:2. + + +Video Support +- +To enable DIU video support (console on a video display), define the macro +CONFIG_FSL_DIU_FB in the board header file (MPC8610HPCD.h) and set the +'monitor' environment variable appropriately. diff --git a/include/configs/MPC8610HPCD.h b/include/configs/MPC8610HPCD.h index 03ee394..1e321f4 100644 --- a/include/configs/MPC8610HPCD.h +++ b/include/configs/MPC8610HPCD.h @@ -21,12 +21,11 @@ #defineCONFIG_SYS_TEXT_BASE0xfff0 -#define CONFIG_FSL_DIU_FB 1 /* FSL DIU */ /* video */ -#undef CONFIG_VIDEO - -#ifdef CONFIG_VIDEO +#ifdef CONFIG_FSL_DIU_FB +#define CONFIG_SYS_DIU_ADDR(CONFIG_SYS_CCSRBAR + 0x2c000) +#define CONFIG_VIDEO #define CONFIG_CMD_BMP #define CONFIG_CFB_CONSOLE #define CONFIG_VGA_AS_SINGLE_DEVICE @@ -88,8 +87,6 @@ #define CONFIG_SYS_CCSRBAR_PHYS_HIGH 0x0 #define CONFIG_SYS_CCSRBAR_PHYSCONFIG_SYS_CCSRBAR_PHYS_LOW -#define CONFIG_SYS_DIU_ADDR(CONFIG_SYS_CCSRBAR+0x2c000) - /* DDR Setup */ #define CONFIG_FSL_DDR2 #undef CONFIG_FSL_DDR_INTERACTIVE @@ -494,9 +491,6 @@ #define CONFIG_WATCHDOG/* watchdog enabled */ #define CONFIG_SYS_WATCHDOG_FREQ 5000/* Feed interval, 5s */ -/*DIU Configuration*/ -#define DIU_CONNECT_TO_DVI /* DIU controller connects to DVI encoder*/ - /* * Miscellaneous configurable options */ diff --git a/include/configs/mpc5121ads.h b/include/configs/mpc5121ads.h index f966325..33a5b86 100644 --- a/include/configs/mpc5121ads.h +++ b/include/configs/mpc5121ads.h @@ -46,14 +46,13 @@ */ #define CONFIG_E3001 /* E300 Family */ #define CONFIG_MPC512X 1 /* MPC512X family */ -#define CONFIG_FSL_DIU_FB 1 /* FSL DIU */ #defineCONFIG_SYS_TEXT_BASE0xFFF0 /* video */ -#undef CONFIG_VIDEO - -#ifdef CONFIG_VIDEO +#ifdef CONFIG_FSL_DIU_FB +#define CONFIG_SYS_DIU_ADDR(CONFIG_SYS_IMMR + 0x2100) +#define CONFIG_VIDEO #define CONFIG_CMD_BMP #define CONFIG_CFB_CONSOLE #define CONFIG_VGA_AS_SINGLE_DEVICE @@ -74,7 +73,6 @@ #define CONFIG_MISC_INIT_R #define CONFIG_SYS_IMMR0x8000 -#define CONFIG_SYS_DIU_ADDR(CONFIG_SYS_IMMR+0x2100) #define CONFIG_SYS_MEMTEST_START 0x0020 /* memtest region */ #define CONFIG_SYS_MEMTEST_END 0x0040 -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [v3] powerpc: clean up DIU macro definitions for the MPC8610HPCD and MPC5121ADS
Dear Timur Tabi, In message 1297808617-22396-1-git-send-email-ti...@freescale.com you wrote: Clean up the macro defintions used to enable DIU (video) support on the MPC8610HPCD and the MPC5121ADS so that they look more like the P1022DS, which is newer. Signed-off-by: Timur Tabi ti...@freescale.com --- doc/README.mpc5121ads | 18 ++ doc/README.mpc8610hpcd|7 +++ include/configs/MPC8610HPCD.h | 12 +++- include/configs/mpc5121ads.h |8 +++- 4 files changed, 31 insertions(+), 14 deletions(-) create mode 100644 doc/README.mpc5121ads diff --git a/doc/README.mpc5121ads b/doc/README.mpc5121ads new file mode 100644 index 000..78fc3c9 --- /dev/null +++ b/doc/README.mpc5121ads @@ -0,0 +1,18 @@ +Freescale MPC5121ADS board +=== + + +Building U-Boot +--- + +$ make mpc5121ads_config +Configuring for mpc5121ads board... + +$ make + + +Video Support +- +To enable DIU video support (console on a video display), define the macro +CONFIG_FSL_DIU_FB in the board header file (mpc5121ads.h) and set the +'monitor' environment variable appropriately. Thanks - well meant, but wrong. It makes little sense to add a README.board file which contains only commonplace like how to configure and build. And CONFIG_* options must be explained in the top level README, not in some board files, and especially not repeatedly in all that might be affected. Such redundancy is always a Bad Thing. Please drop these README.board files and move the documentation for CONFIG_FSL_DIU_FB into README. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The bad reputation UNIX has gotten is totally undeserved, laid on by people who don't understand, who have not gotten in there and tried anything. -- Jim Joyce, owner of Jim Joyce's UNIX Bookstore ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [v4] powerpc: clean up DIU macro definitions for Freescale reference boards
Clean up the macro defintions used to enable DIU (video) support on the MPC8610HPCD and the MPC5121ADS so that they look more like the P1022DS, which is newer. Add software cursor support to all three boards. Also document the CONFIG_FSL_DIU_FB in the README. Signed-off-by: Timur Tabi ti...@freescale.com --- README| 22 ++ include/configs/MPC8610HPCD.h | 13 - include/configs/P1022DS.h |3 +-- include/configs/mpc5121ads.h |9 - 4 files changed, 31 insertions(+), 16 deletions(-) diff --git a/README b/README index 755d17c..9597fed 100644 --- a/README +++ b/README @@ -1057,6 +1057,28 @@ The following options need to be configured: and 16bpp modes defined by CONFIG_VIDEO_SED13806_8BPP or CONFIG_VIDEO_SED13806_16BPP + CONFIG_FSL_DIU_FB + Enable the Freescale DIU video driver. Reference boards for + SOCs that have a DIU should define this macro to enable DIU + support, and should also define these other macros: + + CONFIG_SYS_DIU_ADDR + CONFIG_VIDEO + CONFIG_CMD_BMP + CONFIG_CFB_CONSOLE + CONFIG_VIDEO_SW_CURSOR + CONFIG_VGA_AS_SINGLE_DEVICE + CONFIG_VIDEO_LOGO + CONFIG_VIDEO_BMP_LOGO + + The DIU driver will look for the 'monitor' environment variable, + and if defined, enable the DIU as a console during boot. This + variable should be set to one of these values: + + '0' Output video to the DVI connector + '1' Output video to the LVDS connector + '2' Output video to the Dual-Link LVDS connector + - Keyboard Support: CONFIG_KEYBOARD diff --git a/include/configs/MPC8610HPCD.h b/include/configs/MPC8610HPCD.h index 03ee394..de01c31 100644 --- a/include/configs/MPC8610HPCD.h +++ b/include/configs/MPC8610HPCD.h @@ -21,14 +21,14 @@ #defineCONFIG_SYS_TEXT_BASE0xfff0 -#define CONFIG_FSL_DIU_FB 1 /* FSL DIU */ /* video */ -#undef CONFIG_VIDEO - -#ifdef CONFIG_VIDEO +#ifdef CONFIG_FSL_DIU_FB +#define CONFIG_SYS_DIU_ADDR(CONFIG_SYS_CCSRBAR + 0x2c000) +#define CONFIG_VIDEO #define CONFIG_CMD_BMP #define CONFIG_CFB_CONSOLE +#define CONFIG_VIDEO_SW_CURSOR #define CONFIG_VGA_AS_SINGLE_DEVICE #define CONFIG_VIDEO_LOGO #define CONFIG_VIDEO_BMP_LOGO @@ -88,8 +88,6 @@ #define CONFIG_SYS_CCSRBAR_PHYS_HIGH 0x0 #define CONFIG_SYS_CCSRBAR_PHYSCONFIG_SYS_CCSRBAR_PHYS_LOW -#define CONFIG_SYS_DIU_ADDR(CONFIG_SYS_CCSRBAR+0x2c000) - /* DDR Setup */ #define CONFIG_FSL_DDR2 #undef CONFIG_FSL_DDR_INTERACTIVE @@ -494,9 +492,6 @@ #define CONFIG_WATCHDOG/* watchdog enabled */ #define CONFIG_SYS_WATCHDOG_FREQ 5000/* Feed interval, 5s */ -/*DIU Configuration*/ -#define DIU_CONNECT_TO_DVI /* DIU controller connects to DVI encoder*/ - /* * Miscellaneous configurable options */ diff --git a/include/configs/P1022DS.h b/include/configs/P1022DS.h index cb24041..ed2bada 100644 --- a/include/configs/P1022DS.h +++ b/include/configs/P1022DS.h @@ -185,13 +185,12 @@ #define CONFIG_SYS_PROMPT_HUSH_PS2 /* Video */ -#undef CONFIG_FSL_DIU_FB - #ifdef CONFIG_FSL_DIU_FB #define CONFIG_SYS_DIU_ADDR(CONFIG_SYS_CCSRBAR + 0x1) #define CONFIG_VIDEO #define CONFIG_CMD_BMP #define CONFIG_CFB_CONSOLE +#define CONFIG_VIDEO_SW_CURSOR #define CONFIG_VGA_AS_SINGLE_DEVICE #define CONFIG_VIDEO_LOGO #define CONFIG_VIDEO_BMP_LOGO diff --git a/include/configs/mpc5121ads.h b/include/configs/mpc5121ads.h index f966325..e7ef298 100644 --- a/include/configs/mpc5121ads.h +++ b/include/configs/mpc5121ads.h @@ -46,16 +46,16 @@ */ #define CONFIG_E3001 /* E300 Family */ #define CONFIG_MPC512X 1 /* MPC512X family */ -#define CONFIG_FSL_DIU_FB 1 /* FSL DIU */ #defineCONFIG_SYS_TEXT_BASE0xFFF0 /* video */ -#undef CONFIG_VIDEO - -#ifdef CONFIG_VIDEO +#ifdef CONFIG_FSL_DIU_FB +#define CONFIG_SYS_DIU_ADDR(CONFIG_SYS_IMMR + 0x2100) +#define CONFIG_VIDEO #define CONFIG_CMD_BMP #define CONFIG_CFB_CONSOLE +#define CONFIG_VIDEO_SW_CURSOR #define CONFIG_VGA_AS_SINGLE_DEVICE #define CONFIG_VIDEO_LOGO #define CONFIG_VIDEO_BMP_LOGO @@ -74,7 +74,6 @@ #define CONFIG_MISC_INIT_R #define CONFIG_SYS_IMMR0x8000 -#define CONFIG_SYS_DIU_ADDR(CONFIG_SYS_IMMR+0x2100) #define CONFIG_SYS_MEMTEST_START 0x0020 /* memtest region */ #define CONFIG_SYS_MEMTEST_END 0x0040 -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] spi subystem maintainer?
On Feb 15, 2011, at 2:36 AM, Mike Frysinger wrote:
On Thursday, February 03, 2011 05:36:38 Kumar Gala wrote:
On Feb 2, 2011, at 3:30 AM, Reinhard Meyer wrote:
Dear Stefano Babic:
On 02/02/2011 08:23 AM, Kumar Gala wrote:
Wanted to see if anyone had input on how to deal with the SPI
controller on some of our newer parts. It expects command data
xfer's to happen together. However our current code does not call
spi_xfer() that way.
Which is your concrete case ? spi_xfer is responsible to setup the
controller and to start the transfer, and everything could be done
inside this function. What do you mean exactly with command and data ?
Regards,
Stefano
I think he refers to the common problem that many SPI devices
require CS to stay low during both phases of issuing the
read/write command and transfering the actual data.
Current u-boot code calls spi_xfer() two times.
Hardware controlled CS often go high between both calls, which
requires you to (at least) use GPIO controlled CS, or, even worse,
use bitbang SPI (in cases where the SPI pin assignment is in groups,
not individually).
That's correct, and with the newer FSL controller's we dont have direct
control over the CS. I'm thinking we need to have the command and
response dealt with in a single call to spi_xfer instead of what we seem
to do all over the place today:
ret = spi_xfer(spi, 8, cmd, NULL, flags);
if (ret) {
debug(SF: Failed to send command %02x: %d\n, cmd, ret);
return ret;
}
if (len) {
ret = spi_xfer(spi, len * 8, NULL, response, SPI_XFER_END);
if (ret)
debug(SF: Failed to read response (%zu bytes):
%d\n, len, ret);
}
Needs to turn into something like:
ret = spi_xfer(spi, 8 + len * 8, cmd, response, flags | SPI_XFER_END)
this should be easier in my sf branch as i unified a bunch of the functions.
but while this will probably work for the main commands, how is this supposed
to work for the status polling ? that function is fundamentally based around
setting up a transfer/command and then continuously shifting out a single
result and checking it before shifting out another. for your controller, the
only way to make it work is to do the full transaction every time.
-mike
Probably have to do a transaction every time.
Do you have a tree for these changes? Do you expect them to be in place for
release after v2011.03
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
On Tue, 15 Feb 2011 04:02:44 -0500 Mike Frysinger vap...@gentoo.org wrote: so commit 8aba9dc is not something made for fun, but to fix real bugs people were seeing while building with bi-endian toolchains (arm/superh/mips/probably others), or bi-abi toolchains (blackfin/arm/probably others). Sure. But it had a side effect, and this patch is an attempt to fix that side effect without affecting the real purpose of 8aba9dc. This included anything that cpu/board code added to LDFLAGS -- some architectures added --gc-sections, x86 added --cref, etc. Since the above flags are added to LDFLAGS, rather than replacing them, these flags got used in the final link. Commit 8aba9dc introduces LDFLAGS_u-boot, so that LDFLAGS is no longer the source for the flags for the final link. It generates LDFLAGS_u-boot using PLATFORM_LDFLAGS, not LDFLAGS. It converts most of the board/cpu updates to LDFLAGS into LDFLAGS_u-boot, but it missed --cref. err, i dont think this is correct. LDFLAGS is no longer the *only* source for the final link. if you look at the actual target, you'll see it using $(LDFLAGS) $(LDFLAGS_$(@F)). Ah. So why is PLATFORM_LDFLAGS added into both LDFLAGS and LDFLAGS_u-boot? :-P -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] need your help
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang Denk Sent: Wednesday, February 16, 2011 1:44 AM To: nice Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] need your help [snip] Here are more errors. ## Flattened Device Tree blob at 0040 This is a pretty low address. Eventyally the device tree blob gets overwritten during uncompression. try 0xc0. Roy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request - microblaze
Wolfgang Denk wrote: Dear Michal Simek, In message 4d5a8b38.5030...@monstr.eu you wrote: Dear Wolfgang, please pull the following two bug fixes for Microblaze. Thanks, Michal The following changes since commit c65715de780945950d570e2b69f94e0b186f04b4: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-mips are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git master Michal Simek (2): microblaze: Fix systems with MSR=0 microblaze: Fix msr handling in interrupt_handler arch/microblaze/cpu/irq.S | 19 +-- arch/microblaze/include/asm/asm.h |2 +- 2 files changed, 2 insertions(+), 19 deletions(-) Which branch should I pull from? I guess you mean u-boot-microblaze.git #master ? It was above. are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git master Pulled - hope that was OK. yes, it was. Thanks, Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] ftpmu010: support faraday ftpmu010 driver
Hi Macpaul, On Wed, Jan 26, 2011 at 5:19 AM, Wolfgang Denk w...@denx.de wrote: In message 1294218744-2535-1-git-send-email-macp...@andestech.com you wrote: Faraday's ftpmu010 is a power managemnet unit which support cpu sleep and frequency scaling. It has been integrated into many SoC. This patch also move ftpmu010 to a proper place for later enhancement. Signed-off-by: Macpaul Lin macp...@andestech.com Applied, thanks. Sorry for not following this thread. I notice this today because it breaks a320. I think maybe it will be better to move driver/power/ftpmu010.h to include/ftpmu010.h and add the API declaration in it? I am trying to fix arch/arm/cpu/arm920t/a320/timer.c, but I cannot access the new API now. regards, Po-Yu Chuang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] write to mcBsp address space
Hello Ran, On Tuesday 15 February 2011 04:05 PM, Albert ARIBAUD wrote: Le 15/02/2011 09:21, Ran a écrit : Albert ARIBAUDalbert.aribaudat free.fr writes: Hi Ran, Le 15/02/2011 07:35, Ran Shalit a écrit : Hello, I'm working on OMAPL138 EVM board, with the U-BOOT. I'm trying to access and write into the register (which have write bits), but I always read 0 in all the map space of the mcBSP0 and mcBSP1. (0x01d1 - 0x1d10800, 0x01d11000 - 0x1d11800). I wonder what I missed here. any ideas are welcomed. Many SoCs have base address registers that allow remapping internal or peripheral registers anywhere in the address space, which means the actual address you're trying to get at might not be the right one. Did you check the BAR(s) and make sure the mcBsp address you're targetting is the right one for your board? Thank you very much, Ran Amicalement, Hello Albert, Thank you very much for your reply. I've checked the datasheet but I see no reference to base address registers for the mcBSP. mcBSP: http://www.ti.com/litv/pdf/sprugj6c OMAPL138: http://www.ti.com/lit/gpn/omap-l138 Evidently the mcBsp specs won't tell you how the device is mapped within a given SoC. As for the OMAPL138 SoC, it looks more like an overview. You would need to refer to a detailed spec, one with register level description of the module. I have no idea about this particular OMAP SoC. But OMAPs in general do not have the concept of base address register. One typical issue is that the module in question may not be clocked. So reads or writes to memory mapped IO locations in the module will fail. However, if this is the case it would typically generate a data abort. How about viewing this memory using a JTAG debugger? br, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] ftpmu010: support faraday ftpmu010 driver
Hi Po-Yu, 2011/2/16 Po-Yu Chuang ratbert.chu...@gmail.com Hi Macpaul, On Wed, Jan 26, 2011 at 5:19 AM, Wolfgang Denk w...@denx.de wrote: In message 1294218744-2535-1-git-send-email-macp...@andestech.com you wrote: Faraday's ftpmu010 is a power managemnet unit which support cpu Ah, we are all waiting for the timer fix for arm then the related timer and pmu patch could be reorganized. Sorry for not following this thread. I notice this today because it breaks a320. Could you please describe how does it breaks a320? I think maybe it will be better to move driver/power/ftpmu010.h to include/ftpmu010.h and add the API declaration in it? Does /* * PMU */ #define CONFIG_FTPMU010_POWER Couldn't help on fix the compile problem? Or if the problem occurs in runtime? I am trying to fix arch/arm/cpu/arm920t/a320/timer.c, but I cannot access the new API now. regards, Po-Yu Chuang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- Best regards, Macpaul Lin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] ftpmu010: support faraday ftpmu010 driver
Hi Macpaul, On Wed, Feb 16, 2011 at 3:07 PM, Macpaul Lin macp...@gmail.com wrote: 2011/2/16 Po-Yu Chuang ratbert.chu...@gmail.com On Wed, Jan 26, 2011 at 5:19 AM, Wolfgang Denk w...@denx.de wrote: Faraday's ftpmu010 is a power managemnet unit which support cpu Ah, we are all waiting for the timer fix for arm then the related timer and pmu patch could be reorganized. Do you mean there is another pmu patch to be reviewed? Yes, I am waiting for the arm timer fix too, but I just want it at least to be able to compile. Sorry for not following this thread. I notice this today because it breaks a320. Could you please describe how does it breaks a320? No big deal. Just because the original a320 timer code uses the register definitions like your new driver. Since the header is moved from arch/arm/include/asm/arch-a320/, it fails to compile (of course). I think maybe it will be better to move driver/power/ftpmu010.h to include/ftpmu010.h and add the API declaration in it? Does /* * PMU */ #define CONFIG_FTPMU010_POWER Couldn't help on fix the compile problem? Or if the problem occurs in runtime? No, I already added that. What I need is the declaration of ftpmu010_32768osc_enable(). I want to use it to replace the original pmu register access code in timer_init(). Actually, I am done with the fix (move ftpmu010.h to include/ and add declarations). I can submit the patch. Just want to know if you think it is appropriate. I am trying to fix arch/arm/cpu/arm920t/a320/timer.c, but I cannot access the new API now. regards, Po-Yu Chuang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] ftpmu010: support faraday ftpmu010 driver
Hi Po-Yu and Wolfgang, 2011/2/16 Po-Yu Chuang ratbert.chu...@gmail.com Actually, I am done with the fix (move ftpmu010.h to include/ and add declarations). I can submit the patch. Just want to know if you think it is appropriate. As you can see, the include of PMU header has been replaced to a correct path. [U-Boot,2/3] fttmr010: move fttmr010 controller to drivers/timer folder http://patchwork.ozlabs.org/patch/71952/ However, I cannot found the part of previous patch [U-Boot,1/3] You can find that I have replace a correct path to the file arch/arm/cpu/arm920t/a320/timer.c which haven't been applied. http://www.mail-archive.com/u-boot@lists.denx.de/msg41320.html Wolfgang, could you please check if something have been missing in the last git apply? It looks like that we have something missed in the current tree while this patch have been already applied http://www.mail-archive.com/u-boot@lists.denx.de/msg41320.html;. The missing part is the following patch. diff --git a/arch/arm/cpu/arm920t/a320/timer.c b/arch/arm/cpu/arm920t/a320/timer.c index d2e316f..4718ae6 100644 --- a/arch/arm/cpu/arm920t/a320/timer.c +++ b/arch/arm/cpu/arm920t/a320/timer.c @@ -19,7 +19,7 @@ #include common.h #include asm/io.h -#include asm/arch/ftpmu010.h +#include ../../../../../drivers/power/ftpmu010.h #include asm/arch/fttmr010.h static ulong timestamp; Po-Yu, Yes, there are also another patches waiting to be review and be applied. ftpmu010: fix relocation and enhance features http://patchwork.ozlabs.org/patch/77704/ I am trying to fix arch/arm/cpu/arm920t/a320/timer.c, but I cannot access the new API now. regards, Po-Yu Chuang -- Best regards, Macpaul Lin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
