Re: [U-Boot] mmc changes in v2014.04-rc3 cause problems when using mmc in SPL
Hi, On 04/09/2014 01:07 AM, Tom Rini wrote: On Wed, Apr 09, 2014 at 12:05:04AM +0200, Hans de Goede wrote: Hi, While merging v2014.04-rc3 into our sunxi u-boot branch, I hit a problem where mmc would no longer work in the SPL. The problem is that the new mmc_create call forces use of HEAP memory, while in the SPL there may be no HEAP. For now I've created a small 2048 bytes HEAP in our SPL, but if possible I would like to get rid of the need for a HEAP though, as we only have 24K of RAM for our SPL. 24K should still be enough to have a small malloc pool and the rest of SPL, especially since it sounds like you already didn't have FAT support in there (which has required malloc for ages and is why Pantelis didn't spot this as a problem I think). How close to the limit are we today in the sunxi platforms? We're close to the limit, but in the mean time I've realized that we don't need the HEAP until after we've brought up the DRAM (and the base SPL code does not init the HEAP until after DRAM init, and once we've DRAM we no longer have any space constraints. So things are fine as is. Sorry for the noise. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/9] sunxi: initial sun7i clocks and timer support.
On Mon, 2014-03-24 at 23:42 +0100, Olliver Schinagl wrote: On 03/24/2014 09:52 PM, Marek Vasut wrote: + /* Switch to 24MHz clock while changing PLL1 */ + writel(AXI_DIV_1 AXI_DIV_SHIFT | + AHB_DIV_2 AHB_DIV_SHIFT | + APB0_DIV_1 APB0_DIV_SHIFT | + CPU_CLK_SRC_OSC24M CPU_CLK_SRC_SHIFT, + ccm-cpu_ahb_apb0_cfg); + sdelay(20); What is sdelay() function all about ? It also is from arch/arm/include/asm/arch-sunxi/sys_proto.h and I thought all where replaced with udelays Since these sdelays() are used while we are frobbing around with the clocks I'm not sure that switching to udelay is possible/wise. sdelay is documented as: * sdelay() - simple spin loop. Will be constant time as * its generally used in bypass conditions only. This * is necessary until timers are accessible. IOW it sounds like it is designed to be used in exactly these circumstances. Given the lack of documentation for what is actually required by the hardware when changing these clocks I'm a bit reluctant to go changing things. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/28] net: Move RARP receive logic out of net.c
Sent from my iPhone ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fw_(printenv/setenv) and serial console have different env variables
On Sat, Apr 12, 2014 at 5:57 AM, Andrei Mihut andrei.mi...@gmail.com wrote:
Greetings everyone,
I stumbled over something worth telling.
It started as the bad crc using defaults issue when I tried to use
fw_printenv on my debian iconnect box. I tought it was the fw_env.config.
it wasn't. After hours of researching and compiling from source and the
whole lot of trouble shooting I took the chance to use fw_setenv.
Bingo! it worked. Now fw_printenv gives me no bad crc and prints the
variables including the new ones even after reboot.
My thoughts are that your u-boot is storing the env in a different
area than what your fw_env.config is pointing to in debian. Hence the
crc error. Of course you can get rid of the crc error by running
fw_setenv, as it just dumps the default env in the space defined in
the config file.
NOW HERE IS THE ISSUE
The env variables printed from linux don't show on the serial and viceversa.
It looks like there are 2 sets of them. Needless to say that it's
frustrating.
Anyone has seen anything similar?
** printouts
on the iconnect box
root@ico1:~# fw_printenv
bootcmd=bootp; setenv bootargs root=/dev/nfs
nfsroot=${serverip}:${rootpath}
ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200
firsttest=firsttest1
root@ico1:~# fw_setenv secondtest secondtest
root@ico1:~# fw_printenv
bootcmd=bootp; setenv bootargs root=/dev/nfs
nfsroot=${serverip}:${rootpath}
ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200
firsttest=firsttest1
secondtest=secondtest
root@ico1:~#
iconnect
on the serial console
Environment size: 1633/131068 bytes
iconnect =
iconnect = version
U-Boot 2013.10 (Mar 26 2014 - 18:44:17) Iomega iConnect
arm-openwrt-linux-uclibcgnueabi-gcc (OpenWrt/Linaro GCC 4.8-2014.01 r40028)
4.8.3
GNU ld (GNU Binutils) 2.22
iconnect =
+++
just in case last working
iconnect = printenv
arcNumber=2870
baudrate=115200
bootargs=console=ttyS0,115200 root=/dev/sda4 rootdelay=10
bootargs_console=console=ttyS0,115200 root=/dev/sda4 rootdelay=10
bootargs_root=root=/dev/mtdblock2 rootfstype=jffs2
bootcmd=setenv bootargs $(bootargs_console); run bootcmd_usb;run
preboot;bootm 0x0080
bootcmd_usb=usb start; ext2load usb 0:1 0x0080 /uImageJmybuildiscsi
bootdelay=10
console=console=ttyS0,115200 panic=20
download_kernel=mw $(loadaddr) 0x 0x30; fatload usb 0:1 $(loadaddr)
$(kernel_name);
download_rootfs=mw $(loadaddr) 0x 0x20; fatload usb 0:1 $(loadaddr)
$(rootfs_name);
ethact=egiga0
ethaddr=00:D0:B8:0C:FE:6C
filesize=2dc1b1
flash_kernel=nand erase 0x10 0x40; nand write.e $(loadaddr)
0x10 0x40;
flash_rootfs=nand erase 0x50 0xfb0; nand write.e $(loadaddr)
0x50 0x20;
if_netconsole=ping $(serverip)
ipaddr=10.243.1.239
kernel_name=openwrt-kirkwood-uImage
load_openwrt=setenv bootargs $(console) $(bootargs_root); nand read
$(loadaddr) 0x10 0x40; bootm $(loadaddr)
loadaddr=0x640
machid=B36
mainlineLinux=yes
ncip=10.243.1.251
preboot=run set_eth_parms if_netconsole set_netconsole start_netconsole
rootfs_name=openwrt-kirkwood--jffs2-64k.img
serverip=10.243.1.251
set_eth_parms=mii write 0xb 0 3200
set_netconsole=setenv ncip $(serverip); setenv bootdelay 10
start_netconsole=setenv stdin nc; setenv stdout nc; setenv stderr nc;
version; sleep 10;
stderr=nc
stdin=nc
stdout=nc
serial console
/etc/fw_env.config
root@ico1:~# cat /etc/fw_env.config
# Configuration file for fw_(printenv/saveenv) utility.
# Up to two entries are valid, in this case the redundand
# environment sector is assumed present.
# MTD device name Device offset Env. size Flash sector size
# iomega iconnect
/dev/mtd0 0xa 0x2 0x2
root@ico1:~#
/etc/fw_env.config
Here I see that Device offset is 0xa (which fw_printenv works
with), and looking at include/configs/iconnect.h CONFIG_ENV_OFFSET is
0x8. The sizes do match.
Hence, can you try to change fw_env.config to have a device offset of
0x8 and see if you get same envs?
Thanks
- Suriyan
How do I merge this two?
Thanks and regards.
A.
--
ენდრიუ მე ქოხი اندريه ميهوت אנדריי מיהו 安德魯 アンドルー Андрей Михут אַנדרעי
מיהוט اندرو میهو
___
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] [PATCH v3 3/5] image: add support for Android's boot image format
On Saturday, April 12, 2014 at 11:54:10 PM, Rob Herring wrote:
On Fri, Apr 11, 2014 at 4:44 PM, Marek Vasut ma...@denx.de wrote:
On Thursday, April 10, 2014 at 09:18:05 PM, Rob Herring wrote:
From: Sebastian Siewior bige...@linutronix.de
This patch adds support for the Android boot-image format. The header
file is from the Android project and got slightly alterted so the struct
+ its defines are not generic but have something like a namespace. The
header file is from bootloader/legacy/include/boot/bootimg.h. The
header parsing has been written from scratch and I looked at
bootloader/legacy/usbloader/usbloader.c for some details.
The image contains the physical address (load address) of the kernel and
ramdisk. This address is considered only for the kernel image.
The second image is currently ignored. I haven't found anything that
is creating this.
Can you please elaborate on those last two sentences ?
The android header has 3 images: kernel, ramdisk and second. I think
this is for secondary bootloader, but I'll have to investigate.
Viva hardcoded b/s :'-(
v3 (Rob Herring):
This is based on http://patchwork.ozlabs.org/patch/126797/ with the
following changes:
- Rebased to current mainline
- Moved android image handling to separate functions in
common/image-android.c
- s/u8/char/ in header to fix string function warnings
- Use SPDX identifiers for licenses
- Cleaned-up file source information:
android_image.h is from file include/boot/bootimg.h in repository:
https://android.googlesource.com/platform/bootable/bootloader/legacy
The git commit hash is 4205b865141ff2e255fe1d3bd16de18e217ef06a
usbloader.c would be from the same commit, but it does not appear
to have been used for any actual code.
[...]
@@ -293,7 +306,7 @@ static int bootm_find_os(cmd_tbl_t *cmdtp, int flag,
int argc, return 1;
}
#endif
- } else {
+ } else if (images.ep == ~0UL) {
I don't find this really portable. While it's unlikely the kernel will
have the EP here, don't we have a better solution than using special
value?
This is to address Wolfgang's prior comments about moving setting of
images.ep into the switch statement above. Do you like the previous
version better?
I think I might be missing that part of the discussion. My point is just that
you might rather have a separate variable to detect error instead of having a
special value like this.
Does my rant make sense to you please ?
[...]
@@ -949,7 +951,15 @@ int boot_get_ramdisk(int argc, char * const argv[],
bootm_headers_t *images, (ulong)images-legacy_hdr_os);
image_multi_getimg(images-legacy_hdr_os, 1, rd_data,
rd_len);
- } else {
+ }
+#ifdef CONFIG_ANDROID_BOOT_IMAGE
+ else if ((genimg_get_format(images) == IMAGE_FORMAT_ANDROID)
+ (!andriod_image_get_ramdisk((void *)images-os.start,
andriod_image_get_ramdisk() ? There is a typo in the function name, did
you actually ever even compile this patchset please ?
[...]
Of course it compiles as the same typo is everywhere for this
function... :) I've compiled and run this (although I have not tested
with a ramdisk).
Okay, thanks for clearing this up (and fixing this in v4)!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/9] sunxi: initial sun7i clocks and timer support.
On Sunday, April 13, 2014 at 09:55:57 PM, Ian Campbell wrote: On Mon, 2014-03-24 at 23:42 +0100, Olliver Schinagl wrote: On 03/24/2014 09:52 PM, Marek Vasut wrote: +/* Switch to 24MHz clock while changing PLL1 */ +writel(AXI_DIV_1 AXI_DIV_SHIFT | + AHB_DIV_2 AHB_DIV_SHIFT | + APB0_DIV_1 APB0_DIV_SHIFT | + CPU_CLK_SRC_OSC24M CPU_CLK_SRC_SHIFT, + ccm-cpu_ahb_apb0_cfg); +sdelay(20); What is sdelay() function all about ? It also is from arch/arm/include/asm/arch-sunxi/sys_proto.h and I thought all where replaced with udelays Since these sdelays() are used while we are frobbing around with the clocks I'm not sure that switching to udelay is possible/wise. sdelay is documented as: * sdelay() - simple spin loop. Will be constant time as * its generally used in bypass conditions only. This * is necessary until timers are accessible. IOW it sounds like it is designed to be used in exactly these circumstances. Given the lack of documentation for what is actually required by the hardware when changing these clocks I'm a bit reluctant to go changing things. Don't you have an clock-agnostic timer in the chip ? If not, well, can't be helped. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nitrogen6x: Fix the PAD settings for the ECSPI chipselect
On 4/12/2014 3:54 PM, Eric Nelson wrote:
Hi Fabio,
On 04/11/2014 01:43 PM, Fabio Estevam wrote:
From: Fabio Estevam fabio.este...@freescale.com
ECSPI chipselect (MX6_PAD_EIM_D19__GPIO3_IO19) is used with GPIO
functionality,
so it does not make sense to set its pad as SPI pin.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Eric,
This is untested.
board/boundary/nitrogen6x/nitrogen6x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index d9c05b0..f2492e4 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -331,7 +331,7 @@ int board_mmc_init(bd_t *bis)
#ifdef CONFIG_MXC_SPI
iomux_v3_cfg_t const ecspi1_pads[] = {
/* SS1 */
-MX6_PAD_EIM_D19__GPIO3_IO19 | MUX_PAD_CTRL(SPI_PAD_CTRL),
+MX6_PAD_EIM_D19__GPIO3_IO19 | MUX_PAD_CTRL(NO_PAD_CTRL),
MX6_PAD_EIM_D17__ECSPI1_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL),
MX6_PAD_EIM_D18__ECSPI1_MOSI | MUX_PAD_CTRL(SPI_PAD_CTRL),
MX6_PAD_EIM_D16__ECSPI1_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL),
Tested-by: Eric Nelson eric.nel...@boundarydevices.com
Acked-by: Eric Nelson eric.nel...@boundarydevices.com
NAK. Please don't use NO_PAD_CTRL. What is wrong with
SPI_PAD_CTRL. Your commit message doesn't say.
It is an SPI pin (even if used as a GPIO,) so
why doesn't it make sense.
I think your fixing a problem that doesn't exist.
Troy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nitrogen6x: Fix the PAD settings for the ECSPI chipselect
On Sun, Apr 13, 2014 at 7:08 PM, Troy Kisky
troy.ki...@boundarydevices.com wrote:
NAK. Please don't use NO_PAD_CTRL. What is wrong with
SPI_PAD_CTRL. Your commit message doesn't say.
It is an SPI pin (even if used as a GPIO,) so
why doesn't it make sense.
SPI_PAD_CTRL should be used by the pads that have SPI functionality.
This is not the case for the MX6_PAD_EIM_D19__GPIO3_IO19, which is a
GPIO, so why SPI_PAD_CTRL?
If we follow your argument then the enet_pads1 array is incorrect and
we should change all of them to ENET_PAD_CTRL instead.
iomux_v3_cfg_t const enet_pads1[] = {
MX6_PAD_ENET_MDIO__ENET_MDIO| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_MDC__ENET_MDC| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TXC__RGMII_TXC| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TD0__RGMII_TD0| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TD1__RGMII_TD1| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TD2__RGMII_TD2| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TD3__RGMII_TD3| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TX_CTL__RGMII_TX_CTL| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_REF_CLK__ENET_TX_CLK| MUX_PAD_CTRL(ENET_PAD_CTRL),
/* pin 35 - 1 (PHY_AD2) on reset */
MX6_PAD_RGMII_RXC__GPIO6_IO30| MUX_PAD_CTRL(NO_PAD_CTRL),
/* pin 32 - 1 - (MODE0) all */
MX6_PAD_RGMII_RD0__GPIO6_IO25| MUX_PAD_CTRL(NO_PAD_CTRL),
/* pin 31 - 1 - (MODE1) all */
MX6_PAD_RGMII_RD1__GPIO6_IO27| MUX_PAD_CTRL(NO_PAD_CTRL),
/* pin 28 - 1 - (MODE2) all */
MX6_PAD_RGMII_RD2__GPIO6_IO28| MUX_PAD_CTRL(NO_PAD_CTRL),
/* pin 27 - 1 - (MODE3) all */
MX6_PAD_RGMII_RD3__GPIO6_IO29| MUX_PAD_CTRL(NO_PAD_CTRL),
/* pin 33 - 1 - (CLK125_EN) 125Mhz clockout enabled */
MX6_PAD_RGMII_RX_CTL__GPIO6_IO24| MUX_PAD_CTRL(NO_PAD_CTRL),
/* pin 42 PHY nRST */
MX6_PAD_EIM_D23__GPIO3_IO23| MUX_PAD_CTRL(NO_PAD_CTRL),
MX6_PAD_ENET_RXD0__GPIO1_IO27| MUX_PAD_CTRL(NO_PAD_CTRL),
};
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nitrogen6x: Fix the PAD settings for the ECSPI chipselect
On 4/13/2014 4:01 PM, Fabio Estevam wrote: On Sun, Apr 13, 2014 at 7:08 PM, Troy Kisky troy.ki...@boundarydevices.com wrote: NAK. Please don't use NO_PAD_CTRL. What is wrong with SPI_PAD_CTRL. Your commit message doesn't say. It is an SPI pin (even if used as a GPIO,) so why doesn't it make sense. SPI_PAD_CTRL should be used by the pads that have SPI functionality. This is not the case for the MX6_PAD_EIM_D19__GPIO3_IO19, which is a GPIO, so why SPI_PAD_CTRL? If we follow your argument then the enet_pads1 array is incorrect and we should change all of them to ENET_PAD_CTRL instead. I would ack that patch. I do believe that all NO_PAD_CTRL should be replaced with whatever the register actually contains currently. A nop patch that just makes things explicit. Would you have a problem with that patch? For your particular example of enet, I see no reason that the pad settings should change when switching the mux from ENET to gpio. Btw, I do appreciate your looking at this board file. Sorry, if I sounded rude. Troy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/5] usb/gadget: add the fastboot gadget
Hi Rob,
On 04/11/2014 08:55 PM, Rob Herring wrote:
On Fri, Apr 11, 2014 at 2:14 AM, Bo Shen voice.s...@atmel.com wrote:
Hi Rob Herring,
I am just do a function testing on Atmel sama5d3xek board. And a small
comment as following.
Btw, do you test to transfer big size file. I try a file bigger than
100MiB, it will hang. However use DFU or RNDIS don't meet this issue.
How much RAM do you have? It will happily download into the end of RAM
overwriting u-boot if loadsize is not set. DFU at least has its own
buffer size configuration.
There are 512MiB RAM on board. So, it won't be a problem to load this
file from the begin of the RAM (As the u-boot is relocated to top RAM).
On 04/11/2014 03:18 AM, Rob Herring wrote:
+static void fastboot_unbind(struct usb_gadget *gadget)
+{
+ usb_ep_free_request(gadget-ep0, ep0_req);
+ ep_in-driver_data = NULL;
+ ep_out-driver_data = NULL;
+
+ gadget_is_connected = 0;
+ usb_gadget_disconnect(gadget);
+}
[snip]
+static void fastboot_disconnect(struct usb_gadget *gadget)
+{
+ fastboot_disable_ep(gadget);
+ gadget_is_connected = 0;
Do this only in unbind, as unbind is really disconnect.
So, what should disconnect function do?
Maybe some misunderstanding. I mean the gadget_is_connected should be
cleared in unbind function while not in disconnect function.
Rob
Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot][coreboot-x86] Incremental Make fails
Hi Hua, On Thu, 10 Apr 2014 16:32:32 +0800 Hua Yanghao huayang...@gmail.com wrote: Hi Masahiro, Strange. make coreboot-x86 is not supported anymore. Now, we must do make coreboot-x86_config all instead. We are still using U-boot 2014.01, which seems to be the latest stable release, isn't it? 3. make # second make fails with message: make[1]: Entering directory `/home/hua/git/u-boot/arch/x86/lib' make[1]: *** No rule to make target `.depend', needed by `built-in.o'. Stop. make[1]: Leaving directory `/home/hua/git/u-boot/arch/x86/lib' Strange again. .depend files are not used any more. (They were used in the old build system prior to Kbuild.) Are you sure? I can see the .depend files is created all over the places. For both ARM x86. Can anyone give some hints in how to solve this issue? Which version are you using? U-boot 2014.01 I guess you are not using the latest version in the git repository. The most recommended solution is to use the latest version. Indeed the latest version have things fixed. :-) Will switch over. Fetch the source tree by git clone: git clone git://git.denx.de/u-boot.git A big change happened to the U-Boot build system at v2014-rc1, which is right after v2014.01. Unlike Linux Kernel, the stable releases are not maintained in U-Boot. v2014.01 is just a snapshot of the mainline of develepment 3 months ago. If you want to get a support from the community, I recommend you to use u-boot/master branch. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] i2c: sh_i2c: bugfix: i2c probe command does not work
Hello Tetsuyuki Am 14.04.2014 06:45, schrieb Tetsuyuki Kobayashi: This is regression of commit 2035d77d i2c: sh_i2c: Update to new CONFIG_SYS_I2C framework Before commit 2035d77d, i2c probe command works properly on kzm9g board. KZM-A9-GT# i2c probe Valid chip addresses: 0C 12 1D 32 39 3D 40 60 After commit 2035d77d, i2c probe command does not work. KZM-A9-GT# i2c probe Valid chip addresses: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F sh_i2c_probe() calls sh_i2c_read(), but read length is 0. So acutally it does not read device at all. This patch changes read length to 1. Signed-off-by: Tetsuyuki Kobayashik...@kmckk.co.jp --- drivers/i2c/sh_i2c.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) I could not find your patch in patchwork ... so I think it go through u-boot-sh.git, so: Acked-by: Heiko Schocher h...@denx.de Thanks! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] arm: kzm9g: Add CONFIG_SYS_GENERIC_BOARD
Hello Tetsuyuki, Am 14.04.2014 06:45, schrieb Tetsuyuki Kobayashi: Add CONFIG_SYS_GENERIC_BOARD to enable generic board for kzm9g. See doc/README.generic-board Hmm.. I did not find doc/README.generic-board in current mainline tree ... [...] beside of that: Acked-by: Heiko Schocher h...@denx.de bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] mpc83xx: add support for the ids8313 board
Hello all, Am 25.01.2014 07:53, schrieb Heiko Schocher: add support for the ids8313 board. CPU: e300c3, MPC8313, Rev: 2.1 at 396 MHz, CSB: 132 MHz I2C: ready SPI: ready DRAM: 128 MiB (DDR2, 32-bit, ECC off, 264 MHz) Flash: 8 MiB NAND: 128 MiB Net: TSEC0, TSEC1 [PRIME] This board uses signed fit images, signed with sha256,rsa4096 algorithm. ping? This patchserie is pending now for more then 2 months ... Kim? Following patches are needed for this board support: all needed patches are in mainline or mainline/next now ... [...] bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
