Re: [U-Boot] [PATCH] Davinci: Utility for MMC boot
Hi Wolfgang,
On Wed, Jun 27, 2012 at 03:12:07, Wolfgang Denk wrote:
Dear Prabhakar Lad,
In message 1340708826-26707-1-git-send-email-prabhakar@ti.com you wrote:
From: Alagu Sankar alagusan...@embwise.com
This is a Linux command line tool specific to TI's Davinci platforms, for
flashing UBL (User Boot Loader), u-boot and u-boot Environment in the MMC/SD
card. This MMC/SD card can be used for booting Davinci platforms that
supports
MMC/SD boot option.
Do we also build UBL as part of the U-Boot source tree?
No, we do not build UBL as part of U-Boot.
If not, then why is this tool supposed to be part of the U-Boot tree?
How does this work with a SPL?
This command has options to flash u-boot images to MMC/SD card. When SPL
is supported, this command can be used to flash the single SPL image to
MMC/SD card.
--- a/Makefile
+++ b/Makefile
@@ -726,7 +726,7 @@ clean:
@rm -f $(obj)examples/api/demo{,.bin}
@rm -f $(obj)tools/bmp_logo$(obj)tools/easylogo/easylogo \
$(obj)tools/env/{fw_printenv,fw_setenv}\
- $(obj)tools/envcrc \
+ $(obj)tools/envcrc $(obj)tools/uflash/uflash \
$(obj)tools/gdb/{astest,gdbcont,gdbsend} \
$(obj)tools/gen_eth_addr$(obj)tools/img2srec \
$(obj)tools/mk{env,}image $(obj)tools/mpc86x_clk \
Please keep list sorted.
Ok.
+e. Using the 'uflash' utility, place the UBL and u-uoot binaries on the MMC
+ card. Copy the u-boot.bin to tools/uflash directory
Why is this copy operation needed?
This copy is not needed as long as the path to u-boot.bin is specified
Correctly in command line.
And where is the UBL binary coming from?
UBL binary is optional. We can flash only u-boot.bin.
diff --git a/tools/uflash/config.txt b/tools/uflash/config.txt
new file mode 100644
index 000..f6acb22
--- /dev/null
+++ b/tools/uflash/config.txt
@@ -0,0 +1,11 @@
+bootargs=console=ttyS0,115200n8 root=/dev/mmcblk0p1 rootwait
rootfstype=ext3 rw
+bootcmd=ext2load mmc 0 0x8070 boot/uImage; bootm 0x8070
+bootdelay=1
+baudrate=115200
+bootfile=uImage
+stdin=serial
+stdout=serial
+stderr=serial
+ethact=dm9000
+videostd=ntsc
This looks like U-Boot environment settings? Why are these in the
tools/uflash/ directory? I would expect these are board specific?
For example, what in case a board uses a different baud rate?
Is this really supposed to be board independent? It doesn't look
so...
I agree with this. Can you think of any other scenario?
+
And please, no trailing empty lines!
Ok.
...
+ if (!strcmp(platform, DM3XX)) {
+ if (!uboot_load_address)
+ uboot_load_address = DM3XX_UBOOT_LOAD_ADDRESS;
+ if (!uboot_entry_point)
+ uboot_entry_point = DM3XX_UBOOT_LOAD_ADDRESS;
+ }
+
+ if (!strcmp(platform, OMAPL138)) {
+ if (!uboot_load_address)
+ uboot_load_address = DA850_UBOOT_LOAD_ADDRESS;
+ if (!uboot_entry_point)
+ uboot_entry_point = DA850_UBOOT_LOAD_ADDRESS;
+ }
So this is actually all hardwired for a few very specific board
configurations, right?
Yes.
.
+static int get_file_size(char *fname)
+{
+ FILE *fp;
+ int size;
+
+ fp = fopen(fname, rb);
+ if (fp == NULL) {
+ fprintf(stdout, File %s Open Error : %s\n,
+ fname, strerror(errno));
+ return -1;
+ }
+
+ fseek(fp, 0, SEEK_END);
+ size = ftell(fp);
+ fclose(fp);
Why not simply using stat() ?
Yes that makes sense.
+static int write_file(int devfd, char *fname)
+{
+ FILE *fp;
+ int readlen, writelen;
+
+ fp = fopen(fname, rb);
+ if (fp == NULL) {
+ fprintf(stderr, File %s Open Error: %s,
+ fname, strerror(errno));
+ return -1;
+ }
+
+ while ((readlen = fread(readbuf, 1, BLOCK_SIZE, fp)) 0) {
+ if (readlen BLOCK_SIZE)
+ memset(readbuf[readlen], 0, BLOCK_SIZE-readlen);
+
+ writelen = write(devfd, readbuf, BLOCK_SIZE);
+ if (writelen BLOCK_SIZE) {
+ close(devfd);
+ return -1;
+ }
+ }
+
+ fclose(fp);
You don't even print a warning or error message in case of read
errors? Ouch...
Ok , I'll fix it in V2 version.
Thx,
--Prabhakar Lad
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
C makes it easy for you to shoot yourself in the foot. C++ makes that
Re: [U-Boot] where is rootfs??
Hello thanks for respond. This method not woking good :( Do you have enything sugestion to modify rootfs files?? I find with vmlinux package gzip. In the gzip write files with rootfs. I don't now what I must do to rebuilit this vmlinux :/ Please help ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: rmobile: Add supoprt for KMC KZM-A9-GT board
Dear Nobuhiro Iwamatsu, In message cabmqnv+raovbxagnmv9vo2hyjqz7uz2-tox91qaynrwx4pq...@mail.gmail.com you wrote: ... --- /dev/null +++ b/board/kmc/kzm/lowlevel_init.S ... + and_write32 LIFEC_SEC_SRC, 0xFFE7 + + and_write32 SRCR3, 0x7FFF + and_write32 SMSTPCR2,0xFFFB + and_write32 SRCR2, 0xFFFB + write32 PLLECR, 0x + + cmp_loopPLLECR, 0x0F00, 0x + cmp_loopFRQCRB, 0x8000, 0x + + write32 PLL0CR, 0x2D00 + write32 PLL1CR, 0x1710 + write32 FRQCRB, 0x96235880 + cmp_loopFRQCRB, 0x8000, 0x + + write32 FLCKCR, 0x000B + and_write32 SMSTPCR0, 0xFFFD + + and_write32 SRCR0, 0xFFFD + write32 SMGPIOTIME, 0x0514 + write32 SMCMT2TIME, 0x0514 + write32 SMCPGTIME, 0x0514 + write32 SMSYSCTIME, 0x0514 + + write32 DVFSCR4, 0x00092000 + write32 DVFSCR5, 0x00DC + write32 PLLECR, 0x + cmp_loopPLLECR, 0x0F00, 0x + + write32 FRQCRA, 0x0012453C + write32 FRQCRB, 0x80331350 + cmp_loopFRQCRB, 0x8000, 0x + write32 FRQCRD, 0x0B0B + cmp_loopFRQCRD, 0x8000, 0x + + write32 PCLKCR, 0x0003 + write32 VCLKCR1, 0x012F + write32 VCLKCR2, 0x0119 + write32 VCLKCR3, 0x0119 + write32 ZBCKCR, 0x0002 + write32 FLCKCR, 0x0005 + write32 SD0CKCR, 0x0080 + write32 SD1CKCR, 0x0080 + write32 SD2CKCR, 0x0080 + write32 FSIACKCR, 0x003F + write32 FSIBCKCR, 0x003F + write32 SUBCKCR, 0x0080 + write32 SPUACKCR, 0x000B + write32 SPUVCKCR, 0x000B + write32 MSUCKCR, 0x013F + write32 HSICKCR, 0x0080 + write32 MFCK1CR, 0x003F + write32 MFCK2CR, 0x003F + write32 DSITCKCR, 0x0107 + write32 DSI0PCKCR, 0x0313 + write32 DSI1PCKCR, 0x130D + write32 DSI0PHYCR, 0x2A800E0E + write32 PLL0CR, 0x1E00 + write32 PLL0CR, 0x2D00 + write32 PLL1CR, 0x1710 + write32 PLL2CR, 0x2780 + write32 PLL3CR, 0x1D00 + write32 PLL0STPCR, 0x0008 + write32 PLL1STPCR, 0x000120C0 + write32 PLL2STPCR, 0x00012000 + write32 PLL3STPCR, 0x0030 + write32 PLLECR, 0x000B + cmp_loopPLLECR, 0x0B00, 0x0B00 + + write32 DVFSCR3, 0x000120F0 + write32 MPMODE, 0x0020 + write32 VREFCR, 0x028A + write32 RMSTPCR0, 0xE4628087 + write32 RMSTPCR1, 0x + write32 RMSTPCR2, 0x53FF + write32 RMSTPCR3, 0x + write32 RMSTPCR4, 0x00800D3D + write32 RMSTPCR5, 0xF3FF + write32 SMSTPCR2, 0x + write32 SRCR2, 0x0004 + and_write32 PLLECR, 0xFFF7 + cmp_loopPLLECR, 0x0800, 0x + + write32 HPBCTRL6, 0x0001 + cmp_loopHPBCTRL6, 0x0001, 0x0001 + + write32 FRQCRD, 0x1414 + cmp_loopFRQCRD, 0x8000, 0x + + write32 PLL3CR, 0x1D00 + or_write32 PLLECR, 0x0008 + cmp_loopPLLECR, 0x0800, 0x0800 + + or_write32 DLLCNT0A, 0x0002 + write32 SDGENCNTA, 0x0005 + cmp_loopSDGENCNTA, 0x, 0x + + write32 SDCR0A, 0xACC90159 + write32 SDCR1A, 0x00010059 + write32 SDWCRC0A, 0x50874114 + write32 SDWCRC1A, 0x33199B37 + write32 SDWCRC2A, 0x008F2313 + write32 SDWCR00A, 0x31020707 + write32 SDWCR01A, 0x0017040A + write32 SDWCR10A, 0x31020707 + write32 SDWCR11A, 0x0017040A + write32 SDDRVCR0A, 0x0555 + write32 SDWCR2A, 0x3000 + or_write32 SDPCRA, 0x0080 + cmp_loopSDPCRA, 0x0080, 0x0080 + write32 SDGENCNTA, 0x2710 + cmp_loopSDGENCNTA, 0x, 0x + write32 SDMRACR0A, 0x003F + write32 SDMRA1, 0x + write32 SDGENCNTA, 0x01F4 + cmp_loopSDGENCNTA, 0x, 0x + write32 SDMRACR0A, 0xFF0A + write32
Re: [U-Boot] [PATCH 1/1] USB: EHCI: Initialize multiple USB controllers at once
Dear Jim Lin, sending the very same message eight (8!) times doesnot make it a bit more convincing - on contrary. In message 4b9c9637d5087840a465bdcb251780e9e2d6eda...@hkmail02.nvidia.com you wrote: U-Boot is not multi-tasking, so you can always access only a single USB device at a time ayway. And it is a decoumented design principle that U-Boot must not initialize any devices it does not use itself. So why? Because of this complaint and request for devices under different controllers to be working at same time. You make another claim here, but don't explain how this is supposed to work or whay the exact use case would be where this was needed. U-Boot will not be able to access multiple devices at the same time, so why would it be necessary to enable these? It should be sufficient to enable the controller that is responsible for the single device that is currently being used. One particularly annoying consequence of this is when you use the Seaboard configuration on Springbank. Seaboard selects Tegra's USB3 as usb 0 device, which is the one you can use, in order not to conflict with the flashing USB port USB1. However, Springbank only exposes USB1 since USB3 is used internally for the USB keyboard/mouse. As such, you cannot use the USB port on Springbank under U-Boot at the moment. I have to admit that I cannot make any sense from this statement. The only thing I understand is that you are trying to use a configuration for one hardware (Seaboard) on another, incompatible hardware (Springbank). The simple answer to this problem is: don't do that, then. 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 Ordnung ist die Lust der Vernunft, aber Unordnung die Wonne der Phantasie - Paul Claudel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Davinci: Utility for MMC boot
Dear Lad, Prabhakar,
In message 4665bc9cc4253445b213a010e6dc7b35cdd...@dbde01.ent.ti.com you wrote:
This is a Linux command line tool specific to TI's Davinci platforms, f
or
flashing UBL (User Boot Loader), u-boot and u-boot Environment in the M
MC/SD
card. This MMC/SD card can be used for booting Davinci platforms that s
upports
MMC/SD boot option.
Do we also build UBL as part of the U-Boot source tree?
No, we do not build UBL as part of U-Boot.
Why not?
I assume by adding this tool to the U-Boot tree you want to provide a
single, self-contained build system for the boot loader on such
boards. But this doesn;t work if we are not also building the UBL
image.
If not, then why is this tool supposed to be part of the U-Boot tree?
How does this work with a SPL?
This command has options to flash u-boot images to MMC/SD card. When SPL
is supported, this command can be used to flash the single SPL image to
MMC/SD card.
How exactly does this work? You do not document this use case.
+e. Using the 'uflash' utility, place the UBL and u-uoot binaries on th
e MMC
+ card. Copy the u-boot.bin to tools/uflash directory
Why is this copy operation needed?
This copy is not needed as long as the path to u-boot.bin is specified
Correctly in command line.
And where is the UBL binary coming from?
UBL binary is optional. We can flash only u-boot.bin.
I did not understand this from your documentation. Can you please add
this information?
This looks like U-Boot environment settings? Why are these in the
tools/uflash/ directory? I would expect these are board specific?
For example, what in case a board uses a different baud rate?
Is this really supposed to be board independent? It doesn't look
so...
I agree with this. Can you think of any other scenario?
I have no idea what you are trying to do here. The envrionment
settings are inherently part of U-Boot, and I don't understand why you
are adding another set of settings here.
+ if (!strcmp(platform, DM3XX)) {
+ if (!uboot_load_address)
+ uboot_load_address = DM3XX_UBOOT_LOAD_ADDRESS;
+ if (!uboot_entry_point)
+ uboot_entry_point = DM3XX_UBOOT_LOAD_ADDRESS;
+ }
+
+ if (!strcmp(platform, OMAPL138)) {
+ if (!uboot_load_address)
+ uboot_load_address = DA850_UBOOT_LOAD_ADDRESS;
+ if (!uboot_entry_point)
+ uboot_entry_point = DA850_UBOOT_LOAD_ADDRESS;
+ }
So this is actually all hardwired for a few very specific board
configurations, right?
Yes.
Sorry, but this doesn't make sense then. It doesn't scale. It should
be possible to use such a tool with any such board - and without
changing the code of the tool. Instead of gard-coding all this
information, you should make the tool data driven, so that it's
sufficient to provide respective configuration data - actually I think
all this information is already present in the existing header files,
especially the board configuration file. So why not just reuse this
information?
You don't even print a warning or error message in case of read
errors? Ouch...
Ok , I'll fix it in V2 version.
Please check error checking / handling for all system calls and calls
to library functions.
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
I have often regretted my speech, never my silence.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: rmobile: kzm9g: Adjust hardware setting in lowlevel_init.S
Hi Albert (2012/06/27 6:22), Albert ARIBAUD wrote: On Tue, 26 Jun 2012 11:30:16 +0900, Tetsuyuki Kobayashi k...@kmckk.co.jp wrote: This patch depends on Nobuhiro Iwamatsu's arm: rmobile: Add supoprt for KMC KZM-A9-GT board Tetsuyuki Kobayashi's arm: rmobile: kzm9g: Modify sdram area Seems like a series to me -- you should post it as such, with patches numbered 1/N, 2/N etc. Should be easy as you probably already have them as a series of commits above master; git format-patch should generate the mails alright. OK. I am studying git format-patch and git send-email. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] microblaze: remove wrong define CONFIG_SYS_FLASH_PROTECTION
On 06/27/2012 12:28 AM, Stephan Linz wrote: CONFIG_SYS_FLASH_PROTECTION will defined twice. The second one is outside the flash configuration context and we can remove it safely. Signed-off-by: Stephan Linzl...@li-pro.net --- include/configs/microblaze-generic.h |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/include/configs/microblaze-generic.h b/include/configs/microblaze-generic.h index 295d123..5f16820 100644 --- a/include/configs/microblaze-generic.h +++ b/include/configs/microblaze-generic.h @@ -200,8 +200,6 @@ # define CONFIG_ENV_IS_NOWHERE1 # define CONFIG_ENV_SIZE 0x1000 # define CONFIG_ENV_ADDR (CONFIG_SYS_MONITOR_BASE - CONFIG_ENV_SIZE) -/* hardware flash protection */ -# define CONFIG_SYS_FLASH_PROTECTION #endif /* !FLASH */ /* system ace */ Applied all three patches to microblaze custodian repo with minor cleanup. 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] Atmel : usb : add EHCI driver for Atmel SoC
Dear all, On 25.06.12 15:07, Marek Vasut wrote: Dear Bo Shen, Hi Marek, On 6/25/2012 10:57, Marek Vasut wrote: Dear Bo Shen, Hi Marek, On 6/21/2012 18:17, Marek Vasut wrote: Dear Bo Shen, Some Atmel SoC support USB EHCI, add the EHCI driver to support it. To enable the USB EHCI, add the following configuration options into board relative configuration file and remove USB OHCI options. #define CONFIG_USB_EHCI #define CONFIG_USB_EHCI_ATMEL #define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 2 Signed-off-by: Bo Shenvoice.s...@atmel.com --- [...] btw do you have some user for this code? The at91sam9m10g45ek now uses OHCI, if needed, it can use EHCI. New coming boards will use EHCI. When do you see such board appearing please? The at91sam9m10g45ek board has existed in mainline. As to AT91 maintainer has no response, so I just send the EHCI driver separately. I think there're some issues with the at91 maintainer. Ccing Andreas, maybe he can actually start picking up the atmel patches? Sorry for being late, I read the list not really daily these days. AFAIR Reinhard gave up somewhere end of last year, in fact we currently have no at91 maintainer. I'm willing to step into at least for a while. My main aim is to get the latest Atmel patches into mainline for 2012.07, if Albert is willing to pull them (well less than 20 days left, and some of the patches where slightly after close of MW for 2012.07). As far as I can see these patches are left: Bo Shen (new board): http://patchwork.ozlabs.org/patch/160581/ http://patchwork.ozlabs.org/patch/167290/ Alexandre Belloni (change address for dataflash; first submission in February!): http://patchwork.ozlabs.org/patch/154242/ Jens Scharsig (fixes): http://patchwork.ozlabs.org/patch/147550/ http://patchwork.ozlabs.org/patch/147534/ Vladimir Zapolskiy (new board): http://patchwork.ozlabs.org/patch/135526/ Wolfgang and Albert, how do you think about? best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ARM CONFIG_OF_CONTROL status
Hi, can you please update me about current state of CONFIG_OF_CONTROL for ARM? Are there any other archs/boards which will use this option? Or any other git repo out of mainline u-boot? Has someone tried to look for devices based on compatible property? I see that in usb driver it is based on aliases which is not the best solution. 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][v3] powerpc/CoreNet: add tool to support pbl image build.
Hello, Andy, Do you have any comment for this patch, if no could you help apply it? Best Regards, Shaohui Xie -Original Message- From: Xie Shaohui-B21989 Sent: Tuesday, June 12, 2012 4:11 PM To: u-boot@lists.denx.de Cc: Xie Shaohui-B21989 Subject: [PATCH][v3] powerpc/CoreNet: add tool to support pbl image build. Provides a tool to build boot Image for PBL(Pre boot loader) which is used on Freescale CoreNet SoCs, PBL can be used to load some instructions and/or data for pre-initialization. The default output image is u-boot.pbl, for more details please refer to doc/README.pblimage. Signed-off-by: Shaohui Xie shaohui@freescale.com --- changes for v3: 1. dump config.mk, aligned to comment of Wolfgang Denk; 2. split one configuration file to two, one is for RCW, one is for PBI commands, add second entry in mkimage for second configuration file, aligned to comment of Wood Scott; 3. refined the README.pblimage; Makefile |6 + board/freescale/corenet_ds/pbi.cfg | 51 ++ board/freescale/corenet_ds/rcw.cfg | 32 common/image.c |1 + doc/README.pblimage| 114 + include/configs/corenet_ds.h |2 + include/image.h|1 + tools/Makefile |2 + tools/mkimage.c| 15 ++ tools/mkimage.h|3 + tools/pblimage.c | 328 tools/pblimage.h | 36 12 files changed, 591 insertions(+), 0 deletions(-) create mode 100644 board/freescale/corenet_ds/pbi.cfg create mode 100644 board/freescale/corenet_ds/rcw.cfg create mode 100644 doc/README.pblimage create mode 100644 tools/pblimage.c create mode 100644 tools/pblimage.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: enable unaligned access on ARMv7
Hi Rob and all,
Am Dienstag, den 05.06.2012, 12:42 -0600 schrieb Stephen Warren:
On 06/05/2012 11:47 AM, Lucas Stach wrote:
Recent toolchains default to using the hardware feature for
unaligned access on ARM v7, rather than doing the software
fallback. According to ARM this is safe as all v7 implementations
have to support this feature.
(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471c/BABJFFAE.html)
To avoid CPU hangs when doing unaligned memory access, we have to
turn off alignment checking in our CPU initialisation code.
(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0491c/CIHCGCFD.html)
Does this behavior change trickle down to Linux/... too, or would
an OS completely re-initialize this state, and hence not be
affected?
Linux in particular does reinitialize this state and I expect any
reasonable OS to do so.
Then what is the point of enabling it on U-Boot? Does it fix some issue
whereby some mis-aligned piece of data cannot be properly aligned?
This is a new optimization feature in gcc 4.7 (and backported to some
4.6 versions like the ubuntu 12.04 arm cross compiler (4.6.3)):
http://lists.linaro.org/pipermail/linaro-dev/2012-June/012360.html
http://seabright.co.nz/2012/06/11/kernel-not-booting-with-linaro-gcc/
If you don't want to enable unaligned accesses, then
-mno-unaligned-access needs to be added.
I verified it. Option -mno-unaligned-access works good.
include/mtd/cfi_flash.h
/* CFI standard query structure */
struct cfi_qry {
u8 qry[3];
u16 p_id; -- unaligned!
...
} __attribute__((packed));
$ ${CROSS_COMPILE}gcc --version
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.6.2 20110921
(release) [ARM/embedded-4_6-branch revision 182083]
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
=
Compiled without --mno-unaligned-access
$ ${CROSS_COMPILE}objdump -d -S u-boot
info-vendor = le16_to_cpu(qry.p_id);
cc88: e3003a1cmovwr3, #2588 ; 0xa1c
cc8c: e1dd11bbldrhr1, [sp, #27] -- this is unaligned
access
cc90: ...
cc94: e18410b3strhr1, [r4, r3]
=
Compiled with --mno-unaligned-access
$ ${CROSS_COMPILE}objdump -d -S u-boot
info-vendor = le16_to_cpu(qry.p_id);
cce8: e5dd101cldrbr1, [sp, #28] --
ccec: e5dd301bldrbr3, [sp, #27] -- separated 2 byte
accesses
ccf0: ...
ccf4: e1831401orr r1, r3, r1, lsl #8
ccf8: e3003a1cmovwr3, #2588 ; 0xa1c
ccfc: e18410b3strhr1, [r4, r3]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Is it possible to boot the U-boot from the another U-boot from the flash area
Hi All, I am really curiuos to see if U-boot can boot another version or another Uboot burnt in flash ? Its like having 2 images of U-boot which can boot each other if it is possible can any one of you hint me how I can achive this. I tried to relocate the Uboot and burned on to the flash in 2 different loacation however when I try to do go U-boot effective address it ends up in TLB error in early stage of flash execution. Thanks for the Help. Ish ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fs/ext2/ext2fs.c: fix warning
This patch fixes following warning:
---8---
ext2fs.c: In function 'ext2fs_read_file':
ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this function
[-Wuninitialized]
---8---
The warning was introduced in 436da3cd233e7166b5ce9293dbd28092cf37bcc9.
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
cc: Jason Cooper u-b...@lakedaemon.net
cc: Eric Nelson eric.nel...@boundarydevices.com
cc: Thierry Reding thierry.red...@avionic-design.de
---
fs/ext2/ext2fs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext2/ext2fs.c b/fs/ext2/ext2fs.c
index f1fce48..40b6e6f 100644
--- a/fs/ext2/ext2fs.c
+++ b/fs/ext2/ext2fs.c
@@ -440,7 +440,7 @@ int ext2fs_read_file
/* grab middle blocks in one go */
if (i != pos / blocksize i != blockcnt - 1 blockcnt 3) {
int oldblk = blknr;
- int blocknxt;
+ int blocknxt = blknr;
while (i blockcnt - 1) {
blocknxt = ext2fs_read_block(node, i + 1);
if (blocknxt == (oldblk + 1)) {
--
1.7.10
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fs/ext2/ext2fs.c: fix warning
On Wed, Jun 27, 2012 at 01:47:51PM +0200, Andreas Bießmann wrote:
This patch fixes following warning:
---8---
ext2fs.c: In function 'ext2fs_read_file':
ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this
function [-Wuninitialized]
---8---
The warning was introduced in 436da3cd233e7166b5ce9293dbd28092cf37bcc9.
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
cc: Jason Cooper u-b...@lakedaemon.net
cc: Eric Nelson eric.nel...@boundarydevices.com
cc: Thierry Reding thierry.red...@avionic-design.de
---
fs/ext2/ext2fs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext2/ext2fs.c b/fs/ext2/ext2fs.c
index f1fce48..40b6e6f 100644
--- a/fs/ext2/ext2fs.c
+++ b/fs/ext2/ext2fs.c
@@ -440,7 +440,7 @@ int ext2fs_read_file
/* grab middle blocks in one go */
if (i != pos / blocksize i != blockcnt - 1 blockcnt 3) {
int oldblk = blknr;
- int blocknxt;
+ int blocknxt = blknr;
while (i blockcnt - 1) {
blocknxt = ext2fs_read_block(node, i + 1);
if (blocknxt == (oldblk + 1)) {
This doesn't look quite right. The warning should go away as well if you
change the i != blockcnt - 1 to i blockcnt - 1 in the condition
above. I think that'd be more appropriate, but perhaps Jason is better
qualified to comment.
Thierry
pgppNACCb0F19.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2 V2] Kirkwood: Add support for Ka-Ro TK71
Signed-off-by: Marek Vasut ma...@denx.de Cc: Prafulla Wadaskar prafu...@marvell.com Cc: Wolfgang Denk w...@denx.de --- board/karo/tk71/Makefile | 45 +++ board/karo/tk71/kwbimage.cfg | 174 ++ board/karo/tk71/tk71.c | 174 ++ boards.cfg |1 + include/configs/tk71.h | 130 +++ 5 files changed, 524 insertions(+) create mode 100644 board/karo/tk71/Makefile create mode 100644 board/karo/tk71/kwbimage.cfg create mode 100644 board/karo/tk71/tk71.c create mode 100644 include/configs/tk71.h V2: Enable hush parser diff --git a/board/karo/tk71/Makefile b/board/karo/tk71/Makefile new file mode 100644 index 000..934e391 --- /dev/null +++ b/board/karo/tk71/Makefile @@ -0,0 +1,45 @@ +# +# Copyright (C) 2012 Marek Vasut ma...@denx.de +# on behalf of DENX Software Engineering GmbH +# +# +# 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., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS := tk71.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(call cmd_link_o_target, $(OBJS) $(SOBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/karo/tk71/kwbimage.cfg b/board/karo/tk71/kwbimage.cfg new file mode 100644 index 000..0166826 --- /dev/null +++ b/board/karo/tk71/kwbimage.cfg @@ -0,0 +1,174 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com +# Written-by: Prafulla Wadaskar prafu...@marvell.com +# +# adopted to TK71 by +# Nils Faerber nils.faer...@kernelconcepts.de +# +# 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., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA +# +# Refer docs/README.kwimage for more details about how-to configure +# and create kirkwood boot image +# + +# Boot Media configurations +BOOT_FROM nand +NAND_ECC_MODE default +NAND_PAGE_SIZE 0x0800 + +# SOC registers configuration using bootrom header extension +# Maximum KWBIMAGE_MAX_CONFIG configurations allowed + +# Configure RGMII-0 interface pad voltage to 1.8V +DATA 0xFFD100e0 0x1b1b1b9b + +#Dram initalization for SINGLE x16 CL=5 @ 400MHz +DATA 0xFFD01400 0x43000c30 # DDR Configuration register +# bit13-0: 0xc30 (3120 DDR2 clks refresh rate) +# bit23-14: zero +# bit24: 1= enable exit self refresh mode on DDR access +# bit25: 1 required +# bit29-26: zero +# bit31-30: 01 + +DATA 0xFFD01404 0x36543000 # DDR Controller Control Low +# bit 4:0=addr/cmd in smame cycle +# bit 5:0=clk is driven during self refresh, we don't care for APX +# bit 6:0=use recommended falling edge of clk for addr/cmd +# bit14:0=input buffer always powered up +# bit18:1=cpu lock transaction enabled +# bit23-20: 5=recommended value for CL=5 and STARTBURST_DEL disabled bit31=0 +# bit27-24: 7= CL+2, STARTBURST sample stages, for freqs 400MHz, unbuffered DIMM +# bit30-28: 3 required +# bit31:0=no additional STARTBURST delay + +DATA 0xFFD01408 0x1101355b # DDR Timing (Low) (active cycles value +1) +# bit3-0: TRAS lsbs +# bit7-4: TRCD +# bit11- 8: TRP +# bit15-12: TWR +# bit19-16: TWTR +# bit20:TRAS msb +# bit23-21: 0x0 +# bit27-24: TRRD +# bit31-28: TRTP + +DATA
Re: [U-Boot] [PATCH] i.MX28: bug fixes in PMU configuration code
Dear Stathis Voukelatos,
Fixed some typos in the i.MX28 PMU code that sets up the VDDD
and VDDIO power rails. In addition the VDDD and VDDIO brownout
offset values should be divided by a step size before being
programmed to the corresponding registers.
Signed-off-by: Stathis Voukelatos stathis.voukela...@linn.co.uk
Cc: Stefano Babic sba...@denx.de
Cc: Marek Vasut marek.va...@gmail.com
Will test it ASAP. I should be getting new board by next week, so I'll test-
drive it on that one too.
Thanks for finding those!
---
arch/arm/cpu/arm926ejs/mx28/spl_power_init.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c index 4b09b0c..cc71af8
100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
@@ -716,7 +716,7 @@ int mx28_get_vddio_power_source_off(void)
tmp = readl(power_regs-hw_power_vddioctrl);
if (tmp POWER_VDDIOCTRL_DISABLE_FET) {
if ((tmp POWER_VDDIOCTRL_LINREG_OFFSET_MASK) ==
- POWER_VDDDCTRL_LINREG_OFFSET_0STEPS) {
+ POWER_VDDIOCTRL_LINREG_OFFSET_0STEPS) {
return 1;
}
}
@@ -724,7 +724,7 @@ int mx28_get_vddio_power_source_off(void)
if (!(readl(power_regs-hw_power_5vctrl)
POWER_5VCTRL_ENABLE_DCDC)) {
if ((tmp POWER_VDDIOCTRL_LINREG_OFFSET_MASK) ==
- POWER_VDDDCTRL_LINREG_OFFSET_0STEPS) {
+ POWER_VDDIOCTRL_LINREG_OFFSET_0STEPS) {
return 1;
}
}
@@ -772,7 +772,7 @@ void mx28_power_set_vddio(uint32_t new_target, uint32_t
new_brownout) uint32_t cur_target, diff, bo_int = 0;
uint32_t powered_by_linreg = 0;
- new_brownout = new_target - new_brownout;
+ new_brownout = (new_target - new_brownout + 25) / 50;
cur_target = readl(power_regs-hw_power_vddioctrl);
cur_target = POWER_VDDIOCTRL_TRG_MASK;
@@ -858,8 +858,8 @@ void mx28_power_set_vddio(uint32_t new_target, uint32_t
new_brownout) }
clrsetbits_le32(power_regs-hw_power_vddioctrl,
- POWER_VDDDCTRL_BO_OFFSET_MASK,
- new_brownout POWER_VDDDCTRL_BO_OFFSET_OFFSET);
+ POWER_VDDIOCTRL_BO_OFFSET_MASK,
+ new_brownout POWER_VDDIOCTRL_BO_OFFSET_OFFSET);
}
void mx28_power_set_vddd(uint32_t new_target, uint32_t new_brownout)
@@ -869,7 +869,7 @@ void mx28_power_set_vddd(uint32_t new_target, uint32_t
new_brownout) uint32_t cur_target, diff, bo_int = 0;
uint32_t powered_by_linreg = 0;
- new_brownout = new_target - new_brownout;
+ new_brownout = (new_target - new_brownout + 12) / 25;
cur_target = readl(power_regs-hw_power_vdddctrl);
cur_target = POWER_VDDDCTRL_TRG_MASK;
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] i.MX28: bug fixes in PMU configuration code
Fixed some typos in the i.MX28 PMU code that sets up the VDDD
and VDDIO power rails. In addition the VDDD and VDDIO brownout
offset values should be divided by a step size before being
programmed to the corresponding registers.
Signed-off-by: Stathis Voukelatos stathis.voukela...@linn.co.uk
Cc: Stefano Babic sba...@denx.de
Cc: Marek Vasut marek.va...@gmail.com
---
arch/arm/cpu/arm926ejs/mx28/spl_power_init.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
index 4b09b0c..cc71af8 100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
@@ -716,7 +716,7 @@ int mx28_get_vddio_power_source_off(void)
tmp = readl(power_regs-hw_power_vddioctrl);
if (tmp POWER_VDDIOCTRL_DISABLE_FET) {
if ((tmp POWER_VDDIOCTRL_LINREG_OFFSET_MASK) ==
- POWER_VDDDCTRL_LINREG_OFFSET_0STEPS) {
+ POWER_VDDIOCTRL_LINREG_OFFSET_0STEPS) {
return 1;
}
}
@@ -724,7 +724,7 @@ int mx28_get_vddio_power_source_off(void)
if (!(readl(power_regs-hw_power_5vctrl)
POWER_5VCTRL_ENABLE_DCDC)) {
if ((tmp POWER_VDDIOCTRL_LINREG_OFFSET_MASK) ==
- POWER_VDDDCTRL_LINREG_OFFSET_0STEPS) {
+ POWER_VDDIOCTRL_LINREG_OFFSET_0STEPS) {
return 1;
}
}
@@ -772,7 +772,7 @@ void mx28_power_set_vddio(uint32_t new_target, uint32_t
new_brownout)
uint32_t cur_target, diff, bo_int = 0;
uint32_t powered_by_linreg = 0;
- new_brownout = new_target - new_brownout;
+ new_brownout = (new_target - new_brownout + 25) / 50;
cur_target = readl(power_regs-hw_power_vddioctrl);
cur_target = POWER_VDDIOCTRL_TRG_MASK;
@@ -858,8 +858,8 @@ void mx28_power_set_vddio(uint32_t new_target, uint32_t
new_brownout)
}
clrsetbits_le32(power_regs-hw_power_vddioctrl,
- POWER_VDDDCTRL_BO_OFFSET_MASK,
- new_brownout POWER_VDDDCTRL_BO_OFFSET_OFFSET);
+ POWER_VDDIOCTRL_BO_OFFSET_MASK,
+ new_brownout POWER_VDDIOCTRL_BO_OFFSET_OFFSET);
}
void mx28_power_set_vddd(uint32_t new_target, uint32_t new_brownout)
@@ -869,7 +869,7 @@ void mx28_power_set_vddd(uint32_t new_target, uint32_t
new_brownout)
uint32_t cur_target, diff, bo_int = 0;
uint32_t powered_by_linreg = 0;
- new_brownout = new_target - new_brownout;
+ new_brownout = (new_target - new_brownout + 12) / 25;
cur_target = readl(power_regs-hw_power_vdddctrl);
cur_target = POWER_VDDDCTRL_TRG_MASK;
--
1.7.2.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [nand]: Hack to support 4k page in fsl_elbc_nand
Freescale FCM controller has a 2K size limitation of buffer RAM. In order
to support the Nand flash chip with pagesize larger than 2K bytes,
we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save
them to a large buffer.
Because of this, the in flash layout of the oob is different from the
default for 4096kiB page sizes. Therefore, we need to migrate the
factory bad block markers from the original position to the new layout.
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
Signed-off-by: Liu Shuo b35...@freescale.com
Signed-off-by: Rafael Beims rafael.be...@datacom.ind.br
---
drivers/mtd/nand/fsl_elbc_nand.c | 445 +++---
1 files changed, 417 insertions(+), 28 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 9076ad4..7393266 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -76,15 +76,17 @@ struct fsl_elbc_ctrl {
/* device info */
fsl_lbc_t *regs;
- u8 __iomem *addr;/* Address of assigned FCM buffer*/
- unsigned int page; /* Last page written to / read from */
- unsigned int read_bytes; /* Number of bytes read during command */
- unsigned int column; /* Saved column from SEQIN */
- unsigned int index; /* Pointer to next byte to 'read'*/
- unsigned int status; /* status read from LTESR after last op */
- unsigned int mdr;/* UPM/FCM Data Register value */
- unsigned int use_mdr;/* Non zero if the MDR is to be set */
- unsigned int oob;/* Non zero if operating on OOB data */
+ u8 __iomem *addr; /* Address of assigned FCM buffer */
+ unsigned int page; /* Last page written to / read from */
+ unsigned int read_bytes;/* Number of bytes read during command */
+ unsigned int column;/* Saved column from SEQIN */
+ unsigned int index; /* Pointer to next byte to 'read' */
+ unsigned int status;/* status read from LTESR after last op */
+ unsigned int mdr; /* UPM/FCM Data Register value */
+ unsigned int use_mdr; /* Non zero if the MDR is to be set */
+ unsigned int oob; /* Non zero if operating on OOB data*/
+ char *buffer; /* Just used when pagesize is greater */
+ /* than FCM RAM 2K limitation */
};
/* These map to the positions used by the FCM hardware ECC generator */
@@ -131,6 +133,15 @@ static struct nand_bbt_descr largepage_memorybased = {
.pattern = scan_ff_pattern,
};
+static u8 migrated_pattern[] = { 0xde, 0xad, 0xde, 0xad };
+static struct nand_bbt_descr largepage_migrated = {
+ .options = 0,
+ .offs = 1,
+ .len = 4,
+ .maxblocks = 3,
+ .pattern = migrated_pattern,
+};
+
/*
* ELBC may use HW ECC, so that OOB offsets, that NAND core uses for bbt,
* interfere with ECC positions, that's why we implement our own descriptors.
@@ -159,6 +170,35 @@ static struct nand_bbt_descr bbt_mirror_descr = {
.pattern = mirror_pattern,
};
+static void io_to_buffer(struct mtd_info *mtd, int subpage, int oob)
+{
+ struct nand_chip *chip = mtd-priv;
+ struct fsl_elbc_mtd *priv = chip-priv;
+ struct fsl_elbc_ctrl *ctrl = priv-ctrl;
+ void *src, *dst;
+ int len = oob ? 64 : 2048;
+
+ /* for emulating 4096+ bytes NAND using 2048-byte FCM RAM */
+ dst = ctrl-buffer + (oob ? mtd-writesize : 0) + subpage * len;
+ src = ctrl-addr + (oob ? 2048 : 0);
+ memcpy_fromio(dst, src, len);
+}
+
+static void buffer_to_io(struct mtd_info *mtd, int subpage, int oob)
+{
+ struct nand_chip *chip = mtd-priv;
+ struct fsl_elbc_mtd *priv = chip-priv;
+ struct fsl_elbc_ctrl *ctrl = priv-ctrl;
+ void *src, *dst;
+ int len = oob ? 64 : 2048;
+
+ src = ctrl-buffer + (oob ? mtd-writesize : 0) + subpage * len;
+ dst = ctrl-addr + (oob ? 2048 : 0);
+ memcpy_toio(dst, src, len);
+ /* See the in_8() in fsl_elbc_write_buf() */
+ in_8(ctrl-addr);
+}
+
/*=*/
/*
@@ -194,7 +234,7 @@ static void set_addr(struct mtd_info *mtd, int
column, int page_addr, int oob)
/* for OOB data point to the second half of the buffer */
if (oob)
- ctrl-index += priv-page_size ? 2048 : 512;
+ ctrl-index += mtd-writesize;
vdbg(set_addr: bank=%d, ctrl-addr=0x%p (0x%p),
index %x, pes %d ps %d\n,
@@ -256,13 +296,14 @@ static int fsl_elbc_run_command(struct mtd_info *mtd)
return ctrl-status == LTESR_CC ? 0 : -EIO;
}
-static void fsl_elbc_do_read(struct nand_chip *chip, int oob)
+static void fsl_elbc_do_read(struct mtd_info *mtd, int oob)
{
+ struct
Re: [U-Boot] [PATCH] mx28evk: Fix boot by adjusting HW_DRAM_CTL29 register
Hi Stefano, On Tue, Jun 19, 2012 at 6:12 PM, Marek Vasut ma...@denx.de wrote: Dear Fabio Estevam, commit acc4959fc1 (Revert i.MX28: Enable additional DRAM address bits) broke mx28evk boot. Fix it by properly adjusting the HW_DRAM_CTL29 register value. Suggested-by: Marek Vasut ma...@denx.de Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- board/freescale/mx28evk/iomux.c | 14 ++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/board/freescale/mx28evk/iomux.c Uh, why isn't this file called splboot.c? But Acked-by: Marek Vasut ma...@denx.de Could this one be applied? mx28evk does not boot without this patch. Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/1] fsl_elbc support for 4k devices and factory badblock migration
This is my implementation of the factory badblock migration process for the fsl_elbc driver using the hack to support nand devices with page sizes bigger than 2048k. The migrated pattern is in test mode. I really don't know what is the convention for something like this, and would like to hear suggestions of what this pattern should be. I would really appreciate any feedback related to the patch. Rafael Beims (1): [nand]: Hack to support 4k page in fsl_elbc_nand drivers/mtd/nand/fsl_elbc_nand.c | 445 +++--- 1 files changed, 417 insertions(+), 28 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Atmel : usb : add EHCI driver for Atmel SoC
Dear Andreas, In message 4feacd7e.8000...@gmail.com you wrote: AFAIR Reinhard gave up somewhere end of last year, in fact we currently have no at91 maintainer. I'm willing to step into at least for a while. My main aim is to get the latest Atmel patches into mainline for 2012.07, if Albert is willing to pull them (well less than 20 days left, and some of the patches where slightly after close of MW for 2012.07). ... Wolfgang and Albert, how do you think about? I am really glad you are volunteering - you close a pretty painful gap. Thanks a lot for your work in advance, it is highly appreciated. Your SSH key has been installed for both u-boot-atmel and u-boot-at91 so you should be able to start working. 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 A fractal is by definition a set for which the Hausdorff Besicovitch dimension strictly exceeds the topological dimension. - Mandelbrot, _The Fractal Geometry of Nature_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: AT91: add at91sam9x5ek board support
On 22.05.2012 12:06, Bo Shen wrote:
Add at91sam9x5ek board support.
support AT91SAM9G15, G25, G35, X25, X35 SoC
Signed-off-by: Bo Shen voice.s...@atmel.com
In general:
---8---
total: 14 errors, 11 warnings, 1148 lines checked
NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX
MULTISTATEMENT_MACRO_USE_DO_WHILE
/tmp/[PATCH] arm: AT91: add at91sam9x5ek board support.eml has style
problems, please review.
---8---
please fix these.
---
MAINTAINERS|3 +
arch/arm/cpu/arm926ejs/at91/Makefile |1 +
arch/arm/cpu/arm926ejs/at91/at91sam9x5_devices.c | 223 ++
arch/arm/cpu/arm926ejs/at91/clock.c|7 +-
arch/arm/include/asm/arch-at91/at91sam9_matrix.h |2 +
arch/arm/include/asm/arch-at91/at91sam9x5.h| 172 +++
arch/arm/include/asm/arch-at91/at91sam9x5_matrix.h | 91 ++
arch/arm/include/asm/arch-at91/hardware.h |2 +
board/atmel/at91sam9x5ek/Makefile | 48 +++
board/atmel/at91sam9x5ek/at91sam9x5ek.c| 323
board/atmel/at91sam9x5ek/config.mk |1 +
boards.cfg |1 +
drivers/net/macb.c |4 +-
include/configs/at91sam9x5ek.h | 216 +
14 files changed, 1090 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/cpu/arm926ejs/at91/at91sam9x5_devices.c
create mode 100644 arch/arm/include/asm/arch-at91/at91sam9x5.h
create mode 100644 arch/arm/include/asm/arch-at91/at91sam9x5_matrix.h
create mode 100644 board/atmel/at91sam9x5ek/Makefile
create mode 100644 board/atmel/at91sam9x5ek/at91sam9x5ek.c
create mode 100644 board/atmel/at91sam9x5ek/config.mk
create mode 100644 include/configs/at91sam9x5ek.h
diff --git a/MAINTAINERS b/MAINTAINERS
index e2441d8..cd8b8b5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -658,6 +658,9 @@ Sedji Gaouaousedji.gaou...@atmel.com
at91sam9g10ek ARM926EJS (AT91SAM9G10 SoC)
at91sam9m10g45ekARM926EJS (AT91SAM9G45 SoC)
+Bo Shen voice.s...@atmel.com
+ at91sam9x5ekARM926EJS (AT91SAM9X5 SoC)
+
Simon Guinot simon.gui...@sequanux.org
inetspace_v2ARM926EJS (Kirkwood SoC)
diff --git a/arch/arm/cpu/arm926ejs/at91/Makefile
b/arch/arm/cpu/arm926ejs/at91/Makefile
index f333753..346e58f 100644
--- a/arch/arm/cpu/arm926ejs/at91/Makefile
+++ b/arch/arm/cpu/arm926ejs/at91/Makefile
@@ -35,6 +35,7 @@ COBJS-$(CONFIG_AT91SAM9263) += at91sam9263_devices.o
COBJS-$(CONFIG_AT91SAM9RL) += at91sam9rl_devices.o
COBJS-$(CONFIG_AT91SAM9M10G45) += at91sam9m10g45_devices.o
COBJS-$(CONFIG_AT91SAM9G45) += at91sam9m10g45_devices.o
+COBJS-$(CONFIG_AT91SAM9X5) += at91sam9x5_devices.o
COBJS-$(CONFIG_AT91_EFLASH) += eflash.o
COBJS-$(CONFIG_AT91_LED) += led.o
COBJS-y += clock.o
diff --git a/arch/arm/cpu/arm926ejs/at91/at91sam9x5_devices.c
b/arch/arm/cpu/arm926ejs/at91/at91sam9x5_devices.c
new file mode 100644
index 000..e4262a5
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/at91/at91sam9x5_devices.c
@@ -0,0 +1,223 @@
+/*
+ * Copyright (C) 2012 Atmel Corporation
+ *
+ * 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 asm/arch/at91_common.h
+#include asm/arch/at91_pmc.h
+#include asm/arch/gpio.h
+#include asm/io.h
+
+#define AT91_CIDR_VERSION(0x1f 0) /* Version of the Device */
this should go into a header.
+
+unsigned int get_chip_id(void)
+{
+ return readl(ATMEL_BASE_DBGU + 0x40) ~AT91_CIDR_VERSION;
can we get some explanation of these magic numbers please (0x40 here and
0x44 later), maybe add these offsets to the header?
+
+}
+unsigned int get_extension_chip_id(void)
+{
+ return readl(ATMEL_BASE_DBGU + 0x44);
+}
+
+unsigned int has_emac1()
+{
+ return cpu_is_at91sam9x25();
+}
+unsigned int has_emac0()
+{
+ return !(cpu_is_at91sam9g15());
+}
+unsigned int has_lcdc()
+{
+ return cpu_is_at91sam9g15() || cpu_is_at91sam9g35()
+ || cpu_is_at91sam9x35();
+}
+
+char *get_cpu_name()
Re: [U-Boot] Is it possible to boot the U-boot from the another U-boot from the flash area
Dear Ishwar Saunshi, In message cakd3hysshg8+xnx1yqnvddlyqupgajc-lmg1qz32cy5ebm6...@mail.gmail.com you wrote: I am really curiuos to see if U-boot can boot another version or another Uboot burnt in flash ? Its like having 2 images of U-boot which can boot each other if it is possible can any one of you hint me how I can achive this. I tried to relocate the Uboot and burned on to the flash in 2 different loacation however when I try to do go U-boot effective address it ends up in TLB error in early stage of flash execution. In general, this is not possible. This topic is covered in the FAQ here: http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM 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 Out of register space (ugh) - vi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx28: Fix elftosb source link in README.mx28_common
Hi Marek,
Dear Anatolij Gustschin,
The documented link to elftosb package tarball is not accessible,
change to another working link.
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Marek Vasut marek.va...@gmail.com
Cc: Fabio Estevam feste...@gmail.com
---
doc/README.mx28_common |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/README.mx28_common b/doc/README.mx28_common
index 448d221..fab0e32 100644
--- a/doc/README.mx28_common
+++ b/doc/README.mx28_common
@@ -29,14 +29,14 @@ is the mxsboot tool found in U-Boot source tree.
Firstly, obtain the elftosb archive from the following location:
-http://foss.doredevelopment.dk/mirrors/imx/elftosb-10.12.01.tar.gz
+
http://repository.timesys.com/buildsources/e/elftosb/elftosb-10.12.01/elf
tosb-10.12.01.tar.gz
We use a $VER variable here to denote the current version. At the time of
writing of this document, that is 10.12.01. To obtain the file from
command line, use:
$ VER=10.12.01
-$ wget http://foss.doredevelopment.dk/mirrors/imx/elftosb-${VER}.tar.gz
+$ wget
http://repository.timesys.com/buildsources/e/elftosb/elftosb-${VER}/elftos
b-${VER}.tar.gz
Extract the file:
That's sad, maybe we should mirror this package and be done with it?
Wolfgang/Detlev?
Somewhat late, but still the file can now also be found here:
ftp://ftp.denx.de/pub/tools/elftosb-10.12.01.tar.gz
Cheers
Detlev
--
Music scenes ain't real life / They won't get rid of the bomb
Won't eliminate rape / Or bring down the banks / any kind of change
Takes more time and work / than changing channels on a TV set
-- Jello Biafra
--
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
Re: [U-Boot] ARM CONFIG_OF_CONTROL status
Hi, On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek mon...@monstr.eu wrote: Hi, can you please update me about current state of CONFIG_OF_CONTROL for ARM? Are there any other archs/boards which will use this option? Or any other git repo out of mainline u-boot? Exynos is in progress - development is happening in the Chromium tree and being upstreamed in chunks (although no fdt patches have been sent yet). Has someone tried to look for devices based on compatible property? I see that in usb driver it is based on aliases which is not the best solution. U-Boot doesn't yet have a device model which would allow this in the general case. For now, drivers look for their own compatible nodes. This works well enough until we have a device model. There are other limitations also - for example USB supports only a single controller type working at one time (a restriction we may need to look at to support USB2 and USB3 together). So even if two USB drivers decided that they both found compatible nodes, only one of them could operate. So for now aliases provide just an ordering, nothing else. Regards, Simon 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] mx28: Fix elftosb source link in README.mx28_common
Hi Detlev, On Wed, 27 Jun 2012 15:54:40 +0200 Detlev Zundel d...@denx.de wrote: ... That's sad, maybe we should mirror this package and be done with it? Wolfgang/Detlev? Somewhat late, but still the file can now also be found here: ftp://ftp.denx.de/pub/tools/elftosb-10.12.01.tar.gz Thanks! I'll resend updated patch soon. Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2 2/2] AT91: at91sam9m10g45ek : Enable EHCI instead OHCI
On 26.06.2012 04:21, Bo Shen wrote: Enable EHCI support instead OHCI Signed-off-by: Bo Shen voice.s...@atmel.com I have no style objections. Marek, would you take this and apply it in your usb tree (to have the providing code and user side by side) or should I take it? Acked-by: Andreas Bießmann andreas.de...@googlemail.com --- include/configs/at91sam9m10g45ek.h | 20 +++- 1 file changed, 3 insertions(+), 17 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2 2/2] AT91: at91sam9m10g45ek : Enable EHCI instead OHCI
Dear Andreas Bießmann, On 26.06.2012 04:21, Bo Shen wrote: Enable EHCI support instead OHCI Signed-off-by: Bo Shen voice.s...@atmel.com I have no style objections. Marek, would you take this and apply it in your usb tree (to have the providing code and user side by side) or should I take it? Acked-by: Andreas Bießmann andreas.de...@googlemail.com Take it --- include/configs/at91sam9m10g45ek.h | 20 +++- 1 file changed, 3 insertions(+), 17 deletions(-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] mx28: Fix elftosb source link in README.mx28_common
The documented link to elftosb package tarball is not accessible,
change to another working link.
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Marek Vasut marek.va...@gmail.com
Cc: Fabio Estevam feste...@gmail.com
Acked-by: Otavio Salvador ota...@ossystems.com.br
---
v2:
- change package src url from timesys to DENX ftp
doc/README.mx28_common |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/README.mx28_common b/doc/README.mx28_common
index 448d221..bdd11e7 100644
--- a/doc/README.mx28_common
+++ b/doc/README.mx28_common
@@ -29,14 +29,14 @@ is the mxsboot tool found in U-Boot source tree.
Firstly, obtain the elftosb archive from the following location:
- http://foss.doredevelopment.dk/mirrors/imx/elftosb-10.12.01.tar.gz
+ ftp://ftp.denx.de/pub/tools/elftosb-10.12.01.tar.gz
We use a $VER variable here to denote the current version. At the time of
writing of this document, that is 10.12.01. To obtain the file from command
line, use:
$ VER=10.12.01
- $ wget http://foss.doredevelopment.dk/mirrors/imx/elftosb-${VER}.tar.gz
+ $ wget ftp://ftp.denx.de/pub/tools/elftosb-${VER}.tar.gz
Extract the file:
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] MPC8641HPVN saveenv, newstart u-boot stops
MPC8641HPVN saveenv, newstart u-boot stops Hi All, ich used the board freescale HPCN8641D board with nwest u-boot. only after saveenv and following power off and on, u-boot stops directly without serial output. Because analyse ich have seen: The command saveenv writes environment variable directy the code-area from u-boot(flash). I thing, the hard coded offset to flash environment variable after the .text area in the flash is to be small actually. I give some informations: Power PC MPC8641D Flash area u-boot: version_string: 0xeff4 __bss_end__ 0xeff7a360 size = 0x7a360 In command saveenv...env_flash.c Routine saveenv if (flash_sect_erase((long)flash_addr, end_addr)) used following addresses: flash_addr = 0xeff6 end_addr = 0xeff6 static env_t *flash_addr = (env_t *)CONFIG_ENV_ADDR; File MPC8641HPCN.h #ifndef CONFIG_SYS_RAMBOOT #define CONFIG_ENV_IS_IN_FLASH 1 #define CONFIG_ENV_ADDR (CONFIG_SYS_MONITOR_BASE + 0x6) #define CONFIG_ENV_SECT_SIZE0x1 /* 64K(one sector) for env */ #else #define CONFIG_ENV_IS_NOWHERE 1 /* Store ENV in memory only */ #define CONFIG_ENV_ADDR (CONFIG_SYS_MONITOR_BASE - 0x1000) #endif #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE/* start of monitor */ #define CONFIG_SYS_TEXT_BASE0xeff0 I thing the constand with 0x6 is to small (u-boot size is bigger) For my test I have changed 0x6 into 0x7 #define CONFIG_ENV_ADDR (CONFIG_SYS_MONITOR_BASE + 0x7) Can someone evaluate this analysis? Thanks for the Help. Thiesen -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM CONFIG_OF_CONTROL status
Hi Simon,
On 06/27/2012 03:58 PM, Simon Glass wrote:
Hi,
On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek mon...@monstr.eu
mailto:mon...@monstr.eu wrote:
Hi,
can you please update me about current state of CONFIG_OF_CONTROL for ARM?
Are there any other archs/boards which will use this option?
Or any other git repo out of mainline u-boot?
Exynos is in progress - development is happening in the Chromium tree and being
upstreamed in chunks (although no fdt patches have been sent yet).
ok.
Has someone tried to look for devices based on compatible property?
I see that in usb driver it is based on aliases which is not the best
solution.
U-Boot doesn't yet have a device model which would allow this in the general
case. For now, drivers look for their own compatible nodes. This works well
enough until we have a device model.
There are other limitations also - for example USB supports only a single
controller type working at one time (a restriction we may need to look at to
support USB2 and USB3 together). So even if two USB drivers decided that they
both found compatible nodes, only one of them could operate. So for now aliases
provide just an ordering, nothing else.
I have looked at the code and did some tests on Microblaze.
Firstly I have tried to change emaclite ethernet initialization and I ended
with this code fragment which could be
broadly used by other drivers.
int offset = 0;
do {
offset = fdt_node_offset_by_compatible(gd-fdt_blob, offset,
xlnx,xps-ethernetlite-1.00.a );
u32 rxpp = fdtdec_get_int(gd-fdt_blob, offset,
xlnx,rx-ping-pong, 0);
u32 txpp = fdtdec_get_int(gd-fdt_blob, offset,
xlnx,tx-ping-pong, 0);
u32 reg = fdtdec_get_int(gd-fdt_blob, offset, reg, 0);
if (reg)
ret |= xilinx_emaclite_initialize(bis, reg, txpp, rxpp);
} while (offset != -1);
What do you think? This code is in platform file.
Also I have tested code around aliases which parse DTS aliases list for console
initialization
and I have also get it work for !CONSOLE_SERIAL_MULTI case.
What was the reason to use compat_names table in fdtdec.c file?
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] mx28: Fix elftosb source link in README.mx28_common
Hi Anatolij, The documented link to elftosb package tarball is not accessible, change to another working link. Signed-off-by: Anatolij Gustschin ag...@denx.de Cc: Otavio Salvador ota...@ossystems.com.br Cc: Marek Vasut marek.va...@gmail.com Cc: Fabio Estevam feste...@gmail.com Acked-by: Otavio Salvador ota...@ossystems.com.br Acked-by: Detlev Zundel d...@denx.de Thanks Anatolij! Detlev -- Man is a fool, and woman, for tolerating him, is a damned fool -- Mark Twain -- 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] sha256_crypt for uboot
Hello, I am working on a project to allow uboot to authenticate users by using the same sha256_crypt function that Linux user-space use for libcrypt [ref] http://www.akkadia.org/drepper/SHA-crypt.txt We chose sha256 because uboot already have support for doing sha256 hashes, I am wondering about a few things: 1. Has this been attempted before? 2. If I want to make a test command for a proof of concept using crypt(), how do I modify the Makefile to allow a command to statically link to libcrypt? hacking it into the Makefile's $(PLATFORM_LIBS)? 3. Once I am done porting sha256_crypt to use it using the facilities uboot has, is there any hope of getting this mainlined when I am done? If there is a policy to not unnecessarily add crypto algorithm, then I'll just keep it all in one file to reduce risk of merge conflict. If there is interest to mainline this, then I'll stage the supporting functions that uboot does not have yet (mempcpy, stpcpy, etc) into separate files. Thank you for everyone's time -- Richard Retanubun ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] davinci, c6x: Always use C version of reset code
We can safely use the same reset code written in C for both Davinci and
C6X platforms. In addition the C version of the code is marginally
smaller on Davinci.
Tested-by: Matt Porter mpor...@ti.com
Signed-off-by: Tom Rini tr...@ti.com
---
arch/arm/cpu/arm926ejs/davinci/Makefile |9 +---
arch/arm/cpu/arm926ejs/davinci/reset.S | 81 --
arch/arm/cpu/arm926ejs/davinci/reset.c | 32
arch/arm/cpu/arm926ejs/davinci/reset_c.c | 32
4 files changed, 33 insertions(+), 121 deletions(-)
delete mode 100644 arch/arm/cpu/arm926ejs/davinci/reset.S
create mode 100644 arch/arm/cpu/arm926ejs/davinci/reset.c
delete mode 100644 arch/arm/cpu/arm926ejs/davinci/reset_c.c
diff --git a/arch/arm/cpu/arm926ejs/davinci/Makefile
b/arch/arm/cpu/arm926ejs/davinci/Makefile
index 54f096d..c91928e 100644
--- a/arch/arm/cpu/arm926ejs/davinci/Makefile
+++ b/arch/arm/cpu/arm926ejs/davinci/Makefile
@@ -27,7 +27,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(SOC).o
-COBJS-y+= cpu.o misc.o timer.o psc.o pinmux.o
+COBJS-y+= cpu.o misc.o timer.o psc.o pinmux.o
reset.o
COBJS-$(CONFIG_DA850_LOWLEVEL) += da850_lowlevel.o
COBJS-$(CONFIG_SOC_DM355) += dm355.o
COBJS-$(CONFIG_SOC_DM365) += dm365.o
@@ -42,13 +42,6 @@ COBJS-$(CONFIG_SOC_DM365)+= dm365_lowlevel.o
COBJS-$(CONFIG_SOC_DA8XX) += da850_lowlevel.o
endif
-
-ifeq ($(CPU),c674x)
-COBJS-y+= reset_c.o
-else
-SOBJS = reset.o
-endif
-
ifndef CONFIG_SKIP_LOWLEVEL_INIT
SOBJS += lowlevel_init.o
endif
diff --git a/arch/arm/cpu/arm926ejs/davinci/reset.S
b/arch/arm/cpu/arm926ejs/davinci/reset.S
deleted file mode 100644
index ba0a7c3..000
--- a/arch/arm/cpu/arm926ejs/davinci/reset.S
+++ /dev/null
@@ -1,81 +0,0 @@
-/*
- * Processor reset using WDT for TI TMS320DM644x SoC.
- *
- * Copyright (C) 2007 Sergey Kubushyn k...@koi8.net
- *
- * -
- *
- * 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
- */
-
-.globl reset_cpu
-reset_cpu:
- ldr r0, WDT_TGCR
- mov r1, $0x08
- str r1, [r0]
- ldr r1, [r0]
- orr r1, r1, $0x03
- str r1, [r0]
- mov r1, $0
- ldr r0, WDT_TIM12
- str r1, [r0]
- ldr r0, WDT_TIM34
- str r1, [r0]
- ldr r0, WDT_PRD12
- str r1, [r0]
- ldr r0, WDT_PRD34
- str r1, [r0]
- ldr r0, WDT_TCR
- ldr r1, [r0]
- orr r1, r1, $0x40
- str r1, [r0]
- ldr r0, WDT_WDTCR
- ldr r1, [r0]
- orr r1, r1, $0x4000
- str r1, [r0]
- ldr r1, WDTCR_VAL1
- str r1, [r0]
- ldr r1, WDTCR_VAL2
- str r1, [r0]
- /* Write an invalid value to the WDKEY field to trigger
-* an immediate watchdog reset */
- mov r1, $0x4000
- str r1, [r0]
- nop
- nop
- nop
- nop
-reset_cpu_loop:
- b reset_cpu_loop
-
-WDT_TGCR:
- .word 0x01c21c24
-WDT_TIM12:
- .word 0x01c21c10
-WDT_TIM34:
- .word 0x01c21c14
-WDT_PRD12:
- .word 0x01c21c18
-WDT_PRD34:
- .word 0x01c21c1c
-WDT_TCR:
- .word 0x01c21c20
-WDT_WDTCR:
- .word 0x01c21c28
-WDTCR_VAL1:
- .word 0xa5c64000
-WDTCR_VAL2:
- .word 0xda7e4000
diff --git a/arch/arm/cpu/arm926ejs/davinci/reset.c
b/arch/arm/cpu/arm926ejs/davinci/reset.c
new file mode 100644
index 000..44ae364
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/davinci/reset.c
@@ -0,0 +1,32 @@
+/*
+ * Processor reset using WDT.
+ *
+ * Copyright (C) 2012 Dmitry Bondar b...@inmys.ru
+ * Copyright (C) 2007 Sergey Kubushyn k...@koi8.net
+ *
+ * This file is released under the terms of GPL v2 and any later version.
+ * See the file COPYING in the root directory of the source tree for details.
+*/
+
+#include common.h
+#include asm/io.h
+#include asm/arch/timer_defs.h
+
+void reset_cpu(unsigned long a)
+{
+ struct davinci_timer *const wdttimer =
+ (struct davinci_timer *)DAVINCI_TIMER1_BASE;
+ writel(0x08, wdttimer-tgcr);
+ writel(readl(wdttimer-tgcr) | 0x03, wdttimer-tgcr);
+ writel(0, wdttimer-tim12);
+
Re: [U-Boot] [PATCH] davinci, c6x: Always use C version of reset code
On Wed, Jun 27, 2012 at 08:27:05AM -0700, Tom Rini wrote: We can safely use the same reset code written in C for both Davinci and C6X platforms. In addition the C version of the code is marginally smaller on Davinci. Tested-by: Matt Porter mpor...@ti.com Signed-off-by: Tom Rini tr...@ti.com In the next go-round of the c6x patches please just fold this (and the tested-by) into the patch you add that creates the C version of the reset code. Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] USB: EHCI: Initialize multiple USB controllers at once
On 06/27/2012 12:55 AM, Wolfgang Denk wrote: Dear Jim Lin, sending the very same message eight (8!) times doesnot make it a bit more convincing - on contrary. In message 4b9c9637d5087840a465bdcb251780e9e2d6eda...@hkmail02.nvidia.com you wrote: U-Boot is not multi-tasking, so you can always access only a single USB device at a time ayway. And it is a decoumented design principle that U-Boot must not initialize any devices it does not use itself. So why? Because of this complaint and request for devices under different controllers to be working at same time. You make another claim here, but don't explain how this is supposed to work or whay the exact use case would be where this was needed. U-Boot will not be able to access multiple devices at the same time, so why would it be necessary to enable these? It should be sufficient to enable the controller that is responsible for the single device that is currently being used. One particularly annoying consequence of this is when you use the Seaboard configuration on Springbank. Seaboard selects Tegra's USB3 as usb 0 device, which is the one you can use, in order not to conflict with the flashing USB port USB1. However, Springbank only exposes USB1 since USB3 is used internally for the USB keyboard/mouse. As such, you cannot use the USB port on Springbank under U-Boot at the moment. I have to admit that I cannot make any sense from this statement. The only thing I understand is that you are trying to use a configuration for one hardware (Seaboard) on another, incompatible hardware (Springbank). The simple answer to this problem is: don't do that, then. Seaboard and Springbank are essentially the same board, and hence are almost 100% SW compatible, so there's no problem running a Seaboard build of U-Boot/kernel/... on Springbank. The primary issue here is that many boards have multiple USB ports. Users could plug e.g. a USB-Ethernet device into any of the ports. Requiring the user to know which port is which ID so they can issue the correct usb start n command is painful; no other SW stack limits itself to a single port and so most people don't have a clue which ports are numbered what; they just want USB to work. The specific issue on Springbank is that there are multiple USB ports that are useful at the essentially the same time. One of the USB ports hosts a built-in USB keyboard (inside a sealed clamshell/netbook case), which we would like to use for the U-boot console. Another USB port is external, and people will plug in a USB-Ethernet dongle or USB storage device there. so, if I need to usb start 0 to get the keyboard, and usb start 1 to get USB Ethernet, then as soon as I usb start 1 to get the Ethernet, I've just lost the console, and am unable to interact with U-Boot any more... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] AM335x : Add USB support for AM335x in u-boot
On Tue, Jun 26, 2012 at 03:08:01PM +0530, Harman Sohanpal wrote: From: Gene Zarkhin gene_zark...@bose.com Adds USB support in uboot for AM335x. By default the USB 1 module is enabled. The support for USB 0 can be enabled by changing the USB base address and the phy control register address in the header file am335x.h. USB 1 has a full size connector so acts in host mode and USB 0 has a mini connector so used in device mode. By default, the support is added for host mode hence USB 1 has been enabled by default. Signed-off-by: Gene Zarkhin gene_zark...@bose.com Signed-off-by: Harman Sohanpal harman_sohan...@ti.com What I was saying was that we want to make am335x.h do: #define AM335X_USB0_BASE 0x47401000 #define AM335X_USB1_BASE 0x47401800 Then: #ifdef CONFIG_AM335X_USB0 #define AM335X_USB_OTG_BASE AM335X_USB0_BASE #elif defined(CONFIG_AM335X_USB1) #define AM335X_USB_OTG_BASE AM335X_USB1_BASE #endif #define AM335X_USB_OTG_CORE_BASE (AM335X_USB_OTG_BASE + 0x400) So that in boards.cfg we could add an entry for am335x_evm_usb1 and set CONFIG_AM335X_USB1 dynamically. Then in am335x_evm.h set either MUSB_HCD or MUSB_UDC based on if CONFIG_AM335X_USB0 or CONFIG_AM335X_USB1 is set (and have boards.cfg set CONFIG_AM335X_USB0 for 'am335x_evm). Then you can test device mode on the evm :) And how did you test device mode on the beaglebone? I couldn't since I don't have the rest set of adapters here. Also: +++ b/drivers/usb/musb/am335x.h [snip] +/* Control Module Registers */ +#define CM_REGISTERS CTRL_BASE +#define USB_CTRL0_REG_OFFSET (0x628) +#define USB_CTRL1_REG_OFFSET (0x680) Please get all indentation out to a consistent level +#define PRCM_IDLEST 0x3 +#define DPLL_CLKDCOLDO_GATE_CTRL0x300 And always use tabs :) -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] bcm: Add GPIO driver for BCM2835 SoC
Hello Stephen, On 6/27/2012 7:09 AM, Stephen Warren wrote: On 06/24/2012 11:21 AM, Vikram Narayanan wrote: First off, it's great to see some patches for the chip. Thanks. Sorry for being so nit-picky below; it's a tendency of mine... Thanks for the detailed review. I'd make a v2 for this. And I might probably include you in the signed-off-by line. Hope you don't mind that. Do you have a hosted repo somewhere for this rpi_b stuff? If so, please post it here or we shall have one, which has all the patches queued in for the mainline. What do you say? Share your opinions about this. BTW, I don't think this patch compiles; gpio_set_value() references variable pin, which doesn't exist. Sorry about that, Late night submission! Thanks, Vikram ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: bugfix: save_boot_params_default accesses uninitalized stack when -O0
On Mon, Jun 25, 2012 at 09:42:29PM +0900, Tetsuyuki Kobayashi wrote:
save_boot_params_default() in cpu.c accesses uninitialized stack area
when it compiled with -O0 (not optimized).
Signed-off-by: Tetsuyuki Kobayashi k...@kmckk.co.jp
---
arch/arm/cpu/armv7/cpu.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/cpu/armv7/cpu.c b/arch/arm/cpu/armv7/cpu.c
index c6fa8ef..6104cb2 100644
--- a/arch/arm/cpu/armv7/cpu.c
+++ b/arch/arm/cpu/armv7/cpu.c
@@ -37,8 +37,11 @@
#include asm/cache.h
#include asm/armv7.h
+__attribute__((naked)) /* don't save anything to stack even if compiled with
-O0 */
void save_boot_params_default(u32 r0, u32 r1, u32 r2, u32 r3)
{
+ /* stack is not yet initialized */
+ asm(bx lr);
}
Please add linux/compiler.h and use __naked instead. Thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] mtd/spi: add sst25l driver
On Tue, Jun 26, 2012 at 02:33:13PM +0400, Mikhail Kshevetskiy wrote: current SST driver does not support well this types of flash, so use linux-3.3 code as a base. Signed-off-by: Mikhail Kshevetskiy mikhail.kshevets...@gmail.com The correct form here is to say: Backport from Linux commit If this is from the 3.3 release please say that clearly. Thanks! -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] bcm: Add GPIO driver for BCM2835 SoC
On 06/27/2012 11:32 AM, Vikram Narayanan wrote: Hello Stephen, On 6/27/2012 7:09 AM, Stephen Warren wrote: On 06/24/2012 11:21 AM, Vikram Narayanan wrote: First off, it's great to see some patches for the chip. Thanks. Sorry for being so nit-picky below; it's a tendency of mine... Thanks for the detailed review. I'd make a v2 for this. And I might probably include you in the signed-off-by line. Hope you don't mind that. No, you shouldn't add any tags to the patch that refer to other people, except perhaps a Reported-By, without their explicitly giving those tags. Also, Signed-off-by wouldn't make sense here since I'm not vouching for the code or passing it along. Once V2 is posted, I may give an ack or review tag. Do you have a hosted repo somewhere for this rpi_b stuff? If so, please post it here or we shall have one, which has all the patches queued in for the mainline. What do you say? Share your opinions about this. I do have a repo. It's at: https://github.com/swarren/u-boot However, that's my personal work-space. The RPi patches should eventually make it into the official U-Boot repositories through the standard review process. They are: ARM repo: git://git.denx.de/u-boot-arm.git Main repo: git://git.denx.de/u-boot.git ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: bugfix: Move vector table before jumping relocated code
On Mon, Jun 25, 2012 at 09:40:57PM +0900, Tetsuyuki Kobayashi wrote: Interrupts and exceptions doesn't work in relocated code. It badly use IRQ_STACK_START_IN in rom area as interrupt stack. It is because the vecotr table is not moved to ram area. This patch moves vector table before jumping relocated code. Signed-off-by: Tetsuyuki Kobayashi k...@kmckk.co.jp --- arch/arm/cpu/armv7/start.S | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 52f7f6e..5098f7b 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -277,6 +277,18 @@ jump_2_ram: mcr p15, 0, r0, c7, c10, 4 @ DSB mcr p15, 0, r0, c7, c5, 4 @ ISB #endif +/* + * Move vector table + */ +#if !defined(CONFIG_TEGRA2) +#if !(defined(CONFIG_OMAP44XX) defined(CONFIG_SPL_BUILD)) + /* Set vector address in CP15 VBAR register */ + ldr r0, =_start + add r0, r0, r9 + mcr p15, 0, r0, c12, c0, 0 @Set VBAR +#endif +#endif /* !Tegra2 */ + ldr r0, _board_init_r_ofs adr r1, _start add lr, r0, r1 I think this code should get boot tested on a few platforms to make sure it's OK. As such, I've tried on am335x and omap3 and they're still fine. Tested-by: Tom Rini tr...@ti.com -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/3] Bug fixes for LaCie devices
On Thu, Jun 14, 2012 at 08:18:33AM -0700, Prafulla Wadaskar wrote: -Original Message- From: Simon Guinot [mailto:si...@sequanux.org] Sent: 14 June 2012 20:41 To: Simon Guinot Cc: Prafulla Wadaskar; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH v2 0/3] Bug fixes for LaCie devices On Wed, Jun 06, 2012 at 01:15:57AM +0200, Simon Guinot wrote: This patch series provides bug fixes for LaCie devices (mostly for Internet Space v2 and 2Big Network v2). Changes for v2: - Move bug fixes into a separate patch set. Simon Guinot (3): lacie_kw: fix SDRAM banks number for net2big_v2 lacie_kw: fix CONFIG_SYS_KWD_CONFIG for inetspace_v2 ARM: don't probe PHY address for LaCie boards board/LaCie/common/common.c | 23 +++--- - board/LaCie/common/common.h |2 +- board/LaCie/edminiv2/edminiv2.c |2 +- board/LaCie/net2big_v2/net2big_v2.c |2 +- board/LaCie/netspace_v2/netspace_v2.c |2 +- include/configs/lacie_kw.h|6 +- 6 files changed, 12 insertions(+), 25 deletions(-) Hi Prafulla, Please could you pick this patches ? Sure, I will do it. Hopefully by tomorrow Please could you pick my two patch series ? Thanks. Simon signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] tegra: add GMC/GMD funcmux entry for SFLASH
Stephen,
-Original Message-
From: Stephen Warren [mailto:swar...@wwwdotorg.org]
Sent: Tuesday, June 12, 2012 11:34 AM
To: Tom Warren
Cc: u-boot@lists.denx.de; Stephen Warren
Subject: [PATCH 1/3] tegra: add GMC/GMD funcmux entry for SFLASH
This series (3 patches) has been applied to u-boot-tegra/master. Thanks!
Tom
From: Stephen Warren swar...@nvidia.com
This is used on TrimSlice.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
arch/arm/cpu/armv7/tegra2/funcmux.c| 10 ++
arch/arm/include/asm/arch-tegra2/funcmux.h |3 +++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/tegra2/funcmux.c
b/arch/arm/cpu/armv7/tegra2/funcmux.c
index 455d010..4a31a4c 100644
--- a/arch/arm/cpu/armv7/tegra2/funcmux.c
+++ b/arch/arm/cpu/armv7/tegra2/funcmux.c
@@ -224,6 +224,16 @@ int funcmux_select(enum periph_id id, int config)
}
break;
+ case PERIPH_ID_SPI1:
+ if (config == FUNCMUX_SPI1_GMC_GMD) {
+ pinmux_set_func(PINGRP_GMC, PMUX_FUNC_SFLASH);
+ pinmux_set_func(PINGRP_GMD, PMUX_FUNC_SFLASH);
+
+ pinmux_tristate_disable(PINGRP_GMC);
+ pinmux_tristate_disable(PINGRP_GMD);
+ }
+ break;
+
default:
debug(%s: invalid periph_id %d, __func__, id);
return -1;
diff --git a/arch/arm/include/asm/arch-tegra2/funcmux.h
b/arch/arm/include/asm/arch-tegra2/funcmux.h
index 3cbc7d2..dcd512f 100644
--- a/arch/arm/include/asm/arch-tegra2/funcmux.h
+++ b/arch/arm/include/asm/arch-tegra2/funcmux.h
@@ -54,6 +54,9 @@ enum {
/* USB configs */
FUNCMUX_USB2_ULPI = 0,
+
+ /* Serial Flash configs */
+ FUNCMUX_SPI1_GMC_GMD = 0,
};
/**
--
1.7.0.4
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/1] tegra: usb: Fix device enumeration problem of USB1
Jim,
-Original Message-
From: Jim Lin
Sent: Sunday, June 24, 2012 11:41 PM
To: 'u-boot@lists.denx.de'
Cc: Tom Warren; Marek Vasut; 'Stephen Warren'
Subject: [PATCH v5 1/1] tegra: usb: Fix device enumeration problem of USB1
This patch has been applied to u-boot-tegra/master. Thanks!
Tom
A known hardware issue of USB1 port where bit 1 (connect status
change) of PORTSC register will be set after issuing Port Reset (like usb
reset in u-boot command line).
This will be treated as an error and stops later device enumeration.
Therefore we clear that bit after Port Reset in order to proceed later
device enumeration.
Signed-off-by: Jim Lin ji...@nvidia.com
---
To reproduce this issue, you can modify board .dts file to set as the
following to build u-boot binary.
usb0 = /usb@c500;
usb1 = /usb@c5008000;
Install device on USB1 port (address at 0xc500).
And run usb reset in u-boot console to enumerate device.
Before adding this patch, we could see problem every time.
After adding, tried 10 times of usb reset, usb tree, usb stop
, without seeing issue.
Changes in v5:
- Define USB address mask value in header file
Changes in v4:
- Add comment to describe replacing weak function ehci_powerup_fixup of
ehci-hcd.c
- Remove using variable my_reg
Changes in v3:
- Move patch for USB1 controller into ehci_powerup_fixup of ehci-tegra.c
- Update copyright year to 2012
Changes in v2:
- Change config name
- Add a callback function at the end of ehci_submit_root() function
arch/arm/include/asm/arch-tegra2/tegra2.h |1 +
drivers/usb/host/ehci-tegra.c | 18 +-
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/arch-tegra2/tegra2.h
b/arch/arm/include/asm/arch-tegra2/tegra2.h
index d4ada10..710334b 100644
--- a/arch/arm/include/asm/arch-tegra2/tegra2.h
+++ b/arch/arm/include/asm/arch-tegra2/tegra2.h
@@ -45,6 +45,7 @@
#define NV_PA_CSITE_BASE 0x7004
#define TEGRA_USB1_BASE 0xC500
#define TEGRA_USB3_BASE 0xC5008000
+#define TEGRA_USB_ADDR_MASK 0xC000
#define TEGRA2_SDRC_CS0 NV_PA_SDRAM_BASE
#define LOW_LEVEL_SRAM_STACK 0x4000FFFC
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index a7e105b..4646b29 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2009 NVIDIA Corporation
+ * Copyright (c) 2009-2012 NVIDIA Corporation
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -29,6 +29,22 @@
#include asm/errno.h
#include asm/arch/usb.h
+/*
+ * A known hardware issue where Connect Status Change bit of PORTSC
+register
+ * of USB1 controller will be set after Port Reset.
+ * We have to clear it in order for later device enumeration to proceed.
+ * This ehci_powerup_fixup overrides the weak function
+ehci_powerup_fixup
+ * in ehci-hcd.c.
+ */
+void ehci_powerup_fixup(uint32_t *status_reg, uint32_t *reg) {
+ mdelay(50);
+ if (((u32) status_reg TEGRA_USB_ADDR_MASK) != TEGRA_USB1_BASE)
+ return;
+ /* For EHCI_PS_CSC to be cleared in ehci_hcd.c */
+ if (ehci_readl(status_reg) EHCI_PS_CSC)
+ *reg |= EHCI_PS_CSC;
+}
/*
* Create the appropriate control structures to manage
--
1.7.3
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] BOOT: Fix unused variable issue when enabling bootz support
Stephen,
-Original Message-
From: Stephen Warren [mailto:swar...@wwwdotorg.org]
Sent: Wednesday, June 13, 2012 12:55 PM
To: Tom Warren
Cc: u-boot@lists.denx.de; Stephen Warren; Marek Vasut; Wolfgang Denk
Subject: [PATCH 1/3] BOOT: Fix unused variable issue when enabling bootz
support
This series (3 patches) has been applied to u-boot-tegra/master. Thanks!
Tom
From: Stephen Warren swar...@nvidia.com
cmd_bootm.c: In function 'do_bootz':
cmd_bootm.c:1590:9: warning: variable 'iflag' set but not used [-Wunused-
but-set-variable]
Cc: Marek Vasut marek.va...@gmail.com
Cc: Wolfgang Denk w...@denx.de
Signed-off-by: Stephen Warren swar...@nvidia.com
---
I think this is best taken through the Tegra tree, since it's needed to
avoid introducing warnings when enabling CONFIG_CMD_BOOTZ, which the next
patch enables, and we don't want MAKEALL -s tegra2 to suddenly start giving
warnings.
---
common/cmd_bootm.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index 5685232..45e726a
100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -1587,7 +1587,6 @@ static int bootz_start(cmd_tbl_t *cmdtp, int flag, int
argc,
static int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char * const
argv[]) {
- ulong iflag;
bootm_headers_t images;
if (bootz_start(cmdtp, flag, argc, argv, images)) @@ -1598,7 +1597,7
@@ static int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char * const
argv[])
* overwrite all exception vector code, so we cannot easily
* recover from any failures any more...
*/
- iflag = disable_interrupts();
+ disable_interrupts();
#if defined(CONFIG_CMD_USB)
/*
--
1.7.0.4
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx28: Fix elftosb source link in README.mx28_common
Hi Anatolij, Hi Anatolij, The documented link to elftosb package tarball is not accessible, change to another working link. Signed-off-by: Anatolij Gustschin ag...@denx.de Cc: Otavio Salvador ota...@ossystems.com.br Cc: Marek Vasut marek.va...@gmail.com Cc: Fabio Estevam feste...@gmail.com Acked-by: Otavio Salvador ota...@ossystems.com.br Acked-by: Detlev Zundel d...@denx.de Acked-by: Marek Vasut ma...@denx.de Thanks Anatolij! Detlev Thanks Anatolij! Marek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] Add support new arch: c6x
On Mon, Jun 25, 2012 at 10:02:38PM +0400, Dmitry Bondar wrote:
C6X (C6000) is Texas Instruments architecture of fixed and
floating-point DSPs.
This patch add basic support.
Many of code in arch/c6x/include/asm come from c6x-linux project
(http://linux-c6x.org)
Signed-off-by: Dmitry Bondar b...@inmys.ru
Cc: Tom Rini tr...@ti.com
Please cite the exact commit from upstream where this comes from (I
imagine you could even use kernel.org proper, but I didn't check all
files just a few) and say for example:
Backport from linux commit 27406e978f596a646b87941cba5247eb0ccc8916
Must I say it in each file, or in commit message?
If in commit, how about something like this:
Many of code in arch/c6x/include/asm and arch/c6x/lib come from linux kernel,
c6x headers (arch/c6x/include/asm) in linux kernel mainline from commit
a7f626c1948ab6178d2338831c5ffea7385e9f7f
c6x libs (arch/c6x/lib) in linux kernel mainline from
09831ca73443bd819ad7993db5409b19c899ba33
+#ifndef __ASM_GBL_DATA_H
Tabs instead of spaces. I don't know why checkpatch didn't complain but
please give all of the files a quick check for things like tabspace
and '#definetab' and '#ifndeftab.
I spot-checked a few of the library files and they seem to match the
kernel which is important so I'll set aside disliking ';' as a comment
char.
[snip]
diff --git a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c
index 42f08fd..faf534b 100644
--- a/common/cmd_bdinfo.c
+++ b/common/cmd_bdinfo.c
@@ -513,6 +513,11 @@ int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
return 0;
}
+#elif defined(CONFIG_C6X)
+int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const
argv[])
+{
+return 0;
+}
You should be able to define a minimal set of prints here, see the
OpenRISC example above it.
diff --git a/common/image.c b/common/image.c
index 91954ac..0fff687 100644
--- a/common/image.c
+++ b/common/image.c
@@ -456,8 +456,12 @@ phys_size_t getenv_bootm_size(void)
#if defined(CONFIG_ARM)
return gd-bd-bi_dram[0].size - tmp;
#else
+#if defined(CONFIG_C6X)
+return gd-bd-bi_dram[0].size - tmp;
Here and possibly another place or two in the file, just change the
check from defined(CONFIG_ARM) to defined(CONFIG_ARM) ||
defined(CONFIG_C6X).
Thanks!
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] Add support new arch: c6x
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/27/2012 01:36 PM, b...@inmys.ru wrote: On Mon, Jun 25, 2012 at 10:02:38PM +0400, Dmitry Bondar wrote: C6X (C6000) is Texas Instruments architecture of fixed and floating-point DSPs. This patch add basic support. Many of code in arch/c6x/include/asm come from c6x-linux project (http://linux-c6x.org) Signed-off-by: Dmitry Bondar b...@inmys.ru Cc: Tom Rini tr...@ti.com Please cite the exact commit from upstream where this comes from (I imagine you could even use kernel.org proper, but I didn't check all files just a few) and say for example: Backport from linux commit 27406e978f596a646b87941cba5247eb0ccc8916 Must I say it in each file, or in commit message? Just the commit message. If in commit, how about something like this: Many of code in arch/c6x/include/asm and arch/c6x/lib come from linux kernel, c6x headers (arch/c6x/include/asm) in linux kernel mainline from commit a7f626c1948ab6178d2338831c5ffea7385e9f7f c6x libs (arch/c6x/lib) in linux kernel mainline from 09831ca73443bd819ad7993db5409b19c899ba33 Yes, or just make sure that both parts are still in sync with the kernel at whichever of those commits is later. That'll make any future re-syncs easier on you :) - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP63NeAAoJENk4IS6UOR1WmjUP/3b/SAQxeJXzupGW0PhKH5TZ ptwHPxkzTDcSXGNYmL42XdD4NLTM0rgNxQxZoPobKVVSAynlxv58Bzb9e4Umf/BH HWs4L/TvnAWlAu45BU3wjzPYqF+lo7aDyiw4jDsX0zb+WxArPY90kM1NTCiUvK9U BexzFTrqL0Rfw0vAAIfGSw46qyIRaZp2AM2q97J0Q7j4satiA8AJ7Ly6XcWu43/s 4L5FBF0lDeLLmsMnFXvJOj0O2KWxvyaQx7ola1YkXSSFPdSXY9M2gbkbz+spSe81 Pgw43XJ7OXlrASDsvov7U9V/LHLuqXS/Lo8jVMFTp5hLfXD830mA5dBCipsPJF/1 mIxXy3qIgdxNwtOMeebhfknpIhW6TQV1T5F5RyTFmsB5g1N+5lBTQveMCE1qMqmK Lki6ftPGhsJpPTxNvev/gx3acBQ6O+/X/zWujlj6YUcx1QCZYZq4bXP4a+4MB07N bmuSNwl3PlH03lO9SDUZVBc6h+eLJ2jU1rMba+ojQmcGOUUeq42Cs+W1Lr5dfQEE rcg/y4HxUIbYxkR4P0jJwE0SGsEy25/8X8859rGnQw25Pvxg0xFXmtisDb2WYDzd SU9y31JsLybpa6HeO8F5ex3aRb7+KYhLrOSxoGCGKmgeuJ0ndcQP3dRigrw3jVs6 Tq7hNvK/kgUBVT6pXimQ =4ngS -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] Add support new arch: c6x
Dear b...@inmys.ru, In message 9cc1576e223fd1ac2b8a3329ad55bca8.squirrel@78.108.93.81 you wrote: Please cite the exact commit from upstream where this comes from (I imagine you could even use kernel.org proper, but I didn't check all files just a few) and say for example: Backport from linux commit 27406e978f596a646b87941cba5247eb0ccc8916 Must I say it in each file, or in commit message? How about reading the documentation? It answers such questions, with examples and all 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 There is nothing so deadly as not to hold up to people the opportunity to do great and wonderful things, if we wish to stimulate them in an active way. - Dr. Harold Urey, Nobel Laureate in chemistry ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/6] mcx: Disable DCACHE since USB EHCI is enabled
Dear Ilya Yanok, Hi, 21.06.2012 02:14, Tom Rini wrote: USB EHCI and DCACHE are not compatible, so disable DCACHE support at build-time as run-time disable is insufficient for USB use. Sorry for missing this discussion. I think compile-time disabling of the cache is too brutal. ehci-hcd cache handling is broken anyway: doing unaligned flushes/invalidates is a bug, and we know for sure that upper layers don't care about alignment (and I bet ehci-hcd does this even for its internal buffers). So what's the point in all this cache handling in ehci-hcd? It's not going to work anyway and just produces problems. So I suggest to just disable all this stuff until generic code will be fixed. Alternatively we can do bounce-buffering inside driver. We should rather introduce generic bounce buffer. But the upper layers are getting fixed recently so we should be getting there. Regards, Ilya. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions
Hi Sricharan, On 06/21/2012 02:25 AM, Sricharan R wrote: Hi, [snip..] On 06/15/2012 07:48 AM, R, Sricharan wrote: Hi, On Fri, Jun 15, 2012 at 12:31 AM, Tom Rinitr...@ti.com wrote: If we are built with D-CACHE enabled but have run 'dcache off' and then attempt to flush unaligned regions we spam the console with problems that aren't true (as the cache was off). Today we do cache maintenance operations after the dcache is turned off. One example is before jumping to kernel, we try to invalidate the caches, in cache turned off state. So with this patch those maintenance calls will do nothing, which is not correct. Ah yes, But, shouldn't we be doing these same operations as part of turning the cache off? The problem is that while turning of dcaches, we flush it, and turn cache and MMU off. But these operations are not happening automatically in a single call. So there is a chance of valid entries present in cache even after it is OFF. I think this is what we need to fix. Otherwise, Tom's change looks good to me. How about an invalidate in dcache_disable() or something like that? Correct. So if the cleaning up sequence is fine, then ok. So there should be no need to check if caches are OFF inside the maintenance functions. Kernel does not looks like doing such checks. The real issue looks like we should have had assembly level functions to do the cleanup routines for flush-invalidate-turn OFF caches/MMU atomically. Sorry for the late reply. Yes, kernel doesn't do such checks. But kernel's implementation is different from u-boot implementation. In kernel the invalidate routine flushes unaligned lines in the end which, after a lot of discussions[1], we decided to avoid in u-boot. Instead we printed noisy error messages to alert the user. Now these messages will appear even if we are calling the maintenance functions after the disable and that's what Tom is trying to avoid. br, Aneeesh [1] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/105113 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions
Sricharan, On 06/21/2012 08:23 AM, R, Sricharan wrote: Hi Aneesh, On Thu, Jun 21, 2012 at 2:55 PM, Sricharan Rr.sricha...@ti.com wrote: Hi, [snip..] On 06/15/2012 07:48 AM, R, Sricharan wrote: Hi, On Fri, Jun 15, 2012 at 12:31 AM, Tom Rinitr...@ti.comwrote: If we are built with D-CACHE enabled but have run 'dcache off' and then attempt to flush unaligned regions we spam the console with problems that aren't true (as the cache was off). Today we do cache maintenance operations after the dcache is turned off. One example is before jumping to kernel, we try to invalidate the caches, in cache turned off state. So with this patch those maintenance calls will do nothing, which is not correct. Ah yes, But, shouldn't we be doing these same operations as part of turning the cache off? The problem is that while turning of dcaches, we flush it, and turn cache and MMU off. But these operations are not happening automatically in a single call. So there is a chance of valid entries present in cache even after it is OFF. I think this is what we need to fix. Otherwise, Tom's change looks good to me. How about an invalidate in dcache_disable() or something like that? Correct. So if the cleaning up sequence is fine, then ok. So there should be no need to check if caches are OFF inside the maintenance functions. Kernel does not looks like doing such checks. The real issue looks like we should have had assembly level functions to do the cleanup routines for flush-invalidate-turn OFF caches/MM atomically. Actually, with something like speculation in the behind, only way of ensuring that we do not have any valid entries is to do a invalidate all, after turn of caches/mmu. So this means that we will have a maintenance after turning off. Good point. But we need that invalidate just one last time after the disable, right? How about making the cache_status a variable rather than reading the C bit. And then disable_cache() shall be like this: 1. Flush all 2. Disable C bit 3. Invalidate all 4. cache_status = disabled Maybe, not the best solution. But I can't think of anything better. Please note that after this point there won't be any valid entries in the cache per ARMv7 Architecture reference manual(section B2.2.2): If the cache is disabled, it is guaranteed that no new allocation of memory locations into the cache will occur. br, Aneeesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/6] mcx: Disable DCACHE since USB EHCI is enabled
Hi, 21.06.2012 02:14, Tom Rini wrote: USB EHCI and DCACHE are not compatible, so disable DCACHE support at build-time as run-time disable is insufficient for USB use. Sorry for missing this discussion. I think compile-time disabling of the cache is too brutal. ehci-hcd cache handling is broken anyway: doing unaligned flushes/invalidates is a bug, and we know for sure that upper layers don't care about alignment (and I bet ehci-hcd does this even for its internal buffers). So what's the point in all this cache handling in ehci-hcd? It's not going to work anyway and just produces problems. So I suggest to just disable all this stuff until generic code will be fixed. Alternatively we can do bounce-buffering inside driver. Regards, Ilya. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM CONFIG_OF_CONTROL status
Hi Michal,
On Wed, Jun 27, 2012 at 7:35 AM, Michal Simek mon...@monstr.eu wrote:
Hi Simon,
On 06/27/2012 03:58 PM, Simon Glass wrote:
Hi,
On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek mon...@monstr.eu mailto:
mon...@monstr.eu wrote:
Hi,
can you please update me about current state of CONFIG_OF_CONTROL for
ARM?
Are there any other archs/boards which will use this option?
Or any other git repo out of mainline u-boot?
Exynos is in progress - development is happening in the Chromium tree and
being upstreamed in chunks (although no fdt patches have been sent yet).
ok.
Has someone tried to look for devices based on compatible property?
I see that in usb driver it is based on aliases which is not the best
solution.
U-Boot doesn't yet have a device model which would allow this in the
general case. For now, drivers look for their own compatible nodes. This
works well enough until we have a device model.
There are other limitations also - for example USB supports only a single
controller type working at one time (a restriction we may need to look at
to support USB2 and USB3 together). So even if two USB drivers decided that
they both found compatible nodes, only one of them could operate. So for
now aliases provide just an ordering, nothing else.
I have looked at the code and did some tests on Microblaze.
Firstly I have tried to change emaclite ethernet initialization and I
ended with this code fragment which could be
broadly used by other drivers.
int offset = 0;
do {
offset = fdt_node_offset_by_compatible(**gd-fdt_blob,
offset, xlnx,xps-ethernetlite-1.00.a );
You could check if offset 0 here, or !fdtdec_get_is_enabled(gd-fdt_blob,
offset)
u32 rxpp = fdtdec_get_int(gd-fdt_blob, offset,
xlnx,rx-ping-pong, 0);
u32 txpp = fdtdec_get_int(gd-fdt_blob, offset,
xlnx,tx-ping-pong, 0);
u32 reg = fdtdec_get_int(gd-fdt_blob, offset, reg, 0);
Maybe fdtdec_get_addr()
if (reg)
ret |= xilinx_emaclite_initialize(**bis, reg,
txpp, rxpp);
} while (offset != -1);
What do you think? This code is in platform file.
Seems reasonable to me.
Also I have tested code around aliases which parse DTS aliases list for
console initialization
and I have also get it work for !CONSOLE_SERIAL_MULTI case.
Great - I did send a patch to the list for fdt serial, but haven't really
got back to it.
What was the reason to use compat_names table in fdtdec.c file?
Just so there is a simple register of everything that uses fdt in U-Boot -
the enum is used by driver code. If we end up with a lot of support then we
might reconsider one day
Regards,
Simon
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] arm: bugfix: save_boot_params_default accesses uninitalized stack when -O0
Hi Tom, thank you for reviewing.
(2012/06/28 2:40), Tom Rini wrote:
On Mon, Jun 25, 2012 at 09:42:29PM +0900, Tetsuyuki Kobayashi wrote:
save_boot_params_default() in cpu.c accesses uninitialized stack area
when it compiled with -O0 (not optimized).
Signed-off-by: Tetsuyuki Kobayashik...@kmckk.co.jp
---
arch/arm/cpu/armv7/cpu.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/cpu/armv7/cpu.c b/arch/arm/cpu/armv7/cpu.c
index c6fa8ef..6104cb2 100644
--- a/arch/arm/cpu/armv7/cpu.c
+++ b/arch/arm/cpu/armv7/cpu.c
@@ -37,8 +37,11 @@
#includeasm/cache.h
#includeasm/armv7.h
+__attribute__((naked)) /* don't save anything to stack even if compiled with
-O0 */
void save_boot_params_default(u32 r0, u32 r1, u32 r2, u32 r3)
{
+ /* stack is not yet initialized */
+ asm(bx lr);
}
Please addlinux/compiler.h and use __naked instead. Thanks!
OK. I will post V2 patch.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: bugfix: Move vector table before jumping relocated code
Hi Tom and all, (2012/06/28 3:23), Tom Rini wrote: On Mon, Jun 25, 2012 at 09:40:57PM +0900, Tetsuyuki Kobayashi wrote: Interrupts and exceptions doesn't work in relocated code. It badly use IRQ_STACK_START_IN in rom area as interrupt stack. It is because the vecotr table is not moved to ram area. This patch moves vector table before jumping relocated code. Signed-off-by: Tetsuyuki Kobayashik...@kmckk.co.jp --- arch/arm/cpu/armv7/start.S | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 52f7f6e..5098f7b 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -277,6 +277,18 @@ jump_2_ram: mcr p15, 0, r0, c7, c10, 4 @ DSB mcr p15, 0, r0, c7, c5, 4 @ ISB #endif +/* + * Move vector table + */ +#if !defined(CONFIG_TEGRA2) +#if !(defined(CONFIG_OMAP44XX) defined(CONFIG_SPL_BUILD)) + /* Set vector address in CP15 VBAR register */ + ldr r0, =_start + add r0, r0, r9 + mcr p15, 0, r0, c12, c0, 0 @Set VBAR +#endif +#endif /* !Tegra2 */ + ldr r0, _board_init_r_ofs adr r1, _start add lr, r0, r1 I think this code should get boot tested on a few platforms to make sure it's OK. As such, I've tried on am335x and omap3 and they're still fine. Tested-by: Tom Rinitr...@ti.com Tom, thank you for testing. Easy way to test this patch. Jump any bad address using go command on U-boot prompt. Good restult: go 0x0badc0de ## Starting application at 0x0BADC0DE ... undefined instruction pc : [0badc0e0] lr : [5ff91354] sp : 5feefb98 ip : 001c fp : 5feefbdd r10: 0002 r9 : 5feefbdd r8 : 5feeff68 r7 : 5feeff14 r6 : 0badc0de r5 : 5feefed4 r4 : 0002 r3 : 0badc0de r2 : 5feefed4 r1 : 5feefed4 r0 : 0001 Flags: nZCv IRQs off FIQs off Mode SVC_32 Resetting CPU ... resetting ... Bad result: go 0x0badc0de (.. hang up without any crash dump.) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] bcm: Add GPIO driver for BCM2835 SoC
On 6/27/2012 11:36 PM, Stephen Warren wrote: On 06/27/2012 11:32 AM, Vikram Narayanan wrote: Hello Stephen, On 6/27/2012 7:09 AM, Stephen Warren wrote: On 06/24/2012 11:21 AM, Vikram Narayanan wrote: First off, it's great to see some patches for the chip. Thanks. Sorry for being so nit-picky below; it's a tendency of mine... Thanks for the detailed review. I'd make a v2 for this. And I might probably include you in the signed-off-by line. Hope you don't mind that. No, you shouldn't add any tags to the patch that refer to other people, except perhaps a Reported-By, without their explicitly giving those tags. Also, Signed-off-by wouldn't make sense here since I'm not vouching for the code or passing it along. Once V2 is posted, I may give an ack or review tag. I'm aware of it. :) Just for the level of details you said to change in the code I said so. Don't mind that. Do you have a hosted repo somewhere for this rpi_b stuff? If so, please post it here or we shall have one, which has all the patches queued in for the mainline. What do you say? Share your opinions about this. I do have a repo. It's at: https://github.com/swarren/u-boot However, that's my personal work-space. The RPi patches should eventually make it into the official U-Boot repositories through the standard review process. They are: ARM repo: git://git.denx.de/u-boot-arm.git Main repo: git://git.denx.de/u-boot.git I'm aware of this too. I'm referring to a public hosting of these RPi patches somewhere, so that it could easily be submitted to the mainline in _one_ shot. Since your initial SoC support patches aren't added to the u-boot-arm, I planned to have everything queued up for submission into the mainline *via* the mailing list. Hope you got my point. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions
Aneesh, [snip..] If we are built with D-CACHE enabled but have run 'dcache off' and then attempt to flush unaligned regions we spam the console with problems that aren't true (as the cache was off). Today we do cache maintenance operations after the dcache is turned off. One example is before jumping to kernel, we try to invalidate the caches, in cache turned off state. So with this patch those maintenance calls will do nothing, which is not correct. Ah yes, But, shouldn't we be doing these same operations as part of turning the cache off? The problem is that while turning of dcaches, we flush it, and turn cache and MMU off. But these operations are not happening automatically in a single call. So there is a chance of valid entries present in cache even after it is OFF. I think this is what we need to fix. Otherwise, Tom's change looks good to me. How about an invalidate in dcache_disable() or something like that? Correct. So if the cleaning up sequence is fine, then ok. So there should be no need to check if caches are OFF inside the maintenance functions. Kernel does not looks like doing such checks. The real issue looks like we should have had assembly level functions to do the cleanup routines for flush-invalidate-turn OFF caches/MM atomically. Actually, with something like speculation in the behind, only way of ensuring that we do not have any valid entries is to do a invalidate all, after turn of caches/mmu. So this means that we will have a maintenance after turning off. Good point. But we need that invalidate just one last time after the disable, right? How about making the cache_status a variable rather than reading the C bit. And then disable_cache() shall be like this: 1. Flush all 2. Disable C bit 3. Invalidate all 4. cache_status = disabled Maybe, not the best solution. But I can't think of anything better. Please note that after this point there won't be any valid entries in the cache per ARMv7 Architecture reference manual(section B2.2.2): If the cache is disabled, it is guaranteed that no new allocation of memory locations into the cache will occur. I agree on this sequence. But the only thing is, is it good to turn off the caches runtime, because one driver cant do aligned access ? Will this then not become a custom, say any other driver which sees problem with cache, will then simply go ahead disable and proceed. Is that right ?. yes, having enabled caches we are missing things like UNCACHED allocations, IO etc, but that is going to make boot loaders more heavy, may be. In the end, I am not sure which is the right decision to take here :) Thanks, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM CONFIG_OF_CONTROL status
Hi Simon,
On 06/28/2012 03:10 AM, Simon Glass wrote:
Hi Michal,
On Wed, Jun 27, 2012 at 7:35 AM, Michal Simek mon...@monstr.eu
mailto:mon...@monstr.eu wrote:
Hi Simon,
On 06/27/2012 03:58 PM, Simon Glass wrote:
Hi,
On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek mon...@monstr.eu
mailto:mon...@monstr.eu mailto:mon...@monstr.eu mailto:mon...@monstr.eu
wrote:
Hi,
can you please update me about current state of CONFIG_OF_CONTROL
for ARM?
Are there any other archs/boards which will use this option?
Or any other git repo out of mainline u-boot?
Exynos is in progress - development is happening in the Chromium tree
and being upstreamed in chunks (although no fdt patches have been sent yet).
ok.
Has someone tried to look for devices based on compatible property?
I see that in usb driver it is based on aliases which is not the
best solution.
U-Boot doesn't yet have a device model which would allow this in the
general case. For now, drivers look for their own compatible nodes. This works
well enough until we have a device model.
There are other limitations also - for example USB supports only a
single controller type working at one time (a restriction we may need to look
at to support USB2 and USB3 together). So even if two USB drivers decided that
they both found compatible nodes, only one of them could operate. So for now
aliases provide just an ordering, nothing else.
I have looked at the code and did some tests on Microblaze.
Firstly I have tried to change emaclite ethernet initialization and I ended
with this code fragment which could be
broadly used by other drivers.
int offset = 0;
do {
offset = fdt_node_offset_by_compatible(__gd-fdt_blob, offset,
xlnx,xps-ethernetlite-1.00.a );
You could check if offset 0 here, or !fdtdec_get_is_enabled(gd-fdt_blob,
offset)
u32 rxpp = fdtdec_get_int(gd-fdt_blob, offset,
xlnx,rx-ping-pong, 0);
u32 txpp = fdtdec_get_int(gd-fdt_blob, offset,
xlnx,tx-ping-pong, 0);
u32 reg = fdtdec_get_int(gd-fdt_blob, offset, reg, 0);
Maybe fdtdec_get_addr()
yeah right.
do {
offset = fdt_node_offset_by_compatible(gd-fdt_blob, offset,
xlnx,xps-ethernetlite-1.00.a );
u32 rxpp = fdtdec_get_int(gd-fdt_blob, offset,
xlnx,rx-ping-pong, 0);
u32 txpp = fdtdec_get_int(gd-fdt_blob, offset,
xlnx,tx-ping-pong, 0);
u32 reg = fdtdec_get_addr(gd-fdt_blob, offset, reg);
if (reg != FDT_ADDR_T_NONE)
ret |= xilinx_emaclite_initialize(bis, reg, txpp, rxpp);
} while (offset != -1);
if (reg)
ret |= xilinx_emaclite_initialize(__bis, reg, txpp,
rxpp);
} while (offset != -1);
What do you think? This code is in platform file.
Seems reasonable to me.
ok.
Also I have tested code around aliases which parse DTS aliases list for
console initialization
and I have also get it work for !CONSOLE_SERIAL_MULTI case.
Great - I did send a patch to the list for fdt serial, but haven't really got
back to it.
Can you give me link to it or just subject?
What was the reason to use compat_names table in fdtdec.c file?
Just so there is a simple register of everything that uses fdt in U-Boot - the
enum is used by driver code. If we end up with a lot of support then we might
reconsider one day
Is it requirement that all new drivers should extend this table?
Because from my point of view is just this not necessary to do.
Based on function above this is enough for drivers to be probed.
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] ARM CONFIG_OF_CONTROL status
Hi Michal,
On Wed, Jun 27, 2012 at 10:50 PM, Michal Simek mon...@monstr.eu wrote:
Hi Simon,
On 06/28/2012 03:10 AM, Simon Glass wrote:
Hi Michal,
On Wed, Jun 27, 2012 at 7:35 AM, Michal Simek mon...@monstr.eu mailto:
mon...@monstr.eu wrote:
Hi Simon,
On 06/27/2012 03:58 PM, Simon Glass wrote:
Hi,
On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek
mon...@monstr.eumailto:
mon...@monstr.eu mailto:mon...@monstr.eu mailto:mon...@monstr.eu
wrote:
Hi,
can you please update me about current state of
CONFIG_OF_CONTROL for ARM?
Are there any other archs/boards which will use this option?
Or any other git repo out of mainline u-boot?
Exynos is in progress - development is happening in the Chromium
tree and being upstreamed in chunks (although no fdt patches have been sent
yet).
ok.
Has someone tried to look for devices based on compatible
property?
I see that in usb driver it is based on aliases which is not
the best solution.
U-Boot doesn't yet have a device model which would allow this in
the general case. For now, drivers look for their own compatible nodes.
This works well enough until we have a device model.
There are other limitations also - for example USB supports only a
single controller type working at one time (a restriction we may need to
look at to support USB2 and USB3 together). So even if two USB drivers
decided that they both found compatible nodes, only one of them could
operate. So for now aliases provide just an ordering, nothing else.
I have looked at the code and did some tests on Microblaze.
Firstly I have tried to change emaclite ethernet initialization and I
ended with this code fragment which could be
broadly used by other drivers.
int offset = 0;
do {
offset = fdt_node_offset_by_compatible(**__gd-fdt_blob,
offset, xlnx,xps-ethernetlite-1.00.a );
You could check if offset 0 here, or !fdtdec_get_is_enabled(gd-**fdt_blob,
offset)
u32 rxpp = fdtdec_get_int(gd-fdt_blob, offset,
xlnx,rx-ping-pong, 0);
u32 txpp = fdtdec_get_int(gd-fdt_blob, offset,
xlnx,tx-ping-pong, 0);
u32 reg = fdtdec_get_int(gd-fdt_blob, offset, reg,
0);
Maybe fdtdec_get_addr()
yeah right.
do {
offset = fdt_node_offset_by_compatible(**gd-fdt_blob,
offset, xlnx,xps-ethernetlite-1.00.a );
u32 rxpp = fdtdec_get_int(gd-fdt_blob, offset,
xlnx,rx-ping-pong, 0);
u32 txpp = fdtdec_get_int(gd-fdt_blob, offset,
xlnx,tx-ping-pong, 0);
u32 reg = fdtdec_get_addr(gd-fdt_blob, offset, reg);
if (reg != FDT_ADDR_T_NONE)
ret |= xilinx_emaclite_initialize(**bis, reg,
txpp, rxpp);
} while (offset != -1);
if (reg)
ret |= xilinx_emaclite_initialize(__**bis,
reg, txpp, rxpp);
} while (offset != -1);
What do you think? This code is in platform file.
Seems reasonable to me.
ok.
Also I have tested code around aliases which parse DTS aliases list
for console initialization
and I have also get it work for !CONSOLE_SERIAL_MULTI case.
Great - I did send a patch to the list for fdt serial, but haven't really
got back to it.
Can you give me link to it or just subject?
WIP: fdt: Add serial port controlled by device tree
These are the related commits in the Chromium tree. I will get to
upstreaming these at some point.
1fe36bf gen: serial: Disable FDT serial console if requested
c80331f gen: Adjust fdt console to be silent if no alias present
2006b07 gen: fdt: Add serial port controlled by device tree
711f29d fixup: gen: fdt: Fix compile-time errors
0c8fc5d lost: gen: x86: Allow NS16550 driver to support IO and memory
mapped reg
da92af5 gen: Fix a compiler warning in serial_fdt.c
ab1d572 gen: fdt: silence console in response to device tree 'silent' option
376c215 lost: gen: fdt: Add serial port controlled by device tree
What was the reason to use compat_names table in fdtdec.c file?
Just so there is a simple register of everything that uses fdt in U-Boot
- the enum is used by driver code. If we end up with a lot of support then
we might reconsider one day
Is it requirement that all new drivers should extend this table?
Because from my point of view is just this not necessary to do.
Based on function above this is enough for drivers to be probed.
Fair enough. If you don't want to I don't see why it should be a hard
requirement.
Regards,
Simon
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
