[U-Boot] [PATCH v2 2/8] net: asix: fix operation without eeprom
From: Marcel Ziswiler marcel.ziswi...@toradex.com
This patch fixes operation of our on-board AX88772B chip without EEPROM
but with a ethaddr coming from the regular U-Boot environment. This is
a forward port of some remaining parts initially implemented by
Antmicro.
Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com
---
Changes in v2:
- run it through checkpatch.pl as suggested by Marek and Joe
- cleanup comments and use VID/PID defines as suggested by Marek
- dug out an AX88772 (not B) dongle again and verified operation
- AX88772 (not B) indeed does not work with B modifications
(e.g. VID/PID based differentiation is indeed required)
- dug out another AX88772B dongle as well and verified operation
drivers/usb/eth/asix.c | 32 +---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/eth/asix.c b/drivers/usb/eth/asix.c
index c8697ae..1c2c2d0 100644
--- a/drivers/usb/eth/asix.c
+++ b/drivers/usb/eth/asix.c
@@ -1,6 +1,8 @@
/*
* Copyright (c) 2011 The Chromium OS Authors.
*
+ * Patched for AX88772B by Antmicro Ltd www.antmicro.com
+ *
* SPDX-License-Identifier:GPL-2.0+
*/
@@ -64,8 +66,11 @@
AX_MEDIUM_AC | AX_MEDIUM_RE)
/* AX88772 AX88178 RX_CTL values */
-#define AX_RX_CTL_SO 0x0080
-#define AX_RX_CTL_AB 0x0008
+#define AX_RX_CTL_RH2M 0x0200 /* 32-bit aligned RX IP header */
+#define AX_RX_CTL_RH1M 0x0100 /* Enable RX header format type 1 */
+#define AX_RX_CTL_SO 0x0080
+#define AX_RX_CTL_AB 0x0008
+#define AX_RX_HEADER_DEFAULT (AX_RX_CTL_RH1M | AX_RX_CTL_RH2M)
#define AX_DEFAULT_RX_CTL \
(AX_RX_CTL_SO | AX_RX_CTL_AB)
@@ -92,6 +97,9 @@
#define FLAG_TYPE_AX88772B (1U 2)
#define FLAG_EEPROM_MAC(1U 3) /* initial mac address in
eeprom */
+#define ASIX_USB_VENDOR_ID 0x0b95
+#define AX88772B_USB_PRODUCT_ID0x772b
+
/* local vars */
static int curr_eth_dev; /* index for name of next device detected */
@@ -426,7 +434,16 @@ static int asix_init(struct eth_device *eth, bd_t *bd)
debug(** %s()\n, __func__);
- if (asix_write_rx_ctl(dev, AX_DEFAULT_RX_CTL) 0)
+ if ((dev-pusb_dev-descriptor.idVendor == ASIX_USB_VENDOR_ID)
+ (dev-pusb_dev-descriptor.idProduct == AX88772B_USB_PRODUCT_ID)) {
+ if (asix_write_rx_ctl(dev, AX_DEFAULT_RX_CTL |
+ AX_RX_HEADER_DEFAULT) 0)
+ goto out_err;
+ } else if (asix_write_rx_ctl(dev, AX_DEFAULT_RX_CTL) 0) {
+ goto out_err;
+ }
+
+ if (asix_write_hwaddr(eth) 0)
goto out_err;
do {
@@ -447,6 +464,10 @@ static int asix_init(struct eth_device *eth, bd_t *bd)
goto out_err;
}
+ /* Wait some more to avoid timeout on first transfer
+ (e.g. EHCI timed out on TD - token=0x8008d80) */
+ udelay(25000);
+
return 0;
out_err:
return -1;
@@ -533,6 +554,11 @@ static int asix_recv(struct eth_device *eth)
return -1;
}
+ if ((dev-pusb_dev-descriptor.idVendor == ASIX_USB_VENDOR_ID)
+(dev-pusb_dev-descriptor.idProduct ==
+ AX88772B_USB_PRODUCT_ID))
+ buf_ptr += 2;
+
/* Notify net stack */
net_process_received_packet(buf_ptr + sizeof(packet_len),
packet_len);
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/8] colibri_vf: remove spurious new line
From: Marcel Ziswiler marcel.ziswi...@toradex.com Remove spurious new line in configuration file. Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com Tested-by: Marek Vasut ma...@denx.de Acked-by: Marek Vasut ma...@denx.de --- Changes in v2: none include/configs/colibri_vf.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h index aff2810..2523f32 100644 --- a/include/configs/colibri_vf.h +++ b/include/configs/colibri_vf.h @@ -69,7 +69,6 @@ 512k(u-boot-env), \ -(ubi) - #define CONFIG_MMC #define CONFIG_FSL_ESDHC #define CONFIG_SYS_FSL_ESDHC_ADDR 0 -- 1.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/8] generic-board: allow showing custom board info
From: Marcel Ziswiler marcel.ziswi...@toradex.com
Allow showing custom board info from a checkboard() function being
implemented if CONFIG_CUSTOM_BOARDINFO is specified. Previously the
device tree model was always displayed not taking any
CONFIG_CUSTOM_BOARDINFO into account.
Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com
---
Changes in v2: reword commit message as requested by Simon
common/board_info.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/board_info.c b/common/board_info.c
index 42d0641..a692f74 100644
--- a/common/board_info.c
+++ b/common/board_info.c
@@ -19,7 +19,7 @@ int __weak checkboard(void)
*/
int show_board_info(void)
{
-#ifdef CONFIG_OF_CONTROL
+#if defined(CONFIG_OF_CONTROL) !defined(CONFIG_CUSTOM_BOARDINFO)
DECLARE_GLOBAL_DATA_PTR;
const char *model;
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 7/8] mtd/nand/ubi: assortment of alignment fixes
From: Marcel Ziswiler marcel.ziswi...@toradex.com
Various U-Boot adoptions/extensions to MTD/NAND/UBI did not take buffer
alignment into account which led to failures of the following form:
ERROR: v7_dcache_inval_range - start address is not aligned - 0x1f7f0108
ERROR: v7_dcache_inval_range - stop address is not aligned - 0x1f7f1108
Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com
---
Changes in v2: run it through checkpatch.pl and fix long lines
common/cmd_ubi.c | 2 +-
drivers/mtd/nand/nand_util.c | 2 +-
fs/ubifs/super.c | 6 --
fs/ubifs/ubifs.c | 5 +++--
lib/gzip.c | 2 +-
5 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/common/cmd_ubi.c b/common/cmd_ubi.c
index cbc10c5..30a1259 100644
--- a/common/cmd_ubi.c
+++ b/common/cmd_ubi.c
@@ -363,7 +363,7 @@ int ubi_volume_read(char *volume, char *buf, size_t size)
tbuf_size = vol-usable_leb_size;
if (size tbuf_size)
tbuf_size = ALIGN(size, ubi-min_io_size);
- tbuf = malloc(tbuf_size);
+ tbuf = memalign(ARCH_DMA_MINALIGN, tbuf_size);
if (!tbuf) {
printf(NO MEM\n);
return ENOMEM;
diff --git a/drivers/mtd/nand/nand_util.c b/drivers/mtd/nand/nand_util.c
index ee2c24d..395ba2d 100644
--- a/drivers/mtd/nand/nand_util.c
+++ b/drivers/mtd/nand/nand_util.c
@@ -839,7 +839,7 @@ int nand_torture(nand_info_t *nand, loff_t offset)
patt_count = ARRAY_SIZE(patterns);
- buf = malloc(nand-erasesize);
+ buf = memalign(ARCH_DMA_MINALIGN, nand-erasesize);
if (buf == NULL) {
puts(Out of memory for erase block buffer\n);
return -ENOMEM;
diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index 10f8fff..daa089b 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -57,7 +57,8 @@ struct inode *iget_locked(struct super_block *sb, unsigned
long ino)
{
struct inode *inode;
- inode = (struct inode *)malloc(sizeof(struct ubifs_inode));
+ inode = (struct inode *)memalign(ARCH_DMA_MINALIGN,
+sizeof(struct ubifs_inode));
if (inode) {
inode-i_ino = ino;
inode-i_sb = sb;
@@ -104,7 +105,8 @@ void iput(struct inode *inode)
/*
* Allocate and use new inode
*/
- ino = (struct inode *)malloc(sizeof(struct ubifs_inode));
+ ino = (struct inode *)memalign(ARCH_DMA_MINALIGN,
+ sizeof(struct ubifs_inode));
memcpy(ino, inode, sizeof(struct ubifs_inode));
/*
diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
index 6dd6174..a0daf3e 100644
--- a/fs/ubifs/ubifs.c
+++ b/fs/ubifs/ubifs.c
@@ -108,7 +108,7 @@ static inline struct crypto_comp *crypto_alloc_comp(const
char *alg_name,
struct crypto_comp *ptr;
int i = 0;
- ptr = malloc(sizeof(struct crypto_comp));
+ ptr = memalign(ARCH_DMA_MINALIGN, sizeof(struct crypto_comp));
while (i UBIFS_COMPR_TYPES_CNT) {
comp = ubifs_compressors[i];
if (!comp) {
@@ -723,7 +723,8 @@ static int do_readpage(struct ubifs_info *c, struct inode
*inode,
* destination area to a multiple of
* UBIFS_BLOCK_SIZE.
*/
- buff = malloc(UBIFS_BLOCK_SIZE);
+ buff = memalign(ARCH_DMA_MINALIGN,
+ UBIFS_BLOCK_SIZE);
if (!buff) {
printf(%s: Error, malloc fails!\n,
__func__);
diff --git a/lib/gzip.c b/lib/gzip.c
index ff37d4f..2a74411 100644
--- a/lib/gzip.c
+++ b/lib/gzip.c
@@ -25,7 +25,7 @@ static void *zalloc(void *x, unsigned items, unsigned size)
size *= items;
size = (size + ZALLOC_ALIGNMENT - 1) ~(ZALLOC_ALIGNMENT - 1);
- p = malloc (size);
+ p = memalign(ARCH_DMA_MINALIGN, size);
return (p);
}
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 6/8] image-fdt.c: store returned error value
From: Max Krummenacher max.krummenac...@toradex.com
This fixes the following warning (and the runtime error reporting):
../common/image-fdt.c:491:4: warning: 'fdt_ret' may be used
uninitialized in this function [-Wmaybe-uninitialized]
Signed-off-by: Max Krummenacher max.krummenac...@toradex.com
Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com
Acked-by: Marek Vasut ma...@denx.de
Acked-by: Simon Glass s...@chromium.org
---
Changes in v2: run it through checkpatch.pl and replace spaces with tab
common/image-fdt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/common/image-fdt.c b/common/image-fdt.c
index 80e3e63..5180a03 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -492,7 +492,8 @@ int image_setup_libfdt(bootm_headers_t *images, void *blob,
}
}
if (IMAGE_OF_SYSTEM_SETUP) {
- if (ft_system_setup(blob, gd-bd)) {
+ fdt_ret = ft_system_setup(blob, gd-bd);
+ if (fdt_ret) {
printf(ERROR: system-specific fdt fixup failed: %s\n,
fdt_strerror(fdt_ret));
goto err;
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 8/8] tftp.c: fix CONFIG_TFTP_TSIZE for small files
From: Max Krummenacher max.krummenac...@toradex.com
CONFIG_TFTP_TSIZE should limit a tftp downloads progress to 50 '#'
chars. Make this work also for small files.
If the file size is small, i.e. smaller than 2 tftp block sizes the
number of '#' can get much larger. i.e. with a 1 byte file 65000
characters are printed, with a 512 byte file around 500.
When using CONFIG TFTP BLOCKSIZE together with CONFIG_IP_DEFRAG the
issue is more notable.
Signed-off-by: Max Krummenacher max.krummenac...@toradex.com
Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com
Reviewed-by: Marek Vasut ma...@denx.de
---
Changes in v2: run it through checkpatch.pl and fix missing space in
if clause as suggested by Marek
net/tftp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/tftp.c b/net/tftp.c
index 3e99e73..89be32a 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -249,6 +249,8 @@ static void show_block_marker(void)
if (tftp_tsize) {
ulong pos = tftp_cur_block * tftp_block_size +
tftp_block_wrap_offset;
+ if (pos tftp_tsize)
+ pos = tftp_tsize;
while (tftp_tsize_num_hash pos * 50 / tftp_tsize) {
putc('#');
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/8] fs/fs.c: read up to EOF when len would read past EOF
From: Max Krummenacher max.krummenac...@toradex.com
http://lists.denx.de/pipermail/u-boot/2012-September/134347.html
allows for reading files in chunks from the shell.
When this feature is used to read past the end of a file an error
was returned instead of returning the bytes read up to the end of
file. Thus the following fails in the shell:
offset = 0
len = chunksize
do
read file, offset, len
write data
until bytes_read len
The patch changes the behaviour to printing an informational
message and returning the actual read number of bytes aka read(2)
behaviour for convenient use in U-Boot scripts.
Signed-off-by: Max Krummenacher max.krummenac...@toradex.com
Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com
Acked-by: Marek Vasut ma...@denx.de
---
Changes in v2: mention read(2) behaviour as suggested by Marek
fs/fs.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/fs.c b/fs/fs.c
index ac0897d..827b143 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -301,10 +301,8 @@ int fs_read(const char *filename, ulong addr, loff_t
offset, loff_t len,
unmap_sysmem(buf);
/* If we requested a specific number of bytes, check we got it */
- if (ret == 0 len *actread != len) {
- printf(** Unable to read file %s **\n, filename);
- ret = -1;
- }
+ if (ret == 0 len *actread != len)
+ printf(** %s shorter than offset + len **\n, filename);
fs_close();
return ret;
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/8] assortment of fixes/enhancements
From: Marcel Ziswiler marcel.ziswi...@toradex.com This patch set is an assortment of fixes/enhancements distilled straight from our downstream integration work. Marcel Ziswiler (4): net: asix: fix operation without eeprom generic-board: allow showing custom board info colibri_vf: remove spurious new line mtd/nand/ubi: assortment of alignment fixes Max Krummenacher (3): fs/fs.c: read up to EOF when len would read past EOF image-fdt.c: store returned error value tftp.c: fix CONFIG_TFTP_TSIZE for small files Stefan Agner (1): logos: add Toradex logo common/board_info.c | 2 +- common/cmd_ubi.c | 2 +- common/image-fdt.c | 3 ++- drivers/mtd/nand/nand_util.c | 2 +- drivers/usb/eth/asix.c | 32 +--- fs/fs.c | 6 ++ fs/ubifs/super.c | 6 -- fs/ubifs/ubifs.c | 5 +++-- include/configs/colibri_vf.h | 1 - lib/gzip.c | 2 +- net/tftp.c | 2 ++ tools/logos/toradex.bmp | Bin 0 - 24982 bytes 12 files changed, 46 insertions(+), 17 deletions(-) create mode 100644 tools/logos/toradex.bmp -- 1.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/8] logos: add Toradex logo
From: Stefan Agner stefan.ag...@toradex.com
Use the boot loader splash screen from WinCE which matches our
wallpapers position wise. Although the logo is an 8-bit indexed BMP as
well colours looked odd at first in U-Boot. After converting to full
RGB palette and converting back to an indexed BMP using imagemagick
the Logo showed up properly.
$ convert tools/logos/toradex-rgb.bmp -type Palette -colors 256 \
-compress none -verbose BMP3:tools/logos/toradex.bmp
Signed-off-by: Stefan Agner stefan.ag...@toradex.com
Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com
---
Changes in v2: none
tools/logos/toradex.bmp | Bin 0 - 24982 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 tools/logos/toradex.bmp
diff --git a/tools/logos/toradex.bmp b/tools/logos/toradex.bmp
new file mode 100644
index
..3e2dcf23358dd46fc7b1bb0dae70d3ba985606ee
GIT binary patch
literal 24982
zcmeHPyH~k6(3!0Ppji;#g)jt)k#_{wd9K2#Q*^=NLXlg21U8%UaK+}lmcz@3r8
zfPpKV!nJ|?0|wHjaPQK8fh$)A3?uJj-pr63?s8A3a}M4CL=NZUy*Iyk^WK{wSAYD=
z=YLa_e*aLZ5_0byDD@|}AE+Uf|MdfP9y$Lad;4aB!dw9z0MF;P2q!Z`5EgP!Em{
z)o?ge$HKN5I3e=V$8d`X=FOvUf4RF-9GwOXm?!4O0+n+q7w@T?zki_KefM4U
z{`E%7cX9@4?p}+ee}^sYW=T|)$^Ax)NlX5B0nM{8Rnmzn`m5KKVp_`st_Yv(G+L
zFJHb?UwrX}`tr*!)mLAArM~|9YxT`H-7fD{Z@VV-FNEy@4r_+{P2VN@y8$4Pe1*n
ze*XDq7JPr*Bd|wckH8**|6c?$-BY$WuXH)+4$GltTd^Dw`HM`*ot!Z`8f993j0-
z)2$!rUtO!-SQ0X^-mmg*715T=*=whD64cerzMc+B?zC=6_$mH3O3tvSK1oLQ{fn
zBEG%WnAcLMi@*T@|n=0S?u4y2i3urHi;E0ZADLN604a@3Vdz+-S{=(3z(U(17X
znYN6Qr7kB^4V;ov=iHE?rY_KKnQ(-KGM5~6zSz0hL2#*Gz!F5#Bx;SV790BUc(Z0
zTv-Oqn?tM$W9kcC%w|iVo9ld5RfuJ#p|YwFOR0^@Y6e(ik%uM7P-H~~O`ioml`Lh
zi_r+?4k#c_Knq%8Lx*KlVfCBAQpF%dg7c}COP$KqNCS@*)LptlZ5j)M9DRW$Uw!Q
z-k5_FV`hXv#kzp!44-Z7RD;q@sjZ_v)g(yr6y$P3UnRR#$JdDh!I0)kSeB$piwli
zoMCm70SR_rmkN-I^b~gactsR=WuNkn%r4}ZY+6frZ7yDoivOB15BQY;7$~)rcVC
z=5Pg7GEfS2_kA?G+#9tYASASQ!XrWlHmeajtaEYWk$(JBrlH-XCOA}0*K!x;
z-B@Ca2s%}0dokq%Dw5+IL1Ak-Q^#^bYnnQ9HPUNgiS~)g3jFWrb^jJ7eblQ;MrE
z)6qmnQw9XREmU~Rys%ZlDn0p6HB%TK#rXgjEWkInxP8Y-?%RH-?(yvgE|o3U36I
zy=0cr7A!*yg!+BllM1CTm$3el0U1hP{gTT;*zy@$Ga0t=wYoIrxH=TwAOJie;
z)Q0qODds^L?T!Li5?ehFKKy960gsFE`T__#84?)eHj~bgPJEg^L}M-1!Nw9222k
z#pP!%)Qj!qOy#IJBd}*P@DFTu*Mn7VrvU*M(zpjCY6j6KCxX*aM5=$d;GEPKY4c
z%LW6(=k?zrh`(^O6LjJbQQ{RaBrJ{1v)0XWhaD~?jQcR00xyjh7%-bxT%;)~_XILD
z4)U`x!I9$#ZS55Ku~W9hJ-tlHbmll6VMZ|t%HkSRf%G%Rzp*F|eFocV@;W5!i!g
zoKlE6g)Cw@gLp6pq2%sZduzNZXGk+1?)ry5jMn^Xzu~;8BGGmm#Aww#h0|+q!!~#
zh|6L4E_wD6s9=nX)w58B1W(%tX?KylBO^-gk@Fbvl2(-1+b38edRD5!c^it(YUM=
z?yoTHYX)2pWGqK$-{CAf%pV=G}I6#1ou6-z#`n_PzLusJYp30La$jzNfJSJwFaq
zKm^)MpG)S7+EYcbZEv!Tt+L*AU0c{3E`1`wSgXK;f9G3NNJg|BhJ$V%C8XMV
z5yY1`2fL_nce%}xkrI(bJujQSb{aBV0~vme{n2hSa*5*k?fC0MP7vz}YlXXD_cJ
zFydwrm~GgPqq*BDWh79O*iIzw*ceaomteE$s2sVf}S`gG9i;!-`UHn2#mE=6fev
zkw?34wneOO$9roR?Wzc$)x6xJk3x3Z=X%$Oek)4R(1N?Q9!%p}udsM_`Y@9)Udq
zdj$3f=D=_ut#7g1dfhR;S1NZ)A5s?x@~D3CDUxNSX@uy!IqYxXUQ^oo}Y;rl8-k
z7=~y_Sua}B_%8Q{7bywk}ggk??@{yFtzrODuu13q}y2?kiiZ1p`)-cw+LQpOIj5Z
z04l;B4L0~ifuwSd2hyR`rbVrW3!=CZ1=h5nsvulJU9VXzr++q%^1QyNVZ7x);W
zmR56rXErFYa#5qJq+MoTP@vA;FTe!r(UZj3!T|jGMM;$+WZJ`o4SvVQNwDa-T
z7W*d;ql_QMSep;2+PAci{oD_Pqx7=*0e{#Y~UESmGXFnWe^1b*qhrGv#Iq(lXQf
zlqs~-fQucgCe4oLCl_rfp=8|AJX9RO5?%qd(+Xdqn6wegluCDsMc6w2RIC|(E3_9
zn0wk#aH6`tJlvbX5vjUl#jSe*F-lMxW~s~D6g(|(9AZLL(!`;pQh#RuBvzw*_+(
zmZ`K}L?U5^rnV}U}R*PnL*;6HbRgItRiH(OT{=Aezw*Gorfj*m(`f?!=t9D
zv`Tu}-=Vj$%z3(RCt@N`^~@zRU5E8F{tF$m83E?KvuA9u^7!vKRaJAM79fBTUv*y
zQRiD0ZB$XO!t+1$)`!pK1Bi7OomuQ!nTto=-RdhERE^T{F#NX@i2)7bYm1BBED
zL(ySrEM1MoiGkeCfjT6sOfT=9$c9$VVOq?S`qM$r;g}xjT2LeMKX?e15vX|8I
z1!=s081cA_+Zqhgvy6h#B*+ScX{~va91Fxx?ENy%`S;1p|o7ff+Y=Z6HCt{0
z7w*8kFn`v1EhZig%1j=OJ`r8Ig5d*S!G@Lo}1uI7bOB7DJvd(J7|2Ewtfqz;KLs
z`QWD{yQL=%xKOUIVm7d3ohijsI+3^?1JHjW7hPK*ZQN!ZISw53pdZk`LrMX*ro7
zHz?Mqi}bffVmiBT5GoD;WUJxD?7K{2fpP~^(Xus1(RJBY;a`FSQ?NadY0BJF)cI
z_+9B^Q)EL}^12i^hRRdiJIlxNz3m68!8SI3NQ_qpOC2sW%Tiji349(8cNTv2#TD
zbb4`R7I}PAm2U4g%5JNoHjDAG_}EZ{R{yu-!3digvC4{FV6HxjBdELbslUQdWt
zK*gKXjkmuxT7e%Z?UWpFsEB9ev?Xpor#B33l7-Rl|Mds8IH*}D0M7{-Md2uihNQR
zmQ1TEpcePVsRD+B!e%49r__wt+|S6rBP?Hy||^m=CSoa-}c1J*ezwqNLfpU7XGn
zGMFqlNXYtR;tuQgfL0w#2F$K_pDP1M1MR|+09%E)$olHCd860a*zd?)ioPT2EXb~
zZpzI5hd3;~SksrjGhdIt(T$VGwDTp9}_dsM@#t8l}TdXp=}*Y__z;Jc$v`hFOYl}
zmgJyI8`Ov-ct0V+h~*|0M4%!#0!IQw!d{$BH$g4dNCfP-kf)5Y^b1i_f0F`B1;RO
zY!foMMT#bpty!xOmTt;@IcWMfVo4FAH0$~R(QmcCp63gevBf*nXM5PgcH-$pmcB
zF02L8E_CmOCHWq!{)DB~($cy1{#erJHeyLL_nNS@S`bFk?MD%yB(MVw0T(E1xE|Bu
z5xI7WgvW*+EqGCcL~rI6{QGg|H0Iu3O_AE_y_a1f*7F|lj8yw5P=91n`ReJ
zw7PJ_a$iWnvawt9Nq6PzVY(b-n1Iuq5si7VbNH%Pe6k{w?X9pnmK?1GMLHxGs$%j
z(*})f$l9EU)rDs^82W8s!E?k|vOUV@fy86-!pOUadqrRmwfp9NMiR(RLFpOU9JX
zBKZ?prG^ZGKc#gnISvdiQ`RiDQtV{C(J*k_Bc#^Y*w_LqF^G(f_FrWC9f!7Qad^9
zq1@KY^F2mqY|}oOqcKF|E}fs9d5`pTDX%J$*p7V=}$AXKBQ!fhEZqR4v|Bu+lMT
ztx#@AAzpj!!z6kOsF*xAPwsxW6A2fjTQ~Tclocdfdm@$Ak*P$ayB+1cHNf-maGn~
za|cP`jp6A|A9)nr(@L8Q`!Jk(MSjZt8Yg{KSM%=k^5A(GdQ8DhfQZp`Kk_uO
zg=GJu^#+y$4(Ho@X%xgjEy@tG(z%BxMMSsoedfakH}z8~_=2W2UGdEtneG*ujri
zcqHyL74Zsi-8OPd37c3d@G_mPR7^p{(uB%3u$7%!xwFG_qTm+isjWYKW2%(4|$
Re: [U-Boot] [PATCH v2] x86: baytrail: Configure FSP UPD from device tree
Hi Bin,
On 07/08 11:18, Bin Meng wrote:
Hi Andrew,
On Wed, Jul 8, 2015 at 3:16 AM, and...@bradfordembedded.com wrote:
From: Andrew Bradford andrew.bradf...@kodakalaris.com
Allow for configuration of FSP UPD from the device tree which will
override any settings which the FSP was built with itself if the device
tree settings exist, otherwise simply trust the FSP's defaults.
Modifies the MinnowMax board to transfer the FSP UPD hard-coded settings
to the MinnowMax dts.
Signed-off-by: Andrew Bradford andrew.bradf...@kodakalaris.com
---
Changes from v1:
- Use - rather than _ in dt property names.
- Use Bay Trail for the formal name of the Intel product family.
- Use an fsp, prefix for dt property names for clarity.
- Fix minor code indentation issues.
- Create a dt subnode for the memory-down-params.
- Clarify documentation that dt overrides the FSP's config, so we don't
use booleans.
arch/x86/cpu/baytrail/fsp_configs.c| 188
+
arch/x86/dts/minnowmax.dts | 30
.../misc/intel,baytrail-fsp.txt| 119 +
include/fdtdec.h | 2 +
lib/fdtdec.c | 2 +
5 files changed, 311 insertions(+), 30 deletions(-)
create mode 100644 doc/device-tree-bindings/misc/intel,baytrail-fsp.txt
diff --git a/arch/x86/cpu/baytrail/fsp_configs.c
b/arch/x86/cpu/baytrail/fsp_configs.c
index 86b6926..fce76e6 100644
--- a/arch/x86/cpu/baytrail/fsp_configs.c
+++ b/arch/x86/cpu/baytrail/fsp_configs.c
@@ -1,14 +1,18 @@
/*
* Copyright (C) 2013, Intel Corporation
* Copyright (C) 2014, Bin Meng bmeng...@gmail.com
+ * Copyright (C) 2015, Kodak Alaris, Inc
*
* SPDX-License-Identifier:Intel
*/
#include common.h
+#include fdtdec.h
#include asm/arch/fsp/azalia.h
#include asm/fsp/fsp_support.h
+DECLARE_GLOBAL_DATA_PTR;
+
/* ALC262 Verb Table - 10EC0262 */
static const uint32_t verb_table_data13[] = {
/* Pin Complex (NID 0x11) */
@@ -116,41 +120,165 @@ const struct pch_azalia_config azalia_config = {
.reset_wait_timer_us = 300
};
+/**
+ * Update the FSP's UPD. The FSP itself can be configured for defaults to
+ * store in UPD through Intel's GUI configurator but likely a specific
board
+ * will want to update these from u-boot, so allow for that via device
tree.
+ * If the device tree does not specify a setting, trust the FSP's default.
+ */
void update_fsp_upd(struct upd_region *fsp_upd)
{
struct memory_down_data *mem;
+ const void *blob = gd-fdt_blob;
+ int node;
- /*
-* Configure everything here to avoid the poor hard-pressed user
-* needing to run Intel's binary configuration tool. It may also
allow
-* us to support the 1GB single core variant easily.
-*
-* TODO(s...@chromium.org): Move to device tree
-*/
- fsp_upd-mrc_init_tseg_size = 8;
- fsp_upd-mrc_init_mmio_size = 0x800;
- fsp_upd-emmc_boot_mode = 0xff;
- fsp_upd-enable_sdio = 1;
- fsp_upd-enable_sdcard = 1;
- fsp_upd-enable_hsuart0 = 1;
fsp_upd-azalia_config_ptr = (uint32_t)azalia_config;
- fsp_upd-enable_i2_c0 = 0;
- fsp_upd-enable_i2_c2 = 0;
- fsp_upd-enable_i2_c3 = 0;
- fsp_upd-enable_i2_c4 = 0;
- fsp_upd-enable_xhci = 0;
- fsp_upd-igd_render_standby = 1;
+
+ node = fdtdec_next_compatible(blob, 0, COMPAT_INTEL_BAYTRAIL_FSP);
+ if (node 0) {
+ debug(%s: Cannot find FSP node\n, __func__);
+ return;
+ }
+
+ fsp_upd-mrc_init_tseg_size = fdtdec_get_int(blob, node,
+
fsp,mrc-int-tseg-size,
mrc-int? Guess it is mrc-init.
Yes, thank you for catching this. Will fix in v3.
+
fsp_upd-mrc_init_tseg_size);
+ fsp_upd-mrc_init_mmio_size = fdtdec_get_int(blob, node,
+
fsp,mrc-init-mmio-size,
+
fsp_upd-mrc_init_mmio_size);
+ fsp_upd-mrc_init_spd_addr1 = fdtdec_get_int(blob, node,
+
fsp,mrc-init-spd-addr1,
+
fsp_upd-mrc_init_spd_addr1);
+ fsp_upd-mrc_init_spd_addr2 = fdtdec_get_int(blob, node,
+
fsp,mrc-init-spd-addr2,
+
fsp_upd-mrc_init_spd_addr2);
+ fsp_upd-emmc_boot_mode = fdtdec_get_int(blob, node,
fsp,emmc-boot-mode,
+fsp_upd-emmc_boot_mode);
+
Re: [U-Boot] [PATCH 1/3] dm: serial: Do not panic if no serial ports are found
Hi Simon,
On 07-07-15 09:00, Hans de Goede wrote:
Hi,
On 06-07-15 18:39, Simon Glass wrote:
Hi Hans,
On 5 July 2015 at 12:56, Hans de Goede hdego...@redhat.com wrote:
Some boards simply do not have any serial ports. Also no one will see the
panic message as there is no where to print it if no serial port is found
(and other stdout options are not yet set up at this point).
It is visible (or will be when some patches land) if you have a debug
UART set up.
Ok.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/serial/serial-uclass.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index 815fec3..f036499 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -27,7 +27,7 @@ static const unsigned long baudrate_table[] =
CONFIG_SYS_BAUDRATE_TABLE;
#error Serial is required before relocation - define CONFIG_SYS_MALLOC_F_LEN to
make this work
#endif
-static void serial_find_console_or_panic(void)
+static void serial_find_console(void)
{
struct udevice *dev;
int node;
@@ -77,14 +77,12 @@ static void serial_find_console_or_panic(void)
}
#undef INDEX
}
-
- panic_str(No serial driver found);
}
/* Called prior to relocation */
int serial_init(void)
{
- serial_find_console_or_panic();
+ serial_find_console();
gd-flags |= GD_FLG_SERIAL_READY;
return 0;
@@ -93,7 +91,7 @@ int serial_init(void)
/* Called after relocation */
void serial_initialize(void)
{
- serial_find_console_or_panic();
+ serial_find_console();
}
static void _serial_putc(struct udevice *dev, char ch)
How is this handled before driver model?
It was not, the boards involved all use the A13 SoC which is the
same die as the A10s but then in a different (cheaper) package
with way less pins. As such uart0 is not routed to the outside
on the A13. When not setting CONFIG_DM_SERIAL we are simply using
uart0 as serial console, and that ends at the bonding pads at the
edge of the die. doing things that way is not really useful,
but there is a serial console and u-boot is happy.
In the non devicetree world this sort of was a natural hack, we
simply left CONSOLE_INDEX undefined for these boards, which causes
it to default to 1 / uart0 and things just work. I had never given
this much thought until moving to devicetree.
As you can hopefully understand I do not want to do the samething
with DM_SERIAL builds as that would require hacking up the dts
to add a node for hardware which is effectively disabled for the
A13 package of the sun5i die.
It is possible to mark a
device disabled in device tree - perhaps we should have a way to see
that the console is present (i.e. there is an alias) but it is
disabled?
That seems rather ugly, I really do not want to add an alias to
a non enabled device, that just feels wrong on all levels.
Normally a serial console is required, so I'd like to preserve this
behaviour for most boards.
Ok, I actually expected as much, this was actually my second solution
for the problem at hand, but as it was the simplest solution I decided
to submit this version first. My first / original solution is to add a
CONFIG_DM_SERIAL_NO_PANIC Kconfig option which can then be set on boards
which have no serial port.
Or probably better a CONFIG_DM_SERIAL_NO_SERIAL_CONSOLE option ?
This option would disable the panic / disable probing all together while
we would keep using DM_SERIAL on these boards, because:
1) Consistency I really want to use DM_FOO everywhere for sunxi
2) The non dm serial code cannot handle not having a serial port either,
and fixing it looks like it is going to be a bit harder (from a quick
glance).
You probably just have not gotten around to this yet, but in case it is
not clear, the above solution (adding a CONFIG_DM_SERIAL_NO_SERIAL_CONSOLE
Kconfig option) is a suggestion on how to fix. I'll happily implement this
if people like it, but atm I'm waiting for feedback on the suggestion.
Regards,
Hans
p.s.
I'm on vacation from July 11th - July 19th, so if I'm quiet that is why :)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] pci: Add function to find an extended capability
Hi Minghuan,
On Tue, Jul 7, 2015 at 7:55 PM, Minghuan Lian
minghuan.l...@freescale.com wrote:
PCIe extends device's configuration space to 4k and provides
extended capability. The patch adds function to find them.
The code is ported from Linux PCIe driver.
Signed-off-by: Minghuan Lian minghuan.l...@freescale.com
---
drivers/pci/pci.c | 45 +
include/pci.h | 41 +
2 files changed, 86 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 157491c..c9bc098 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -526,3 +526,48 @@ int pci_find_cap(struct pci_controller *hose, pci_dev_t
dev, int pos, int cap)
}
return 0;
}
+
+int pci_find_next_ext_capability(struct pci_controller *hose, pci_dev_t dev,
+int start, int cap)
I am thinking whether we should provide this API too. Maybe just
pci_hose_find_ext_capability() is enough.
+{
+ u32 header;
+ int ttl, pos = PCI_CFG_SPACE_SIZE;
+
+ /* minimum 8 bytes per capability */
+ ttl = (PCI_CFG_SPACE_EXP_SIZE - PCI_CFG_SPACE_SIZE) / 8;
+
+ if (start)
+ pos = start;
+
+ pci_hose_read_config_dword(hose, dev, pos, header);
+ if (header == 0x || header == 0)
+ return 0;
+
+ while (ttl-- 0) {
+ if (PCI_EXT_CAP_ID(header) == cap pos != start)
+ return pos;
+
+ pos = PCI_EXT_CAP_NEXT(header);
+ if (pos PCI_CFG_SPACE_SIZE)
+ break;
+
+ pci_hose_read_config_dword(hose, dev, pos, header);
+ if (header == 0x || header == 0)
+ break;
+ }
+
+ return 0;
+}
+
+/**
+ * pci_host_find_ext_capability - Find an extended capability
Typo. pci_hose
+ *
+ * Returns the address of the requested extended capability structure
+ * within the device's PCI configuration space or 0 if the device does
+ * not support it.
+ */
+int pci_hose_find_ext_capability(struct pci_controller *hose, pci_dev_t dev,
+int cap)
+{
+ return pci_find_next_ext_capability(hose, dev, 0, cap);
+}
diff --git a/include/pci.h b/include/pci.h
index 07b1e9a..2f88714 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -11,6 +11,9 @@
#ifndef _PCI_H
#define _PCI_H
+#define PCI_CFG_SPACE_SIZE 256
+#define PCI_CFG_SPACE_EXP_SIZE 4096
+
/*
* Under PCI, each device has 256 bytes of configuration address space,
* of which the first 64 bytes are standardized as follows:
@@ -413,6 +416,39 @@
#define PCI_FIND_CAP_TTL 0x48
#define CAP_START_POS 0x40
+/* Extended Capabilities (PCI-X 2.0 and Express) */
+#define PCI_EXT_CAP_ID(header) (header 0x)
+#define PCI_EXT_CAP_VER(header)((header 16) 0xf)
+#define PCI_EXT_CAP_NEXT(header) ((header 20) 0xffc)
+
+#define PCI_EXT_CAP_ID_ERR 0x01/* Advanced Error Reporting */
+#define PCI_EXT_CAP_ID_VC 0x02/* Virtual Channel Capability */
+#define PCI_EXT_CAP_ID_DSN 0x03/* Device Serial Number */
+#define PCI_EXT_CAP_ID_PWR 0x04/* Power Budgeting */
+#define PCI_EXT_CAP_ID_RCLD0x05/* Root Complex Link Declaration */
+#define PCI_EXT_CAP_ID_RCILC 0x06/* Root Complex Internal Link Control
*/
+#define PCI_EXT_CAP_ID_RCEC0x07/* Root Complex Event Collector */
+#define PCI_EXT_CAP_ID_MFVC0x08/* Multi-Function VC Capability */
+#define PCI_EXT_CAP_ID_VC9 0x09/* same as _VC */
+#define PCI_EXT_CAP_ID_RCRB0x0A/* Root Complex RB? */
+#define PCI_EXT_CAP_ID_VNDR0x0B/* Vendor-Specific */
+#define PCI_EXT_CAP_ID_CAC 0x0C/* Config Access - obsolete */
+#define PCI_EXT_CAP_ID_ACS 0x0D/* Access Control Services */
+#define PCI_EXT_CAP_ID_ARI 0x0E/* Alternate Routing ID */
+#define PCI_EXT_CAP_ID_ATS 0x0F/* Address Translation Services */
+#define PCI_EXT_CAP_ID_SRIOV 0x10/* Single Root I/O Virtualization */
+#define PCI_EXT_CAP_ID_MRIOV 0x11/* Multi Root I/O Virtualization */
+#define PCI_EXT_CAP_ID_MCAST 0x12/* Multicast */
+#define PCI_EXT_CAP_ID_PRI 0x13/* Page Request Interface */
+#define PCI_EXT_CAP_ID_AMD_XXX 0x14/* Reserved for AMD */
+#define PCI_EXT_CAP_ID_REBAR 0x15/* Resizable BAR */
+#define PCI_EXT_CAP_ID_DPA 0x16/* Dynamic Power Allocation */
+#define PCI_EXT_CAP_ID_TPH 0x17/* TPH Requester */
+#define PCI_EXT_CAP_ID_LTR 0x18/* Latency Tolerance Reporting */
+#define PCI_EXT_CAP_ID_SECPCI 0x19/* Secondary PCIe Capability */
+#define PCI_EXT_CAP_ID_PMUX0x1A/* Protocol Multiplexing */
+#define PCI_EXT_CAP_ID_PASID 0x1B/* Process Address Space ID */
+
/* Include the ID list */
#include pci_ids.h
@@
Re: [U-Boot] [PATCH 1/3] dm: dts: ls2085a: Bring in ls2085a dts files from linux kernel
Hello Sharma, On Wed, 8 Jul 2015 07:31:47 +, Sharma Bhupesh bhupesh.sha...@freescale.com wrote: -Original Message- From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wang Haikun On 7/8/2015 3:13 PM, Bin Meng wrote: Hi, On Wed, Jul 8, 2015 at 2:51 PM, Wang Haikun haikun.w...@freescale.com wrote: On 6/26/2015 7:53 PM, Haikun Wang wrote: From: Haikun Wang haikun.w...@freescale.com Bring in required device tree files for ls2085a from Linux. These are initially unchanged and have a number of pieces not needed by U-Boot. Hi Simon, I got below comment when review this patch internal. Please help me confirm. For new platforms like ARM64, it was discussed to not duplicate the DTS in u-boot and Linux, simply because that will break compatibility with other bootloaders like Linaro's BootMonitor and UEFI bootloader, which do not place the DTS in the bootloader. Also in near future, with DTS being replaced by ACPI gradually for ARM64 platforms, it was discussed that in a longer run it would be beneficial to move DTS out of both u-boot and Linux and maintain it as a separate tree. I think UEFI + ACPI is only required for ARMv8 servers, not for all ARMv8 processors. Is ls2085a a processor targeting the server market? No, at least it's not our major market. I want to know whether we have made a conclusion that u-boot will not add Arm64 dts files? Adding Russell and Mark for their thoughts. AFAIK there were discussions to generate common DTS files for PPC and ARM platforms, where it was discussed that in a longer run it would be beneficial to move DTS out of both u-boot and Linux and maintain it as a separate tree. This might be what happens in the long term (and I pretty much agree with having DTS common to, and separate from, any project that uses them even though that means yet one more configuration item to manage at the full project delivery level), but precisely because it is a long term goal, it is not what's going on right now. In the interim, and AFAIAC, I'm fine with DTS files living in U-Boot. And I'd be finer yet with a simple way to specify where the DTS files can be searched for at build time, using e.g. an env var, something like: DTC_PATH = /home/dev/linux/arch/arm/boot/dtc tools/buildman/... I believe this would be quite easy to implement in both U-Boot and Linux with dtc_cpp_flags, by passing DTC_PATH as a -I option. One could even specify a set of paths, which would produce several -I options, for instance making dtc search first in U-Boot's own repo, then in the standalone DTS files projects repo (once a standalone DTS files project exists, that is). Looking in U-Boot first would allow using U-boot as a staging area for new DTS files until the standalone DTS project picks them up. Regards, Bhupesh Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] warning: override: reassigning to symbol OF_CONTROL
On Wed, Jul 8, 2015 at 5:05 PM, Bin Meng bmeng...@gmail.com wrote: Hi Simon, I've rebased my git repo on u-boot-x86/master branch and found one warning popped up: $ make crownbay_defconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf arch/../configs/crownbay_defconfig:23:warning: override: reassigning to symbol OF_CONTROL Do you know where is this coming from? Never mind. I found the cause. It is caused by duplicated entries in the defconfig, which should be caused by the u-boot-x86/master rebase operation on the u-boot master branch. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] dm: dts: ls2085a: Bring in ls2085a dts files from linux kernel
-Original Message- From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wang Haikun On 7/8/2015 3:13 PM, Bin Meng wrote: Hi, On Wed, Jul 8, 2015 at 2:51 PM, Wang Haikun haikun.w...@freescale.com wrote: On 6/26/2015 7:53 PM, Haikun Wang wrote: From: Haikun Wang haikun.w...@freescale.com Bring in required device tree files for ls2085a from Linux. These are initially unchanged and have a number of pieces not needed by U-Boot. Hi Simon, I got below comment when review this patch internal. Please help me confirm. For new platforms like ARM64, it was discussed to not duplicate the DTS in u-boot and Linux, simply because that will break compatibility with other bootloaders like Linaro's BootMonitor and UEFI bootloader, which do not place the DTS in the bootloader. Also in near future, with DTS being replaced by ACPI gradually for ARM64 platforms, it was discussed that in a longer run it would be beneficial to move DTS out of both u-boot and Linux and maintain it as a separate tree. I think UEFI + ACPI is only required for ARMv8 servers, not for all ARMv8 processors. Is ls2085a a processor targeting the server market? No, at least it's not our major market. I want to know whether we have made a conclusion that u-boot will not add Arm64 dts files? Adding Russell and Mark for their thoughts. AFAIK there were discussions to generate common DTS files for PPC and ARM platforms, where it was discussed that in a longer run it would be beneficial to move DTS out of both u-boot and Linux and maintain it as a separate tree. Regards, Bhupesh Best regards, Wang Haikun [snip] Regards, Bin ___ 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 1/2] pci: Add function to find an extended capability
Hi Bin,
Thanks for your comments.
Please see my reply inline.
-Original Message-
From: Bin Meng [mailto:bmeng...@gmail.com]
Sent: Wednesday, July 08, 2015 4:14 PM
To: Lian Minghuan-B31939
Cc: U-Boot Mailing List; Hu Mingkai-B21284; Sun York-R58495
Subject: Re: [U-Boot] [PATCH 1/2] pci: Add function to find an extended
capability
Hi Minghuan,
On Tue, Jul 7, 2015 at 7:55 PM, Minghuan Lian
minghuan.l...@freescale.com wrote:
PCIe extends device's configuration space to 4k and provides extended
capability. The patch adds function to find them.
The code is ported from Linux PCIe driver.
Signed-off-by: Minghuan Lian minghuan.l...@freescale.com
---
drivers/pci/pci.c | 45
+
include/pci.h | 41 +
2 files changed, 86 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index
157491c..c9bc098 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -526,3 +526,48 @@ int pci_find_cap(struct pci_controller *hose,
pci_dev_t dev, int pos, int cap)
}
return 0;
}
+
+int pci_find_next_ext_capability(struct pci_controller *hose, pci_dev_t
dev,
+int start, int cap)
I am thinking whether we should provide this API too. Maybe just
pci_hose_find_ext_capability() is enough.
[Minghuan] pci_hose_find_ext_capability() only can return the pos of the first
capability query.
pci_find_next_ext_capability can return the second third .. pos of the
searched capability.
We may refer to the comment of Linux
Some capabilities can occur several times, e.g., the
* vendor-specific capability, and this provides a way to find them all.
+{
+ u32 header;
+ int ttl, pos = PCI_CFG_SPACE_SIZE;
+
+ /* minimum 8 bytes per capability */
+ ttl = (PCI_CFG_SPACE_EXP_SIZE - PCI_CFG_SPACE_SIZE) / 8;
+
+ if (start)
+ pos = start;
+
+ pci_hose_read_config_dword(hose, dev, pos, header);
+ if (header == 0x || header == 0)
+ return 0;
+
+ while (ttl-- 0) {
+ if (PCI_EXT_CAP_ID(header) == cap pos != start)
+ return pos;
+
+ pos = PCI_EXT_CAP_NEXT(header);
+ if (pos PCI_CFG_SPACE_SIZE)
+ break;
+
+ pci_hose_read_config_dword(hose, dev, pos, header);
+ if (header == 0x || header == 0)
+ break;
+ }
+
+ return 0;
+}
+
+/**
+ * pci_host_find_ext_capability - Find an extended capability
Typo. pci_hose
[Minghuan] Sorry, I will fix it.
+ *
+ * Returns the address of the requested extended capability structure
+ * within the device's PCI configuration space or 0 if the device
+does
+ * not support it.
+ */
+int pci_hose_find_ext_capability(struct pci_controller *hose, pci_dev_t
dev,
+int cap) {
+ return pci_find_next_ext_capability(hose, dev, 0, cap); }
diff --git a/include/pci.h b/include/pci.h index 07b1e9a..2f88714
100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -11,6 +11,9 @@
#ifndef _PCI_H
#define _PCI_H
+#define PCI_CFG_SPACE_SIZE 256
+#define PCI_CFG_SPACE_EXP_SIZE 4096
+
/*
* Under PCI, each device has 256 bytes of configuration address space,
* of which the first 64 bytes are standardized as follows:
@@ -413,6 +416,39 @@
#define PCI_FIND_CAP_TTL 0x48
#define CAP_START_POS 0x40
+/* Extended Capabilities (PCI-X 2.0 and Express) */
+#define PCI_EXT_CAP_ID(header) (header 0x)
+#define PCI_EXT_CAP_VER(header)((header 16) 0xf)
+#define PCI_EXT_CAP_NEXT(header) ((header 20) 0xffc)
+
+#define PCI_EXT_CAP_ID_ERR 0x01/* Advanced Error Reporting */
+#define PCI_EXT_CAP_ID_VC 0x02/* Virtual Channel Capability */
+#define PCI_EXT_CAP_ID_DSN 0x03/* Device Serial Number */
+#define PCI_EXT_CAP_ID_PWR 0x04/* Power Budgeting */
+#define PCI_EXT_CAP_ID_RCLD0x05/* Root Complex Link Declaration
*/
+#define PCI_EXT_CAP_ID_RCILC 0x06/* Root Complex Internal Link
Control */
+#define PCI_EXT_CAP_ID_RCEC0x07/* Root Complex Event Collector
*/
+#define PCI_EXT_CAP_ID_MFVC0x08/* Multi-Function VC Capability
*/
+#define PCI_EXT_CAP_ID_VC9 0x09/* same as _VC */
+#define PCI_EXT_CAP_ID_RCRB0x0A/* Root Complex RB? */
+#define PCI_EXT_CAP_ID_VNDR0x0B/* Vendor-Specific */
+#define PCI_EXT_CAP_ID_CAC 0x0C/* Config Access - obsolete */
+#define PCI_EXT_CAP_ID_ACS 0x0D/* Access Control Services */
+#define PCI_EXT_CAP_ID_ARI 0x0E/* Alternate Routing ID */
+#define PCI_EXT_CAP_ID_ATS 0x0F/* Address Translation Services */
+#define PCI_EXT_CAP_ID_SRIOV
Re: [U-Boot] [PATCH 1/3] dm: dts: ls2085a: Bring in ls2085a dts files from linux kernel
Hi Albert -Original Message- From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net] Sent: Wednesday, July 08, 2015 2:50 PM To: Sharma Bhupesh-B45370 Cc: Wang Haikun-B53464; Bin Meng; Russell King; Mark Rutland; Sun York- R58495; Kushwaha Prabhakar-B32579; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 1/3] dm: dts: ls2085a: Bring in ls2085a dts files from linux kernel Hello Sharma, On Wed, 8 Jul 2015 07:31:47 +, Sharma Bhupesh bhupesh.sha...@freescale.com wrote: -Original Message- From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wang Haikun On 7/8/2015 3:13 PM, Bin Meng wrote: Hi, On Wed, Jul 8, 2015 at 2:51 PM, Wang Haikun haikun.w...@freescale.com wrote: On 6/26/2015 7:53 PM, Haikun Wang wrote: From: Haikun Wang haikun.w...@freescale.com Bring in required device tree files for ls2085a from Linux. These are initially unchanged and have a number of pieces not needed by U-Boot. Hi Simon, I got below comment when review this patch internal. Please help me confirm. For new platforms like ARM64, it was discussed to not duplicate the DTS in u-boot and Linux, simply because that will break compatibility with other bootloaders like Linaro's BootMonitor and UEFI bootloader, which do not place the DTS in the bootloader. Also in near future, with DTS being replaced by ACPI gradually for ARM64 platforms, it was discussed that in a longer run it would be beneficial to move DTS out of both u-boot and Linux and maintain it as a separate tree. I think UEFI + ACPI is only required for ARMv8 servers, not for all ARMv8 processors. Is ls2085a a processor targeting the server market? No, at least it's not our major market. I want to know whether we have made a conclusion that u-boot will not add Arm64 dts files? Adding Russell and Mark for their thoughts. AFAIK there were discussions to generate common DTS files for PPC and ARM platforms, where it was discussed that in a longer run it would be beneficial to move DTS out of both u-boot and Linux and maintain it as a separate tree. This might be what happens in the long term (and I pretty much agree with having DTS common to, and separate from, any project that uses them even though that means yet one more configuration item to manage at the full project delivery level), but precisely because it is a long term goal, it is not what's going on right now. In the interim, and AFAIAC, I'm fine with DTS files living in U-Boot. And I'd be finer yet with a simple way to specify where the DTS files can be searched for at build time, using e.g. an env var, something like: DTC_PATH = /home/dev/linux/arch/arm/boot/dtc tools/buildman/... I believe this would be quite easy to implement in both U-Boot and Linux with dtc_cpp_flags, by passing DTC_PATH as a -I option. One could even specify a set of paths, which would produce several -I options, for instance making dtc search first in U-Boot's own repo, then in the standalone DTS files projects repo (once a standalone DTS files project exists, that is). Looking in U-Boot first would allow using U- boot as a staging area for new DTS files until the standalone DTS project picks them up. I am in agreement, with what you said above, but we must be careful to not introduce any dependencies in Linux dts assuming that the u-boot dts will fix them up or implement them. With Linaro BootMonitor and UEFI like bootloaders, which don't have the comprehensive DTS infrastructure, nor the dts fixup infrastructure, we should be pushing u-boot dts changes back to the Linux dts, to make sure that Linux boots fine with other ARM64 bootloaders like UEFI. Regards, Bhupesh Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] warning: override: reassigning to symbol OF_CONTROL
Hi Simon, I've rebased my git repo on u-boot-x86/master branch and found one warning popped up: $ make crownbay_defconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf arch/../configs/crownbay_defconfig:23:warning: override: reassigning to symbol OF_CONTROL Do you know where is this coming from? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/8] net: asix: fix operation without eeprom
On Wednesday, July 08, 2015 at 01:58:47 PM, Marcel Ziswiler wrote:
From: Marcel Ziswiler marcel.ziswi...@toradex.com
This patch fixes operation of our on-board AX88772B chip without EEPROM
but with a ethaddr coming from the regular U-Boot environment. This is
a forward port of some remaining parts initially implemented by
Antmicro.
Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com
Hi!
---
Changes in v2:
- run it through checkpatch.pl as suggested by Marek and Joe
- cleanup comments and use VID/PID defines as suggested by Marek
- dug out an AX88772 (not B) dongle again and verified operation
- AX88772 (not B) indeed does not work with B modifications
(e.g. VID/PID based differentiation is indeed required)
- dug out another AX88772B dongle as well and verified operation
drivers/usb/eth/asix.c | 32 +---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/eth/asix.c b/drivers/usb/eth/asix.c
index c8697ae..1c2c2d0 100644
--- a/drivers/usb/eth/asix.c
+++ b/drivers/usb/eth/asix.c
@@ -1,6 +1,8 @@
/*
* Copyright (c) 2011 The Chromium OS Authors.
*
+ * Patched for AX88772B by Antmicro Ltd www.antmicro.com
+ *
* SPDX-License-Identifier: GPL-2.0+
*/
@@ -64,8 +66,11 @@
AX_MEDIUM_AC | AX_MEDIUM_RE)
/* AX88772 AX88178 RX_CTL values */
-#define AX_RX_CTL_SO 0x0080
-#define AX_RX_CTL_AB 0x0008
+#define AX_RX_CTL_RH2M 0x0200 /* 32-bit aligned RX IP header
*/
+#define AX_RX_CTL_RH1M 0x0100 /* Enable RX header format type
1
*/
+#define AX_RX_CTL_SO 0x0080
+#define AX_RX_CTL_AB 0x0008
+#define AX_RX_HEADER_DEFAULT (AX_RX_CTL_RH1M | AX_RX_CTL_RH2M)
#define AX_DEFAULT_RX_CTL\
(AX_RX_CTL_SO | AX_RX_CTL_AB)
@@ -92,6 +97,9 @@
#define FLAG_TYPE_AX88772B (1U 2)
#define FLAG_EEPROM_MAC (1U 3) /* initial mac address in
eeprom */
+#define ASIX_USB_VENDOR_ID 0x0b95
+#define AX88772B_USB_PRODUCT_ID 0x772b
+
/* local vars */
static int curr_eth_dev; /* index for name of next device detected */
@@ -426,7 +434,16 @@ static int asix_init(struct eth_device *eth, bd_t *bd)
debug(** %s()\n, __func__);
- if (asix_write_rx_ctl(dev, AX_DEFAULT_RX_CTL) 0)
+ if ((dev-pusb_dev-descriptor.idVendor == ASIX_USB_VENDOR_ID)
+ (dev-pusb_dev-descriptor.idProduct == AX88772B_USB_PRODUCT_ID)) {
I'd introduce a variable here, like ...
u32 ctl = AX_DEFAULT_RX_CTL;
if (test the ID here)
ctl |= AX_RX_HEADER_DEFAULT;
asix_write();
That might be more readable, no ? :)
+ if (asix_write_rx_ctl(dev, AX_DEFAULT_RX_CTL |
+AX_RX_HEADER_DEFAULT) 0)
+ goto out_err;
+ } else if (asix_write_rx_ctl(dev, AX_DEFAULT_RX_CTL) 0) {
+ goto out_err;
+ }
+
+ if (asix_write_hwaddr(eth) 0)
goto out_err;
do {
@@ -447,6 +464,10 @@ static int asix_init(struct eth_device *eth, bd_t *bd)
goto out_err;
}
+ /* Wait some more to avoid timeout on first transfer
+(e.g. EHCI timed out on TD - token=0x8008d80) */
Comment style :)
+ udelay(25000);
mdelay(25); :)
return 0;
out_err:
return -1;
@@ -533,6 +554,11 @@ static int asix_recv(struct eth_device *eth)
return -1;
}
+ if ((dev-pusb_dev-descriptor.idVendor == ASIX_USB_VENDOR_ID)
+ (dev-pusb_dev-descriptor.idProduct ==
+ AX88772B_USB_PRODUCT_ID))
+ buf_ptr += 2;
+
/* Notify net stack */
net_process_received_packet(buf_ptr + sizeof(packet_len),
packet_len);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/8] mtd/nand/ubi: assortment of alignment fixes
On 8 July 2015 at 05:58, Marcel Ziswiler mar...@ziswiler.com wrote: From: Marcel Ziswiler marcel.ziswi...@toradex.com Various U-Boot adoptions/extensions to MTD/NAND/UBI did not take buffer alignment into account which led to failures of the following form: ERROR: v7_dcache_inval_range - start address is not aligned - 0x1f7f0108 ERROR: v7_dcache_inval_range - stop address is not aligned - 0x1f7f1108 Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com --- Changes in v2: run it through checkpatch.pl and fix long lines common/cmd_ubi.c | 2 +- drivers/mtd/nand/nand_util.c | 2 +- fs/ubifs/super.c | 6 -- fs/ubifs/ubifs.c | 5 +++-- lib/gzip.c | 2 +- 5 files changed, 10 insertions(+), 7 deletions(-) Reviewed-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/8] generic-board: allow showing custom board info
On 8 July 2015 at 05:58, Marcel Ziswiler mar...@ziswiler.com wrote: From: Marcel Ziswiler marcel.ziswi...@toradex.com Allow showing custom board info from a checkboard() function being implemented if CONFIG_CUSTOM_BOARDINFO is specified. Previously the device tree model was always displayed not taking any CONFIG_CUSTOM_BOARDINFO into account. Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com --- Changes in v2: reword commit message as requested by Simon common/board_info.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] x86: Eliminate make defconfig warning for Crown Bay and Minnowmax
Remove duplicated entry of OF_CONTROL in crownbay_defconfig and minnowmax_defconfig which causes a warning when making defconfig. The updated defconfig files are generated by 'make savedefconfig'. Signed-off-by: Bin Meng bmeng...@gmail.com --- configs/crownbay_defconfig | 14 ++ configs/minnowmax_defconfig | 6 ++ 2 files changed, 8 insertions(+), 12 deletions(-) diff --git a/configs/crownbay_defconfig b/configs/crownbay_defconfig index c906883..17e6a72 100644 --- a/configs/crownbay_defconfig +++ b/configs/crownbay_defconfig @@ -4,7 +4,10 @@ CONFIG_DEFAULT_DEVICE_TREE=crownbay CONFIG_TARGET_CROWNBAY=y CONFIG_SMP=y CONFIG_MAX_CPUS=2 +CONFIG_HAVE_VGA_BIOS=y CONFIG_GENERATE_PIRQ_TABLE=y +CONFIG_GENERATE_MP_TABLE=y +CONFIG_CMD_CPU=y # CONFIG_CMD_IMLS is not set # CONFIG_CMD_FLASH is not set # CONFIG_CMD_SETEXPR is not set @@ -13,15 +16,10 @@ CONFIG_BOOTSTAGE=y CONFIG_BOOTSTAGE_REPORT=y CONFIG_CMD_BOOTSTAGE=y CONFIG_OF_CONTROL=y -CONFIG_SPI_FLASH=y -CONFIG_USE_PRIVATE_LIBGCC=y -CONFIG_SYS_VSNPRINTF=y -CONFIG_HAVE_VGA_BIOS=y -CONFIG_GENERATE_MP_TABLE=y -CONFIG_CMD_CPU=y -CONFIG_CMD_NET=y -CONFIG_OF_CONTROL=y CONFIG_CPU=y +CONFIG_SPI_FLASH=y CONFIG_VIDEO_VESA=y CONFIG_FRAMEBUFFER_SET_VESA_MODE=y CONFIG_DM_RTC=y +CONFIG_USE_PRIVATE_LIBGCC=y +CONFIG_SYS_VSNPRINTF=y diff --git a/configs/minnowmax_defconfig b/configs/minnowmax_defconfig index 582d6cc..29dd44b 100644 --- a/configs/minnowmax_defconfig +++ b/configs/minnowmax_defconfig @@ -3,8 +3,8 @@ CONFIG_VENDOR_INTEL=y CONFIG_DEFAULT_DEVICE_TREE=minnowmax CONFIG_TARGET_MINNOWMAX=y CONFIG_HAVE_INTEL_ME=y -CONFIG_HAVE_VGA_BIOS=y CONFIG_SMP=y +CONFIG_HAVE_VGA_BIOS=y CONFIG_GENERATE_SFI_TABLE=y CONFIG_CMD_CPU=y # CONFIG_CMD_IMLS is not set @@ -16,12 +16,10 @@ CONFIG_BOOTSTAGE_REPORT=y CONFIG_CMD_BOOTSTAGE=y CONFIG_OF_CONTROL=y CONFIG_CPU=y +CONFIG_DM_PCI=y CONFIG_SPI_FLASH=y CONFIG_VIDEO_VESA=y CONFIG_FRAMEBUFFER_SET_VESA_MODE=y CONFIG_FRAMEBUFFER_VESA_MODE_11A=y CONFIG_USE_PRIVATE_LIBGCC=y CONFIG_SYS_VSNPRINTF=y -CONFIG_CMD_NET=y -CONFIG_OF_CONTROL=y -CONFIG_DM_PCI=y -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] dm: dts: ls2085a: Bring in ls2085a dts files from linux kernel
Hello Sharma, On Wed, 8 Jul 2015 10:31:45 +, Sharma Bhupesh bhupesh.sha...@freescale.com wrote: Hi Albert -Original Message- From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net] Sent: Wednesday, July 08, 2015 2:50 PM To: Sharma Bhupesh-B45370 Cc: Wang Haikun-B53464; Bin Meng; Russell King; Mark Rutland; Sun York- R58495; Kushwaha Prabhakar-B32579; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 1/3] dm: dts: ls2085a: Bring in ls2085a dts files from linux kernel Hello Sharma, On Wed, 8 Jul 2015 07:31:47 +, Sharma Bhupesh bhupesh.sha...@freescale.com wrote: -Original Message- From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wang Haikun On 7/8/2015 3:13 PM, Bin Meng wrote: Hi, On Wed, Jul 8, 2015 at 2:51 PM, Wang Haikun haikun.w...@freescale.com wrote: On 6/26/2015 7:53 PM, Haikun Wang wrote: From: Haikun Wang haikun.w...@freescale.com Bring in required device tree files for ls2085a from Linux. These are initially unchanged and have a number of pieces not needed by U-Boot. Hi Simon, I got below comment when review this patch internal. Please help me confirm. For new platforms like ARM64, it was discussed to not duplicate the DTS in u-boot and Linux, simply because that will break compatibility with other bootloaders like Linaro's BootMonitor and UEFI bootloader, which do not place the DTS in the bootloader. Also in near future, with DTS being replaced by ACPI gradually for ARM64 platforms, it was discussed that in a longer run it would be beneficial to move DTS out of both u-boot and Linux and maintain it as a separate tree. I think UEFI + ACPI is only required for ARMv8 servers, not for all ARMv8 processors. Is ls2085a a processor targeting the server market? No, at least it's not our major market. I want to know whether we have made a conclusion that u-boot will not add Arm64 dts files? Adding Russell and Mark for their thoughts. AFAIK there were discussions to generate common DTS files for PPC and ARM platforms, where it was discussed that in a longer run it would be beneficial to move DTS out of both u-boot and Linux and maintain it as a separate tree. This might be what happens in the long term (and I pretty much agree with having DTS common to, and separate from, any project that uses them even though that means yet one more configuration item to manage at the full project delivery level), but precisely because it is a long term goal, it is not what's going on right now. In the interim, and AFAIAC, I'm fine with DTS files living in U-Boot. And I'd be finer yet with a simple way to specify where the DTS files can be searched for at build time, using e.g. an env var, something like: DTC_PATH = /home/dev/linux/arch/arm/boot/dtc tools/buildman/... I believe this would be quite easy to implement in both U-Boot and Linux with dtc_cpp_flags, by passing DTC_PATH as a -I option. One could even specify a set of paths, which would produce several -I options, for instance making dtc search first in U-Boot's own repo, then in the standalone DTS files projects repo (once a standalone DTS files project exists, that is). Looking in U-Boot first would allow using U- boot as a staging area for new DTS files until the standalone DTS project picks them up. I am in agreement, with what you said above, but we must be careful to not introduce any dependencies in Linux dts assuming that the u-boot dts will fix them up or implement them. With Linaro BootMonitor and UEFI like bootloaders, which don't have the comprehensive DTS infrastructure, nor the dts fixup infrastructure, we should be pushing u-boot dts changes back to the Linux dts, to make sure that Linux boots fine with other ARM64 bootloaders like UEFI. Agreed: DTS files should be designed to work with all projects that use them, even DTS files temporarily provided within U-Boot. Regards, Bhupesh Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 22/54] dm: Correct the missing method check in cpu_get_info()
On 23 June 2015 at 15:38, Simon Glass s...@chromium.org wrote:
This is checking the wrong method. Fix it.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3: None
Changes in v2: None
drivers/cpu/cpu-uclass.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpu/cpu-uclass.c b/drivers/cpu/cpu-uclass.c
index ab18ee2..ffe250d 100644
--- a/drivers/cpu/cpu-uclass.c
+++ b/drivers/cpu/cpu-uclass.c
@@ -25,7 +25,7 @@ int cpu_get_info(struct udevice *dev, struct cpu_info *info)
{
struct cpu_ops *ops = cpu_get_ops(dev);
- if (!ops-get_desc)
+ if (!ops-get_info)
return -ENOSYS;
return ops-get_info(dev, info);
--
2.4.3.573.g4eafbef
Applied to u-boot-x86.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: imximage: add new CHECK/CLR BIT command
Hi Peng,
On 30/06/2015 10:02, Peng Fan wrote:
The reason to add different commands but not one CHECK_DATA_COMMAND is that
compatible with current implementation.
Current DCD supports DATA 4 addr value. If want to use one
CHECK_DATA_COMMAND
to cover CHECK_BITS_SET/CLR, we need another entry, then commands like this:
CHECK_DATA 4 addr mask [SET or CLR], which will make code more complex. So,
I choose to make CHECK_BITS_SET/CLR different commands, but not one CHECK_DATA
command.
Since 4 is not used for V2, how about CHECK_DATA SET addr mask and
CHECK_DATA CLR addr mask?
dcd_v2_t is redefined, because there may not be only one write data command,
there may be many different commands like CHECK_BITS_SET, CHECK_BITS_CLR and
CLR_BIT.
I disagree or maybe this is related to i.MX7, where I could not check
the documentation. Please explain here: I see only one command
(CHECK_DATA_COMMAND, Chapter 8.7.2.2 in i.MX6Q).
i.MX7 needs CHECK_DATA_COMMAND to wait some bits set, because CHECK_BITS_SET
is implemented, so I call it a command:)
Yeah, there is only one CHECK_DATA_COMMAND. I'll refine this piece commit msg.
dcd_len is still leaved there, since changing it needs changes for dcd v1.
For v2, we check whether dcd size is larger than MAX_DCD_SIZE_V2, but not
dcd_len.
It is just a bit confusing, and these are details in implementation -
they are not related to the commit where you explain the new feature.
Move these comments inside the code where they belong to.
Ok. Will do.
Signed-off-by: Peng Fan peng@freescale.com
---
tools/imximage.c | 129
++-
tools/imximage.h | 24 +--
2 files changed, 119 insertions(+), 34 deletions(-)
diff --git a/tools/imximage.c b/tools/imximage.c
index 6f469ae..1c0225d 100644
--- a/tools/imximage.c
+++ b/tools/imximage.c
@@ -22,6 +22,9 @@ static table_entry_t imximage_cmds[] = {
{CMD_BOOT_FROM, BOOT_FROM,boot command, },
{CMD_BOOT_OFFSET, BOOT_OFFSET, Boot offset,},
{CMD_DATA, DATA, Reg Write Data, },
+ {CMD_CLR_BIT, CLR_BIT, Reg clear bit, },
+ {CMD_CHECK_BITS_SET,CHECK_BITS_SET, Reg Check bits set, },
+ {CMD_CHECK_BITS_CLR,CHECK_BITS_CLR, Reg Check bits clr, },
The table reflects Freescale's documentation. This has the big advantage
because there is no need to explain which command is supposed to do
because this is really well done by Freescale in the manuals. Here we
should have only an additional entry due to CHECK_DATA_COMMAND, exactly
what the SOC is able to do.
Back to the question, why I implemented CHECK_BITS_SET/CLR, but not
CHECK_DATA_COMMAND. I do not want to introduce more entry in one DCD entry
such as CHECK_DATA 4 addr mask [CLR/SET], so I use two software commands
to cover CHECK_DATA_COMMAND.
Yes, I understand, but if we check the current implementation you'll
agree that it follows the schema to have an entry in the command table
for each ROM command.
Ok. more work need to be done to use this way, seems need to refactor
the current patch.
The main point about your comments is my way implementation should
follow Reference mannual, but not different commands implemented in imximage.c
for only one command in reference mannual.
Yes, this is my biggest concern in your implementation. This makes IMHO
also more confusing the code later when it must be detected if it was a
CMD_DATA or CMD_CLR_BIT or...
This is automatically solved by switching to function pointers.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] dm: serial: Do not panic if no serial ports are found
+Masahiro
Hi Hans,
On 8 July 2015 at 05:56, Hans de Goede hdego...@redhat.com wrote:
Hi Simon,
On 07-07-15 09:00, Hans de Goede wrote:
Hi,
On 06-07-15 18:39, Simon Glass wrote:
Hi Hans,
On 5 July 2015 at 12:56, Hans de Goede hdego...@redhat.com wrote:
Some boards simply do not have any serial ports. Also no one will see
the
panic message as there is no where to print it if no serial port is
found
(and other stdout options are not yet set up at this point).
It is visible (or will be when some patches land) if you have a debug
UART set up.
Ok.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/serial/serial-uclass.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/serial/serial-uclass.c
b/drivers/serial/serial-uclass.c
index 815fec3..f036499 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -27,7 +27,7 @@ static const unsigned long baudrate_table[] =
CONFIG_SYS_BAUDRATE_TABLE;
#error Serial is required before relocation - define
CONFIG_SYS_MALLOC_F_LEN to make this work
#endif
-static void serial_find_console_or_panic(void)
+static void serial_find_console(void)
{
struct udevice *dev;
int node;
@@ -77,14 +77,12 @@ static void serial_find_console_or_panic(void)
}
#undef INDEX
}
-
- panic_str(No serial driver found);
}
/* Called prior to relocation */
int serial_init(void)
{
- serial_find_console_or_panic();
+ serial_find_console();
gd-flags |= GD_FLG_SERIAL_READY;
return 0;
@@ -93,7 +91,7 @@ int serial_init(void)
/* Called after relocation */
void serial_initialize(void)
{
- serial_find_console_or_panic();
+ serial_find_console();
}
static void _serial_putc(struct udevice *dev, char ch)
How is this handled before driver model?
It was not, the boards involved all use the A13 SoC which is the
same die as the A10s but then in a different (cheaper) package
with way less pins. As such uart0 is not routed to the outside
on the A13. When not setting CONFIG_DM_SERIAL we are simply using
uart0 as serial console, and that ends at the bonding pads at the
edge of the die. doing things that way is not really useful,
but there is a serial console and u-boot is happy.
In the non devicetree world this sort of was a natural hack, we
simply left CONSOLE_INDEX undefined for these boards, which causes
it to default to 1 / uart0 and things just work. I had never given
this much thought until moving to devicetree.
As you can hopefully understand I do not want to do the samething
with DM_SERIAL builds as that would require hacking up the dts
to add a node for hardware which is effectively disabled for the
A13 package of the sun5i die.
It is possible to mark a
device disabled in device tree - perhaps we should have a way to see
that the console is present (i.e. there is an alias) but it is
disabled?
That seems rather ugly, I really do not want to add an alias to
a non enabled device, that just feels wrong on all levels.
Normally a serial console is required, so I'd like to preserve this
behaviour for most boards.
Ok, I actually expected as much, this was actually my second solution
for the problem at hand, but as it was the simplest solution I decided
to submit this version first. My first / original solution is to add a
CONFIG_DM_SERIAL_NO_PANIC Kconfig option which can then be set on boards
which have no serial port.
Or probably better a CONFIG_DM_SERIAL_NO_SERIAL_CONSOLE option ?
This option would disable the panic / disable probing all together while
we would keep using DM_SERIAL on these boards, because:
1) Consistency I really want to use DM_FOO everywhere for sunxi
2) The non dm serial code cannot handle not having a serial port either,
and fixing it looks like it is going to be a bit harder (from a quick
glance).
You probably just have not gotten around to this yet, but in case it is
not clear, the above solution (adding a CONFIG_DM_SERIAL_NO_SERIAL_CONSOLE
Kconfig option) is a suggestion on how to fix. I'll happily implement this
if people like it, but atm I'm waiting for feedback on the suggestion.
I've been thinking about it. Perhaps an option to allow U-Boot to run
without a console is best. But instead of CONFIG_DM_SERIAL_NO_PANIC,
perhaps we could have CONFIG_REQUIRE_CONSOLE which is normally y. I
don't think this has anything to do with driver model and we should
try to use CONFIG_DM... only when the old and new code paths coexist.
I added Masahiro also in case he has ideas.
Regards,
Hans
p.s.
I'm on vacation from July 11th - July 19th, so if I'm quiet that is why :)
Have fun!
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] usb: s3c-otg: support 8-bit interface
Hi Steve, On 15-07-07 06:27 AM, Lukasz Majewski wrote: Hi Steve, Signed-off-by: Steve Rae s...@broadcom.com --- Changes in v2: None drivers/usb/gadget/s3c_udc_otg.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/usb/gadget/s3c_udc_otg.c b/drivers/usb/gadget/s3c_udc_otg.c index 7a2d1e7..2e3b4f7 100644 --- a/drivers/usb/gadget/s3c_udc_otg.c +++ b/drivers/usb/gadget/s3c_udc_otg.c @@ -414,7 +414,11 @@ static void reconfig_usbd(struct s3c_udc *dev) |07 /* Ulpi DDR sel*/ |06 /* 0: high speed utmi+, 1: full speed serial*/ |04 /* 0: utmi+, 1:ulpi*/ +#ifdef CONFIG_USB_GADGET_PHY_8_BIT + |03 /* phy i/f 0:8bit, 1:16bit*/ +#else |13 /* phy i/f 0:8bit, 1:16bit*/ +#endif Is your board using also host phy? As fair as I remember, the upper 8 bits are for host interface. Hi Lukasz, Are you suggesting that we define this as a 16-bit interface, and then only use the upper 8-bits (to achieve the 8-bit interface)? Please clarify, Thanks Steve As fair as I remember we use lower 8 bits for device PHY and upper for host. Your board (with this Synopsys IP) should work with 16 bits as well. |0x70;/* HS/FS Timeout**/ if (dev-pdata-usb_gusbcfg) Despite my above question: Acked-by: Lukasz Majewski l.majew...@samsung.com -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] usb: gadget: bcm_udc_otg files
On Wednesday, July 08, 2015 at 04:22:14 PM, Lukasz Majewski wrote: Hi Steve, Hi! b/drivers/usb/gadget/bcm_udc_otg.h new file mode 100644 index 000..81a1fc0 --- /dev/null +++ b/drivers/usb/gadget/bcm_udc_otg.h @@ -0,0 +1,17 @@ +/* + * Copyright 2015 Broadcom Corporation. -- Please also add the name of the code author. this is not standard practice at Broadcom and it seems that at least five (5) people have contributed to the code in this commit What would you suggest? The most recent author, or ??? I will not push you to add names if it is not mandatory in your company. I just wanted to stress here that putting ones name is some kind of reward when working with community. And it's also much easier to point fingers if something goes wrong :-) (and contact the author, but that's in git log too, so whatever) [...] Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-sunxi master (bugfix for v2015.07)
Hi Tom,
One of the sunxi dts files for a new board got merged into the
upstream kernel under a different name than that it was originally
submitted with. This pull-req contains a single patch adjusting
the name in u-boot, so that we do not end up shipping a u-boot
which looks for a differently named .dtb file then the kernel
ships with.
The following changes since commit 0a888f584c48984cb9657a5d42dc994b33c264a7:
ARM: DRA72x: fix io delay calibration for ethernet (2015-07-07 20:15:52 -0400)
are available in the git repository at:
http://git.denx.de/u-boot-sunxi.git master
for you to fetch changes up to 8fa2e20913183133998cbbb78a5184bd20ccfcbe:
sunxi: Adjust Ippo_q8h_v1_2_a33_1024x600 dts filename to match the upstream
kernel (2015-07-08 16:21:27 +0200)
Hans de Goede (1):
sunxi: Adjust Ippo_q8h_v1_2_a33_1024x600 dts filename to match the
upstream kernel
arch/arm/dts/Makefile | 2 +-
...8i-a33-ippo-q8h-v1.2-lcd1024x600.dts = sun8i-a33-ippo-q8h-v1.2.dts} | 0
configs/Ippo_q8h_v1_2_a33_1024x600_defconfig| 2 +-
3 files changed, 2 insertions(+), 2 deletions(-)
rename arch/arm/dts/{sun8i-a33-ippo-q8h-v1.2-lcd1024x600.dts =
sun8i-a33-ippo-q8h-v1.2.dts} (100%)
Regards,
Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: usb-phy: Never power off the usb ports
On Wednesday, July 08, 2015 at 04:54:07 PM, Hans de Goede wrote: USB devices are not really designed to get the power bounced off and on at them. Esp. USB powered harddisks do not like this. Currently we power off the USB ports both on a usb reset and when booting the kernel, causing the usb-power to bounce off and then back on again. This patch removes the powering off calls, fixing the undesirable power bouncing. Signed-off-by: Hans de Goede hdego...@redhat.com Shall I pick this through u-boot-usb or would you like this to go through u-boot-sunxi ? Recently, I feel a bit left out :-) (but I'm not opposed if you pick this through sunxi, don't get me wrong). 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 v3 00/25] dm: Introduce Rockchip RK3288 support
+ML Hi Ulrich, On 7 July 2015 at 08:32, Ulrich Prinz ulrich.pr...@googlemail.com wrote: Am 24.06.2015 um 01:28 schrieb Simon Glass: The Rockchip RK3288 is based on a quad-core Cortex-A17 CPU and has a good set of peripherals. Various full-featured U-Boot ports are available and this is an attempt to bring those features into mainline. With this series the Firefly RK3288 can boot to a prompt from an SD card. Simon, I want to jump 'on your train' and follow you through these Rockchip devices. I have quite some of them and would like to test and complete mainline u-boot code as well as I now and then support other guys in Android and mainline kernel. Great, nice to hear from you! There's lots to do. Is there a reachable git repo that I can clone from you, or can you give me a rough starting point (patches and underlying u-boot revision) from where I have to add these zillions of patches you submitted? Trying to add your patches on to the HEAD revision leads me just deeper and deeper into more patches :) Sorry I didn't include that in the cover letter. It's u-boot-dm in branch rockchip-working - http://git.denx.de/u-boot-dm.git/ Kind regards Ulrich Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] dm: serial: Do not panic if no serial ports are found
Hi,
On 08-07-15 16:08, Simon Glass wrote:
+Masahiro
Hi Hans,
On 8 July 2015 at 05:56, Hans de Goede hdego...@redhat.com wrote:
Hi Simon,
On 07-07-15 09:00, Hans de Goede wrote:
Hi,
On 06-07-15 18:39, Simon Glass wrote:
Hi Hans,
On 5 July 2015 at 12:56, Hans de Goede hdego...@redhat.com wrote:
Some boards simply do not have any serial ports. Also no one will see
the
panic message as there is no where to print it if no serial port is
found
(and other stdout options are not yet set up at this point).
It is visible (or will be when some patches land) if you have a debug
UART set up.
Ok.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/serial/serial-uclass.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/serial/serial-uclass.c
b/drivers/serial/serial-uclass.c
index 815fec3..f036499 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -27,7 +27,7 @@ static const unsigned long baudrate_table[] =
CONFIG_SYS_BAUDRATE_TABLE;
#error Serial is required before relocation - define
CONFIG_SYS_MALLOC_F_LEN to make this work
#endif
-static void serial_find_console_or_panic(void)
+static void serial_find_console(void)
{
struct udevice *dev;
int node;
@@ -77,14 +77,12 @@ static void serial_find_console_or_panic(void)
}
#undef INDEX
}
-
- panic_str(No serial driver found);
}
/* Called prior to relocation */
int serial_init(void)
{
- serial_find_console_or_panic();
+ serial_find_console();
gd-flags |= GD_FLG_SERIAL_READY;
return 0;
@@ -93,7 +91,7 @@ int serial_init(void)
/* Called after relocation */
void serial_initialize(void)
{
- serial_find_console_or_panic();
+ serial_find_console();
}
static void _serial_putc(struct udevice *dev, char ch)
How is this handled before driver model?
It was not, the boards involved all use the A13 SoC which is the
same die as the A10s but then in a different (cheaper) package
with way less pins. As such uart0 is not routed to the outside
on the A13. When not setting CONFIG_DM_SERIAL we are simply using
uart0 as serial console, and that ends at the bonding pads at the
edge of the die. doing things that way is not really useful,
but there is a serial console and u-boot is happy.
In the non devicetree world this sort of was a natural hack, we
simply left CONSOLE_INDEX undefined for these boards, which causes
it to default to 1 / uart0 and things just work. I had never given
this much thought until moving to devicetree.
As you can hopefully understand I do not want to do the samething
with DM_SERIAL builds as that would require hacking up the dts
to add a node for hardware which is effectively disabled for the
A13 package of the sun5i die.
It is possible to mark a
device disabled in device tree - perhaps we should have a way to see
that the console is present (i.e. there is an alias) but it is
disabled?
That seems rather ugly, I really do not want to add an alias to
a non enabled device, that just feels wrong on all levels.
Normally a serial console is required, so I'd like to preserve this
behaviour for most boards.
Ok, I actually expected as much, this was actually my second solution
for the problem at hand, but as it was the simplest solution I decided
to submit this version first. My first / original solution is to add a
CONFIG_DM_SERIAL_NO_PANIC Kconfig option which can then be set on boards
which have no serial port.
Or probably better a CONFIG_DM_SERIAL_NO_SERIAL_CONSOLE option ?
This option would disable the panic / disable probing all together while
we would keep using DM_SERIAL on these boards, because:
1) Consistency I really want to use DM_FOO everywhere for sunxi
2) The non dm serial code cannot handle not having a serial port either,
and fixing it looks like it is going to be a bit harder (from a quick
glance).
You probably just have not gotten around to this yet, but in case it is
not clear, the above solution (adding a CONFIG_DM_SERIAL_NO_SERIAL_CONSOLE
Kconfig option) is a suggestion on how to fix. I'll happily implement this
if people like it, but atm I'm waiting for feedback on the suggestion.
I've been thinking about it. Perhaps an option to allow U-Boot to run
without a console is best. But instead of CONFIG_DM_SERIAL_NO_PANIC,
perhaps we could have CONFIG_REQUIRE_CONSOLE which is normally y.
That works for me, although I would prefer CONFIG_REQUIRE_SERIAL_CONSOLE,
the boards in question do have a console in the form of a cfb console.
Regards,
Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: usb-phy: Never power off the usb ports
On Wed, 2015-07-08 at 16:54 +0200, Hans de Goede wrote: USB devices are not really designed to get the power bounced off and on at them. Esp. USB powered harddisks do not like this. Currently we power off the USB ports both on a usb reset and when booting the kernel, causing the usb-power to bounce off and then back on again. This patch removes the powering off calls, fixing the undesirable power bouncing. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sunxi: usb-phy: Never power off the usb ports
USB devices are not really designed to get the power bounced off and on
at them. Esp. USB powered harddisks do not like this.
Currently we power off the USB ports both on a usb reset and when
booting the kernel, causing the usb-power to bounce off and then back
on again.
This patch removes the powering off calls, fixing the undesirable power
bouncing.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/cpu/armv7/sunxi/usb_phy.c| 17 -
arch/arm/include/asm/arch-sunxi/usb_phy.h | 1 -
drivers/usb/host/ehci-sunxi.c | 1 -
drivers/usb/host/ohci-sunxi.c | 1 -
drivers/usb/musb-new/sunxi.c | 3 ---
5 files changed, 23 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/usb_phy.c
b/arch/arm/cpu/armv7/sunxi/usb_phy.c
index 4d63a74..74d251d 100644
--- a/arch/arm/cpu/armv7/sunxi/usb_phy.c
+++ b/arch/arm/cpu/armv7/sunxi/usb_phy.c
@@ -47,7 +47,6 @@ static struct sunxi_usb_phy {
int gpio_id_det;
int id;
int init_count;
- int power_on_count;
} sunxi_usb_phy[] = {
{
.usb_rst_mask = CCM_USB_CTRL_PHY0_RST | CCM_USB_CTRL_PHY0_CLK,
@@ -212,26 +211,10 @@ void sunxi_usb_phy_power_on(int index)
{
struct sunxi_usb_phy *phy = sunxi_usb_phy[index];
- phy-power_on_count++;
- if (phy-power_on_count != 1)
- return;
-
if (phy-gpio_vbus = 0)
gpio_set_value(phy-gpio_vbus, 1);
}
-void sunxi_usb_phy_power_off(int index)
-{
- struct sunxi_usb_phy *phy = sunxi_usb_phy[index];
-
- phy-power_on_count--;
- if (phy-power_on_count != 0)
- return;
-
- if (phy-gpio_vbus = 0)
- gpio_set_value(phy-gpio_vbus, 0);
-}
-
int sunxi_usb_phy_vbus_detect(int index)
{
struct sunxi_usb_phy *phy = sunxi_usb_phy[index];
diff --git a/arch/arm/include/asm/arch-sunxi/usb_phy.h
b/arch/arm/include/asm/arch-sunxi/usb_phy.h
index 17d31b8..89a287c 100644
--- a/arch/arm/include/asm/arch-sunxi/usb_phy.h
+++ b/arch/arm/include/asm/arch-sunxi/usb_phy.h
@@ -15,7 +15,6 @@ int sunxi_usb_phy_remove(void);
void sunxi_usb_phy_init(int index);
void sunxi_usb_phy_exit(int index);
void sunxi_usb_phy_power_on(int index);
-void sunxi_usb_phy_power_off(int index);
int sunxi_usb_phy_vbus_detect(int index);
int sunxi_usb_phy_id_detect(int index);
void sunxi_usb_phy_enable_squelch_detect(int index, int enable);
diff --git a/drivers/usb/host/ehci-sunxi.c b/drivers/usb/host/ehci-sunxi.c
index 34130f8..38d5f92 100644
--- a/drivers/usb/host/ehci-sunxi.c
+++ b/drivers/usb/host/ehci-sunxi.c
@@ -67,7 +67,6 @@ static int ehci_usb_remove(struct udevice *dev)
if (ret)
return ret;
- sunxi_usb_phy_power_off(priv-phy_index);
sunxi_usb_phy_exit(priv-phy_index);
#ifdef CONFIG_SUNXI_GEN_SUN6I
diff --git a/drivers/usb/host/ohci-sunxi.c b/drivers/usb/host/ohci-sunxi.c
index e33a8f7..6079272 100644
--- a/drivers/usb/host/ohci-sunxi.c
+++ b/drivers/usb/host/ohci-sunxi.c
@@ -69,7 +69,6 @@ static int ohci_usb_remove(struct udevice *dev)
if (ret)
return ret;
- sunxi_usb_phy_power_off(priv-phy_index);
sunxi_usb_phy_exit(priv-phy_index);
#ifdef CONFIG_SUNXI_GEN_SUN6I
diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
index 3a29b18..702c592 100644
--- a/drivers/usb/musb-new/sunxi.c
+++ b/drivers/usb/musb-new/sunxi.c
@@ -233,9 +233,6 @@ static void sunxi_musb_disable(struct musb *musb)
if (!enabled)
return;
- if (is_host_enabled(musb))
- sunxi_usb_phy_power_off(0); /* port power off */
-
USBC_ForceVbusValidToLow(musb-mregs);
mdelay(200); /* Wait for the current session to timeout */
--
2.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] usb: gadget: bcm_udc_otg files
Hi Steve,
Hi, Lukasz
On 15-07-07 06:33 AM, Lukasz Majewski wrote:
Hi Steve,
From: JD (Jiandong) Zheng jdzh...@broadcom.com
Add the required files for the Broadcom UDC OTG interface.
Signed-off-by: Steve Rae s...@broadcom.com
---
Changes in v2: None
arch/arm/include/asm/arch-bcm281xx/sysmap.h | 7
drivers/usb/gadget/bcm_udc_otg.h| 17 ++
drivers/usb/gadget/bcm_udc_otg_phy.c| 50
+ 3 files changed, 74 insertions(+)
create mode 100644 drivers/usb/gadget/bcm_udc_otg.h
create mode 100644 drivers/usb/gadget/bcm_udc_otg_phy.c
diff --git a/arch/arm/include/asm/arch-bcm281xx/sysmap.h
b/arch/arm/include/asm/arch-bcm281xx/sysmap.h index
93ebf34..dbcc88c 100644 ---
a/arch/arm/include/asm/arch-bcm281xx/sysmap.h +++
b/arch/arm/include/asm/arch-bcm281xx/sysmap.h @@ -27,4 +27,11 @@
#define SECWD2_BASE_ADDR 0x35002f40
#define TIMER_BASE_ADDR 0x3e00d000
+#define HSOTG_DCTL_OFFSET
0x0804 +#define
HSOTG_DCTL_SFTDISCON_MASK
0x0002 + +#define HSOTG_CTRL_PHY_P1CTL_OFFSET
0x0008 +#define
HSOTG_CTRL_PHY_P1CTL_SOFT_RESET_MASK
0x0002 +#define
HSOTG_CTRL_PHY_P1CTL_NON_DRIVING_MASK 0x0001 +
#endif diff --git a/drivers/usb/gadget/bcm_udc_otg.h
b/drivers/usb/gadget/bcm_udc_otg.h new file mode 100644
index 000..81a1fc0
--- /dev/null
+++ b/drivers/usb/gadget/bcm_udc_otg.h
@@ -0,0 +1,17 @@
+/*
+ * Copyright 2015 Broadcom Corporation.
-- Please also add the name of the code author.
this is not standard practice at Broadcom
and it seems that at least five (5) people have contributed to the
code in this commit
What would you suggest? The most recent author, or ???
I will not push you to add names if it is not mandatory in your company.
I just wanted to stress here that putting ones name is some kind of
reward when working with community.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef __BCM_UDC_OTG_H
+#define __BCM_UDC_OTG_H
+
+#include linux/types.h
+
+#define wfld_set(addr, fld_val, fld_mask) \
+ (writel(((readl(addr) ~(fld_mask)) | (fld_val)),
(addr))) +#define wfld_clear(addr, fld_mask) \
+ (writel((readl(addr) ~(fld_mask)), (addr)))
Maybe we could replace those preprocessor macros with static inline
functions?
Hmmm - since writel() and readl() are also macros, it makes it
difficult to make these into functions
I think that it would be doable to embed writel() and readl() in a
static inline function.
I guess we could use uintprt_t and uint32_t
Would you agree?
We can give it a try.
+
+#endif
diff --git a/drivers/usb/gadget/bcm_udc_otg_phy.c
b/drivers/usb/gadget/bcm_udc_otg_phy.c new file mode 100644
index 000..1aa9f91
--- /dev/null
+++ b/drivers/usb/gadget/bcm_udc_otg_phy.c
@@ -0,0 +1,50 @@
+/*
+ * Copyright 2015 Broadcom Corporation.
--- The same as above.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include config.h
+#include common.h
+#include asm/io.h
+#include asm/arch/sysmap.h
+
+#include usb/s3c_udc.h
+#include bcm_udc_otg.h
+
+void otg_phy_init(struct s3c_udc *dev)
+{
+ /* set Phy to driving mode */
+ wfld_clear(HSOTG_CTRL_BASE_ADDR +
HSOTG_CTRL_PHY_P1CTL_OFFSET,
+ HSOTG_CTRL_PHY_P1CTL_NON_DRIVING_MASK);
+
+ udelay(100);
+
+ /* clear Soft Disconnect */
+ wfld_clear(HSOTG_BASE_ADDR + HSOTG_DCTL_OFFSET,
+ HSOTG_DCTL_SFTDISCON_MASK);
+
+ /* invoke Reset (active low) */
+ wfld_clear(HSOTG_CTRL_BASE_ADDR +
HSOTG_CTRL_PHY_P1CTL_OFFSET,
+ HSOTG_CTRL_PHY_P1CTL_SOFT_RESET_MASK);
+
+ udelay(1);
^^ -- would it be possible to add some comment
regarding for what we are waiting here?
OK
+
+ /* release Reset */
+ wfld_set(HSOTG_CTRL_BASE_ADDR +
HSOTG_CTRL_PHY_P1CTL_OFFSET,
+ HSOTG_CTRL_PHY_P1CTL_SOFT_RESET_MASK,
+ HSOTG_CTRL_PHY_P1CTL_SOFT_RESET_MASK);
+}
+
+void otg_phy_off(struct s3c_udc *dev)
+{
+ /* Soft Disconnect */
+ wfld_set(HSOTG_BASE_ADDR + HSOTG_DCTL_OFFSET,
+ HSOTG_DCTL_SFTDISCON_MASK,
+ HSOTG_DCTL_SFTDISCON_MASK);
+
+ /* set Phy to non-driving (reset) mode */
+ wfld_set(HSOTG_CTRL_BASE_ADDR +
HSOTG_CTRL_PHY_P1CTL_OFFSET,
+ HSOTG_CTRL_PHY_P1CTL_NON_DRIVING_MASK,
+ HSOTG_CTRL_PHY_P1CTL_NON_DRIVING_MASK);
+}
Thanks, Steve
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] keystone2: add wfi in to the core_spin loop
When core A turning of core B, via tetris DPSC it places the core
B DPSC into transitional state. The core B has to execute wfi instruction
to move its DPSC to the OFF state. This patch add such instruction.
Signed-off-by: Vitaly Andrianov vita...@ti.com
---
arch/arm/mach-keystone/cmd_mon.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-keystone/cmd_mon.c b/arch/arm/mach-keystone/cmd_mon.c
index f9f58a3..73ceb83 100644
--- a/arch/arm/mach-keystone/cmd_mon.c
+++ b/arch/arm/mach-keystone/cmd_mon.c
@@ -55,8 +55,13 @@ U_BOOT_CMD(mon_install, 2, 0, do_mon_install,
static void core_spin(void)
{
- while (1)
- ; /* forever */;
+ while (1) {
+ asm volatile (
+ dsb\n
+ isb\n
+ wfi\n
+ );
+ }
}
int mon_power_on(int core_id, void *ep)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/6] mmc: hi6220_dw_mmc: Add hi6220 glue code for dw_mmc controller.
This patch adds the glue code for hi6220 SoC which has 2x synopsis
dw_mmc controllers. This will be used by the hikey board support
in subsequent patches.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
arch/arm/include/asm/arch-hi6220/dwmmc.h | 8 +
drivers/mmc/Makefile | 1 +
drivers/mmc/hi6220_dw_mmc.c | 56
3 files changed, 65 insertions(+)
create mode 100644 arch/arm/include/asm/arch-hi6220/dwmmc.h
create mode 100644 drivers/mmc/hi6220_dw_mmc.c
diff --git a/arch/arm/include/asm/arch-hi6220/dwmmc.h
b/arch/arm/include/asm/arch-hi6220/dwmmc.h
new file mode 100644
index 000..c747383
--- /dev/null
+++ b/arch/arm/include/asm/arch-hi6220/dwmmc.h
@@ -0,0 +1,8 @@
+/*
+ * (C) Copyright 2015 Linaro
+ * Peter Griffin peter.grif...@linaro.org
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+int hi6220_dwmci_add_port(int index, u32 regbase, int bus_width);
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index ed73687..81a1a8f 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_BFIN_SDH) += bfin_sdh.o
obj-$(CONFIG_DAVINCI_MMC) += davinci_mmc.o
obj-$(CONFIG_DWMMC) += dw_mmc.o
obj-$(CONFIG_EXYNOS_DWMMC) += exynos_dw_mmc.o
+obj-$(CONFIG_HIKEY_DWMMC) += hi6220_dw_mmc.o
obj-$(CONFIG_FSL_ESDHC) += fsl_esdhc.o
obj-$(CONFIG_FTSDC010) += ftsdc010_mci.o
obj-$(CONFIG_FTSDC021) += ftsdc021_sdhci.o
diff --git a/drivers/mmc/hi6220_dw_mmc.c b/drivers/mmc/hi6220_dw_mmc.c
new file mode 100644
index 000..106f673
--- /dev/null
+++ b/drivers/mmc/hi6220_dw_mmc.c
@@ -0,0 +1,56 @@
+/*
+ * (C) Copyright 2015 Linaro
+ * peter.griffin peter.grif...@linaro.org
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include dwmmc.h
+#include malloc.h
+#include asm-generic/errno.h
+
+#defineDWMMC_MAX_CH_NUM4
+
+#defineDWMMC_MAX_FREQ 5000
+#defineDWMMC_MIN_FREQ 378000
+
+/* Source clock is configured to 100Mhz by ATF bl1*/
+#define MMC0_DEFAULT_FREQ 1
+
+static int hi6220_dwmci_core_init(struct dwmci_host *host, int index)
+{
+ host-name = HiKey DWMMC;
+
+ host-dev_index = index;
+
+ /* Add the mmc channel to be registered with mmc core */
+ if (add_dwmci(host, DWMMC_MAX_FREQ, DWMMC_MIN_FREQ)) {
+ printf(DWMMC%d registration failed\n, index);
+ return -1;
+ }
+ return 0;
+}
+
+/*
+ * This function adds the mmc channel to be registered with mmc core.
+ * index - mmc channel number.
+ * regbase - register base address of mmc channel specified in 'index'.
+ * bus_width - operating bus width of mmc channel specified in 'index'.
+ */
+int hi6220_dwmci_add_port(int index, u32 regbase, int bus_width)
+{
+ struct dwmci_host *host = NULL;
+
+ host = calloc(1, sizeof(struct dwmci_host));
+ if (!host) {
+ error(dwmci_host malloc fail!\n);
+ return -ENOMEM;
+ }
+
+ host-ioaddr = (void *)regbase;
+ host-buswidth = bus_width;
+ host-bus_hz = MMC0_DEFAULT_FREQ;
+
+ return hi6220_dwmci_core_init(host, index);
+}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 6/6] ARM64: hikey: Add a README for this board.
To help others with compiling and flashing ATF and u-boot add a README for this board. Signed-off-by: Peter Griffin peter.grif...@linaro.org --- board/hisilicon/hikey/README | 160 +++ 1 file changed, 160 insertions(+) create mode 100644 board/hisilicon/hikey/README diff --git a/board/hisilicon/hikey/README b/board/hisilicon/hikey/README new file mode 100644 index 000..25c8143 --- /dev/null +++ b/board/hisilicon/hikey/README @@ -0,0 +1,160 @@ +Introduction + + +HiKey is the first certified 96Boards Consumer Edition board. The board/SoC has: - +* HiSilicon Kirin 6220 eight-core ARM Cortex-A53 64-bit SoC running at 1.2GHz. +* ARM Mali 450-MP4 GPU +* 1GB 800MHz LPDDR3 DRAM +* 4GB eMMC Flash Storage +* microSD +* 802.11a/b/g/n WiFi, Bluetooth + +The HiKey schematic can be found here: - +https://github.com/96boards/documentation/blob/master/hikey/96Boards-Hikey-Rev-A1.pdf + +A SoC datasheet can be found here: - +https://github.com/96boards/documentation/blob/master/hikey/ +Hi6220V100_Multi-Mode_Application_Processor_Function_Description.pdf + +Currently the u-boot port supports: - +* USB +* eMMC +* SD card +* GPIO + +Compile u-boot +== + +make CROSS_COMPILE=aarch64-linux-gnu- hikey_config +make CROSS_COMPILE=aarch64-linux-gnu- + +ARM Trusted Firmware (ATF) l-loader += + +This u-boot port has been tested with l-loader, booting ATF, which then boots +u-boot as the bl33.bin executable. + +1. Get ATF source code +git clone https://github.com/96boards/arm-trusted-firmware.git + +2. Compile ATF I use the makefile here +http://people.linaro.org/~peter.griffin/hikey/hikey-u-boot-release_r1/build-tf.mak + +3. Get l-loader +git clone https://github.com/96boards/l-loader.git + +4. Make sym links to ATF bip / fip binaries +ln -s /home/griffinp/aarch64/bl1-hikey.bin bl1.bin +ln -s /home/griffinp/aarch64/fip-hikey.bin fip.bin + +arm-linux-gnueabihf-gcc -c -o start.o start.S +arm-linux-gnueabihf-gcc -c -o debug.o debug.S +arm-linux-gnueabihf-ld -Bstatic -Tl-loader.lds -Ttext 0xf9800800 start.o debug.o -o loader +arm-linux-gnueabihf-objcopy -O binary loader temp + +python gen_loader.py -o l-loader.bin --img_loader=temp --img_bl1=bl1.bin +sudo bash -x generate_ptable.sh +python gen_loader.py -o ptable.img --img_prm_ptable=prm_ptable.img --img_sec_ptable=sec_ptable.img + +These instructions are adapted from +https://github.com/96boards/documentation/wiki/HiKeyUEFI + +FLASHING + + +1. Connect jumper J2 to go into recovery mode and flash l-loader.bin with + fastboot using the hisi-idt.py utility + + git clone https://github.com/96boards/burn-boot.git + sudo python /home/griffinp/Software/hikey/burn-boot/hisi-idt.py -d /dev/ttyUSB0 --img1=/tmp/l-loader.bin + +2. Once LED 0 comes on solid, it should be detected as a fastboot device + (on some boards I've found this to be unreliable) + +sudo fastboot devices + +3. Flash the images +wget https://builds.96boards.org/releases/hikey/nvme.img +sudo fastboot flash ptable ptable.img +sudo fastboot flash fastboot fip.bin +sudo fastboot flash nvme nvme.img + +4. Disconnect jumper J2, and reset the board and you will now (hopefully) + have ATF, booting u-boot from eMMC. On 'new' boards I've had to do the + flashing twice in the past to avoid an ATF error. + +See working boot trace below: - + +debug EMMC boot: print init OK +debug EMMC boot: send RST_N . +debug EMMC boot: start eMMC boot.. +load fastboot1! +Switch to aarch64 mode. CPU0 executes at 0xf9801000! +NOTICE: Booting Trusted Firmware +NOTICE: BL1: v1.1(release):a0c0399 +NOTICE: BL1: Built : 13:23:48, May 22 2015 +NOTICE: succeed to init lpddr3 rank0 dram phy +INFO:lpddr3_freq_init, set ddrc 533mhz +INFO:init ddr3 rank0 +INFO:ddr3 rank1 init pass +INFO:lpddr3_freq_init, set ddrc 800mhz +INFO:init ddr3 rank0 +INFO:ddr3 rank1 init pass +INFO:Elpida DDR +NOTICE: BL1: Booting BL2 +INFO:[BDID] [fff91c18] midr: 0x410fd033 +INFO:[BDID] [fff91c1c] board type: 0 +INFO:[BDID] [fff91c20] board id: 0x2b +INFO:init_acpu_dvfs: pmic version 17 +INFO:init_acpu_dvfs: ACPU_CHIP_MAX_FREQ=0x186a00. +INFO:acpu_dvfs_volt_init: success! +INFO:acpu_dvfs_set_freq: support freq num is 5 +INFO:acpu_dvfs_set_freq: start prof is 0x4 +INFO:acpu_dvfs_set_freq: magic is 0x5a5ac5c5 +INFO:acpu_dvfs_set_freq: voltage: +INFO: - 0: 0x3a +INFO: - 1: 0x3a +INFO: - 2: 0x4a +INFO: - 3: 0x5b +INFO: - 4: 0x6b +NOTICE: acpu_dvfs_set_freq: set acpu freq success!NOTICE: BL2: v1.1(debug):a0c0399 +NOTICE: BL2: Built : 10:19:28, May 27 2015 +INFO:BL2: Loading BL3-0 +INFO:Using FIP +WARNING: Failed to access image 'bl30.bin' (-1) +ERROR: Failed to load BL3-0 (-1) +ERROR: Please burn mcu image: +ERROR: sudo fastboot flash mcuimage mcuimage.bin +INFO:BL2: TrustZone: protecting 16777216 bytes of memory at 0x3f00 +INFO:BL2:
[U-Boot] [PATCH] keystone2: use appropriate HD field for destination port
K2L and L2E have different from K2HK EthSS version, which uses tag_info
field for destination slave port. This commit adds the dest_port_info field
to the struct pktdma_cfg, to configure which HD filed tag_info or pkt_info
shall be used to configure descriptor.
Before that commit the swinfo[2] was used for that purpose. Even if that
worked on K2HK devices, the correct field for K2HK is the pkt_info.
The netcp_send() configure appropriate HD info field depending on the
direct_info of the currently using netcp.
Signed-off-by: Vitaly Andrianov vita...@ti.com
Acked-by: Murali Karicheri m-kariche...@ti.com
---
arch/arm/include/asm/ti-common/keystone_nav.h | 9 -
drivers/dma/keystone_nav.c| 12 ++--
drivers/net/keystone_net.c| 3 +--
3 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/ti-common/keystone_nav.h
b/arch/arm/include/asm/ti-common/keystone_nav.h
index 696d8c6..5a0e391 100644
--- a/arch/arm/include/asm/ti-common/keystone_nav.h
+++ b/arch/arm/include/asm/ti-common/keystone_nav.h
@@ -152,6 +152,11 @@ struct rx_flow_regs {
u32 thresh[3];
};
+enum dest_port_info {
+ PKT_INFO,
+ TAG_INFO
+};
+
struct pktdma_cfg {
struct global_ctl_regs *global;
struct tx_chan_regs *tx_ch;
@@ -167,6 +172,7 @@ struct pktdma_cfg {
u32 tx_snd_q;
u32 rx_flow; /* flow that is used for RX */
+ enum dest_port_info dest_port_info;/* HD fiels for dest port bits */
};
extern struct pktdma_cfg netcp_pktdma;
@@ -184,7 +190,8 @@ struct rx_buff_desc {
int ksnav_close(struct pktdma_cfg *pktdma);
int ksnav_init(struct pktdma_cfg *pktdma, struct rx_buff_desc *rx_buffers);
-int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes, u32
swinfo2);
+int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
+ u32 dest_port);
void *ksnav_recv(struct pktdma_cfg *pktdma, u32 **pkt, int *num_bytes);
void ksnav_release_rxhd(struct pktdma_cfg *pktdma, void *hd);
diff --git a/drivers/dma/keystone_nav.c b/drivers/dma/keystone_nav.c
index dfca75a..64b1cee 100644
--- a/drivers/dma/keystone_nav.c
+++ b/drivers/dma/keystone_nav.c
@@ -278,7 +278,8 @@ int ksnav_close(struct pktdma_cfg *pktdma)
return QM_OK;
}
-int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes, u32 swinfo2)
+int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
+ u32 dest_port)
{
struct qm_host_desc *hd;
@@ -286,8 +287,15 @@ int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int
num_bytes, u32 swinfo2)
if (hd == NULL)
return QM_ERR;
+ dest_port = 0xf;
hd-desc_info = num_bytes;
- hd-swinfo[2] = swinfo2;
+ if (pktdma-dest_port_info == PKT_INFO) {
+ hd-packet_info = qm_cfg-qpool_num | (dest_port 16);
+ } else {
+ hd-packet_info = qm_cfg-qpool_num;
+ hd-tag_info = dest_port;
+ }
+
hd-packet_info = qm_cfg-qpool_num;
qm_buff_push(hd, pktdma-tx_snd_q, pkt, num_bytes);
diff --git a/drivers/net/keystone_net.c b/drivers/net/keystone_net.c
index 0c5fdee..e2adb67 100644
--- a/drivers/net/keystone_net.c
+++ b/drivers/net/keystone_net.c
@@ -381,8 +381,7 @@ int32_t cpmac_drv_send(u32 *buffer, int num_bytes, int
slave_port_num)
if (num_bytes EMAC_MIN_ETHERNET_PKT_SIZE)
num_bytes = EMAC_MIN_ETHERNET_PKT_SIZE;
- return ksnav_send(netcp_pktdma, buffer,
- num_bytes, (slave_port_num) 16);
+ return ksnav_send(netcp_pktdma, buffer, num_bytes, slave_port_num);
}
/* Eth device open */
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/6] dm: gpio: hi6220: Add a hi6220 GPIO driver model driver.
This patch adds support for the GPIO perif found on hi6220
SoC.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
arch/arm/include/asm/arch-hi6220/gpio.h | 29 ++
drivers/gpio/Makefile | 2 +
drivers/gpio/hi6220_gpio.c | 95 +
3 files changed, 126 insertions(+)
create mode 100644 arch/arm/include/asm/arch-hi6220/gpio.h
create mode 100644 drivers/gpio/hi6220_gpio.c
diff --git a/arch/arm/include/asm/arch-hi6220/gpio.h
b/arch/arm/include/asm/arch-hi6220/gpio.h
new file mode 100644
index 000..98122a2
--- /dev/null
+++ b/arch/arm/include/asm/arch-hi6220/gpio.h
@@ -0,0 +1,29 @@
+/*
+ * Copyright (C) 2015 Linaro
+ * Peter Griffin peter.grif...@linaro.org
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _HI6220_GPIO_H_
+#define _HI6220_GPIO_H_
+
+#define HI6220_GPIO_BASE(bank) (((bank 4) ? 0xf8011000 : \
+ 0xf702 - 0x4000) + (0x1000 * bank))
+
+#define BIT(x) (1 (x))
+
+#define HI6220_GPIO_PER_BANK 8
+#define HI6220_GPIO_DIR0x400
+
+struct gpio_bank {
+ u8 *base; /* address of registers in physical memory */
+};
+
+/* Information about a GPIO bank */
+struct hikey_gpio_platdata {
+ int bank_index;
+ unsigned int base; /* address of registers in physical memory */
+};
+
+#endif /* _HI6220_GPIO_H_ */
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 5864850..b470bab 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -46,3 +46,5 @@ obj-$(CONFIG_LPC32XX_GPIO)+= lpc32xx_gpio.o
obj-$(CONFIG_STM32_GPIO) += stm32_gpio.o
obj-$(CONFIG_ZYNQ_GPIO)+= zynq_gpio.o
obj-$(CONFIG_VYBRID_GPIO) += vybrid_gpio.o
+obj-$(CONFIG_HIKEY_GPIO) += hi6220_gpio.o
+
diff --git a/drivers/gpio/hi6220_gpio.c b/drivers/gpio/hi6220_gpio.c
new file mode 100644
index 000..3f41bff
--- /dev/null
+++ b/drivers/gpio/hi6220_gpio.c
@@ -0,0 +1,95 @@
+/*
+ * Copyright (C) 2015 Linaro
+ * Peter Griffin peter.grif...@linaro.org
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include dm.h
+#include asm/gpio.h
+#include asm/io.h
+#include errno.h
+
+static int hi6220_gpio_direction_input(struct udevice *dev, unsigned int gpio)
+{
+ struct gpio_bank *bank = dev_get_priv(dev);
+ u8 data;
+
+ data = readb(bank-base + HI6220_GPIO_DIR);
+ data = ~(1 gpio);
+ writeb(data, bank-base + HI6220_GPIO_DIR);
+
+ return 0;
+}
+
+static int hi6220_gpio_set_value(struct udevice *dev, unsigned gpio,
+ int value)
+{
+ struct gpio_bank *bank = dev_get_priv(dev);
+
+ writeb(!!value gpio, bank-base + (BIT(gpio + 2)));
+ return 0;
+}
+
+static int hi6220_gpio_direction_output(struct udevice *dev, unsigned gpio,
+ int value)
+{
+ struct gpio_bank *bank = dev_get_priv(dev);
+ u8 data;
+
+ data = readb(bank-base + HI6220_GPIO_DIR);
+ data |= 1 gpio;
+ writeb(data, bank-base + HI6220_GPIO_DIR);
+
+ hi6220_gpio_set_value(dev, gpio, value);
+
+ return 0;
+}
+
+static int hi6220_gpio_get_value(struct udevice *dev, unsigned gpio)
+{
+ struct gpio_bank *bank = dev_get_priv(dev);
+
+ return !!readb(bank-base + (BIT(gpio + 2)));
+}
+
+
+
+static const struct dm_gpio_ops gpio_hi6220_ops = {
+ .direction_input= hi6220_gpio_direction_input,
+ .direction_output = hi6220_gpio_direction_output,
+ .get_value = hi6220_gpio_get_value,
+ .set_value = hi6220_gpio_set_value,
+};
+
+static int hi6220_gpio_probe(struct udevice *dev)
+{
+ struct gpio_bank *bank = dev_get_priv(dev);
+ struct hikey_gpio_platdata *plat = dev_get_platdata(dev);
+ struct gpio_dev_priv *uc_priv = dev-uclass_priv;
+ char name[18], *str;
+
+ sprintf(name, GPIO%d_, plat-bank_index);
+
+ str = strdup(name);
+ if (!str)
+ return -ENOMEM;
+
+ uc_priv-bank_name = str;
+ uc_priv-gpio_count = HI6220_GPIO_PER_BANK;
+
+ bank-base = (u8 *)plat-base;
+
+ return 0;
+}
+
+U_BOOT_DRIVER(gpio_hi6220) = {
+ .name = gpio_hi6220,
+ .id = UCLASS_GPIO,
+ .ops= gpio_hi6220_ops,
+ .probe = hi6220_gpio_probe,
+ .priv_auto_alloc_size = sizeof(struct gpio_bank),
+};
+
+
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/6] Add support for hi6220 SoC and HiKey 96boards CE board.
Hi Folks, This series adds support for the first 96boards consumer edition HiKey board. More information can be found about this board at the following link https://www.96boards.org/products/hikey/. This initial port adds support for: - 1) Serial 2) eMMC and sd card 3) USB 4) GPIO It has been tested with Arm Trusted Firmware running u-boot as the BL33 executable. Some instructions on exactly how to compile everything (l-loader, with Arm Trusted Firmware, which then loads u-boot) is documented in the README found in the board/hisilicon/hikey directory. A basic SoC datasheet can be found here: - https://github.com/96boards/documentation/blob/master/hikey/ Hi6220V100_Multi-Mode_Application_Processor_Function_Description.pdf Board schematic can be found here: - https://github.com/96boards/documentation/blob/master/hikey/ 96Boards-Hikey-Rev-A1.pdf A rather pleasant side effect of rebasing to v2015.07-rc2 is that the two main bugs with the v1 series (that I new about at least) are resolved. DHCP now works correctly, and USB mass storage devices are also enumerated). I had a quick look at migrating the gpio driver over to DT like Simon suggested. Currently there is a bug in fdtdec_get_addr() for 64bit platforms which I ran into. See patch from Thierry here http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/215346 Also I'm not sure on the protocol here, but the DT nodes for the gpio controller aren't yet present in upstream Linux kernel, so I think it would be better to wait until they are, so that u-boot and kernel DT don't diverge. Migrating over to DT at that point should then be fairly trivial. Changes since v1: - Rename vendor to hisilicon not 96boards (Rob) - Get rid of aemv8a vexpress leftover (Rob) - Remove __weak on misc_init_r (Rob) - Remove unnecessary LINUX_BOOT_PARAM_ADDR (Rob) - COUNTER_FREQUENCY in decimal to avoid comment (Rob) - Remove leftover V2M* from vexpress (Rob) - Migrate configs/hikey.h over to use config_distro_defaults.h (Rob) - Remove custom u-boot prompt (Rob) - Enable icache - Remove custom delay function, as mdelay/udelay work fine (Rob) - Update CONFIG_SYS_LOAD_ADDR to 0x8 (Rob) - Use suggested macro for declaring gpio addresses (Marek) - Zap dead Macros (Marek) - Use calloc instead of malloc (Marek) - Reduce PHYS_RAM by 16Mb to accomodate OPTEE in latest ATF code (Peter) - Rebase on v2015.07-rc2 (Peter) - Add CONFIG_NET=y so that env callbacks work (Peter) - Add a README on how to build / flash u-boot (Simon) kind regards, Peter. Peter Griffin (6): dm: gpio: hi6220: Add a hi6220 GPIO driver model driver. ARM: hi6220: Add register and bitfield definition header files. hi6553: Add register definition and bitfield header for 6553 pmic mmc: hi6220_dw_mmc: Add hi6220 glue code for dw_mmc controller. ARM64: hikey: hi6220: Add u-boot support for the 96boards CE HiKey board. ARM64: hikey: Add a README for this board. arch/arm/Kconfig | 8 + arch/arm/include/asm/arch-hi6220/dwmmc.h | 8 + arch/arm/include/asm/arch-hi6220/gpio.h| 29 ++ arch/arm/include/asm/arch-hi6220/hi6220.h | 324 .../include/asm/arch-hi6220/hi6220_regs_alwayson.h | 349 + arch/arm/include/asm/arch-hi6220/hi6553.h | 75 board/hisilicon/hikey/Kconfig | 15 + board/hisilicon/hikey/Makefile | 8 + board/hisilicon/hikey/README | 160 board/hisilicon/hikey/hikey.c | 415 + configs/hikey_defconfig| 5 + drivers/gpio/Makefile | 2 + drivers/gpio/hi6220_gpio.c | 95 + drivers/mmc/Makefile | 1 + drivers/mmc/hi6220_dw_mmc.c| 56 +++ include/configs/hikey.h| 168 + 16 files changed, 1718 insertions(+) create mode 100644 arch/arm/include/asm/arch-hi6220/dwmmc.h create mode 100644 arch/arm/include/asm/arch-hi6220/gpio.h create mode 100644 arch/arm/include/asm/arch-hi6220/hi6220.h create mode 100644 arch/arm/include/asm/arch-hi6220/hi6220_regs_alwayson.h create mode 100644 arch/arm/include/asm/arch-hi6220/hi6553.h create mode 100644 board/hisilicon/hikey/Kconfig create mode 100644 board/hisilicon/hikey/Makefile create mode 100644 board/hisilicon/hikey/README create mode 100644 board/hisilicon/hikey/hikey.c create mode 100644 configs/hikey_defconfig create mode 100644 drivers/gpio/hi6220_gpio.c create mode 100644 drivers/mmc/hi6220_dw_mmc.c create mode 100644 include/configs/hikey.h -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] keystone2: add high memory test
Keystone2 SOC physical DDR3 address range is outside the first 4GB and
cannot be entirely accessible without MMU enabled. Only first 2GB of
the physical memory have 32-bits aliased addresses. This patch adds u-boot
shell command that allows to enable/disable MMU and map the 1GB of
36bits physical memory to the first 4GB address range.
Signed-off-by: Vitaly Andrianov vita...@ti.com
---
arch/arm/mach-keystone/Makefile | 3 +-
arch/arm/mach-keystone/highmem.c | 162 +++
2 files changed, 164 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-keystone/highmem.c
diff --git a/arch/arm/mach-keystone/Makefile b/arch/arm/mach-keystone/Makefile
index ed030db..56b6457 100644
--- a/arch/arm/mach-keystone/Makefile
+++ b/arch/arm/mach-keystone/Makefile
@@ -1,5 +1,5 @@
#
-# (C) Copyright 2012-2014
+# (C) Copyright 2012-2015
# Texas Instruments Incorporated, www.ti.com
#
# SPDX-License-Identifier: GPL-2.0+
@@ -16,3 +16,4 @@ obj-y += cmd_mon.o
obj-y += msmc.o
obj-y += ddr3.o cmd_ddr3.o
obj-y += keystone.o
+obj-y += highmem.o
diff --git a/arch/arm/mach-keystone/highmem.c b/arch/arm/mach-keystone/highmem.c
new file mode 100644
index 000..d024e04
--- /dev/null
+++ b/arch/arm/mach-keystone/highmem.c
@@ -0,0 +1,162 @@
+/*
+ * Keystone2: High Memory Test
+ *
+ * (C) Copyright 2013-2015
+ * Texas Instruments Incorporated, www.ti.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+/*
+ * Keysone2 systems which have more then 2GB of DDR2A memory
+ * cannot access that memory without MMU enable. In order to test
+ * the entire memory we need to create MMU translation table,
+ * enable MMU and test the memory in portions. After the test
+ * we need to disable MMU.
+ *
+ * We assume that the memory size = 2GB and u-boot code is relocated
+ * to the upper GB of the PA address range and the 0x8000-0xbfff
+ * address range is available to use for testing.
+ *
+ * The code will create simple 1 level page table with 4 entries of
+ * 1GB blocks. The block with VA 0x8000-0xbfff will be used
+ * to map different portions of the DDR3a.
+ *
+ */
+
+#include common.h
+#include asm/armv7.h
+
+static unsigned long long pgd_table[4] __aligned(0x1000);
+static unsigned long sctlr_save;
+static int mmu_enabled;
+
+/* Invalidate TLB */
+void my_v7_inval_tlb(void)
+{
+ /* Invalidate entire unified TLB */
+ asm volatile (mcr p15, 0, %0, c8, c7, 0 : : r (0));
+ /* Invalidate entire data TLB */
+ asm volatile (mcr p15, 0, %0, c8, c6, 0 : : r (0));
+ /* Invalidate entire instruction TLB */
+ asm volatile (mcr p15, 0, %0, c8, c5, 0 : : r (0));
+ /* Full system DSB - make sure that the invalidation is complete */
+ CP15DSB;
+ /* Full system ISB - make sure the instruction stream sees it */
+ CP15ISB;
+}
+
+static unsigned long enable_mmu(unsigned long long *ttbr0)
+{
+ unsigned long ret;
+ asm (
+ stmfd r13!, {r10, r11}\n
+ /* set ttbr0*/
+ movr10, %1\n
+ movr11, #0\n
+ mcrr p15, 0, r10, r11, c2\n
+ /* ttbcr = 0x8000 */
+ movr10, #0\n
+ orrr10, r10, #(1 31)\n
+ mcrp15, 0, r10, c2, c0, 2\n
+ /* save current SCTLR value */
+ mrcp15, #0, r10, c1, c0, #0\n
+ mov%0, r10\n
+ /* disable cache*/
+ bicr10, r10,#(1 12)\n
+ bicr10, r10,#(1 2)\n
+ mcrp15, #0, r10, c1, c0, #0\n
+ isb\n
+ dsb\n
+ bl invalidate_dcache_all\n
+ bl my_v7_inval_tlb\n
+ /* enable mmu */
+ mrcp15, #0, r10, c1, c0, #0\n
+ orrr10, r10,#1\n
+ mcrp15, #0, r10, c1, c0, #0\n
+ ldmfd r13!, {r10, r11}\n
+ : =r (ret) : r (ttbr0) : r10, r11, cc
+ );
+
+ return ret;
+}
+
+static void disable_mmu(unsigned long sctlr_old)
+{
+ asm volatile (
+ movr10, %0\n
+ bicr10, r10,#1\n
+ mcrp15, #0, r10, c1, c0, #0\n
+ : : r (sctlr_old) : r10, cc
+ );
+}
+
+
+static void pgd_table_init(void)
+{
+ /*
+* we create identical mapping for the whole 4GB address range
+* this table maps 0x0-0x VA to aliased PA range
+* 0x0__ - 0x0__;
+*/
+
+ pgd_table[0] = 0x071dULL;
+ pgd_table[1] = 0x471dULL;
+ pgd_table[2] = 0x871dULL;
+ pgd_table[3] = 0xc71dULL;
+}
+
+int do_highmem_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ unsigned long pgd2_pa;
+ unsigned long long pgd_val;
+
[U-Boot] [PATCH] keystone2: net: add mcast function to keyston2 Ethernet driver
The MCAST_TFTP support requires that network drivers has mcast functon
implemented. This commit adds dummy keystone2_eth_bcast_addr() to meet
the requirement. As far as the driver doesn't use ALE and doesn't filter
any incoming packets, the function is empty.
Signed-off-by: Vitaly Andrianov vita...@ti.com
---
drivers/net/keystone_net.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/keystone_net.c b/drivers/net/keystone_net.c
index e2adb67..b3ab13d 100644
--- a/drivers/net/keystone_net.c
+++ b/drivers/net/keystone_net.c
@@ -511,6 +511,13 @@ static int keystone2_eth_rcv_packet(struct eth_device *dev)
return pkt_size;
}
+#ifdef CONFIG_MCAST_TFTP
+static int keystone2_eth_bcast_addr(struct eth_device *dev, u32 ip, u8 set)
+{
+ return 0;
+}
+#endif
+
/*
* This function initializes the EMAC hardware.
*/
@@ -536,6 +543,9 @@ int keystone2_emac_initialize(struct eth_priv_t *eth_priv)
dev-halt = keystone2_eth_close;
dev-send = keystone2_eth_send_packet;
dev-recv = keystone2_eth_rcv_packet;
+#ifdef CONFIG_MCAST_TFTP
+ dev-mcast = keystone2_eth_bcast_addr;
+#endif
eth_register(dev);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/6] hi6553: Add register definition and bitfield header for 6553 pmic
This pmic is used on the 96boards consumer edition HiKey board. Signed-off-by: Peter Griffin peter.grif...@linaro.org --- arch/arm/include/asm/arch-hi6220/hi6553.h | 75 +++ 1 file changed, 75 insertions(+) create mode 100644 arch/arm/include/asm/arch-hi6220/hi6553.h diff --git a/arch/arm/include/asm/arch-hi6220/hi6553.h b/arch/arm/include/asm/arch-hi6220/hi6553.h new file mode 100644 index 000..d0770e1 --- /dev/null +++ b/arch/arm/include/asm/arch-hi6220/hi6553.h @@ -0,0 +1,75 @@ +/* + * (C) Copyright 2015 Linaro + * Peter Griffin peter.grif...@linaro.org + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#ifndef __HI6553_PMIC_H__ +#define __HI6553_PMIC_H__ + +#define HI6553_DISABLE6_XO_CLK 0x036 + +#define HI6553_DISABLE6_XO_CLK_BB (1 0) +#define HI6553_DISABLE6_XO_CLK_CONN(1 1) +#define HI6553_DISABLE6_XO_CLK_NFC (1 2) +#define HI6553_DISABLE6_XO_CLK_RF1 (1 3) +#define HI6553_DISABLE6_XO_CLK_RF2 (1 4) + +#define HI6553_VERSION_REG 0x000 +#define HI6553_ENABLE2_LDO1_8 0x029 +#define HI6553_DISABLE2_LDO1_8 0x02a +#define HI6553_ONOFF_STATUS2_LDO1_80x02b +#define HI6553_ENABLE3_LDO9_16 0x02c +#define HI6553_DISABLE3_LDO9_160x02d +#define HI6553_ONOFF_STATUS3_LDO9_16 0x02e +#define HI6553_PERI_EN_MARK0x040 +#define HI6553_BUCK2_REG1 0x04a +#define HI6553_BUCK2_REG5 0x04e +#define HI6553_BUCK2_REG6 0x04f +#define HI6553_BUCK3_REG3 0x054 +#define HI6553_BUCK3_REG5 0x056 +#define HI6553_BUCK3_REG6 0x057 +#define HI6553_BUCK4_REG2 0x05b +#define HI6553_BUCK4_REG5 0x05e +#define HI6553_BUCK4_REG6 0x05f +#define HI6553_CLK_TOP00x063 +#define HI6553_CLK_TOP30x066 +#define HI6553_CLK_TOP40x067 +#define HI6553_VSET_BUCK2_ADJ 0x06d +#define HI6553_VSET_BUCK3_ADJ 0x06e +#define HI6553_LDO7_REG_ADJ0x078 +#define HI6553_LDO10_REG_ADJ 0x07b +#define HI6553_LDO19_REG_ADJ 0x084 +#define HI6553_LDO20_REG_ADJ 0x085 +#define HI6553_DR_LED_CTRL 0x098 +#define HI6553_DR_OUT_CTRL 0x099 +#define HI6553_DR3_ISET0x09a +#define HI6553_DR3_START_DEL 0x09b +#define HI6553_DR4_ISET0x09c +#define HI6553_DR4_START_DEL 0x09d +#define HI6553_DR345_TIM_CONF0 0x0a0 +#define HI6553_NP_REG_ADJ1 0x0be +#define HI6553_NP_REG_CHG 0x0c0 +#define HI6553_BUCK01_CTRL20x0d9 +#define HI6553_BUCK0_CTRL1 0x0dd +#define HI6553_BUCK0_CTRL5 0x0e1 +#define HI6553_BUCK0_CTRL7 0x0e3 +#define HI6553_BUCK1_CTRL1 0x0e8 +#define HI6553_BUCK1_CTRL5 0x0ec +#define HI6553_BUCK1_CTRL7 0x0ef +#define HI6553_CLK19M2_600_586_EN 0x0fe + +#define HI6553_LED_START_DELAY_TIME0x00 +#define HI6553_LED_ELEC_VALUE 0x07 +#define HI6553_LED_LIGHT_TIME 0xf0 +#define HI6553_LED_GREEN_ENABLE(1 1) +#define HI6553_LED_OUT_CTRL0x00 + +#define HI6553_PMU_V3000x30 +#define HI6553_PMU_V3100x31 + +unsigned char hi6553_read_8(unsigned int offset); +void hi6553_write_8(unsigned int offset, unsigned char value); + +#endif /* __HI6553_PMIC_H__ */ -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/6] ARM64: hikey: hi6220: Add u-boot support for the 96boards CE HiKey board.
HiKey is the first 96boards consumer edition compliant board. It features a
hi6220
SoC which has eight ARM A53 cpu's.
This initial port adds support for: -
1) Serial
2) eMMC / sd card
3) USB
4) GPIO
It has been tested with Arm Trusted Firmware running u-boot as the BL33
executable.
Notes:
eMMC has been tested with basic reading of eMMC partition intto DDR. I have not
tested writing / erasing. Due to lack of clock control it won't be
running in the most performant high speed mode.
SD card slot has been tested for reading and booting kernels into DDR.
It is also currently used for saving the u-boot enviroment.
USB has been tested with ASIX networking adapter to tftpboot kernels
into DDR. On v2015.07-rc2 dhcp now works, and also usb mass storage
is enumerated correctly.
GPIO has been tested using gpio toggle GPIO4_1-3 to flash LEDs.
Basic SoC datasheet can be found here: -
https://github.com/96boards/documentation/blob/master/hikey/
Hi6220V100_Multi-Mode_Application_Processor_Function_Description.pdf
Board schematic can be found here: -
https://github.com/96boards/documentation/blob/master/hikey/
96Boards-Hikey-Rev-A1.pdf
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
arch/arm/Kconfig | 8 +
board/hisilicon/hikey/Kconfig | 15 ++
board/hisilicon/hikey/Makefile | 8 +
board/hisilicon/hikey/hikey.c | 415 +
configs/hikey_defconfig| 5 +
include/configs/hikey.h| 168 +
6 files changed, 619 insertions(+)
create mode 100644 board/hisilicon/hikey/Kconfig
create mode 100644 board/hisilicon/hikey/Makefile
create mode 100644 board/hisilicon/hikey/hikey.c
create mode 100644 configs/hikey_defconfig
create mode 100644 include/configs/hikey.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2985e6e..d0b7939 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -721,6 +721,13 @@ config TARGET_LS2085ARDB
development platform that supports the QorIQ LS2085A
Layerscape Architecture processor.
+config TARGET_HIKEY
+ bool Support HiKey 96boards Consumer Edition Platform
+ select ARM64
+ help
+ Support for HiKey 96boards platform. It features a HI6220
+ SoC, with 8xA53 CPU, mali450 gpu, and 1GB RAM.
+
config TARGET_LS1021AQDS
bool Support ls1021aqds
select CPU_V7
@@ -865,6 +872,7 @@ source board/Marvell/gplugd/Kconfig
source board/armadeus/apf27/Kconfig
source board/armltd/vexpress/Kconfig
source board/armltd/vexpress64/Kconfig
+source board/hisilicon/hikey/Kconfig
source board/bachmann/ot1200/Kconfig
source board/balloon3/Kconfig
source board/barco/platinum/Kconfig
diff --git a/board/hisilicon/hikey/Kconfig b/board/hisilicon/hikey/Kconfig
new file mode 100644
index 000..f7f1055
--- /dev/null
+++ b/board/hisilicon/hikey/Kconfig
@@ -0,0 +1,15 @@
+if TARGET_HIKEY
+
+config SYS_BOARD
+ default hikey
+
+config SYS_VENDOR
+ default hisilicon
+
+config SYS_SOC
+ default hi6220
+
+config SYS_CONFIG_NAME
+ default hikey
+
+endif
diff --git a/board/hisilicon/hikey/Makefile b/board/hisilicon/hikey/Makefile
new file mode 100644
index 000..d4ec8c7
--- /dev/null
+++ b/board/hisilicon/hikey/Makefile
@@ -0,0 +1,8 @@
+#
+# (C) Copyright 2000-2004
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y := hikey.o
diff --git a/board/hisilicon/hikey/hikey.c b/board/hisilicon/hikey/hikey.c
new file mode 100644
index 000..bd5c409
--- /dev/null
+++ b/board/hisilicon/hikey/hikey.c
@@ -0,0 +1,415 @@
+/*
+ * (C) Copyright 2015 Linaro
+ * Peter Griffin peter.grif...@linaro.org
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include common.h
+#include dm.h
+#include malloc.h
+#include errno.h
+#include netdev.h
+#include asm/io.h
+#include asm-generic/gpio.h
+#include asm/arch/gpio.h
+#include asm/arch/dwmmc.h
+#include asm/arch/hi6220.h
+#include asm/arch/hi6553.h
+
+#ifdef CONFIG_DM_GPIO
+static const struct hikey_gpio_platdata hi6220_gpio[] = {
+ { 0, HI6220_GPIO_BASE(0)},
+ { 1, HI6220_GPIO_BASE(1)},
+ { 2, HI6220_GPIO_BASE(2)},
+ { 3, HI6220_GPIO_BASE(3)},
+ { 4, HI6220_GPIO_BASE(4)},
+ { 5, HI6220_GPIO_BASE(5)},
+ { 6, HI6220_GPIO_BASE(6)},
+ { 7, HI6220_GPIO_BASE(7)},
+ { 8, HI6220_GPIO_BASE(8)},
+ { 9, HI6220_GPIO_BASE(9)},
+ { 10, HI6220_GPIO_BASE(10)},
+ { 11, HI6220_GPIO_BASE(11)},
+ { 12, HI6220_GPIO_BASE(12)},
+ { 13, HI6220_GPIO_BASE(13)},
+ { 14, HI6220_GPIO_BASE(14)},
+ { 15, HI6220_GPIO_BASE(15)},
+ { 16, HI6220_GPIO_BASE(16)},
+ { 17, HI6220_GPIO_BASE(17)},
+ { 18, HI6220_GPIO_BASE(18)},
+ { 19, HI6220_GPIO_BASE(19)},
+
+};
+
+U_BOOT_DEVICES(hi6220_gpios) = {
+ { gpio_hi6220, hi6220_gpio[0] },
+ { gpio_hi6220, hi6220_gpio[1] },
+ { gpio_hi6220, hi6220_gpio[2] },
+ { gpio_hi6220,
[U-Boot] [PATCH v2 2/6] ARM: hi6220: Add register and bitfield definition header files.
This patch adds the header files which will be used in the subsquent board / drivers to enable support for hi6220 hikey board. Signed-off-by: Peter Griffin peter.grif...@linaro.org --- arch/arm/include/asm/arch-hi6220/hi6220.h | 324 +++ .../include/asm/arch-hi6220/hi6220_regs_alwayson.h | 349 + 2 files changed, 673 insertions(+) create mode 100644 arch/arm/include/asm/arch-hi6220/hi6220.h create mode 100644 arch/arm/include/asm/arch-hi6220/hi6220_regs_alwayson.h diff --git a/arch/arm/include/asm/arch-hi6220/hi6220.h b/arch/arm/include/asm/arch-hi6220/hi6220.h new file mode 100644 index 000..3ddec91 --- /dev/null +++ b/arch/arm/include/asm/arch-hi6220/hi6220.h @@ -0,0 +1,324 @@ +/* + * (C) Copyright 2015 Linaro + * Peter Griffin peter.grif...@linaro.org + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#ifndef __HI6220_H__ +#define __HI6220_H__ + +#include hi6220_regs_alwayson.h + +#define HI6220_MMC0_BASE 0xF723D000 +#define HI6220_MMC1_BASE 0xF723E000 + +#define HI6220_PMUSSI_BASE 0xF800 + +#define HI6220_PERI_BASE 0xF703 + +#define PERI_SC_PERIPH_CTRL1 (HI6220_PERI_BASE + 0x000) + +#define PERI_CTRL1_ETR_AXI_CSYSREQ_N (1 0) +#define PERI_CTRL1_HIFI_INT_MASK (1 1) +#define PERI_CTRL1_HIFI_ALL_INT_MASK (1 2) +#define PERI_CTRL1_ETR_AXI_CSYSREQ_N_MSK (1 16) +#define PERI_CTRL1_HIFI_INT_MASK_MSK (1 17) +#define PERI_CTRL1_HIFI_ALL_INT_MASK_MSK (1 18) + + +#define PERI_SC_PERIPH_CTRL2 (HI6220_PERI_BASE + 0x004) + +#define PERI_CTRL2_MMC_CLK_PHASE_BYPASS_EN_MMC0(1 0) +#define PERI_CTRL2_MMC_CLK_PHASE_BYPASS_EN_MMC1(1 2) +#define PERI_CTRL2_NAND_SYS_MEM_SEL(1 6) +#define PERI_CTRL2_G3D_DDRT_AXI_SEL(1 7) +#define PERI_CTRL2_GU_MDM_BBP_TESTPIN_SEL (1 8) +#define PERI_CTRL2_CODEC_SSI_MASTER_CHECK (1 9) +#define PERI_CTRL2_FUNC_TEST_SOFT (1 12) +#define PERI_CTRL2_CSSYS_TS_ENABLE (1 15) +#define PERI_CTRL2_HIFI_RAMCTRL_S_EMA (1 16) +#define PERI_CTRL2_HIFI_RAMCTRL_S_EMAW (1 20) +#define PERI_CTRL2_HIFI_RAMCTRL_S_EMAS (1 22) +#define PERI_CTRL2_HIFI_RAMCTRL_S_RET1N(1 26) +#define PERI_CTRL2_HIFI_RAMCTRL_S_RET2N(1 27) +#define PERI_CTRL2_HIFI_RAMCTRL_S_PGEN (1 28) + +#define PERI_SC_PERIPH_CTRL3 (HI6220_PERI_BASE + 0x008) + +#define PERI_CTRL3_HIFI_DDR_HARQMEM_ADDR (1 0) +#define PERI_CTRL3_HIFI_HARQMEMRMP_EN (1 12) +#define PERI_CTRL3_HARQMEM_SYS_MED_SEL (1 13) +#define PERI_CTRL3_SOC_AP_OCCUPY_GRP1 (1 14) +#define PERI_CTRL3_SOC_AP_OCCUPY_GRP2 (1 16) +#define PERI_CTRL3_SOC_AP_OCCUPY_GRP3 (1 18) +#define PERI_CTRL3_SOC_AP_OCCUPY_GRP4 (1 20) +#define PERI_CTRL3_SOC_AP_OCCUPY_GRP5 (1 22) +#define PERI_CTRL3_SOC_AP_OCCUPY_GRP6 (1 24) + +#define PERI_SC_PERIPH_CTRL4 (HI6220_PERI_BASE + 0x00c) + +#define PERI_CTRL4_PICO_FSELV (1 0) +#define PERI_CTRL4_FPGA_EXT_PHY_SEL(1 3) +#define PERI_CTRL4_PICO_REFCLKSEL (1 4) +#define PERI_CTRL4_PICO_SIDDQ (1 6) +#define PERI_CTRL4_PICO_SUSPENDM_SLEEPM(1 7) +#define PERI_CTRL4_PICO_OGDISABLE (1 8) +#define PERI_CTRL4_PICO_COMMONONN (1 9) +#define PERI_CTRL4_PICO_VBUSVLDEXT (1 10) +#define PERI_CTRL4_PICO_VBUSVLDEXTSEL (1 11) +#define PERI_CTRL4_PICO_VATESTENB (1 12) +#define PERI_CTRL4_PICO_SUSPENDM (1 14) +#define PERI_CTRL4_PICO_SLEEPM (1 15) +#define PERI_CTRL4_BC11_C (1 16) +#define PERI_CTRL4_BC11_B (1 17) +#define PERI_CTRL4_BC11_A (1 18) +#define PERI_CTRL4_BC11_GND(1 19) +#define PERI_CTRL4_BC11_FLOAT (1 20) +#define PERI_CTRL4_OTG_PHY_SEL (1 21) +#define PERI_CTRL4_USB_OTG_SS_SCALEDOWN_MODE (1 22) +#define PERI_CTRL4_OTG_DM_PULLDOWN (1 24) +#define PERI_CTRL4_OTG_DP_PULLDOWN (1 25) +#define PERI_CTRL4_OTG_IDPULLUP(1 26) +#define PERI_CTRL4_OTG_DRVBUS (1 27) +#define PERI_CTRL4_OTG_SESSEND (1 28) +#define PERI_CTRL4_OTG_BVALID (1 29)
Re: [U-Boot] [RFC PATCH 12/12] devres: add debug command to dump devres
2015-07-08 13:29 GMT+09:00 Masahiro Yamada yamada.masah...@socionext.com:
diff --git a/drivers/core/devres.c b/drivers/core/devres.c
index f24bcac..71f2f67 100644
--- a/drivers/core/devres.c
+++ b/drivers/core/devres.c
@@ -13,6 +13,7 @@
#include linux/kernel.h
#include linux/list.h
#include dm/device.h
+#include dm/root.h
struct devres {
struct list_headentry;
@@ -136,6 +137,42 @@ void devres_release_all(struct udevice *dev)
release_nodes(dev, dev-devres_head, false);
}
+#ifdef CONFIG_CMD_DEVRES
+void dump_resources(struct udevice *dev, int depth)
+{
I forgot to add static.
I will fix it in v2 if the basic idea of this series is OK.
--
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 v3 17/25] rockchip: rk3288: Add pinctrl driver
Hi Simon,
2015-07-07 2:32 GMT+09:00 Simon Glass s...@chromium.org:
Hi Masahiro,
On 6 July 2015 at 11:24, Masahiro Yamada yamada.masah...@socionext.com
wrote:
Hi Simon,
2015-06-24 8:29 GMT+09:00 Simon Glass s...@chromium.org:
+
+static int rk3288_pinctrl_get_periph_id(struct udevice *dev,
+ struct udevice *periph)
+{
+ u32 cell[3];
+ int ret;
+
+ ret = fdtdec_get_int_array(gd-fdt_blob, periph-of_offset,
+ interrupts, cell, ARRAY_SIZE(cell));
+ if (ret 0)
+ return -EINVAL;
+
+ switch (cell[1]) {
+ case 44:
+ return PERIPH_ID_SPI0;
+ case 45:
+ return PERIPH_ID_SPI1;
+ case 46:
+ return PERIPH_ID_SPI2;
+ case 60:
+ return PERIPH_ID_I2C0;
+ case 62: /* Note strange order */
+ return PERIPH_ID_I2C1;
+ case 61:
+ return PERIPH_ID_I2C2;
+ case 63:
+ return PERIPH_ID_I2C3;
+ case 64:
+ return PERIPH_ID_I2C4;
+ case 65:
+ return PERIPH_ID_I2C5;
+ }
+
+ return -ENOENT;
+}
Weird.
Do you parse the interrupts property
to identify the peripheral?
This is what I really do not like to do.
Yes. It's similar to a clock number. It doesn't really matter what we
use. The interrupt number is a fixed part of the binding and will
never change.
I guess it is abuse of interrupts property.
Moreover, it can not cover cases where a single signal can be routed to
several pins.
For example, say we want to set pinmux for the I2C channel 0 (SDA0 and SCL0).
On some vendors' SoCs, it is possible to connect SDA0 to either pin10
or pin20 for example.
Likewise, SCL0 can be connected to pin11 or pin21.
(Yes, it is possible on my SoCs)
The interrupt ID can identify it is I2C0, and that's it.
Some boards expect the signals come out of pin10, 11,
and other boards pin20, 21.
The interrupt ID cannot distinguish those cases; the pinctrl-*
property can do it.
This is mentioned in Documentation/pinctrl.txt and
that is why a single function can have multiple pin-groups in Linux's
pinctrl drivers.
I think this design cannot meet some vendors' demand.
At least, I am unhappy with it.
Could you hold your pinctrl patches and give me time to discuss a bit
more, please?
I understand how pinctrl drivers work in Linux, so please give me some time
to consider if better design might be possible.
--
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] keystone2: use appropriate HD field for destination port
On 07/08/2015 01:50 PM, ivan.khoronzhuk wrote:
Vitaly,
On 08.07.15 20:26, Vitaly Andrianov wrote:
On 07/08/2015 01:05 PM, Ivan Khoronzhuk wrote:
Vitaly,
On 08.07.15 20:05, Vitaly Andrianov wrote:
On 07/08/2015 12:38 PM, Ivan Khoronzhuk wrote:
Hi, Vitaly
I suppose it's better to decide in upper driver how to use swinfo
field.
Like in drivers/net/keystone_net.c
The keystone navigator supposed to be used as a tool for communicating
between different IPs, and each of them decide how to use swinfo
fields.
It's protocol specific information and should be known only in sending
parts. What if tomorrow you will decide to send some packet to PA?,
you
will rewrite this function again?
It's not the place for such kind information.
Even more, this is the h/w specific decision and no need to check this
for each sent packet. You better statically assign how to use this
field
depending on h/w revision, using #if.
On 08.07.15 18:45, Vitaly Andrianov wrote:
K2L and L2E have different from K2HK EthSS version, which uses
tag_info
field for destination slave port. This commit adds the dest_port_info
field
to the struct pktdma_cfg, to configure which HD filed tag_info or
pkt_info
shall be used to configure descriptor.
Before that commit the swinfo[2] was used for that purpose. Even if
that
worked on K2HK devices, the correct field for K2HK is the pkt_info.
The netcp_send() configure appropriate HD info field depending on the
direct_info of the currently using netcp.
Signed-off-by: Vitaly Andrianov vita...@ti.com
Acked-by: Murali Karicheri m-kariche...@ti.com
---
arch/arm/include/asm/ti-common/keystone_nav.h | 9 -
drivers/dma/keystone_nav.c| 12 ++--
drivers/net/keystone_net.c| 3 +--
3 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/ti-common/keystone_nav.h
b/arch/arm/include/asm/ti-common/keystone_nav.h
index 696d8c6..5a0e391 100644
--- a/arch/arm/include/asm/ti-common/keystone_nav.h
+++ b/arch/arm/include/asm/ti-common/keystone_nav.h
@@ -152,6 +152,11 @@ struct rx_flow_regs {
u32thresh[3];
};
+enum dest_port_info {
+PKT_INFO,
+TAG_INFO
+};
+
struct pktdma_cfg {
struct global_ctl_regs*global;
struct tx_chan_regs*tx_ch;
@@ -167,6 +172,7 @@ struct pktdma_cfg {
u32tx_snd_q;
u32rx_flow; /* flow that is used for RX */
+enum dest_port_info dest_port_info;/* HD fiels for dest port
bits */
};
extern struct pktdma_cfg netcp_pktdma;
@@ -184,7 +190,8 @@ struct rx_buff_desc {
int ksnav_close(struct pktdma_cfg *pktdma);
int ksnav_init(struct pktdma_cfg *pktdma, struct rx_buff_desc
*rx_buffers);
-int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
u32 swinfo2);
+int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
+ u32 dest_port);
void *ksnav_recv(struct pktdma_cfg *pktdma, u32 **pkt, int
*num_bytes);
void ksnav_release_rxhd(struct pktdma_cfg *pktdma, void *hd);
diff --git a/drivers/dma/keystone_nav.c b/drivers/dma/keystone_nav.c
index dfca75a..64b1cee 100644
--- a/drivers/dma/keystone_nav.c
+++ b/drivers/dma/keystone_nav.c
@@ -278,7 +278,8 @@ int ksnav_close(struct pktdma_cfg *pktdma)
return QM_OK;
}
-int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
u32 swinfo2)
+int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
+ u32 dest_port)
{
struct qm_host_desc *hd;
@@ -286,8 +287,15 @@ int ksnav_send(struct pktdma_cfg *pktdma, u32
*pkt, int num_bytes, u32 swinfo2)
if (hd == NULL)
return QM_ERR;
+dest_port = 0xf;
hd-desc_info= num_bytes;
-hd-swinfo[2]= swinfo2;
+if (pktdma-dest_port_info == PKT_INFO) {
+hd-packet_info= qm_cfg-qpool_num | (dest_port 16);
+} else {
+hd-packet_info = qm_cfg-qpool_num;
+hd-tag_info = dest_port;
+}
+
hd-packet_info = qm_cfg-qpool_num;
qm_buff_push(hd, pktdma-tx_snd_q, pkt, num_bytes);
diff --git a/drivers/net/keystone_net.c b/drivers/net/keystone_net.c
index 0c5fdee..e2adb67 100644
--- a/drivers/net/keystone_net.c
+++ b/drivers/net/keystone_net.c
@@ -381,8 +381,7 @@ int32_t cpmac_drv_send(u32 *buffer, int
num_bytes,
int slave_port_num)
if (num_bytes EMAC_MIN_ETHERNET_PKT_SIZE)
num_bytes = EMAC_MIN_ETHERNET_PKT_SIZE;
-return ksnav_send(netcp_pktdma, buffer,
- num_bytes, (slave_port_num) 16);
+return ksnav_send(netcp_pktdma, buffer, num_bytes,
slave_port_num);
}
/* Eth device open */
Hi Ivan,
I agree with you. And probably we will need to implement your proposal
in future commits. This commit is to fix the bug, which is in existing
driver.
Thanks,
Vitaly
Sorry, I supposed that first msg was not sent.
It's better to fix it in drivers/net/keystone_net.c
Ivan,
I don't understand your proposal. The network driver doesn't know
anything about CPPI DMA engine
Re: [U-Boot] [PATCH] keystone2: use appropriate HD field for destination port
On 07/08/2015 12:38 PM, Ivan Khoronzhuk wrote:
Hi, Vitaly
I suppose it's better to decide in upper driver how to use swinfo field.
Like in drivers/net/keystone_net.c
The keystone navigator supposed to be used as a tool for communicating
between different IPs, and each of them decide how to use swinfo fields.
It's protocol specific information and should be known only in sending
parts. What if tomorrow you will decide to send some packet to PA?, you
will rewrite this function again?
It's not the place for such kind information.
Even more, this is the h/w specific decision and no need to check this
for each sent packet. You better statically assign how to use this field
depending on h/w revision, using #if.
On 08.07.15 18:45, Vitaly Andrianov wrote:
K2L and L2E have different from K2HK EthSS version, which uses tag_info
field for destination slave port. This commit adds the dest_port_info
field
to the struct pktdma_cfg, to configure which HD filed tag_info or
pkt_info
shall be used to configure descriptor.
Before that commit the swinfo[2] was used for that purpose. Even if that
worked on K2HK devices, the correct field for K2HK is the pkt_info.
The netcp_send() configure appropriate HD info field depending on the
direct_info of the currently using netcp.
Signed-off-by: Vitaly Andrianov vita...@ti.com
Acked-by: Murali Karicheri m-kariche...@ti.com
---
arch/arm/include/asm/ti-common/keystone_nav.h | 9 -
drivers/dma/keystone_nav.c| 12 ++--
drivers/net/keystone_net.c| 3 +--
3 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/ti-common/keystone_nav.h
b/arch/arm/include/asm/ti-common/keystone_nav.h
index 696d8c6..5a0e391 100644
--- a/arch/arm/include/asm/ti-common/keystone_nav.h
+++ b/arch/arm/include/asm/ti-common/keystone_nav.h
@@ -152,6 +152,11 @@ struct rx_flow_regs {
u32thresh[3];
};
+enum dest_port_info {
+PKT_INFO,
+TAG_INFO
+};
+
struct pktdma_cfg {
struct global_ctl_regs*global;
struct tx_chan_regs*tx_ch;
@@ -167,6 +172,7 @@ struct pktdma_cfg {
u32tx_snd_q;
u32rx_flow; /* flow that is used for RX */
+enum dest_port_info dest_port_info;/* HD fiels for dest port
bits */
};
extern struct pktdma_cfg netcp_pktdma;
@@ -184,7 +190,8 @@ struct rx_buff_desc {
int ksnav_close(struct pktdma_cfg *pktdma);
int ksnav_init(struct pktdma_cfg *pktdma, struct rx_buff_desc
*rx_buffers);
-int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
u32 swinfo2);
+int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
+ u32 dest_port);
void *ksnav_recv(struct pktdma_cfg *pktdma, u32 **pkt, int *num_bytes);
void ksnav_release_rxhd(struct pktdma_cfg *pktdma, void *hd);
diff --git a/drivers/dma/keystone_nav.c b/drivers/dma/keystone_nav.c
index dfca75a..64b1cee 100644
--- a/drivers/dma/keystone_nav.c
+++ b/drivers/dma/keystone_nav.c
@@ -278,7 +278,8 @@ int ksnav_close(struct pktdma_cfg *pktdma)
return QM_OK;
}
-int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
u32 swinfo2)
+int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
+ u32 dest_port)
{
struct qm_host_desc *hd;
@@ -286,8 +287,15 @@ int ksnav_send(struct pktdma_cfg *pktdma, u32
*pkt, int num_bytes, u32 swinfo2)
if (hd == NULL)
return QM_ERR;
+dest_port = 0xf;
hd-desc_info= num_bytes;
-hd-swinfo[2]= swinfo2;
+if (pktdma-dest_port_info == PKT_INFO) {
+hd-packet_info= qm_cfg-qpool_num | (dest_port 16);
+} else {
+hd-packet_info = qm_cfg-qpool_num;
+hd-tag_info = dest_port;
+}
+
hd-packet_info = qm_cfg-qpool_num;
qm_buff_push(hd, pktdma-tx_snd_q, pkt, num_bytes);
diff --git a/drivers/net/keystone_net.c b/drivers/net/keystone_net.c
index 0c5fdee..e2adb67 100644
--- a/drivers/net/keystone_net.c
+++ b/drivers/net/keystone_net.c
@@ -381,8 +381,7 @@ int32_t cpmac_drv_send(u32 *buffer, int num_bytes,
int slave_port_num)
if (num_bytes EMAC_MIN_ETHERNET_PKT_SIZE)
num_bytes = EMAC_MIN_ETHERNET_PKT_SIZE;
-return ksnav_send(netcp_pktdma, buffer,
- num_bytes, (slave_port_num) 16);
+return ksnav_send(netcp_pktdma, buffer, num_bytes, slave_port_num);
}
/* Eth device open */
Hi Ivan,
I agree with you. And probably we will need to implement your proposal
in future commits. This commit is to fix the bug, which is in existing
driver.
Thanks,
Vitaly
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] keystone2: use appropriate HD field for destination port
On 07/08/2015 01:05 PM, Ivan Khoronzhuk wrote:
Vitaly,
On 08.07.15 20:05, Vitaly Andrianov wrote:
On 07/08/2015 12:38 PM, Ivan Khoronzhuk wrote:
Hi, Vitaly
I suppose it's better to decide in upper driver how to use swinfo field.
Like in drivers/net/keystone_net.c
The keystone navigator supposed to be used as a tool for communicating
between different IPs, and each of them decide how to use swinfo fields.
It's protocol specific information and should be known only in sending
parts. What if tomorrow you will decide to send some packet to PA?, you
will rewrite this function again?
It's not the place for such kind information.
Even more, this is the h/w specific decision and no need to check this
for each sent packet. You better statically assign how to use this field
depending on h/w revision, using #if.
On 08.07.15 18:45, Vitaly Andrianov wrote:
K2L and L2E have different from K2HK EthSS version, which uses tag_info
field for destination slave port. This commit adds the dest_port_info
field
to the struct pktdma_cfg, to configure which HD filed tag_info or
pkt_info
shall be used to configure descriptor.
Before that commit the swinfo[2] was used for that purpose. Even if
that
worked on K2HK devices, the correct field for K2HK is the pkt_info.
The netcp_send() configure appropriate HD info field depending on the
direct_info of the currently using netcp.
Signed-off-by: Vitaly Andrianov vita...@ti.com
Acked-by: Murali Karicheri m-kariche...@ti.com
---
arch/arm/include/asm/ti-common/keystone_nav.h | 9 -
drivers/dma/keystone_nav.c| 12 ++--
drivers/net/keystone_net.c| 3 +--
3 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/ti-common/keystone_nav.h
b/arch/arm/include/asm/ti-common/keystone_nav.h
index 696d8c6..5a0e391 100644
--- a/arch/arm/include/asm/ti-common/keystone_nav.h
+++ b/arch/arm/include/asm/ti-common/keystone_nav.h
@@ -152,6 +152,11 @@ struct rx_flow_regs {
u32thresh[3];
};
+enum dest_port_info {
+PKT_INFO,
+TAG_INFO
+};
+
struct pktdma_cfg {
struct global_ctl_regs*global;
struct tx_chan_regs*tx_ch;
@@ -167,6 +172,7 @@ struct pktdma_cfg {
u32tx_snd_q;
u32rx_flow; /* flow that is used for RX */
+enum dest_port_info dest_port_info;/* HD fiels for dest port
bits */
};
extern struct pktdma_cfg netcp_pktdma;
@@ -184,7 +190,8 @@ struct rx_buff_desc {
int ksnav_close(struct pktdma_cfg *pktdma);
int ksnav_init(struct pktdma_cfg *pktdma, struct rx_buff_desc
*rx_buffers);
-int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
u32 swinfo2);
+int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
+ u32 dest_port);
void *ksnav_recv(struct pktdma_cfg *pktdma, u32 **pkt, int
*num_bytes);
void ksnav_release_rxhd(struct pktdma_cfg *pktdma, void *hd);
diff --git a/drivers/dma/keystone_nav.c b/drivers/dma/keystone_nav.c
index dfca75a..64b1cee 100644
--- a/drivers/dma/keystone_nav.c
+++ b/drivers/dma/keystone_nav.c
@@ -278,7 +278,8 @@ int ksnav_close(struct pktdma_cfg *pktdma)
return QM_OK;
}
-int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
u32 swinfo2)
+int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
+ u32 dest_port)
{
struct qm_host_desc *hd;
@@ -286,8 +287,15 @@ int ksnav_send(struct pktdma_cfg *pktdma, u32
*pkt, int num_bytes, u32 swinfo2)
if (hd == NULL)
return QM_ERR;
+dest_port = 0xf;
hd-desc_info= num_bytes;
-hd-swinfo[2]= swinfo2;
+if (pktdma-dest_port_info == PKT_INFO) {
+hd-packet_info= qm_cfg-qpool_num | (dest_port 16);
+} else {
+hd-packet_info = qm_cfg-qpool_num;
+hd-tag_info = dest_port;
+}
+
hd-packet_info = qm_cfg-qpool_num;
qm_buff_push(hd, pktdma-tx_snd_q, pkt, num_bytes);
diff --git a/drivers/net/keystone_net.c b/drivers/net/keystone_net.c
index 0c5fdee..e2adb67 100644
--- a/drivers/net/keystone_net.c
+++ b/drivers/net/keystone_net.c
@@ -381,8 +381,7 @@ int32_t cpmac_drv_send(u32 *buffer, int num_bytes,
int slave_port_num)
if (num_bytes EMAC_MIN_ETHERNET_PKT_SIZE)
num_bytes = EMAC_MIN_ETHERNET_PKT_SIZE;
-return ksnav_send(netcp_pktdma, buffer,
- num_bytes, (slave_port_num) 16);
+return ksnav_send(netcp_pktdma, buffer, num_bytes,
slave_port_num);
}
/* Eth device open */
Hi Ivan,
I agree with you. And probably we will need to implement your proposal
in future commits. This commit is to fix the bug, which is in existing
driver.
Thanks,
Vitaly
Sorry, I supposed that first msg was not sent.
It's better to fix it in drivers/net/keystone_net.c
Ivan,
I don't understand your proposal. The network driver doesn't know
anything about CPPI DMA engine internals. That is the navigator's job to
fill appropriate packet BD fields and it only takes care
Re: [U-Boot] Please pull u-boot-sunxi master (bugfix for v2015.07)
On Wed, Jul 08, 2015 at 04:52:43PM +0200, Hans de Goede wrote: Hi Tom, One of the sunxi dts files for a new board got merged into the upstream kernel under a different name than that it was originally submitted with. This pull-req contains a single patch adjusting the name in u-boot, so that we do not end up shipping a u-boot which looks for a differently named .dtb file then the kernel ships with. The following changes since commit 0a888f584c48984cb9657a5d42dc994b33c264a7: ARM: DRA72x: fix io delay calibration for ethernet (2015-07-07 20:15:52 -0400) are available in the git repository at: http://git.denx.de/u-boot-sunxi.git master for you to fetch changes up to 8fa2e20913183133998cbbb78a5184bd20ccfcbe: sunxi: Adjust Ippo_q8h_v1_2_a33_1024x600 dts filename to match the upstream kernel (2015-07-08 16:21:27 +0200) Applied to u-boot/master, 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] net: designware: Program MAC address to hardware after soft reset
On Mon, Jun 15, 2015 at 06:40:19PM +0800, Bin Meng wrote: commit f566c99 net: Update hardware MAC address if it changes in env removes writing MAC address to designware controller after soft reset. This makes designware ethernet port fail to work. Actually the MAC address should always be programmed after soft reset. Signed-off-by: Bin Meng bmeng...@gmail.com Acked-by: Joe Hershberger joe.hershber...@ni.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] net: lpc32xx: improve download rate in RMII phy mode
Hi Vladimir, Thanks for taking the time to test this patch. After further investigation, the issue was with our internal Micrel KSZ8031RNL phy implementation. The extra 10ms delay is not require. This patch should be discard. Thanks for the feedback regarding the mail system; - for an internal mail address, the tab is not translated in space. - for an external e-mail, there is a translation that take place; we will look into the problem before sending the patch to support the Micrel KSZ8031RNL phy. Sylvain Lemieux -Original Message- From: Vladimir Zapolskiy [mailto:v...@mleia.com] Sent: 8-Jul-15 1:06 AM To: LEMIEUX, SYLVAIN Cc: joe.hershber...@ni.com; albert.arib...@3adev.fr; u-boot@lists.denx.de Subject: Re: [PATCH 1/1] net: lpc32xx: improve download rate in RMII phy mode Hi Sylvain, On 07.07.2015 22:13, LEMIEUX, SYLVAIN wrote: This is a minor update to LPC32xx MAC driver patch that add support for the RMII phy mode. In the legacy BSP from NXP, in RMII phy mode, an extra 10ms delay was present after the release of the soft reset. In my tests (connected using RMII phy mode to a Micrel KSZ8031RNL), the download rate was 20% to 25% slower if the extra 10ms delay was not present. I found some time to test this change, and actually on my environment I don't observe any improvement, below are some details: * tested on devkit3250 board with SMSC LAN8700 phy connected to LPC3250 MAC over RMII, * to download files to RAM I used tftp protocol, * file download is started immediately on boot, boot delay is set to 0, bootcmd runs dhcp and then tftp, * I downloaded files of 1 MiB and 48 MiB size, both cases produce the same download speed of about 1.15 MiB/second, presence/absence of the proposed 10ms delay in lpc32xx_eth_initialize() has no impact on download speed, * the speed is not limited by external network hardware or topology, absolutely in the same environment an iMX6 board is capable to download files over tftp at 3.5 - 4.0 MiB per second rate, * 20% to 25% download speed improvement (1.15 MiB/s to expected ~1.4 MiB/s) is not observed after applying your proposed change, probably in your environment this delay is needed due to your board, network connection or PHY specifics, is Micrel KSZ8031RNL support comes from legacy BSP?, * I can not confirm that an additional delay on board/MAC init is needed here regardless of its presence in legacy BSP since it defers board initialization by 10ms with no visual download speed improvement, also any possible relation between this delay and download speed is not obvious, * download speed in my legacy BSP dated by 2010 is about 3-4 times slower than in vanilla U-boot, unfortunately the exact figure is not reported. If the change has positive impact for you, I would propose to add a delay in your board file, e.g. in board_early_init_f() after lpc32xx_eth_initialize() call and retest, right at the moment I hesitate to add a 10ms delay to _all_ users of LPC32xx MAC / RMII phy. Also it would be nice to know the exact download speed on your end for * current version of lpc32xx_eth.c with my recent patches applied, * current version of lpc32xx_eth.c with my recent patches applied and your change, * legacy BSP. A couple of general recommendations regarding posting changes: * too long lines in commit message, * it seems that your mail server screws up tab symbols from the mail body, the patch can not be applied as is, * also it seems that your mail server repacks messages, so that a downloaded version of the sent patch is not a valid patch, from the mail headers: -- With best wishes, Vladimir This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: usb-phy: Never power off the usb ports
Hi, On 08-07-15 17:02, Marek Vasut wrote: On Wednesday, July 08, 2015 at 04:54:07 PM, Hans de Goede wrote: USB devices are not really designed to get the power bounced off and on at them. Esp. USB powered harddisks do not like this. Currently we power off the USB ports both on a usb reset and when booting the kernel, causing the usb-power to bounce off and then back on again. This patch removes the powering off calls, fixing the undesirable power bouncing. Signed-off-by: Hans de Goede hdego...@redhat.com Shall I pick this through u-boot-usb or would you like this to go through u-boot-sunxi ? Recently, I feel a bit left out :-) Heh, sorry but we've a bunch of other sunxi/usb mixed patches already queued up, so I think it is best if I take this one through the sunxi tree to avoid conflicts. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] dcache support for Raspberry Pi 1
Hello Albert,
On Monday 06 July 2015, 23:26:41 wrote Albert ARIBAUD:
On Mon, 06 Jul 2015 20:24:31 +0200, Alexander Stein
alexander...@web.de wrote:
Hello Albert,
On Monday 06 July 2015, 09:39:40 wrote Albert ARIBAUD:
On Sat, 4 Jul 2015 11:48:39 +0200, Alexander Stein
alexander...@web.de wrote:
dcache supprt increases the MMC read performance on RPI 1 from 5,4
MiB/s to
12.3 MiB/s. It doesn't seem to have any affect on RPI 2 though. I just
get
error messages about non-cacheline aligned address upon invalidation.
Could it be that code needed to support dcache is not the same for
rpi_2's bcm2836 than it is for rpi's bcm2835?
Sure, bcm2835 is a armv6 while bcm2836 is a armv7.
Anyway: if code properly handles unaligned addresses then it should not
throw an error message about it. Can you look into why the error is
thrown?
Apparently it does not handle non-cacheline aligned addresses transparently
or silently.
Here is the part of the code:
static void v7_dcache_inval_range(u32 start, u32 stop, u32 line_len)
{
/*
* If start address is not aligned to cache-line do not
* invalidate the first cache-line
*/
if (start (line_len - 1)) {
printf(ERROR: %s - start address is not aligned - 0x%08x\n,
__func__, start);
/* move to next cache line */
start = (start + line_len - 1) ~(line_len - 1);
}
I don't know why (a) the cache invalidation is only done from the next
cache line and (b) why this can't be done transparently without printing an
error.
But currently I'm not keen on fiddling with armv7 caches.
Well, I can see why.
Let's assume were invalidating the second half of a cache line because
that's where a buffer starts which we want to force-read from external
memory because some device fille dthis buffer with important data.
Now, most probably the compiler and linker will have used the addresses
before our buffer to map some variables which may be unrelated to the
buffer.
At the time we're told to invalidate the buffer, these variables may be
modified in-cache but not yet written out to external memory. If we
invalidate the first cache line, then we erase these modifications --
they're lost.
Now, this is an unsolvable problem -- we can't flush these variables
before invalidating, because then we would flush the whole cache line,
which would overwrite and trash the buffer in external memory.
So anyway, we're doomed; there is nothing we can do -- hence the ERROR
message. From the on, we can either just give up and go hang(), or we
can try to save whatever can be, skip the half cache line and start
invalidating at the next boundary.
(same goes for the last address: it has to be at the end of a cache
line, or else we can neither invalidate nor flush.)
Thanks for thise detailed explanation. I agree this is really a problem.
But how should this behandled: The raspberry pi messagebox handling sends a
message which might have more or less arbitrary length.
I think it might be possible to achieve in every case that those message starts
at the beginning of a cacheline. But the end might be
at different positions with different messages sent. You must flush your data
to get the firmware actually see this and you must invalidate to eventually
read the answer data which is located at the same position.
I guess I might just have not hit your described problem in my board (yet).
Best regards,
Alexander
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] crypto/fsl: fix snooping for write transactions
HW coherency won't work properly for CAAM write transactions
if AWCACHE is left to default (POR) value - 4'b0001.
It has to be programmed to 4'b0010.
For platforms that have HW coherency support:
-PPC-based: the update has no effect; CAAM coherency already works
due to the IOMMU (PAMU) driver setting the correct memory coherency
attributes
-ARM-based: the update fixes cache coherency issues,
since IOMMU (SMMU) driver is not programmed to behave similar to PAMU
Fixes: b9eebfade974c (fsl_sec: Add hardware accelerated SHA256 and SHA1)
Signed-off-by: Horia Geantă horia.gea...@freescale.com
Reviewed-by: Aneesh Bansal aneesh.ban...@freescale.com
Reviewed-by: Mingkai Hu mingkai...@freescale.com
---
drivers/crypto/fsl/jr.c | 10 ++
drivers/crypto/fsl/jr.h | 2 ++
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
index f99d59480c81..e2bd913aa259 100644
--- a/drivers/crypto/fsl/jr.c
+++ b/drivers/crypto/fsl/jr.c
@@ -459,14 +459,16 @@ static int rng_init(void)
int sec_init(void)
{
- int ret = 0;
-
-#ifdef CONFIG_PHYS_64BIT
ccsr_sec_t *sec = (void *)CONFIG_SYS_FSL_SEC_ADDR;
uint32_t mcr = sec_in32(sec-mcfgr);
+ int ret = 0;
- sec_out32(sec-mcfgr, mcr | 1 MCFGR_PS_SHIFT);
+ mcr = (mcr ~MCFGR_AWCACHE_MASK) | (0x2 MCFGR_AWCACHE_SHIFT);
+#ifdef CONFIG_PHYS_64BIT
+ mcr |= (1 MCFGR_PS_SHIFT);
#endif
+ sec_out32(sec-mcfgr, mcr);
+
ret = jr_init();
if (ret 0) {
printf(SEC initialization failed\n);
diff --git a/drivers/crypto/fsl/jr.h b/drivers/crypto/fsl/jr.h
index cce2c589ce0b..152606008845 100644
--- a/drivers/crypto/fsl/jr.h
+++ b/drivers/crypto/fsl/jr.h
@@ -21,6 +21,8 @@
#define MCFGR_SWRST ((uint32_t)(1)31) /* Software Reset */
#define MCFGR_DMA_RST ((uint32_t)(1)28) /* DMA Reset */
#define MCFGR_PS_SHIFT 16
+#define MCFGR_AWCACHE_SHIFT8
+#define MCFGR_AWCACHE_MASK (0xf MCFGR_AWCACHE_SHIFT)
#define JR_INTMASK 0x0001
#define JRCR_RESET 0x01
#define JRINT_ERR_HALT_INPROGRESS 0x4
--
2.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/20] dm: net: Support usbethaddr environment variable
+Hans Hi Joe, On 7 July 2015 at 22:04, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Simon, On Tue, Jul 7, 2015 at 9:53 PM, Simon Glass s...@chromium.org wrote: For USB Ethernet devices we need to use the usbethaddr environment variable (instead of ethaddr) the Ethernet hardware address. Add this to the uclass so that it happens automatically. I have always thought that this approach of having a separate prefix for usbethaddr was a smelly hack. Are we sure we want to propagate it here? Can we not just use dev-seq? It should already be unique in the DM, right? I was really looking forward to that all going away. Ah, OK, sorry. Do you think we need a way of specifying the eth interface # as we do with aliases at present? We did have one but Han has just removed it :-) Otherwise we'll just end up counting up from the last 'fixed' ethernet interface. Maybe that is good enough. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] dm: serial: Do not panic if no serial ports are found
Hi Hans,
On 8 July 2015 at 08:16, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 08-07-15 16:08, Simon Glass wrote:
+Masahiro
Hi Hans,
On 8 July 2015 at 05:56, Hans de Goede hdego...@redhat.com wrote:
Hi Simon,
On 07-07-15 09:00, Hans de Goede wrote:
Hi,
On 06-07-15 18:39, Simon Glass wrote:
Hi Hans,
On 5 July 2015 at 12:56, Hans de Goede hdego...@redhat.com wrote:
Some boards simply do not have any serial ports. Also no one will see
the
panic message as there is no where to print it if no serial port is
found
(and other stdout options are not yet set up at this point).
It is visible (or will be when some patches land) if you have a debug
UART set up.
Ok.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/serial/serial-uclass.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/serial/serial-uclass.c
b/drivers/serial/serial-uclass.c
index 815fec3..f036499 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -27,7 +27,7 @@ static const unsigned long baudrate_table[] =
CONFIG_SYS_BAUDRATE_TABLE;
#error Serial is required before relocation - define
CONFIG_SYS_MALLOC_F_LEN to make this work
#endif
-static void serial_find_console_or_panic(void)
+static void serial_find_console(void)
{
struct udevice *dev;
int node;
@@ -77,14 +77,12 @@ static void serial_find_console_or_panic(void)
}
#undef INDEX
}
-
- panic_str(No serial driver found);
}
/* Called prior to relocation */
int serial_init(void)
{
- serial_find_console_or_panic();
+ serial_find_console();
gd-flags |= GD_FLG_SERIAL_READY;
return 0;
@@ -93,7 +91,7 @@ int serial_init(void)
/* Called after relocation */
void serial_initialize(void)
{
- serial_find_console_or_panic();
+ serial_find_console();
}
static void _serial_putc(struct udevice *dev, char ch)
How is this handled before driver model?
It was not, the boards involved all use the A13 SoC which is the
same die as the A10s but then in a different (cheaper) package
with way less pins. As such uart0 is not routed to the outside
on the A13. When not setting CONFIG_DM_SERIAL we are simply using
uart0 as serial console, and that ends at the bonding pads at the
edge of the die. doing things that way is not really useful,
but there is a serial console and u-boot is happy.
In the non devicetree world this sort of was a natural hack, we
simply left CONSOLE_INDEX undefined for these boards, which causes
it to default to 1 / uart0 and things just work. I had never given
this much thought until moving to devicetree.
As you can hopefully understand I do not want to do the samething
with DM_SERIAL builds as that would require hacking up the dts
to add a node for hardware which is effectively disabled for the
A13 package of the sun5i die.
It is possible to mark a
device disabled in device tree - perhaps we should have a way to see
that the console is present (i.e. there is an alias) but it is
disabled?
That seems rather ugly, I really do not want to add an alias to
a non enabled device, that just feels wrong on all levels.
Normally a serial console is required, so I'd like to preserve this
behaviour for most boards.
Ok, I actually expected as much, this was actually my second solution
for the problem at hand, but as it was the simplest solution I decided
to submit this version first. My first / original solution is to add a
CONFIG_DM_SERIAL_NO_PANIC Kconfig option which can then be set on boards
which have no serial port.
Or probably better a CONFIG_DM_SERIAL_NO_SERIAL_CONSOLE option ?
This option would disable the panic / disable probing all together while
we would keep using DM_SERIAL on these boards, because:
1) Consistency I really want to use DM_FOO everywhere for sunxi
2) The non dm serial code cannot handle not having a serial port either,
and fixing it looks like it is going to be a bit harder (from a
quick
glance).
You probably just have not gotten around to this yet, but in case it is
not clear, the above solution (adding a
CONFIG_DM_SERIAL_NO_SERIAL_CONSOLE
Kconfig option) is a suggestion on how to fix. I'll happily implement
this
if people like it, but atm I'm waiting for feedback on the suggestion.
I've been thinking about it. Perhaps an option to allow U-Boot to run
without a console is best. But instead of CONFIG_DM_SERIAL_NO_PANIC,
perhaps we could have CONFIG_REQUIRE_CONSOLE which is normally y.
That works for me, although I would prefer CONFIG_REQUIRE_SERIAL_CONSOLE,
the boards in question do have a console in the form of a cfb console.
SGTM thanks Hans.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: usb-phy: Never power off the usb ports
On Wednesday, July 08, 2015 at 07:49:37 PM, Hans de Goede wrote: Hi, Hi! On 08-07-15 17:02, Marek Vasut wrote: On Wednesday, July 08, 2015 at 04:54:07 PM, Hans de Goede wrote: USB devices are not really designed to get the power bounced off and on at them. Esp. USB powered harddisks do not like this. Currently we power off the USB ports both on a usb reset and when booting the kernel, causing the usb-power to bounce off and then back on again. This patch removes the powering off calls, fixing the undesirable power bouncing. Signed-off-by: Hans de Goede hdego...@redhat.com Shall I pick this through u-boot-usb or would you like this to go through u-boot-sunxi ? Recently, I feel a bit left out :-) Heh, sorry but we've a bunch of other sunxi/usb mixed patches already queued up, so I think it is best if I take this one through the sunxi tree to avoid conflicts. *SULK* !! All righty. Also: Acked-by: Marek Vasut ma...@denx.de 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 03/13] apalis/colibri_t20/t30: integrate recovery mode detection
On 07/07/2015 12:04 AM, Marcel Ziswiler wrote: On 6 July 2015 18:38:21 CEST, Simon Glass s...@chromium.org wrote: Out of interest, is this just a message for the user? Why is it useful? Well, we or customers might do other interesting things on entering rcm like stopping autoboot or automatically start ums. But that's not what this patch does; it simply prints a message. It doesn't seem terribly useful. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] crypto/fsl: clean-up - use fdt_setprop_u32 helper
Signed-off-by: Horia Geantă horia.gea...@freescale.com --- drivers/crypto/fsl/sec.c | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/drivers/crypto/fsl/sec.c b/drivers/crypto/fsl/sec.c index b25b1a4052d2..0940faf768cc 100644 --- a/drivers/crypto/fsl/sec.c +++ b/drivers/crypto/fsl/sec.c @@ -60,27 +60,26 @@ void fdt_fixup_crypto_node(void *blob, int sec_rev) return; } - val = cpu_to_fdt32(sec_rev_prop_list[sec_idx].num_channels); - err = fdt_setprop(blob, crypto_node, fsl,num-channels, val, 4); + err = fdt_setprop_u32(blob, crypto_node, fsl,num-channels, + sec_rev_prop_list[sec_idx].num_channels); if (err 0) printf(WARNING: could not set crypto property: %s\n, fdt_strerror(err)); - val = cpu_to_fdt32(sec_rev_prop_list[sec_idx].descriptor_types_mask); - err = fdt_setprop(blob, crypto_node, fsl,descriptor-types-mask, - val, 4); + err = fdt_setprop_u32(blob, crypto_node, fsl,descriptor-types-mask, + sec_rev_prop_list[sec_idx].descriptor_types_mask); if (err 0) printf(WARNING: could not set crypto property: %s\n, fdt_strerror(err)); - val = cpu_to_fdt32(sec_rev_prop_list[sec_idx].exec_units_mask); - err = fdt_setprop(blob, crypto_node, fsl,exec-units-mask, val, 4); + err = fdt_setprop_u32(blob, crypto_node, fsl,exec-units-mask, + sec_rev_prop_list[sec_idx].exec_units_mask); if (err 0) printf(WARNING: could not set crypto property: %s\n, fdt_strerror(err)); - val = cpu_to_fdt32(sec_rev_prop_list[sec_idx].channel_fifo_len); - err = fdt_setprop(blob, crypto_node, fsl,channel-fifo-len, val, 4); + err = fdt_setprop_u32(blob, crypto_node, fsl,channel-fifo-len, + sec_rev_prop_list[sec_idx].channel_fifo_len); if (err 0) printf(WARNING: could not set crypto property: %s\n, fdt_strerror(err)); -- 2.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] crypto/fsl: fix era property value on LE platforms
Use fdt_setprop_u32() instead of fdt_setprop().
Fixes: 0181937fa371a (crypto/fsl: Add fixup for crypto node)
Signed-off-by: Horia Geantă horia.gea...@freescale.com
Reviewed-by: Mingkai Hu mingkai...@freescale.com
---
drivers/crypto/fsl/sec.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/crypto/fsl/sec.c b/drivers/crypto/fsl/sec.c
index 443ee964feae..b25b1a4052d2 100644
--- a/drivers/crypto/fsl/sec.c
+++ b/drivers/crypto/fsl/sec.c
@@ -155,8 +155,7 @@ static void fdt_fixup_crypto_era(void *blob, u32 era)
return;
}
- err = fdt_setprop(blob, crypto_node, fsl,sec-era, era,
- sizeof(era));
+ err = fdt_setprop_u32(blob, crypto_node, fsl,sec-era, era);
if (err 0) {
printf(ERROR: could not set fsl,sec-era property: %s\n,
fdt_strerror(err));
--
2.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] keystone2: use appropriate HD field for destination port
Hi, Vitaly
I suppose it's better to decide in upper driver how to use swinfo field.
Like in drivers/net/keystone_net.c
The keystone navigator supposed to be used as a tool for communicating
between different IPs, and each of them decide how to use swinfo fields.
It's protocol specific information and should be known only in sending
parts. What if tomorrow you will decide to send some packet to PA?, you
will rewrite this function again?
It's not the place for such kind information.
Even more, this is the h/w specific decision and no need to check this
for each sent packet. You better statically assign how to use this field
depending on h/w revision, using #if.
On 08.07.15 18:45, Vitaly Andrianov wrote:
K2L and L2E have different from K2HK EthSS version, which uses tag_info
field for destination slave port. This commit adds the dest_port_info field
to the struct pktdma_cfg, to configure which HD filed tag_info or pkt_info
shall be used to configure descriptor.
Before that commit the swinfo[2] was used for that purpose. Even if that
worked on K2HK devices, the correct field for K2HK is the pkt_info.
The netcp_send() configure appropriate HD info field depending on the
direct_info of the currently using netcp.
Signed-off-by: Vitaly Andrianov vita...@ti.com
Acked-by: Murali Karicheri m-kariche...@ti.com
---
arch/arm/include/asm/ti-common/keystone_nav.h | 9 -
drivers/dma/keystone_nav.c| 12 ++--
drivers/net/keystone_net.c| 3 +--
3 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/ti-common/keystone_nav.h
b/arch/arm/include/asm/ti-common/keystone_nav.h
index 696d8c6..5a0e391 100644
--- a/arch/arm/include/asm/ti-common/keystone_nav.h
+++ b/arch/arm/include/asm/ti-common/keystone_nav.h
@@ -152,6 +152,11 @@ struct rx_flow_regs {
u32 thresh[3];
};
+enum dest_port_info {
+ PKT_INFO,
+ TAG_INFO
+};
+
struct pktdma_cfg {
struct global_ctl_regs *global;
struct tx_chan_regs *tx_ch;
@@ -167,6 +172,7 @@ struct pktdma_cfg {
u32 tx_snd_q;
u32 rx_flow; /* flow that is used for RX */
+ enum dest_port_info dest_port_info;/* HD fiels for dest port bits */
};
extern struct pktdma_cfg netcp_pktdma;
@@ -184,7 +190,8 @@ struct rx_buff_desc {
int ksnav_close(struct pktdma_cfg *pktdma);
int ksnav_init(struct pktdma_cfg *pktdma, struct rx_buff_desc *rx_buffers);
-int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes, u32
swinfo2);
+int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
+ u32 dest_port);
void *ksnav_recv(struct pktdma_cfg *pktdma, u32 **pkt, int *num_bytes);
void ksnav_release_rxhd(struct pktdma_cfg *pktdma, void *hd);
diff --git a/drivers/dma/keystone_nav.c b/drivers/dma/keystone_nav.c
index dfca75a..64b1cee 100644
--- a/drivers/dma/keystone_nav.c
+++ b/drivers/dma/keystone_nav.c
@@ -278,7 +278,8 @@ int ksnav_close(struct pktdma_cfg *pktdma)
return QM_OK;
}
-int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes, u32 swinfo2)
+int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
+ u32 dest_port)
{
struct qm_host_desc *hd;
@@ -286,8 +287,15 @@ int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int
num_bytes, u32 swinfo2)
if (hd == NULL)
return QM_ERR;
+ dest_port = 0xf;
hd-desc_info= num_bytes;
- hd-swinfo[2]= swinfo2;
+ if (pktdma-dest_port_info == PKT_INFO) {
+ hd-packet_info = qm_cfg-qpool_num | (dest_port 16);
+ } else {
+ hd-packet_info = qm_cfg-qpool_num;
+ hd-tag_info = dest_port;
+ }
+
hd-packet_info = qm_cfg-qpool_num;
qm_buff_push(hd, pktdma-tx_snd_q, pkt, num_bytes);
diff --git a/drivers/net/keystone_net.c b/drivers/net/keystone_net.c
index 0c5fdee..e2adb67 100644
--- a/drivers/net/keystone_net.c
+++ b/drivers/net/keystone_net.c
@@ -381,8 +381,7 @@ int32_t cpmac_drv_send(u32 *buffer, int num_bytes, int
slave_port_num)
if (num_bytes EMAC_MIN_ETHERNET_PKT_SIZE)
num_bytes = EMAC_MIN_ETHERNET_PKT_SIZE;
- return ksnav_send(netcp_pktdma, buffer,
- num_bytes, (slave_port_num) 16);
+ return ksnav_send(netcp_pktdma, buffer, num_bytes, slave_port_num);
}
/* Eth device open */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Eliminate make defconfig warning for Crown Bay and Minnowmax
Hi Bin, On 8 July 2015 at 07:50, Bin Meng bmeng...@gmail.com wrote: Remove duplicated entry of OF_CONTROL in crownbay_defconfig and minnowmax_defconfig which causes a warning when making defconfig. The updated defconfig files are generated by 'make savedefconfig'. Signed-off-by: Bin Meng bmeng...@gmail.com --- configs/crownbay_defconfig | 14 ++ configs/minnowmax_defconfig | 6 ++ 2 files changed, 8 insertions(+), 12 deletions(-) I've incorporated this into the offending patches in x86/master. Please take a look and let me know what you think. I'd rather avoid strange errors in the tree, even tools/genboardscfg.py. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] keystone2: use appropriate HD field for destination port
On 08.07.15 22:22, ivan.khoronzhuk wrote:
Vitaly,
On 08.07.15 21:28, Vitaly Andrianov wrote:
On 07/08/2015 01:50 PM, ivan.khoronzhuk wrote:
Vitaly,
On 08.07.15 20:26, Vitaly Andrianov wrote:
On 07/08/2015 01:05 PM, Ivan Khoronzhuk wrote:
Vitaly,
On 08.07.15 20:05, Vitaly Andrianov wrote:
On 07/08/2015 12:38 PM, Ivan Khoronzhuk wrote:
Hi, Vitaly
I suppose it's better to decide in upper driver how to use swinfo
field.
Like in drivers/net/keystone_net.c
The keystone navigator supposed to be used as a tool for
communicating
between different IPs, and each of them decide how to use swinfo
fields.
It's protocol specific information and should be known only in
sending
parts. What if tomorrow you will decide to send some packet to PA?,
you
will rewrite this function again?
It's not the place for such kind information.
Even more, this is the h/w specific decision and no need to check
this
for each sent packet. You better statically assign how to use this
field
depending on h/w revision, using #if.
On 08.07.15 18:45, Vitaly Andrianov wrote:
K2L and L2E have different from K2HK EthSS version, which uses
tag_info
field for destination slave port. This commit adds the
dest_port_info
field
to the struct pktdma_cfg, to configure which HD filed tag_info or
pkt_info
shall be used to configure descriptor.
Before that commit the swinfo[2] was used for that purpose. Even if
that
worked on K2HK devices, the correct field for K2HK is the pkt_info.
The netcp_send() configure appropriate HD info field depending on
the
direct_info of the currently using netcp.
Signed-off-by: Vitaly Andrianov vita...@ti.com
Acked-by: Murali Karicheri m-kariche...@ti.com
---
arch/arm/include/asm/ti-common/keystone_nav.h | 9 -
drivers/dma/keystone_nav.c| 12 ++--
drivers/net/keystone_net.c| 3 +--
3 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/ti-common/keystone_nav.h
b/arch/arm/include/asm/ti-common/keystone_nav.h
index 696d8c6..5a0e391 100644
--- a/arch/arm/include/asm/ti-common/keystone_nav.h
+++ b/arch/arm/include/asm/ti-common/keystone_nav.h
@@ -152,6 +152,11 @@ struct rx_flow_regs {
u32thresh[3];
};
+enum dest_port_info {
+PKT_INFO,
+TAG_INFO
+};
+
struct pktdma_cfg {
struct global_ctl_regs*global;
struct tx_chan_regs*tx_ch;
@@ -167,6 +172,7 @@ struct pktdma_cfg {
u32tx_snd_q;
u32rx_flow; /* flow that is used for RX */
+enum dest_port_info dest_port_info;/* HD fiels for dest
port
bits */
};
extern struct pktdma_cfg netcp_pktdma;
@@ -184,7 +190,8 @@ struct rx_buff_desc {
int ksnav_close(struct pktdma_cfg *pktdma);
int ksnav_init(struct pktdma_cfg *pktdma, struct rx_buff_desc
*rx_buffers);
-int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
u32 swinfo2);
+int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
+ u32 dest_port);
void *ksnav_recv(struct pktdma_cfg *pktdma, u32 **pkt, int
*num_bytes);
void ksnav_release_rxhd(struct pktdma_cfg *pktdma, void *hd);
diff --git a/drivers/dma/keystone_nav.c
b/drivers/dma/keystone_nav.c
index dfca75a..64b1cee 100644
--- a/drivers/dma/keystone_nav.c
+++ b/drivers/dma/keystone_nav.c
@@ -278,7 +278,8 @@ int ksnav_close(struct pktdma_cfg *pktdma)
return QM_OK;
}
-int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
u32 swinfo2)
+int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
+ u32 dest_port)
{
struct qm_host_desc *hd;
@@ -286,8 +287,15 @@ int ksnav_send(struct pktdma_cfg *pktdma, u32
*pkt, int num_bytes, u32 swinfo2)
if (hd == NULL)
return QM_ERR;
+dest_port = 0xf;
hd-desc_info= num_bytes;
-hd-swinfo[2]= swinfo2;
+if (pktdma-dest_port_info == PKT_INFO) {
+hd-packet_info= qm_cfg-qpool_num | (dest_port
16);
+} else {
+hd-packet_info = qm_cfg-qpool_num;
+hd-tag_info = dest_port;
+}
+
hd-packet_info = qm_cfg-qpool_num;
qm_buff_push(hd, pktdma-tx_snd_q, pkt, num_bytes);
diff --git a/drivers/net/keystone_net.c
b/drivers/net/keystone_net.c
index 0c5fdee..e2adb67 100644
--- a/drivers/net/keystone_net.c
+++ b/drivers/net/keystone_net.c
@@ -381,8 +381,7 @@ int32_t cpmac_drv_send(u32 *buffer, int
num_bytes,
int slave_port_num)
if (num_bytes EMAC_MIN_ETHERNET_PKT_SIZE)
num_bytes = EMAC_MIN_ETHERNET_PKT_SIZE;
-return ksnav_send(netcp_pktdma, buffer,
- num_bytes, (slave_port_num) 16);
+return ksnav_send(netcp_pktdma, buffer, num_bytes,
slave_port_num);
}
/* Eth device open */
Hi Ivan,
I agree with you. And probably we will need to implement your
proposal
in future commits. This commit is to fix the bug, which is in
existing
driver.
Thanks,
Vitaly
Sorry, I supposed that first msg was not sent.
It's better to fix it in drivers/net/keystone_net.c
Ivan,
Re: [U-Boot] [PATCH 01/20] dm: net: Support usbethaddr environment variable
Hi Joe, On 8 July 2015 at 14:43, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Simon, On Wed, Jul 8, 2015 at 3:31 PM, Simon Glass s...@chromium.org wrote: +Hans Hi Joe, On 7 July 2015 at 22:04, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Simon, On Tue, Jul 7, 2015 at 9:53 PM, Simon Glass s...@chromium.org wrote: For USB Ethernet devices we need to use the usbethaddr environment variable (instead of ethaddr) the Ethernet hardware address. Add this to the uclass so that it happens automatically. I have always thought that this approach of having a separate prefix for usbethaddr was a smelly hack. Are we sure we want to propagate it here? Can we not just use dev-seq? It should already be unique in the DM, right? I was really looking forward to that all going away. Ah, OK, sorry. Do you think we need a way of specifying the eth interface # as we do with aliases at present? We did have one but Han has just removed it :-) Can you reference where this happened. A quick search didn't turn it up for me. Otherwise we'll just end up counting up from the last 'fixed' ethernet interface. Maybe that is good enough. That's probably good enough, but some may prefer more explicit control. The thread is here: http://patchwork.ozlabs.org/patch/485637/ Before, we could I think add USB devices to the device tree and give them a specific number (although I never actually tested it), but that won't work now. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] dfu: Delete superfluous initialization of the dfu_buf_size static variable
After extension of the dfu_get_buf() to also setup (implicitly) the dfu_buf_size
variable it is not needed to set dfu_buf_size to CONFIG_SYS_DFU_DATA_BUF_SIZE.
This variable is set in the dfu_get_buf() by not only considering
CONFIG_SYS_DFU_DATA_BUF but more importantly the dfu_bufsiz env variable.
Therefore, dfu_get_buf() should be used for initialization.
Signed-off-by: Lukasz Majewski l.majew...@majess.pl
---
drivers/dfu/dfu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 0560afa..332be67 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -76,7 +76,7 @@ int dfu_init_env_entities(char *interface, char *devstr)
}
static unsigned char *dfu_buf;
-static unsigned long dfu_buf_size = CONFIG_SYS_DFU_DATA_BUF_SIZE;
+static unsigned long dfu_buf_size;
unsigned char *dfu_free_buf(void)
{
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] keystone2: use appropriate HD field for destination port
Hi, Vitaly
I suppose it's better to decide in upper driver how to use swinfo field.
Like in drivers/net/keystone_net.c
The keystone navigator supposed to be used as a tool for communicating
between different IPs, and each of them decide how to use swinfo fields.
It's protocol specific information and should be known only for sending
parts. What if tomorrow will be decided to send some packet to PA?,
rewrite this function again?
It's not the place for such kind information.
This is the h/w specific static decision and no need to check this
for each sent packet. It be better to statically assign how to use this
field depending on h/w revision, using macro configs, for instance:
CONFIG_SOC_K2HK
CONFIG_KSNET_NETCP_V1_0
CONFIG_KSNET_NETCP_V1_5
On 08.07.15 18:45, Vitaly Andrianov wrote:
K2L and L2E have different from K2HK EthSS version, which uses tag_info
field for destination slave port. This commit adds the dest_port_info field
to the struct pktdma_cfg, to configure which HD filed tag_info or pkt_info
shall be used to configure descriptor.
Before that commit the swinfo[2] was used for that purpose. Even if that
worked on K2HK devices, the correct field for K2HK is the pkt_info.
The netcp_send() configure appropriate HD info field depending on the
direct_info of the currently using netcp.
Signed-off-by: Vitaly Andrianov vita...@ti.com
Acked-by: Murali Karicheri m-kariche...@ti.com
---
arch/arm/include/asm/ti-common/keystone_nav.h | 9 -
drivers/dma/keystone_nav.c| 12 ++--
drivers/net/keystone_net.c| 3 +--
3 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/ti-common/keystone_nav.h
b/arch/arm/include/asm/ti-common/keystone_nav.h
index 696d8c6..5a0e391 100644
--- a/arch/arm/include/asm/ti-common/keystone_nav.h
+++ b/arch/arm/include/asm/ti-common/keystone_nav.h
@@ -152,6 +152,11 @@ struct rx_flow_regs {
u32 thresh[3];
};
+enum dest_port_info {
+ PKT_INFO,
+ TAG_INFO
+};
+
struct pktdma_cfg {
struct global_ctl_regs *global;
struct tx_chan_regs *tx_ch;
@@ -167,6 +172,7 @@ struct pktdma_cfg {
u32 tx_snd_q;
u32 rx_flow; /* flow that is used for RX */
+ enum dest_port_info dest_port_info;/* HD fiels for dest port bits */
};
extern struct pktdma_cfg netcp_pktdma;
@@ -184,7 +190,8 @@ struct rx_buff_desc {
int ksnav_close(struct pktdma_cfg *pktdma);
int ksnav_init(struct pktdma_cfg *pktdma, struct rx_buff_desc *rx_buffers);
-int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes, u32
swinfo2);
+int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
+ u32 dest_port);
void *ksnav_recv(struct pktdma_cfg *pktdma, u32 **pkt, int *num_bytes);
void ksnav_release_rxhd(struct pktdma_cfg *pktdma, void *hd);
diff --git a/drivers/dma/keystone_nav.c b/drivers/dma/keystone_nav.c
index dfca75a..64b1cee 100644
--- a/drivers/dma/keystone_nav.c
+++ b/drivers/dma/keystone_nav.c
@@ -278,7 +278,8 @@ int ksnav_close(struct pktdma_cfg *pktdma)
return QM_OK;
}
-int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes, u32 swinfo2)
+int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
+ u32 dest_port)
{
struct qm_host_desc *hd;
@@ -286,8 +287,15 @@ int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int
num_bytes, u32 swinfo2)
if (hd == NULL)
return QM_ERR;
+ dest_port = 0xf;
hd-desc_info= num_bytes;
- hd-swinfo[2]= swinfo2;
+ if (pktdma-dest_port_info == PKT_INFO) {
+ hd-packet_info = qm_cfg-qpool_num | (dest_port 16);
+ } else {
+ hd-packet_info = qm_cfg-qpool_num;
+ hd-tag_info = dest_port;
+ }
+
hd-packet_info = qm_cfg-qpool_num;
qm_buff_push(hd, pktdma-tx_snd_q, pkt, num_bytes);
diff --git a/drivers/net/keystone_net.c b/drivers/net/keystone_net.c
index 0c5fdee..e2adb67 100644
--- a/drivers/net/keystone_net.c
+++ b/drivers/net/keystone_net.c
@@ -381,8 +381,7 @@ int32_t cpmac_drv_send(u32 *buffer, int num_bytes, int
slave_port_num)
if (num_bytes EMAC_MIN_ETHERNET_PKT_SIZE)
num_bytes = EMAC_MIN_ETHERNET_PKT_SIZE;
- return ksnav_send(netcp_pktdma, buffer,
- num_bytes, (slave_port_num) 16);
+ return ksnav_send(netcp_pktdma, buffer, num_bytes, slave_port_num);
}
/* Eth device open */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] keystone2: use appropriate HD field for destination port
Vitaly,
On 08.07.15 20:05, Vitaly Andrianov wrote:
On 07/08/2015 12:38 PM, Ivan Khoronzhuk wrote:
Hi, Vitaly
I suppose it's better to decide in upper driver how to use swinfo field.
Like in drivers/net/keystone_net.c
The keystone navigator supposed to be used as a tool for communicating
between different IPs, and each of them decide how to use swinfo fields.
It's protocol specific information and should be known only in sending
parts. What if tomorrow you will decide to send some packet to PA?, you
will rewrite this function again?
It's not the place for such kind information.
Even more, this is the h/w specific decision and no need to check this
for each sent packet. You better statically assign how to use this field
depending on h/w revision, using #if.
On 08.07.15 18:45, Vitaly Andrianov wrote:
K2L and L2E have different from K2HK EthSS version, which uses tag_info
field for destination slave port. This commit adds the dest_port_info
field
to the struct pktdma_cfg, to configure which HD filed tag_info or
pkt_info
shall be used to configure descriptor.
Before that commit the swinfo[2] was used for that purpose. Even if that
worked on K2HK devices, the correct field for K2HK is the pkt_info.
The netcp_send() configure appropriate HD info field depending on the
direct_info of the currently using netcp.
Signed-off-by: Vitaly Andrianov vita...@ti.com
Acked-by: Murali Karicheri m-kariche...@ti.com
---
arch/arm/include/asm/ti-common/keystone_nav.h | 9 -
drivers/dma/keystone_nav.c| 12 ++--
drivers/net/keystone_net.c| 3 +--
3 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/ti-common/keystone_nav.h
b/arch/arm/include/asm/ti-common/keystone_nav.h
index 696d8c6..5a0e391 100644
--- a/arch/arm/include/asm/ti-common/keystone_nav.h
+++ b/arch/arm/include/asm/ti-common/keystone_nav.h
@@ -152,6 +152,11 @@ struct rx_flow_regs {
u32thresh[3];
};
+enum dest_port_info {
+PKT_INFO,
+TAG_INFO
+};
+
struct pktdma_cfg {
struct global_ctl_regs*global;
struct tx_chan_regs*tx_ch;
@@ -167,6 +172,7 @@ struct pktdma_cfg {
u32tx_snd_q;
u32rx_flow; /* flow that is used for RX */
+enum dest_port_info dest_port_info;/* HD fiels for dest port
bits */
};
extern struct pktdma_cfg netcp_pktdma;
@@ -184,7 +190,8 @@ struct rx_buff_desc {
int ksnav_close(struct pktdma_cfg *pktdma);
int ksnav_init(struct pktdma_cfg *pktdma, struct rx_buff_desc
*rx_buffers);
-int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
u32 swinfo2);
+int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
+ u32 dest_port);
void *ksnav_recv(struct pktdma_cfg *pktdma, u32 **pkt, int
*num_bytes);
void ksnav_release_rxhd(struct pktdma_cfg *pktdma, void *hd);
diff --git a/drivers/dma/keystone_nav.c b/drivers/dma/keystone_nav.c
index dfca75a..64b1cee 100644
--- a/drivers/dma/keystone_nav.c
+++ b/drivers/dma/keystone_nav.c
@@ -278,7 +278,8 @@ int ksnav_close(struct pktdma_cfg *pktdma)
return QM_OK;
}
-int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
u32 swinfo2)
+int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
+ u32 dest_port)
{
struct qm_host_desc *hd;
@@ -286,8 +287,15 @@ int ksnav_send(struct pktdma_cfg *pktdma, u32
*pkt, int num_bytes, u32 swinfo2)
if (hd == NULL)
return QM_ERR;
+dest_port = 0xf;
hd-desc_info= num_bytes;
-hd-swinfo[2]= swinfo2;
+if (pktdma-dest_port_info == PKT_INFO) {
+hd-packet_info= qm_cfg-qpool_num | (dest_port 16);
+} else {
+hd-packet_info = qm_cfg-qpool_num;
+hd-tag_info = dest_port;
+}
+
hd-packet_info = qm_cfg-qpool_num;
qm_buff_push(hd, pktdma-tx_snd_q, pkt, num_bytes);
diff --git a/drivers/net/keystone_net.c b/drivers/net/keystone_net.c
index 0c5fdee..e2adb67 100644
--- a/drivers/net/keystone_net.c
+++ b/drivers/net/keystone_net.c
@@ -381,8 +381,7 @@ int32_t cpmac_drv_send(u32 *buffer, int num_bytes,
int slave_port_num)
if (num_bytes EMAC_MIN_ETHERNET_PKT_SIZE)
num_bytes = EMAC_MIN_ETHERNET_PKT_SIZE;
-return ksnav_send(netcp_pktdma, buffer,
- num_bytes, (slave_port_num) 16);
+return ksnav_send(netcp_pktdma, buffer, num_bytes,
slave_port_num);
}
/* Eth device open */
Hi Ivan,
I agree with you. And probably we will need to implement your proposal
in future commits. This commit is to fix the bug, which is in existing
driver.
Thanks,
Vitaly
Sorry, I supposed that first msg was not sent.
It's better to fix it in drivers/net/keystone_net.c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] keystone2: use appropriate HD field for destination port
Vitaly,
On 08.07.15 21:28, Vitaly Andrianov wrote:
On 07/08/2015 01:50 PM, ivan.khoronzhuk wrote:
Vitaly,
On 08.07.15 20:26, Vitaly Andrianov wrote:
On 07/08/2015 01:05 PM, Ivan Khoronzhuk wrote:
Vitaly,
On 08.07.15 20:05, Vitaly Andrianov wrote:
On 07/08/2015 12:38 PM, Ivan Khoronzhuk wrote:
Hi, Vitaly
I suppose it's better to decide in upper driver how to use swinfo
field.
Like in drivers/net/keystone_net.c
The keystone navigator supposed to be used as a tool for
communicating
between different IPs, and each of them decide how to use swinfo
fields.
It's protocol specific information and should be known only in
sending
parts. What if tomorrow you will decide to send some packet to PA?,
you
will rewrite this function again?
It's not the place for such kind information.
Even more, this is the h/w specific decision and no need to check
this
for each sent packet. You better statically assign how to use this
field
depending on h/w revision, using #if.
On 08.07.15 18:45, Vitaly Andrianov wrote:
K2L and L2E have different from K2HK EthSS version, which uses
tag_info
field for destination slave port. This commit adds the
dest_port_info
field
to the struct pktdma_cfg, to configure which HD filed tag_info or
pkt_info
shall be used to configure descriptor.
Before that commit the swinfo[2] was used for that purpose. Even if
that
worked on K2HK devices, the correct field for K2HK is the pkt_info.
The netcp_send() configure appropriate HD info field depending on
the
direct_info of the currently using netcp.
Signed-off-by: Vitaly Andrianov vita...@ti.com
Acked-by: Murali Karicheri m-kariche...@ti.com
---
arch/arm/include/asm/ti-common/keystone_nav.h | 9 -
drivers/dma/keystone_nav.c| 12 ++--
drivers/net/keystone_net.c| 3 +--
3 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/ti-common/keystone_nav.h
b/arch/arm/include/asm/ti-common/keystone_nav.h
index 696d8c6..5a0e391 100644
--- a/arch/arm/include/asm/ti-common/keystone_nav.h
+++ b/arch/arm/include/asm/ti-common/keystone_nav.h
@@ -152,6 +152,11 @@ struct rx_flow_regs {
u32thresh[3];
};
+enum dest_port_info {
+PKT_INFO,
+TAG_INFO
+};
+
struct pktdma_cfg {
struct global_ctl_regs*global;
struct tx_chan_regs*tx_ch;
@@ -167,6 +172,7 @@ struct pktdma_cfg {
u32tx_snd_q;
u32rx_flow; /* flow that is used for RX */
+enum dest_port_info dest_port_info;/* HD fiels for dest
port
bits */
};
extern struct pktdma_cfg netcp_pktdma;
@@ -184,7 +190,8 @@ struct rx_buff_desc {
int ksnav_close(struct pktdma_cfg *pktdma);
int ksnav_init(struct pktdma_cfg *pktdma, struct rx_buff_desc
*rx_buffers);
-int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
u32 swinfo2);
+int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
+ u32 dest_port);
void *ksnav_recv(struct pktdma_cfg *pktdma, u32 **pkt, int
*num_bytes);
void ksnav_release_rxhd(struct pktdma_cfg *pktdma, void *hd);
diff --git a/drivers/dma/keystone_nav.c b/drivers/dma/keystone_nav.c
index dfca75a..64b1cee 100644
--- a/drivers/dma/keystone_nav.c
+++ b/drivers/dma/keystone_nav.c
@@ -278,7 +278,8 @@ int ksnav_close(struct pktdma_cfg *pktdma)
return QM_OK;
}
-int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
u32 swinfo2)
+int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
+ u32 dest_port)
{
struct qm_host_desc *hd;
@@ -286,8 +287,15 @@ int ksnav_send(struct pktdma_cfg *pktdma, u32
*pkt, int num_bytes, u32 swinfo2)
if (hd == NULL)
return QM_ERR;
+dest_port = 0xf;
hd-desc_info= num_bytes;
-hd-swinfo[2]= swinfo2;
+if (pktdma-dest_port_info == PKT_INFO) {
+hd-packet_info= qm_cfg-qpool_num | (dest_port 16);
+} else {
+hd-packet_info = qm_cfg-qpool_num;
+hd-tag_info = dest_port;
+}
+
hd-packet_info = qm_cfg-qpool_num;
qm_buff_push(hd, pktdma-tx_snd_q, pkt, num_bytes);
diff --git a/drivers/net/keystone_net.c b/drivers/net/keystone_net.c
index 0c5fdee..e2adb67 100644
--- a/drivers/net/keystone_net.c
+++ b/drivers/net/keystone_net.c
@@ -381,8 +381,7 @@ int32_t cpmac_drv_send(u32 *buffer, int
num_bytes,
int slave_port_num)
if (num_bytes EMAC_MIN_ETHERNET_PKT_SIZE)
num_bytes = EMAC_MIN_ETHERNET_PKT_SIZE;
-return ksnav_send(netcp_pktdma, buffer,
- num_bytes, (slave_port_num) 16);
+return ksnav_send(netcp_pktdma, buffer, num_bytes,
slave_port_num);
}
/* Eth device open */
Hi Ivan,
I agree with you. And probably we will need to implement your proposal
in future commits. This commit is to fix the bug, which is in existing
driver.
Thanks,
Vitaly
Sorry, I supposed that first msg was not sent.
It's better to fix it in drivers/net/keystone_net.c
Ivan,
I don't understand your proposal. The network
Re: [U-Boot] [PATCH] keystone2: use appropriate HD field for destination port
Vitaly,
On 08.07.15 20:26, Vitaly Andrianov wrote:
On 07/08/2015 01:05 PM, Ivan Khoronzhuk wrote:
Vitaly,
On 08.07.15 20:05, Vitaly Andrianov wrote:
On 07/08/2015 12:38 PM, Ivan Khoronzhuk wrote:
Hi, Vitaly
I suppose it's better to decide in upper driver how to use swinfo
field.
Like in drivers/net/keystone_net.c
The keystone navigator supposed to be used as a tool for communicating
between different IPs, and each of them decide how to use swinfo
fields.
It's protocol specific information and should be known only in sending
parts. What if tomorrow you will decide to send some packet to PA?, you
will rewrite this function again?
It's not the place for such kind information.
Even more, this is the h/w specific decision and no need to check this
for each sent packet. You better statically assign how to use this
field
depending on h/w revision, using #if.
On 08.07.15 18:45, Vitaly Andrianov wrote:
K2L and L2E have different from K2HK EthSS version, which uses
tag_info
field for destination slave port. This commit adds the dest_port_info
field
to the struct pktdma_cfg, to configure which HD filed tag_info or
pkt_info
shall be used to configure descriptor.
Before that commit the swinfo[2] was used for that purpose. Even if
that
worked on K2HK devices, the correct field for K2HK is the pkt_info.
The netcp_send() configure appropriate HD info field depending on the
direct_info of the currently using netcp.
Signed-off-by: Vitaly Andrianov vita...@ti.com
Acked-by: Murali Karicheri m-kariche...@ti.com
---
arch/arm/include/asm/ti-common/keystone_nav.h | 9 -
drivers/dma/keystone_nav.c| 12 ++--
drivers/net/keystone_net.c| 3 +--
3 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/ti-common/keystone_nav.h
b/arch/arm/include/asm/ti-common/keystone_nav.h
index 696d8c6..5a0e391 100644
--- a/arch/arm/include/asm/ti-common/keystone_nav.h
+++ b/arch/arm/include/asm/ti-common/keystone_nav.h
@@ -152,6 +152,11 @@ struct rx_flow_regs {
u32thresh[3];
};
+enum dest_port_info {
+PKT_INFO,
+TAG_INFO
+};
+
struct pktdma_cfg {
struct global_ctl_regs*global;
struct tx_chan_regs*tx_ch;
@@ -167,6 +172,7 @@ struct pktdma_cfg {
u32tx_snd_q;
u32rx_flow; /* flow that is used for RX */
+enum dest_port_info dest_port_info;/* HD fiels for dest port
bits */
};
extern struct pktdma_cfg netcp_pktdma;
@@ -184,7 +190,8 @@ struct rx_buff_desc {
int ksnav_close(struct pktdma_cfg *pktdma);
int ksnav_init(struct pktdma_cfg *pktdma, struct rx_buff_desc
*rx_buffers);
-int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
u32 swinfo2);
+int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
+ u32 dest_port);
void *ksnav_recv(struct pktdma_cfg *pktdma, u32 **pkt, int
*num_bytes);
void ksnav_release_rxhd(struct pktdma_cfg *pktdma, void *hd);
diff --git a/drivers/dma/keystone_nav.c b/drivers/dma/keystone_nav.c
index dfca75a..64b1cee 100644
--- a/drivers/dma/keystone_nav.c
+++ b/drivers/dma/keystone_nav.c
@@ -278,7 +278,8 @@ int ksnav_close(struct pktdma_cfg *pktdma)
return QM_OK;
}
-int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
u32 swinfo2)
+int ksnav_send(struct pktdma_cfg *pktdma, u32 *pkt, int num_bytes,
+ u32 dest_port)
{
struct qm_host_desc *hd;
@@ -286,8 +287,15 @@ int ksnav_send(struct pktdma_cfg *pktdma, u32
*pkt, int num_bytes, u32 swinfo2)
if (hd == NULL)
return QM_ERR;
+dest_port = 0xf;
hd-desc_info= num_bytes;
-hd-swinfo[2]= swinfo2;
+if (pktdma-dest_port_info == PKT_INFO) {
+hd-packet_info= qm_cfg-qpool_num | (dest_port 16);
+} else {
+hd-packet_info = qm_cfg-qpool_num;
+hd-tag_info = dest_port;
+}
+
hd-packet_info = qm_cfg-qpool_num;
qm_buff_push(hd, pktdma-tx_snd_q, pkt, num_bytes);
diff --git a/drivers/net/keystone_net.c b/drivers/net/keystone_net.c
index 0c5fdee..e2adb67 100644
--- a/drivers/net/keystone_net.c
+++ b/drivers/net/keystone_net.c
@@ -381,8 +381,7 @@ int32_t cpmac_drv_send(u32 *buffer, int num_bytes,
int slave_port_num)
if (num_bytes EMAC_MIN_ETHERNET_PKT_SIZE)
num_bytes = EMAC_MIN_ETHERNET_PKT_SIZE;
-return ksnav_send(netcp_pktdma, buffer,
- num_bytes, (slave_port_num) 16);
+return ksnav_send(netcp_pktdma, buffer, num_bytes,
slave_port_num);
}
/* Eth device open */
Hi Ivan,
I agree with you. And probably we will need to implement your proposal
in future commits. This commit is to fix the bug, which is in existing
driver.
Thanks,
Vitaly
Sorry, I supposed that first msg was not sent.
It's better to fix it in drivers/net/keystone_net.c
Ivan,
I don't understand your proposal. The network driver doesn't know
anything about CPPI DMA engine internals. That is the navigator's job to
fill
Re: [U-Boot] [PATCH v3 17/25] rockchip: rk3288: Add pinctrl driver
Hi Masahiro,
On 8 July 2015 at 03:35, Masahiro Yamada yamada.masah...@socionext.com wrote:
Hi Simon,
2015-07-07 2:32 GMT+09:00 Simon Glass s...@chromium.org:
Hi Masahiro,
On 6 July 2015 at 11:24, Masahiro Yamada yamada.masah...@socionext.com
wrote:
Hi Simon,
2015-06-24 8:29 GMT+09:00 Simon Glass s...@chromium.org:
+
+static int rk3288_pinctrl_get_periph_id(struct udevice *dev,
+ struct udevice *periph)
+{
+ u32 cell[3];
+ int ret;
+
+ ret = fdtdec_get_int_array(gd-fdt_blob, periph-of_offset,
+ interrupts, cell, ARRAY_SIZE(cell));
+ if (ret 0)
+ return -EINVAL;
+
+ switch (cell[1]) {
+ case 44:
+ return PERIPH_ID_SPI0;
+ case 45:
+ return PERIPH_ID_SPI1;
+ case 46:
+ return PERIPH_ID_SPI2;
+ case 60:
+ return PERIPH_ID_I2C0;
+ case 62: /* Note strange order */
+ return PERIPH_ID_I2C1;
+ case 61:
+ return PERIPH_ID_I2C2;
+ case 63:
+ return PERIPH_ID_I2C3;
+ case 64:
+ return PERIPH_ID_I2C4;
+ case 65:
+ return PERIPH_ID_I2C5;
+ }
+
+ return -ENOENT;
+}
Weird.
Do you parse the interrupts property
to identify the peripheral?
This is what I really do not like to do.
Yes. It's similar to a clock number. It doesn't really matter what we
use. The interrupt number is a fixed part of the binding and will
never change.
I guess it is abuse of interrupts property.
Moreover, it can not cover cases where a single signal can be routed to
several pins.
This is code that is specific to RK3288. The numbering scheme is
completely arbitrary and is local to that one function. If we wanted
to use a different scheme (now or later) it would just involve
changing that one function.
Other SoCs may have other rules.
For example, say we want to set pinmux for the I2C channel 0 (SDA0 and SCL0).
On some vendors' SoCs, it is possible to connect SDA0 to either pin10
or pin20 for example.
Likewise, SCL0 can be connected to pin11 or pin21.
(Yes, it is possible on my SoCs)
The interrupt ID can identify it is I2C0, and that's it.
Some boards expect the signals come out of pin10, 11,
and other boards pin20, 21.
The interrupt ID cannot distinguish those cases; the pinctrl-*
property can do it.
The interrupt ID is just a way of determining the peripheral. The
actual pinmux setting for that peripheral is handled by the flags
parameter.
This is mentioned in Documentation/pinctrl.txt and
that is why a single function can have multiple pin-groups in Linux's
pinctrl drivers.
I think this design cannot meet some vendors' demand.
At least, I am unhappy with it.
Could you hold your pinctrl patches and give me time to discuss a bit
more, please?
I understand how pinctrl drivers work in Linux, so please give me some time
to consider if better design might be possible.
It is clear that we are heading towards a more general pinmux scheme,
and I can imagine us implementing the pinctrl for some SoCs.
The current proposal is a step towards that but is considerably
simpler. I am familiar with pinctrl but decided against a full
implementation for U-Boot as I feel it is overkill and would not
attract substantial SoC support.
There is no hurry with applying these patches. Let me know what you figure out.
Regards,
Simon
--
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 1/3] dm: dts: ls2085a: Bring in ls2085a dts files from linux kernel
On 6/26/2015 7:53 PM, Haikun Wang wrote:
From: Haikun Wang haikun.w...@freescale.com
Bring in required device tree files for ls2085a from Linux.
These are initially unchanged and have a number of pieces not needed by
U-Boot.
Hi Simon,
I got below comment when review this patch internal.
Please help me confirm.
For new platforms like ARM64, it was discussed to not duplicate the DTS
in u-boot and Linux, simply because that will break compatibility with
other bootloaders like Linaro's BootMonitor and UEFI bootloader, which
do not place the DTS in the bootloader. Also in near future, with DTS
being replaced by ACPI gradually for ARM64 platforms, it was discussed
that in a longer run it would be beneficial to move DTS out of both
u-boot and Linux and maintain it as a separate tree.
Best regards,
Wang Haikun
Signed-off-by: Haikun Wang haikun.w...@freescale.com
---
arch/arm/dts/fsl-ls2085a.dtsi | 120
++
1 file changed, 120 insertions(+)
create mode 100644 arch/arm/dts/fsl-ls2085a.dtsi
diff --git a/arch/arm/dts/fsl-ls2085a.dtsi b/arch/arm/dts/fsl-ls2085a.dtsi
new file mode 100644
index 000..f0679a8
--- /dev/null
+++ b/arch/arm/dts/fsl-ls2085a.dtsi
@@ -0,0 +1,120 @@
+/*
+ * Freescale ls2085a SOC common device tree source
+ *
+ * Copyright 2013-2015 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+/ {
+ compatible = fsl,ls2085a;
+ interrupt-parent = gic;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ cpus {
+ #address-cells = 2;
+ #size-cells = 0;
+
+ /*
+ * We expect the enable-method for cpu's to be psci, but this
+ * is dependent on the SoC FW, which will fill this in.
+ *
+ * Currently supported enable-method is psci v0.2
+ */
+
+ /* We have 4 clusters having 2 Cortex-A57 cores each */
+ cpu@0 {
+ device_type = cpu;
+ compatible = arm,cortex-a57;
+ reg = 0x0 0x0;
+ };
+
+ cpu@1 {
+ device_type = cpu;
+ compatible = arm,cortex-a57;
+ reg = 0x0 0x1;
+ };
+
+ cpu@100 {
+ device_type = cpu;
+ compatible = arm,cortex-a57;
+ reg = 0x0 0x100;
+ };
+
+ cpu@101 {
+ device_type = cpu;
+ compatible = arm,cortex-a57;
+ reg = 0x0 0x101;
+ };
+
+ cpu@200 {
+ device_type = cpu;
+ compatible = arm,cortex-a57;
+ reg = 0x0 0x200;
+ };
+
+ cpu@201 {
+ device_type = cpu;
+ compatible = arm,cortex-a57;
+ reg = 0x0 0x201;
+ };
+
+ cpu@300 {
+ device_type = cpu;
+ compatible = arm,cortex-a57;
+ reg = 0x0 0x300;
+ };
+
+ cpu@301 {
+ device_type = cpu;
+ compatible = arm,cortex-a57;
+ reg = 0x0 0x301;
+ };
+ };
+
+ memory@8000 {
+ device_type = memory;
+ reg = 0x 0x8000 0 0x8000;
+ /* DRAM space - 1, size : 2 GB DRAM */
+ };
+
+ gic: interrupt-controller@600 {
+ compatible = arm,gic-v3;
+ reg = 0x0 0x0600 0 0x1, /* GIC Dist */
+ 0x0 0x0610 0 0x10; /* GICR (RD_base + SGI_base)
*/
+ #interrupt-cells = 3;
+ interrupt-controller;
+ interrupts = 1 9 0x4;
+ };
+
+ timer {
+ compatible = arm,armv8-timer;
+ interrupts = 1 13 0x8, /* Physical Secure PPI, active-low */
+ 1 14 0x8, /* Physical Non-Secure PPI, active-low
*/
+ 1 11 0x8, /* Virtual PPI, active-low */
+ 1 10 0x8; /* Hypervisor PPI, active-low */
+ };
+
+ serial0: serial@21c0500 {
+ device_type = serial;
+ compatible = fsl,ns16550, ns16550a;
+ reg = 0x0 0x21c0500 0x0 0x100;
+ clock-frequency = 0; /* Updated by bootloader */
+ interrupts = 0 32 0x1; /* edge triggered */
+ };
+
+ serial1: serial@21c0600 {
+ device_type = serial;
+ compatible = fsl,ns16550, ns16550a;
+ reg = 0x0 0x21c0600 0x0 0x100;
+ clock-frequency = 0; /* Updated by bootloader */
+ interrupts = 0 32 0x1; /* edge triggered */
+ };
+
+ fsl_mc: fsl-mc@80c00 {
+
Re: [U-Boot] [PATCH 1/3] dm: dts: ls2085a: Bring in ls2085a dts files from linux kernel
Hi, On Wed, Jul 8, 2015 at 2:51 PM, Wang Haikun haikun.w...@freescale.com wrote: On 6/26/2015 7:53 PM, Haikun Wang wrote: From: Haikun Wang haikun.w...@freescale.com Bring in required device tree files for ls2085a from Linux. These are initially unchanged and have a number of pieces not needed by U-Boot. Hi Simon, I got below comment when review this patch internal. Please help me confirm. For new platforms like ARM64, it was discussed to not duplicate the DTS in u-boot and Linux, simply because that will break compatibility with other bootloaders like Linaro's BootMonitor and UEFI bootloader, which do not place the DTS in the bootloader. Also in near future, with DTS being replaced by ACPI gradually for ARM64 platforms, it was discussed that in a longer run it would be beneficial to move DTS out of both u-boot and Linux and maintain it as a separate tree. I think UEFI + ACPI is only required for ARMv8 servers, not for all ARMv8 processors. Is ls2085a a processor targeting the server market? [snip] Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] dm: dts: ls2085a: Bring in ls2085a dts files from linux kernel
On 7/8/2015 3:13 PM, Bin Meng wrote: Hi, On Wed, Jul 8, 2015 at 2:51 PM, Wang Haikun haikun.w...@freescale.com wrote: On 6/26/2015 7:53 PM, Haikun Wang wrote: From: Haikun Wang haikun.w...@freescale.com Bring in required device tree files for ls2085a from Linux. These are initially unchanged and have a number of pieces not needed by U-Boot. Hi Simon, I got below comment when review this patch internal. Please help me confirm. For new platforms like ARM64, it was discussed to not duplicate the DTS in u-boot and Linux, simply because that will break compatibility with other bootloaders like Linaro's BootMonitor and UEFI bootloader, which do not place the DTS in the bootloader. Also in near future, with DTS being replaced by ACPI gradually for ARM64 platforms, it was discussed that in a longer run it would be beneficial to move DTS out of both u-boot and Linux and maintain it as a separate tree. I think UEFI + ACPI is only required for ARMv8 servers, not for all ARMv8 processors. Is ls2085a a processor targeting the server market? No, at least it's not our major market. I want to know whether we have made a conclusion that u-boot will not add Arm64 dts files? Best regards, Wang Haikun [snip] Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] net: asix: fix operation without eeprom
Hi Joe On 8 July 2015 05:55:28 CEST, Joe Hershberger joe.hershber...@gmail.com wrote: Definitely use checkpatch.pl on this series. Yeah, it's been late and I somehow forgot about it. I already run v2 about to be posted through it now. I recommend patman. So far I have not used that one yet but thanks for the tip. I'm guessing this is ported from the ASIX Linux driver. Perhaps mention in the log where it came from. As mentioned in the log it actually came from Antmicro who did an initial port way back 2011. Please don't use magic numbers. I already got rid of this in v2. Also, ideally don't create PID hacks. Understood, unfortunately I don't know what the effect of this on other ASIX variants is. Is this always needed or is it only helpful to your device? Good question which posting it here I hoped to get some more feedback about. Cheers Marcel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] arm: baltos: enable CMD_NET and FIT support in defconfig
On Wed, Jul 8, 2015 at 12:54 AM, Simon Glass s...@chromium.org wrote:
On 6 July 2015 at 09:28, Yegor Yefremov yegorsli...@googlemail.com wrote:
Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
---
configs/am335x_baltos_defconfig | 4 ++--
include/configs/baltos.h| 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
Reviewed-by: Simon Glass s...@chromium.org
But please remember to add a commit message with your patches.
Thanks. Will do.
Yegor
diff --git a/configs/am335x_baltos_defconfig
b/configs/am335x_baltos_defconfig
index bf73919..8e8a897 100644
--- a/configs/am335x_baltos_defconfig
+++ b/configs/am335x_baltos_defconfig
@@ -3,9 +3,9 @@ CONFIG_TARGET_AM335X_BALTOS=y
CONFIG_SPL=y
CONFIG_SPL_STACK_R=y
CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
CONFIG_SYS_EXTRA_OPTIONS=NAND
-CONFIG_CONS_INDEX=1
# CONFIG_CMD_IMLS is not set
# CONFIG_CMD_FLASH is not set
# CONFIG_CMD_SETEXPR is not set
-# CONFIG_CMD_NET is not set
diff --git a/include/configs/baltos.h b/include/configs/baltos.h
index 68bfee5..632523e 100644
--- a/include/configs/baltos.h
+++ b/include/configs/baltos.h
@@ -39,8 +39,6 @@
#define CONFIG_CMD_PART
/* FIT support */
-#define CONFIG_FIT
-#define CONFIG_FIT_VERBOSE 1 /* enable fit_format_{error,warning}() */
#define CONFIG_OF_BOARD_SETUP
/* UBI Support */
--
2.1.0
___
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] hang: ARM64/Relocating u-boot from u-boot
Hello Wolfgang, On Wed, 08 Jul 2015 00:36:52 +0200, Wolfgang Denk w...@denx.de wrote: Dear Jagan, In message CAD6G_RQnrBWyPp1CyiDxkZ4vme4PB5fNHDX-f2Sf=9cvrod...@mail.gmail.com you wrote: I'm running u-boot from u-boot prompt, just like a standalone application with CONFIG_SYS_TEXT_BASE address. ... (note: the board here identifies itself as ARM64 Reference Board, which does not exist in the current U-Boot source code, so this is obviously a non-mainline(-yet?) port for which we could hardly give assistance anyway.) Has any one tried the same before, please let me know for any inputs? Actually this is even a FAQ: http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM If I may, this FAQ is slightly outdated, in that chainloading U-Boot is not only possible but actually made possible by design, at least for many ARM (and possibly some ARM64) targets, and I suspect for many non-ARM targets too, as long as they use SPL. First off: the FAQ is perfectly true if applied to running SPL from SPL. But you can easily run U-Boot from SPL -- that's actually the point of SPL in the first place -- and this is done, usually, by having SPL reset the hardware to the extent of getting external RAM working, and conversively having U-Boot reset the hardware in (OS) booting condition *except* for the external RAM part which U-Boot could not do anyway. IOW, on targets with SPL, U-Boot starts with the guarantee that all initializations needed for external RAM to work have been done, and it guarantees that it will not perform these external RAM inits again. And since an SPL-chainloaded U-Boot runs with external already initialized and does not initialize it again, it follows that this U-Boot is a valid environment for running another instance of itself, provided the new instance and current instances do not overwrite each other. And U-Boot relocates itself to the highest possible address, thereby freeing up its load address. Provided this load address was chosen low in external RAM, and provided the board has enough external RAM (which any board aiming to chainload a big Linux kernel from a smaller U-Boot should have), this allows loading U-Boot to its link-time address from a running U-Boot instance without any trashing of either instance. All of this makes it nont only perfectly possible for (SPL-run) U-Boot to chainload (SPL-run) U-Boot, it pretty much guarantees it. And while chainloading ans SPL-run U-Boot is useless in bringing up a board (where the effort is in SPL itself), it becomes very useful in adding or modifying all the rest of U-Boot, for instance tweaking the performance of a network driver. (on an OT note, I'd even say that a SPL-supported U-Bot which cannot chainload itself probably does not completely and/or properly reset the hardware into booting condition, but that's slightly beside the point.) Note that the above description applies to any target in which U-Boot starts from external RAM rather than IRAM or FLASH; not only those targets with SPL, but also those with a ROM bootloader capable to initialize the external RAM and chain to its payoad there, e.g. kirkwood. Maybe we could add an addendum to the FAQ for the SPL and ROM bootloader cases? Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/13] apalis/colibri_t20/t30: increase tftp blocksize
On 07/06/2015 02:20 AM, Marcel Ziswiler wrote: From: Max Krummenacher max.krummenac...@toradex.com Enable CONFIG_IP_DEFRAG and set CONFIG_TFTP_BLOCKSIZE to 16384. This increases the tftp download speed considerably. While at it enable CONFIG_TFTP_TSIZE which limits the progress bar to fifty '#' independent of the downloaded file size. Do either of patches 12 and 13 make sense for all Tegra boards? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] dcache support for Raspberry Pi 1
Hello Alexander,
On Wed, 08 Jul 2015 20:15:42 +0200, Alexander Stein
alexander...@web.de wrote:
Hello Albert,
On Monday 06 July 2015, 23:26:41 wrote Albert ARIBAUD:
On Mon, 06 Jul 2015 20:24:31 +0200, Alexander Stein
alexander...@web.de wrote:
Hello Albert,
On Monday 06 July 2015, 09:39:40 wrote Albert ARIBAUD:
On Sat, 4 Jul 2015 11:48:39 +0200, Alexander Stein
alexander...@web.de wrote:
dcache supprt increases the MMC read performance on RPI 1 from 5,4
MiB/s to
12.3 MiB/s. It doesn't seem to have any affect on RPI 2 though. I
just get
error messages about non-cacheline aligned address upon invalidation.
Could it be that code needed to support dcache is not the same for
rpi_2's bcm2836 than it is for rpi's bcm2835?
Sure, bcm2835 is a armv6 while bcm2836 is a armv7.
Anyway: if code properly handles unaligned addresses then it should not
throw an error message about it. Can you look into why the error is
thrown?
Apparently it does not handle non-cacheline aligned addresses
transparently or silently.
Here is the part of the code:
static void v7_dcache_inval_range(u32 start, u32 stop, u32 line_len)
{
/*
* If start address is not aligned to cache-line do not
* invalidate the first cache-line
*/
if (start (line_len - 1)) {
printf(ERROR: %s - start address is not aligned -
0x%08x\n,
__func__, start);
/* move to next cache line */
start = (start + line_len - 1) ~(line_len - 1);
}
I don't know why (a) the cache invalidation is only done from the next
cache line and (b) why this can't be done transparently without printing
an error.
But currently I'm not keen on fiddling with armv7 caches.
Well, I can see why.
Let's assume were invalidating the second half of a cache line because
that's where a buffer starts which we want to force-read from external
memory because some device fille dthis buffer with important data.
Now, most probably the compiler and linker will have used the addresses
before our buffer to map some variables which may be unrelated to the
buffer.
At the time we're told to invalidate the buffer, these variables may be
modified in-cache but not yet written out to external memory. If we
invalidate the first cache line, then we erase these modifications --
they're lost.
Now, this is an unsolvable problem -- we can't flush these variables
before invalidating, because then we would flush the whole cache line,
which would overwrite and trash the buffer in external memory.
So anyway, we're doomed; there is nothing we can do -- hence the ERROR
message. From the on, we can either just give up and go hang(), or we
can try to save whatever can be, skip the half cache line and start
invalidating at the next boundary.
(same goes for the last address: it has to be at the end of a cache
line, or else we can neither invalidate nor flush.)
Thanks for thise detailed explanation. I agree this is really a problem.
But how should this behandled: The raspberry pi messagebox handling sends a
message which might have more or less arbitrary length.
I think it might be possible to achieve in every case that those message
starts at the beginning of a cacheline. But the end might be
at different positions with different messages sent. You must flush your data
to get the firmware actually see this and you must invalidate to eventually
read the answer data which is located at the same position.
I guess I might just have not hit your described problem in my board (yet).
True, each message might have various and non-cacheline-aligned
sizes, but there is always a point in time when the buffer for that
message is allocated, and the size of buffer can be greater than the
size of the message. Here, we can compute the /buffer/ size by rounding
up the /message/ size to a multiple of the cache line.
Then, if we make sure that the buffer starts at a cache line boundary
(using the 'align' attribute or calling memalign), it follows that the
buffer also ends at a cache line boundary--IOW, the buffer occupies
whole cache lines only, and cannot share a cache line with some
other, unknown, variable.
Therefore, invalidating (resp. flushing) the buffer will always
invalidate (resp. flush) the whole message and nothing else than the
message. It will invalidate (resp.flush) a few more bytes, but these
are unused so there is no risk.
Note that I've considered the cache line here, but buffers which are
copied to/from DDR by some device using DMA might have stricter
alignment constraints yet. This just changes what value we should
align the start address and size of such buffers to.
Best regards,
Alexander
Amicalement,
--
Albert.
[U-Boot] [PATCH] ls1021a: etsec: Enable Tx Data and TxBD snooping
To improve eTSEC performance on LS1021A Rev2.0, snooping of all transmit frames from memory and all transmit BD memory accesses in enabled. Signed-off-by: Alison Wang alison.w...@freescale.com --- include/tsec.h | 4 1 file changed, 4 deletions(-) diff --git a/include/tsec.h b/include/tsec.h index 58cdc19..1119d2c 100644 --- a/include/tsec.h +++ b/include/tsec.h @@ -129,11 +129,7 @@ #define MINFLR_INIT_SETTINGS 0x0040 -#ifdef CONFIG_LS102XA -#define DMACTRL_INIT_SETTINGS 0x0003 -#else #define DMACTRL_INIT_SETTINGS 0x00c3 -#endif #define DMACTRL_GRS0x0010 #define DMACTRL_GTS0x0008 #define DMACTRL_LE 0x8000 -- 2.1.0.27.g96db324 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: ls1021a: allow OCRAM access permission as R/W in SPL
On LS1021A Rev2.0, OCRAM's security level needs to be changed to
non-secure access for SD boot. This patch will allow OCRAM
access permission as R/W in SPL.
Signed-off-by: Alison Wang alison.w...@freescale.com
---
board/freescale/ls1021aqds/ls1021aqds.c | 178 +---
board/freescale/ls1021atwr/ls1021atwr.c | 177 ---
2 files changed, 184 insertions(+), 171 deletions(-)
diff --git a/board/freescale/ls1021aqds/ls1021aqds.c
b/board/freescale/ls1021aqds/ls1021aqds.c
index 92f613a..2d96770 100644
--- a/board/freescale/ls1021aqds/ls1021aqds.c
+++ b/board/freescale/ls1021aqds/ls1021aqds.c
@@ -54,6 +54,92 @@ enum {
GE1_CLK125,
};
+#ifdef CONFIG_LS102XA_NS_ACCESS
+static struct csu_ns_dev ns_dev[] = {
+ { CSU_CSLX_PCIE2_IO, CSU_ALL_RW },
+ { CSU_CSLX_PCIE1_IO, CSU_ALL_RW },
+ { CSU_CSLX_MG2TPR_IP, CSU_ALL_RW },
+ { CSU_CSLX_IFC_MEM, CSU_ALL_RW },
+ { CSU_CSLX_OCRAM, CSU_ALL_RW },
+ { CSU_CSLX_GIC, CSU_ALL_RW },
+ { CSU_CSLX_PCIE1, CSU_ALL_RW },
+ { CSU_CSLX_OCRAM2, CSU_ALL_RW },
+ { CSU_CSLX_QSPI_MEM, CSU_ALL_RW },
+ { CSU_CSLX_PCIE2, CSU_ALL_RW },
+ { CSU_CSLX_SATA, CSU_ALL_RW },
+ { CSU_CSLX_USB3, CSU_ALL_RW },
+ { CSU_CSLX_SERDES, CSU_ALL_RW },
+ { CSU_CSLX_QDMA, CSU_ALL_RW },
+ { CSU_CSLX_LPUART2, CSU_ALL_RW },
+ { CSU_CSLX_LPUART1, CSU_ALL_RW },
+ { CSU_CSLX_LPUART4, CSU_ALL_RW },
+ { CSU_CSLX_LPUART3, CSU_ALL_RW },
+ { CSU_CSLX_LPUART6, CSU_ALL_RW },
+ { CSU_CSLX_LPUART5, CSU_ALL_RW },
+ { CSU_CSLX_DSPI2, CSU_ALL_RW },
+ { CSU_CSLX_DSPI1, CSU_ALL_RW },
+ { CSU_CSLX_QSPI, CSU_ALL_RW },
+ { CSU_CSLX_ESDHC, CSU_ALL_RW },
+ { CSU_CSLX_2D_ACE, CSU_ALL_RW },
+ { CSU_CSLX_IFC, CSU_ALL_RW },
+ { CSU_CSLX_I2C1, CSU_ALL_RW },
+ { CSU_CSLX_USB2, CSU_ALL_RW },
+ { CSU_CSLX_I2C3, CSU_ALL_RW },
+ { CSU_CSLX_I2C2, CSU_ALL_RW },
+ { CSU_CSLX_DUART2, CSU_ALL_RW },
+ { CSU_CSLX_DUART1, CSU_ALL_RW },
+ { CSU_CSLX_WDT2, CSU_ALL_RW },
+ { CSU_CSLX_WDT1, CSU_ALL_RW },
+ { CSU_CSLX_EDMA, CSU_ALL_RW },
+ { CSU_CSLX_SYS_CNT, CSU_ALL_RW },
+ { CSU_CSLX_DMA_MUX2, CSU_ALL_RW },
+ { CSU_CSLX_DMA_MUX1, CSU_ALL_RW },
+ { CSU_CSLX_DDR, CSU_ALL_RW },
+ { CSU_CSLX_QUICC, CSU_ALL_RW },
+ { CSU_CSLX_DCFG_CCU_RCPM, CSU_ALL_RW },
+ { CSU_CSLX_SECURE_BOOTROM, CSU_ALL_RW },
+ { CSU_CSLX_SFP, CSU_ALL_RW },
+ { CSU_CSLX_TMU, CSU_ALL_RW },
+ { CSU_CSLX_SECURE_MONITOR, CSU_ALL_RW },
+ { CSU_CSLX_RESERVED0, CSU_ALL_RW },
+ { CSU_CSLX_ETSEC1, CSU_ALL_RW },
+ { CSU_CSLX_SEC5_5, CSU_ALL_RW },
+ { CSU_CSLX_ETSEC3, CSU_ALL_RW },
+ { CSU_CSLX_ETSEC2, CSU_ALL_RW },
+ { CSU_CSLX_GPIO2, CSU_ALL_RW },
+ { CSU_CSLX_GPIO1, CSU_ALL_RW },
+ { CSU_CSLX_GPIO4, CSU_ALL_RW },
+ { CSU_CSLX_GPIO3, CSU_ALL_RW },
+ { CSU_CSLX_PLATFORM_CONT, CSU_ALL_RW },
+ { CSU_CSLX_CSU, CSU_ALL_RW },
+ { CSU_CSLX_ASRC, CSU_ALL_RW },
+ { CSU_CSLX_SPDIF, CSU_ALL_RW },
+ { CSU_CSLX_FLEXCAN2, CSU_ALL_RW },
+ { CSU_CSLX_FLEXCAN1, CSU_ALL_RW },
+ { CSU_CSLX_FLEXCAN4, CSU_ALL_RW },
+ { CSU_CSLX_FLEXCAN3, CSU_ALL_RW },
+ { CSU_CSLX_SAI2, CSU_ALL_RW },
+ { CSU_CSLX_SAI1, CSU_ALL_RW },
+ { CSU_CSLX_SAI4, CSU_ALL_RW },
+ { CSU_CSLX_SAI3, CSU_ALL_RW },
+ { CSU_CSLX_FTM2, CSU_ALL_RW },
+ { CSU_CSLX_FTM1, CSU_ALL_RW },
+ { CSU_CSLX_FTM4, CSU_ALL_RW },
+ { CSU_CSLX_FTM3, CSU_ALL_RW },
+ { CSU_CSLX_FTM6, CSU_ALL_RW },
+ { CSU_CSLX_FTM5, CSU_ALL_RW },
+ { CSU_CSLX_FTM8, CSU_ALL_RW },
+ { CSU_CSLX_FTM7, CSU_ALL_RW },
+ { CSU_CSLX_COP_DCSR, CSU_ALL_RW },
+ { CSU_CSLX_EPU, CSU_ALL_RW },
+ { CSU_CSLX_GDI, CSU_ALL_RW },
+ { CSU_CSLX_DDI, CSU_ALL_RW },
+ { CSU_CSLX_RESERVED1, CSU_ALL_RW },
+ { CSU_CSLX_USB3_PHY, CSU_ALL_RW },
+ { CSU_CSLX_RESERVED2, CSU_ALL_RW },
+};
+#endif
+
int checkboard(void)
{
#ifndef CONFIG_QSPI_BOOT
@@ -289,6 +375,12 @@ void board_init_f(ulong dummy)
dram_init();
+ /* Allow OCRAM access permission as R/W */
+#ifdef CONFIG_LS102XA_NS_ACCESS
+ enable_devices_ns_access(ns_dev[4], 1);
+ enable_devices_ns_access(ns_dev[7], 1);
+#endif
+
board_init_r(NULL, 0);
}
#endif
@@ -441,92 +533,6 @@ int misc_init_r(void)
return 0;
}
-#ifdef CONFIG_LS102XA_NS_ACCESS
-static struct csu_ns_dev ns_dev[] = {
- { CSU_CSLX_PCIE2_IO, CSU_ALL_RW },
- { CSU_CSLX_PCIE1_IO, CSU_ALL_RW },
- { CSU_CSLX_MG2TPR_IP, CSU_ALL_RW },
- { CSU_CSLX_IFC_MEM, CSU_ALL_RW },
- { CSU_CSLX_OCRAM, CSU_ALL_RW },
- { CSU_CSLX_GIC, CSU_ALL_RW },
- { CSU_CSLX_PCIE1, CSU_ALL_RW },
- { CSU_CSLX_OCRAM2, CSU_ALL_RW },
- { CSU_CSLX_QSPI_MEM, CSU_ALL_RW },
- { CSU_CSLX_PCIE2,
Re: [U-Boot] [PATCH v2 4/6] mmc: hi6220_dw_mmc: Add hi6220 glue code for dw_mmc controller.
On 07/09/2015 12:57 AM, Peter Griffin wrote:
This patch adds the glue code for hi6220 SoC which has 2x synopsis
dw_mmc controllers. This will be used by the hikey board support
in subsequent patches.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
arch/arm/include/asm/arch-hi6220/dwmmc.h | 8 +
drivers/mmc/Makefile | 1 +
drivers/mmc/hi6220_dw_mmc.c | 56
3 files changed, 65 insertions(+)
create mode 100644 arch/arm/include/asm/arch-hi6220/dwmmc.h
create mode 100644 drivers/mmc/hi6220_dw_mmc.c
diff --git a/arch/arm/include/asm/arch-hi6220/dwmmc.h
b/arch/arm/include/asm/arch-hi6220/dwmmc.h
new file mode 100644
index 000..c747383
--- /dev/null
+++ b/arch/arm/include/asm/arch-hi6220/dwmmc.h
@@ -0,0 +1,8 @@
+/*
+ * (C) Copyright 2015 Linaro
+ * Peter Griffin peter.grif...@linaro.org
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+int hi6220_dwmci_add_port(int index, u32 regbase, int bus_width);
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index ed73687..81a1a8f 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_BFIN_SDH) += bfin_sdh.o
obj-$(CONFIG_DAVINCI_MMC) += davinci_mmc.o
obj-$(CONFIG_DWMMC) += dw_mmc.o
obj-$(CONFIG_EXYNOS_DWMMC) += exynos_dw_mmc.o
+obj-$(CONFIG_HIKEY_DWMMC) += hi6220_dw_mmc.o
obj-$(CONFIG_FSL_ESDHC) += fsl_esdhc.o
obj-$(CONFIG_FTSDC010) += ftsdc010_mci.o
obj-$(CONFIG_FTSDC021) += ftsdc021_sdhci.o
diff --git a/drivers/mmc/hi6220_dw_mmc.c b/drivers/mmc/hi6220_dw_mmc.c
new file mode 100644
index 000..106f673
--- /dev/null
+++ b/drivers/mmc/hi6220_dw_mmc.c
@@ -0,0 +1,56 @@
+/*
+ * (C) Copyright 2015 Linaro
+ * peter.griffin peter.grif...@linaro.org
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+#include dwmmc.h
+#include malloc.h
+#include asm-generic/errno.h
+
+#define DWMMC_MAX_CH_NUM4
+
+#define DWMMC_MAX_FREQ 5000
+#define DWMMC_MIN_FREQ 378000
Is there any reason for using 378000 instead of 400K?
+
+/* Source clock is configured to 100Mhz by ATF bl1*/
+#define MMC0_DEFAULT_FREQ1
Always configured to 100Mhz? Is there no method to get clock value?
+
+static int hi6220_dwmci_core_init(struct dwmci_host *host, int index)
+{
+ host-name = HiKey DWMMC;
+
+ host-dev_index = index;
+
+ /* Add the mmc channel to be registered with mmc core */
+ if (add_dwmci(host, DWMMC_MAX_FREQ, DWMMC_MIN_FREQ)) {
+ printf(DWMMC%d registration failed\n, index);
+ return -1;
+ }
+ return 0;
+}
+
+/*
+ * This function adds the mmc channel to be registered with mmc core.
+ * index - mmc channel number.
+ * regbase - register base address of mmc channel specified in 'index'.
+ * bus_width - operating bus width of mmc channel specified in 'index'.
+ */
+int hi6220_dwmci_add_port(int index, u32 regbase, int bus_width)
+{
+ struct dwmci_host *host = NULL;
+
+ host = calloc(1, sizeof(struct dwmci_host));
+ if (!host) {
+ error(dwmci_host malloc fail!\n);
malloc - calloc?
Best Regards,
Jaehoon Chung
+ return -ENOMEM;
+ }
+
+ host-ioaddr = (void *)regbase;
+ host-buswidth = bus_width;
+ host-bus_hz = MMC0_DEFAULT_FREQ;
+
+ return hi6220_dwmci_core_init(host, index);
+}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 06/12] devres: introduce Devres (Managed Device Resource) framework
Hi Simon,
2015-07-09 9:22 GMT+09:00 Simon Glass s...@chromium.org:
Hi Masahiro,
On 7 July 2015 at 22:29, Masahiro Yamada yamada.masah...@socionext.com
wrote:
In U-Boot's driver model, memory is basically allocated and freed
in the core framework. So, low level drivers generally only have
to specify the size of needed memory with .priv_auto_alloc_size,
.platdata_auto_alloc_size, etc. Nevertheless, some drivers still
need to allocate memory on their own in case they cannot statically
know how much memory is needed. Moreover, I am afraid the failure
paths of driver model core parts are getting messier as more and
more memory size members are supported, .per_child_auto_alloc_size,
.per_child_platdata_auto_alloc_size... So, I believe it is
reasonable enough to port Devres into U-boot.
As you know, Devres, which originates in Linux, manages device
resources for each device and automatically releases them on driver
detach. With devres, device resources are guaranteed to be freed
whether initialization fails half-way or the device gets detached.
The basic idea is totally the same to that of Linux, but I tweaked
it a bit so that it fits in U-Boot's driver model.
In U-Boot, drivers are activated in two steps: binding and probing.
Binding puts a driver and a device together. It is just data
manipulation on the system memory, so nothing has happened on the
hardware device at this moment. When the device is really used, it
is probed. Probing initializes the real hardware device to make it
really ready for use.
So, the resources acquired during the probing process must be freed
when the device is removed. Likewise, what has been allocated in
binding should be released when the device is unbound. The struct
devres has a member probe to remember when the resource was
allocated.
CONFIG_DEBUG_DEVRES is also supported for easier debugging.
If enabled, debug messages are printed each time a resource is
allocated/freed.
Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com
A few points to make:
1. I don't think we will be adding a lot more types of memory attached
to devices. We have:
- device private data
- uclass' private data for the device
- parent's private data for the device
That is all set up in device_probe() and friends. Then we have
platform data for the above which is set up in device_bind(). Within
the driver model architecture it's hard to see another type of data
coming along although of course I would not rule it out.
2. The auto-allocation feature of driver model has actually been very
successful at removing the need for drivers to do their own memory
allocation.
git grep -l U_BOOT_DRIVER |wc
105
grep '[mc]alloc(' `git grep -l U_BOOT_DRIVER ` |wc
20
and a quick check suggests that half of those 10 are bogus (could be
redone to avoid a special malloc()).
So I don't think the devm functions will be used much.
Right.
3. How do we handle things like gpio_exynos_bind() which allocs some
data and passes it to a device it creates, as platform data? At
present we don't free it.
So, currently this driver is leaking the memory, isn't it?
If we use devm_kzalloc() here, the platdata for GPIOs
will be released when the parent pinctrl is unbound.
4. There is a data size overhead to this which is not insignificant.
As I read it we add 16 bytes to each memory allocation, which for most
devices will amount to 32 or 48 bytes. Currently struct udevice is 84
bytes so increasing the overhead by 50% for no real improvement in
functionality. This does matter in SPL in some cases.
With all that said I think overall this is a good and useful change. I
can see it saving hassle later.
So, can we reduce the overhead / turn it off for SPL? Perhaps it could
dissolve to nothing if CONFIG_DM_DEVICE_REMOVE is not defined?
I think I can do this.
devres.c can be built (and makes sense) only when CONFIG_DM_DEVICE_REMOVE is
enabled.
As it happens I started yesterday on a change to check driver model
pointers. I've been talking about it for a while but there are enough
drivers out there that I think it is worth doing now. I hope to have
something next week. However it doesn't look like it will interfere
with your change much.
BTW can we please have exported functions documented in the header file?
IIRC, when we discussed this before, we could not reach agreement
which should be documented, headers or sources.
I know you prefer comments in headers, while I prefer in sources (like Linux).
I can move them to dm/device.h if you think it is important to be
consistent in the DM core portion.
--
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] thermal: imx_thermal: fix busywait if IMX6 temp 0C
The temperature calculation must be typecasted to keep the compiler from sign extending a negative value prior to division. This fixes an issue where if the CPU temperature is 0C it will get stuck in the busywait loop until the CPU heats up to 0C. Cc: Ye Li b37...@freescale.com Cc: Jason Liu r64...@freescale.com Signed-off-by: Tim Harvey thar...@gateworks.com --- drivers/thermal/imx_thermal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c index 0d893c9..6d1ac97 100644 --- a/drivers/thermal/imx_thermal.c +++ b/drivers/thermal/imx_thermal.c @@ -115,7 +115,7 @@ static int read_cpu_temperature(struct udevice *dev) writel(TEMPSENSE0_FINISHED, anatop-tempsense0_clr); /* milli_Tmeas = c2 - Nmeas * c1 */ - temperature = (c2 - n_meas * c1)/1000; + temperature = (long)(c2 - n_meas * c1)/1000; /* power down anatop thermal sensor */ writel(TEMPSENSE0_POWER_DOWN, anatop-tempsense0_set); -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Eliminate make defconfig warning for Crown Bay and Minnowmax
Hi Bin, On 8 July 2015 at 18:17, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Thu, Jul 9, 2015 at 4:28 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 8 July 2015 at 07:50, Bin Meng bmeng...@gmail.com wrote: Remove duplicated entry of OF_CONTROL in crownbay_defconfig and minnowmax_defconfig which causes a warning when making defconfig. The updated defconfig files are generated by 'make savedefconfig'. Signed-off-by: Bin Meng bmeng...@gmail.com --- configs/crownbay_defconfig | 14 ++ configs/minnowmax_defconfig | 6 ++ 2 files changed, 8 insertions(+), 12 deletions(-) I've incorporated this into the offending patches in x86/master. Please take a look and let me know what you think. I'd rather avoid strange errors in the tree, even tools/genboardscfg.py. It looks good. But the order does not match 'savedefconfig', like what I did in this patch. I've tested all 7 x86 boards, and found only these two have this ordering issue. I am not sure if this issue is now a must as I see the mainline seems all defconfigs are updated. If you like you could send a new patch to fix the order? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND 0/7] spi: cadence_qspi: optimize fix indirect rd-writes
Hi Stefan, -Original Message- From: Vikas MANOCHA Sent: Wednesday, July 01, 2015 9:25 AM To: 'Stefan Roese' Cc: 'u-boot@lists.denx.de'; 'grmo...@opensource.altera.com'; 'dingu...@opensource.altera.com'; 'jt...@openedev.com' Subject: RE: [PATCH RESEND 0/7] spi: cadence_qspi: optimize fix indirect rd-writes Hi Stefan, -Original Message- From: Vikas MANOCHA Sent: Monday, June 22, 2015 4:31 PM To: 'Stefan Roese' Cc: u-boot@lists.denx.de; grmo...@opensource.altera.com; dingu...@opensource.altera.com; jt...@openedev.com Subject: RE: [PATCH RESEND 0/7] spi: cadence_qspi: optimize fix indirect rd-writes Thanks Stefan, -Original Message- From: Stefan Roese [mailto:s...@denx.de] Sent: Monday, June 22, 2015 1:35 AM To: Vikas MANOCHA Cc: u-boot@lists.denx.de; grmo...@opensource.altera.com; dingu...@opensource.altera.com; jt...@openedev.com Subject: Re: [PATCH RESEND 0/7] spi: cadence_qspi: optimize fix indirect rd-writes Hi Vikas, On 19.06.2015 23:38, Vikas MANOCHA wrote: - git bisect or cherry-pick to find out which patch is breaking the read functionality. This one is the first introducing this breakage: spi: cadence_qspi: fix base trigger address transfer start address Ok, can you confirm applying patches upto ( including) spi: cadence_qspi: fix indirect read/write start address , read/write to flash are working fine. Please note that with this patch the code does not compile: drivers/spi/cadence_qspi_apb.c: In function 'qpsi_write_sram_fifo_push': drivers/spi/cadence_qspi_apb.c:227:32: error: 'struct cadence_spi_platdata' has no member named 'trigger_base' unsigned int *dest_addr = plat-trigger_base; I've manually fixed this trivial change (trigger_base - ahbbase) and tests with these patches applied show some problems with sf stability (bit-flips): Sorry for this dumb mistake which happened during rebase :-(, I will correct in next patch series. = sf update 40 10 10 1048576 bytes written, 0 bytes skipped in 34.196s, speed 31395 B/s = sf read 50 10 10 SF: 1048576 bytes @ 0x10 Read: OK = cmp.b 40 50 10 byte at 0x0040001e (0x9f) != byte at 0x0050001e (0x8f) Total of 30 byte(s) were the same This is new - removing all your patches seems to solve this issue again. Thanks again Stefan for these tests. It is not easy for me to figure out this instability without the board but I don 't see any logical error in the patches. Off-course code is more optimized fast with these patches. Access timing in the log provided by you also confirms it. I can suggest following checks on the hardware: - Figure out the issue is with read or write, which means comparing the flash with ram after read/write. - Put some random microsecond delays in the read/write to confirm it is timing issue. Any update on it ? In addition can you please check the patch causing this instability on socfpga. I don't like to bug you but to close this patchset, this info tests mentioned above seems to be required. I am ready to check it but would need the hardware platform. Rgds, Vikas Rgds, Vikas So there seems to be something wrong with the previous patches as well. here the output with the patches reverted: = sf probe SF: Detected N25Q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB SF: Warning - Only lower 16MiB accessible, Full access #define CONFIG_SPI_FLASH_BAR = sf update 40 10 10 1048576 bytes written, 0 bytes skipped in 35.872s, speed 29929 B/s = sf read 50 10 10 SF: 1048576 bytes @ 0x10 Read: OK = cmp.b 40 50 10 Total of 1048576 byte(s) were the same The point is if after applying above mentioned patch (...: fix indirect read/write start address), Read/write are working fine, then trigger_base value of 0xFFA00_ should also work fine. Can you please modify the trigger_base value from 0x0 to 0xFFA0_ in Socfpga.dtsi check. If it works, it would mean both (socfpga stv0991) are behaving same. No. With this change, the sf read command crashes / hangs on the SoCFPGA board. Ok, I don't know why socfpga is not working with trigger_base to be 0xFFA0_. Normally it should work, Graham also thinks the same, Let's wait for his discussion with the Altera designers. Rgds, Vikas Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] ahci: Fix compiling warnings under 64bit platforms
On Tue, Jul 07, 2015 at 03:48:26PM +0800, tang yuantian wrote: From: Tang Yuantian yuantian.t...@freescale.com When compling under 64bit platforms, there are lots of warnings, like: drivers/block/ahci.c:114:18: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] u8 *port_mmio = (u8 *)probe_ent-port[port].port_mmio; ^ drivers/block/ahci.c: In function ?.hci_host_init?. drivers/block/ahci.c:218:49: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] probe_ent-port[i].port_mmio = ahci_port_base((u32) mmio, i); .. Signed-off-by: Shaohui Xie shaohui@freescale.com Signed-off-by: Tang Yuantian yuantian.t...@freescale.com --- This introduces a warning with ELDK 5.5 on nitrogen6q,novena,ot1200_spl,nitrogen6q2g,m53evk,mx6qsabrelite,udoo_quad,ima3-mx53,tb s2910,cm_fx6,ot1200,gwventana,mx53loco: ../drivers/block/dwc_ahsata.c:169:32: warning: assignment makes pointer from integer without a cast [enabled by default] ../drivers/block/dwc_ahsata.c: In function 'ahci_port_start': ../drivers/block/dwc_ahsata.c:523:2: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'ulong' [-Wformat=] -- 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 7/8] mtd/nand/ubi: assortment of alignment fixes
On Wed, 2015-07-08 at 13:58 +0200, Marcel Ziswiler wrote: From: Marcel Ziswiler marcel.ziswi...@toradex.com Various U-Boot adoptions/extensions to MTD/NAND/UBI did not take buffer alignment into account which led to failures of the following form: ERROR: v7_dcache_inval_range - start address is not aligned - 0x1f7f0108 ERROR: v7_dcache_inval_range - stop address is not aligned - 0x1f7f1108 Signed-off-by: Marcel Ziswiler marcel.ziswi...@toradex.com --- Changes in v2: run it through checkpatch.pl and fix long lines common/cmd_ubi.c | 2 +- drivers/mtd/nand/nand_util.c | 2 +- fs/ubifs/super.c | 6 -- fs/ubifs/ubifs.c | 5 +++-- lib/gzip.c | 2 +- 5 files changed, 10 insertions(+), 7 deletions(-) As per discussion on v1, this isn't enough to guarantee that the stop address will be aligned. There needs to be a wrapper around memalign() that cache- aligns the size as well. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] thermal:imx_thermal: enter busywait cooling loop when over max CPU temp
On Tue, Jun 9, 2015 at 6:40 AM, Tim Harvey thar...@gateworks.com wrote:
Remove the check for temperature being within the min/max range and enter the
busywait cooling loop whenever the CPU temperature is over the critical temp.
This fixes the issue where if a board was booted at a temp greater than
the CPU temperature max, it would skip the loop and never indicate or try
to address the overtemp issue.
Cc: Ye Li b37...@freescale.com
Cc: Jason Liu r64...@freescale.com
Signed-off-by: Tim Harvey thar...@gateworks.com
---
drivers/thermal/imx_thermal.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index 0d893c9..42ca8d0 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -130,16 +130,12 @@ int imx_thermal_get_temp(struct udevice *dev, int *temp)
int cpu_tmp = 0;
cpu_tmp = read_cpu_temperature(dev);
- while (cpu_tmp priv-minc cpu_tmp priv-maxc) {
- if (cpu_tmp = priv-critical) {
- printf(CPU Temperature (%dC) too close to max (%dC),
- cpu_tmp, priv-maxc);
- puts( waiting...\n);
- udelay(500);
- cpu_tmp = read_cpu_temperature(dev);
- } else {
- break;
- }
+ while (cpu_tmp = priv-critical) {
+ printf(CPU Temperature (%dC) too close to max (%dC),
+ cpu_tmp, priv-maxc);
+ puts( waiting...\n);
+ udelay(500);
+ cpu_tmp = read_cpu_temperature(dev);
}
*temp = cpu_tmp;
--
1.9.1
Stefano,
Any feedback on this?
Regards,
Tim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Eliminate make defconfig warning for Crown Bay and Minnowmax
Hi Simon, On Thu, Jul 9, 2015 at 4:28 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 8 July 2015 at 07:50, Bin Meng bmeng...@gmail.com wrote: Remove duplicated entry of OF_CONTROL in crownbay_defconfig and minnowmax_defconfig which causes a warning when making defconfig. The updated defconfig files are generated by 'make savedefconfig'. Signed-off-by: Bin Meng bmeng...@gmail.com --- configs/crownbay_defconfig | 14 ++ configs/minnowmax_defconfig | 6 ++ 2 files changed, 8 insertions(+), 12 deletions(-) I've incorporated this into the offending patches in x86/master. Please take a look and let me know what you think. I'd rather avoid strange errors in the tree, even tools/genboardscfg.py. It looks good. But the order does not match 'savedefconfig', like what I did in this patch. I've tested all 7 x86 boards, and found only these two have this ordering issue. I am not sure if this issue is now a must as I see the mainline seems all defconfigs are updated. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 02/12] linux_compat: remove cpu_relax() define
On 7 July 2015 at 22:29, Masahiro Yamada yamada.masah...@socionext.com wrote:
The macro cpu_relax() is defined by several headers in different
ways.
arch/{arm,avr32,mips}/include/asm/processor.h defines it as follows:
#define cpu_relax() barrier()
On the other hand, include/linux/compat.h defines it as follows:
#define cpu_relax() do {} while (0)
If both headers are included from the same source file, the warning
warning: cpu_relax redefined [enabled by default]
is displayed.
It effectively makes it impossible to include linux/compat.h
from some sources. Drop the latter.
Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com
---
drivers/usb/musb-new/musb_gadget_ep0.c | 1 +
include/linux/compat.h | 2 --
2 files changed, 1 insertion(+), 2 deletions(-)
Acked-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/12] linux_compat: handle __GFP_ZERO in kmalloc()
On 7 July 2015 at 22:29, Masahiro Yamada yamada.masah...@socionext.com wrote: Currently, kzalloc() returns zero-filled memory, while kmalloc() simply ignores the second argument and never fills the memory area with zeros. I want kmalloc(size, __GFP_ZERO) to behave as kzalloc() does, which will make it easier to add more memory allocator variants. With the introduction of __GFP_ZERO flag, going forward, kzmalloc() variants can fall back to kmalloc() enabling the __GFP_ZERO flag. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com --- include/linux/compat.h | 20 lib/linux_compat.c | 13 ++--- 2 files changed, 18 insertions(+), 15 deletions(-) Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 06/12] devres: introduce Devres (Managed Device Resource) framework
Hi Masahiro,
On 7 July 2015 at 22:29, Masahiro Yamada yamada.masah...@socionext.com wrote:
In U-Boot's driver model, memory is basically allocated and freed
in the core framework. So, low level drivers generally only have
to specify the size of needed memory with .priv_auto_alloc_size,
.platdata_auto_alloc_size, etc. Nevertheless, some drivers still
need to allocate memory on their own in case they cannot statically
know how much memory is needed. Moreover, I am afraid the failure
paths of driver model core parts are getting messier as more and
more memory size members are supported, .per_child_auto_alloc_size,
.per_child_platdata_auto_alloc_size... So, I believe it is
reasonable enough to port Devres into U-boot.
As you know, Devres, which originates in Linux, manages device
resources for each device and automatically releases them on driver
detach. With devres, device resources are guaranteed to be freed
whether initialization fails half-way or the device gets detached.
The basic idea is totally the same to that of Linux, but I tweaked
it a bit so that it fits in U-Boot's driver model.
In U-Boot, drivers are activated in two steps: binding and probing.
Binding puts a driver and a device together. It is just data
manipulation on the system memory, so nothing has happened on the
hardware device at this moment. When the device is really used, it
is probed. Probing initializes the real hardware device to make it
really ready for use.
So, the resources acquired during the probing process must be freed
when the device is removed. Likewise, what has been allocated in
binding should be released when the device is unbound. The struct
devres has a member probe to remember when the resource was
allocated.
CONFIG_DEBUG_DEVRES is also supported for easier debugging.
If enabled, debug messages are printed each time a resource is
allocated/freed.
Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com
A few points to make:
1. I don't think we will be adding a lot more types of memory attached
to devices. We have:
- device private data
- uclass' private data for the device
- parent's private data for the device
That is all set up in device_probe() and friends. Then we have
platform data for the above which is set up in device_bind(). Within
the driver model architecture it's hard to see another type of data
coming along although of course I would not rule it out.
2. The auto-allocation feature of driver model has actually been very
successful at removing the need for drivers to do their own memory
allocation.
git grep -l U_BOOT_DRIVER |wc
105
grep '[mc]alloc(' `git grep -l U_BOOT_DRIVER ` |wc
20
and a quick check suggests that half of those 10 are bogus (could be
redone to avoid a special malloc()).
So I don't think the devm functions will be used much.
3. How do we handle things like gpio_exynos_bind() which allocs some
data and passes it to a device it creates, as platform data? At
present we don't free it.
4. There is a data size overhead to this which is not insignificant.
As I read it we add 16 bytes to each memory allocation, which for most
devices will amount to 32 or 48 bytes. Currently struct udevice is 84
bytes so increasing the overhead by 50% for no real improvement in
functionality. This does matter in SPL in some cases.
With all that said I think overall this is a good and useful change. I
can see it saving hassle later.
So, can we reduce the overhead / turn it off for SPL? Perhaps it could
dissolve to nothing if CONFIG_DM_DEVICE_REMOVE is not defined?
As it happens I started yesterday on a change to check driver model
pointers. I've been talking about it for a while but there are enough
drivers out there that I think it is worth doing now. I hope to have
something next week. However it doesn't look like it will interfere
with your change much.
BTW can we please have exported functions documented in the header file?
Regards,
Simon
[snip]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 07/12] devres: add devm_kmalloc() and friends (managed memory allocation)
On 7 July 2015 at 22:29, Masahiro Yamada yamada.masah...@socionext.com wrote: devm_kmalloc() is identical to kmalloc() except that the memory allocated with it is managed and will be automatically released when the device is removed/unbound. Likewise for the other variants. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com --- drivers/core/devres.c | 21 + include/dm/device.h | 23 +++ 2 files changed, 44 insertions(+) Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 01/12] x86: delete unneeded declarations of disable_irq() and enable_irq()
On 7 July 2015 at 22:46, Bin Meng bmeng...@gmail.com wrote: On Wed, Jul 8, 2015 at 12:29 PM, Masahiro Yamada yamada.masah...@socionext.com wrote: These two declarations in arch/x86/include/asm/interrupt.h conflict with ones in include/linux/compat.h, so x86 boards cannot include linux/compat.h. The comment /* arch/x86/lib/interrupts.c */ is bogus now, and we do not see any definitions of disable_irq() and enable_irq() in there. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com --- arch/x86/include/asm/interrupt.h | 4 1 file changed, 4 deletions(-) diff --git a/arch/x86/include/asm/interrupt.h b/arch/x86/include/asm/interrupt.h index 0a75f89..00cbe07 100644 --- a/arch/x86/include/asm/interrupt.h +++ b/arch/x86/include/asm/interrupt.h @@ -16,10 +16,6 @@ /* arch/x86/cpu/interrupts.c */ void set_vector(u8 intnum, void *routine); -/* arch/x86/lib/interrupts.c */ -void disable_irq(int irq); -void enable_irq(int irq); - /* Architecture specific functions */ void mask_irq(int irq); void unmask_irq(int irq); -- Reviewed-by: Bin Meng bmeng...@gmail.com Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 03/12] linux_compat: move vzalloc() to header file as an inline function
On 7 July 2015 at 22:29, Masahiro Yamada yamada.masah...@socionext.com wrote: The vzalloc(size) is equivalent to kzalloc(size, 0). Move it to include/linux/compat.h as an inline function in order to avoid the function call overhead. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com --- include/linux/compat.h | 6 -- lib/linux_compat.c | 5 - 2 files changed, 4 insertions(+), 7 deletions(-) Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 05/12] dm: add DM_FLAG_BOUND flag
Hi Masahiro, On 7 July 2015 at 22:29, Masahiro Yamada yamada.masah...@socionext.com wrote: Currently, we only have DM_FLAG_ACTIVATED to indicate the device status, but we still cannot know in which stage is in progress, binding or probing. This commit introduces a new flag, DM_FLAG_BOUND, which is set when the device is really bound, and cleared when it is unbound. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com Under what situation does a device exist without being bound? Binding is supposed to be the act of creating the device. OK I see after reading the rest of the patches that we might use devm_alloc() during the bind process and want to track that. I guess this is OK. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 06/12] devres: introduce Devres (Managed Device Resource) framework
Hello Masahiro, On Thu, 9 Jul 2015 14:16:33 +0900, Masahiro Yamada yamada.masah...@socionext.com wrote: Hi Simon, 3. How do we handle things like gpio_exynos_bind() which allocs some data and passes it to a device it creates, as platform data? At present we don't free it. So, currently this driver is leaking the memory, isn't it? If we use devm_kzalloc() here, the platdata for GPIOs will be released when the parent pinctrl is unbound. Does gpio_exynos_bind() get called enough between entry and exit from U-boot that the memory leaks prevent U-Boot from doing its job properly? 4. There is a data size overhead to this which is not insignificant. As I read it we add 16 bytes to each memory allocation, which for most devices will amount to 32 or 48 bytes. Currently struct udevice is 84 bytes so increasing the overhead by 50% for no real improvement in functionality. This does matter in SPL in some cases. With all that said I think overall this is a good and useful change. I can see it saving hassle later. So, can we reduce the overhead / turn it off for SPL? Perhaps it could dissolve to nothing if CONFIG_DM_DEVICE_REMOVE is not defined? I think I can do this. devres.c can be built (and makes sense) only when CONFIG_DM_DEVICE_REMOVE is enabled. Agreed. As it happens I started yesterday on a change to check driver model pointers. I've been talking about it for a while but there are enough drivers out there that I think it is worth doing now. I hope to have something next week. However it doesn't look like it will interfere with your change much. BTW can we please have exported functions documented in the header file? IIRC, when we discussed this before, we could not reach agreement which should be documented, headers or sources. I know you prefer comments in headers, while I prefer in sources (like Linux). I can move them to dm/device.h if you think it is important to be consistent in the DM core portion. My .02EUR: I prefer comments in both, targeting different people. In .h files, for the benefit of users of the function, describe what it does, what its arguments mean and what its return value means. In .c files, for the benefit of maintainers (in a loose sense) of the function, describe how it does its job (if and where the code does not make it reasonably obvious). -- Best Regards Masahiro Yamada Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
