Re: [U-Boot] [PATCH] spl:falcon:trats Update Trats default board configuration file to support FALCON MODE
Hi Minkyu,
> Support for a new command (defined at envs) - spl_export generates
> the ATAGS image necessary for fast boot. Afterwards, it is stored
> at ext4 partition.
>
> Generated image format:
> CRC [4B] SIZE [4B] PAYLOAD(ATAGS/DT) [SIZE]
>
> Remarks:
> - CRC is calculated only for PAYLOAD
> - SIZE is the size of PAYLOAD
>
> It is important to adjust ${splsize} when large image is generated.
> It is defined as hex, since ext4 related commands expect it.
>
> The ${spladdr} environment variable corresponds to
> CONFIG_SYS_SPL_ARGS_ADDR
>
> Additionally definitions for DFU have been refactored and support for
> EFI has been added as well.
>
Could this patch be added to u-boot-samsung tree? It brings many
updates for trats configuration and it would be nice to bring it to
2013.01 u-boot release.
> Signed-off-by: Lukasz Majewski
> Signed-off-by: Kyungmin Park
> Cc: Minkyu Kang
> ---
> board/samsung/trats/trats.c |2 +-
> include/configs/trats.h | 45
> +- 2 files changed, 36
> insertions(+), 11 deletions(-)
>
> diff --git a/board/samsung/trats/trats.c b/board/samsung/trats/trats.c
> index e540190..4738043 100644
> --- a/board/samsung/trats/trats.c
> +++ b/board/samsung/trats/trats.c
> @@ -66,7 +66,7 @@ struct s3c_plat_otg_data s5pc210_otg_data;
>
> int board_init(void)
> {
> - gd->bd->bi_boot_params = PHYS_SDRAM_1 + 0x100;
> + gd->bd->bi_boot_params = CONFIG_SYS_SPL_ARGS_ADDR;
>
> check_hw_revision();
> printf("HW Revision:\t0x%x\n", board_rev);
> diff --git a/include/configs/trats.h b/include/configs/trats.h
> index 355029e..52fe77d 100644
> --- a/include/configs/trats.h
> +++ b/include/configs/trats.h
> @@ -98,6 +98,7 @@
> #undef CONFIG_CMD_MTDPARTS
> #define CONFIG_CMD_MMC
> #define CONFIG_CMD_DFU
> +#define CONFIG_CMD_SETEXPR
>
> /* FAT */
> #define CONFIG_CMD_FAT
> @@ -123,9 +124,8 @@
> #define CONFIG_ENV_COMMON_BOOT "${console} ${meminfo}"
>
> #define CONFIG_DFU_ALT \
> - "dfu_alt_info=" \
> "u-boot mmc 80 400;" \
> - "uImage fat 0 2\0" \
> + "uImage ext4 0 2\0" \
>
> #define CONFIG_ENV_OVERWRITE
> #define CONFIG_SYS_CONSOLE_INFO_QUIET
> @@ -144,20 +144,20 @@
> "mmc read 0 0x4210 0x80 0x200; run
> updatebackup\0" \ "lpj=lpj=3981312\0" \
> "nfsboot=" \
> - "set bootargs root=/dev/nfs rw " \
> + "setenv bootargs root=/dev/nfs rw " \
> "nfsroot=${nfsroot},nolock,tcp " \
> "ip=${ipaddr}:${serverip}:${gatewayip}:" \
> "${netmask}:generic:usb0:off "
> CONFIG_ENV_COMMON_BOOT \ "; run bootk\0" \
> "ramfsboot=" \
> - "set bootargs root=/dev/ram0 rw rootfstype=ext2 " \
> + "setenv bootargs root=/dev/ram0 rw rootfstype=ext2 "
> \ "${console} ${meminfo} " \
> "initrd=0x4300,8M ramdisk=8192\0" \
> "mmcboot=" \
> - "set bootargs
> root=/dev/mmcblk${mmcdev}p${mmcrootpart} " \
> + "setenv bootargs
> root=/dev/mmcblk${mmcdev}p${mmcrootpart} " \ "${lpj} rootwait
> ${console} ${meminfo} ${opts} ${lcdinfo}; " \ "run loaduimage; bootm
> 0x40007FC0\0" \
> - "bootchart=set opts init=/sbin/bootchartd; run bootcmd\0" \
> + "bootchart=setenv opts init=/sbin/bootchartd; run bootcmd\0"
> \ "boottrace=setenv opts initcall_debug; run bootcmd\0" \
> "mmcoops=mmc read 0 0x4000 0x40 8; md 0x4000
> 0x400\0" \ "verify=n\0" \
> @@ -166,12 +166,30 @@
> "meminfo=crashkernel=32M@0x5000\0" \
> "nfsroot=/nfsroot/arm\0" \
> "bootblock=" CONFIG_BOOTBLOCK "\0" \
> - "loaduimage=fatload mmc ${mmcdev}:${mmcbootpart} 0x40007FC0
> uImage\0" \
> + "loaduimage=ext4load mmc ${mmcdev}:${mmcbootpart} 0x40007FC0
> uImage\0" \ "mmcdev=0\0" \
> "mmcbootpart=2\0" \
> - "mmcrootpart=3\0" \
> + "mmcrootpart=5\0" \
> "opts=always_resume=1\0" \
> - CONFIG_DFU_ALT
> + "dfu_alt_info=" CONFIG_DFU_ALT \
> + "spladdr=0x4100\0" \
> + "splsize=0x200\0" \
> + "splfile=falcon.bin\0" \
> + "spl_export=" \
> +"setexpr spl_imgsize ${splsize} + 8 ;" \
> +"setexpr spl_imgaddr ${spladdr} - 8 ;" \
> +"setexpr spl_addr_tmp ${spladdr} - 4 ;" \
> +"mw.b ${spl_imgaddr} 0x00 ${spl_imgsize};run
> loaduimage;" \
> +"setenv bootargs
> root=/dev/mmcblk${mmcdev}p${mmcrootpart} " \
> +"${lpj} rootwait ${console} ${meminfo} ${opts}
> ${lcdinfo};" \
> +"spl export atags 0x40007FC0;" \
> +"crc32 ${spladdr} ${splsize} ${spl_imgaddr};" \
> +"mw.l ${spl_addr_tmp} ${splsize};" \
> +"ext4write mmc ${mmcdev}:${mmcbootpart}" \
> +" /${splfile} ${spl_imgaddr} ${spl_imgsize};" \
> +"setenv spl_imgsize;" \
> +"setenv spl_imgaddr;" \
> +"setenv spl_addr_tmp;\0"
>
> /* Miscellaneous
Re: [U-Boot] Bricked when trying to attach UBI
Luca Ceresoli wrote:
Hi,
I'm Cc'ing the linux-mtd list as well as the authors of the Linux
commits cited below.
For these new readers: I reported a problem with U-Boot 2012.04.01 not
being able to attach an UBI partition in NAND, while Linux (2.6.37) can
attach and repair it.
It looks like an U-Boot bug, but I discovered strange things around the
chip->badblockbits variable (in the NAND code) by comparing the
relevant code in U-Boot and Linux.
Sorry for Cc'ing so many people, but following this issue I was lead
from one subsystem to another (and from U-Boot to Linux).
Previous discussion is here:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/149624
Luca Ceresoli wrote:
Hi Andreas,
Andreas Bießmann wrote:
Hi Luca,
On 19.12.2012 16:56, Luca Ceresoli wrote:
Hi Andreas,
Andreas Bießmann wrote:
...
Creating 1 MTD partitions on "nand0":
0x0010-0x1000 : "mtd=3"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size:129024 bytes
UBI: smallest flash I/O unit:2048
UBI: sub-page size: 512
UBI: VID header offset: 512 (aligned 512)
UBI: data offset:2048
UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0,
need 1)
Now the device is totally blocked, and power cycling does not change
the result.
have you tried to increase the malloc arena in u-boot
(CONIG_SYS_MALLOC_LEN)?
We had errors like this before [1],[2] and [3], maybe others -
apparently with another error message, but please give it a try. We
know
ubi recovery needs some ram and 1MiB may be not enough.
Thanks for your suggestion.
Unfortunately this does not seem to be the cause of my problem: I
tried
increasing my CONFIG_SYS_MALLOC_LEN in include/configs/dig297.h from
(1024 << 10) to both (1024 << 12) and (1024 << 14), but without any
difference.
Well, ok ... Malloc arena is always my first thought if I read about
problems with ubi in u-boot.
Have you looked up the differences in drivers/mtd/ubi/ in your u-boot
and linux tree? Maybe you can see something obviously different in the
ubi_wl_init_scan()?
I had some days ago, but I double-checked now as you suggested. Indeed
there is an important difference: attach_by_scanning() (build.c) calls
ubi_wl_init_scan() and ubi_eba_init_scan() just like Linux does, but in
a swapped order!
This swap dates back to:
commit d63894654df72b010de2abb4b3f07d0d755f65b6
Author: Holger Brunck
Date: Mon Oct 10 13:08:19 2011 +0200
UBI: init eba tables before wl when attaching a device
This fixes that u-boot gets stuck when a bitflip was detected
during "ubi part ". If a bitflip was detected UBI tries
to copy the PEB to a different place. This needs that the eba table
are initialized, but this was done after the wear levelling worker
detects the bitflip. So changes the initialisation of these two
tasks in u-boot.
This is a u-boot specific patch and not needed in the linux layer,
because due to commit 1b1f9a9d00447d
UBI: Ensure that "background thread" operations are really executed
we schedule these tasks in place and not as in linux after the
inital
task which schedule this new task is finished.
Signed-off-by: Holger Brunck
cc: Stefan Roese
Signed-off-by: Stefan Roese
I tried reverting that commit and... surprise! U-Boot can now attach UBI
and boot properly!
But the cited commit actually fixed a bug that bite our board a few
months back, so it should not be reverted without thinking twice. Now
it apparently introduced another bug. :-(
I'm Cc:ing the commit author for comments.
Nonetheless, I have evidence of a different behaviour between U-Boot
and Linux even before the two swapped functions are called.
What attach_by_scanning() does in Linux is (abbreviated):
static int attach_by_scanning(struct ubi_device *ubi)
{
si = ubi_scan(ubi);
...fill ubi->some_fields...;
err = ubi_read_volume_table(ubi, si);
/* MARK */
err = ubi_eba_init_scan(ubi, si); /* swapped in U-Boot */
err = ubi_wl_init_scan(ubi, si); /* swapped in U-Boot */
ubi_scan_destroy_si(si);
return 0;
}
See the two swapped calls.
At MARK, I printed some of the peb counters in *ubi, and I got
different results for ubi->avail_pebs between U-Boot and Linux:
U-Boot: UBI: POST_TBL: rsvd=2018, avail=21, beb_rsvd_{pebs,level}=0,0
Linux: UBI: POST_TBL: rsvd=2018, avail=22, beb_rsvd_{pebs,level}=0,0
The printed values were equal before calling ubi_read_volume_table().
I have no idea about where this difference comes from, nor if this
difference can cause my troubles.
I will better investigate tomorrow looking into ubi_read_volume_table().
After half a day of debugging and an insane amount of printk()s added to
both U-Boot and Linux, I have some more hints to understand the problem.
The two different results quoted above show that U-Boot counted 21
available erase
Re: [U-Boot] [PATCH 1/1] omap4: use plain text env file instead boot scripts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/25/12 09:15, Javier Martinez Canillas wrote: > Based on commit cf073e49bc3502be1b48a0e3faf0cde9edbb89db for > beagleboard > > Using the new env import command it is possible to use plain text > files instead of script-images. Plain text files are much easier > to handle. The only problem I see with this is that in beagle-land there was some regret we didn't make this an either/or. In other words, look for uEnv.txt, if found, use it, otherwise see if we have a boot.scr, if so use it, and if we still haven't been then keep trying a "normal" boot from MMC. This means we don't break existing users (or distributions) that had been relying on boot.scr being used automatically. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ5EaKAAoJENk4IS6UOR1WjdgP/1e3R3PGKguwd4gezzdA4tAX 1K1HWtzhJ/3z/aW2LyIUp3LDGXBoUizf+ss1aqVYLDuq36V5uWfxFMBOas+Zt6b0 D36wuH6rNWqY6muhIqJlPub082riVGCS1Zsbdkho3hkNy9DY8eNjfWN+SqLY17WS AGyC1Xgoba828EjMiV0woICcDasarl+r3qTY/xEkCPEyvu8MvixAMY3F6mZKqfdA lk32Hghl/WnaQTHYDkZTQGhIQz+wLfXAH19OMSQmOfIfcRyoShcbylLLFaSfP2BV TqK7xAAibjLkNj++uXecob69054x8C4wnUMK1PN5XNhwDdA5ttsiAF6K4EKhURO7 jQ3epsqGUgso9WgAODJv3SjqHXu0WY9ASNds0kXAT0SDRYl4/I6uzWlexrQPN0Oo d5KwjINPpQpWR86z9rUl+FXIbTj2naslFBO1QryAeDWVPGYOlBrDaKA37iJFWYKI YFF/FKHz6JFMgaF3RWCDsZN/nx93bOq+LDNo9+ejDhp90+iu9wezsACZx8KBiyxy Xyw9Wjm+lUJv5ZQxGOFSVH8eUpaKLbk3dE5z8IHi6YoQSY/IHqHHXqrqU3dz8KbP FJNVUISUYAgYP7f4QaI1P/Tm/u4JV+bovmx65BClprl9FESnvQ8FfPl2lmzboXWX 6vcln6tUmX4+itkUJ7BB =z+WM -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] am335x_evm: enable support for booting via USB
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/31/12 11:32, Ilya Yanok wrote: > This adds necessary config options to enable usb booting and fixes > board_eth_init() function to take into account that we may have USB > ether support in SPL now. [snip] > +#define CONFIG_USBNET_HOST_ADDR "de:ad:be:af:00:00" +#define > CONFIG_USBNET_DEV_ADDR"de:ad:be:af:00:01" #endif /* > CONFIG_MUSB_GADGET */ We need to re-work this, ala the vendor tree, to use the same MAC as the cpsw ethernet device uses, to match the ROM behavior. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ5E1IAAoJENk4IS6UOR1WWd4P/R5LN98R0TFyRaynMgaUMUHp yxl8HclxesZ521AXKQ+laazCbwA+5n+yOr9UIkdNj7Cw9VJ+nh5PacecXhKO6Jdc TOGsSzy/yQAofmPjqndKoys1ICNlBo9xUYTG2j4AedJaa4ogYEICJxyrq77dGEMw d+PktUKf2BCp6ui3vERiLUycoqdf/GU6fcTftodX97B+MNO/JBGTIPXzw5zsYljQ SSR2he7JM6CN0YBNqbO8cssdDSd65VMi5rFy7viZWsd6qYhHaKI10lvdLNVryPRl aCPNj8qOCYvswKHk028OQuiUQEOUIw2fRqEXNGfJbhYkk8ePaTsrdiwOHUWMjMlW gF5Two5eX8SUobkirqwGYt3V5uGuumS3ZLPw4lAuZpmLBbzmlLvPw4EooOT1CSoS AW/Je0dQ87PqOcQkcci97V5Cp2Hef1VLMAh7cAYA+AUQ6nNDwqU7dwZUjFTeDZQB 2MHOURgcOKRyMmni21M1GyLWwfTrv7Q47PIqEl31cmFW05xVoQ06Km8TwsCK8L66 a0H99UuSO1gTsOHRAogUKDdH3gebwtQkDaMTUzH/4FTJWnvMNvGPuzM8Q7BdmAYg V/heDO7yR0LJtfNiBiC3KxbVmw980Un5TZAXpH2CFNc1+3DyW3MYyXGhsHNnd4hn fLdgBqd1xQj+B1osy6Ol =FtLs -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] am335x_evm: add new config with forced USB booting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/31/12 11:32, Ilya Yanok wrote: > Currently AM335X hardware has bug in it's ROM code that prevents > USB booting from working normally. So we have to load SPL via > serial console instead. But it's feasible to use USB for loading > the main U-Boot image. This patch adds additional am335x_evm > configuration for this. > > Signed-off-by: Ilya Yanok > > --- boards.cfg | 1 + 1 file changed, 1 insertion(+) > > diff --git a/boards.cfg b/boards.cfg index 91504c0..e7c66a9 100644 > --- a/boards.cfg +++ b/boards.cfg @@ -229,6 +229,7 @@ > integratorap_cm946es arm arm946esintegrator > armltd integratorcp_cm946es arm arm946es > integrator armltd - > integratorcp:CM946ES ca9x4_ct_vxp arm armv7 > vexpressarmltd am335x_evm arm > armv7 am335x ti am33xx > am335x_evm:SERIAL1,CONS_INDEX=1 +am335x_evm_usbboot arm > armv7 am335x ti am33xx > am335x_evm:SERIAL1,CONS_INDEX=1,SPL_FORCE_BOOT_DEVICE=BOOT_DEVICE_USBETH I > don't like the name here as fixed hardware will be widely available at some point. How about am335x_evm_force_usbboot ? - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ5E2aAAoJENk4IS6UOR1WeFYP/0DFrm0Ia6nhFIyB9NLNdpHK 5um5sKhe3z5W1QX4W5T0Bm/sJtG7+YAUwy2A+GRzwbGxFz5/dXOeqvSRcB2hMS7/ mX+Clh0gJSWN/M+9rHTxJzP47cDcxuukXDQ9V6clCcTS6oP/OqkiywxeTl+XipC3 mOTlKTpo6i9TnnewXKWWaEt3xturbAYeqKxMBU2c1ynHeczADUPmScY88+7OV61T Ysn+po7ylXc8gSOuffLbWURYdv46Sl3kCCgPIbN77gyYJKBjsssoGNTndEPCRX5z 8XEEg+DXzuzf6AztWmjis62LsySBsic8TEzj2QoZ+VJTuMgsWnJU8L4NVkYH+mwB sj7/xz7gKLIjF3/2upSJ6khoWtlzoRzMRMoQ7oLOYxhEVufQM5mznXRNcAsjUu03 eHysQPNxFTGWLE5SVlplKd8PJXtuxDCHwahFdpAaaE+TxYWYwIzaFXf+EO1PCH8j 3oNFNu66xFiYG/xb4gU+vLpw5HQCHkV2AS1g+11ucuB40sFhTi+56CIQCHbitu94 ZBM0YJ5/S87hO7cwM9bGq6+HlmTZ1oYuowKC4B0wTok5ZSyCwWNgyuqXR0vYV9ip Iojp2ix/QTMHwZC43h+UnccTePMvc6E4FdyCqAOhcSxF1amY7KNDj3S9YaMAdyYs 2DMThy1sPhRpS+dSTOOj =SSkH -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] am33xx: support for booting via usbeth
On Mon, Dec 31, 2012 at 08:32:40PM +0400, Ilya Yanok wrote: > This patch adds BOOT_DEVICE define for USB booting and fixes > spl_board_init function to call arch_misc_init (this is the place there > musb is initialized). [snip] > @@ -54,6 +54,9 @@ void spl_board_init(void) > #ifdef CONFIG_SPL_NAND_SUPPORT > gpmc_init(); > #endif > +#if defined(CONFIG_AM33XX) && defined(CONFIG_SPL_MUSB_NEW_SUPPORT) > + arch_misc_init(); > +#endif I don't think we need both tests here. As I said in the DFU thread, arch_misc_init is where everyone should be doing the "just register things" side of gadget USB hook-up. Clocking and pinmux are elsewhere anyhow. -- 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] drivers/block/systemace: fixes read/write words for bus width = 8
2013/1/2 Alexey Brodkin : > From: Alexey Brodkin > > Current implementation works fine for bus width = 16 bits because we > never get into "if" branch. > > If one sets width to 8 bits there will be 2 consequent data accesses > (read/write): > 1. Correct data access for 8-bit bus > 2. Unconditional (and in this case incorrect) data access as if data bus > is 16-bit wide > > Signed-off-by: Alexey Brodkin > --- > drivers/block/systemace.c |7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/block/systemace.c b/drivers/block/systemace.c > index 247cf06..88561a7 100644 > --- a/drivers/block/systemace.c > +++ b/drivers/block/systemace.c > @@ -66,7 +66,8 @@ static void ace_writew(u16 val, unsigned off) > writeb(val >> 8, base + off + 1); > #endif > } > - out16(base + off, val); > + else > + out16(base + off, val); > } yes > static u16 ace_readw(unsigned off) > @@ -78,8 +79,8 @@ static u16 ace_readw(unsigned off) > return readb(base + off) | (readb(base + off + 1) << 8); > #endif > } > - > - return in16(base + off); > + else > + return in16(base + off); > } No need to use it - because for width=8 it will return above. M -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture 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] drivers/block/systemace: replaced in16/out16 with more common readw/writew macros
2013/1/2 Alexey Brodkin : > Most architectures don't have symbols "in16"/"out16" defined. > Only Microblaze/PowerPC/Spark architectures do have them defined. > > At the same time there're much more common macros "readw"/"writew" for > 16-bit data access defined in most of architectures (in > linux kernel header "io.h"). > > So use of "readw"/"writew" makes it possible to build this driver for > virtually any architecture. > > Signed-off-by: Alexey Brodkin > --- > drivers/block/systemace.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/block/systemace.c b/drivers/block/systemace.c > index 88561a7..32c9169 100644 > --- a/drivers/block/systemace.c > +++ b/drivers/block/systemace.c > @@ -67,7 +67,7 @@ static void ace_writew(u16 val, unsigned off) > #endif > } > else > - out16(base + off, val); > + writew(val, base + off); > } > > static u16 ace_readw(unsigned off) > @@ -80,7 +80,7 @@ static u16 ace_readw(unsigned off) > #endif > } > else > - return in16(base + off); > + return readw(base + off); > } Same as before in this part of the code. But idea is OK. M -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PULL-REQ] MTD update
On Sun, Dec 30, 2012 at 08:24:00AM +0530, Vikram Narayanan wrote: > On 12/28/2012 7:29 PM, Tom Rini wrote: > >On Fri, Dec 28, 2012 at 07:17:42AM -0500, Sergey Lapin wrote: > > > >>Hi, all! > >> > >>As I failed to submit 250KB patch to the list > >>I will send this pull request > >> > >>This patch is not for inclusion yet. > >>This patch is just update of u-boot MTD with > >>Linux kernel's MTD v3.8-rc. > > > >First, while I appreciate the effort, I'd rather us sync with v3.7 > >release rather than the in-flux v3.8. Second, can you please look at > >the archives about how we've done these re-syncs before? I really don't > >want to take a single giant patch and we're usually able to break this > >up into chunks. Thanks! > > Can someone point to the exact thread where such discussion has > happened before? > > The re-sync has to happen addressing the bisect-ability as well. > > Already there was a discussion on syncing the UBI layer. So, if some > ideas are thrown, it would be beneficial for both MTD and UBI sync. What I was thinking of was: http://en.usenet.digipedia.org/thread/11185/23221/ http://en.usenet.digipedia.org/thread/11185/23218/ http://en.usenet.digipedia.org/thread/11185/28371/ But, from a lazy-poke of a single file, once we get out from the includes section of the files, some git format-patch'ing on the files we share with the kernel, between the last backport hash and v3.7 for example should be applicable with only a bit of hand fixing up. And if one wanted to do this slowly (3.0 to 3.1 to 3.2 to ...) it might be a little easier to manage. -- 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] [RFC]: always relocate u-boot before the framebuffer
On Mon, Dec 31, 2012 at 03:54:25PM +0100, Wolfgang Denk wrote: > Dear Lukasz Majewski, > > In message <20121231153353.2d9a5dda@amdc308.digital.local> you wrote: > > > > > - addr = lcd_setmem(addr); > > > - gd->fb_base = addr; > > > + gd->fb_base = lcd_setmem(addr); > > > #endif /* CONFIG_FB_ADDR */ > > > + /* always continue placement below the frame buffer to not > > > overlap */ > > > > Good idea. I will test it and let you know. > > Please see my responses. This is definitely NOT a good idea, it will > break most (all?) boards that use CONFIG_FB_ADDR in the way it was > intended for. I think this means we've got people not understanding what the variable IS for. And at the high level, the idea of "lets transition from U-Boot to Linux without a flicker" is good. So, what is the variables we should be using for this, today? Or do we need to add and document more? Or are we all just failing to RTFM here? -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] spl:falcon:trats Update Trats default board configuration file to support FALCON MODE
Support for a new command (defined at envs) - spl_export generates
the ATAGS image necessary for fast boot. Afterwards, it is stored
at ext4 partition.
Generated image format:
CRC [4B] SIZE [4B] PAYLOAD(ATAGS/DT) [SIZE]
Remarks:
- CRC is calculated only for PAYLOAD
- SIZE is the size of PAYLOAD
It is important to adjust ${splsize} when large image is generated.
It is defined as hex, since ext4 related commands expect it.
The ${spladdr} environment variable corresponds to
CONFIG_SYS_SPL_ARGS_ADDR
Additionally definitions for DFU have been refactored and support for
EFI has been added as well.
Signed-off-by: Lukasz Majewski
Signed-off-by: Kyungmin Park
Cc: Minkyu Kang
---
Changes for v2:
- Rebase the code on the newest master branch
---
board/samsung/trats/trats.c |2 +-
include/configs/trats.h | 45 +-
2 files changed, 36 insertions(+), 11 deletions(-)
diff --git a/board/samsung/trats/trats.c b/board/samsung/trats/trats.c
index 4724029..88d193d 100644
--- a/board/samsung/trats/trats.c
+++ b/board/samsung/trats/trats.c
@@ -67,7 +67,7 @@ struct s3c_plat_otg_data s5pc210_otg_data;
int board_init(void)
{
- gd->bd->bi_boot_params = PHYS_SDRAM_1 + 0x100;
+ gd->bd->bi_boot_params = CONFIG_SYS_SPL_ARGS_ADDR;
check_hw_revision();
printf("HW Revision:\t0x%x\n", board_rev);
diff --git a/include/configs/trats.h b/include/configs/trats.h
index 6efee5c..63745ac 100644
--- a/include/configs/trats.h
+++ b/include/configs/trats.h
@@ -99,6 +99,7 @@
#define CONFIG_CMD_MMC
#define CONFIG_CMD_DFU
#define CONFIG_CMD_GPT
+#define CONFIG_CMD_SETEXPR
/* FAT */
#define CONFIG_CMD_FAT
@@ -144,9 +145,8 @@
"name="PARTS_UMS",size=-,uuid=${uuid_gpt_"PARTS_UMS"}\0" \
#define CONFIG_DFU_ALT \
- "dfu_alt_info=" \
"u-boot mmc 80 400;" \
- "uImage fat 0 2\0" \
+ "uImage ext4 0 2\0" \
#define CONFIG_ENV_OVERWRITE
#define CONFIG_SYS_CONSOLE_INFO_QUIET
@@ -165,20 +165,20 @@
"mmc read 0 0x4210 0x80 0x200; run updatebackup\0" \
"lpj=lpj=3981312\0" \
"nfsboot=" \
- "set bootargs root=/dev/nfs rw " \
+ "setenv bootargs root=/dev/nfs rw " \
"nfsroot=${nfsroot},nolock,tcp " \
"ip=${ipaddr}:${serverip}:${gatewayip}:" \
"${netmask}:generic:usb0:off " CONFIG_ENV_COMMON_BOOT \
"; run bootk\0" \
"ramfsboot=" \
- "set bootargs root=/dev/ram0 rw rootfstype=ext2 " \
+ "setenv bootargs root=/dev/ram0 rw rootfstype=ext2 " \
"${console} ${meminfo} " \
"initrd=0x4300,8M ramdisk=8192\0" \
"mmcboot=" \
- "set bootargs root=/dev/mmcblk${mmcdev}p${mmcrootpart} " \
+ "setenv bootargs root=/dev/mmcblk${mmcdev}p${mmcrootpart} " \
"${lpj} rootwait ${console} ${meminfo} ${opts} ${lcdinfo}; " \
"run loaduimage; bootm 0x40007FC0\0" \
- "bootchart=set opts init=/sbin/bootchartd; run bootcmd\0" \
+ "bootchart=setenv opts init=/sbin/bootchartd; run bootcmd\0" \
"boottrace=setenv opts initcall_debug; run bootcmd\0" \
"mmcoops=mmc read 0 0x4000 0x40 8; md 0x4000 0x400\0" \
"verify=n\0" \
@@ -187,13 +187,31 @@
"meminfo=crashkernel=32M@0x5000\0" \
"nfsroot=/nfsroot/arm\0" \
"bootblock=" CONFIG_BOOTBLOCK "\0" \
- "loaduimage=fatload mmc ${mmcdev}:${mmcbootpart} 0x40007FC0 uImage\0" \
+ "loaduimage=ext4load mmc ${mmcdev}:${mmcbootpart} 0x40007FC0 uImage\0" \
"mmcdev=0\0" \
"mmcbootpart=2\0" \
- "mmcrootpart=3\0" \
+ "mmcrootpart=5\0" \
"opts=always_resume=1\0" \
"partitions=" PARTS_DEFAULT \
- CONFIG_DFU_ALT \
+ "dfu_alt_info=" CONFIG_DFU_ALT \
+ "spladdr=0x4100\0" \
+ "splsize=0x200\0" \
+ "splfile=falcon.bin\0" \
+ "spl_export=" \
+ "setexpr spl_imgsize ${splsize} + 8 ;" \
+ "setexpr spl_imgaddr ${spladdr} - 8 ;" \
+ "setexpr spl_addr_tmp ${spladdr} - 4 ;" \
+ "mw.b ${spl_imgaddr} 0x00 ${spl_imgsize};run loaduimage;" \
+ "setenv bootargs root=/dev/mmcblk${mmcdev}p${mmcrootpart} " \
+ "${lpj} rootwait ${console} ${meminfo} ${opts} ${lcdinfo};" \
+ "spl export atags 0x40007FC0;" \
+ "crc32 ${spladdr} ${splsize} ${spl_imgaddr};" \
+ "mw.l ${spl_addr_tmp} ${splsize};" \
+ "ext4write mmc ${mmcdev}:${mmcbootpart}" \
+ " /${splfile} ${spl_imgaddr} ${spl_imgsize};" \
+ "setenv spl_imgsize;" \
+ "setenv spl_imgaddr;" \
+ "setenv spl_addr_tmp;\0"
/* Miscellaneous configurable options */
#define CONFIG_SYS_LONGHELP/* undef to save memory */
@@ -234,6 +252,14 @@
#define CONF
Re: [U-Boot] [PATCH] drivers/block/systemace: fixes read/write words for bus width = 8
Hi, 2013/1/2 Алексей Бродкин : > The reason for latter modification is to make code more readable. > Do you think if I may submit this as a cosmetic change separately? If you mean create 3rd patch then no. Thanks, Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RESEND] video:cache:fix: Buffer alignment and dcache flush for lcd subsystem
This commit makes the video subsystem code cache aware.
Memory allocated for decompressed BMP memory is now cache line aligned.
Flushing of the dcache is also performed after copying BMP data to fb
address (it is done for 32 BPP bitmap used on Trats board (Exynos4210)).
Tested-by: Lukasz Majewski
Signed-off-by: Lukasz Majewski
Signed-off-by: Kyungmin Park
Cc: Anatolij Gustschin
---
common/cmd_bmp.c |2 +-
common/lcd.c |3 +++
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/common/cmd_bmp.c b/common/cmd_bmp.c
index 5a52edd..57f3eb5 100644
--- a/common/cmd_bmp.c
+++ b/common/cmd_bmp.c
@@ -55,7 +55,7 @@ bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long
*lenp)
* Decompress bmp image
*/
len = CONFIG_SYS_VIDEO_LOGO_MAX_SIZE;
- dst = malloc(CONFIG_SYS_VIDEO_LOGO_MAX_SIZE);
+ dst = memalign(CONFIG_SYS_CACHELINE_SIZE, len);
if (dst == NULL) {
puts("Error: malloc in gunzip failed!\n");
return NULL;
diff --git a/common/lcd.c b/common/lcd.c
index 4778655..784d1fb 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -1023,6 +1023,9 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
}
fb -= (lcd_line_length + width * (bpix / 8));
}
+ flush_dcache_range((unsigned long) fb,
+ (unsigned long) fb +
+ (lcd_line_length * height));
break;
#endif /* CONFIG_BMP_32BPP */
default:
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Makefile: remove MLO.byteswap on clobber
On clobber, do a cleanup even for SPL build else, we'd have
MLO.byteswap remaining for certain platforms like am33xx SPL builds
Signed-off-by: Nishanth Menon
---
To notice the missing cleanup:
With the cross compile flags set, do:
make am335x_evm_config; make; make clobber; git status
On branch master
Untracked files:
(use "git add ..." to include in what will be committed)
MLO.byteswap
Patch based on:v2013.01-rc2-172-gf8cfcf1 (master)
git://git.denx.de/u-boot.git
Makefile |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index a7b6cd1..4e64622 100644
--- a/Makefile
+++ b/Makefile
@@ -869,7 +869,7 @@ clobber:tidy
@rm -f $(obj)nand_spl/{u-boot-nand_spl.lds,u-boot-spl,u-boot-spl.map}
@rm -f $(obj)spl/{u-boot-spl,u-boot-spl.bin,u-boot-spl.map}
@rm -f $(obj)spl/{u-boot-spl.lds,u-boot.lst}
- @rm -f $(obj)MLO
+ @rm -f $(obj)MLO MLO.byteswap
@rm -f $(obj)SPL
@rm -f $(obj)tools/xway-swap-bytes
@rm -f $(obj)arch/powerpc/cpu/mpc824x/bedbug_603e.c
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx53loco: Fix PMIC name
On Wed, Dec 26, 2012 at 11:51 AM, Robert Nelson wrote: > On Wed, Dec 26, 2012 at 11:21 AM, Fabio Estevam wrote: >> On Wed, Dec 26, 2012 at 3:08 PM, Robert Nelson >> wrote: >> >>> I'll keep debugging it here, did reverting this commit, help with the >>> resets? >>> http://git.denx.de/?p=u-boot.git;a=commit;h=28e5ac2d974547bde0c72aa0c1d66fd22c6ef3ad >> >> Tried reverting it and still see the data-aborts. >> >> I am also testing on my mx53loco board with the mc34708 pmic and I see >> that it hangs on boot about 10% of the attempts: >> U-Boot 2013.01-rc2-00172-gf8cfcf1-dirty (Dec 26 2012 - 15:15:27) >> >> Board: MX53 LOCO >> I2C: ready >> DRAM: 1 GiB >> MMC: FSL_SDHC: 0, FSL_SDHC: 1 >> >> This did not happen prior to commit c73368150 (pmic: Extend PMIC >> framework to support multiple instances >> of PMIC devices). > > Okay, now we are on the same page, upgraded to: > "arm-linux-gnueabihf-gcc (crosstool-NG > linaro-1.13.1-4.7-2012.12-20121214 - Linaro GCC 2012.12) 4.7.3 > 20121205 (prerelease)".. > > With your Dialog patch, it is properly setting 1Ghz, and just keeps > rebooting.. :) > > U-Boot 2013.01-rc2-00173-ga0d04f3 (Dec 26 2012 - 11:47:34) > > Board: MX53 LOCO > I2C: ready > DRAM: 1 GiB > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > *** Warning - bad CRC, using default environment > In:serial > Out: serial > Err: serial > CPU: Freescale i.MX53 family rev2.0 at 1000 MHz > Reset cause: WDOG > Net: FEC > Warning: FEC using MAC address from net device > > Hit any key to stop autoboot: 0 > > data abort > MAYBE you should read doc/README.arm-unaligned-accesses > pc : [] lr : [] > sp : af565d68 ip : fff4 fp : > r10: 0003 r9 : affab8d9 r8 : af565f58 > r7 : r6 : e5bc345d r5 : af6df330 r4 : e5bc345d > r3 : af6df334 r2 : af6df333 r1 : r0 : af6df330 > Flags: nzCv IRQs off FIQs off Mode SVC_32 > > Resetting CPU ... > resetting ... Okay success on another bisect run to find what was causing the Data Abort with linaro's gcc toolchain.. gcc version 4.7.3 20121205 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2012.12-20121214 - Linaro GCC 2012.12) Reverting, Troy's last 4 imximage changes: ab857f2613be39274d0870768720067ff9d859c0 (imximage: make set_imx_hdr_v1/v2 easier to read) ad0826dcd81ba6cf4cc93a4ca8337e1bc676c238 (imximage: change parameters to set_imx_hdr) 243319825fa6e79885d57b6b78e72f3fe10ef69c (imximage: delay setting of image size) 348ca8efb79652d2b259fbd0ed6d317a77a8cbb9 (imximage: fix size of image to load.) (this was the first bad bisect, the previous 3 are needed for a clean revert) Along with Fabio's "mx53loco: Call PMIC related functions from board_late_init()" The Dialog based mx53loco is no operating correctly with linaro's toolchain... U-Boot 2013.01-rc2-00176-gbc67175-dirty (Jan 02 2013 - 12:14:51) Board: MX53 LOCO I2C: ready DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial CPU: Freescale i.MX53 family rev2.0 at 1000 MHz Reset cause: POR Net: FEC Warning: FEC using MAC address from net device Hit any key to stop autoboot: 0 mmc0 is current device ** Unrecognized filesystem type ** ** Unrecognized filesystem type ** Booting from net ... BOOTP broadcast 1 Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx53loco: Fix PMIC name
On Wed, Jan 2, 2013 at 4:27 PM, Robert Nelson wrote: > Okay success on another bisect run to find what was causing the Data > Abort with linaro's gcc toolchain.. > gcc version 4.7.3 20121205 (prerelease) (crosstool-NG > linaro-1.13.1-4.7-2012.12-20121214 - Linaro GCC 2012.12) > > Reverting, Troy's last 4 imximage changes: > > ab857f2613be39274d0870768720067ff9d859c0 (imximage: make > set_imx_hdr_v1/v2 easier to read) > ad0826dcd81ba6cf4cc93a4ca8337e1bc676c238 (imximage: change parameters > to set_imx_hdr) > 243319825fa6e79885d57b6b78e72f3fe10ef69c (imximage: delay setting of image > size) > 348ca8efb79652d2b259fbd0ed6d317a77a8cbb9 (imximage: fix size of image > to load.) (this was the first bad bisect, the previous 3 are needed > for a clean revert) > > Along with Fabio's "mx53loco: Call PMIC related functions from > board_late_init()" > > The Dialog based mx53loco is no operating correctly with linaro's toolchain... > > U-Boot 2013.01-rc2-00176-gbc67175-dirty (Jan 02 2013 - 12:14:51) > > Board: MX53 LOCO > I2C: ready > DRAM: 1 GiB > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > *** Warning - bad CRC, using default environment > > In:serial > Out: serial > Err: serial > CPU: Freescale i.MX53 family rev2.0 at 1000 MHz > Reset cause: POR > Net: FEC > Warning: FEC using MAC address from net device > > Hit any key to stop autoboot: 0 > mmc0 is current device > ** Unrecognized filesystem type ** > ** Unrecognized filesystem type ** > Booting from net ... > BOOTP broadcast 1 Thanks for bisecting, Robert. Troy/Stefano, Any suggestions about this? It would be really nice if we could keep mx53loco functional when using gcc 4.6.2. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] drivers/block/systemace: fixes read/write words for bus width = 8
From: Alexey Brodkin Current implementation works fine for bus width = 16 bits because we never get into "if" branch. If one sets width to 8 bits there will be 2 consequent data accesses (read/write): 1. Correct data access for 8-bit bus 2. Unconditional (and in this case incorrect) data access as if data bus is 16-bit wide Signed-off-by: Alexey Brodkin --- drivers/block/systemace.c |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/block/systemace.c b/drivers/block/systemace.c index 247cf06..88561a7 100644 --- a/drivers/block/systemace.c +++ b/drivers/block/systemace.c @@ -66,7 +66,8 @@ static void ace_writew(u16 val, unsigned off) writeb(val >> 8, base + off + 1); #endif } - out16(base + off, val); + else + out16(base + off, val); } static u16 ace_readw(unsigned off) @@ -78,8 +79,8 @@ static u16 ace_readw(unsigned off) return readb(base + off) | (readb(base + off + 1) << 8); #endif } - - return in16(base + off); + else + return in16(base + off); } static unsigned long systemace_read(int dev, unsigned long start, -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] drivers/block/systemace: replaced in16/out16 with more common readw/writew macros
Most architectures don't have symbols "in16"/"out16" defined. Only Microblaze/PowerPC/Spark architectures do have them defined. At the same time there're much more common macros "readw"/"writew" for 16-bit data access defined in most of architectures (in linux kernel header "io.h"). So use of "readw"/"writew" makes it possible to build this driver for virtually any architecture. Signed-off-by: Alexey Brodkin --- drivers/block/systemace.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/block/systemace.c b/drivers/block/systemace.c index 88561a7..32c9169 100644 --- a/drivers/block/systemace.c +++ b/drivers/block/systemace.c @@ -67,7 +67,7 @@ static void ace_writew(u16 val, unsigned off) #endif } else - out16(base + off, val); + writew(val, base + off); } static u16 ace_readw(unsigned off) @@ -80,7 +80,7 @@ static u16 ace_readw(unsigned off) #endif } else - return in16(base + off); + return readw(base + off); } static unsigned long systemace_read(int dev, unsigned long start, -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/block/systemace: fixes read/write words for bus width = 8
The reason for latter modification is to make code more readable. Do you think if I may submit this as a cosmetic change separately? 2013/1/2 Michal Simek > 2013/1/2 Alexey Brodkin : > > From: Alexey Brodkin > > > > Current implementation works fine for bus width = 16 bits because we > > never get into "if" branch. > > > > If one sets width to 8 bits there will be 2 consequent data accesses > > (read/write): > > 1. Correct data access for 8-bit bus > > 2. Unconditional (and in this case incorrect) data access as if data bus > > is 16-bit wide > > > > Signed-off-by: Alexey Brodkin > > --- > > drivers/block/systemace.c |7 --- > > 1 file changed, 4 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/block/systemace.c b/drivers/block/systemace.c > > index 247cf06..88561a7 100644 > > --- a/drivers/block/systemace.c > > +++ b/drivers/block/systemace.c > > @@ -66,7 +66,8 @@ static void ace_writew(u16 val, unsigned off) > > writeb(val >> 8, base + off + 1); > > #endif > > } > > - out16(base + off, val); > > + else > > + out16(base + off, val); > > } > > yes > > > > static u16 ace_readw(unsigned off) > > @@ -78,8 +79,8 @@ static u16 ace_readw(unsigned off) > > return readb(base + off) | (readb(base + off + 1) << 8); > > #endif > > } > > - > > - return in16(base + off); > > + else > > + return in16(base + off); > > } > > No need to use it - because for width=8 it will return above. > > M > > > > > -- > Michal Simek, Ing. (M.Eng) > w: www.monstr.eu p: +42-0-721842854 > Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ > Maintainer of Linux kernel - Xilinx Zynq ARM architecture > Microblaze U-BOOT custodian > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tools: imximage: Let .name field be more generic
From: Fabio Estevam
Since this structure is not i.MX5x specific, remove the '5x' to make it more
generic.
Signed-off-by: Fabio Estevam
---
tools/imximage.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/imximage.c b/tools/imximage.c
index 63f88b6..80ff66b 100644
--- a/tools/imximage.c
+++ b/tools/imximage.c
@@ -544,7 +544,7 @@ int imximage_check_params(struct mkimage_params *params)
* imximage parameters
*/
static struct image_type_params imximage_params = {
- .name = "Freescale i.MX 5x Boot Image support",
+ .name = "Freescale i.MX Boot Image support",
.header_size= sizeof(struct imx_header),
.hdr= (void *)&imximage_header,
.check_image_type = imximage_check_image_types,
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/block/systemace: fixes read/write words for bus width = 8
Actually I meant to respin both patches. 1. Only add "else" thread for "ace_writew", keeping "ace_readw" unchanged 2. Replace "in16"/"out16" with "readw"/"writew" 2013/1/2 Michal Simek > Hi, > > 2013/1/2 Алексей Бродкин : > > The reason for latter modification is to make code more readable. > > Do you think if I may submit this as a cosmetic change separately? > > If you mean create 3rd patch then no. > > Thanks, > Michal > > > -- > Michal Simek, Ing. (M.Eng) > w: www.monstr.eu p: +42-0-721842854 > Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ > Maintainer of Linux kernel - Xilinx Zynq ARM architecture > 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] mx53loco: Fix PMIC name
On 1/2/2013 11:33 AM, Fabio Estevam wrote:
Thanks for bisecting, Robert. Troy/Stefano, Any suggestions about
this? It would be really nice if we could keep mx53loco functional
when using gcc 4.6.2. Regards, Fabio Estevam
Could you see if this patch makes any difference? It still needs cleaned
up some before mainline
[PATCH V4 01/11] imximage: mx53 needs transfer length a multiple of 512
diff --git a/tools/imximage.c b/tools/imximage.c
index 63f88b6..7e54e97 100644
--- a/tools/imximage.c
+++ b/tools/imximage.c
@@ -494,6 +494,8 @@ static void imximage_print_header(const void *ptr)
}
}
+#define ALIGN(a, b) (((a) + (b) - 1) & ~((b) - 1))
+
static void imximage_set_header(void *ptr, struct stat *sbuf, int ifd,
struct mkimage_params *params)
{
@@ -515,7 +517,13 @@ static void imximage_set_header(void *ptr, struct stat
*sbuf, int ifd,
/* Set the imx header */
(*set_imx_hdr)(imxhdr, dcd_len, params->ep, imxhdr->flash_offset);
- *header_size_ptr = sbuf->st_size + imxhdr->flash_offset;
+ /*
+* ROM bug alert
+* mx53 only loads 512 byte multiples.
+* The remaining fraction of a block bytes would
+* not be loaded.
+*/
+ *header_size_ptr = ALIGN(sbuf->st_size + imxhdr->flash_offset, 512);
}
int imximage_check_params(struct mkimage_params *params)
-- 1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx53loco: Fix PMIC name
On Wed, Jan 2, 2013 at 1:42 PM, Troy Kisky
wrote:
> On 1/2/2013 11:33 AM, Fabio Estevam wrote:
>>
>> Thanks for bisecting, Robert. Troy/Stefano, Any suggestions about this? It
>> would be really nice if we could keep mx53loco functional when using gcc
>> 4.6.2. Regards, Fabio Estevam
>
> Could you see if this patch makes any difference? It still needs cleaned up
> some before mainline
> [PATCH V4 01/11] imximage: mx53 needs transfer length a multiple of 512
>
> diff --git a/tools/imximage.c b/tools/imximage.c
> index 63f88b6..7e54e97 100644
> --- a/tools/imximage.c
> +++ b/tools/imximage.c
> @@ -494,6 +494,8 @@ static void imximage_print_header(const void *ptr)
> }
> }
> +#define ALIGN(a, b) (((a) + (b) - 1) & ~((b) - 1))
> +
> static void imximage_set_header(void *ptr, struct stat *sbuf, int ifd,
> struct mkimage_params *params)
> {
> @@ -515,7 +517,13 @@ static void imximage_set_header(void *ptr, struct stat
> *sbuf, int ifd,
> /* Set the imx header */
> (*set_imx_hdr)(imxhdr, dcd_len, params->ep, imxhdr->flash_offset);
> - *header_size_ptr = sbuf->st_size + imxhdr->flash_offset;
> + /*
> +* ROM bug alert
> +* mx53 only loads 512 byte multiples.
> +* The remaining fraction of a block bytes would
> +* not be loaded.
> +*/
> + *header_size_ptr = ALIGN(sbuf->st_size + imxhdr->flash_offset, 512);
> }
> int imximage_check_params(struct mkimage_params *params)
> -- 1.7.9.5
Sweet! Thanks Troy,
That fixes it on my Dialog based mx53loco with linaro's 4.7.3 gcc toolchain...
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx53loco: Fix PMIC name
On Wed, Jan 2, 2013 at 5:58 PM, Robert Nelson wrote: > Sweet! Thanks Troy, > > That fixes it on my Dialog based mx53loco with linaro's 4.7.3 gcc toolchain... Excellent, Troy! Fixes the issue for me with gcc 4.6.2 as well. It would be really nice to have this one applied for 2013.01. Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC]: always relocate u-boot before the framebuffer
Dear Tom, In message <20130102154854.GC14738@bill-the-cat> you wrote: > > > Please see my responses. This is definitely NOT a good idea, it will > > break most (all?) boards that use CONFIG_FB_ADDR in the way it was > > intended for. > > I think this means we've got people not understanding what the variable > IS for. And at the high level, the idea of "lets transition from U-Boot > to Linux without a flicker" is good. So, what is the variables we > should be using for this, today? Or do we need to add and document > more? Or are we all just failing to RTFM here? I think the key problem is insufficient documentation of what CONFIG_FB_ADDR is intended for (i. e. graphics controllers with external video RAM). Eventualy a patch as attached might help? The idea of "lets transition from U-Boot to Linux without a flicker" is as old as PPCBoot (i. e. even predates U-Boot). The standard mechanism as implemented should work out of the box, assuming that both U-Boot and Linux use the same configuration of the graphics controller (resulting in the same size of the needed frame buffer memory). And if they use different configurations, you won't be able to pass a pre-initialized frame buffer ayway. The problem Jeroen ran into is/was caused by the fct that U-Boot and Linux computed different sizes for the frame buffer. I think this is either a bug, or a difference in the configuration, but Jeroen did not reply to my question for the reason for this difference yet. Best regards, Wolfgang Denk Suggested doc patch: >From ede2e170bd6c4b4ab6a3b7752400eb8afe0fdec9 Mon Sep 17 00:00:00 2001 From: Wolfgang Denk Date: Wed, 2 Jan 2013 21:10:29 +0100 Subject: [PATCH] VIDEO: better document the correct use of CONFIG_FB_ADDR Signed-off-by: Wolfgang Denk cc: Anatolij Gustschin --- README | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/README b/README index 78f40df..f84108e 100644 --- a/README +++ b/README @@ -2695,11 +2695,14 @@ FIT uImage format: - Frame Buffer Address: CONFIG_FB_ADDR - Define CONFIG_FB_ADDR if you want to use specific - address for frame buffer. - Then system will reserve the frame buffer address to - defined address instead of lcd_setmem (this function - grabs the memory for frame buffer by panel's size). +Define CONFIG_FB_ADDR if you want to use specific +address for frame buffer. This is typically the case +when using a graphics controller has separate video +memory. U-Boot will then reserve the frame buffer at +the given address instead of dynamically reserving it +in system RAM by calling lcd_setmem(), which grabs +the memory for the frame buffer depending on the +configured panel size. Please see board_init_f function. -- 1.7.11.7 -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The shortest unit of time in the multiverse is the News York Second, defined as the period of time between the traffic lights turning green and the cab behind you honking. - Terry Pratchett, _Lords and Ladies_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/block/systemace: replaced in16/out16 with more common readw/writew macros
Dear Alexey Brodkin, In message <1357139186-9172-1-git-send-email-alexey.brod...@gmail.com> you wrote: > Most architectures don't have symbols "in16"/"out16" defined. > Only Microblaze/PowerPC/Spark architectures do have them defined. > > At the same time there're much more common macros "readw"/"writew" for > 16-bit data access defined in most of architectures (in > linux kernel header "io.h"). > > So use of "readw"/"writew" makes it possible to build this driver for > virtually any architecture. > > Signed-off-by: Alexey Brodkin Did you actually test this on - say - any PowerPC board? To my understanding, in16() / out16() perform big endian accesses (i. e. direct load / store operations) on PowerPC, while readw / writew do byte-swapping (for accessling little-endian things like PCI busses). I speculate that this patch will break all big-endian systems. 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 are three principal ways to lose money: wine, women, and engi- neers. While the first two are more pleasant, the third is by far the more certain." - Baron Rothschild, ca. 1800 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/block/systemace: fixes read/write words for bus width = 8
Dear Alexey Brodkin, In message <1357137512-8618-1-git-send-email-alexey.brod...@gmail.com> you wrote: > From: Alexey Brodkin > > Current implementation works fine for bus width = 16 bits because we > never get into "if" branch. > > If one sets width to 8 bits there will be 2 consequent data accesses > (read/write): > 1. Correct data access for 8-bit bus > 2. Unconditional (and in this case incorrect) data access as if data bus > is 16-bit wide Sorry, I don't get this. You say, if one sets width to 8 bits, then the code fails when the bus is actually 16 bits wide? But this is just a bad configuration then - why do we need to change the code? All that is needed is to run with a correct configuration? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Real programmers can write assembly code in any language. :-) - Larry Wall in <8...@jpl-devvax.jpl.nasa.gov> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] Tegra30: clocks: Fix clock tables for I2C and other periphs
On 12/21/2012 05:16 PM, Tom Warren wrote: > Add 16-bit divider support (I2C) to periph table, annotate and > correct some entries, and fix clk_id lookup function. > diff --git a/arch/arm/cpu/tegra30-common/clock.c > b/arch/arm/cpu/tegra30-common/clock.c > - TYPE(PERIPHC_TSENSOR, CLOCK_TYPE_PCM), > + TYPE(PERIPHC_TSENSOR, CLOCK_TYPE_PCST), /* s/b PCTS */ It is now, so I assume that comment is stale? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] Tegra30: fdt: Update DT files with I2C info for T30/Cardhu
On 12/21/2012 05:16 PM, Tom Warren wrote:
> Note that T30 does not have a separate/different DVC (power I2C)
> controller like T20 - all 5 I2C controllers are identical, but
> DVC_I2C is still used to designate the controller intended for
> power control (PWR_I2C in the schematics). On Cardhu, it's used
> to access the PMU and EEPROM, as well as the audio codec, temp
> sensor, and fuel gauge devices from the OS.
> diff --git a/arch/arm/dts/tegra30.dtsi b/arch/arm/dts/tegra30.dtsi
> + tegra_car: clock@60006000 {
> + compatible = "nvidia,tegra30-car", "nvidia,tegra20-car";
> + reg = <0x60006000 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + clocks {
It'd be nice to keep the DT nodes sorted in the same order they are in
the kernel. There, the rules are that nodes appears in order:
1) Any nodes from /include/d files, in the order they appeared in the
underlying file.
2) Any nodes with a reg property, in order of the address in the reg
property.
3) Any nodes without a reg property, in alphabetical order by node name.
This will allow the U-Boot and kernel DT files to be more easily
compared/diff'd.
The clocks and osc node would usually be part of the board file, not the
SoC file, I believe...
Actually, the clocks "osc" and (later) "clk_32k" don't appear to be used
anywhere; can we just drop their nodes until if/when they are?
> + i2c@7000c000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "nvidia,tegra30-i2c", "nvidia,tegra20-i2c";
> + reg = <0x7000C000 0x100>;
> + /* PERIPH_ID_I2C1, CLK_M */
> + clocks = <&tegra_car 12>;
> + };
I think we should use lower-case for all hex constants in the DT. Also,
can the properties appear in the same order as in the kernel DT files so
they're easier to compare/diff.
Also, the SoC .dtsi file should have status="disabled" for all the
optionally-used HW modules, and the board files set status="okay" for
those that the board actually uses.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] Tegra30: I2C: Enable I2C driver on Cardhu
On 12/21/2012 05:16 PM, Tom Warren wrote: > Tested all 5 'buses', i2c probe enumerates device addresses on all > but dev 4 (I2C4) [no devices on that bus on my Cardhu]. > > Note that this uses the extant tegra_i2c.c driver w/o modification. Aside from previous comments, Reviewed-by: Stephen Warren ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] Tegra30: clocks: Fix clock tables for I2C and other periphs
No, it's now PCST, which is close as I can get to PCTS w/o adding a whole new clock_type entry for just this one piece of HW, which isn't used in U-Boot anyway. PCST is PLLP, PLLC, CLK_S, and CLK_M. PCTS is PLLP, PLLC, CLK_M and CLK_S. On Wed, Jan 2, 2013 at 1:35 PM, Stephen Warren wrote: > On 12/21/2012 05:16 PM, Tom Warren wrote: >> Add 16-bit divider support (I2C) to periph table, annotate and >> correct some entries, and fix clk_id lookup function. > >> diff --git a/arch/arm/cpu/tegra30-common/clock.c >> b/arch/arm/cpu/tegra30-common/clock.c > >> - TYPE(PERIPHC_TSENSOR, CLOCK_TYPE_PCM), >> + TYPE(PERIPHC_TSENSOR, CLOCK_TYPE_PCST), /* s/b PCTS */ > > It is now, so I assume that comment is stale? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] Tegra30: fdt: Update DT files with I2C info for T30/Cardhu
Alrightly. Can you send me a link to the latest-and-greatest
T30/Cardhu kernel DT files so I can use 'em as a reference? Every time
I do a Google search for kernel files I'm never sure if I've got the
latest one or not.
Thanks
On Wed, Jan 2, 2013 at 1:41 PM, Stephen Warren wrote:
> On 12/21/2012 05:16 PM, Tom Warren wrote:
>> Note that T30 does not have a separate/different DVC (power I2C)
>> controller like T20 - all 5 I2C controllers are identical, but
>> DVC_I2C is still used to designate the controller intended for
>> power control (PWR_I2C in the schematics). On Cardhu, it's used
>> to access the PMU and EEPROM, as well as the audio codec, temp
>> sensor, and fuel gauge devices from the OS.
>
>> diff --git a/arch/arm/dts/tegra30.dtsi b/arch/arm/dts/tegra30.dtsi
>
>> + tegra_car: clock@60006000 {
>> + compatible = "nvidia,tegra30-car", "nvidia,tegra20-car";
>> + reg = <0x60006000 0x1000>;
>> + #clock-cells = <1>;
>> + };
>> +
>> + clocks {
>
> It'd be nice to keep the DT nodes sorted in the same order they are in
> the kernel. There, the rules are that nodes appears in order:
>
> 1) Any nodes from /include/d files, in the order they appeared in the
> underlying file.
>
> 2) Any nodes with a reg property, in order of the address in the reg
> property.
>
> 3) Any nodes without a reg property, in alphabetical order by node name.
>
> This will allow the U-Boot and kernel DT files to be more easily
> compared/diff'd.
>
> The clocks and osc node would usually be part of the board file, not the
> SoC file, I believe...
>
> Actually, the clocks "osc" and (later) "clk_32k" don't appear to be used
> anywhere; can we just drop their nodes until if/when they are?
>
>> + i2c@7000c000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "nvidia,tegra30-i2c", "nvidia,tegra20-i2c";
>> + reg = <0x7000C000 0x100>;
>> + /* PERIPH_ID_I2C1, CLK_M */
>> + clocks = <&tegra_car 12>;
>> + };
>
> I think we should use lower-case for all hex constants in the DT. Also,
> can the properties appear in the same order as in the kernel DT files so
> they're easier to compare/diff.
>
> Also, the SoC .dtsi file should have status="disabled" for all the
> optionally-used HW modules, and the board files set status="okay" for
> those that the board actually uses.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] Tegra30: fdt: Update DT files with I2C info for T30/Cardhu
On 01/02/2013 01:58 PM, Tom Warren wrote: > Alrightly. Can you send me a link to the latest-and-greatest > T30/Cardhu kernel DT files so I can use 'em as a reference? Every time > I do a Google search for kernel files I'm never sure if I've got the > latest one or not. The easiest way is probably: git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git cd linux-2.6/arch/arm/boot/dts ls *cardhu* ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] mx53loco: Add support for SEIKO 4.3'' WVGA panel
From: Fabio Estevam
Add support for the Seiko 4.3'' WVGA panel on mx53loco.
By default, the CLAA WVGA panel is selected.
In order to support the Seiko panel, the enviroment variable 'panel' must be
set to 'seiko'.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Allow a single binary to support both CLAA and Seiko panels
board/freescale/mx53loco/mx53loco.c |2 --
board/freescale/mx53loco/mx53loco_video.c | 53 ++---
2 files changed, 49 insertions(+), 6 deletions(-)
diff --git a/board/freescale/mx53loco/mx53loco.c
b/board/freescale/mx53loco/mx53loco.c
index 63a4f8b..9635e62 100644
--- a/board/freescale/mx53loco/mx53loco.c
+++ b/board/freescale/mx53loco/mx53loco.c
@@ -463,8 +463,6 @@ int board_init(void)
mxc_set_sata_internal_clock();
setup_iomux_i2c();
- lcd_enable();
-
return 0;
}
diff --git a/board/freescale/mx53loco/mx53loco_video.c
b/board/freescale/mx53loco/mx53loco_video.c
index 69991e8..f02c0e5 100644
--- a/board/freescale/mx53loco/mx53loco_video.c
+++ b/board/freescale/mx53loco/mx53loco_video.c
@@ -46,6 +46,21 @@ static struct fb_videomode const claa_wvga = {
.vmode = FB_VMODE_NONINTERLACED
};
+static struct fb_videomode const seiko_wvga = {
+ .name = "Seiko-43WVF1G",
+ .refresh= 60,
+ .xres = 800,
+ .yres = 480,
+ .pixclock = 29851, /* picosecond (33.5 MHz) */
+ .left_margin= 89,
+ .right_margin = 164,
+ .upper_margin = 23,
+ .lower_margin = 10,
+ .hsync_len = 10,
+ .vsync_len = 10,
+ .sync = 0,
+};
+
void setup_iomux_lcd(void)
{
mxc_request_iomux(MX53_PIN_DI0_DISP_CLK, IOMUX_CONFIG_ALT0);
@@ -86,9 +101,39 @@ void setup_iomux_lcd(void)
gpio_direction_output(IOMUX_TO_GPIO(MX53_PIN_GPIO_1), 1);
}
-void lcd_enable(void)
+int board_video_skip(void)
{
- int ret = ipuv3_fb_init(&claa_wvga, 0, IPU_PIX_FMT_RGB565);
- if (ret)
- printf("LCD cannot be configured: %d\n", ret);
+ int ret;
+ char const *e = getenv("panel");
+
+ if (!e) {
+ /* 'panel' env variable not found. Default to 'claa' lcd */
+ ret = ipuv3_fb_init(&claa_wvga, 0, IPU_PIX_FMT_RGB565);
+ if (ret)
+ printf("LCD cannot be configured: %d\n", ret);
+ return ret;
+
+ } else { /* 'panel' env variable is found */
+ if (strcmp(e, "claa") == 0) {
+ ret = ipuv3_fb_init(&claa_wvga, 0, IPU_PIX_FMT_RGB565);
+ if (ret)
+ printf("LCD cannot be configured: %d\n", ret);
+ return ret;
+ }
+
+ if (strcmp(e, "seiko") == 0) {
+ ret = ipuv3_fb_init(&seiko_wvga, 0, IPU_PIX_FMT_RGB24);
+ if (ret)
+ printf("LCD cannot be configured: %d\n", ret);
+ return ret;
+ }
+ /*
+* If 'panel' variable has a value different then
+* 'claa' or 'seiko' then setup as 'claa' lcd by default
+*/
+ ret = ipuv3_fb_init(&claa_wvga, 0, IPU_PIX_FMT_RGB565);
+ if (ret)
+ printf("LCD cannot be configured: %d\n", ret);
+ return ret;
+ }
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] omap4: use plain text env file instead boot scripts
On Wed, Jan 2, 2013 at 3:39 PM, Tom Rini wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 12/25/12 09:15, Javier Martinez Canillas wrote: >> Based on commit cf073e49bc3502be1b48a0e3faf0cde9edbb89db for >> beagleboard >> >> Using the new env import command it is possible to use plain text >> files instead of script-images. Plain text files are much easier >> to handle. > > The only problem I see with this is that in beagle-land there was some > regret we didn't make this an either/or. In other words, look for > uEnv.txt, if found, use it, otherwise see if we have a boot.scr, if so > use it, and if we still haven't been then keep trying a "normal" boot > from MMC. This means we don't break existing users (or distributions) > that had been relying on boot.scr being used automatically. > > - -- > Tom Hi Tom, I see, I'll post a v2 then that fallbacks to boot.scr in case uEnv.txt is not found. I'll post a patch to fix the beagle and IGEP boards as well. Thanks a lot and best regards, Javier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-x86.git
On Wed, Dec 26, 2012 at 10:42:25AM -0800, Simon Glass wrote: > Hi Tom, > > These are the two that patchwork somehow missed. They are in there > now, so here is the pull request for those two. > > > The following changes since commit f8cfcf1b1c7543d5dd103359376a3319301143bc: > > env: don't generate callback list entries for SPL (2012-12-22 05:57:16 > -0700) > > are available in the git repository at: > git://git.denx.de/u-boot-x86.git master > > Simon Glass (1): > x86: coreboot: Enable io command > > Stefan Reinauer (1): > x86: Add coreboot version to u-boot's version command > > common/cmd_version.c |7 ++- > include/configs/coreboot.h |1 + > 2 files changed, 7 insertions(+), 1 deletions(-) Applied, 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 v2] spl:falcon:trats Update Trats default board configuration file to support FALCON MODE
On 03/01/13 01:06, Lukasz Majewski wrote:
> Support for a new command (defined at envs) - spl_export generates
> the ATAGS image necessary for fast boot. Afterwards, it is stored
> at ext4 partition.
>
> Generated image format:
> CRC [4B] SIZE [4B] PAYLOAD(ATAGS/DT) [SIZE]
>
> Remarks:
> - CRC is calculated only for PAYLOAD
> - SIZE is the size of PAYLOAD
>
> It is important to adjust ${splsize} when large image is generated.
> It is defined as hex, since ext4 related commands expect it.
>
> The ${spladdr} environment variable corresponds to
> CONFIG_SYS_SPL_ARGS_ADDR
>
> Additionally definitions for DFU have been refactored and support for
> EFI has been added as well.
>
> Signed-off-by: Lukasz Majewski
> Signed-off-by: Kyungmin Park
> Cc: Minkyu Kang
> ---
> Changes for v2:
> - Rebase the code on the newest master branch
> ---
> board/samsung/trats/trats.c |2 +-
> include/configs/trats.h | 45 +-
> 2 files changed, 36 insertions(+), 11 deletions(-)
>
applied to u-boot-samsung/master
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][RFC] MTD resync from Linux-3.8-rc2+ (master)
Subject line should be something like
"mtd: sync NAND and mtdcore with Linux v3.8-rc2".
What is in v3.8-rc2 that you need? I agree with others that we should
sync from stable versions.
On 12/28/2012 05:19:17 AM, Sergey Lapin wrote:
Signed-off-by: Sergey Lapin
---
Warning: no testing, except for single board,
was made with this patch.
It is just basic resync for NAND parts of MTD with some modifications
to mtdcore
I tried to be as close to original as possible.
What is the code size change with this patch?
diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 543c845..ba1e22a 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -25,7 +25,9 @@ include $(TOPDIR)/config.mk
LIB:= $(obj)libmtd.o
-COBJS-$(CONFIG_MTD_DEVICE) += mtdcore.o
+ifneq (,$(findstring y,$(CONFIG_MTD_DEVICE)$(CONFIG_CMD_NAND)))
+COBJS-y += mtdcore.o
+endif
So NAND now depends on mtdcore... what changed to make this necessary?
And shouldn't we fix board files to include both, rather than hack up
the makefiles in this one spot?
What about the #ifdef CONFIG_MTD_DEVICE in drivers/mtd/nand/nand.c?
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 3a81ada..1e722a1 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -9,6 +9,7 @@
#include
#include
+#include
#include
struct mtd_info *mtd_table[MAX_MTD_DEVICES];
@@ -32,6 +33,30 @@ int add_mtd_device(struct mtd_info *mtd)
our caller is still holding us here. So none
of this try_ nonsense, and no bitching about
it
either. :) */
+ /* default value if not set by driver */
+ if (mtd->bitflip_threshold == 0)
+mtd->bitflip_threshold =
mtd->ecc_strength;
+
+ if (is_power_of_2(mtd->erasesize))
+mtd->erasesize_shift =
ffs(mtd->erasesize) - 1;
+ else
+ mtd->erasesize_shift = 0;
+
+ if (is_power_of_2(mtd->writesize))
+mtd->writesize_shift =
ffs(mtd->writesize) - 1;
+ else
+ mtd->writesize_shift = 0;
+
+ mtd->erasesize_mask = (1 <<
mtd->erasesize_shift) - 1;
+ mtd->writesize_mask = (1 <<
mtd->writesize_shift) - 1;
+ if ((mtd->flags & MTD_WRITEABLE) && (mtd->flags
& MTD_POWERUP_LOCK)) {
+ int error;
+ error = mtd_unlock(mtd, 0, mtd->size);
+ if (error && error != -EOPNOTSUPP)
+ printk(KERN_WARNING
+ "%s: unlock failed,
writes may not work\n",
+ mtd->name);
+ }
return 0;
}
Please factor this out into its own function that can look more like
Linux's add_mtd_device(), and have U-Boot's add_mtd_device() just be a
wrapper that does the loop and calls the internal function when it finds
a slot.
+int mtd_device_parse_register(struct mtd_info *mtd, const char
**types,
+ struct mtd_part_parser_data *parser_data,
+ const struct mtd_partition *parts,
+ int nr_parts)
+{
+ int err;
+#ifdef CONFIG_MTD_PARTITIONS
+ struct mtd_partition *real_parts;
+
+ err = parse_mtd_partitions(mtd, types, &real_parts,
parser_data);
+ if (err <= 0 && nr_parts && parts) {
+ real_parts = kmemdup(parts, sizeof(*parts) * nr_parts,
+GFP_KERNEL);
+ if (!real_parts)
+ err = -ENOMEM;
+ else
+ err = nr_parts;
+ }
+
+ if (err > 0) {
+ err = add_mtd_partitions(mtd, real_parts, err);
+ kfree(real_parts);
+ } else if (err == 0) {
+ err = add_mtd_device(mtd);
+ if (err == 1)
+ err = -ENODEV;
+ }
+#else
+ err = add_mtd_device(mtd);
+ if (err == 1)
+ err = -ENODEV;
+#endif
I don't see parse_mtd_partitions() in U-Boot, before or after this
patch.
I think you're doing more than updating the version, and are bringing in
functionality that U-Boot previously excluded.
+/*
+ * This stuff for eXecute-In-Place. phys is optional and may be set
to NULL.
+ */
+int mtd_point(struct mtd_info *mtd, loff_t from, size_t len, size_t
*retlen,
+ void **virt, resource_size_t *phys)
Why do we need this in U-Boot?
+{
+ *retlen = 0;
+ *virt = NULL;
+ if (phys)
+ *phys = 0;
+ if (!mtd->_point)
+ return -EOPNOTSUPP;
+ if (from < 0 || from > mtd->size || len > mtd->size - from)
+ return -EINVAL;
+ if (!len)
+ return 0;
+ return mtd->_point(mtd, from, len, retlen, virt, phys);
+}
+/* We
Re: [U-Boot] [PATCH 1/1] serial/ns16550: check UART mode for TEMT value
On 12/23/2012 05:17:25 PM, Javier Martinez Canillas wrote:
On Sat, Dec 22, 2012 at 4:40 AM, Javier Martinez Canillas
wrote:
>
> But if I'm the only one having this issue maybe is just my hardware
behaving
> badly. I'll ask other OMAP3 users if they can boot with mainline
U-Boot to
> confirm this.
>
Hello,
I tested with an Beagleboard which is another OMAP3 board that has the
same PC16550D UART than my OMAP3 IGEPv2 and the board does not hang
while waiting for TEMT. I've also tested with an OMAP4 pandaboard and
it boots correctly too.
But the hung issue seems to not be an issue with my IGEPv2 board but
with any IGEPv2 board since another user reported that his board hangs
with the latest U-Boot too. Reverting cb55b332 (serial/ns16550: wait
for TEMT before initializing) solved the issue for him.
Will a patch like this be an acceptable solution?
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index bbd91ca..8106a9a 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -36,8 +36,10 @@
void NS16550_init(NS16550_t com_port, int baud_divisor)
{
+#if (CONFIG_MACH_TYPE != MACH_TYPE_IGEP0020)
while (!(serial_in(&com_port->lsr) & UART_LSR_TEMT))
;
+#endif
Probably better to have your board config file define
CONFIG_SYS_NS16550_BROKEN_TEMT or similar (and document the symbol in
README).
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PULL-REQ] MTD update
On 01/02/2013 09:33:33 AM, Tom Rini wrote: On Sun, Dec 30, 2012 at 08:24:00AM +0530, Vikram Narayanan wrote: > On 12/28/2012 7:29 PM, Tom Rini wrote: > >On Fri, Dec 28, 2012 at 07:17:42AM -0500, Sergey Lapin wrote: > > > >>Hi, all! > >> > >>As I failed to submit 250KB patch to the list > >>I will send this pull request > >> > >>This patch is not for inclusion yet. > >>This patch is just update of u-boot MTD with > >>Linux kernel's MTD v3.8-rc. > > > >First, while I appreciate the effort, I'd rather us sync with v3.7 > >release rather than the in-flux v3.8. Second, can you please look at > >the archives about how we've done these re-syncs before? I really don't > >want to take a single giant patch and we're usually able to break this > >up into chunks. Thanks! > > Can someone point to the exact thread where such discussion has > happened before? "git log driver/mtd/nand_base.c" and look for "sync". :-) > The re-sync has to happen addressing the bisect-ability as well. > > Already there was a discussion on syncing the UBI layer. So, if some > ideas are thrown, it would be beneficial for both MTD and UBI sync. What I was thinking of was: http://en.usenet.digipedia.org/thread/11185/23221/ http://en.usenet.digipedia.org/thread/11185/23218/ http://en.usenet.digipedia.org/thread/11185/28371/ But, from a lazy-poke of a single file, once we get out from the includes section of the files, some git format-patch'ing on the files we share with the kernel, between the last backport hash and v3.7 for example should be applicable with only a bit of hand fixing up. And if one wanted to do this slowly (3.0 to 3.1 to 3.2 to ...) it might be a little easier to manage. That's probably overkill, though breaking it into two or three version jumps would improve the ability to bisect where problems come from. In any case, the size of the patch should go down once it stops merging in things that were deliberately left out of U-Boot. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 4/9] EXYNOS5: DWMMC: Added FDT support for DWMMC
Hi Jaehoon,
Thanks for the comments.
Please find my response below.
Thanks & Regards
Amarendra
On 2 January 2013 10:50, Jaehoon Chung wrote:
> On 12/31/2012 07:58 PM, Amar wrote:
> > This patch adds FDT support for DWMMC, by reading the DWMMC node data
> > from the device tree and initialising DWMMC channels as per data
> > obtained from the node.
> >
> > Changes from V1:
> > 1)Updated code to have same signature for the function
> > exynos_dwmci_init() for both FDT and non-FDT versions.
> > 2)Updated code to pass device_id parameter to the function
> > exynos5_mmc_set_clk_div() instead of index.
> > 3)Updated code to decode the value of "samsung,width" from FDT.
> > 4)Channel index is computed instead of getting from FDT.
> >
> > Changes from V2:
> > 1)Updation of commit message and resubmition of proper patch set.
> >
> > Signed-off-by: Vivek Gautam
> > Signed-off-by: Amar
> > ---
> > arch/arm/include/asm/arch-exynos/dwmmc.h | 4 ++
> > drivers/mmc/exynos_dw_mmc.c | 116
> +--
> > include/dwmmc.h | 4 ++
> > 3 files changed, 117 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/arch-exynos/dwmmc.h
> b/arch/arm/include/asm/arch-exynos/dwmmc.h
> > index 8acdf9b..40dcc7b 100644
> > --- a/arch/arm/include/asm/arch-exynos/dwmmc.h
> > +++ b/arch/arm/include/asm/arch-exynos/dwmmc.h
> > @@ -29,8 +29,12 @@
> >
> > int exynos_dwmci_init(u32 regbase, int bus_width, int index);
> >
> > +#ifdef CONFIG_OF_CONTROL
> > +unsigned int exynos_dwmmc_init(const void *blob);
> > +#else
> > static inline unsigned int exynos_dwmmc_init(int index, int bus_width)
> > {
> > unsigned int base = samsung_get_base_mmc() + (0x1 * index);
> > return exynos_dwmci_init(base, bus_width, index);
> > }
> > +#endif
> > diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
> > index 72a31b7..541889f 100644
> > --- a/drivers/mmc/exynos_dw_mmc.c
> > +++ b/drivers/mmc/exynos_dw_mmc.c
> > @@ -19,39 +19,141 @@
> > */
> >
> > #include
> > -#include
> > #include
> > +#include
> > +#include
> > +#include
> > #include
> > #include
> > +#include
> > +
> > +#define DWMMC_MAX_CH_NUM4
> > +#define DWMMC_MAX_FREQ 5200
> > +#define DWMMC_MIN_FREQ 40
> > +#define DWMMC_MMC0_CLKSEL_VAL 0x03030001
> > +#define DWMMC_MMC2_CLKSEL_VAL 0x03020001
> >
> > static char *EXYNOS_NAME = "EXYNOS DWMMC";
> > +u32 timing[3];
> >
> > +/*
> > + * Function used as callback function to initialise the
> > + * CLKSEL register for every mmc channel.
> > + */
> > static void exynos_dwmci_clksel(struct dwmci_host *host)
> > {
> > - u32 val;
> > - val = DWMCI_SET_SAMPLE_CLK(DWMCI_SHIFT_0) |
> > - DWMCI_SET_DRV_CLK(DWMCI_SHIFT_0) | DWMCI_SET_DIV_RATIO(0);
> > + dwmci_writel(host, DWMCI_CLKSEL, host->clksel_val);
> > +}
> >
> > - dwmci_writel(host, DWMCI_CLKSEL, val);
> > +unsigned int exynos_dwmci_get_clk(int dev_index)
> > +{
> > + return get_mmc_clk(dev_index);
> > }
> >
> > int exynos_dwmci_init(u32 regbase, int bus_width, int index)
> > {
> > struct dwmci_host *host = NULL;
> > + int dev_id = 0;
> > host = malloc(sizeof(struct dwmci_host));
> > if (!host) {
> > printf("dwmci_host malloc fail!\n");
> > return 1;
> > }
> > + /* Convert index into corresponding peripheral ID */
> > + dev_id = index + PERIPH_ID_SDMMC0;
> Is it right at every case?
>
Yes, it is right in every case.
Consider the finction "int exynos_dwmci_init(u32 regbase, int bus_width,
int index)"
If the input argument 'index' is between (0-3), then the statement "dev_id
= index + PERIPH_ID_SDMMC0;" works good.
So, the function exynos_dwmci_init(u32 regbase, int bus_width, int index)
is being called as below
1) FDT Case:
The function exynos_dwmmc_init() calls exynos_dwmmc_init()
The dev_id is extracted from arch/arm/dts/exynos5250.dtsi. The dev_id is
nothing but the interrupt number.
dwmmc0 - dev_id = 75
dwmmc1 - dev_id = 76
dwmmc2 - dev_id = 77
dwmmc3 - dev_id = 78
At same time the enum values are (Refer
"arch/arm/include/asm/arch-exynos/periph.h")
PERIPH_ID_SDMMC0 = 75,
PERIPH_ID_SDMMC1,
PERIPH_ID_SDMMC2,
PERIPH_ID_SDMMC3,
Here "index = dev_id - PERIPH_ID_SDMMC0" works good for all channels
(mmc0 - mmc3)
As proper values are mentioned in arch/arm/dts/exynos5250.dtsi, proper
values of "index" (i.e 0 - 3) will be computed here.
2) Non-FDT case:
The function board_mmc_init() calls exynos_dwmmc_init() as shown below
int board_mmc_init(bd_t *bis)
{
/*EMMC: dwmmc Channel-0 with 8 bit bus width */
err = exynos_dwmmc_init(0, 8);
}
Here the coder shall ensure to pass proper index number (0 to 3) for porper
working.
> > +
> > + /* set the clock divisor - clk_div_fsys for mmc */
> > + if (
Re: [U-Boot] [PATCH V3 5/9] EXYNOS5: DWMMC: API to set mmc clock divisor
Hi Jaehoon
Thanks for the comments.
Please find my response below.
Than
On 2 January 2013 09:01, Jaehoon Chung wrote:
> Hi Amar,
>
> On 12/31/2012 07:58 PM, Amar wrote:
> > This API computes the divisor value based on MPLL clock and
> > writes it into the FSYS1 register.
> >
> > Changes from V1:
> > 1)Updated the function exynos5_mmc_set_clk_div() to receive
> > 'device_i'd as input parameter instead of 'index'.
> >
> > Changes from V2:
> > 1)Updation of commit message and resubmition of proper patch set.
> >
> > Signed-off-by: Amar
> > ---
> > arch/arm/cpu/armv7/exynos/clock.c | 38
> --
> > arch/arm/include/asm/arch-exynos/clk.h | 4
> > 2 files changed, 40 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/cpu/armv7/exynos/clock.c
> b/arch/arm/cpu/armv7/exynos/clock.c
> > index 973b84e..cd42689 100644
> > --- a/arch/arm/cpu/armv7/exynos/clock.c
> > +++ b/arch/arm/cpu/armv7/exynos/clock.c
> > @@ -490,7 +490,7 @@ static unsigned long exynos4_get_mmc_clk(int
> dev_index)
> > (struct exynos4_clock *)samsung_get_base_clock();
> > unsigned long uclk, sclk;
> > unsigned int sel, ratio, pre_ratio;
> > - int shift;
> > + int shift = 0;
> >
> > sel = readl(&clk->src_fsys);
> > sel = (sel >> (dev_index << 2)) & 0xf;
> > @@ -539,7 +539,7 @@ static unsigned long exynos5_get_mmc_clk(int
> dev_index)
> > (struct exynos5_clock *)samsung_get_base_clock();
> > unsigned long uclk, sclk;
> > unsigned int sel, ratio, pre_ratio;
> > - int shift;
> > + int shift = 0;
> >
> > sel = readl(&clk->src_fsys);
> > sel = (sel >> (dev_index << 2)) & 0xf;
> > @@ -659,6 +659,40 @@ static void exynos5_set_mmc_clk(int dev_index,
> unsigned int div)
> > writel(val, addr);
> > }
> >
> > +/* exynos5: set the mmc clock div ratio in fsys1 */
> > +int exynos5_mmc_set_clk_div(int dev_id)
> Why return the int type?
>
Yes, not required to return. I will update.
> > +{
> > + struct exynos5_clock *clk =
> > + (struct exynos5_clock *)samsung_get_base_clock();
> > + unsigned int addr;
> > + unsigned int clock;
> > + unsigned int tmp;
> > + unsigned int i;
> Can't use unsigned int addr, clock? We can save the line.
>
Ok.
> > +
> > + /* get mpll clock */
> > + clock = get_pll_clk(MPLL) / 100;
> > +
> > + /*
> > + * CLK_DIV_FSYS1
> > + * MMC0_PRE_RATIO [15:8], MMC0_RATIO [3:0]
> > + * CLK_DIV_FSYS2
> > + * MMC2_PRE_RATIO [15:8], MMC2_RATIO [3:0]
> > + */
> > + if (dev_id <= PERIPH_ID_SDMMC1)
> > + addr = (unsigned int)&clk->div_fsys1;
> > + else
> > + addr = (unsigned int)&clk->div_fsys2;
> > +
> > + tmp = readl(addr) & ~FSYS1_MMC0_DIV_MASK;
> FSYS1_MMC0_DIV_MASK? then case of MMC2?
> It is wrong macro name..You also used the clk->div_fsys2..
>
Yes, will change the macro name.
> > + for (i = 0; i <= 0xf; i++) {
> > + if ((clock / (i + 1)) <= 400) {
> > + writel(tmp | i << 0, addr);
> > + break;
> > + }
> > + }
> > + return 0;
> > +}
> I didn't understand this function(exynos5_mmc_set_clk_div?).
> What purpose? I think good that proper to use the "div" as argument.
> void exynos5_mmc_set_clk(int dev_id, unsigned int div).
For fixing dwmmc driver, I referred to working code from
"chromiumos/src/third_party/u-boot".
In chromium uboot, during mhci init, the function "clock_set_mshci()" is
called which is in "arch/arm/cpu/armv7/exynos5/clock.c"
Our function "*exynos5_mmc_set_clk_div()"* is same as "*clock_set_mshci()".*
Now coming to 'div' as argument we have the below scenarios / questions
1-> What is the value of 'div' to be passed from calling function ?
2-> The value of 'div' needs to be computed in calling function.
3-> As per my understanding, 'div' value depends on values of MPLL clock
and FSYS1/2.
4-> *Question:* Is it OK to put the piece of code which accesses MPLL,
FSYS1, FSYS2 in drivers/mmc/exynos_dw_mmc.c. ?
5-> If we compute 'div' value in "drivers/mmc/exynos_dw_mmc.c", then
there will be duplication of code (Read of FSYS1/2).
Please comment on the above.
> +
> /* get_lcd_clk: return lcd clock frequency */
> static unsigned long exynos4_get_lcd_clk(void)
> {
> diff --git a/arch/arm/include/asm/arch-exynos/clk.h
b/arch/arm/include/asm/arch-exynos/clk.h
> index 1935b0b..2fd7c3e 100644
> --- a/arch/arm/include/asm/arch-exynos/clk.h
> +++ b/arch/arm/include/asm/arch-exynos/clk.h
> @@ -29,6 +29,9 @@
> #define VPLL 4
> #define BPLL 5
>
> +#define FSYS1_MMC0_DIV_MASK 0xff0f
> +#define FSYS1_MMC0_DIV_VAL 0x0701
> +
> unsigned long get_pll_clk(int pllreg);
> unsigned long get_arm_clk(void);
> unsigned long get_i2c_clk(void);
> @@ -36,6 +39,7 @@ unsigned long get_pwm_clk(void);
> unsigned long get_uart_clk(int dev_index);
> unsigned long get_mmc_clk(int dev_index);
> vo
Re: [U-Boot] [PATCH V3 5/9] EXYNOS5: DWMMC: API to set mmc clock divisor
Hi Amar,
..snip..
>> I didn't understand this function(exynos5_mmc_set_clk_div?).
>> What purpose? I think good that proper to use the "div" as argument.
>> void exynos5_mmc_set_clk(int dev_id, unsigned int div).
>
>
> For fixing dwmmc driver, I referred to working code from
> "chromiumos/src/third_party/u-boot".
> In chromium uboot, during mhci init, the function "clock_set_mshci()" is
> called which is in "arch/arm/cpu/armv7/exynos5/clock.c"
>
> Our function "*exynos5_mmc_set_clk_div()"* is same as "*clock_set_mshci()".*
>
> Now coming to 'div' as argument we have the below scenarios / questions
> 1-> What is the value of 'div' to be passed from calling function ?
It will be the pre_ratio's value for FSYSx register.
> 2-> The value of 'div' needs to be computed in calling function.
It will be computed before called this function. For example, in dw_mmc.c or
exynos_dw_mc.c
> 3-> As per my understanding, 'div' value depends on values of MPLL clock
> and FSYS1/2.
Right..but it will be changed the source clock. MMC/SD can use the every source
clock.
> 4-> *Question:* Is it OK to put the piece of code which accesses MPLL,
> FSYS1, FSYS2 in drivers/mmc/exynos_dw_mmc.c. ?
Sure..we can use the get_mmc_clk/set_mmc_clk. then we can get source clock
value.
and compute the div value for request clock.
> 5-> If we compute 'div' value in "drivers/mmc/exynos_dw_mmc.c", then
> there will be duplication of code (Read of FSYS1/2).
What code is duplication? Could you explain to me more?
Only need to compute the div value in exynos_dw_mmc.c.
why need to compute into here?
Best Regards,
Jaehoon Chung
>
> Please comment on the above.
>
>> +
>> /* get_lcd_clk: return lcd clock frequency */
>> static unsigned long exynos4_get_lcd_clk(void)
>> {
>> diff --git a/arch/arm/include/asm/arch-exynos/clk.h
> b/arch/arm/include/asm/arch-exynos/clk.h
>> index 1935b0b..2fd7c3e 100644
>> --- a/arch/arm/include/asm/arch-exynos/clk.h
>> +++ b/arch/arm/include/asm/arch-exynos/clk.h
>> @@ -29,6 +29,9 @@
>> #define VPLL 4
>> #define BPLL 5
>>
>> +#define FSYS1_MMC0_DIV_MASK 0xff0f
>> +#define FSYS1_MMC0_DIV_VAL 0x0701
>> +
>> unsigned long get_pll_clk(int pllreg);
>> unsigned long get_arm_clk(void);
>> unsigned long get_i2c_clk(void);
>> @@ -36,6 +39,7 @@ unsigned long get_pwm_clk(void);
>> unsigned long get_uart_clk(int dev_index);
>> unsigned long get_mmc_clk(int dev_index);
>> void set_mmc_clk(int dev_index, unsigned int div);
>> +int exynos5_mmc_set_clk_div(int dev_index);
>> unsigned long get_lcd_clk(void);
>> void set_lcd_clk(void);
>> void set_mipi_clk(void);
>>
>
> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>
>
>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master
Hi Albert, 2012년 12월 22일 토요일에 Albert ARIBAUD님이 작성: > Hello Tom, > > The following changes since commit > 095728803eedfce850a2f85828f79500cb09979e: > > Merge branch 'master' of git://git.denx.de/u-boot-net (2012-12-17 > 18:39:50 -0700) > > are available in the git repository at: > > > git://git.denx.de/u-boot-arm master > > for you to fetch changes up to 96764df1b47ddebfb50fadf5af72530b07b5fc89: > > Merge samsung, imx, tegra into u-boot-arm/master (2012-12-22 11:59:14 > +0100) > > This pull request is specifically to get past the big merge issues from > u-boot-arm to u-boot which involved samsung, ixm and tegra fixes, > thanks to all those who took part in helping untie the knot. Once this > is in, I'll certainly have another pull request, early in the coming > week. > > > > Albert ARIBAUD (2): > Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' > Merge samsung, imx, tegra into u-boot-arm/master >From this merge commit, i found "arm:exynos4:pinmux: Modify the gpio function for mmc" commit codes are removed. It seems to be removed by manual merge with "exynos:pinmux: Add pinmux support for i2c" commit. Thanks. > > Allen Martin (2): > tegra: add CONSOLE_MUX support to tegra-kbc > Merge remote-tracking branch 'u-boot/master' into > u-boot-arm-merged > > Ashok Kumar Reddy (1): > ARM: arm1176: Define arch_cpu_init() for s3c64xx > > Benoît Thébaudeau (17): > arm1136: Fix enable_caches() > mx31: Move EHCI definitions to ehci-fsl.h > ehci-mxc: Clean up > ehci-mx5: Clean up > ehci-mx5: Fix OC_DIS usage > ehci-mx5: Fix OPM usage > ehci-mx5: Fix *PM usage for i.MX53 > ehci-mx5: Add missing OC_DIS for i.MX53 > ehci-mxc: Make EHCI power/oc polarities configurable > ehci-mxc: Make i.MX25 EHCI configurable > ehci-mxc: Define host offsets > ehci-mxc: Add support for i.MX35 > mx35pdk: Add support for OTG > ehci-mx5/6: Make board_ehci_hcd_init() optional > ehci-mxc: Fix host power mask bit for i.MX35 > ehci-mxc: Fix host power mask bit for i.MX25 > mx5: Mark lowlevel_init board-specific code > > Chander Kashyap (1): > Exynos5250: Enable PXE Support > > Fabio Estevam (28): > mx25pdk: Include CONFIG_MX25 > mx25pdk: Add esdhc support > pmic_fsl: Introduce FSL_PMIC_I2C_LENGTH > mx25: Place common functions into sys_proto.h > pmic: Add support for mc34704 > mx25pdk: Add Ethernet support > mx53loco: Allow booting a zImage kernel > mx25pdk: Allow booting a zImage kernel > mx51evk: Allow booting a zImage kernel > mx35pdk: Allow booting a zImage kernel > mx6qsabre_common: Allow booting a zImage kernel > mx5: Align SPI CS naming with i.MX53 reference manual > mx5: Print CSPI clock in 'clock' command > spi: mxc_spi: Fix handling of chip select > spi: mxc_spi: Fix spi clock glitch durant reset > mx6: clock: Only show CSPI clock if CSPI is enabled > mx28evk: Configure CONFIG_BOOTDELAY to one second > mx53loco: Configure CONFIG_BOOTDELAY to one second > mx6qsabrelite: Configure CONFIG_BOOTDELAY to one second > mx6qsabre_common: Configure CONFIG_BOOTDELAY to one second > mx51evk: Configure CONFIG_BOOTDELAY to one second > mx25pdk: Configure CONFIG_BOOTDELAY to one second > mx31pdk: Configure CONFIG_BOOTDELAY to one second > mx35pdk: Configure CONFIG_BOOTDELAY to one second > mx25pdk: Adapt it for the new PMIC framework > woodburn: Set gpio value in gpio_direction_output() > mx53loco: Fix PMIC name > mx25pdk: Allow booting a device tree kernel > > Hatim RV (3): > EXYNOS: Add clock for SPI > EXYNOS5: Add base address for SPI > EXYNOS5: Enable SPI > > Marek Vasut (9): > dm: wdt: Move s5p watchdog timer to drivers/watchdog/ > mx28: Fix typo in POWER_MINPWR_VBG_OFF > mx28: Fix typo in POWER_DCLIMITS_NEGLIMIT_OFFSET > mx28: Remove SET, CLR, TOG ops from PLLxCTRL1 registers > mx28: Rename regs-power.h to regs-power-mx28.h > mxs: Silence elftosb > mxs: Implement common function to setup VDDx > mxs: Properly setup VDDD in power supply setup code > mxs: Staticize SPL functions > > Mayuresh Kulkarni (1): > tegra: Enable display/lcd support on Seaboard > > Minkyu Kang (6): > ARCH: EXYNOS: add support to match product id > EXYNOS: Clock: Add common function for pll rate calculation > s3c64xx: fix the compiler error and warning > Merge branch 'master' of git://git.denx.de/u-boot into resolve > universal_c210: fix compiler error and compiler warning > universal_c210: check the NULL pointer when get the PMIC > > Otavio Salvador (1): > mxs: SPL: Generalize memory initialization > > Piotr Wilczek (12): > arm:exynos4:trats: Correct SDRAM configur
Re: [U-Boot] [PATCH V3 4/9] EXYNOS5: DWMMC: Added FDT support for DWMMC
Hi Amar,
..snip..
>>> }
>>>
>>> int exynos_dwmci_init(u32 regbase, int bus_width, int index)
>>> {
>>> struct dwmci_host *host = NULL;
>>> + int dev_id = 0;
>>> host = malloc(sizeof(struct dwmci_host));
>>> if (!host) {
>>> printf("dwmci_host malloc fail!\n");
>>> return 1;
>>> }
>>> + /* Convert index into corresponding peripheral ID */
>>> + dev_id = index + PERIPH_ID_SDMMC0;
>> Is it right at every case?
>>
>
> Yes, it is right in every case.
>
> Consider the finction "int exynos_dwmci_init(u32 regbase, int bus_width,
> int index)"
> If the input argument 'index' is between (0-3), then the statement "dev_id
> = index + PERIPH_ID_SDMMC0;" works good.
>
> So, the function exynos_dwmci_init(u32 regbase, int bus_width, int index)
> is being called as below
> 1) FDT Case:
> The function exynos_dwmmc_init() calls exynos_dwmmc_init()
> The dev_id is extracted from arch/arm/dts/exynos5250.dtsi. The dev_id is
> nothing but the interrupt number.
> dwmmc0 - dev_id = 75
> dwmmc1 - dev_id = 76
> dwmmc2 - dev_id = 77
> dwmmc3 - dev_id = 78
>
> At same time the enum values are (Refer
> "arch/arm/include/asm/arch-exynos/periph.h")
> PERIPH_ID_SDMMC0 = 75,
> PERIPH_ID_SDMMC1,
> PERIPH_ID_SDMMC2,
> PERIPH_ID_SDMMC3,
>
> Here "index = dev_id - PERIPH_ID_SDMMC0" works good for all channels
> (mmc0 - mmc3)
>
> As proper values are mentioned in arch/arm/dts/exynos5250.dtsi, proper
> values of "index" (i.e 0 - 3) will be computed here.
>
> 2) Non-FDT case:
> The function board_mmc_init() calls exynos_dwmmc_init() as shown below
> int board_mmc_init(bd_t *bis)
> {
>
>
> /*EMMC: dwmmc Channel-0 with 8 bit bus width */
> err = exynos_dwmmc_init(0, 8);
> }
> Here the coder shall ensure to pass proper index number (0 to 3) for porper
> working.
Sorry, i confused the dev_id and dev_index..Thank you for explanation.
Best Regards,
Jaehoon Chung
>
>
>> > +
>>> + /* set the clock divisor - clk_div_fsys for mmc */
>>> + if (exynos5_mmc_set_clk_div(dev_id)) {
>>> + debug("mmc clock div set failed\n");
>>> + return -1;
>>> + }
>>>
>>> host->name = EXYNOS_NAME;
>>> host->ioaddr = (void *)regbase;
>>> host->buswidth = bus_width;
>>> +#ifdef CONFIG_OF_CONTROL
>>> + host->clksel_val = (DWMCI_SET_SAMPLE_CLK(timing[0]) |
>>> + DWMCI_SET_DRV_CLK(timing[1]) |
>>> + DWMCI_SET_DIV_RATIO(timing[2]));
>>> +#else
>>> + if (0 == index)
>>> + host->clksel_val = DWMMC_MMC0_CLKSEL_VAL;
>>> + if (2 == index)
>>> + host->clksel_val = DWMMC_MMC2_CLKSEL_VAL;
>>> +#endif
>>> host->clksel = exynos_dwmci_clksel;
>>> host->dev_index = index;
>>> -
>>> - add_dwmci(host, 5200, 40);
>>> + host->mmc_clk = exynos_dwmci_get_clk;
>>> + /* Add the mmc chennel to be registered with mmc core */
>>> + add_dwmci(host, DWMMC_MAX_FREQ, DWMMC_MIN_FREQ);
>>>
>>> return 0;
>>> }
>>>
>>> +#ifdef CONFIG_OF_CONTROL
>>> +unsigned int exynos_dwmmc_init(const void *blob)
>>> +{
>>> + u32 base;
>>> + int index, bus_width;
>>> + int node_list[DWMMC_MAX_CH_NUM];
>>> + int err = 0;
>>> + int dev_id, flag;
>>> + int count, i;
>>> +
>>> + count = fdtdec_find_aliases_for_id(blob, "dwmmc",
>>> + COMPAT_SAMSUNG_EXYNOS5_DWMMC, node_list,
>>> + DWMMC_MAX_CH_NUM);
>>> +
>>> + for (i = 0; i < count; i++) {
>>> + int node = node_list[i];
>>> +
>>> + if (node <= 0)
>>> + continue;
>>> +
>>> + /* Extract device id for each mmc channel */
>>> + dev_id = pinmux_decode_periph_id(blob, node);
>>> +
>>> + /* Get the bus width from the device node */
>>> + bus_width = fdtdec_get_int(blob, node,
>> "samsung,bus-width", 0);
>>> + if (bus_width < 0) {
>>> + debug("DWMMC: Can't get bus-width\n");
>>> + return -1;
>>> + }
>>> + if (8 == bus_width)
>>> + flag = PINMUX_FLAG_8BIT_MODE;
>>> + else
>>> + flag = PINMUX_FLAG_NONE;
>>> +
>>> + /* config pinmux for each mmc channel */
>>> + err = exynos_pinmux_config(dev_id, flag);
>>> + if (err) {
>>> + debug("DWMMC not configured\n");
>>> + return err;
>>> + }
>>> +
>>> + index = dev_id - PERIPH_ID_SDMMC0;
>>> +
>>> + /* Get the base address from the device node */
>>> + base = fdtdec_get_addr(blob, node, "reg");
>>> + if (!base) {
>>> + debug("DWMMC: Can't get base address\n");
>>> + return -1;
>>> + }
>>> + /* Extract the timing info from the node */
>>> + err = fd
Re: [U-Boot] Pull request: u-boot-arm/master
Hi Albert, > Hi Albert, > > 2012년 12월 22일 토요일에 Albert ARIBAUD님이 작성: > > > Hello Tom, > > > > The following changes since commit > > 095728803eedfce850a2f85828f79500cb09979e: > > > > Merge branch 'master' of git://git.denx.de/u-boot-net (2012-12-17 > > 18:39:50 -0700) > > > > are available in the git repository at: > > > > > > git://git.denx.de/u-boot-arm master > > > > for you to fetch changes up to > > 96764df1b47ddebfb50fadf5af72530b07b5fc89: > > > > Merge samsung, imx, tegra into u-boot-arm/master (2012-12-22 > > 11:59:14 +0100) > > > > This pull request is specifically to get past the big merge issues > > from u-boot-arm to u-boot which involved samsung, ixm and tegra > > fixes, thanks to all those who took part in helping untie the knot. > > Once this is in, I'll certainly have another pull request, early in > > the coming week. > > > > > > > > Albert ARIBAUD (2): > > Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' > > Merge samsung, imx, tegra into u-boot-arm/master > > > From this merge commit, i found "arm:exynos4:pinmux: Modify the gpio > function for mmc" commit codes are removed. > It seems to be removed by manual merge with "exynos:pinmux: Add pinmux > support for i2c" commit. Joonyoung thanks for information. We have spotted this yesterday. Piotr has prepared patch for fixing this (will be posted very soon). After Piotr's patch Trats recognizes eMMC device again. > > Thanks. > > > > > > Allen Martin (2): > > tegra: add CONSOLE_MUX support to tegra-kbc > > Merge remote-tracking branch 'u-boot/master' into > > u-boot-arm-merged > > > > Ashok Kumar Reddy (1): > > ARM: arm1176: Define arch_cpu_init() for s3c64xx > > > > Benoît Thébaudeau (17): > > arm1136: Fix enable_caches() > > mx31: Move EHCI definitions to ehci-fsl.h > > ehci-mxc: Clean up > > ehci-mx5: Clean up > > ehci-mx5: Fix OC_DIS usage > > ehci-mx5: Fix OPM usage > > ehci-mx5: Fix *PM usage for i.MX53 > > ehci-mx5: Add missing OC_DIS for i.MX53 > > ehci-mxc: Make EHCI power/oc polarities configurable > > ehci-mxc: Make i.MX25 EHCI configurable > > ehci-mxc: Define host offsets > > ehci-mxc: Add support for i.MX35 > > mx35pdk: Add support for OTG > > ehci-mx5/6: Make board_ehci_hcd_init() optional > > ehci-mxc: Fix host power mask bit for i.MX35 > > ehci-mxc: Fix host power mask bit for i.MX25 > > mx5: Mark lowlevel_init board-specific code > > > > Chander Kashyap (1): > > Exynos5250: Enable PXE Support > > > > Fabio Estevam (28): > > mx25pdk: Include CONFIG_MX25 > > mx25pdk: Add esdhc support > > pmic_fsl: Introduce FSL_PMIC_I2C_LENGTH > > mx25: Place common functions into sys_proto.h > > pmic: Add support for mc34704 > > mx25pdk: Add Ethernet support > > mx53loco: Allow booting a zImage kernel > > mx25pdk: Allow booting a zImage kernel > > mx51evk: Allow booting a zImage kernel > > mx35pdk: Allow booting a zImage kernel > > mx6qsabre_common: Allow booting a zImage kernel > > mx5: Align SPI CS naming with i.MX53 reference manual > > mx5: Print CSPI clock in 'clock' command > > spi: mxc_spi: Fix handling of chip select > > spi: mxc_spi: Fix spi clock glitch durant reset > > mx6: clock: Only show CSPI clock if CSPI is enabled > > mx28evk: Configure CONFIG_BOOTDELAY to one second > > mx53loco: Configure CONFIG_BOOTDELAY to one second > > mx6qsabrelite: Configure CONFIG_BOOTDELAY to one second > > mx6qsabre_common: Configure CONFIG_BOOTDELAY to one second > > mx51evk: Configure CONFIG_BOOTDELAY to one second > > mx25pdk: Configure CONFIG_BOOTDELAY to one second > > mx31pdk: Configure CONFIG_BOOTDELAY to one second > > mx35pdk: Configure CONFIG_BOOTDELAY to one second > > mx25pdk: Adapt it for the new PMIC framework > > woodburn: Set gpio value in gpio_direction_output() > > mx53loco: Fix PMIC name > > mx25pdk: Allow booting a device tree kernel > > > > Hatim RV (3): > > EXYNOS: Add clock for SPI > > EXYNOS5: Add base address for SPI > > EXYNOS5: Enable SPI > > > > Marek Vasut (9): > > dm: wdt: Move s5p watchdog timer to drivers/watchdog/ > > mx28: Fix typo in POWER_MINPWR_VBG_OFF > > mx28: Fix typo in POWER_DCLIMITS_NEGLIMIT_OFFSET > > mx28: Remove SET, CLR, TOG ops from PLLxCTRL1 registers > > mx28: Rename regs-power.h to regs-power-mx28.h > > mxs: Silence elftosb > > mxs: Implement common function to setup VDDx > > mxs: Properly setup VDDD in power supply setup code > > mxs: Staticize SPL functions > > > > Mayuresh Kulkarni (1): > > tegra: Enable display/lcd support on Seaboard > > > > Minkyu Kang (6): > > ARCH: EXYNOS: add support to match product id > > EX
[U-Boot] [PATCH] arm:exynos4:pinmux: Modify the gpio function for mmc
This patch add pinmux settings for Exynos4 for mmc0 and mmc2 The pinmux setting previously added in commit a3eab2ac41 has been deleted in merge 96764df1b4 Piotr Wilczek (1): arm:exynos4:pinmux: Modify the gpio function for mmc arch/arm/cpu/armv7/exynos/pinmux.c | 45 1 file changed, 45 insertions(+) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm:exynos4:pinmux: Modify the gpio function for mmc
This patch add pinmux settings for Exynos4 for mmc0 and mmc2
Signed-off-by: Piotr Wilczek
Signed-off-by: Kyungmin Park
CC: Minkyu Kang
CC: Albert ARIBAUD
---
arch/arm/cpu/armv7/exynos/pinmux.c | 45
1 file changed, 45 insertions(+)
diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c
b/arch/arm/cpu/armv7/exynos/pinmux.c
index 20a4b84..ee58dac 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -370,6 +370,43 @@ static void exynos4_i2c_config(int peripheral, int flags)
}
}
+static int exynos4_mmc_config(int peripheral, int flags)
+{
+ struct exynos4_gpio_part2 *gpio2 =
+ (struct exynos4_gpio_part2 *)samsung_get_base_gpio_part2();
+ struct s5p_gpio_bank *bank, *bank_ext;
+ int i;
+
+ switch (peripheral) {
+ case PERIPH_ID_SDMMC0:
+ bank = &gpio2->k0;
+ bank_ext = &gpio2->k1;
+ break;
+ case PERIPH_ID_SDMMC2:
+ bank = &gpio2->k2;
+ bank_ext = &gpio2->k3;
+ break;
+ default:
+ return -1;
+ }
+ for (i = 0; i < 7; i++) {
+ if (i == 2)
+ continue;
+ s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2));
+ s5p_gpio_set_pull(bank, i, GPIO_PULL_NONE);
+ s5p_gpio_set_drv(bank, i, GPIO_DRV_4X);
+ }
+ if (flags & PINMUX_FLAG_8BIT_MODE) {
+ for (i = 3; i < 7; i++) {
+ s5p_gpio_cfg_pin(bank_ext, i, GPIO_FUNC(0x3));
+ s5p_gpio_set_pull(bank_ext, i, GPIO_PULL_NONE);
+ s5p_gpio_set_drv(bank_ext, i, GPIO_DRV_4X);
+ }
+ }
+
+ return 0;
+}
+
static int exynos4_pinmux_config(int peripheral, int flags)
{
switch (peripheral) {
@@ -383,6 +420,14 @@ static int exynos4_pinmux_config(int peripheral, int flags)
case PERIPH_ID_I2C7:
exynos4_i2c_config(peripheral, flags);
break;
+ case PERIPH_ID_SDMMC0:
+ case PERIPH_ID_SDMMC2:
+ return exynos4_mmc_config(peripheral, flags);
+ case PERIPH_ID_SDMMC1:
+ case PERIPH_ID_SDMMC3:
+ case PERIPH_ID_SDMMC4:
+ printf("SDMMC device %d not implemented\n", peripheral);
+ return -1;
default:
debug("%s: invalid peripheral %d", __func__, peripheral);
return -1;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/block/systemace: fixes read/write words for bus width = 8
Hi Wolfgang,
2013/1/2 Wolfgang Denk :
> Dear Alexey Brodkin,
>
> In message <1357137512-8618-1-git-send-email-alexey.brod...@gmail.com> you
> wrote:
>> From: Alexey Brodkin
>>
>> Current implementation works fine for bus width = 16 bits because we
>> never get into "if" branch.
>>
>> If one sets width to 8 bits there will be 2 consequent data accesses
>> (read/write):
>> 1. Correct data access for 8-bit bus
>> 2. Unconditional (and in this case incorrect) data access as if data bus
>> is 16-bit wide
>
> Sorry, I don't get this.
>
> You say, if one sets width to 8 bits, then the code fails when the bus
> is actually 16 bits wide?
>
> But this is just a bad configuration then - why do we need to change
> the code? All that is needed is to run with a correct configuration?
Here is that function with my comment about missing "else".
In ace_writew function we shouldn't write 16bit value when width is 8.
(It probably doesn't break anything but it is not correct - I will
check it on the HW)
static void ace_writew(u16 val, unsigned off)
{
if (width == 8) {
#if !defined(__BIG_ENDIAN)
writeb(val >> 8, base + off);
writeb(val, base + off + 1);
#else
writeb(val, base + off);
writeb(val >> 8, base + off + 1);
#endif
}
<--- missing else here
writew(base + off, val);
}
For ace_readw is situation different because it always returns value for width 8
that's why it never reach 16bit read.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
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] drivers/block/systemace: fixes read/write words for bus width = 8
Dear Michal Simek, In message you wrote: > > > You say, if one sets width to 8 bits, then the code fails when the bus > > is actually 16 bits wide? ... > Here is that function with my comment about missing "else". > In ace_writew function we shouldn't write 16bit value when width is 8. > (It probably doesn't break anything but it is not correct - I will > check it on the HW) I see. Well, I think the commit message is not really clear. I definitely misunderstood it. Maybe it can be improved? Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I have the simplest tastes. I am always satisfied with the best. -- Oscar Wilde ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 3/9] DWMMC: Initialise dwmci and resolve EMMC read write issues
Hi Jaehoon,
Thanks for the comments.
Please find the response below.
Thanks & Regards
Amarendra Reddy
On 2 January 2013 10:42, Jaehoon Chung wrote:
> On 12/31/2012 07:58 PM, Amar wrote:
> > This patch enumerates dwmci and set auto stop command during
> > dwmci initialisation.
> > EMMC read/write is not happening in current implementation
> > due to improper fifo size computation. Hence Modified the fifo size
> > computation to resolve EMMC read write issues.
> What issue for read/write?
After bootup, the command 'mmcinfo' was working fine. It displays the EMMC
device properties(Manufacturer,OEM, SD version ... ) properly.
But the EMMC read / write was not happening. Then I referred to chromium
uboot working code and observed that FIFO size configuraion is missing in
our code.
After configuring FIFO size, read / write happened properly. That is what I
meant.
>
> Changes from V1:
> 1)Created the macros RX_WMARK_SHIFT and RX_WMARK_MASK in header
file.
>
> Changes from V2:
> 1)Updation of commit message and resubmition of proper patch set.
>
> Signed-off-by: Amar
> ---
> drivers/mmc/dw_mmc.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> index 4070d4e..d8fa1a2 100644
> --- a/drivers/mmc/dw_mmc.c
> +++ b/drivers/mmc/dw_mmc.c
> @@ -136,6 +136,7 @@ static int dwmci_send_cmd(struct mmc *mmc, struct
mmc_cmd *cmd,
> return TIMEOUT;
> }
> timeout--;
> + mdelay(1);
> Why add the mdelay(1)? Could you explain to me?
Again this one also I added after referring to chromium uboot working code.
Without mdelay(), there was a problem while writing into EMMC boot
partitions.
*Problem Description:* When I write into EMMC boot partition,
-> It fails in first attempt and displays the error *"Timeout on data
busy". *
-> Immediately it retries and succeeds in second attempt.
To avoid the above problem I added mdelay().
> > }
> >
> > dwmci_writel(host, DWMCI_RINTSTS, DWMCI_INTMSK_ALL);
> > @@ -314,7 +315,7 @@ static void dwmci_set_ios(struct mmc *mmc)
> > static int dwmci_init(struct mmc *mmc)
> > {
> > struct dwmci_host *host = (struct dwmci_host *)mmc->priv;
> > - u32 fifo_size, fifoth_val;
> > + u32 fifo_size, fifoth_val, ier;
> >
> > dwmci_writel(host, DWMCI_PWREN, 1);
> >
> > @@ -323,6 +324,14 @@ static int dwmci_init(struct mmc *mmc)
> > return -1;
> > }
> >
> > + /* Enumerate at 400KHz */
> > + dwmci_setup_bus(host, mmc->f_min);
> > +
> > + /* Set auto stop command */
> > + ier = dwmci_readl(host, DWMCI_CTRL);
> > + ier |= (1<<10);
> Use the define..ex) define DWMCI_CTRL_AUTO_STOP_CMD BIT(10)
>
Ok.
> > + dwmci_writel(host, DWMCI_CTRL, ier);
> If set to auto stop command, then you didn't see any problem?
>
Actually, it works fine even without setting auto stop command.
Initially I referred to the working code from chromium uboot, and tried to
maintain all our dwmci init code inline with chromium uboot.
Hence I added "set auto command".
> Best Regards,
> Jaehoon Chung
> > +
> > dwmci_writel(host, DWMCI_RINTSTS, 0x);
> > dwmci_writel(host, DWMCI_INTMASK, 0);
> >
> > @@ -332,10 +341,11 @@ static int dwmci_init(struct mmc *mmc)
> > dwmci_writel(host, DWMCI_BMOD, 1);
> >
> > fifo_size = dwmci_readl(host, DWMCI_FIFOTH);
> > + fifo_size = ((fifo_size & RX_WMARK_MASK) >> RX_WMARK_SHIFT) + 1;
> > if (host->fifoth_val)
> > fifoth_val = host->fifoth_val;
> > else
> > - fifoth_val = MSIZE(0x2) | RX_WMARK(fifo_size/2 -1) |
> > + fifoth_val = MSIZE(0x2) | RX_WMARK(fifo_size/2 - 1) |
> > TX_WMARK(fifo_size/2);
> > dwmci_writel(host, DWMCI_FIFOTH, fifoth_val);
> >
> >
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
