Re: [U-Boot] [RFC v3 PATCH 3/4] pinctrl: add simple pinctrl implementation
Hi Simon,
2015-08-12 23:16 GMT+09:00 Simon Glass :
>> diff --git a/include/dm/pinctrl.h b/include/dm/pinctrl.h
>> index 42008da..b2ba0b4 100644
>> --- a/include/dm/pinctrl.h
>> +++ b/include/dm/pinctrl.h
>> @@ -85,6 +85,8 @@ struct pinctrl_ops {
>> int (*pinconf_group_set)(struct udevice *dev, unsigned
>> group_selector,
>> unsigned param, unsigned argument);
>> int (*set_state)(struct udevice *dev, struct udevice *config);
>> + /* for pinctrl-simple */
>> + int (*set_state_simple)(struct udevice *dev, struct udevice *periph);
>
> So should the other members be #idef'd out? Also, comments on this function?
>
After my careful consideration, I did not do this.
If we do this,the corresponding members in all drivers must be also
#ifdef'd out,
including full-pinctrl drivers that do not care about memory footprint.
I do not like adding #ifdefs around to fix build errors found with
"make allyesconfig", "make randconfig".
I think it is a general strategy to not #ifdef out struct members.
--
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)
On Tue 2015-08-25 10:25:35, Bin Meng wrote: > Hi, > > With latest u-boot/master, TFTP is seriously broken. Sorry about that. > => tftp 10 bzImage > Speed: 100, full duplex > Using pch_gbe device > TFTP from server 10.10.0.8; our IP address is 10.10.0.100; sending > through gateway 10.10.0.1 > Filename 'bzImage'. > Load address: 0x10 > Loading: T > TFTP error: 'Unsupported option(s) requested' (8) > Starting again > > git bisect shows the following commit broke the TFTP I was not intentionally changing the packets being sent. Could you try to capture tcpdump, including contents of packet, ideally in both working and broken sessions? Could you try setting -#define TIMEOUT5000UL +#define TIMEOUT100UL in net/tftp.c to something like 1000UL? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/4] distro_bootcmd: Add support for booting from ubifs
Hi, On 24-08-15 18:57, Scott Wood wrote: On Sat, 2015-08-22 at 20:04 +0200, Hans de Goede wrote: Hi Stephen & Scott, As requested by Stephen here is a new version of my patch-set to add mtd with ubi on top with ubifs on top support to distro_bootcmd, this time using the generic filesystem related commands / code. Scott, can you review the first three patches, and perhaps these should also be merged through your tree ? I don't see anything NAND-specific about them, nor am I particularly familiar with ubifs internals or U-Boot filesystem support... Kyungmin Park and Heiko Schocher are listed as the UBI custodians. My bad, since you are the mtd custodian, I assumed that you would be maintaining ubi[fs] too, my mistake. Heiko, Kyungmin (added to the Cc), can one of you please review the first 3 patches of this set. I think this is post v2015.10 material, once reviewed I can merge it through the sunxi tree, or you can pick it up. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] sunxi_nand_spl: Remove NAND_SUNXI_SPL_SYNDROME_PARTITIONS_END
Hi, On 24-08-15 19:02, Scott Wood wrote: On Sat, 2015-08-22 at 20:13 +0200, Hans de Goede wrote: We only ever use syndrome mode for the partitions which contain the SPL, as that is required for the BROM to be able to read the SPL. Instead of using some arbritray limit for deciding whether or not to use syndrome, be smart and check if u-boot-dtb.bin is directly behind the SPL, if it is not then it is on its own partition and we should not use syndrome. Note the reason why we only use syndrome mode is because it comes with weaker randomization, "...why we only use syndrome mode for the SPL is because..." introducing a risc for more bit errors, risk Will fix. - int syndrome = offs < CONFIG_NAND_SUNXI_SPL_SYNDROME_PARTITIONS_END; - int i; + int i, syndrome; + + if (CONFIG_SYS_NAND_U_BOOT_OFFS == CONFIG_SPL_PAD_TO) + syndrome = 1; /* u-boot-dtb.bin appended to SPL */ + else + syndrome = 0; /* u-boot-dtb.bin on its own partition */ Is it not possible for a separate partition to begin at CONFIG_SPL_PAD_TO, or would padding not be used in that case? CONFIG_SPL_PAD_TO always is 32k on sunxi, partitions must be on an eraseblock boundary and eraseblocks are always much larger then 32k, so this cannot happen. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/9] x86: crownbay: Convert to use CONFIG_DM_USB
Move to driver model for USB on Intel Crown Bay. Signed-off-by: Bin Meng --- configs/crownbay_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/crownbay_defconfig b/configs/crownbay_defconfig index 4fc1827..6edd710 100644 --- a/configs/crownbay_defconfig +++ b/configs/crownbay_defconfig @@ -23,6 +23,8 @@ CONFIG_NETDEVICES=y CONFIG_E1000=y CONFIG_VIDEO_VESA=y CONFIG_FRAMEBUFFER_SET_VESA_MODE=y +CONFIG_USB=y +CONFIG_DM_USB=y CONFIG_DM_RTC=y CONFIG_USE_PRIVATE_LIBGCC=y CONFIG_SYS_VSNPRINTF=y -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/9] net: e1000: Fix build warnings for 32-bit
commit 6497e37 "net: e1000: Support 64-bit physical address" causes
compiler warnings on 32-bit U-Boot build below.
drivers/net/e1000.c: In function 'e1000_configure_tx':
drivers/net/e1000.c:4982:2: warning: right shift count >= width of type
[enabled by default]
drivers/net/e1000.c: In function 'e1000_configure_rx':
drivers/net/e1000.c:5126:2: warning: right shift count >= width of type
[enabled by default]
This commit fixes the build warnings.
Signed-off-by: Bin Meng
---
drivers/net/e1000.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 6f74d30..a467280 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -4977,9 +4977,10 @@ e1000_configure_tx(struct e1000_hw *hw)
unsigned long tctl;
unsigned long tipg, tarc;
uint32_t ipgr1, ipgr2;
+ uint64_t tdba = (unsigned long)tx_base;
- E1000_WRITE_REG(hw, TDBAL, (unsigned long)tx_base & 0x);
- E1000_WRITE_REG(hw, TDBAH, (unsigned long)tx_base >> 32);
+ E1000_WRITE_REG(hw, TDBAL, (uint32_t)(tdba & 0x));
+ E1000_WRITE_REG(hw, TDBAH, (uint32_t)(tdba >> 32));
E1000_WRITE_REG(hw, TDLEN, 128);
@@ -5103,6 +5104,8 @@ e1000_configure_rx(struct e1000_hw *hw)
{
unsigned long rctl, ctrl_ext;
rx_tail = 0;
+ uint64_t rdba = (unsigned long)rx_base;
+
/* make sure receives are disabled while setting up the descriptors */
rctl = E1000_READ_REG(hw, RCTL);
E1000_WRITE_REG(hw, RCTL, rctl & ~E1000_RCTL_EN);
@@ -5122,8 +5125,8 @@ e1000_configure_rx(struct e1000_hw *hw)
E1000_WRITE_FLUSH(hw);
}
/* Setup the Base and Length of the Rx Descriptor Ring */
- E1000_WRITE_REG(hw, RDBAL, (unsigned long)rx_base & 0x);
- E1000_WRITE_REG(hw, RDBAH, (unsigned long)rx_base >> 32);
+ E1000_WRITE_REG(hw, RDBAL, (uint32_t)(rdba & 0x));
+ E1000_WRITE_REG(hw, RDBAH, (uint32_t)(rdba >> 32));
E1000_WRITE_REG(hw, RDLEN, 128);
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/9] dm: eth: Correctly detect alias in eth_get_dev_by_name()
When given a device name string, we should test if it contains "eth"
before we treat it as an alias.
With this commit, now we are really able to rotate between network
interfaces with driver model (previously it was broken).
Signed-off-by: Bin Meng
---
net/eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/eth.c b/net/eth.c
index 0b4b08a..fbf30b0 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -197,7 +197,7 @@ struct udevice *eth_get_dev_by_name(const char *devname)
struct uclass *uc;
/* Must be longer than 3 to be an alias */
- if (strlen(devname) > strlen("eth")) {
+ if (strstr(devname, "eth") && strlen(devname) > strlen("eth")) {
startp = devname + strlen("eth");
seq = simple_strtoul(startp, &endp, 10);
}
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/9] net: Revert "tftp: adjust settings to be suitable for 100Mbit ethernet"
Testing either pch_gbe or e1000 driver via tftp command on Intel
Crown Bay board, shows the following failure.
TFTP error: 'Unsupported option(s) requested' (8)
It turns out commit 620776d causes this. Revert this commit for now.
Signed-off-by: Bin Meng
---
net/tftp.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/tftp.c b/net/tftp.c
index 18ce84c..89be32a 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -19,10 +19,10 @@
/* Well known TFTP port # */
#define WELL_KNOWN_PORT69
/* Millisecs to timeout for lost pkt */
-#define TIMEOUT100UL
+#define TIMEOUT5000UL
#ifndefCONFIG_NET_RETRY_COUNT
/* # of timeouts before giving up */
-# define TIMEOUT_COUNT 1000
+# define TIMEOUT_COUNT 10
#else
# define TIMEOUT_COUNT (CONFIG_NET_RETRY_COUNT * 2)
#endif
@@ -711,10 +711,10 @@ void tftp_start(enum proto_t protocol)
if (ep != NULL)
timeout_ms = simple_strtol(ep, NULL, 10);
- if (timeout_ms < 10) {
- printf("TFTP timeout (%ld ms) too low, set min = 10 ms\n",
+ if (timeout_ms < 1000) {
+ printf("TFTP timeout (%ld ms) too low, set min = 1000 ms\n",
timeout_ms);
- timeout_ms = 10;
+ timeout_ms = 1000;
}
debug("TFTP blocksize = %i, timeout = %ld ms\n",
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/9] dm: eth: Do not call board_eth_init() or cpu_eth_init()
With driver model, board_eth_init() or cpu_eth_init() is not needed.
Remove the call to these in eth_common_init().
Signed-off-by: Bin Meng
---
net/eth.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/eth.c b/net/eth.c
index d3ec8d6..0b4b08a 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -96,6 +96,7 @@ static void eth_common_init(void)
phy_init();
#endif
+#ifndef CONFIG_DM_ETH
/*
* If board-specific initialization exists, call it.
* If not, call a CPU-specific one
@@ -109,6 +110,7 @@ static void eth_common_init(void)
} else {
printf("Net Initialization Skipped\n");
}
+#endif
}
#ifdef CONFIG_DM_ETH
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/9] net: pch_gbe: Convert to driver model
This commit converts pch_gbe ethernet driver to driver model.
Since this driver is only used by Intel Crown Bay board, the
conversion does not keep the non-dm version.
Signed-off-by: Bin Meng
---
drivers/net/pch_gbe.c | 133 +++---
drivers/net/pch_gbe.h | 2 -
include/netdev.h | 4 --
3 files changed, 73 insertions(+), 66 deletions(-)
diff --git a/drivers/net/pch_gbe.c b/drivers/net/pch_gbe.c
index a03bdc0..004fcf8 100644
--- a/drivers/net/pch_gbe.c
+++ b/drivers/net/pch_gbe.c
@@ -7,10 +7,10 @@
*/
#include
+#include
#include
#include
#include
-#include
#include
#include "pch_gbe.h"
@@ -19,7 +19,7 @@
#endif
static struct pci_device_id supported[] = {
- { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TCF_GBE },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TCF_GBE) },
{ }
};
@@ -62,9 +62,10 @@ static int pch_gbe_mac_write(struct pch_gbe_regs *mac_regs,
u8 *addr)
return -ETIME;
}
-static int pch_gbe_reset(struct eth_device *dev)
+static int pch_gbe_reset(struct udevice *dev)
{
- struct pch_gbe_priv *priv = dev->priv;
+ struct pch_gbe_priv *priv = dev_get_priv(dev);
+ struct eth_pdata *plat = dev_get_platdata(dev);
struct pch_gbe_regs *mac_regs = priv->mac_regs;
ulong start;
@@ -97,7 +98,7 @@ static int pch_gbe_reset(struct eth_device *dev)
* so we have to reload MAC address here in order to
* make linux pch_gbe driver happy.
*/
- return pch_gbe_mac_write(mac_regs, dev->enetaddr);
+ return pch_gbe_mac_write(mac_regs, plat->enetaddr);
}
udelay(10);
@@ -107,9 +108,9 @@ static int pch_gbe_reset(struct eth_device *dev)
return -ETIME;
}
-static void pch_gbe_rx_descs_init(struct eth_device *dev)
+static void pch_gbe_rx_descs_init(struct udevice *dev)
{
- struct pch_gbe_priv *priv = dev->priv;
+ struct pch_gbe_priv *priv = dev_get_priv(dev);
struct pch_gbe_regs *mac_regs = priv->mac_regs;
struct pch_gbe_rx_desc *rx_desc = &priv->rx_desc[0];
int i;
@@ -128,9 +129,9 @@ static void pch_gbe_rx_descs_init(struct eth_device *dev)
&mac_regs->rx_dsc_sw_p);
}
-static void pch_gbe_tx_descs_init(struct eth_device *dev)
+static void pch_gbe_tx_descs_init(struct udevice *dev)
{
- struct pch_gbe_priv *priv = dev->priv;
+ struct pch_gbe_priv *priv = dev_get_priv(dev);
struct pch_gbe_regs *mac_regs = priv->mac_regs;
struct pch_gbe_tx_desc *tx_desc = &priv->tx_desc[0];
@@ -183,9 +184,9 @@ static void pch_gbe_adjust_link(struct pch_gbe_regs
*mac_regs,
return;
}
-static int pch_gbe_init(struct eth_device *dev, bd_t *bis)
+static int pch_gbe_start(struct udevice *dev)
{
- struct pch_gbe_priv *priv = dev->priv;
+ struct pch_gbe_priv *priv = dev_get_priv(dev);
struct pch_gbe_regs *mac_regs = priv->mac_regs;
if (pch_gbe_reset(dev))
@@ -226,18 +227,18 @@ static int pch_gbe_init(struct eth_device *dev, bd_t *bis)
return 0;
}
-static void pch_gbe_halt(struct eth_device *dev)
+static void pch_gbe_stop(struct udevice *dev)
{
- struct pch_gbe_priv *priv = dev->priv;
+ struct pch_gbe_priv *priv = dev_get_priv(dev);
pch_gbe_reset(dev);
phy_shutdown(priv->phydev);
}
-static int pch_gbe_send(struct eth_device *dev, void *packet, int length)
+static int pch_gbe_send(struct udevice *dev, void *packet, int length)
{
- struct pch_gbe_priv *priv = dev->priv;
+ struct pch_gbe_priv *priv = dev_get_priv(dev);
struct pch_gbe_regs *mac_regs = priv->mac_regs;
struct pch_gbe_tx_desc *tx_head, *tx_desc;
u16 frame_ctrl = 0;
@@ -277,15 +278,13 @@ static int pch_gbe_send(struct eth_device *dev, void
*packet, int length)
return -ETIME;
}
-static int pch_gbe_recv(struct eth_device *dev)
+static int pch_gbe_recv(struct udevice *dev, int flags, uchar **packetp)
{
- struct pch_gbe_priv *priv = dev->priv;
+ struct pch_gbe_priv *priv = dev_get_priv(dev);
struct pch_gbe_regs *mac_regs = priv->mac_regs;
- struct pch_gbe_rx_desc *rx_head, *rx_desc;
+ struct pch_gbe_rx_desc *rx_desc;
u32 hw_desc, buffer_addr, length;
- int rx_swp;
- rx_head = &priv->rx_desc[0];
rx_desc = &priv->rx_desc[priv->rx_idx];
readl(&mac_regs->int_st);
@@ -293,11 +292,21 @@ static int pch_gbe_recv(struct eth_device *dev)
/* Just return if not receiving any packet */
if ((u32)rx_desc == hw_desc)
- return 0;
+ return -EAGAIN;
buffer_addr = pci_mem_to_phys(priv->bdf, rx_desc->buffer_addr);
+ *packetp = (uchar *)buffer_addr;
length = rx_desc->rx_words_eob - 3 - ETH_FCS_LEN;
- net_process_received_packet((uchar *)buffer_add
[U-Boot] [PATCH 6/9] x86: crownbay: Convert to use CONFIG_DM_ETH for E1000
Since E1000 driver has been converted to driver model, enable it
on Intel Crown Bay. But the Intel Topcliff GbE driver has not been
converted to driver model yet, disable it for now.
Signed-off-by: Bin Meng
---
board/intel/crownbay/crownbay.c | 6 --
configs/crownbay_defconfig | 2 +-
include/configs/crownbay.h | 1 -
3 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/board/intel/crownbay/crownbay.c b/board/intel/crownbay/crownbay.c
index d6de9fa..3a79e69 100644
--- a/board/intel/crownbay/crownbay.c
+++ b/board/intel/crownbay/crownbay.c
@@ -7,7 +7,6 @@
#include
#include
#include
-#include
#include
int board_early_init_f(void)
@@ -24,8 +23,3 @@ void setup_pch_gpios(u16 gpiobase, const struct pch_gpio_map
*gpio)
{
return;
}
-
-int board_eth_init(bd_t *bis)
-{
- return pci_eth_init(bis);
-}
diff --git a/configs/crownbay_defconfig b/configs/crownbay_defconfig
index 6edd710..f027faf 100644
--- a/configs/crownbay_defconfig
+++ b/configs/crownbay_defconfig
@@ -19,7 +19,7 @@ CONFIG_OF_CONTROL=y
CONFIG_CPU=y
CONFIG_DM_PCI=y
CONFIG_SPI_FLASH=y
-CONFIG_NETDEVICES=y
+CONFIG_DM_ETH=y
CONFIG_E1000=y
CONFIG_VIDEO_VESA=y
CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
diff --git a/include/configs/crownbay.h b/include/configs/crownbay.h
index 998da78..a344c85 100644
--- a/include/configs/crownbay.h
+++ b/include/configs/crownbay.h
@@ -50,7 +50,6 @@
#define CONFIG_CMD_MMC
/* Topcliff Gigabit Ethernet */
-#define CONFIG_PCH_GBE
#define CONFIG_PHYLIB
/* Environment configuration */
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/9] net: pch_gbe: Add Kconfig option
Add Kconfig option in preparation for moving board to use Kconfig. Signed-off-by: Bin Meng --- drivers/net/Kconfig | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 7367d9e..ccaf675 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -79,4 +79,13 @@ config ETH_DESIGNWARE 100Mbit and 1 Gbit operation. You must enable CONFIG_PHYLIB to provide the PHY (physical media interface). +config PCH_GBE + bool "Intel Platform Controller Hub EG20T GMAC driver" + depends on DM_PCI + default n + help + This MAC is present in Intel Platform Controller Hub EG20T. It + supports 10/100/1000 Mbps operation. You must enable CONFIG_PHYLIB + to provide the PHY (physical media interface). + endif # NETDEVICES -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 9/9] x86: crownbay: Enable CONFIG_PCH_GBE
Now that we have converted the pch_gbe driver to driver moel, enable it on Intel Crown Bay board. Signed-off-by: Bin Meng --- configs/crownbay_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/crownbay_defconfig b/configs/crownbay_defconfig index f027faf..f328159 100644 --- a/configs/crownbay_defconfig +++ b/configs/crownbay_defconfig @@ -21,6 +21,7 @@ CONFIG_DM_PCI=y CONFIG_SPI_FLASH=y CONFIG_DM_ETH=y CONFIG_E1000=y +CONFIG_PCH_GBE=y CONFIG_VIDEO_VESA=y CONFIG_FRAMEBUFFER_SET_VESA_MODE=y CONFIG_USB=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 v2 0/4] distro_bootcmd: Add support for booting from ubifs
Hello Hans, Am 25.08.2015 um 09:15 schrieb Hans de Goede: Hi, On 24-08-15 18:57, Scott Wood wrote: On Sat, 2015-08-22 at 20:04 +0200, Hans de Goede wrote: Hi Stephen & Scott, As requested by Stephen here is a new version of my patch-set to add mtd with ubi on top with ubifs on top support to distro_bootcmd, this time using the generic filesystem related commands / code. Scott, can you review the first three patches, and perhaps these should also be merged through your tree ? I don't see anything NAND-specific about them, nor am I particularly familiar with ubifs internals or U-Boot filesystem support... Kyungmin Park and Heiko Schocher are listed as the UBI custodians. My bad, since you are the mtd custodian, I assumed that you would be maintaining ubi[fs] too, my mistake. Heiko, Kyungmin (added to the Cc), can one of you please review the first 3 patches of this set. I think this is post v2015.10 material, once reviewed I can merge it through the sunxi tree, or you can pick it up. I had it on my list, but as I thought (as you ;-) it is 2015.10 material I looked not deeper into it ... Sorry, I look into it ASAP. bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/1] lib/display_options: Fix print_freq
Hello Suriyan,
Am 25.08.2015 um 07:59 schrieb Suriyan Ramasami:
Build without CONFIG_SPL_SERIAL_SUPPORT does not print the cpu freq.
Booting an odroid U3 board, one sees this:
CPU: Exynos4412 @ GHz
instead of:
CPU: Exynos4412 @ 1 GHz
This change was done to get rid of compiler warnings related to the
unused variable 'n' when CONFIG_SPL_SERIAL_SUPPORT is not defined in an
SPL build. Example board: smartweb
Signed-off-by: Suriyan Ramasami
---
v2:
* Get rid of variable 'n' altogether
v1:
* Remove #ifdef CONFIG_SPL_SERIAL_SUPPORT
lib/display_options.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
Thanks!
Acked-by: Heiko Schocher
bye,
Heiko
diff --git a/lib/display_options.c b/lib/display_options.c
index df134cd..83ea4de 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -26,9 +26,6 @@ int display_options (void)
void print_freq(uint64_t freq, const char *s)
{
unsigned long m = 0;
-#if defined(CONFIG_SPL_SERIAL_SUPPORT)
- unsigned long n;
-#endif
uint32_t f;
static const char names[] = {'G', 'M', 'K'};
unsigned long d = 1e9;
@@ -48,9 +45,6 @@ void print_freq(uint64_t freq, const char *s)
}
f = do_div(freq, d);
-#if defined(CONFIG_SPL_SERIAL_SUPPORT)
- n = freq;
-#endif
/* If there's a remainder, show the first few digits */
if (f) {
@@ -63,9 +57,7 @@ void print_freq(uint64_t freq, const char *s)
m = (m / 10) + (m % 100 >= 50);
}
-#if defined(CONFIG_SPL_SERIAL_SUPPORT)
- printf("%lu", n);
-#endif
+ printf("%lu", (unsigned long) freq);
if (m)
printf(".%ld", m);
printf(" %cHz%s", c, s);
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: Enable non-secure access to RTC on sun6i (A31s)
On Tue, Aug 25, 2015 at 3:34 PM, Marc Zyngier wrote:
> On Tue, 25 Aug 2015 10:49:19 +0800
> Chen-Yu Tsai wrote:
>
> Hi,
>
> Thanks for putting this patch together. A few comments below:
>
>> On the A31s the RTC is by default secured. Thus when u-boot
>> loads the kernel in non-secure world, the RTC is unavailable. The
>> SoC has a TrustZone Protection Controller, which can be used to
>> enable non-secure access to the RTC.
>>
>> On the A31 the TZPC doesn't seem to do anything, i.e. changes to
>> its register contents do not affect access to the RTC.
>
> Does it mean that the RTC is still inaccessible? Or that it has always
> been accessible?
Means its always accessible.
>>
>> Signed-off-by: Chen-Yu Tsai
>> ---
>> arch/arm/cpu/armv7/sunxi/Makefile | 1 +
>> arch/arm/cpu/armv7/sunxi/board.c | 5 +
>> arch/arm/cpu/armv7/sunxi/tzpc.c| 18 ++
>> arch/arm/include/asm/arch-sunxi/tzpc.h | 23 +++
>> 4 files changed, 47 insertions(+)
>> create mode 100644 arch/arm/cpu/armv7/sunxi/tzpc.c
>> create mode 100644 arch/arm/include/asm/arch-sunxi/tzpc.h
>>
>> diff --git a/arch/arm/cpu/armv7/sunxi/Makefile
>> b/arch/arm/cpu/armv7/sunxi/Makefile
>> index 76c7e55..459d5d8 100644
>> --- a/arch/arm/cpu/armv7/sunxi/Makefile
>> +++ b/arch/arm/cpu/armv7/sunxi/Makefile
>> @@ -28,6 +28,7 @@ obj-$(CONFIG_MACH_SUN6I)+= clock_sun6i.o
>> obj-$(CONFIG_MACH_SUN7I) += clock_sun4i.o
>> obj-$(CONFIG_MACH_SUN8I) += clock_sun6i.o
>> obj-$(CONFIG_MACH_SUN9I) += clock_sun9i.o
>> +obj-$(CONFIG_MACH_SUN6I) += tzpc.o
>>
>> obj-$(CONFIG_AXP152_POWER) += pmic_bus.o
>> obj-$(CONFIG_AXP209_POWER) += pmic_bus.o
>> diff --git a/arch/arm/cpu/armv7/sunxi/board.c
>> b/arch/arm/cpu/armv7/sunxi/board.c
>> index f01846e..b40198b 100644
>> --- a/arch/arm/cpu/armv7/sunxi/board.c
>> +++ b/arch/arm/cpu/armv7/sunxi/board.c
>> @@ -23,6 +23,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>>
>> #include
>> @@ -115,6 +116,10 @@ void s_init(void)
>> "orr r0, r0, #1 << 6\n"
>> "mcr p15, 0, r0, c1, c0, 1\n");
>> #endif
>> +#if defined CONFIG_MACH_SUN6I
>> + /* Enable non-secure access to the RTC */
>> + tzpc_init();
>> +#endif
>>
>> clock_init();
>> timer_init();
>> diff --git a/arch/arm/cpu/armv7/sunxi/tzpc.c
>> b/arch/arm/cpu/armv7/sunxi/tzpc.c
>> new file mode 100644
>> index 000..5c9c69b
>> --- /dev/null
>> +++ b/arch/arm/cpu/armv7/sunxi/tzpc.c
>> @@ -0,0 +1,18 @@
>> +/*
>> + * (C) Copyright 2015 Chen-Yu Tsai
>> + *
>> + * SPDX-License-Identifier: GPL-2.0+
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +/* Configure Trust Zone Protection Controller */
>> +void tzpc_init(void)
>> +{
>> + struct sunxi_tzpc *tzpc = (struct sunxi_tzpc *)SUNXI_TZPC_BASE;
>> +
>> + /* Enable non-secure access to the RTC */
>> + writel(SUNXI_TZPC_DECPORT0_RTC, &tzpc->decport0_set);
>
> Irk. Seem blow.
>
>> +}
>> diff --git a/arch/arm/include/asm/arch-sunxi/tzpc.h
>> b/arch/arm/include/asm/arch-sunxi/tzpc.h
>> new file mode 100644
>> index 000..ba4d43b
>> --- /dev/null
>> +++ b/arch/arm/include/asm/arch-sunxi/tzpc.h
>> @@ -0,0 +1,23 @@
>> +/*
>> + * (C) Copyright 2015 Chen-Yu Tsai
>> + *
>> + * SPDX-License-Identifier: GPL-2.0+
>> + */
>> +
>> +#ifndef _SUNXI_TZPC_H
>> +#define _SUNXI_TZPC_H
>
> Why is this sunxi specific? This seems to describe a standard ARM BP147
> (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dto0015a/index.html),
> so I'd expect the various offsets and the file location to reflect this.
>
> Another platform (FSL 2085) seems to use the same IP, so it would make
> sense to clean that part of the code too.
I guess we could make this generic. Seems samsung uses this as well.
>> +
>> +#ifndef __ASSEMBLY__
>> +struct sunxi_tzpc {
>> + u32 r0size; /* 0x00 Size of secure RAM region */
>> + u32 decport0_status;/* 0x04 Status of decode protection port 0 */
>> + u32 decport0_set; /* 0x08 Set decode protection port 0 */
>> + u32 decport0_clear; /* 0x0c Clear decode protection port 0 */
>> +};
>
> I'm not overly fond of this way to describe a set of contiguous
> register. It tends to be fairly fragile (the compiler is free to
> insert some padding) and prevents the use of offsets from assembly code.
Seems this is how we are doing things in U-boot...
I'm OK either way.
>> +#endif
>> +
>> +#define SUNXI_TZPC_DECPORT0_RTC (1 << 1)
>> +
>> +void tzpc_init(void);
>
> And this won't help if you have assembly code either.
>
>> +
>> +#endif /* _SUNXI_TZPC_H */
>
> If I can suggest something, it would be to make this something generic,
> with a standard config option describing the base, a set of offsets
> from the base (as #defines), and then a set of accessors accessible from
> C code.
>
> LS2085 could also be cleaned up to reuse the same offsets (instead of
> hardcoding the register addresses).
OK. Will loo
Re: [U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)
Hi Joe,
On Tue, Aug 25, 2015 at 12:24 PM, Joe Hershberger
wrote:
> Hi Bin,
>
> On Mon, Aug 24, 2015 at 11:05 PM, Bin Meng wrote:
>> Hi Joe,
>>
>> On Tue, Aug 25, 2015 at 11:42 AM, Joe Hershberger
>> wrote:
>>> Hi Bin,
>>>
>>> On Mon, Aug 24, 2015 at 9:25 PM, Bin Meng wrote:
Hi,
With latest u-boot/master, TFTP is seriously broken.
=> tftp 10 bzImage
Speed: 100, full duplex
Using pch_gbe device
TFTP from server 10.10.0.8; our IP address is 10.10.0.100; sending
through gateway 10.10.0.1
Filename 'bzImage'.
Load address: 0x10
Loading: T
TFTP error: 'Unsupported option(s) requested' (8)
Starting again
>>>
>>> I'm guessing you are having an issue that the TFTP server you are
>>> using for some reason does not allow a timeout as small as 10 ms. What
>>> server are you testing against? Can you experiment and find the lowest
>>> that it accepts? Maybe there is a compromise we can reach that still
>>> works with most (all?) servers and also improves the behavior in a
>>> lossy environment.
>>
>> I am using a CentOS server, with /etc/xinetd.d/tftp configuration below.
>>
>> service tftp
>> {
>> socket_type = dgram
>> protocol= udp
>> wait= yes
>> user= root
>> server = /usr/sbin/in.tftpd
>> server_args = -s /tftpboot
>> disable = no
>> per_source = 11
>> cps = 100 2
>> flags = IPv4
>> }
>>
>> I don't see an entry to change timeout settings.
>
> I didn't mean to change the server settings; I meant can you adjust
> the U-Boot code until your server doesn't reject the option?
>
I would like to revert this commit before we find a solution. Even if
I find a proper value to get tftp work again in my network
environment, we don't know if this commit breaks someone else's board.
After all, this timeout value has been there for years (?), and I
believe it is a safe value for all the boards that are actively
maintained.
[snip]
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: Enable non-secure access to RTC on sun6i (A31s)
On Tue, 25 Aug 2015 10:49:19 +0800
Chen-Yu Tsai wrote:
Hi,
Thanks for putting this patch together. A few comments below:
> On the A31s the RTC is by default secured. Thus when u-boot
> loads the kernel in non-secure world, the RTC is unavailable. The
> SoC has a TrustZone Protection Controller, which can be used to
> enable non-secure access to the RTC.
>
> On the A31 the TZPC doesn't seem to do anything, i.e. changes to
> its register contents do not affect access to the RTC.
Does it mean that the RTC is still inaccessible? Or that it has always
been accessible?
>
> Signed-off-by: Chen-Yu Tsai
> ---
> arch/arm/cpu/armv7/sunxi/Makefile | 1 +
> arch/arm/cpu/armv7/sunxi/board.c | 5 +
> arch/arm/cpu/armv7/sunxi/tzpc.c| 18 ++
> arch/arm/include/asm/arch-sunxi/tzpc.h | 23 +++
> 4 files changed, 47 insertions(+)
> create mode 100644 arch/arm/cpu/armv7/sunxi/tzpc.c
> create mode 100644 arch/arm/include/asm/arch-sunxi/tzpc.h
>
> diff --git a/arch/arm/cpu/armv7/sunxi/Makefile
> b/arch/arm/cpu/armv7/sunxi/Makefile
> index 76c7e55..459d5d8 100644
> --- a/arch/arm/cpu/armv7/sunxi/Makefile
> +++ b/arch/arm/cpu/armv7/sunxi/Makefile
> @@ -28,6 +28,7 @@ obj-$(CONFIG_MACH_SUN6I)+= clock_sun6i.o
> obj-$(CONFIG_MACH_SUN7I) += clock_sun4i.o
> obj-$(CONFIG_MACH_SUN8I) += clock_sun6i.o
> obj-$(CONFIG_MACH_SUN9I) += clock_sun9i.o
> +obj-$(CONFIG_MACH_SUN6I) += tzpc.o
>
> obj-$(CONFIG_AXP152_POWER) += pmic_bus.o
> obj-$(CONFIG_AXP209_POWER) += pmic_bus.o
> diff --git a/arch/arm/cpu/armv7/sunxi/board.c
> b/arch/arm/cpu/armv7/sunxi/board.c
> index f01846e..b40198b 100644
> --- a/arch/arm/cpu/armv7/sunxi/board.c
> +++ b/arch/arm/cpu/armv7/sunxi/board.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -115,6 +116,10 @@ void s_init(void)
> "orr r0, r0, #1 << 6\n"
> "mcr p15, 0, r0, c1, c0, 1\n");
> #endif
> +#if defined CONFIG_MACH_SUN6I
> + /* Enable non-secure access to the RTC */
> + tzpc_init();
> +#endif
>
> clock_init();
> timer_init();
> diff --git a/arch/arm/cpu/armv7/sunxi/tzpc.c b/arch/arm/cpu/armv7/sunxi/tzpc.c
> new file mode 100644
> index 000..5c9c69b
> --- /dev/null
> +++ b/arch/arm/cpu/armv7/sunxi/tzpc.c
> @@ -0,0 +1,18 @@
> +/*
> + * (C) Copyright 2015 Chen-Yu Tsai
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#include
> +#include
> +#include
> +
> +/* Configure Trust Zone Protection Controller */
> +void tzpc_init(void)
> +{
> + struct sunxi_tzpc *tzpc = (struct sunxi_tzpc *)SUNXI_TZPC_BASE;
> +
> + /* Enable non-secure access to the RTC */
> + writel(SUNXI_TZPC_DECPORT0_RTC, &tzpc->decport0_set);
Irk. Seem blow.
> +}
> diff --git a/arch/arm/include/asm/arch-sunxi/tzpc.h
> b/arch/arm/include/asm/arch-sunxi/tzpc.h
> new file mode 100644
> index 000..ba4d43b
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-sunxi/tzpc.h
> @@ -0,0 +1,23 @@
> +/*
> + * (C) Copyright 2015 Chen-Yu Tsai
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#ifndef _SUNXI_TZPC_H
> +#define _SUNXI_TZPC_H
Why is this sunxi specific? This seems to describe a standard ARM BP147
(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dto0015a/index.html),
so I'd expect the various offsets and the file location to reflect this.
Another platform (FSL 2085) seems to use the same IP, so it would make
sense to clean that part of the code too.
> +
> +#ifndef __ASSEMBLY__
> +struct sunxi_tzpc {
> + u32 r0size; /* 0x00 Size of secure RAM region */
> + u32 decport0_status;/* 0x04 Status of decode protection port 0 */
> + u32 decport0_set; /* 0x08 Set decode protection port 0 */
> + u32 decport0_clear; /* 0x0c Clear decode protection port 0 */
> +};
I'm not overly fond of this way to describe a set of contiguous
register. It tends to be fairly fragile (the compiler is free to
insert some padding) and prevents the use of offsets from assembly code.
> +#endif
> +
> +#define SUNXI_TZPC_DECPORT0_RTC (1 << 1)
> +
> +void tzpc_init(void);
And this won't help if you have assembly code either.
> +
> +#endif /* _SUNXI_TZPC_H */
If I can suggest something, it would be to make this something generic,
with a standard config option describing the base, a set of offsets
from the base (as #defines), and then a set of accessors accessible from
C code.
LS2085 could also be cleaned up to reuse the same offsets (instead of
hardcoding the register addresses).
Thanks,
M.
--
Jazz is not dead. It just smells funny.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] video: cfb_console: Allow VGA device to work without i8042 keyboard
Hi Bin, On Mon, 24 Aug 2015 01:00:07 -0700 Bin Meng wrote: > So far if CONFIG_VGA_AS_SINGLE_DEVICE is not defined, the VGA device > will try to initialize a keyboard device (for x86, it is i8042). But > if i8042 controller initialization fails (eg: there is no keyboard > connected to the PS/2 port), drv_video_init() just simply returns. > This kills the opportunity of using a usb keyboard later with the vga > console, as the vga initialization part is actually ok, only keyboard > part fails. Change the code logic to allow this. > > Signed-off-by: Bin Meng > Reviewed-by: Simon Glass Acked-by: Anatolij Gustschin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: Enable non-secure access to RTC on sun6i (A31s)
Hi,
On 25-08-15 09:40, Chen-Yu Tsai wrote:
On Tue, Aug 25, 2015 at 3:34 PM, Marc Zyngier wrote:
On Tue, 25 Aug 2015 10:49:19 +0800
Chen-Yu Tsai wrote:
Hi,
Thanks for putting this patch together. A few comments below:
On the A31s the RTC is by default secured. Thus when u-boot
loads the kernel in non-secure world, the RTC is unavailable. The
SoC has a TrustZone Protection Controller, which can be used to
enable non-secure access to the RTC.
On the A31 the TZPC doesn't seem to do anything, i.e. changes to
its register contents do not affect access to the RTC.
Does it mean that the RTC is still inaccessible? Or that it has always
been accessible?
Means its always accessible.
Ah, so what you're saying is that on A31 the RTC is always accessible and
on A31s it depends on the TZPC settings ?
That does not make sense since both are the same die used in a different
package, so chances are this does not depend on A31 vs A31s but on a
difference in revision of the die.
It does not matter, we can just flip the bit in the TZPC everywhere to
make sure the kernel has access to the RTC.
Regards,
Hans
Signed-off-by: Chen-Yu Tsai
---
arch/arm/cpu/armv7/sunxi/Makefile | 1 +
arch/arm/cpu/armv7/sunxi/board.c | 5 +
arch/arm/cpu/armv7/sunxi/tzpc.c| 18 ++
arch/arm/include/asm/arch-sunxi/tzpc.h | 23 +++
4 files changed, 47 insertions(+)
create mode 100644 arch/arm/cpu/armv7/sunxi/tzpc.c
create mode 100644 arch/arm/include/asm/arch-sunxi/tzpc.h
diff --git a/arch/arm/cpu/armv7/sunxi/Makefile
b/arch/arm/cpu/armv7/sunxi/Makefile
index 76c7e55..459d5d8 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_MACH_SUN6I)+= clock_sun6i.o
obj-$(CONFIG_MACH_SUN7I) += clock_sun4i.o
obj-$(CONFIG_MACH_SUN8I) += clock_sun6i.o
obj-$(CONFIG_MACH_SUN9I) += clock_sun9i.o
+obj-$(CONFIG_MACH_SUN6I) += tzpc.o
obj-$(CONFIG_AXP152_POWER) += pmic_bus.o
obj-$(CONFIG_AXP209_POWER) += pmic_bus.o
diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
index f01846e..b40198b 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -115,6 +116,10 @@ void s_init(void)
"orr r0, r0, #1 << 6\n"
"mcr p15, 0, r0, c1, c0, 1\n");
#endif
+#if defined CONFIG_MACH_SUN6I
+ /* Enable non-secure access to the RTC */
+ tzpc_init();
+#endif
clock_init();
timer_init();
diff --git a/arch/arm/cpu/armv7/sunxi/tzpc.c b/arch/arm/cpu/armv7/sunxi/tzpc.c
new file mode 100644
index 000..5c9c69b
--- /dev/null
+++ b/arch/arm/cpu/armv7/sunxi/tzpc.c
@@ -0,0 +1,18 @@
+/*
+ * (C) Copyright 2015 Chen-Yu Tsai
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include
+#include
+#include
+
+/* Configure Trust Zone Protection Controller */
+void tzpc_init(void)
+{
+ struct sunxi_tzpc *tzpc = (struct sunxi_tzpc *)SUNXI_TZPC_BASE;
+
+ /* Enable non-secure access to the RTC */
+ writel(SUNXI_TZPC_DECPORT0_RTC, &tzpc->decport0_set);
Irk. Seem blow.
+}
diff --git a/arch/arm/include/asm/arch-sunxi/tzpc.h
b/arch/arm/include/asm/arch-sunxi/tzpc.h
new file mode 100644
index 000..ba4d43b
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/tzpc.h
@@ -0,0 +1,23 @@
+/*
+ * (C) Copyright 2015 Chen-Yu Tsai
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef _SUNXI_TZPC_H
+#define _SUNXI_TZPC_H
Why is this sunxi specific? This seems to describe a standard ARM BP147
(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dto0015a/index.html),
so I'd expect the various offsets and the file location to reflect this.
Another platform (FSL 2085) seems to use the same IP, so it would make
sense to clean that part of the code too.
I guess we could make this generic. Seems samsung uses this as well.
+
+#ifndef __ASSEMBLY__
+struct sunxi_tzpc {
+ u32 r0size; /* 0x00 Size of secure RAM region */
+ u32 decport0_status;/* 0x04 Status of decode protection port 0 */
+ u32 decport0_set; /* 0x08 Set decode protection port 0 */
+ u32 decport0_clear; /* 0x0c Clear decode protection port 0 */
+};
I'm not overly fond of this way to describe a set of contiguous
register. It tends to be fairly fragile (the compiler is free to
insert some padding) and prevents the use of offsets from assembly code.
Seems this is how we are doing things in U-boot...
I'm OK either way.
+#endif
+
+#define SUNXI_TZPC_DECPORT0_RTC (1 << 1)
+
+void tzpc_init(void);
And this won't help if you have assembly code either.
+
+#endif /* _SUNXI_TZPC_H */
If I can suggest something, it would be to make this something generic,
with a standard config option describing the base, a set of offsets
from the base (as #defines), and then a set of accessors accessible f
[U-Boot] [PATCH] picosam9g45: adopt CONFIG_SYS_PROMPT
Commit 181bd9dc61d2da88b78f1c1138a685dae39354d6 introduced Kconfig selection for SYS_PROMPT. When applying the new picosam9g45 board this change slipped through, adopt it. Signed-off-by: Andreas Bießmann --- configs/picosam9g45_defconfig | 1 + include/configs/picosam9g45.h | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/picosam9g45_defconfig b/configs/picosam9g45_defconfig index 4128193..ccca1ca 100644 --- a/configs/picosam9g45_defconfig +++ b/configs/picosam9g45_defconfig @@ -3,6 +3,7 @@ CONFIG_ARCH_AT91=y CONFIG_TARGET_PICOSAM9G45=y CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS="AT91SAM9M10G45,SYS_USE_MMC" +CONFIG_SYS_PROMPT="U-Boot> " # CONFIG_CMD_BDI is not set # CONFIG_CMD_IMI is not set # CONFIG_CMD_IMLS is not set diff --git a/include/configs/picosam9g45.h b/include/configs/picosam9g45.h index e3039c2..9e9b1d0 100644 --- a/include/configs/picosam9g45.h +++ b/include/configs/picosam9g45.h @@ -156,7 +156,6 @@ #define CONFIG_BAUDRATE115200 -#define CONFIG_SYS_PROMPT "U-Boot> " #define CONFIG_SYS_CBSIZE 256 #define CONFIG_SYS_MAXARGS 16 #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE \ -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/7] video: ct69000: Remove unused codes
On Mon, 24 Aug 2015 01:00:09 -0700 Bin Meng wrote: > Remove unused CONFIG_USE_CPCIDVI wrapped codes. > > Signed-off-by: Bin Meng Acked-by: Anatolij Gustschin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] video: cfb_console: Allow VGA device to work without i8042 keyboard
Hi Simon, On Mon, 24 Aug 2015 22:13:41 -0600 Simon Glass wrote: > On 24 August 2015 at 02:00, Bin Meng wrote: > > So far if CONFIG_VGA_AS_SINGLE_DEVICE is not defined, the VGA device > > will try to initialize a keyboard device (for x86, it is i8042). But > > if i8042 controller initialization fails (eg: there is no keyboard > > connected to the PS/2 port), drv_video_init() just simply returns. > > This kills the opportunity of using a usb keyboard later with the vga > > console, as the vga initialization part is actually ok, only keyboard > > part fails. Change the code logic to allow this. > > > > Signed-off-by: Bin Meng > > Reviewed-by: Simon Glass > > What are your thoughts on this patch, please? it is okay for me, please merge it with other patches in this series. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH
On 07/28/2015 05:00 PM, Tom Rini wrote: > On Sun, Jul 26, 2015 at 06:48:15PM +0200, Paul Kocialkowski wrote: > >> In order to achieve reproducible builds in U-Boot, timestamps that are >> defined >> at build-time have to be somewhat eliminated. The SOURCE_DATE_EPOCH >> environment >> variable allows setting a fixed value for those timestamps. >> >> Simply by setting SOURCE_DATE_EPOCH to a fixed value, a number of targets >> can be >> built reproducibly. This is the case for e.g. sunxi devices. >> >> However, some other devices might need some more tweaks, especially regarding >> the image generation tools. >> >> Signed-off-by: Paul Kocialkowski > > Applied to u-boot/master, thanks! This commit breaks build on non GNU hosts (like OS X and persumably other *BSD hosts). Before, those hosts where supported, so for me this has to be fixed for 2015.10 We need a) some mechanism to search for the GNU date variant or b) some wrapper to provide the correct output on those host machines. I vote for a), it is acceptable to have the GNU date available but we should error on 'no GNU date available'. Furthermore we need to have the date command exchangeable by e.g. gdate, gnudate, ... maybe with full path. Andreas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] exynos: Rise ARM voltage to 1.1V for chained bootloaders
If board uses downstream Chrome OS U-Boot as first stage
bootloader and upstream version is chained second stage,
1.1V is minimum voltage borderline.
Signed-off-by: Misha Komarovskiy
---
board/samsung/common/exynos5-dt.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/board/samsung/common/exynos5-dt.c
b/board/samsung/common/exynos5-dt.c
index 7d1b88a..a550d00 100644
--- a/board/samsung/common/exynos5-dt.c
+++ b/board/samsung/common/exynos5-dt.c
@@ -121,11 +121,12 @@ int exynos_power_init(void)
return ret;
/*
-* This would normally be 1.3V, but since we are running slowly 1V
+* This would normally be 1.3V, but since we are running slowly 1.1V
* is enough. For spring it helps reduce CPU temperature and avoid
-* hangs with the case open.
+* hangs with the case open. 1.1V is minimum voltage borderline for
+* chained bootloaders.
*/
- ret = exynos_set_regulator("vdd_arm", 100);
+ ret = exynos_set_regulator("vdd_arm", 110);
if (ret)
return ret;
ret = exynos_set_regulator("vdd_int", 1012500);
--
1.8.4.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)
Hi Pavel, On Tue, Aug 25, 2015 at 3:12 PM, Pavel Machek wrote: > On Tue 2015-08-25 10:25:35, Bin Meng wrote: >> Hi, >> >> With latest u-boot/master, TFTP is seriously broken. > > Sorry about that. > >> => tftp 10 bzImage >> Speed: 100, full duplex >> Using pch_gbe device >> TFTP from server 10.10.0.8; our IP address is 10.10.0.100; sending >> through gateway 10.10.0.1 >> Filename 'bzImage'. >> Load address: 0x10 >> Loading: T >> TFTP error: 'Unsupported option(s) requested' (8) >> Starting again >> >> git bisect shows the following commit broke the TFTP > > I was not intentionally changing the packets being sent. > > Could you try to capture tcpdump, including contents of packet, > ideally in both working and broken sessions? > Yep, I will do that. I also tested a tftpd Windows server (http://tftpd32.jounin.net) and it looks that this Windows server is immune to this commit. > Could you try setting > > -#define TIMEOUT5000UL > +#define TIMEOUT100UL > > in net/tftp.c to something like 1000UL? > Could you please elaborate more on what this commit is trying to fix, or improve? From the commit message, I don't quite understand "With 5 seconds timeout, 10 retries maximum, tftp is impossible even on local network with single full-speed TCP connection". Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v5, 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot
Hi Paul, Tom,
i am failing bring up my AM335x boards (tseries, kwb) with bare UART
connection since introducing this change.
--
U-Boot SPL 2015.10-rc2-00079-g35f2192-dirty (Aug 25 2015 - 07:34:24)
boot device - 0
SPL: Unsupported Boot Device (0)!
### ERROR ### Please RESET the board ###
---
The source of my problem is the __weak function in omap-common/boot-common.c
__weak u32 omap_sys_boot_device(void)
{
return BOOT_DEVICE_NONE;
}
which one is called on line #82
For my understanding this function should be called allways if chip has
basically support for some BOOT_DEVICE_x __AND__ there is no
implementation for it - the function should prevent target from stalling
with selecting another (hopefully working) boot-device.
Right ?
I am not sure at this time how to deal with the facts ... i see several
possibilities:
a)
i have to implement some "omap_sys_boot_device" function in my boards -
this would maybe sometimes comfortable but i think this is not inventors
mind. It would be more convenient to implement it in some common place
for AM335x or OMAP. But what do with the information about SYS_BOOT pins
? they always represent a boot-order ... which boot-device should it take ?
b) and/or something is wrong with the #ifdef ... construct at line #67 -
In fact there is a problem with
/
defined(BOOT_DEVICE_USBETH) && !defined(CONFIG_SPL_USBETH_SUPPORT)/
basicaly BOOT_DEVICE_USBETH is defined in spl.h but in my configuration
there is no #define for CONFIG_SPL_USBETH_SUPPORT and so the following
switch/case calls in case of BOOT_DEVICE_UART this weak function.
further i think that this construct isn't complete yet, because it wants
to handle all peripheral booting on AM335x or OMAP in general.
following peripherals are currently handled:
BOOT_DEVICE_UART
BOOT_DEVICE_USB
BOOT_DEVICE_USBETH
but there is also
BOOT_DEVICE_CPGMAC
Summary i think this changeset isn't complete.
How we want to deal with this facts ?
best regards,
Hannes
On 28.07.2015 16:59, Tom Rini wrote:
On Wed, Jul 15, 2015 at 04:02:23PM +0200, Paul Kocialkowski wrote:
OMAP devices might boot from peripheral devices, such as UART or USB.
When that happens, the U-Boot SPL tries to boot the next stage (complete U-Boot)
from that peripheral device, but in most cases, this is not a valid boot device.
This introduces a fallback option that reads the SYS_BOOT pins, that are used by
the bootrom to determine which device to boot from. It is intended for the
SYS_BOOT value to be interpreted in the memory-preferred scheme, so that the
U-Boot SPL can load the next stage from a valid location.
Practically, this options allows loading the U-Boot SPL through USB and have it
load the next stage according to the memory device selected by SYS_BOOT instead
of stalling.
Signed-off-by: Paul Kocialkowski
Applied to u-boot/master, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/t4240qds: add support of reading Core voltage
From: Shaohui Xie
A U-boot CMD vdd_read is implemented to read Core voltage.
Signed-off-by: Shaohui Xie
---
board/freescale/t4qds/t4240qds.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/board/freescale/t4qds/t4240qds.c b/board/freescale/t4qds/t4240qds.c
index 4f2cccd..56273e4 100644
--- a/board/freescale/t4qds/t4240qds.c
+++ b/board/freescale/t4qds/t4240qds.c
@@ -887,8 +887,38 @@ static int do_vdd_adjust(cmd_tbl_t *cmdtp,
return 0;
}
+static int do_vdd_read(cmd_tbl_t *cmdtp,
+ int flag, int argc,
+ char * const argv[])
+{
+ int vdd, ret;
+
+ if (argc < 1)
+ return CMD_RET_USAGE;
+
+ ret = select_i2c_ch_pca9547(I2C_MUX_CH_VOL_MONITOR);
+ if (ret) {
+ printf("VID: I2c failed to switch channel\n");
+ return 0;
+ }
+
+ vdd = read_voltage();
+ if (vdd < 0)
+ printf("VID: Could not read voltage\n");
+ else
+ printf("VID: Core voltage is at %d mV\n", vdd);
+
+ return 0;
+}
+
U_BOOT_CMD(
vdd_override, 2, 0, do_vdd_adjust,
"Override VDD",
"- override with the voltage specified in mV, eg. 1050"
);
+
+U_BOOT_CMD(
+ vdd_read, 1, 0, do_vdd_read,
+ "read VDD",
+ " - Read the voltage specified in mV"
+)
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)
On Tue, Aug 25, 2015 at 4:58 PM, Bin Meng wrote: > Hi Pavel, > > On Tue, Aug 25, 2015 at 3:12 PM, Pavel Machek wrote: >> On Tue 2015-08-25 10:25:35, Bin Meng wrote: >>> Hi, >>> >>> With latest u-boot/master, TFTP is seriously broken. >> >> Sorry about that. >> >>> => tftp 10 bzImage >>> Speed: 100, full duplex >>> Using pch_gbe device >>> TFTP from server 10.10.0.8; our IP address is 10.10.0.100; sending >>> through gateway 10.10.0.1 >>> Filename 'bzImage'. >>> Load address: 0x10 >>> Loading: T >>> TFTP error: 'Unsupported option(s) requested' (8) >>> Starting again >>> >>> git bisect shows the following commit broke the TFTP >> >> I was not intentionally changing the packets being sent. >> >> Could you try to capture tcpdump, including contents of packet, >> ideally in both working and broken sessions? >> > > Yep, I will do that. I also tested a tftpd Windows server > (http://tftpd32.jounin.net) and it looks that this Windows server is > immune to this commit. > >> Could you try setting >> >> -#define TIMEOUT5000UL >> +#define TIMEOUT100UL >> >> in net/tftp.c to something like 1000UL? >> > > Could you please elaborate more on what this commit is trying to fix, > or improve? From the commit message, I don't quite understand "With 5 > seconds timeout, 10 retries maximum, tftp is impossible even on local > network with single full-speed TCP connection". > OK, I am now pretty sure this commit should be reverted. This commit is a spec violation to RFC 2349 in which it defines the timeout minimum value should be 1. With this commit change, we set timeout to 100ms which creates a wrong option timeout value = 0, when sending tftp read request to the server. The Linux xinitd server strictly follows the RFC and reports 'Unsupported option(s) requested' (8) while the Windows server is quite forgiving. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] net: Revert "tftp: adjust settings to be suitable for 100Mbit ethernet"
Hi Joe,
On Tue, Aug 25, 2015 at 3:22 PM, Bin Meng wrote:
> Testing either pch_gbe or e1000 driver via tftp command on Intel
> Crown Bay board, shows the following failure.
>
> TFTP error: 'Unsupported option(s) requested' (8)
>
> It turns out commit 620776d causes this. Revert this commit for now.
Please check http://lists.denx.de/pipermail/u-boot/2015-August/225187.html
on why this commit should be reverted.
Let me know if you have different thoughts (eg: I can respin a v2 to
explicitly mention in the commit message that commit 620776d is a spec
violation to RTC 2349 thus we need revert it)
>
> Signed-off-by: Bin Meng
> ---
>
> net/tftp.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/net/tftp.c b/net/tftp.c
> index 18ce84c..89be32a 100644
> --- a/net/tftp.c
> +++ b/net/tftp.c
> @@ -19,10 +19,10 @@
> /* Well known TFTP port # */
> #define WELL_KNOWN_PORT69
> /* Millisecs to timeout for lost pkt */
> -#define TIMEOUT100UL
> +#define TIMEOUT5000UL
> #ifndefCONFIG_NET_RETRY_COUNT
> /* # of timeouts before giving up */
> -# define TIMEOUT_COUNT 1000
> +# define TIMEOUT_COUNT 10
> #else
> # define TIMEOUT_COUNT (CONFIG_NET_RETRY_COUNT * 2)
> #endif
> @@ -711,10 +711,10 @@ void tftp_start(enum proto_t protocol)
> if (ep != NULL)
> timeout_ms = simple_strtol(ep, NULL, 10);
>
> - if (timeout_ms < 10) {
> - printf("TFTP timeout (%ld ms) too low, set min = 10 ms\n",
> + if (timeout_ms < 1000) {
> + printf("TFTP timeout (%ld ms) too low, set min = 1000 ms\n",
>timeout_ms);
> - timeout_ms = 10;
> + timeout_ms = 1000;
> }
>
> debug("TFTP blocksize = %i, timeout = %ld ms\n",
> --
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] expose eth_is_active() function to test network device state
Am 24.08.2015 um 19:02 schrieb Joe Hershberger: Hi Simon, On Mon, Aug 24, 2015 at 11:59 AM, Simon Glass wrote: Hi Bernhard, [...] i.e. sunxi GMAC (by simply adding #define CONFIG_NETCONSOLE). In that case how about adding that config to that board? Does it cause problems for other people? I'll pile on and agree that it would be great to have at least one board with this enabled, and even better to have one that supports DM_ETH and one that does not. -Joe grep "#define CONFIG_NETCONSOLE" include/configs/* lists a considerable number of boards where NETCONSOLE seems to be active by default. I guess none of these has moved to DM_ETH yet, or I'd have expected reports of "broken" builds. If you're all for it, I can of course enable NETCONSOLE for the Banana Pi/Pro. (It may even be done across-the-board for all SUNXI_[EG]MAC configs?) Personally, I'm a bit reluctant to "enforce" this setting, because until now my understanding was that NETCONSOLE is supposed to be mostly optional, i.e. at user's choice - especially for boards where other means of input/output are readily available (serial console, vga, usb keyboard). I don't expect this to create problems, it just adds code that probably won't be used most of the time (as long as "nc" doesn't get used for stdin/stdout). I guess the proper way to do it would be to introduce Kconfig support; will this do? diff --git a/net/Kconfig b/net/Kconfig index 915371d..87c1729 100644 --- a/net/Kconfig +++ b/net/Kconfig @@ -16,4 +16,10 @@ config NET_RANDOM_ETHADDR A new MAC address will be generated on every boot and it will not be added to the environment. +config NETCONSOLE + bool "Netconsole support" + help + Support the 'nc' input/output device for networked console. + See README.NetConsole for details. + endif # if NET In case this gets a "go", I'd prepare a v2 patch set that includes enabling CONFIG_NETCONSOLE via Bananapi_defconfig / Bananapro_defconfig. Regards, B. Nortmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Reproducible-builds] [U-Boot, v2] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH
On 2015-08-25, Andreas Bießmann wrote: > On 07/28/2015 05:00 PM, Tom Rini wrote: >> On Sun, Jul 26, 2015 at 06:48:15PM +0200, Paul Kocialkowski wrote: >>> In order to achieve reproducible builds in U-Boot, timestamps that are >>> defined >>> at build-time have to be somewhat eliminated. The SOURCE_DATE_EPOCH >>> environment >>> variable allows setting a fixed value for those timestamps. >>> >>> Simply by setting SOURCE_DATE_EPOCH to a fixed value, a number of targets >>> can be >>> built reproducibly. This is the case for e.g. sunxi devices. >>> >>> However, some other devices might need some more tweaks, especially >>> regarding >>> the image generation tools. >>> >>> Signed-off-by: Paul Kocialkowski >> >> Applied to u-boot/master, thanks! > > This commit breaks build on non GNU hosts (like OS X and persumably > other *BSD hosts). Before, those hosts where supported, so for me this > has to be fixed for 2015.10 > > We need a) some mechanism to search for the GNU date variant or b) some > wrapper to provide the correct output on those host machines. > > I vote for a), it is acceptable to have the GNU date available but we > should error on 'no GNU date available'. Furthermore we need to have the > date command exchangeable by e.g. gdate, gnudate, ... maybe with full path. There was a proposed patch which only uses the GNU date extensions if SOURCE_DATE_EPOCH environment variable is set, would this sufficiently address your concerns, at least for the short term? Message-Id: <1438337042-30762-1-git-send-email-judge.pack...@gmail.com> http://lists.denx.de/pipermail/u-boot/2015-August/221429.html live well, vagrant signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH
On Thu, Jul 30, 2015 at 11:54 PM, Bin Meng wrote: > This commit breaks the following commit: > > commit f3f431a712729a1af94d01bd1bfde17a252ff02c > Author: Chris Packham > Date: Sun May 10 21:02:09 2015 +1200 > > Makefile: Add U_BOOT_TZ and include in version > > Define U_BOOT_TZ alongside U_BOOT_TIME and U_BOOT_DATE and use it to > include the timezone in the version output. > > Acked-by: Simon Glass > Signed-off-by: Chris Packham > > Before this commit I have: > U-Boot 2015.07-00345-g9c57487 (Jul 31 2015 - 10:49:31 +0800) > > After this commit I have: > U-Boot 2015.07-00346-gf3f431a (Jul 31 2015 - 02:50:54 +) > > As you see: the timezone information is missing, and U-Boot's > timestamp is now GMT+0 (the correct one should be GMT+8) > > Is this intended behavior? Or if not, please fix it. I notice the same behavior here and I agree it would be nice to fix this. Thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: Enable non-secure access to RTC on sun6i (A31s)
On 25/08/15 08:40, Chen-Yu Tsai wrote:
> On Tue, Aug 25, 2015 at 3:34 PM, Marc Zyngier wrote:
>> On Tue, 25 Aug 2015 10:49:19 +0800
>> Chen-Yu Tsai wrote:
>>
>> Hi,
>>
>> Thanks for putting this patch together. A few comments below:
>>
>>> On the A31s the RTC is by default secured. Thus when u-boot
>>> loads the kernel in non-secure world, the RTC is unavailable. The
>>> SoC has a TrustZone Protection Controller, which can be used to
>>> enable non-secure access to the RTC.
>>>
>>> On the A31 the TZPC doesn't seem to do anything, i.e. changes to
>>> its register contents do not affect access to the RTC.
>>
>> Does it mean that the RTC is still inaccessible? Or that it has always
>> been accessible?
>
> Means its always accessible.
>
>>>
>>> Signed-off-by: Chen-Yu Tsai
>>> ---
>>> arch/arm/cpu/armv7/sunxi/Makefile | 1 +
>>> arch/arm/cpu/armv7/sunxi/board.c | 5 +
>>> arch/arm/cpu/armv7/sunxi/tzpc.c| 18 ++
>>> arch/arm/include/asm/arch-sunxi/tzpc.h | 23 +++
>>> 4 files changed, 47 insertions(+)
>>> create mode 100644 arch/arm/cpu/armv7/sunxi/tzpc.c
>>> create mode 100644 arch/arm/include/asm/arch-sunxi/tzpc.h
>>>
>>> diff --git a/arch/arm/cpu/armv7/sunxi/Makefile
>>> b/arch/arm/cpu/armv7/sunxi/Makefile
>>> index 76c7e55..459d5d8 100644
>>> --- a/arch/arm/cpu/armv7/sunxi/Makefile
>>> +++ b/arch/arm/cpu/armv7/sunxi/Makefile
>>> @@ -28,6 +28,7 @@ obj-$(CONFIG_MACH_SUN6I)+= clock_sun6i.o
>>> obj-$(CONFIG_MACH_SUN7I) += clock_sun4i.o
>>> obj-$(CONFIG_MACH_SUN8I) += clock_sun6i.o
>>> obj-$(CONFIG_MACH_SUN9I) += clock_sun9i.o
>>> +obj-$(CONFIG_MACH_SUN6I) += tzpc.o
>>>
>>> obj-$(CONFIG_AXP152_POWER) += pmic_bus.o
>>> obj-$(CONFIG_AXP209_POWER) += pmic_bus.o
>>> diff --git a/arch/arm/cpu/armv7/sunxi/board.c
>>> b/arch/arm/cpu/armv7/sunxi/board.c
>>> index f01846e..b40198b 100644
>>> --- a/arch/arm/cpu/armv7/sunxi/board.c
>>> +++ b/arch/arm/cpu/armv7/sunxi/board.c
>>> @@ -23,6 +23,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>>
>>> #include
>>> @@ -115,6 +116,10 @@ void s_init(void)
>>> "orr r0, r0, #1 << 6\n"
>>> "mcr p15, 0, r0, c1, c0, 1\n");
>>> #endif
>>> +#if defined CONFIG_MACH_SUN6I
>>> + /* Enable non-secure access to the RTC */
>>> + tzpc_init();
>>> +#endif
>>>
>>> clock_init();
>>> timer_init();
>>> diff --git a/arch/arm/cpu/armv7/sunxi/tzpc.c
>>> b/arch/arm/cpu/armv7/sunxi/tzpc.c
>>> new file mode 100644
>>> index 000..5c9c69b
>>> --- /dev/null
>>> +++ b/arch/arm/cpu/armv7/sunxi/tzpc.c
>>> @@ -0,0 +1,18 @@
>>> +/*
>>> + * (C) Copyright 2015 Chen-Yu Tsai
>>> + *
>>> + * SPDX-License-Identifier: GPL-2.0+
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +/* Configure Trust Zone Protection Controller */
>>> +void tzpc_init(void)
>>> +{
>>> + struct sunxi_tzpc *tzpc = (struct sunxi_tzpc *)SUNXI_TZPC_BASE;
>>> +
>>> + /* Enable non-secure access to the RTC */
>>> + writel(SUNXI_TZPC_DECPORT0_RTC, &tzpc->decport0_set);
>>
>> Irk. Seem blow.
>>
>>> +}
>>> diff --git a/arch/arm/include/asm/arch-sunxi/tzpc.h
>>> b/arch/arm/include/asm/arch-sunxi/tzpc.h
>>> new file mode 100644
>>> index 000..ba4d43b
>>> --- /dev/null
>>> +++ b/arch/arm/include/asm/arch-sunxi/tzpc.h
>>> @@ -0,0 +1,23 @@
>>> +/*
>>> + * (C) Copyright 2015 Chen-Yu Tsai
>>> + *
>>> + * SPDX-License-Identifier: GPL-2.0+
>>> + */
>>> +
>>> +#ifndef _SUNXI_TZPC_H
>>> +#define _SUNXI_TZPC_H
>>
>> Why is this sunxi specific? This seems to describe a standard ARM BP147
>> (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dto0015a/index.html),
>> so I'd expect the various offsets and the file location to reflect this.
>>
>> Another platform (FSL 2085) seems to use the same IP, so it would make
>> sense to clean that part of the code too.
>
> I guess we could make this generic. Seems samsung uses this as well.
>
>>> +
>>> +#ifndef __ASSEMBLY__
>>> +struct sunxi_tzpc {
>>> + u32 r0size; /* 0x00 Size of secure RAM region */
>>> + u32 decport0_status;/* 0x04 Status of decode protection port 0 */
>>> + u32 decport0_set; /* 0x08 Set decode protection port 0 */
>>> + u32 decport0_clear; /* 0x0c Clear decode protection port 0 */
>>> +};
>>
>> I'm not overly fond of this way to describe a set of contiguous
>> register. It tends to be fairly fragile (the compiler is free to
>> insert some padding) and prevents the use of offsets from assembly code.
>
> Seems this is how we are doing things in U-boot...
> I'm OK either way.
>
>>> +#endif
>>> +
>>> +#define SUNXI_TZPC_DECPORT0_RTC (1 << 1)
>>> +
>>> +void tzpc_init(void);
>>
>> And this won't help if you have assembly code either.
>>
>>> +
>>> +#endif /* _SUNXI_TZPC_H */
>>
>> If I can suggest something, it would be to make this something generic,
>> with a standard config option describing the base, a set of offsets
>> from t
Re: [U-Boot] [Reproducible-builds] [U-Boot, v2] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH
On 08/25/2015 11:55 AM, Vagrant Cascadian wrote: > On 2015-08-25, Andreas Bießmann wrote: >> On 07/28/2015 05:00 PM, Tom Rini wrote: >>> On Sun, Jul 26, 2015 at 06:48:15PM +0200, Paul Kocialkowski wrote: In order to achieve reproducible builds in U-Boot, timestamps that are defined at build-time have to be somewhat eliminated. The SOURCE_DATE_EPOCH environment variable allows setting a fixed value for those timestamps. Simply by setting SOURCE_DATE_EPOCH to a fixed value, a number of targets can be built reproducibly. This is the case for e.g. sunxi devices. However, some other devices might need some more tweaks, especially regarding the image generation tools. Signed-off-by: Paul Kocialkowski >>> >>> Applied to u-boot/master, thanks! >> >> This commit breaks build on non GNU hosts (like OS X and persumably >> other *BSD hosts). Before, those hosts where supported, so for me this >> has to be fixed for 2015.10 >> >> We need a) some mechanism to search for the GNU date variant or b) some >> wrapper to provide the correct output on those host machines. >> >> I vote for a), it is acceptable to have the GNU date available but we >> should error on 'no GNU date available'. Furthermore we need to have the >> date command exchangeable by e.g. gdate, gnudate, ... maybe with full path. > > There was a proposed patch which only uses the GNU date extensions if > SOURCE_DATE_EPOCH environment variable is set, would this sufficiently > address your concerns, at least for the short term? > > Message-Id: <1438337042-30762-1-git-send-email-judge.pack...@gmail.com> > http://lists.denx.de/pipermail/u-boot/2015-August/221429.html thanks for the pointer, normal builds work with that change. Andreas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] Makefile: Use correct timezone for U_BOOT_TZ
On 08/13/2015 08:08 AM, Chris Packham wrote:
> When building with SOURCE_DATE_EPOCH the timezone is in UTC. When
> building normally the timezone is taken from the build machine's locale
> setting.
>
> Signed-off-by: Chris Packham
> Tested-by: Bin Meng
> Tested-by: Paul Kocialkowski
This also re-enables normal building on *BSD style hosts.
Tested-by: Andreas Bießmann
> ---
>
> Changes in v3:
> - None
>
> Changes in v2:
> - Collect some tested-by tags
> - Remove reference to f3f431a71272 in the commit message
> - Drop Ccs that were erroneously added when submitting v1, remaining Ccs
> are from the original mailing list thread
>
> Makefile | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index ad51e60..3ff063a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1279,10 +1279,16 @@ define filechk_version.h
> endef
>
> define filechk_timestamp.h
> - (SOURCE_DATE="$${SOURCE_DATE_EPOCH:+@$$SOURCE_DATE_EPOCH}"; \
> - LC_ALL=C date -u -d "$${SOURCE_DATE:-now}" +'#define U_BOOT_DATE "%b %d
> %C%y"'; \
> - LC_ALL=C date -u -d "$${SOURCE_DATE:-now}" +'#define U_BOOT_TIME "%T"';
> \
> - LC_ALL=C date -u -d "$${SOURCE_DATE:-now}" +'#define U_BOOT_TZ "%z"' )
> + (if test -n "$${SOURCE_DATE_EPOCH}"; then \
> + SOURCE_DATE="@$${SOURCE_DATE_EPOCH}"; \
> + LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_DATE "%b
> %d %C%y"'; \
> + LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_TIME
> "%T"'; \
> + LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_TZ
> "%z"'; \
> + else \
> + LC_ALL=C date +'#define U_BOOT_DATE "%b %d %C%y"'; \
> + LC_ALL=C date +'#define U_BOOT_TIME "%T"'; \
> + LC_ALL=C date +'#define U_BOOT_TZ "%z"'; \
> + fi)
> endef
>
> $(version_h): include/config/uboot.release FORCE
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net: bootp fix vci string on SPL-Boot
If CONFIG_CMD_DHCP is enabled, the vci (vendor-class-identifier) string isn't inserted into the bootp-packet during SPL stage because the CONFIG_BOOTP_VCI_STRING instead CONFIG_SPL_NET_VCI_STRING We fix this with testing for CONFIG_SPL_BUILD and testing for existing CONFIG_SPL_NET_VCI_STRING. Signed-off-by: Hannes Schmelzer --- net/bootp.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/bootp.c b/net/bootp.c index 43466af..b547786 100644 --- a/net/bootp.c +++ b/net/bootp.c @@ -498,7 +498,9 @@ static int dhcp_extended(u8 *e, int message_type, struct in_addr server_ip, } #endif -#ifdef CONFIG_BOOTP_VCI_STRING +#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_NET_VCI_STRING) + put_vci(e, CONFIG_SPL_NET_VCI_STRING); +#elif defined(CONFIG_BOOTP_VCI_STRING) put_vci(e, CONFIG_BOOTP_VCI_STRING); #endif -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] ubifs: Modify ubifs u-boot wrapper function prototypes for generic fs use
Hello Hans,
Am 22.08.2015 um 20:04 schrieb Hans de Goede:
Modify the ubifs u-boot wrapper function prototypes for generic fs use,
and give them their own header file.
This is a preparation patch for adding ubifs support to the generic fs
code from fs/fs.c.
Signed-off-by: Hans de Goede
---
common/cmd_ubifs.c| 14 +++
fs/ubifs/ubifs.c | 70 ---
fs/ubifs/ubifs.h | 6 +
include/ubifs_uboot.h | 29 +
4 files changed, 89 insertions(+), 30 deletions(-)
create mode 100644 include/ubifs_uboot.h
Only one nitpick, beside of this, you can add my:
Reviewed-by: Heiko Schocher
diff --git a/common/cmd_ubifs.c b/common/cmd_ubifs.c
index 8e9a4e5..0a3dd24 100644
--- a/common/cmd_ubifs.c
+++ b/common/cmd_ubifs.c
@@ -15,11 +15,10 @@
#include
#include
#include
-
-#include "../fs/ubifs/ubifs.h"
+#include
static int ubifs_initialized;
-static int ubifs_mounted;
+int ubifs_mounted;
later you add "extern int ubifs_mounted" in include/ubifs_uboot.h
Maybe you want to add a function, which returns the state
of this var and let the var static?
bye,
Heiko
static int do_ubifs_mount(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
@@ -54,14 +53,7 @@ int ubifs_is_mounted(void)
void cmd_ubifs_umount(void)
{
-
- if (ubifs_sb) {
- printf("Unmounting UBIFS volume %s!\n",
- ((struct ubifs_info *)(ubifs_sb->s_fs_info))->vi.name);
- ubifs_umount(ubifs_sb->s_fs_info);
- }
-
- ubifs_sb = NULL;
+ uboot_ubifs_umount();
ubifs_mounted = 0;
ubifs_initialized = 0;
}
diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
index 6dd6174..5af861c 100644
--- a/fs/ubifs/ubifs.c
+++ b/fs/ubifs/ubifs.c
@@ -568,7 +568,7 @@ static unsigned long ubifs_findfile(struct super_block *sb,
char *filename)
return 0;
}
-int ubifs_ls(char *filename)
+int ubifs_ls(const char *filename)
{
struct ubifs_info *c = ubifs_sb->s_fs_info;
struct file *file;
@@ -579,7 +579,7 @@ int ubifs_ls(char *filename)
int ret = 0;
c->ubi = ubi_open_volume(c->vi.ubi_num, c->vi.vol_id, UBI_READONLY);
- inum = ubifs_findfile(ubifs_sb, filename);
+ inum = ubifs_findfile(ubifs_sb, (char *)filename);
if (!inum) {
ret = -1;
goto out;
@@ -785,7 +785,8 @@ error:
return err;
}
-int ubifs_load(char *filename, u32 addr, u32 size)
+int ubifs_read(const char *filename, void *buf, loff_t offset,
+ loff_t size, loff_t *actread)
{
struct ubifs_info *c = ubifs_sb->s_fs_info;
unsigned long inum;
@@ -796,10 +797,18 @@ int ubifs_load(char *filename, u32 addr, u32 size)
int count;
int last_block_size = 0;
+ *actread = 0;
+
+ if (offset & (PAGE_SIZE - 1)) {
+ printf("ubifs: Error offset must be a multple of %d\n",
+ PAGE_SIZE);
+ return -1;
+ }
+
c->ubi = ubi_open_volume(c->vi.ubi_num, c->vi.vol_id, UBI_READONLY);
/* ubifs_findfile will resolve symlinks, so we know that we get
* the real file here */
- inum = ubifs_findfile(ubifs_sb, filename);
+ inum = ubifs_findfile(ubifs_sb, (char *)filename);
if (!inum) {
err = -1;
goto out;
@@ -815,19 +824,24 @@ int ubifs_load(char *filename, u32 addr, u32 size)
goto out;
}
+ if (offset > inode->i_size) {
+ printf("ubifs: Error offset (%lld) > file-size (%lld)\n",
+ offset, size);
+ err = -1;
+ goto put_inode;
+ }
+
/*
* If no size was specified or if size bigger than filesize
* set size to filesize
*/
- if ((size == 0) || (size > inode->i_size))
- size = inode->i_size;
+ if ((size == 0) || (size > (inode->i_size - offset)))
+ size = inode->i_size - offset;
count = (size + UBIFS_BLOCK_SIZE - 1) >> UBIFS_BLOCK_SHIFT;
- printf("Loading file '%s' to addr 0x%08x with size %d (0x%08x)...\n",
- filename, addr, size, size);
- page.addr = (void *)addr;
- page.index = 0;
+ page.addr = buf;
+ page.index = offset / PAGE_SIZE;
page.inode = inode;
for (i = 0; i < count; i++) {
/*
@@ -844,16 +858,44 @@ int ubifs_load(char *filename, u32 addr, u32 size)
page.index++;
}
- if (err)
+ if (err) {
printf("Error reading file '%s'\n", filename);
- else {
- setenv_hex("filesize", size);
- printf("Done\n");
+ *actread = i * PAGE_SIZE;
+ } else {
+ *actread = size;
}
+put_inode:
ubifs_iput(inode);
out:
ubi_close_volume(c->ubi);
return er
Re: [U-Boot] [PATCH v2 2/4] ubifs: Add functions for generic fs use
Hello Hans,
Am 22.08.2015 um 20:04 schrieb Hans de Goede:
Implement the necessary functions for implementing generic fs support
for ubifs.
Signed-off-by: Hans de Goede
---
fs/ubifs/ubifs.c | 62 +++
include/ubifs_uboot.h | 4
2 files changed, 66 insertions(+)
Reviewed-by: Heiko Schocher
bye,
Heiko
diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
index 5af861c..89f1f2a 100644
--- a/fs/ubifs/ubifs.c
+++ b/fs/ubifs/ubifs.c
@@ -568,6 +568,22 @@ static unsigned long ubifs_findfile(struct super_block
*sb, char *filename)
return 0;
}
+int ubifs_set_blk_dev(block_dev_desc_t *rbdd, disk_partition_t *info)
+{
+ /* Check that ubifs is mounted and that we are not being a blkdev */
+ if (!ubifs_mounted) {
+ printf("UBIFS not mounted, use ubifsmount to mount volume
first!\n");
+ return -1;
+ }
+
+ if (rbdd) {
+ printf("UBIFS cannot be used with normal block devices\n");
+ return -1;
+ }
+
+ return 0;
+}
+
int ubifs_ls(const char *filename)
{
struct ubifs_info *c = ubifs_sb->s_fs_info;
@@ -616,6 +632,48 @@ out:
return ret;
}
+int ubifs_exists(const char *filename)
+{
+ struct ubifs_info *c = ubifs_sb->s_fs_info;
+ unsigned long inum;
+
+ c->ubi = ubi_open_volume(c->vi.ubi_num, c->vi.vol_id, UBI_READONLY);
+ inum = ubifs_findfile(ubifs_sb, (char *)filename);
+ ubi_close_volume(c->ubi);
+
+ return inum != 0;
+}
+
+int ubifs_size(const char *filename, loff_t *size)
+{
+ struct ubifs_info *c = ubifs_sb->s_fs_info;
+ unsigned long inum;
+ struct inode *inode;
+ int err = 0;
+
+ c->ubi = ubi_open_volume(c->vi.ubi_num, c->vi.vol_id, UBI_READONLY);
+
+ inum = ubifs_findfile(ubifs_sb, (char *)filename);
+ if (!inum) {
+ err = -1;
+ goto out;
+ }
+
+ inode = ubifs_iget(ubifs_sb, inum);
+ if (IS_ERR(inode)) {
+ printf("%s: Error reading inode %ld!\n", __func__, inum);
+ err = PTR_ERR(inode);
+ goto out;
+ }
+
+ *size = inode->i_size;
+
+ ubifs_iput(inode);
+out:
+ ubi_close_volume(c->ubi);
+ return err;
+}
+
/*
* ubifsload...
*/
@@ -873,6 +931,10 @@ out:
return err;
}
+void ubifs_close(void)
+{
+}
+
/* Compat wrappers for common/cmd_ubifs.c */
int ubifs_load(char *filename, u32 addr, u32 size)
{
diff --git a/include/ubifs_uboot.h b/include/ubifs_uboot.h
index d10a909..c600e38 100644
--- a/include/ubifs_uboot.h
+++ b/include/ubifs_uboot.h
@@ -22,8 +22,12 @@ int uboot_ubifs_mount(char *vol_name);
void uboot_ubifs_umount(void);
int ubifs_load(char *filename, u32 addr, u32 size);
+int ubifs_set_blk_dev(block_dev_desc_t *rbdd, disk_partition_t *info);
int ubifs_ls(const char *dir_name);
+int ubifs_exists(const char *filename);
+int ubifs_size(const char *filename, loff_t *size);
int ubifs_read(const char *filename, void *buf, loff_t offset,
loff_t size, loff_t *actread);
+void ubifs_close(void);
#endif /* __UBIFS_UBOOT_H__ */
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] arm: tegra30: video: integrate display driver for t30
On Mon, Aug 24, 2015 at 10:58:48AM -0600, Simon Glass wrote:
> +Nikita
>
> Hi Thierry,
>
> On 24 August 2015 at 04:12, Thierry Reding wrote:
> > On Fri, Aug 21, 2015 at 06:37:37PM -0600, Simon Glass wrote:
> > [...]
> >> I have serious doubts about the wisdom of requiring a contributor to
> >> completely re-architect the existing display system in U-Boot. It's a
> >> big job. Perhaps we can settle for following along the same lines and
> >> not making things worse?
> >
> > I didn't suggest re-architecting the display system in U-Boot. What I
> > was suggesting was a way to architect Tegra-specific display driver code
> > to make it reusable rather than duplicate display controller programming
> > for each new generation, while the hardware has remained mostly the
> > same.
>
> OK, I misunderstood.
>
> >
> >> > Perhaps something as simple as:
> >> >
> >> > struct tegra_dc {
> >> > ...
> >> > int (*enable)(struct tegra_dc *dc, const struct
> >> > display_mode *mode);
> >> > void (*disable)(struct tegra_dc *dc);
> >> > ...
> >> > };
> >> >
> >> > struct tegra_output {
> >> > ...
> >> > struct tegra_dc *dc;
> >> > ...
> >> > int (*enable)(struct tegra_output *output, const struct
> >> > display_mode *mode);
> >> > void (*disable)(struct tegra_output *output);
> >> > ...
> >> > };
> >> >
> >> > would work fine. That's roughly how drivers are implemented in the
> >> > kernel. Setting up display on an output would be done by determining the
> >> > mode (typically by parsing EDID if available, or using a hard-coded mode
> >> > otherwise) and then calling:
> >> >
> >> > output->dc = dc;
> >> > dc->enable(dc, mode);
> >> > output->enable(output, mode);
> >> >
> >> > You might want to add in an abstraction for panels as well to make sure
> >> > you have enough flexibility to enable and disable those, too. In that
> >> > case you'd probably want to complement the above sequence with:
> >> >
> >> > panel->enable(panel);
> >>
> >> Please don't add function points to structures on an ad-hoc basis.
> >> These should use driver model. There is a uclass for display port but
> >> not for LCD panels or SOR. You could add a very simple one for a panel
> >> if you like. Please take a look at tegra124's display driver for an
> >> example.
> >
> > I don't think the driver model is a good fit here. Abstracting a display
> > port isn't very useful in itself because users don't really care about
> > the type of display, they only care about it being a display. So if you
> > want to usefully abstract you'd do it at a higher level, such as display
> > or screen. Then you have a generic object which users can use to put up
> > a framebuffer onto a physical screen.
>
> I think you are referring to the lcd/video interface. If so, this is
> already fairly well defined, but lcd and video should be merged, and a
> uclass could be added. Nikita Kiryanov has done quite a bit of work on
> the merging side.
>
> But I still think there is value in a low-level abstraction too.
> Function pointers indicate that there is an interface that can be used
> by multiple drivers, and that is what driver model is for. See
> displayport.h for an attempt at this. We can of course consider
> expanding the display port uclass to encompass panels in general. I
> was reluctant to do that with a sample size of one. Here is the
> current interface:
>
> /**
> * display_port_read_edid() - Read information from EDID
> *
> * @dev:Device to read from
> * @buf:Buffer to read into (should be EDID_SIZE bytes)
> * @buf_size: Buffer size (should be EDID_SIZE)
> * @return number of bytes read, <=0 for error
> */
> int display_port_read_edid(struct udevice *dev, u8 *buf, int buf_size);
>
> /**
> * display_port_enable() - Enable a display port device
> *
> * @dev:Device to enable
> * @panel_bpp: Number of bits per pixel for panel
> * @timing: Display timings
> * @return 0 if OK, -ve on error
> */
> int display_port_enable(struct udevice *dev, int panel_bpp,
> const struct display_timing *timing);
Both of these really aren't specific to DisplayPort. A DSI or HDMI input
also wants to be enabled or have its EDID queried. Well, EDID may not be
available on most DSI panels, so I think this particular abstraction
should be slightly higher-level. What users are interested in isn't the
EDID information, but the content therein. So I think a better way to
return this type of information is by generating a list of modes (or a
single one) given a display output device.
And once you have that abstraction it becomes useless to abstract the
various types of outputs, because DisplayPort, LVDS, HDMI, DSI, etc.
will all behave the same.
> > SOR is an even worse abstraction because it's comple
Re: [U-Boot] [PATCH v2 3/4] ubifs: Add generic fs support
Hello Hans,
Am 22.08.2015 um 20:04 schrieb Hans de Goede:
Add generic fs support, so that commands like ls, load and test -e can be
used on ubifs.
Signed-off-by: Hans de Goede
---
disk/part.c | 23 +++
fs/fs.c | 16
include/fs.h | 1 +
3 files changed, 40 insertions(+)
Reviewed-by: Heiko Schocher
bye,
Heiko
diff --git a/disk/part.c b/disk/part.c
index 43485c9..e1a8bde 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#undefPART_DEBUG
@@ -530,6 +531,28 @@ int get_device_and_partition(const char *ifname, const
char *dev_part_str,
return 0;
}
+#ifdef CONFIG_CMD_UBIFS
+ /*
+* Special-case ubi, ubi goes through a mtd, rathen then through
+* a regular block device.
+*/
+ if (0 == strcmp(ifname, "ubi")) {
+ if (!ubifs_mounted) {
+ printf("UBIFS not mounted, use ubifsmount to mount volume
first!\n");
+ return -1;
+ }
+
+ *dev_desc = NULL;
+ memset(info, 0, sizeof(*info));
+ strcpy((char *)info->type, BOOT_PART_TYPE);
+ strcpy((char *)info->name, "UBI");
+#ifdef CONFIG_PARTITION_UUIDS
+ info->uuid[0] = 0;
+#endif
+ return 0;
+ }
+#endif
+
/* If no dev_part_str, use bootdevice environment variable */
if (!dev_part_str || !strlen(dev_part_str) ||
!strcmp(dev_part_str, "-"))
diff --git a/fs/fs.c b/fs/fs.c
index 827b143..b2d6a53 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -157,6 +158,21 @@ static struct fstype_info fstypes[] = {
.uuid = fs_uuid_unsupported,
},
#endif
+#ifdef CONFIG_CMD_UBIFS
+ {
+ .fstype = FS_TYPE_UBIFS,
+ .name = "ubifs",
+ .null_dev_desc_ok = true,
+ .probe = ubifs_set_blk_dev,
+ .close = ubifs_close,
+ .ls = ubifs_ls,
+ .exists = ubifs_exists,
+ .size = ubifs_size,
+ .read = ubifs_read,
+ .write = fs_write_unsupported,
+ .uuid = fs_uuid_unsupported,
+ },
+#endif
{
.fstype = FS_TYPE_ANY,
.name = "unsupported",
diff --git a/include/fs.h b/include/fs.h
index fd1e4ab..059a395 100644
--- a/include/fs.h
+++ b/include/fs.h
@@ -22,6 +22,7 @@
#define FS_TYPE_FAT 1
#define FS_TYPE_EXT 2
#define FS_TYPE_SANDBOX 3
+#define FS_TYPE_UBIFS 4
/*
* Tell the fs layer which block device an partition to use for future
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)
On Tue 2015-08-25 16:58:58, Bin Meng wrote: > Hi Pavel, > > On Tue, Aug 25, 2015 at 3:12 PM, Pavel Machek wrote: > > On Tue 2015-08-25 10:25:35, Bin Meng wrote: > >> Hi, > >> > >> With latest u-boot/master, TFTP is seriously broken. > > > > Sorry about that. > > > >> => tftp 10 bzImage > >> Speed: 100, full duplex > >> Using pch_gbe device > >> TFTP from server 10.10.0.8; our IP address is 10.10.0.100; sending > >> through gateway 10.10.0.1 > >> Filename 'bzImage'. > >> Load address: 0x10 > >> Loading: T > >> TFTP error: 'Unsupported option(s) requested' (8) > >> Starting again > >> > >> git bisect shows the following commit broke the TFTP > > > > I was not intentionally changing the packets being sent. > > > > Could you try to capture tcpdump, including contents of packet, > > ideally in both working and broken sessions? > > > > Yep, I will do that. I also tested a tftpd Windows server > (http://tftpd32.jounin.net) and it looks that this Windows server is > immune to this commit. > > > Could you try setting > > > > -#define TIMEOUT5000UL > > +#define TIMEOUT100UL > > > > in net/tftp.c to something like 1000UL? > > > > Could you please elaborate more on what this commit is trying to fix, > or improve? From the commit message, I don't quite understand "With 5 > seconds timeout, 10 retries maximum, tftp is impossible even on local > network with single full-speed TCP connection". Well, with 10 retries maximum, I get enough packet loss on local network that tftp fails. Now, longer timeout will make it slower, but not fail. So "max retries" is really critical. If rfc says minimum is 1sec, we should not really default to 100msec, sorry about that. Can you try with 1sec if it works for you? Thanks and best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] SOURCE_DATE_EPOCH must not be linux only... (was Re: [Reproducible-builds] [U-Boot, v2] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH)
Hi, (just stating the (IMHO) obvious here…) On Dienstag, 25. August 2015, Vagrant Cascadian wrote: > There was a proposed patch which only uses the GNU date extensions if > SOURCE_DATE_EPOCH environment variable is set, would this sufficiently > address your concerns, at least for the short term? there also should be a solution which works on BSD in the not so long term if we want the SOURCE_DATE_EPOCH specification to take off..! (and this probably also affects other software where we want to (or did) introduce SOURCE_DATE_EPOCH!) cheers, Holger signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] ubifs: Modify ubifs u-boot wrapper function prototypes for generic fs use
Hi, On 25-08-15 13:00, Heiko Schocher wrote: Hello Hans, Am 22.08.2015 um 20:04 schrieb Hans de Goede: Modify the ubifs u-boot wrapper function prototypes for generic fs use, and give them their own header file. This is a preparation patch for adding ubifs support to the generic fs code from fs/fs.c. Signed-off-by: Hans de Goede --- common/cmd_ubifs.c| 14 +++ fs/ubifs/ubifs.c | 70 --- fs/ubifs/ubifs.h | 6 + include/ubifs_uboot.h | 29 + 4 files changed, 89 insertions(+), 30 deletions(-) create mode 100644 include/ubifs_uboot.h Only one nitpick, beside of this, you can add my: Reviewed-by: Heiko Schocher diff --git a/common/cmd_ubifs.c b/common/cmd_ubifs.c index 8e9a4e5..0a3dd24 100644 --- a/common/cmd_ubifs.c +++ b/common/cmd_ubifs.c @@ -15,11 +15,10 @@ #include #include #include - -#include "../fs/ubifs/ubifs.h" +#include static int ubifs_initialized; -static int ubifs_mounted; +int ubifs_mounted; later you add "extern int ubifs_mounted" in include/ubifs_uboot.h Maybe you want to add a function, which returns the state of this var and let the var static? Yes that would be cleaner, I'll fix the patch-set to do things that way. Thanks for the reviews. So when the time come comes (when v2015.10 is out), how do we merge these 3, shall I take them upstream through the linux-sunxi tree, or do you want me to send a v2 with this fixed, and then you take them upstream ? Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Change default tftp timeout to be rfc-compliant
tftp timeout of 100msec gives good performance on local ethernet, but some servers (Centos) refuse to operate, and it is against RFC 2349. This fixes regression caused by 620776d734e4b126c407f636bda825a594a17723 . Signed-off-by: Pavel Machek diff --git a/net/tftp.c b/net/tftp.c index 18ce84c..e919638 100644 --- a/net/tftp.c +++ b/net/tftp.c @@ -18,8 +18,9 @@ /* Well known TFTP port # */ #define WELL_KNOWN_PORT69 -/* Millisecs to timeout for lost pkt */ -#define TIMEOUT100UL +/* Millisecs to timeout for lost pkt. Anything below 1000msec is against RFC, and + some servers will refuse it. */ +#define TIMEOUT1000UL #ifndefCONFIG_NET_RETRY_COUNT /* # of timeouts before giving up */ # define TIMEOUT_COUNT 1000 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] arm: Enable CONFIG_SYS_GENERIC_BOARD for all boards
Hi Simon, On Wed, Aug 19, 2015 at 6:35 AM, Simon Glass wrote: > All boards should be converted to generic board by now. Change the rest > over. If this causes run-time breakages then we can remove those boards. Why not just remove these apparently unmaintained boards, as announced in [1]? Regards, Christian [1] http://lists.denx.de/pipermail/u-boot/2015-January/201032.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/3] add pinctrl driver framework
I am trying my best to have this subsystem as DT-compatible with Linux as possible, also saving memory foot print as a boot loader. It would be very appreciated if Linus Walleij, the maintainer of pinctrl subsystem in Linux, would check this series if he could find some time. Masahiro Yamada (3): dm: core: allow device_bind() to not return a device pointer pinctrl: add pin control uclass support pinctrl: sandbox: add sandbox pinctrl driver arch/sandbox/dts/sandbox.dts | 19 ++ configs/sandbox_defconfig | 3 + drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/core/device.c | 10 +- drivers/pinctrl/Kconfig | 109 drivers/pinctrl/Makefile | 4 + drivers/pinctrl/pinctrl-generic.c | 359 ++ drivers/pinctrl/pinctrl-sandbox.c | 147 drivers/pinctrl/pinctrl-uclass.c | 229 include/dm/device-internal.h | 4 +- include/dm/lists.h| 4 +- include/dm/pinctrl.h | 227 include/dm/uclass-id.h| 2 + 14 files changed, 1114 insertions(+), 6 deletions(-) create mode 100644 drivers/pinctrl/Kconfig create mode 100644 drivers/pinctrl/Makefile create mode 100644 drivers/pinctrl/pinctrl-generic.c create mode 100644 drivers/pinctrl/pinctrl-sandbox.c create mode 100644 drivers/pinctrl/pinctrl-uclass.c create mode 100644 include/dm/pinctrl.h -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 9/9] dfu: tftp: Kconfig: Enable DFU_TFTP support on the am335x_boneblack_defconfig
Hi Lukasz, On Sun, Aug 23, 2015 at 5:21 PM, Lukasz Majewski wrote: > This commit enables support for DFU_TFTP on the am335x bone black device. > > Signed-off-by: Lukasz Majewski Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] arm: Enable CONFIG_SYS_GENERIC_BOARD for all boards
2015-08-22 5:44 GMT+09:00 Masahiro Yamada : > Hi Simon, > > > 2015-08-22 2:53 GMT+09:00 Simon Glass : >> Hi Masahiro, >> >> On 19 August 2015 at 19:36, Masahiro Yamada >> wrote: >>> 2015-08-19 13:35 GMT+09:00 Simon Glass : All boards should be converted to generic board by now. Change the rest over. If this causes run-time breakages then we can remove those boards. Signed-off-by: Simon Glass Can you record which boards have been forcibly converted in the git-log? If we find a board difficult to keep in the future and it matches the list of forcibly converted boards, we can excuse for removing it. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] board/BuR: simplify default IP-setup on B&R boards.
To simplify and having a common default IP-setup on all B&R boards we
introduce an environment variable "brdefaultip" which does following.
Test if ${ipaddr} is empty, if yes it set's up some defaults:
- ipaddr : 192.168.60.1
- netmask : 255.255.255.0
- gatewayip: 192.168.60.254
- serverip : 192.168.60.254
This environment is ran from CONFIG_PREBOOT.
All other "tricks" are dropped.
Signed-off-by: Hannes Schmelzer
---
board/BuR/kwb/board.c | 10 --
include/configs/bur_am335x_common.h | 12 +---
2 files changed, 5 insertions(+), 17 deletions(-)
diff --git a/board/BuR/kwb/board.c b/board/BuR/kwb/board.c
index 640aca4..039ec20 100644
--- a/board/BuR/kwb/board.c
+++ b/board/BuR/kwb/board.c
@@ -283,16 +283,6 @@ int board_late_init(void)
}
/* setup vxworks bootline */
char *vxworksbootline = (char *)VXWORKS_BOOTLINE;
-
- /* setup default IP, in case if there is nothing in environment */
- if (!getenv("ipaddr")) {
- setenv("ipaddr", "192.168.60.1");
- setenv("netmask", "255.255.255.0");
- setenv("serverip", "192.168.60.254");
- setenv("gatewayip", "192.168.60.254");
- puts("net: had no IP! made default setup.\n");
- }
-
sprintf(vxworksbootline,
"%s h=%s e=%s:%s g=%s %s o=0x%08x;0x%08x;0x%08x;0x%08x",
DEFAULT_BOOTLINE,
diff --git a/include/configs/bur_am335x_common.h
b/include/configs/bur_am335x_common.h
index 838ef1f..c696092 100644
--- a/include/configs/bur_am335x_common.h
+++ b/include/configs/bur_am335x_common.h
@@ -14,18 +14,16 @@
/* - */
#define BUR_COMMON_ENV \
"usbscript=usb start && fatload usb 0 0x8000 usbscript.img && source\0" \
-"defaultip=192.168.60.253\0" \
-"defaultsip=192.168.60.254\0" \
+"brdefaultip=if test -r ${ipaddr}; then; else" \
+" setenv ipaddr 192.168.60.1; setenv serverip 192.168.60.254;" \
+" setenv gatewayip 192.168.60.254; setenv netmask 255.255.255.0; fi;\0" \
"netconsole=echo switching to network console ...; " \
-"if dhcp; then setenv ncip ${serverip}; " \
-"else " \
-"setenv ncip 192.168.60.254; setenv serverip 192.168.60.254; " \
-"setenv gatewayip 192.168.60.254; setenv ipaddr 192.168.60.1; " \
-"fi; " \
+"if dhcp; then; else run brdefaultip; fi; setenv ncip ${serverip}; " \
"setcurs 1 9; lcdputs myip; setcurs 10 9; lcdputs ${ipaddr};" \
"setcurs 1 10;lcdputs serverip; setcurs 10 10; lcdputs ${serverip};" \
"setenv stdout nc;setenv stdin nc;setenv stderr nc\0"
+#define CONFIG_PREBOOT "run brdefaultip"
#define CONFIG_CMD_TIME
#define CONFIG_SYS_GENERIC_BOARD
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] Makefile: Add SOURCE_DATE_TZ
Le jeudi 13 août 2015 à 18:08 +1200, Chris Packham a écrit :
> Along with SOURCE_DATE_EPOCH SOURCE_DATE_TZ can be used to recreate a
> build with a specific date timestamp. This allows the verification of
> source supplied with a pre-compiled binary.
>
> If SOURCE_DATE_EPOCH is supplied SOURCE_DATE_TZ can be used to specify
> what will appear in the output of the version command. If SOURCE_DATE_TZ
> is not specified UTC will be used. SOURCE_DATE_TZ on it's own will not
> have an affect.
I advise against merging this patch given Ximin Luo's comments on v1, at
least until this has been properly discussed with the reproducible team
and a precise meaning for it has been agreed on.
> Signed-off-by: Chris Packham
> ---
> This is a quick proof of concept that allows some control of how the
> timezone is displayed. Now you can do something like
>
> make SOURCE_DATE_EPOCH=12345678 SOURCE_DATE_TZ=America/Los_Angeles
>
>
> Changes in v3:
> - Drop RFC
>
> Changes in v2: None
>
> Makefile | 7 ---
> README | 9 ++---
> 2 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 3ff063a..609b595 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1281,9 +1281,10 @@ endef
> define filechk_timestamp.h
> (if test -n "$${SOURCE_DATE_EPOCH}"; then \
> SOURCE_DATE="@$${SOURCE_DATE_EPOCH}"; \
> - LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_DATE "%b
> %d %C%y"'; \
> - LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_TIME
> "%T"'; \
> - LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_TZ
> "%z"'; \
> + SOURCE_TZ="$${SOURCE_DATE_TZ:-UTC}"; \
> + TZ="$${SOURCE_TZ}" LC_ALL=C date -d "$${SOURCE_DATE}" +'#define
> U_BOOT_DATE "%b %d %C%y"'; \
> + TZ="$${SOURCE_TZ}" LC_ALL=C date -d "$${SOURCE_DATE}" +'#define
> U_BOOT_TIME "%T"'; \
> + TZ="$${SOURCE_TZ}" LC_ALL=C date -d "$${SOURCE_DATE}" +'#define
> U_BOOT_TZ "%z"'; \
> else \
> LC_ALL=C date +'#define U_BOOT_DATE "%b %d %C%y"'; \
> LC_ALL=C date +'#define U_BOOT_TIME "%T"'; \
> diff --git a/README b/README
> index 1bcb63c..d2e3e94 100644
> --- a/README
> +++ b/README
> @@ -5087,11 +5087,14 @@ Reproducible builds
> In order to achieve reproducible builds, timestamps used in the U-Boot build
> process have to be set to a fixed value.
>
> -This is done using the SOURCE_DATE_EPOCH environment variable.
> -SOURCE_DATE_EPOCH is to be set on the build host's shell, not as a
> configuration
> -option for U-Boot or an environment variable in U-Boot.
> +This is done using the SOURCE_DATE_EPOCH and SOURCE_DATE_TZ environment
> +variables. These are to be set on the build host's shell, not as a
> +configuration option for U-Boot or an environment variable in U-Boot.
>
> SOURCE_DATE_EPOCH should be set to a number of seconds since the epoch, in
> UTC.
> +SOURCE_DATE_TZ will default to UTC but can be set to another timezone and is
> +used to determine how the date is displayed (tzselect(1) can be used to
> +determine an appropriate value).
>
> Building the Software:
> ==
signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] Makefile: Use correct timezone for U_BOOT_TZ
Le jeudi 13 août 2015 à 18:08 +1200, Chris Packham a écrit :
> When building with SOURCE_DATE_EPOCH the timezone is in UTC. When
> building normally the timezone is taken from the build machine's locale
> setting.
Looks good to me!
> Signed-off-by: Chris Packham
> Tested-by: Bin Meng
> Tested-by: Paul Kocialkowski
> ---
>
> Changes in v3:
> - None
>
> Changes in v2:
> - Collect some tested-by tags
> - Remove reference to f3f431a71272 in the commit message
> - Drop Ccs that were erroneously added when submitting v1, remaining Ccs
> are from the original mailing list thread
>
> Makefile | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index ad51e60..3ff063a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1279,10 +1279,16 @@ define filechk_version.h
> endef
>
> define filechk_timestamp.h
> - (SOURCE_DATE="$${SOURCE_DATE_EPOCH:+@$$SOURCE_DATE_EPOCH}"; \
> - LC_ALL=C date -u -d "$${SOURCE_DATE:-now}" +'#define U_BOOT_DATE "%b %d
> %C%y"'; \
> - LC_ALL=C date -u -d "$${SOURCE_DATE:-now}" +'#define U_BOOT_TIME "%T"';
> \
> - LC_ALL=C date -u -d "$${SOURCE_DATE:-now}" +'#define U_BOOT_TZ "%z"' )
> + (if test -n "$${SOURCE_DATE_EPOCH}"; then \
> + SOURCE_DATE="@$${SOURCE_DATE_EPOCH}"; \
> + LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_DATE "%b
> %d %C%y"'; \
> + LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_TIME
> "%T"'; \
> + LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_TZ
> "%z"'; \
> + else \
> + LC_ALL=C date +'#define U_BOOT_DATE "%b %d %C%y"'; \
> + LC_ALL=C date +'#define U_BOOT_TIME "%T"'; \
> + LC_ALL=C date +'#define U_BOOT_TZ "%z"'; \
> + fi)
> endef
>
> $(version_h): include/config/uboot.release FORCE
signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)
Hi,
i've same problem.
Running tftp-hpa on Linux Mint 17.
cat /etc/default/tftpd-hpa
# /etc/default/tftpd-hpa
RUN_DAEMON="yes"
TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/tftpboot/tseries"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-l -s"
best regards,
Hannes
On 25.08.2015 09:40, Bin Meng wrote:
Hi Joe,
On Tue, Aug 25, 2015 at 12:24 PM, Joe Hershberger
wrote:
Hi Bin,
On Mon, Aug 24, 2015 at 11:05 PM, Bin Meng wrote:
Hi Joe,
On Tue, Aug 25, 2015 at 11:42 AM, Joe Hershberger
wrote:
Hi Bin,
On Mon, Aug 24, 2015 at 9:25 PM, Bin Meng wrote:
Hi,
With latest u-boot/master, TFTP is seriously broken.
=> tftp 10 bzImage
Speed: 100, full duplex
Using pch_gbe device
TFTP from server 10.10.0.8; our IP address is 10.10.0.100; sending
through gateway 10.10.0.1
Filename 'bzImage'.
Load address: 0x10
Loading: T
TFTP error: 'Unsupported option(s) requested' (8)
Starting again
I'm guessing you are having an issue that the TFTP server you are
using for some reason does not allow a timeout as small as 10 ms. What
server are you testing against? Can you experiment and find the lowest
that it accepts? Maybe there is a compromise we can reach that still
works with most (all?) servers and also improves the behavior in a
lossy environment.
I am using a CentOS server, with /etc/xinetd.d/tftp configuration below.
service tftp
{
socket_type = dgram
protocol= udp
wait= yes
user= root
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot
disable = no
per_source = 11
cps = 100 2
flags = IPv4
}
I don't see an entry to change timeout settings.
I didn't mean to change the server settings; I meant can you adjust
the U-Boot code until your server doesn't reject the option?
I would like to revert this commit before we find a solution. Even if
I find a proper value to get tftp work again in my network
environment, we don't know if this commit breaks someone else's board.
After all, this timeout value has been there for years (?), and I
believe it is a safe value for all the boards that are actively
maintained.
[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] [Reproducible-builds] [U-Boot, v2] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH
Le mardi 25 août 2015 à 12:20 +0200, Andreas Bießmann a écrit : > On 08/25/2015 11:55 AM, Vagrant Cascadian wrote: > > On 2015-08-25, Andreas Bießmann wrote: > >> On 07/28/2015 05:00 PM, Tom Rini wrote: > >>> On Sun, Jul 26, 2015 at 06:48:15PM +0200, Paul Kocialkowski wrote: > In order to achieve reproducible builds in U-Boot, timestamps that are > defined > at build-time have to be somewhat eliminated. The SOURCE_DATE_EPOCH > environment > variable allows setting a fixed value for those timestamps. > > Simply by setting SOURCE_DATE_EPOCH to a fixed value, a number of > targets can be > built reproducibly. This is the case for e.g. sunxi devices. > > However, some other devices might need some more tweaks, especially > regarding > the image generation tools. > > Signed-off-by: Paul Kocialkowski > >>> > >>> Applied to u-boot/master, thanks! > >> > >> This commit breaks build on non GNU hosts (like OS X and persumably > >> other *BSD hosts). Before, those hosts where supported, so for me this > >> has to be fixed for 2015.10 > >> > >> We need a) some mechanism to search for the GNU date variant or b) some > >> wrapper to provide the correct output on those host machines. > >> > >> I vote for a), it is acceptable to have the GNU date available but we > >> should error on 'no GNU date available'. Furthermore we need to have the > >> date command exchangeable by e.g. gdate, gnudate, ... maybe with full path. > > > > There was a proposed patch which only uses the GNU date extensions if > > SOURCE_DATE_EPOCH environment variable is set, would this sufficiently > > address your concerns, at least for the short term? > > > > Message-Id: <1438337042-30762-1-git-send-email-judge.pack...@gmail.com> > > http://lists.denx.de/pipermail/u-boot/2015-August/221429.html > > thanks for the pointer, normal builds work with that change. I think we should get that patch merged so that it doesn't affect regular builds on non-GNU hosts. It is also relevant for the purpose it serves initially, too. -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/ signature.asc Description: This is a digitally signed message part ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)
On Tue 2015-08-25 14:13:17, Hannes Schmelzer wrote: > Hi, > > i've same problem. > > Running tftp-hpa on Linux Mint 17. > > cat /etc/default/tftpd-hpa > # /etc/default/tftpd-hpa > RUN_DAEMON="yes" > TFTP_USERNAME="tftp" > TFTP_DIRECTORY="/tftpboot/tseries" > TFTP_ADDRESS="0.0.0.0:69" > TFTP_OPTIONS="-l -s" Yes. Please try patch I mailed half an hour ago... it should fix that. (Actually here it is again, without changelog). Sorry for the trouble, Pavel Date: Tue, 25 Aug 2015 13:44:25 +0200 From: Pavel Machek To: Bin Meng Cc: Joe Hershberger , Tom Rini , U-Boot Mailing List Subject: [PATCH] Change default tftp timeout to be rfc-compliant diff --git a/net/tftp.c b/net/tftp.c index 18ce84c..e919638 100644 --- a/net/tftp.c +++ b/net/tftp.c @@ -18,8 +18,9 @@ /* Well known TFTP port # */ #define WELL_KNOWN_PORT69 -/* Millisecs to timeout for lost pkt */ -#define TIMEOUT100UL +/* Millisecs to timeout for lost pkt. Anything below 1000msec is against RFC, and + some servers will refuse it. */ +#define TIMEOUT1000UL #ifndefCONFIG_NET_RETRY_COUNT /* # of timeouts before giving up */ # define TIMEOUT_COUNT 1000 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] sunxi: Add inet98v_rev2 defconfig and dts file
The inet98v_rev2 is a pcb used in generic A13 based tablets. It features
volume buttons, a power barrel, micro-usb otg, headphone connector and
a power button.
The dts file is identical to the one submitted to the upstream kernel.
Signed-off-by: Hans de Goede
---
arch/arm/dts/Makefile| 1 +
arch/arm/dts/sun5i-a13-inet-98v-rev2.dts | 236 +++
board/sunxi/MAINTAINERS | 1 +
3 files changed, 238 insertions(+)
create mode 100644 arch/arm/dts/sun5i-a13-inet-98v-rev2.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index eb10a14..3d1d37f 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -95,6 +95,7 @@ dtb-$(CONFIG_MACH_SUN5I) += \
sun5i-a13-forfun-q88db.dtb \
sun5i-a13-hsg-h702.dtb \
sun5i-a13-inet-86vs.dtb \
+ sun5i-a13-inet-98v-rev2.dtb \
sun5i-a13-olinuxino.dtb \
sun5i-a13-olinuxino-micro.dtb \
sun5i-a13-tzx-q8-713b7.dtb \
diff --git a/arch/arm/dts/sun5i-a13-inet-98v-rev2.dts
b/arch/arm/dts/sun5i-a13-inet-98v-rev2.dts
new file mode 100644
index 000..6d466a2
--- /dev/null
+++ b/arch/arm/dts/sun5i-a13-inet-98v-rev2.dts
@@ -0,0 +1,236 @@
+/*
+ * Copyright 2015 Hans de Goede
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun5i-a13.dtsi"
+#include "sunxi-common-regulators.dtsi"
+#include
+#include
+#include
+#include
+
+/ {
+ model = "INet-98V Rev 02";
+ compatible = "primux,inet98v-rev2", "allwinner,sun5i-a13";
+
+ aliases {
+ serial0 = &uart1;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+};
+
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "okay";
+
+ axp209: pmic@34 {
+ reg = <0x34>;
+ interrupts = <0>;
+ };
+};
+
+#include "axp209.dtsi"
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_a>;
+ status = "okay";
+
+ pcf8563: rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+};
+
+&lradc {
+ vref-supply = <®_ldo2>;
+ status = "okay";
+
+ button@200 {
+ label = "Volume Up";
+ linux,code = ;
+ channel = <0>;
+ voltage = <20>;
+ };
+
+ button@400 {
+ label = "Volume Down";
+ linux,code = ;
+ channel = <0>;
+ voltage = <40>;
+ };
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_inet98fv2>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 6 0 GPIO_ACTIVE_HIGH>; /* PG0 */
+ cd-inverted;
+ status = "okay";
+};
+
+&mmc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_pins_a>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <8>;
+ non
[U-Boot] [PATCH 1/2] sunxi: Ampe_A76_defconfig: Add otg id pin configuration
Add otg id pin configuration, this speeds up bootup when no host cable is plugged into the otg port. Signed-off-by: Hans de Goede --- configs/Ampe_A76_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/Ampe_A76_defconfig b/configs/Ampe_A76_defconfig index 3aaf029..85724b0 100644 --- a/configs/Ampe_A76_defconfig +++ b/configs/Ampe_A76_defconfig @@ -5,6 +5,7 @@ CONFIG_DRAM_CLK=432 CONFIG_MMC0_CD_PIN="PG0" CONFIG_USB0_VBUS_PIN="PG12" CONFIG_USB0_VBUS_DET="PG1" +CONFIG_USB0_ID_DET="PG2" CONFIG_AXP_GPIO=y # CONFIG_VIDEO_HDMI is not set CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:18,pclk_khz:33000,le:45,ri:82,up:22,lo:22,hs:1,vs:1,sync:3,vmode:0" -- 2.4.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)
Hi Pavel, this works for me. many thanks. I will looking for some patch coming soon. best regards, Hannes On 25.08.2015 14:19, Pavel Machek wrote: On Tue 2015-08-25 14:13:17, Hannes Schmelzer wrote: Hi, i've same problem. Running tftp-hpa on Linux Mint 17. cat /etc/default/tftpd-hpa # /etc/default/tftpd-hpa RUN_DAEMON="yes" TFTP_USERNAME="tftp" TFTP_DIRECTORY="/tftpboot/tseries" TFTP_ADDRESS="0.0.0.0:69" TFTP_OPTIONS="-l -s" Yes. Please try patch I mailed half an hour ago... it should fix that. (Actually here it is again, without changelog). Sorry for the trouble, Pavel Date: Tue, 25 Aug 2015 13:44:25 +0200 From: Pavel Machek To: Bin Meng Cc: Joe Hershberger , Tom Rini , U-Boot Mailing List Subject: [PATCH] Change default tftp timeout to be rfc-compliant diff --git a/net/tftp.c b/net/tftp.c index 18ce84c..e919638 100644 --- a/net/tftp.c +++ b/net/tftp.c @@ -18,8 +18,9 @@ /* Well known TFTP port # */ #define WELL_KNOWN_PORT 69 -/* Millisecs to timeout for lost pkt */ -#define TIMEOUT100UL +/* Millisecs to timeout for lost pkt. Anything below 1000msec is against RFC, and + some servers will refuse it. */ +#define TIMEOUT1000UL #ifndef CONFIG_NET_RETRY_COUNT /* # of timeouts before giving up */ # define TIMEOUT_COUNT1000 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] arm: mvebu: Only set CONFIG_SKIP_LOWLEVEL_INIT for SPL
When running on the AXP I sometimes noticed a strange behavior. As some
characters are not echoed on the U-Boot prompt. Not disabling the
lowlevel_init code, especially calling cpu_init_cp15() in the main
U-Boot seems to solve this issue.
Signed-off-by: Stefan Roese
---
arch/arm/mach-mvebu/cpu.c | 31 +++
include/configs/db-88f6820-gp.h | 2 ++
include/configs/db-mv784mp-gp.h | 2 ++
include/configs/maxbcm.h| 2 ++
4 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
index efd4d04..895ad92 100644
--- a/arch/arm/mach-mvebu/cpu.c
+++ b/arch/arm/mach-mvebu/cpu.c
@@ -27,6 +27,14 @@ static struct mbus_win windows[] = {
CPU_TARGET_DEVICEBUS_BOOTROM_SPI, CPU_ATTR_BOOTROM },
};
+void lowlevel_init(void)
+{
+ /*
+* Dummy implementation, we only need LOWLEVEL_INIT
+* on Armada to configure CP15 in start.S / cpu_init_cp15()
+*/
+}
+
void reset_cpu(unsigned long ignored)
{
struct mvebu_system_registers *reg =
@@ -214,7 +222,10 @@ static void setup_usb_phys(void)
int arch_cpu_init(void)
{
-#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_ARMADA_38X)
+#if !defined(CONFIG_SPL_BUILD)
+ struct pl310_regs *const pl310 =
+ (struct pl310_regs *)CONFIG_SYS_PL310_BASE;
+
/*
* Only with disabled MMU its possible to switch the base
* register address on Armada 38x. Without this the SDRAM
@@ -234,18 +245,14 @@ int arch_cpu_init(void)
* configured the internal register base to the value used
* in the macros / defines in the U-Boot header (soc.h).
*/
- if (mvebu_soc_family() == MVEBU_SOC_A38X) {
- struct pl310_regs *const pl310 =
- (struct pl310_regs *)CONFIG_SYS_PL310_BASE;
- /*
-* To fully release / unlock this area from cache, we need
-* to flush all caches and disable the L2 cache.
-*/
- icache_disable();
- dcache_disable();
- clrbits_le32(&pl310->pl310_ctrl, L2X0_CTRL_EN);
- }
+ /*
+* To fully release / unlock this area from cache, we need
+* to flush all caches and disable the L2 cache.
+*/
+ icache_disable();
+ dcache_disable();
+ clrbits_le32(&pl310->pl310_ctrl, L2X0_CTRL_EN);
#endif
/*
diff --git a/include/configs/db-88f6820-gp.h b/include/configs/db-88f6820-gp.h
index 1dd4182..15f7bdf 100644
--- a/include/configs/db-88f6820-gp.h
+++ b/include/configs/db-88f6820-gp.h
@@ -16,7 +16,9 @@
#define CONFIG_SYS_L2_PL310
+#ifdef CONFIG_SPL_BUILD
#define CONFIG_SKIP_LOWLEVEL_INIT /* disable board lowlevel_init */
+#endif
#define CONFIG_SYS_GENERIC_BOARD
#define CONFIG_DISPLAY_BOARDINFO_LATE
diff --git a/include/configs/db-mv784mp-gp.h b/include/configs/db-mv784mp-gp.h
index eec2ba9..f075a2d 100644
--- a/include/configs/db-mv784mp-gp.h
+++ b/include/configs/db-mv784mp-gp.h
@@ -13,7 +13,9 @@
#define CONFIG_ARMADA_XP /* SOC Family Name */
#define CONFIG_DB_784MP_GP /* Board target name for DDR training */
+#ifdef CONFIG_SPL_BUILD
#define CONFIG_SKIP_LOWLEVEL_INIT /* disable board lowlevel_init */
+#endif
#define CONFIG_SYS_GENERIC_BOARD
#define CONFIG_DISPLAY_BOARDINFO_LATE
diff --git a/include/configs/maxbcm.h b/include/configs/maxbcm.h
index 3530a26..3bed9c7 100644
--- a/include/configs/maxbcm.h
+++ b/include/configs/maxbcm.h
@@ -11,7 +11,9 @@
* High Level Configuration Options (easy to change)
*/
#define CONFIG_ARMADA_XP /* SOC Family Name */
+#ifdef CONFIG_SPL_BUILD
#define CONFIG_SKIP_LOWLEVEL_INIT /* disable board lowlevel_init */
+#endif
#define CONFIG_SYS_GENERIC_BOARD
#define CONFIG_DISPLAY_BOARDINFO_LATE
--
2.5.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] arm: mvebu: Add option to use UART xmodem protocol via kwboot
This patch enables the use of the kwboot tool, to boot mainline U-Boot
on the Marvell Armada XP/38x SoC's. This is done by returning to the
SoC's BootROM after SPL has initialized the SDRAM. We need to make sure
to not reconfigure the internal register space and MBARs. Otherwise
the BootROM will not be able to continue after SPL jumps back to it.
To use this feature, please don't forget to change the BOOT_FROM line
in your board specfic kwbimage.cfg file this way:
BOOT_FROM uart
Tested on these Marvell eval boards:
DB-MV784MP-GP - Armada XP
DB-88F6820-GP - Armada 38x
Signed-off-by: Stefan Roese
Cc: Dirk Eibach
Cc: Kevin Smith
Cc: Luka Perkov
---
Makefile | 12 +++-
arch/arm/mach-mvebu/Kconfig| 10 ++
arch/arm/mach-mvebu/include/mach/cpu.h | 2 ++
arch/arm/mach-mvebu/include/mach/soc.h | 2 +-
arch/arm/mach-mvebu/lowlevel_spl.S | 16
arch/arm/mach-mvebu/spl.c | 25 +
6 files changed, 65 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 9919314..9d1905f 100644
--- a/Makefile
+++ b/Makefile
@@ -901,7 +901,7 @@ MKIMAGEFLAGS_u-boot.kwb = -n
$(srctree)/$(CONFIG_SYS_KWD_CONFIG:"%"=%) \
-T kwbimage -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_TEXT_BASE)
MKIMAGEFLAGS_u-boot-spl.kwb = -n $(srctree)/$(CONFIG_SYS_KWD_CONFIG:"%"=%) \
- -T kwbimage -a $(CONFIG_SPL_TEXT_BASE) -e $(CONFIG_SPL_TEXT_BASE)
+ -T kwbimage -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_TEXT_BASE)
MKIMAGEFLAGS_u-boot.pbl = -n $(srctree)/$(CONFIG_SYS_FSL_PBL_RCW:"%"=%) \
-R $(srctree)/$(CONFIG_SYS_FSL_PBL_PBI:"%"=%) -T pblimage
@@ -909,8 +909,18 @@ MKIMAGEFLAGS_u-boot.pbl = -n
$(srctree)/$(CONFIG_SYS_FSL_PBL_RCW:"%"=%) \
u-boot.img u-boot.kwb u-boot.pbl: u-boot.bin FORCE
$(call if_changed,mkimage)
+# If the kwboot xmodem protocol is used, to boot U-Boot on the MVEBU
+# SoC's, the SPL U-Boot returns to the BootROM after it completes
+# the SDRAM setup. The BootROM expects no U-Boot header in the main
+# U-Boot image. So we need to combine SPL and u-boot.bin instead of
+# u-boot.img in this case.
+ifdef CONFIG_MVEBU_BOOTROM_UARTBOOT
+u-boot-spl.kwb: u-boot.bin spl/u-boot-spl.bin FORCE
+ $(call if_changed,mkimage)
+else
u-boot-spl.kwb: u-boot.img spl/u-boot-spl.bin FORCE
$(call if_changed,mkimage)
+endif
MKIMAGEFLAGS_u-boot-dtb.img = $(MKIMAGEFLAGS_u-boot.img)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 1aa9640..79ff0e8 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -18,4 +18,14 @@ endchoice
config SYS_SOC
default "mvebu"
+config MVEBU_BOOTROM_UARTBOOT
+ bool "Use kwboot to boot via BootROM xmodem protocol"
+ help
+ This option provides support for booting via the Marvell
+ xmodem protocol, used by the kwboot tool.
+
+ Please don't forget to configure the boot device in
+ the board specific kwbimage.cfg file this way:
+ BOOT_FROM uart
+
endif
diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h
b/arch/arm/mach-mvebu/include/mach/cpu.h
index 6fa4173..5e8bf0c 100644
--- a/arch/arm/mach-mvebu/include/mach/cpu.h
+++ b/arch/arm/mach-mvebu/include/mach/cpu.h
@@ -119,6 +119,8 @@ int mvebu_mbus_probe(struct mbus_win windows[], int count);
int mvebu_soc_family(void);
u32 mvebu_get_nand_clock(void);
+void return_to_bootrom(void);
+
int mv_sdh_init(unsigned long regbase, u32 max_clk, u32 min_clk, u32 quirks);
/*
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h
b/arch/arm/mach-mvebu/include/mach/soc.h
index a8a6b27..64e5443 100644
--- a/arch/arm/mach-mvebu/include/mach/soc.h
+++ b/arch/arm/mach-mvebu/include/mach/soc.h
@@ -33,7 +33,7 @@
/* SOC specific definations */
#define INTREG_BASE0xd000
#define INTREG_BASE_ADDR_REG (INTREG_BASE + 0x20080)
-#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SYS_MVEBU_DDR_A38X)
+#if defined(CONFIG_SPL_BUILD)
/*
* On A38x switching the regs base address without running from
* SDRAM doesn't seem to work. So let the SPL still use the
diff --git a/arch/arm/mach-mvebu/lowlevel_spl.S
b/arch/arm/mach-mvebu/lowlevel_spl.S
index 69da7fe..c8cc8b2 100644
--- a/arch/arm/mach-mvebu/lowlevel_spl.S
+++ b/arch/arm/mach-mvebu/lowlevel_spl.S
@@ -5,10 +5,26 @@
#include
#include
+#ifdef CONFIG_MVEBU_BOOTROM_UARTBOOT
ENTRY(save_boot_params)
+ stmfd sp!, {r0 - r12, lr} /* @ save registers on stack */
+ ldr r12, =CONFIG_SPL_BOOTROM_SAVE
+ str sp, [r12]
b save_boot_params_ret
ENDPROC(save_boot_params)
+ENTRY(return_to_bootrom)
+ ldr r12, =CONFIG_SPL_BOOTROM_SAVE
+ ldr sp, [r12]
+ mov r0, #0x0/* @ return value: 0x0 NO_ERR */
+ ldmfd sp!, {r0 - r12, pc} /* @ restore regs and return */
+ENDPROC(return_to_bootrom)
+#else
+ENTRY(save_boot_params)
+ b
[U-Boot] [PATCH 1/3] arm: mvebu: Move Armada XP/38x Kconfig to mach specific Kconfig file
Introduce a mach-mvebu/Kconfig for all Armada based SoC's. Signed-off-by: Stefan Roese --- arch/arm/Kconfig| 16 arch/arm/mach-mvebu/Kconfig | 21 + board/Marvell/db-88f6820-gp/Kconfig | 3 --- board/Marvell/db-mv784mp-gp/Kconfig | 3 --- board/maxbcm/Kconfig| 3 --- configs/db-88f6820-gp_defconfig | 3 ++- configs/db-mv784mp-gp_defconfig | 1 + configs/maxbcm_defconfig| 1 + 8 files changed, 29 insertions(+), 22 deletions(-) create mode 100644 arch/arm/mach-mvebu/Kconfig diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index a99ae28..92e5512 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -103,18 +103,8 @@ config KIRKWOOD bool "Marvell Kirkwood" select CPU_ARM926EJS -config TARGET_DB_88F6820_GP - bool "Support DB-88F6820-GP" - select CPU_V7 - select SUPPORT_SPL - -config TARGET_DB_MV784MP_GP - bool "Support db-mv784mp-gp" - select CPU_V7 - select SUPPORT_SPL - -config TARGET_MAXBCM - bool "Support maxbcm" +config ARCH_MVEBU + bool "Marvell MVEBU family (Armada XP/38x)" select CPU_V7 select SUPPORT_SPL @@ -845,6 +835,8 @@ source "arch/arm/mach-keystone/Kconfig" source "arch/arm/mach-kirkwood/Kconfig" +source "arch/arm/mach-mvebu/Kconfig" + source "arch/arm/cpu/armv7/mx6/Kconfig" source "arch/arm/cpu/armv7/mx5/Kconfig" diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig new file mode 100644 index 000..1aa9640 --- /dev/null +++ b/arch/arm/mach-mvebu/Kconfig @@ -0,0 +1,21 @@ +if ARCH_MVEBU + +choice + prompt "Marvell MVEBU (Armada XP/38x) board select" + optional + +config TARGET_DB_88F6820_GP + bool "Support DB-88F6820-GP" + +config TARGET_DB_MV784MP_GP + bool "Support db-mv784mp-gp" + +config TARGET_MAXBCM + bool "Support maxbcm" + +endchoice + +config SYS_SOC + default "mvebu" + +endif diff --git a/board/Marvell/db-88f6820-gp/Kconfig b/board/Marvell/db-88f6820-gp/Kconfig index b2e9115..f12b968 100644 --- a/board/Marvell/db-88f6820-gp/Kconfig +++ b/board/Marvell/db-88f6820-gp/Kconfig @@ -6,9 +6,6 @@ config SYS_BOARD config SYS_VENDOR default "Marvell" -config SYS_SOC - default "mvebu" - config SYS_CONFIG_NAME default "db-88f6820-gp" diff --git a/board/Marvell/db-mv784mp-gp/Kconfig b/board/Marvell/db-mv784mp-gp/Kconfig index d0b426e..428a5e1 100644 --- a/board/Marvell/db-mv784mp-gp/Kconfig +++ b/board/Marvell/db-mv784mp-gp/Kconfig @@ -6,9 +6,6 @@ config SYS_BOARD config SYS_VENDOR default "Marvell" -config SYS_SOC - default "mvebu" - config SYS_CONFIG_NAME default "db-mv784mp-gp" diff --git a/board/maxbcm/Kconfig b/board/maxbcm/Kconfig index e86aa16..2edccfe 100644 --- a/board/maxbcm/Kconfig +++ b/board/maxbcm/Kconfig @@ -3,9 +3,6 @@ if TARGET_MAXBCM config SYS_BOARD default "maxbcm" -config SYS_SOC - default "mvebu" - config SYS_CONFIG_NAME default "maxbcm" diff --git a/configs/db-88f6820-gp_defconfig b/configs/db-88f6820-gp_defconfig index 0ff6706..24647ce 100644 --- a/configs/db-88f6820-gp_defconfig +++ b/configs/db-88f6820-gp_defconfig @@ -1,6 +1,7 @@ -CONFIG_SPL=y CONFIG_ARM=y +CONFIG_ARCH_MVEBU=y CONFIG_TARGET_DB_88F6820_GP=y +CONFIG_SPL=y # CONFIG_CMD_IMLS is not set # CONFIG_CMD_FLASH is not set # CONFIG_CMD_SETEXPR is not set diff --git a/configs/db-mv784mp-gp_defconfig b/configs/db-mv784mp-gp_defconfig index d11377f..4a828a0 100644 --- a/configs/db-mv784mp-gp_defconfig +++ b/configs/db-mv784mp-gp_defconfig @@ -1,4 +1,5 @@ CONFIG_ARM=y +CONFIG_ARCH_MVEBU=y CONFIG_TARGET_DB_MV784MP_GP=y CONFIG_SPL=y # CONFIG_CMD_IMLS is not set diff --git a/configs/maxbcm_defconfig b/configs/maxbcm_defconfig index b0b0d6c..5957997 100644 --- a/configs/maxbcm_defconfig +++ b/configs/maxbcm_defconfig @@ -1,4 +1,5 @@ CONFIG_ARM=y +CONFIG_ARCH_MVEBU=y CONFIG_TARGET_MAXBCM=y CONFIG_SPL=y # CONFIG_CMD_IMLS is not set -- 2.5.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v5, 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot
Le mardi 25 août 2015 à 10:40 +0200, Schmelzer Hannes a écrit : > Hi Paul, Tom, > > i am failing bring up my AM335x boards (tseries, kwb) with bare UART > connection since introducing this change. Does this mean that you're trying to get the device to load the full U-Boot binary over UART? > For my understanding this function should be called allways if chip > has basically support for some BOOT_DEVICE_x __AND__ there is no > implementation for it - the function should prevent target from > stalling with selecting another (hopefully working) boot-device. > Right ? This is a fallback mechanism that allows selecting the boot device from the SYS_BOOT pins when the U-Boot SPL was loaded from peripheral booting (USB or UART) by the bootrom and that the U-Boot SPL has no support for continuing boot through that same peripheral (USB or UART). It does require omap_sys_boot_device to be implemented for each platform (currently, only am33xx doesn't have a proper one). The point is that it selects another *memory* (read, not peripheral) boot device that the U-Boot SPL may be able to handle. In any case, it offers a way to *maybe* put the U-Boot SPL on the right track instead of being unable to boot at all. > I am not sure at this time how to deal with the facts ... i see > several possibilities: > > a) > i have to implement some "omap_sys_boot_device" function in my boards > - this would maybe sometimes comfortable but i think this is not > inventors mind. It would be more convenient to implement it in some > common place for AM335x or OMAP. But what do with the information > about SYS_BOOT pins ? they always represent a boot-order ... which > boot-device should it take ? That function is not supposed to be board-specific at all, but to be platform-specific. This is not the way to select the proper boot device, which is done by reading the boot info structure passed by the bootrom (first thing in omap-common/lowlevel_init.S). > b) and/or something is wrong with the #ifdef ... construct at line #67 > - > In fact there is a problem with > defined(BOOT_DEVICE_USBETH) && !defined(CONFIG_SPL_USBETH_SUPPORT) > > basicaly BOOT_DEVICE_USBETH is defined in spl.h but in my > configuration there is no #define for CONFIG_SPL_USBETH_SUPPORT and so > the following switch/case calls in case of BOOT_DEVICE_UART this weak > function. If I got everything right, the bootrom is passing BOOT_DEVICE_UART as boot device, but you haven't selected CONFIG_SPL_YMODEM_SUPPORT. Thus, it falls back to asking omap_sys_boot_device, which is not implemented. The real problem here is that you have not enabled support for loading the main U-Boot binary via UART, with CONFIG_SPL_YMODEM_SUPPORT. UART booting is unrelated to CONFIG_SPL_USBETH_SUPPORT. > further i think that this construct isn't complete yet, because it > wants to handle all peripheral booting on AM335x or OMAP in general. > > following peripherals are currently handled: > > BOOT_DEVICE_UART > BOOT_DEVICE_USB > BOOT_DEVICE_USBETH > > but there is also > BOOT_DEVICE_CPGMAC > > Summary i think this changeset isn't complete. Can the bootrom indicate that it booted from BOOT_DEVICE_CPGMAC? I haven't seen that and don't really know what it corresponds to. But if you think it is concerned by this fallback mechanism, you could add support for it. I only made this for the omap devices I have (and I don't have any am33xx board) and I didn't want to blindly implement too much for am33xx. > On 28.07.2015 16:59, Tom Rini wrote: > > > On Wed, Jul 15, 2015 at 04:02:23PM +0200, Paul Kocialkowski wrote: > > > > > OMAP devices might boot from peripheral devices, such as UART or USB. > > > When that happens, the U-Boot SPL tries to boot the next stage (complete > > > U-Boot) > > > from that peripheral device, but in most cases, this is not a valid boot > > > device. > > > > > > This introduces a fallback option that reads the SYS_BOOT pins, that are > > > used by > > > the bootrom to determine which device to boot from. It is intended for the > > > SYS_BOOT value to be interpreted in the memory-preferred scheme, so that > > > the > > > U-Boot SPL can load the next stage from a valid location. > > > > > > Practically, this options allows loading the U-Boot SPL through USB and > > > have it > > > load the next stage according to the memory device selected by SYS_BOOT > > > instead > > > of stalling. > > > > > > Signed-off-by: Paul Kocialkowski > > Applied to u-boot/master, thanks! > > > > > > > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > http://lists.denx.de/mailman/listinfo/u-boot > signature.asc Description: This is a digitally signed message part ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v5, 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot
Hi Paul, thanks for answer. On 25.08.2015 14:27, Paul Kocialkowski wrote: Le mardi 25 août 2015 à 10:40 +0200, Schmelzer Hannes a écrit : Hi Paul, Tom, i am failing bring up my AM335x boards (tseries, kwb) with bare UART connection since introducing this change. Does this mean that you're trying to get the device to load the full U-Boot binary over UART? Yes i do so. On at least one BuR board this is the only possibility for very first startup. Once U-Boot is loaded via UART we fetch the rest from TFTP and burn it into eMMC flash connected to MMC1. For my understanding this function should be called allways if chip has basically support for some BOOT_DEVICE_x __AND__ there is no implementation for it - the function should prevent target from stalling with selecting another (hopefully working) boot-device. Right ? This is a fallback mechanism that allows selecting the boot device from the SYS_BOOT pins when the U-Boot SPL was loaded from peripheral booting (USB or UART) by the bootrom and that the U-Boot SPL has no support for continuing boot through that same peripheral (USB or UART). It does require omap_sys_boot_device to be implemented for each platform (currently, only am33xx doesn't have a proper one). The point is that it selects another *memory* (read, not peripheral) boot device that the U-Boot SPL may be able to handle. In any case, it offers a way to *maybe* put the U-Boot SPL on the right track instead of being unable to boot at all. Okay, i understand - this keeps track with my understanding. I am not sure at this time how to deal with the facts ... i see several possibilities: a) i have to implement some "omap_sys_boot_device" function in my boards - this would maybe sometimes comfortable but i think this is not inventors mind. It would be more convenient to implement it in some common place for AM335x or OMAP. But what do with the information about SYS_BOOT pins ? they always represent a boot-order ... which boot-device should it take ? That function is not supposed to be board-specific at all, but to be platform-specific. This is not the way to select the proper boot device, which is done by reading the boot info structure passed by the bootrom (first thing in omap-common/lowlevel_init.S). b) and/or something is wrong with the #ifdef ... construct at line #67 - In fact there is a problem with defined(BOOT_DEVICE_USBETH) && !defined(CONFIG_SPL_USBETH_SUPPORT) basicaly BOOT_DEVICE_USBETH is defined in spl.h but in my configuration there is no #define for CONFIG_SPL_USBETH_SUPPORT and so the following switch/case calls in case of BOOT_DEVICE_UART this weak function. If I got everything right, the bootrom is passing BOOT_DEVICE_UART as boot device, but you haven't selected CONFIG_SPL_YMODEM_SUPPORT. Thus, it falls back to asking omap_sys_boot_device, which is not implemented. I don't think, there is everything right. Have a closer look to the #ifdef. #if (defined(BOOT_DEVICE_UART) && !defined(CONFIG_SPL_YMODEM_SUPPORT)) || \ (defined(BOOT_DEVICE_USB) && !defined(CONFIG_SPL_USB_SUPPORT)) || \ (defined(BOOT_DEVICE_USBETH) && !defined(CONFIG_SPL_USBETH_SUPPORT)) I have enabled CONFIG_SPL_YMODEM_SUPPORT, look at bur_am335x_common.h. The real problem here is that you have not enabled support for loading the main U-Boot binary via UART, with CONFIG_SPL_YMODEM_SUPPORT. UART booting is unrelated to CONFIG_SPL_USBETH_SUPPORT. No, due to the fact that defined(BOOT_DEVICE_USBETH) is allways true (spl.h) and i don't have CONFIG_SPL_USBETH_SUPPORT enabled, the #ifdef above: defined(BOOT_DEVICE_USBETH) && !defined(CONFIG_SPL_USBETH_SUPPORT) becomes true and the followed switch/case does the rest. further i think that this construct isn't complete yet, because it wants to handle all peripheral booting on AM335x or OMAP in general. following peripherals are currently handled: BOOT_DEVICE_UART BOOT_DEVICE_USB BOOT_DEVICE_USBETH but there is also BOOT_DEVICE_CPGMAC Summary i think this changeset isn't complete. Can the bootrom indicate that it booted from BOOT_DEVICE_CPGMAC? I haven't seen that and don't really know what it corresponds to. But if you think it is concerned by this fallback mechanism, you could add support for it. I only made this for the omap devices I have (and I don't have any am33xx board) and I didn't want to blindly implement too much for am33xx. Yes, thats possible von AM335x. I will have a close look if it is necessary to implement here some fallback. But probably not, because the most likely case is that "full" U-Boot supports Ethernet and the SPL doesn't and not otherwise :-) best regards, Hannes ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net: protect status led access in bootp
This fixes the error when STATUS_LED_BOOT is not defined. Signed-off-by: Thomas Chou --- net/bootp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/bootp.c b/net/bootp.c index 43466af..ab17869 100644 --- a/net/bootp.c +++ b/net/bootp.c @@ -349,7 +349,7 @@ static void bootp_handler(uchar *pkt, unsigned dest, struct in_addr sip, /* * Got a good BOOTP reply. Copy the data into our variables. */ -#ifdef CONFIG_STATUS_LED +#if defined(CONFIG_STATUS_LED) && defined(STATUS_LED_BOOT) status_led_set(STATUS_LED_BOOT, STATUS_LED_OFF); #endif -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Change default tftp timeout to be rfc-compliant
Hi Pavel, Joe, On Tue, Aug 25, 2015 at 7:44 PM, Pavel Machek wrote: > > > tftp timeout of 100msec gives good performance on local ethernet, but > some servers (Centos) refuse to operate, and it is against RFC 2349. > > This fixes regression caused by > 620776d734e4b126c407f636bda825a594a17723 . > This patch does not fix the issue properly. As the commit 620776d also changed the "<1000" test logic to "<10", which should not be. See my comments below. > Signed-off-by: Pavel Machek > > diff --git a/net/tftp.c b/net/tftp.c > index 18ce84c..e919638 100644 > --- a/net/tftp.c > +++ b/net/tftp.c > @@ -18,8 +18,9 @@ > > /* Well known TFTP port # */ > #define WELL_KNOWN_PORT69 > -/* Millisecs to timeout for lost pkt */ > -#define TIMEOUT100UL > +/* Millisecs to timeout for lost pkt. Anything below 1000msec is against > RFC, and > + some servers will refuse it. */ Nits: please use correct multi-line comment format. > +#define TIMEOUT1000UL > #ifndefCONFIG_NET_RETRY_COUNT > /* # of timeouts before giving up */ > # define TIMEOUT_COUNT 1000 > > -- I still would like to revert commit 620776d (IOW, apply my revert patch @ http://patchwork.ozlabs.org/patch/510389/). Then Pavel to submit a new patch to change only TIMEOUT_COUNT to something larger (I am still not convinced that we need change the retry count from 10 to 1000). Perhaps with a better comment in the codes to explain why a larger TIMEOUT_COUNT is needed. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] ARM: rpi: Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support
Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support and enable it to set
'board_rev' and 'board_name' envs.
'board_rev' can be used in scripts to determine what board we are running on
and 'board_name' for pretty printing.
Signed-off-by: Guillaume GARDET
Cc: Stephen Warren
---
Changes in V2:
* Move setenvs to set_board_info() function
* Expand patch log
board/raspberrypi/rpi/rpi.c | 13 +
include/configs/rpi-common.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index d21750e..dc6f096 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -236,10 +236,23 @@ static void set_usbethaddr(void)
return;
}
+#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+static void set_board_info(void)
+{
+ char str_rev[11];
+ sprintf(str_rev, "0x%X", rpi_board_rev);
+ setenv("board_rev", str_rev);
+ setenv("board_name", models[rpi_board_rev].name);
+}
+#endif /* CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG */
+
int misc_init_r(void)
{
set_fdtfile();
set_usbethaddr();
+#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+ set_board_info();
+#endif
return 0;
}
diff --git a/include/configs/rpi-common.h b/include/configs/rpi-common.h
index 8830a10..17237cf 100644
--- a/include/configs/rpi-common.h
+++ b/include/configs/rpi-common.h
@@ -133,6 +133,7 @@
#include
/* Environment */
+#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
#define ENV_DEVICE_SETTINGS \
"stdin=serial,lcd\0" \
"stdout=serial,lcd\0" \
--
1.8.4.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MIPS: add atomic operations support.
some of the u-boot frameworks like ubi-fs and eth_gadget
uses atomic_* api's. So add atomic api's for mips.
This makes ubi-fs on nand work with mips platform.
Signed-off-by: Govindraj Raja
---
arch/mips/include/asm/atomic.h | 90 ++
1 file changed, 90 insertions(+)
create mode 100644 arch/mips/include/asm/atomic.h
diff --git a/arch/mips/include/asm/atomic.h b/arch/mips/include/asm/atomic.h
new file mode 100644
index 000..163e7e2
--- /dev/null
+++ b/arch/mips/include/asm/atomic.h
@@ -0,0 +1,90 @@
+/*
+ * Based on: linux/arch/mips/include/asm/atomic.h
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __ASM_MIPS_ATOMIC_H
+#define __ASM_MIPS_ATOMIC_H
+
+typedef struct { volatile int counter; } atomic_t;
+
+#define ATOMIC_INIT(i) { (i) }
+
+#include
+
+#define atomic_read(v) ((v)->counter)
+#define atomic_set(v, i) (((v)->counter) = (i))
+
+static inline void atomic_add(int i, volatile atomic_t *v)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ v->counter += i;
+ local_irq_restore(flags);
+}
+
+static inline void atomic_sub(int i, volatile atomic_t *v)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ v->counter -= i;
+ local_irq_restore(flags);
+}
+
+static inline void atomic_inc(volatile atomic_t *v)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ v->counter += 1;
+ local_irq_restore(flags);
+}
+
+static inline void atomic_dec(volatile atomic_t *v)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ v->counter -= 1;
+ local_irq_restore(flags);
+}
+
+static inline int atomic_dec_and_test(volatile atomic_t *v)
+{
+ unsigned long flags;
+ int val;
+
+ local_irq_save(flags);
+ val = v->counter;
+ v->counter = val -= 1;
+ local_irq_restore(flags);
+
+ return val == 0;
+}
+
+static inline int atomic_add_negative(int i, volatile atomic_t *v)
+{
+ unsigned long flags;
+ int val;
+
+ local_irq_save(flags);
+ val = v->counter;
+ v->counter = val += i;
+ local_irq_restore(flags);
+
+ return val < 0;
+}
+
+static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ *addr &= ~mask;
+ local_irq_restore(flags);
+}
+
+#endif /* __ASM_MIPS_ATOMIC_H */
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] x86: EFI: boot fails at exit_boot_services - Was: Stuck trying to build a non-qemu EFI payload
Hi Simon, thanks for helping, please find my reply below. On 21 August 2015 at 23:51, Simon Glass wrote: > Note that once you call exit_boot_services you will not be able to use > the console. Be careful here - the board may appear to hang but > actually it is broken by you trying to output to the console. Yes, I had realised it, but it seemed - on qemu - that it would still work to call "putc", after the code: > map.version = version; > map.desc_size = desc_size; > add_entry_addr(priv, EFIET_MEMORY_MAP, &map, sizeof(map), desc, size); > add_entry_addr(priv, EFIET_END, NULL, 0, 0, 0); But maybe I was just "lucky" and it worked even if it was not supposed to. For example, maybe it was using memory pages that had already been freed. However, after your reply, I re-cloned the x86 branch, just to be sure I would be starting from a clean slate, and re-did the configuration from scratch, without adding any traces. The result is that stub reaches the call "jump_to_uboot", so it seems that there are no problems there. The issues are to be found in the payload (as expected, since I'm using the qemu defconfig). Trying the QEMU image on my Haswell test device, I see it rebooting. Since I do not have means to obtain a serial console (please see footer note), I resorted to using a "while(1);" to identify the point where the reboot happens, by turning the reboot into a hang. The location where the reboot is triggered is in: common/board_f.c: board_init_f_mem @ 1048: memset(gd_ptr, '\0', sizeof(*gd)); I do not know the value of the pointer, but it seems that it is incorrect and writing to this address causes a reset. I wonder if this is because I'm still using the device tree for the machine emulated by QEMU and if I should build one for my specific Haswell NUC. Btw, the EFI bios offers the option of printing the EFI device tree. Is it the same used by U-Boot, so that I could use this information to create the Device Tree file? -- thanks, igor ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Change default tftp timeout to be rfc-compliant
On Tue 2015-08-25 21:03:26, Bin Meng wrote: > Hi Pavel, Joe, > > On Tue, Aug 25, 2015 at 7:44 PM, Pavel Machek wrote: > > > > > > tftp timeout of 100msec gives good performance on local ethernet, but > > some servers (Centos) refuse to operate, and it is against RFC 2349. > > > > This fixes regression caused by > > 620776d734e4b126c407f636bda825a594a17723 . > > > > This patch does not fix the issue properly. As the commit 620776d also > changed the "<1000" test logic to "<10", which should not be. See my > comments below. Yes, I know.. and I'd like the test logic to stay. Some tftp servers can handle that, and performance is significantly better that way. Best regards, Pavel > I still would like to revert commit 620776d (IOW, apply my revert > patch @ http://patchwork.ozlabs.org/patch/510389/). Then Pavel to > submit a new patch to change only TIMEOUT_COUNT to something larger (I > am still not convinced that we need change the retry count from 10 to > 1000). Perhaps with a better comment in the codes to explain why a > larger TIMEOUT_COUNT is needed. > > Regards, > Bin -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v5, 5/8] omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot
> > If I got everything right, the bootrom is passing BOOT_DEVICE_UART as > > boot device, but you haven't selected CONFIG_SPL_YMODEM_SUPPORT. Thus, > > it falls back to asking omap_sys_boot_device, which is not implemented. > I don't think, there is everything right. Have a closer look to the #ifdef. > > #if (defined(BOOT_DEVICE_UART) && !defined(CONFIG_SPL_YMODEM_SUPPORT)) || \ > (defined(BOOT_DEVICE_USB) && !defined(CONFIG_SPL_USB_SUPPORT)) || \ > (defined(BOOT_DEVICE_USBETH) && !defined(CONFIG_SPL_USBETH_SUPPORT)) > > I have enabled CONFIG_SPL_YMODEM_SUPPORT, look at bur_am335x_common.h. > > > The real problem here is that you have not enabled support for loading > > the main U-Boot binary via UART, with CONFIG_SPL_YMODEM_SUPPORT. > > > > UART booting is unrelated to CONFIG_SPL_USBETH_SUPPORT. > No, due to the fact that defined(BOOT_DEVICE_USBETH) is allways true > (spl.h) and i don't have > CONFIG_SPL_USBETH_SUPPORT enabled, the #ifdef above: > > defined(BOOT_DEVICE_USBETH) && !defined(CONFIG_SPL_USBETH_SUPPORT) > > becomes true and the followed switch/case does the rest. Oh you're right, I hadn't thought this through. I'll think about how to solve this in the cleanest way (I wouldn't want to duplicate the ifdef logic too much). Thanks for bringing this up. > >> further i think that this construct isn't complete yet, because it > >> wants to handle all peripheral booting on AM335x or OMAP in general. > >> > >> following peripherals are currently handled: > >> > >> BOOT_DEVICE_UART > >> BOOT_DEVICE_USB > >> BOOT_DEVICE_USBETH > >> > >> but there is also > >> BOOT_DEVICE_CPGMAC > >> > >> Summary i think this changeset isn't complete. > > Can the bootrom indicate that it booted from BOOT_DEVICE_CPGMAC? > > I haven't seen that and don't really know what it corresponds to. But if > > you think it is concerned by this fallback mechanism, you could add > > support for it. I only made this for the omap devices I have (and I > > don't have any am33xx board) and I didn't want to blindly implement too > > much for am33xx. > Yes, thats possible von AM335x. > I will have a close look if it is necessary to implement here some fallback. > But probably not, because the most likely case is that "full" U-Boot > supports Ethernet and the SPL doesn't and not otherwise :-) Alright then, that's fine with me. It's okay if the fallback mechanism doesn't handle all use cases, too. -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/ signature.asc Description: This is a digitally signed message part ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Change default tftp timeout to be rfc-compliant
On Tue, Aug 25, 2015 at 04:32:48PM +0200, Pavel Machek wrote: > On Tue 2015-08-25 21:03:26, Bin Meng wrote: > > Hi Pavel, Joe, > > > > On Tue, Aug 25, 2015 at 7:44 PM, Pavel Machek wrote: > > > > > > > > > tftp timeout of 100msec gives good performance on local ethernet, but > > > some servers (Centos) refuse to operate, and it is against RFC 2349. > > > > > > This fixes regression caused by > > > 620776d734e4b126c407f636bda825a594a17723 . > > > > > > > This patch does not fix the issue properly. As the commit 620776d also > > changed the "<1000" test logic to "<10", which should not be. See my > > comments below. > > Yes, I know.. and I'd like the test logic to stay. Some tftp servers > can handle that, and performance is significantly better that way. Well, what does the RFC say we can and cannot do here? -- 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] board/BuR: simplify default IP-setup on B&R boards.
On Tue, Aug 25, 2015 at 01:55:41PM +0200, Hannes Schmelzer wrote:
> To simplify and having a common default IP-setup on all B&R boards we
> introduce an environment variable "brdefaultip" which does following.
>
> Test if ${ipaddr} is empty, if yes it set's up some defaults:
> - ipaddr : 192.168.60.1
> - netmask : 255.255.255.0
> - gatewayip: 192.168.60.254
> - serverip : 192.168.60.254
>
> This environment is ran from CONFIG_PREBOOT.
>
> All other "tricks" are dropped.
>
> Signed-off-by: Hannes Schmelzer
>
Reviewed-by: Tom Rini
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Fix bad return value checks (detected with Coccinelle)
In the "Getting Started with Coccinelle - KVM edition" presentation that
has been held by Julia Lawall at the KVM forum 2015 (see the slides at
http://events.linuxfoundation.org/sites/events/files/slides/tutorial_kvm_0.pdf),
she pointed out some bad return value checks in U-Boot that can be
detected with Coccinelle by using the following config file:
@@
identifier x,y;
identifier f;
statement S;
@@
x = f(...);
(
if (x < 0) S
|
if (
- y
+ x
< 0) S
)
This patch now fixes these issues.
Signed-off-by: Thomas Huth
---
Note: I haven't tested this patch at all, so please review carefully.
I just wanted to let you know about these issues in case you haven't
been aware of them yet. And in case if somebody else already reported
them, please excuse the double information, I wasn't reading the
u-boot mailing list so far yet.
diff -u -p a/board/samsung/origen/tools/mkorigenspl.c
b/board/samsung/origen/tools/mkorigenspl.c
--- a/board/samsung/origen/tools/mkorigenspl.c
+++ b/board/samsung/origen/tools/mkorigenspl.c
@@ -52,7 +52,7 @@ int main(int argc, char **argv)
}
ofd = open(argv[2], O_WRONLY | O_CREAT | O_TRUNC, FILE_PERM);
- if (ifd < 0) {
+ if (ofd < 0) {
fprintf(stderr, "%s: Can't open %s: %s\n",
argv[0], argv[2], strerror(errno));
if (ifd)
diff -u -p a/board/samsung/smdkv310/tools/mksmdkv310spl.c
b/board/samsung/smdkv310/tools/mksmdkv310spl.c
--- a/board/samsung/smdkv310/tools/mksmdkv310spl.c
+++ b/board/samsung/smdkv310/tools/mksmdkv310spl.c
@@ -50,7 +50,7 @@ int main(int argc, char **argv)
}
ofd = open(argv[2], O_WRONLY | O_CREAT | O_TRUNC, FILE_PERM);
- if (ifd < 0) {
+ if (ofd < 0) {
fprintf(stderr, "%s: Can't open %s: %s\n",
argv[0], argv[2], strerror(errno));
if (ifd)
diff -u -p a/drivers/hwmon/lm81.c b/drivers/hwmon/lm81.c
--- a/drivers/hwmon/lm81.c
+++ b/drivers/hwmon/lm81.c
@@ -90,7 +90,7 @@ int dtt_init_one(int sensor)
if (adr < 0)
return 1;
rev = dtt_read (sensor, DTT_REV);
- if (adr < 0)
+ if (rev < 0)
return 1;
debug ("DTT: Found LM81@%x Rev: %d\n", adr, rev);
diff -u -p a/tools/fit_check_sign.c b/tools/fit_check_sign.c
--- a/tools/fit_check_sign.c
+++ b/tools/fit_check_sign.c
@@ -75,7 +75,7 @@ int main(int argc, char **argv)
if (ffd < 0)
return EXIT_FAILURE;
kfd = mmap_fdt(cmdname, keyfile, 0, &key_blob, &ksbuf, false);
- if (ffd < 0)
+ if (kfd < 0)
return EXIT_FAILURE;
image_set_host_blob(key_blob);
diff -u -p a/tools/mkexynosspl.c b/tools/mkexynosspl.c
--- a/tools/mkexynosspl.c
+++ b/tools/mkexynosspl.c
@@ -110,7 +110,7 @@ int main(int argc, char **argv)
}
ofd = open(argv[of_index], O_WRONLY | O_CREAT | O_TRUNC, FILE_PERM);
- if (ifd < 0) {
+ if (ofd < 0) {
fprintf(stderr, "%s: Can't open %s: %s\n",
prog_name, argv[of_index], strerror(errno));
exit(EXIT_FAILURE);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Change default tftp timeout to be rfc-compliant
On Tue 2015-08-25 10:49:10, Tom Rini wrote: > On Tue, Aug 25, 2015 at 04:32:48PM +0200, Pavel Machek wrote: > > On Tue 2015-08-25 21:03:26, Bin Meng wrote: > > > Hi Pavel, Joe, > > > > > > On Tue, Aug 25, 2015 at 7:44 PM, Pavel Machek wrote: > > > > > > > > > > > > tftp timeout of 100msec gives good performance on local ethernet, but > > > > some servers (Centos) refuse to operate, and it is against RFC 2349. > > > > > > > > This fixes regression caused by > > > > 620776d734e4b126c407f636bda825a594a17723 . > > > > > > > > > > This patch does not fix the issue properly. As the commit 620776d also > > > changed the "<1000" test logic to "<10", which should not be. See my > > > comments below. > > > > Yes, I know.. and I'd like the test logic to stay. Some tftp servers > > can handle that, and performance is significantly better that way. > > Well, what does the RFC say we can and cannot do here? According to RFC, we should not be putting 0 there. Best regards, Pavel http://www.rfc-base.org/txt/rfc-2349.txt #secs The number of seconds to wait before retransmitting, specified in ASCII. Valid values range between "1" and "255" seconds, inclusive. This is a NULL-terminated field. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] omap-common: SYS_BOOT fallback logic correction
The SYS_BOOT-based fallback shouldn't only check for one of the conditions of
use and then let the switch/case handle each boot device without enforcing the
conditions for each type of boot device again.
For instance, this behaviour would trigger the fallback for UART when
BOOT_DEVICE_UART is defined, CONFIG_SPL_YMODEM_SUPPORT is enabled (which should
be a show-stopper) and e.g. BOOT_DEVICE_USB is enabled and not
CONFIG_SPL_USB_SUPPORT.
Separating the logic for USB and UART is a first step to solve this.
In addition, a similar problematic behaviour took place when BOOT_DEVICE_USBETH,
BOOT_DEVICE_USB and CONFIG_SPL_USBETH_SUPPORT were enabled and not
CONFIG_SPL_USB_SUPPORT.
Since BOOT_DEVICE_USBETH is only a problem when it's defined to the same value
as BOOT_DEVICE_USB, we can check that BOOT_DEVICE_USBETH and BOOT_DEVICE_USB are
different and if not, that CONFIG_SPL_USBETH_SUPPORT is not enabled to enable
the SYS_BOOT-based fallback mechanism.
Signed-off-by: Paul Kocialkowski
---
arch/arm/cpu/armv7/omap-common/boot-common.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/boot-common.c
b/arch/arm/cpu/armv7/omap-common/boot-common.c
index 5ec46fa..41f65c0 100644
--- a/arch/arm/cpu/armv7/omap-common/boot-common.c
+++ b/arch/arm/cpu/armv7/omap-common/boot-common.c
@@ -30,6 +30,7 @@ void save_omap_boot_params(void)
{
u32 boot_params = *((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS);
struct omap_boot_parameters *omap_boot_params;
+ int sys_boot_device = 0;
u32 boot_device;
u32 boot_mode;
@@ -64,31 +65,31 @@ void save_omap_boot_params(void)
if (boot_device == BOOT_DEVICE_QSPI_4)
boot_device = BOOT_DEVICE_SPI;
#endif
-#if (defined(BOOT_DEVICE_UART) && !defined(CONFIG_SPL_YMODEM_SUPPORT)) || \
-(defined(BOOT_DEVICE_USB) && !defined(CONFIG_SPL_USB_SUPPORT)) || \
-(defined(BOOT_DEVICE_USBETH) && !defined(CONFIG_SPL_USBETH_SUPPORT))
/*
* When booting from peripheral booting, the boot device is not usable
* as-is (unless there is support for it), so the boot device is instead
* figured out using the SYS_BOOT pins.
*/
- switch (boot_device) {
-#ifdef BOOT_DEVICE_UART
- case BOOT_DEVICE_UART:
+#if defined(BOOT_DEVICE_UART) && !defined(CONFIG_SPL_YMODEM_SUPPORT)
+ if (boot_device == BOOT_DEVICE_UART)
+ sys_boot_device = 1;
#endif
-#ifdef BOOT_DEVICE_USB
- case BOOT_DEVICE_USB:
+#if defined(BOOT_DEVICE_USB) && !defined(CONFIG_SPL_USB_SUPPORT) && \
+(!defined(BOOT_DEVICE_USBETH) || \
+((BOOT_DEVICE_USBETH != BOOT_DEVICE_USB) || \
+!defined(CONFIG_SPL_USBETH_SUPPORT)))
+ if (boot_device == BOOT_DEVICE_USB)
+ sys_boot_device = 1;
#endif
+
+ if (sys_boot_device) {
boot_device = omap_sys_boot_device();
/* MMC raw mode will fallback to FS mode. */
if ((boot_device >= MMC_BOOT_DEVICES_START) &&
(boot_device <= MMC_BOOT_DEVICES_END))
boot_mode = MMCSD_MODE_RAW;
-
- break;
}
-#endif
gd->arch.omap_boot_device = boot_device;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] drivers: Introduce a simplified remoteproc framework
On 08/25/2015 12:04 AM, Simon Glass wrote:
[...]
>> index ..e8fdb124e251
>> --- /dev/null
>> +++ b/common/cmd_remoteproc.c
>> @@ -0,0 +1,224 @@
>> +/*
>> + * (C) Copyright 2015
>> + * Texas Instruments Incorporated - http://www.ti.com/
>> + * SPDX-License-Identifier:GPL-2.0+
>> + */
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>
> nit: can you please sort those includes?
Yes - Sorry abotu that , I missed.
[...]
>> +static int print_remoteproc_list(void)
>> +{
>> + struct udevice *dev;
>> + struct uclass *uc;
>> + int ret;
>> + char *type;
>> +
>> + ret = uclass_get(UCLASS_RPROC, &uc);
>> + if (ret) {
>> + printf("Cannot find Remote processor class\n");
>> + return ret;
>> + }
>> +
>> + uclass_foreach_dev(dev, uc) {
>> + struct dm_rproc_uclass_pdata *uc_pdata;
>> + const struct dm_rproc_ops *ops = device_get_ops(dev);
>
> Can you create a rproc_get_ops() static inline as is done with other
> uclasses, and use that?
Will do. thanks on the hint.
>> +
>> + uc_pdata = dev_get_uclass_platdata(dev);
>> + if (!uc_pdata) {
>> + debug("%s: no uclass_platdata?\n", dev->name);
>> + return -ENXIO;
>> + }
>
> That can never happen so you can remove this check.
OK. will remove elsewhere as well.
>> diff --git a/doc/device-tree-bindings/remoteproc/remoteproc.txt
>> b/doc/device-tree-bindings/remoteproc/remoteproc.txt
>> new file mode 100644
>> index ..1a98a2e3a03c
>> --- /dev/null
>> +++ b/doc/device-tree-bindings/remoteproc/remoteproc.txt
>> @@ -0,0 +1,14 @@
>> +Remote Processor uClass
>
> uclass
Thanks. will do.
>
>> +
>> +Binding:
>> +
>> +Remoteproc devices shall have compatible corresponding to thier
>> +drivers. However the following generic properties will be supported
>> +
>> +Optional Properties:
>> +- remoteproc-name: a string, used if provided to describe the processor.
>> + This must be unique in an operational system.
>> +- remoteproc-internal-memory-mapped: a bool, indicates that the remote
>> + processor has internal memory that it uses to execute code and store
>> + data. Such a device is not expected to have a MMU. If no type property
>> + is provided, the device is assumed to map to such a model.
>
> Perhaps you could also specific a fallback compatible string so that
> it is possible to have both that and the specific string. Then it is
> easy to see what type this device is.
That assumes a standard compatible is available for all devices -> but
with remoteproc devices, we cannot really do that, correct?.
>
> Also does this correspond to any existing device tree binding in (e.g.) Linux?
As of v4.2-rc8, only binding we have in upstream kernel is
Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
which is not really helpful here.
>> diff --git a/doc/driver-model/remoteproc-framework.txt
>> b/doc/driver-model/remoteproc-framework.txt
>> new file mode 100644
>> index ..32cb40242e62
>> --- /dev/null
>> +++ b/doc/driver-model/remoteproc-framework.txt
>> @@ -0,0 +1,163 @@
>> +#
>> +# (C) Copyright 2015
>> +# Texas Instruments Incorporated - http://www.ti.com/
>> +# SPDX-License-Identifier: GPL-2.0+
>> +#
>> +
>> +Remote Processor Framework
>> +==
>> +TOC:
>> +1. Introduction
>> +2. How does it work - The driver
>> +3. Describing the device using platform data
>> +4. Describing the device using device tree
>> +
>> +1. Introduction
>> +===
>> +
>> +This is an introduction to driver-model for Remote Processors found
>> +on various System on Chip(SoCs). The term remote processor is used to
>> +indicate that this is not the processor on which u-boot is operating
>
> U-Boot
thanks.
[...]
>> index 092bc02b304e..24bd51269602 100644
>> --- a/drivers/Kconfig
>> +++ b/drivers/Kconfig
>> @@ -60,6 +60,8 @@ source "drivers/crypto/Kconfig"
>>
>> source "drivers/thermal/Kconfig"
>>
>> +source "drivers/remoteproc/Kconfig"
>
> Please sort these, so remoteproc should go up above thermal.
will do, thanks.
[..]
>> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
>> new file mode 100644
>> index ..700f52caf1dc
>> --- /dev/null
>> +++ b/drivers/remoteproc/Kconfig
>> @@ -0,0 +1,15 @@
>> +#
>> +# (C) Copyright 2015
>> +# Texas Instruments Incorporated - http://www.ti.com/
>> +# SPDX-License-Identifier: GPL-2.0+
>> +#
>> +
>> +menu "Remote Processor drivers"
>> +
>> +# DM_REMOTEPROC gets selected by drivers as needed
>> +# All users should depend on DM
>> +config DM_REMOTEPROC
>
> Can we use USE REMOTEPROC? The DM_ prefix indicates that driver model
> is an optional feature for that subsystem, and when everything is
> converted we intend to remove all the DM_ options.
Aaaah... thanks for clarifying.. I had gotten confused on the naming.. i
had
Re: [U-Boot] [PATCH v2 1/1] lib/display_options: Fix print_freq
On Tue, Aug 25, 2015 at 12:59 AM, Suriyan Ramasami wrote: > Build without CONFIG_SPL_SERIAL_SUPPORT does not print the cpu freq. > Booting an odroid U3 board, one sees this: > CPU: Exynos4412 @ GHz > instead of: > CPU: Exynos4412 @ 1 GHz > > This change was done to get rid of compiler warnings related to the > unused variable 'n' when CONFIG_SPL_SERIAL_SUPPORT is not defined in an > SPL build. Example board: smartweb > > Signed-off-by: Suriyan Ramasami Reviewed-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] sandbox: Introduce dummy remoteproc nodes
On 08/25/2015 12:04 AM, Simon Glass wrote:
> Hi Nishanth,
>
> On 24 August 2015 at 11:28, Nishanth Menon wrote:
>> Introduce dummy devices for sandbox remoteproc device and enable it by
>> default
>>
>> Signed-off-by: Nishanth Menon
>> ---
>> arch/sandbox/dts/test.dts | 13 +
>> configs/sandbox_defconfig | 2 ++
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
>> index c948df8c864b..df9b71310dbe 100644
>> --- a/arch/sandbox/dts/test.dts
>> +++ b/arch/sandbox/dts/test.dts
>> @@ -25,6 +25,8 @@
>> usb0 = &usb_0;
>> usb1 = &usb_1;
>> usb2 = &usb_2;
>> + remoteproc1 = &rproc_1;
>> + remoteproc2 = &rproc_2;
>
> Can you please put these in alpha order?
OK. will do.
>
>> };
>>
>> a-test {
>> @@ -296,6 +298,17 @@
>> status = "disabled";
>> };
>>
>> +
>> + rproc_1: rproc@1 {
>> + compatible = "sandbox,test-processor";
>> + remoteproc-name = "remoteproc-test-dev1";
>> + };
>> +
>> + rproc_2: rproc@2 {
>> + compatible = "sandbox,test-processor";
>> + internal-memory-mapped;
>> + remoteproc-name = "remoteproc-test-dev2";
>> + };
>
> And these should go after reset {} I think.
Ack.
>
>> };
>>
>> #include "sandbox_pmic.dtsi"
>> diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
>> index 874a26b572aa..4a2750c154bc 100644
>> --- a/configs/sandbox_defconfig
>> +++ b/configs/sandbox_defconfig
>> @@ -54,3 +54,5 @@ CONFIG_LED_GPIO=y
>> CONFIG_SYSCON=y
>> CONFIG_REGMAP=y
>> CONFIG_DEVRES=y
>> +CONFIG_DM_TESTPROC_SANDBOX=y
>
> CONFIG_TESTPROC_SANDBOX
Ack.
[...]
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] remoteproc: Introduce a sandbox dummy driver
On 08/25/2015 12:04 AM, Simon Glass wrote:
[...]
>> +# Please keep the configuration alphabetically sorted.
>> +config DM_TESTPROC_SANDBOX
>
> Should this be REMOTEPROC_SANDBOX?
Yep - will do.
>> diff --git a/drivers/remoteproc/sandbox_testproc.c
>> b/drivers/remoteproc/sandbox_testproc.c
>> new file mode 100644
>> index ..e942f66fc2dc
>> --- /dev/null
>> +++ b/drivers/remoteproc/sandbox_testproc.c
>> @@ -0,0 +1,243 @@
>> +/*
>> + * (C) Copyright 2015
>> + * Texas Instruments Incorporated - http://www.ti.com/
>> + * SPDX-License-Identifier:GPL-2.0+
>> + */
>> +#define pr_fmt(fmt) "%s: " fmt, __func__
^^
>> +#include
>> +#include
>> +#include
>> +#include
[...]
>> +
>> +static int sandbox_testproc_is_running(struct udevice *dev)
>> +{
>> + struct dm_rproc_uclass_pdata *uc_pdata;
>> + struct sandbox_test_devdata *ddata;
>> + int ret = 1;
>> +
>> + uc_pdata = dev_get_uclass_platdata(dev);
>> + ddata = dev_get_priv(dev);
>> +
>> + if (ddata->current_state == sb_running)
>> + ret = 0;
>> + debug("%s: called(%d)\n", uc_pdata->name, ret);
>
> should that say "is_running called" / do you need __func__?
pr_fmt (at the start of the file) should take care of it.
[...]
>> +U_BOOT_DRIVER(sandbox_testproc) = {
>> + /* *INDENT-OFF* */
>
> What is that for? ^^
trying to keep indent sane - will drop.
Thanks once again for the review.
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] drivers/sandbox: Introduce a simplified remoteproc framework
On 08/25/2015 12:04 AM, Simon Glass wrote: [...] > Can you please also add a test to test/dm/remoteproc.c? It should try > a few operations as a sanity check. Ideally it shouldn't output > anything on the console. OK. Will do. Thanks a ton for the detailed review. I will try and get everything done in day or so, hopefully. Thanks once again for all the work. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] expose eth_is_active() function to test network device state
Hi Bernhard, On Tue, Aug 25, 2015 at 4:53 AM, Bernhard Nortmann wrote: > Am 24.08.2015 um 19:02 schrieb Joe Hershberger: >> >> Hi Simon, >> >> On Mon, Aug 24, 2015 at 11:59 AM, Simon Glass wrote: >>> >>> Hi Bernhard, >>> >>> [...] >>> i.e. sunxi GMAC (by simply adding #define CONFIG_NETCONSOLE). >>> In that case how about adding that config to that board? Does it cause >>> problems for other people? >> >> I'll pile on and agree that it would be great to have at least one >> board with this enabled, and even better to have one that supports >> DM_ETH and one that does not. >> >> -Joe > > > grep "#define CONFIG_NETCONSOLE" include/configs/* > lists a considerable number of boards where NETCONSOLE seems to be active > by default. I guess none of these has moved to DM_ETH yet, or I'd have > expected reports of "broken" builds. > > If you're all for it, I can of course enable NETCONSOLE for the Banana > Pi/Pro. (It may even be done across-the-board for all SUNXI_[EG]MAC > configs?) Seems reasonable to me. > Personally, I'm a bit reluctant to "enforce" this setting, because until > now my understanding was that NETCONSOLE is supposed to be mostly > optional, i.e. at user's choice - especially for boards where other > means of input/output are readily available (serial console, vga, usb > keyboard). These are not resource constrained boards, right? > I don't expect this to create problems, it just adds code that probably > won't be used most of the time (as long as "nc" doesn't get used for > stdin/stdout). It's good to have a build target and also a test or so. We should maybe enable it in sandbox. > I guess the proper way to do it would be to introduce Kconfig support; > will this do? > > diff --git a/net/Kconfig b/net/Kconfig > index 915371d..87c1729 100644 > --- a/net/Kconfig > +++ b/net/Kconfig > @@ -16,4 +16,10 @@ config NET_RANDOM_ETHADDR > A new MAC address will be generated on every boot and it will > not be added to the environment. > > +config NETCONSOLE > + bool "Netconsole support" I'm pretty sure CamelCase is used in NetConsole. > + help > + Support the 'nc' input/output device for networked console. > + See README.NetConsole for details. > + > endif # if NET > > > In case this gets a "go", I'd prepare a v2 patch set that includes enabling > CONFIG_NETCONSOLE via Bananapi_defconfig / Bananapro_defconfig. I guess that will work (not running moveconfig.pl) with CONFIG_NETCONSOLE since so far most boards that don't define CONFIG_DM_ETH don't define CONFIG_NET or CONFIG_NETDEVICES so that CONFIG_NETCONSOLE option wouldn't be available. We'll have to change that for next release. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/BuR: simplify default IP-setup on B&R boards.
Hi Hannes,
On Tue, Aug 25, 2015 at 6:55 AM, Hannes Schmelzer wrote:
> To simplify and having a common default IP-setup on all B&R boards we
> introduce an environment variable "brdefaultip" which does following.
>
> Test if ${ipaddr} is empty, if yes it set's up some defaults:
> - ipaddr : 192.168.60.1
> - netmask : 255.255.255.0
> - gatewayip: 192.168.60.254
> - serverip : 192.168.60.254
>
> This environment is ran from CONFIG_PREBOOT.
>
> All other "tricks" are dropped.
>
> Signed-off-by: Hannes Schmelzer
Acked-by: Joe Hershberger
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: bootp fix vci string on SPL-Boot
Hi Hannes, On Tue, Aug 25, 2015 at 5:17 AM, Hannes Schmelzer wrote: > If CONFIG_CMD_DHCP is enabled, the vci (vendor-class-identifier) string > isn't inserted into the bootp-packet during SPL stage because the > > CONFIG_BOOTP_VCI_STRING > instead > CONFIG_SPL_NET_VCI_STRING > > We fix this with testing for CONFIG_SPL_BUILD and testing for existing > CONFIG_SPL_NET_VCI_STRING. > > Signed-off-by: Hannes Schmelzer Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] arm: tegra30: video: integrate display driver for t30
Hi Thierry,
On 25 August 2015 at 05:02, Thierry Reding wrote:
> On Mon, Aug 24, 2015 at 10:58:48AM -0600, Simon Glass wrote:
>> +Nikita
>>
>> Hi Thierry,
>>
>> On 24 August 2015 at 04:12, Thierry Reding wrote:
>> > On Fri, Aug 21, 2015 at 06:37:37PM -0600, Simon Glass wrote:
>> > [...]
>> >> I have serious doubts about the wisdom of requiring a contributor to
>> >> completely re-architect the existing display system in U-Boot. It's a
>> >> big job. Perhaps we can settle for following along the same lines and
>> >> not making things worse?
>> >
>> > I didn't suggest re-architecting the display system in U-Boot. What I
>> > was suggesting was a way to architect Tegra-specific display driver code
>> > to make it reusable rather than duplicate display controller programming
>> > for each new generation, while the hardware has remained mostly the
>> > same.
>>
>> OK, I misunderstood.
>>
>> >
>> >> > Perhaps something as simple as:
>> >> >
>> >> > struct tegra_dc {
>> >> > ...
>> >> > int (*enable)(struct tegra_dc *dc, const struct
>> >> > display_mode *mode);
>> >> > void (*disable)(struct tegra_dc *dc);
>> >> > ...
>> >> > };
>> >> >
>> >> > struct tegra_output {
>> >> > ...
>> >> > struct tegra_dc *dc;
>> >> > ...
>> >> > int (*enable)(struct tegra_output *output, const struct
>> >> > display_mode *mode);
>> >> > void (*disable)(struct tegra_output *output);
>> >> > ...
>> >> > };
>> >> >
>> >> > would work fine. That's roughly how drivers are implemented in the
>> >> > kernel. Setting up display on an output would be done by determining the
>> >> > mode (typically by parsing EDID if available, or using a hard-coded mode
>> >> > otherwise) and then calling:
>> >> >
>> >> > output->dc = dc;
>> >> > dc->enable(dc, mode);
>> >> > output->enable(output, mode);
>> >> >
>> >> > You might want to add in an abstraction for panels as well to make sure
>> >> > you have enough flexibility to enable and disable those, too. In that
>> >> > case you'd probably want to complement the above sequence with:
>> >> >
>> >> > panel->enable(panel);
>> >>
>> >> Please don't add function points to structures on an ad-hoc basis.
>> >> These should use driver model. There is a uclass for display port but
>> >> not for LCD panels or SOR. You could add a very simple one for a panel
>> >> if you like. Please take a look at tegra124's display driver for an
>> >> example.
>> >
>> > I don't think the driver model is a good fit here. Abstracting a display
>> > port isn't very useful in itself because users don't really care about
>> > the type of display, they only care about it being a display. So if you
>> > want to usefully abstract you'd do it at a higher level, such as display
>> > or screen. Then you have a generic object which users can use to put up
>> > a framebuffer onto a physical screen.
>>
>> I think you are referring to the lcd/video interface. If so, this is
>> already fairly well defined, but lcd and video should be merged, and a
>> uclass could be added. Nikita Kiryanov has done quite a bit of work on
>> the merging side.
>>
>> But I still think there is value in a low-level abstraction too.
>> Function pointers indicate that there is an interface that can be used
>> by multiple drivers, and that is what driver model is for. See
>> displayport.h for an attempt at this. We can of course consider
>> expanding the display port uclass to encompass panels in general. I
>> was reluctant to do that with a sample size of one. Here is the
>> current interface:
>>
>> /**
>> * display_port_read_edid() - Read information from EDID
>> *
>> * @dev:Device to read from
>> * @buf:Buffer to read into (should be EDID_SIZE bytes)
>> * @buf_size: Buffer size (should be EDID_SIZE)
>> * @return number of bytes read, <=0 for error
>> */
>> int display_port_read_edid(struct udevice *dev, u8 *buf, int buf_size);
>>
>> /**
>> * display_port_enable() - Enable a display port device
>> *
>> * @dev:Device to enable
>> * @panel_bpp: Number of bits per pixel for panel
>> * @timing: Display timings
>> * @return 0 if OK, -ve on error
>> */
>> int display_port_enable(struct udevice *dev, int panel_bpp,
>> const struct display_timing *timing);
>
> Both of these really aren't specific to DisplayPort. A DSI or HDMI input
> also wants to be enabled or have its EDID queried. Well, EDID may not be
> available on most DSI panels, so I think this particular abstraction
> should be slightly higher-level. What users are interested in isn't the
> EDID information, but the content therein. So I think a better way to
> return this type of information is by generating a list of modes (or a
> single one) given a display output device.
That sounds reasonable.
>
> And once you have
Re: [U-Boot] [PATCH] omap-common: SYS_BOOT fallback logic correction
On Tue, Aug 25, 2015 at 05:40:53PM +0200, Paul Kocialkowski wrote: > The SYS_BOOT-based fallback shouldn't only check for one of the conditions of > use and then let the switch/case handle each boot device without enforcing the > conditions for each type of boot device again. > > For instance, this behaviour would trigger the fallback for UART when > BOOT_DEVICE_UART is defined, CONFIG_SPL_YMODEM_SUPPORT is enabled (which > should > be a show-stopper) and e.g. BOOT_DEVICE_USB is enabled and not > CONFIG_SPL_USB_SUPPORT. > Separating the logic for USB and UART is a first step to solve this. > > In addition, a similar problematic behaviour took place when > BOOT_DEVICE_USBETH, > BOOT_DEVICE_USB and CONFIG_SPL_USBETH_SUPPORT were enabled and not > CONFIG_SPL_USB_SUPPORT. > > Since BOOT_DEVICE_USBETH is only a problem when it's defined to the same value > as BOOT_DEVICE_USB, we can check that BOOT_DEVICE_USBETH and BOOT_DEVICE_USB > are > different and if not, that CONFIG_SPL_USBETH_SUPPORT is not enabled to enable > the SYS_BOOT-based fallback mechanism. > > Signed-off-by: Paul Kocialkowski Reviewed-by: Tom Rini But I'm going to wait until Hannes can report back with a Tested-by too, 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/9] net: Revert "tftp: adjust settings to be suitable for 100Mbit ethernet"
Hi Bin, On Tue, Aug 25, 2015 at 4:26 AM, Bin Meng wrote: > Hi Joe, > > On Tue, Aug 25, 2015 at 3:22 PM, Bin Meng wrote: >> Testing either pch_gbe or e1000 driver via tftp command on Intel >> Crown Bay board, shows the following failure. >> >> TFTP error: 'Unsupported option(s) requested' (8) >> >> It turns out commit 620776d causes this. Revert this commit for now. > > Please check http://lists.denx.de/pipermail/u-boot/2015-August/225187.html > on why this commit should be reverted. > > Let me know if you have different thoughts (eg: I can respin a v2 to > explicitly mention in the commit message that commit 620776d is a spec > violation to RTC 2349 thus we need revert it) I agree we should revert it for this release. Please send a v2 that describes as much detail from the RFC as needed and references the RFC as well. We will revert it and figure out if there is a compliant way we can improve performance in a high-load situation. By pushing this to next release we will get much more testing and not risk losing compatibility in this release. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: protect status led access in bootp
Hi Thomas, On Tue, Aug 25, 2015 at 7:54 AM, Thomas Chou wrote: > This fixes the error when STATUS_LED_BOOT is not defined. > > Signed-off-by: Thomas Chou Acked-by: Joe Hershberger Don't forget to Cc: the maintainer of the area you are patching. Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] thermal: imx_thermal: rework driver to be reused
- Rework imx_thermal driver to be used across i.MX
processor that support thermal sensors
- Make read_cpu_temperature SoC dependent
Signed-off-by: Adrian Alonso
Signed-off-by: Peng Fan
---
arch/arm/cpu/armv7/mx6/soc.c | 86 +++-
arch/arm/imx-common/cpu.c | 13 ++--
arch/arm/include/asm/arch-mx6/sys_proto.h | 2 +
drivers/thermal/Makefile | 2 +-
drivers/thermal/imx_thermal.c | 106 --
include/configs/cgtqmx6eval.h | 4 +-
include/configs/embestmx6boards.h | 2 +-
include/configs/gw_ventana.h | 2 +-
include/configs/mx6cuboxi.h | 2 +-
include/configs/mx6sabre_common.h | 2 +-
include/configs/mx6slevk.h| 2 +-
include/configs/mx6sxsabresd.h| 2 +-
include/configs/mx6ul_14x14_evk.h | 2 +-
include/configs/tbs2910.h | 2 +-
include/imx_thermal.h | 26
15 files changed, 130 insertions(+), 125 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index 8ad8da8..68f4507 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
enum ldo_reg {
@@ -38,7 +39,7 @@ struct scu_regs {
u32 fpga_rev;
};
-#if defined(CONFIG_IMX6_THERMAL)
+#if defined(CONFIG_IMX_THERMAL)
static const struct imx_thermal_plat imx6_thermal_plat = {
.regs = (void *)ANATOP_BASE_ADDR,
.fuse_bank = 1,
@@ -171,6 +172,89 @@ u32 get_cpu_temp_grade(int *minc, int *maxc)
return val;
}
+int read_cpu_temperature(struct udevice *dev)
+{
+ int temperature;
+ unsigned int reg, n_meas;
+ const struct imx_thermal_plat *pdata = dev_get_platdata(dev);
+ struct anatop_regs *anatop = (struct anatop_regs *)pdata->regs;
+ struct thermal_data *priv = dev_get_priv(dev);
+ u32 fuse = priv->fuse;
+ int t1, n1;
+ u32 c1, c2;
+ u64 temp64;
+
+ /*
+* Sensor data layout:
+* [31:20] - sensor value @ 25C
+* We use universal formula now and only need sensor value @ 25C
+* slope = 0.4297157 - (0.0015976 * 25C fuse)
+*/
+ n1 = fuse >> 20;
+ t1 = 25; /* t1 always 25C */
+
+ /*
+* Derived from linear interpolation:
+* slope = 0.4297157 - (0.0015976 * 25C fuse)
+* slope = (FACTOR2 - FACTOR1 * n1) / FACTOR0
+* (Nmeas - n1) / (Tmeas - t1) = slope
+* We want to reduce this down to the minimum computation necessary
+* for each temperature read. Also, we want Tmeas in millicelsius
+* and we don't want to lose precision from integer division. So...
+* Tmeas = (Nmeas - n1) / slope + t1
+* milli_Tmeas = 1000 * (Nmeas - n1) / slope + 1000 * t1
+* milli_Tmeas = -1000 * (n1 - Nmeas) / slope + 1000 * t1
+* Let constant c1 = (-1000 / slope)
+* milli_Tmeas = (n1 - Nmeas) * c1 + 1000 * t1
+* Let constant c2 = n1 *c1 + 1000 * t1
+* milli_Tmeas = c2 - Nmeas * c1
+*/
+ temp64 = FACTOR0;
+ temp64 *= 1000;
+ do_div(temp64, FACTOR1 * n1 - FACTOR2);
+ c1 = temp64;
+ c2 = n1 * c1 + 1000 * t1;
+
+ /*
+* now we only use single measure, every time we read
+* the temperature, we will power on/down anadig thermal
+* module
+*/
+ writel(TEMPSENSE0_POWER_DOWN, &anatop->tempsense0_clr);
+ writel(MISC0_REFTOP_SELBIASOFF, &anatop->ana_misc0_set);
+
+ /* setup measure freq */
+ reg = readl(&anatop->tempsense1);
+ reg &= ~TEMPSENSE1_MEASURE_FREQ;
+ reg |= MEASURE_FREQ;
+ writel(reg, &anatop->tempsense1);
+
+ /* start the measurement process */
+ writel(TEMPSENSE0_MEASURE_TEMP, &anatop->tempsense0_clr);
+ writel(TEMPSENSE0_FINISHED, &anatop->tempsense0_clr);
+ writel(TEMPSENSE0_MEASURE_TEMP, &anatop->tempsense0_set);
+
+ /* make sure that the latest temp is valid */
+ while ((readl(&anatop->tempsense0) &
+ TEMPSENSE0_FINISHED) == 0)
+ udelay(1);
+
+ /* read temperature count */
+ reg = readl(&anatop->tempsense0);
+ n_meas = (reg & TEMPSENSE0_TEMP_CNT_MASK)
+ >> TEMPSENSE0_TEMP_CNT_SHIFT;
+ writel(TEMPSENSE0_FINISHED, &anatop->tempsense0_clr);
+
+ /* milli_Tmeas = c2 - Nmeas * c1 */
+ temperature = (long)(c2 - n_meas * c1)/1000;
+
+ /* power down anatop thermal sensor */
+ writel(TEMPSENSE0_POWER_DOWN, &anatop->tempsense0_set);
+ writel(MISC0_REFTOP_SELBIASOFF, &anatop->ana_misc0_clr);
+
+ return temperature;
+}
+
#ifdef CONFIG_REVISION_TAG
u32 __weak get_board_rev(void)
{
diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
index e27546c..a5efbd5 100644
--- a/arch/arm/imx-common/c
Re: [U-Boot] [PATCH v5 05/13] imx: mx7 dm thermal driver support
Hi Stefano,
> -Original Message-
> From: Stefano Babic [mailto:sba...@denx.de]
> Sent: Sunday, August 23, 2015 11:04 AM
> To: Alonso Lazcano Adrian-B38018 ; u-
> b...@lists.denx.de; sba...@denx.de; Estevam Fabio-R49496
>
> Cc: ota...@ossystems.com.br; Li Frank-B20596 ;
> Garg Nitin-B37173
> Subject: Re: [PATCH v5 05/13] imx: mx7 dm thermal driver support
>
> Hi Adrian,
>
> On 11/08/2015 18:19, Adrian Alonso wrote:
> > * Add thermal driver support for imx7 SoC
> > read_cpu_temperature is SoC dependent
> > * Redefine config macro to support imx7 and imx6 SoC
> >
> > Signed-off-by: Adrian Alonso
> > Signed-off-by: Peng Fan
> > ---
> > Changes for V2:
> > - Rework patch so it can be applyed on top of patch
> > imx6: standardise OCOTP and fuse config to mx6_common Changes for
> > V3: Resend Changes for V4: Resend Changes for V5: Resend
> >
> > arch/arm/imx-common/cpu.c | 10 ++--
> > drivers/thermal/Makefile | 2 +-
> > drivers/thermal/imx_thermal.c | 100
> +++---
> > include/configs/embestmx6boards.h | 2 +-
> > include/configs/gw_ventana.h | 2 +-
> > include/configs/mx6cuboxi.h | 2 +-
> > include/configs/mx6sabre_common.h | 2 +-
> > include/configs/mx6slevk.h| 2 +-
> > include/configs/mx6sxsabresd.h| 2 +-
> > include/configs/tbs2910.h | 2 +-
> > 10 files changed, 108 insertions(+), 18 deletions(-)
> >
>
> Agree changing the name to CONFIG_IMX_THERMAL.
>
> > diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
> > index e27546c..b0b75df 100644
> > --- a/arch/arm/imx-common/cpu.c
> > +++ b/arch/arm/imx-common/cpu.c
> > @@ -154,14 +154,16 @@ int print_cpuinfo(void)
> > u32 cpurev;
> > __maybe_unused u32 max_freq;
> >
> > -#if defined(CONFIG_MX6) && defined(CONFIG_IMX6_THERMAL)
> > +#if defined(CONFIG_IMX_THERMAL)
>
> > struct udevice *thermal_dev;
> > - int cpu_tmp, minc, maxc, ret;
> > + int cpu_tmp, ret;
> > #endif
> >
> > cpurev = get_cpu_rev();
> >
> > #if defined(CONFIG_MX6)
>
> > + int minc, maxc;
> > +
> > printf("CPU: Freescale i.MX%s rev%d.%d",
> >get_imx_type((cpurev & 0xFF000) >> 12),
> >(cpurev & 0x000F0) >> 4,
> > @@ -181,7 +183,7 @@ int print_cpuinfo(void)
> > mxc_get_clock(MXC_ARM_CLK) / 100); #endif
> >
> > -#if defined(CONFIG_MX6) && defined(CONFIG_IMX6_THERMAL)
> > +#if defined(CONFIG_MX6) && defined(CONFIG_IMX_THERMAL)
> > puts("CPU: ");
> > switch (get_cpu_temp_grade(&minc, &maxc)) {
> > case TEMP_AUTOMOTIVE:
> > @@ -198,6 +200,8 @@ int print_cpuinfo(void)
> > break;
> > }
> > printf("(%dC to %dC)", minc, maxc);
> > +#endif
> > +#if defined(CONFIG_IMX_THERMAL)
> > ret = uclass_get_device(UCLASS_THERMAL, 0, &thermal_dev);
> > if (!ret) {
> > ret = thermal_get_temp(thermal_dev, &cpu_tmp); diff --git
> > a/drivers/thermal/Makefile b/drivers/thermal/Makefile index
> > 6d4cacd..d768f5e 100644
> > --- a/drivers/thermal/Makefile
> > +++ b/drivers/thermal/Makefile
> > @@ -6,4 +6,4 @@
> > #
> >
> > obj-$(CONFIG_DM_THERMAL) += thermal-uclass.o
> > -obj-$(CONFIG_IMX6_THERMAL) += imx_thermal.o
> > +obj-$(CONFIG_IMX_THERMAL) += imx_thermal.o
> > diff --git a/drivers/thermal/imx_thermal.c
> > b/drivers/thermal/imx_thermal.c index 3c6c967..717f36e 100644
> > --- a/drivers/thermal/imx_thermal.c
> > +++ b/drivers/thermal/imx_thermal.c
> > @@ -19,6 +19,14 @@
> > #include
> > #include
> >
>
>
> Because this is a driver, and I guess that we can reuse it in future and newer
> SOCs will have always this feature, I will prefer to remove CPU related
> #ifdef
> (#ifdef CONFIG_MX6 and CONFIG_MX7).
>
> Use in this case (even if sometimes they are defined at compile time) the
> is_cpu_type() accessors, or one of the related functions. For example:
>
[Adrian] Please take a look at patch "thermal: imx_thermal: rework driver to be
reused"
Seems to me that with imx_thermal driver rework as proposed could lead to a
better
Reuse of existing thermal driver.
>
> > +struct thermal_data {
> > + unsigned int fuse;
> > + int critical;
> > + int minc;
> > + int maxc;
> > +};
> > +
> > +#if defined(CONFIG_MX6)
> > /* board will busyloop until this many degrees C below CPU max
> temperature */
> > #define TEMPERATURE_HOT_DELTA 5 /* CPU maxT - 5C */
> > #define FACTOR01000
> > @@ -34,13 +42,6 @@
> > #define MISC0_REFTOP_SELBIASOFF(1 << 3)
> > #define TEMPSENSE1_MEASURE_FREQ0x
> >
> > -struct thermal_data {
> > - unsigned int fuse;
> > - int critical;
> > - int minc;
> > - int maxc;
> > -};
> > -
> > static int read_cpu_temperature(struct udevice *dev) {
> > int temperature;
> > @@ -124,6 +125,79 @@ static int read_cpu_temperature(struct udevice
> *dev)
> > return temperature;
> > }
> >
> > +#elif defined(CONFIG_MX7)
>
> Here - defines are quite independent, footprint al
Re: [U-Boot] x86: EFI: boot fails at exit_boot_services - Was: Stuck trying to build a non-qemu EFI payload
Hi Igor, On 25 August 2015 at 07:18, Stoppa, Igor wrote: > Hi Simon, > thanks for helping, please find my reply below. > > On 21 August 2015 at 23:51, Simon Glass wrote: > >> Note that once you call exit_boot_services you will not be able to use >> the console. Be careful here - the board may appear to hang but >> actually it is broken by you trying to output to the console. > > Yes, I had realised it, but it seemed - on qemu - that it would still > work to call "putc", after the code: > >> map.version = version; >> map.desc_size = desc_size; >> add_entry_addr(priv, EFIET_MEMORY_MAP, &map, sizeof(map), desc, size); >> add_entry_addr(priv, EFIET_END, NULL, 0, 0, 0); > > But maybe I was just "lucky" and it worked even if it was not supposed to. > For example, maybe it was using memory pages that had already been freed. > > However, after your reply, I re-cloned the x86 branch, just to be sure > I would be starting from a clean slate, and re-did the configuration > from scratch, without adding any traces. > > The result is that stub reaches the call "jump_to_uboot", so it seems > that there are no problems there. > > The issues are to be found in the payload (as expected, since I'm > using the qemu defconfig). > > Trying the QEMU image on my Haswell test device, I see it rebooting. > > Since I do not have means to obtain a serial console (please see > footer note), I resorted to using a "while(1);" to identify the point > where the reboot happens, by turning the reboot into a hang. > > The location where the reboot is triggered is in: > > common/board_f.c: board_init_f_mem @ > 1048: memset(gd_ptr, '\0', sizeof(*gd)); > > I do not know the value of the pointer, but it seems that it is > incorrect and writing to this address causes a reset. You might be able to output it with printhex8() if not too early. This is supposed to be in cache-as-RAM space. See start.S where it calls that function. The FSP returns that value so I'm not sure what could be wrong. > > I wonder if this is because I'm still using the device tree for the > machine emulated by QEMU and if I should build one for my specific > Haswell NUC. > > Btw, the EFI bios offers the option of printing the EFI device tree. > Is it the same used by U-Boot, so that I could use this information to > create the Device Tree file? I don't think the device tree matters. Also we use the open firmware device tree (as Linux) - I thought EFI had its own thing? > > -- > thanks, igor Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] thermal: imx_thermal: rework driver to be reused
Hi Adrian,
On 25/08/2015 18:07, Adrian Alonso wrote:
> - Rework imx_thermal driver to be used across i.MX
> processor that support thermal sensors
ok
> - Make read_cpu_temperature SoC dependent
Agree on that, but why moving into the soc / cpu file ?
We have a driver for a specific hardware. The driver supports more as
one SOC. it is a common case. We have already such a cases, and the
driver must have code for both of them.
Take as example the SPI driver (on u-boot or Linux). It supports
multiple i.MXes without demanding code outside of the driver itself.
Aomething like:
read_cpu_temperature_mx6()
{
}
read_cpu_temperature_mx7()
{
}
int read_cpu_temperature(struct udevice *dev)
{
}
I think moving "read_cpu_temperature" is wrong because everybody expects
that all stuff related to the thermal is in the corresponding driver,
that is imx-thermal.
>
> Signed-off-by: Adrian Alonso
> Signed-off-by: Peng Fan
> ---
> arch/arm/cpu/armv7/mx6/soc.c | 86 +++-
> arch/arm/imx-common/cpu.c | 13 ++--
> arch/arm/include/asm/arch-mx6/sys_proto.h | 2 +
> drivers/thermal/Makefile | 2 +-
> drivers/thermal/imx_thermal.c | 106
> --
> include/configs/cgtqmx6eval.h | 4 +-
> include/configs/embestmx6boards.h | 2 +-
> include/configs/gw_ventana.h | 2 +-
> include/configs/mx6cuboxi.h | 2 +-
> include/configs/mx6sabre_common.h | 2 +-
> include/configs/mx6slevk.h| 2 +-
> include/configs/mx6sxsabresd.h| 2 +-
> include/configs/mx6ul_14x14_evk.h | 2 +-
> include/configs/tbs2910.h | 2 +-
> include/imx_thermal.h | 26
> 15 files changed, 130 insertions(+), 125 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
> index 8ad8da8..68f4507 100644
> --- a/arch/arm/cpu/armv7/mx6/soc.c
> +++ b/arch/arm/cpu/armv7/mx6/soc.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> enum ldo_reg {
> @@ -38,7 +39,7 @@ struct scu_regs {
> u32 fpga_rev;
> };
>
> -#if defined(CONFIG_IMX6_THERMAL)
> +#if defined(CONFIG_IMX_THERMAL)
> static const struct imx_thermal_plat imx6_thermal_plat = {
> .regs = (void *)ANATOP_BASE_ADDR,
> .fuse_bank = 1,
> @@ -171,6 +172,89 @@ u32 get_cpu_temp_grade(int *minc, int *maxc)
> return val;
> }
>
> +int read_cpu_temperature(struct udevice *dev)
> +{
> + int temperature;
> + unsigned int reg, n_meas;
> + const struct imx_thermal_plat *pdata = dev_get_platdata(dev);
> + struct anatop_regs *anatop = (struct anatop_regs *)pdata->regs;
> + struct thermal_data *priv = dev_get_priv(dev);
> + u32 fuse = priv->fuse;
> + int t1, n1;
> + u32 c1, c2;
> + u64 temp64;
> +
> + /*
> + * Sensor data layout:
> + * [31:20] - sensor value @ 25C
> + * We use universal formula now and only need sensor value @ 25C
> + * slope = 0.4297157 - (0.0015976 * 25C fuse)
> + */
> + n1 = fuse >> 20;
> + t1 = 25; /* t1 always 25C */
> +
> + /*
> + * Derived from linear interpolation:
> + * slope = 0.4297157 - (0.0015976 * 25C fuse)
> + * slope = (FACTOR2 - FACTOR1 * n1) / FACTOR0
> + * (Nmeas - n1) / (Tmeas - t1) = slope
> + * We want to reduce this down to the minimum computation necessary
> + * for each temperature read. Also, we want Tmeas in millicelsius
> + * and we don't want to lose precision from integer division. So...
> + * Tmeas = (Nmeas - n1) / slope + t1
> + * milli_Tmeas = 1000 * (Nmeas - n1) / slope + 1000 * t1
> + * milli_Tmeas = -1000 * (n1 - Nmeas) / slope + 1000 * t1
> + * Let constant c1 = (-1000 / slope)
> + * milli_Tmeas = (n1 - Nmeas) * c1 + 1000 * t1
> + * Let constant c2 = n1 *c1 + 1000 * t1
> + * milli_Tmeas = c2 - Nmeas * c1
> + */
> + temp64 = FACTOR0;
> + temp64 *= 1000;
> + do_div(temp64, FACTOR1 * n1 - FACTOR2);
> + c1 = temp64;
> + c2 = n1 * c1 + 1000 * t1;
> +
> + /*
> + * now we only use single measure, every time we read
> + * the temperature, we will power on/down anadig thermal
> + * module
> + */
> + writel(TEMPSENSE0_POWER_DOWN, &anatop->tempsense0_clr);
> + writel(MISC0_REFTOP_SELBIASOFF, &anatop->ana_misc0_set);
> +
> + /* setup measure freq */
> + reg = readl(&anatop->tempsense1);
> + reg &= ~TEMPSENSE1_MEASURE_FREQ;
> + reg |= MEASURE_FREQ;
> + writel(reg, &anatop->tempsense1);
> +
> + /* start the measurement process */
> + writel(TEMPSENSE0_MEASURE_TEMP, &anatop->tempsense0_clr);
> + writel(TEMPSENSE0_FINISHED, &anatop->tempsense0_clr);
> + writel(TEMPSENSE0_MEASURE_TEMP, &anatop->tempsense0_set);
> +
> + /* make sure that the latest temp is valid *
Re: [U-Boot] [PATCH] net: bootp fix vci string on SPL-Boot
On Tue, Aug 25, 2015 at 12:17:59PM +0200, Hannes Schmelzer wrote: > If CONFIG_CMD_DHCP is enabled, the vci (vendor-class-identifier) string > isn't inserted into the bootp-packet during SPL stage because the > > CONFIG_BOOTP_VCI_STRING > instead > CONFIG_SPL_NET_VCI_STRING > > We fix this with testing for CONFIG_SPL_BUILD and testing for existing > CONFIG_SPL_NET_VCI_STRING. > > Signed-off-by: Hannes Schmelzer > Reviewed-by: Tom Rini -- 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 2/9] net: e1000: Fix build warnings for 32-bit
On Tue, 2015-08-25 at 00:22 -0700, Bin Meng wrote: > commit 6497e37 "net: e1000: Support 64-bit physical address" causes > compiler warnings on 32-bit U-Boot build below. > > drivers/net/e1000.c: In function 'e1000_configure_tx': > drivers/net/e1000.c:4982:2: warning: right shift count >= width of type > [enabled by default] > drivers/net/e1000.c: In function 'e1000_configure_rx': > drivers/net/e1000.c:5126:2: warning: right shift count >= width of type > [enabled by default] > > This commit fixes the build warnings. > > Signed-off-by: Bin Meng > --- > > drivers/net/e1000.c | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c > index 6f74d30..a467280 100644 > --- a/drivers/net/e1000.c > +++ b/drivers/net/e1000.c > @@ -4977,9 +4977,10 @@ e1000_configure_tx(struct e1000_hw *hw) > unsigned long tctl; > unsigned long tipg, tarc; > uint32_t ipgr1, ipgr2; > + uint64_t tdba = (unsigned long)tx_base; > > - E1000_WRITE_REG(hw, TDBAL, (unsigned long)tx_base & 0x); > - E1000_WRITE_REG(hw, TDBAH, (unsigned long)tx_base >> 32); > + E1000_WRITE_REG(hw, TDBAL, (uint32_t)(tdba & 0x)); > + E1000_WRITE_REG(hw, TDBAH, (uint32_t)(tdba >> 32)); You could use upper_32_bits()/lower_32_bits(). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] expose eth_is_active() function to test network device state
Am 25.08.2015 um 17:55 schrieb Joe Hershberger: > Hi Bernhard, > > [...] > It's good to have a build target and also a test or so. We should > maybe enable it in sandbox. I'm not familiar at all with the U-Boot "sandbox" architecture, so I'd prefer to leave that to someone else. > I'm pretty sure CamelCase is used in NetConsole. Thanks, I'll fix that. > I guess that will work (not running moveconfig.pl) with > CONFIG_NETCONSOLE since so far most boards that don't define > CONFIG_DM_ETH don't define CONFIG_NET or CONFIG_NETDEVICES so that > CONFIG_NETCONSOLE option wouldn't be available. We'll have to change > that for next release. > > -Joe Yes, that Kconfig vs. "legacy" options battle is a bit of a problem. If it keeps things simpler for now, I could add "NETCONSOLE" to the respective CONFIG_SYS_EXTRA_OPTIONS as an alternative approach, and leave that Kconfig migration for the future. Which do you prefer? Regards, B. Nortmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 12/33] mkimage: Allow padding to any length
Hi Simon, On Mon, Aug 24, 2015 at 10:12 AM, Simon Glass wrote: > At present there is an arbitrary limit of 4KB for padding. Rockchip needs > more than that, so remove this restriction. > > Signed-off-by: Simon Glass Reviewed-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 13/33] mkimage: Allow the original file size to be recorded
Hi Simon, On Mon, Aug 24, 2015 at 10:12 AM, Simon Glass wrote: > Allow the image handler to store the original input file size so that it > can reference it later. > > Signed-off-by: Simon Glass Reviewed-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] expose eth_is_active() function to test network device state
Hi Bernhard, On Tue, Aug 25, 2015 at 1:01 PM, Bernhard Nortmann wrote: > Am 25.08.2015 um 17:55 schrieb Joe Hershberger: >> Hi Bernhard, >> >> [...] >> It's good to have a build target and also a test or so. We should >> maybe enable it in sandbox. > > I'm not familiar at all with the U-Boot "sandbox" architecture, so I'd > prefer > to leave that to someone else. > >> I'm pretty sure CamelCase is used in NetConsole. > > Thanks, I'll fix that. > >> I guess that will work (not running moveconfig.pl) with >> CONFIG_NETCONSOLE since so far most boards that don't define >> CONFIG_DM_ETH don't define CONFIG_NET or CONFIG_NETDEVICES so that >> CONFIG_NETCONSOLE option wouldn't be available. We'll have to change >> that for next release. >> >> -Joe > > Yes, that Kconfig vs. "legacy" options battle is a bit of a problem. If it > keeps things simpler for now, I could add "NETCONSOLE" to the respective > CONFIG_SYS_EXTRA_OPTIONS as an alternative approach, and leave that Kconfig > migration for the future. Which do you prefer? I think it will be better to take the approach you already are (add to Kconfig). Just make sure you use savedefconfig when you add the option to the bananapi defconfig. Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 27/33] rockchip: Add an MMC driver
Hi Simon,
On 24/08/15 16:12, Simon Glass wrote:
> Add an MMC driver which supports RK3288, but may also support other SoCs.
> It uses the Designware MMC device.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
> drivers/mmc/Kconfig| 9 +
> drivers/mmc/Makefile | 1 +
> drivers/mmc/rockchip_mmc.c | 98
> ++
> 3 files changed, 108 insertions(+)
> create mode 100644 drivers/mmc/rockchip_mmc.c
>
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 3e835f7..cd5f53c 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -10,6 +10,15 @@ config DM_MMC
> appear as block devices in U-Boot and can support filesystems such
> as EXT4 and FAT.
>
> +config ROCKCHIP_MMC
> + bool "Rockchip SD/MMC controller support"
> + depends on DM && OF_CONTROL
> + help
> + This enables support for the Rockchip SD/MMM controller, which is
> + based on Designware IP. The device is compatible with SD 3.0,
> + SDIO 3.0 and MMC 4.5 and supports common eMMC chips as well as
> + removeable SD and micro-SD cards.
> +
> config SH_SDHI
> bool "SuperH/Renesas ARM SoCs on-chip SDHI host controller support"
> depends on RMOBILE
> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
> index cae207c..7fd63de 100644
> --- a/drivers/mmc/Makefile
> +++ b/drivers/mmc/Makefile
> @@ -29,6 +29,7 @@ obj-$(CONFIG_MXS_MMC) += mxsmmc.o
> obj-$(CONFIG_OMAP_HSMMC) += omap_hsmmc.o
> obj-$(CONFIG_X86) += pci_mmc.o
> obj-$(CONFIG_PXA_MMC_GENERIC) += pxa_mmc_gen.o
> +obj-$(CONFIG_ROCKCHIP_MMC) += rockchip_mmc.o
> obj-$(CONFIG_SUPPORT_EMMC_RPMB) += rpmb.o
> obj-$(CONFIG_S3C_SDI) += s3c_sdi.o
> obj-$(CONFIG_S5P_SDHCI) += s5p_sdhci.o
> diff --git a/drivers/mmc/rockchip_mmc.c b/drivers/mmc/rockchip_mmc.c
> new file mode 100644
> index 000..430e7e5
> --- /dev/null
> +++ b/drivers/mmc/rockchip_mmc.c
> @@ -0,0 +1,98 @@
> +/*
> + * Copyright (c) 2013 Google, Inc
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +struct rockchip_mmc_priv {
> + struct udevice *clk;
> + struct rk3288_grf *grf;
> + struct dwmci_host host;
> +};
> +
> +static uint rockchip_mmc_get_mmc_clk(struct dwmci_host *host, uint freq)
> +{
> + struct udevice *dev = host->priv;
> + struct rockchip_mmc_priv *priv = dev_get_priv(dev);
> + int ret;
> +
> + ret = clk_set_periph_rate(priv->clk, PERIPH_ID_SDMMC0 + host->dev_index,
> + freq);
> + if (ret < 0) {
> + debug("%s: err=%d\n", __func__, ret);
> + return ret;
> + }
> +
> + return freq;
> +}
> +
> +static int rockchip_mmc_ofdata_to_platdata(struct udevice *dev)
> +{
> + struct rockchip_mmc_priv *priv = dev_get_priv(dev);
> + struct dwmci_host *host = &priv->host;
> +
> + host->name = dev->name;
> + host->ioaddr = (void *)dev_get_addr(dev);
> + host->buswidth = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
> + "bus-width", 4);
> + host->get_mmc_clk = rockchip_mmc_get_mmc_clk;
> + host->priv = dev;
> +
> + /* TODO(s...@chromium.org): Remove the need for this hack */
> + host->dev_index = (ulong)host->ioaddr == 0xff0f ? 0 : 1;
> +
> + return 0;
> +}
> +
> +int rockchip_mmc_probe(struct udevice *dev)
> +{
> + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> + struct rockchip_mmc_priv *priv = dev_get_priv(dev);
> + struct dwmci_host *host = &priv->host;
> + u32 minmax[2];
> + int ret;
> +
> + priv->grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
> + if (IS_ERR(priv->grf))
> + return PTR_ERR(priv->grf);
> + ret = uclass_get_device(UCLASS_CLK, CLK_GENERAL, &priv->clk);
> + if (ret)
> + return ret;
> +
> + ret = fdtdec_get_int_array(gd->fdt_blob, dev->of_offset,
> +"clock-freq-min-max", minmax, 2);
> + if (!ret)
> + ret = add_dwmci(host, minmax[1], minmax[0]);
> + if (ret)
> + return ret;
> +
> + upriv->mmc = host->mmc;
> +
> + return 0;
> +}
> +
> +static const struct udevice_id rockchip_mmc_ids[] = {
> + { .compatible = "rockchip,rk3288-dw-mshc" },
> + { }
> +};
> +
> +U_BOOT_DRIVER(rockchip_mmc_drv) = {
> + .name = "rockchip_mmc",
> + .id = UCLASS_MMC,
> + .of_match = rockchip_mmc_ids,
> + .ofdata_to_platdata = rockchip_mmc_ofdata_to_platdata,
> + .probe = rockchip_mmc_probe,
> + .priv_auto_alloc_size = sizeof(struct dwmci_host),
Shouldn't that be "sizeof(struct rockchip_mmc_priv)" here instead? (I
mentioned that already before, just not sure whether that mail got lost
or I was just t
Re: [U-Boot] [PATCH v2 06/28] tpm: Move the I2C TPM code into one file
Hi Simon, Le 25/08/2015 06:13, Simon Glass a écrit : Hi Christophe, On 24 August 2015 at 14:24, Christophe Ricard wrote: Hi Simon, I don't disagree with this patch (from patch 6 to patch 12). However, i believe it would be better to have this driver renamed tpm_i2c_infineon as shown in my previous patch: http://lists.denx.de/pipermail/u-boot/2015-August/223582.html Could you update this ? Yes, although I think this can be a separate patch. I was going to use yours... Then ok. This is fine for me :) Best Regards Christophe [snip] Best Regards Christophe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 20/28] tpm: Check that parse_byte_string() has data to parse
Hi Simon, Le 25/08/2015 06:13, Simon Glass a écrit : Hi Christophe, On 24 August 2015 at 14:22, Christophe Ricard wrote: Hi Simon, Print an error ? Are you sure ? I guess the comment is not accurate ;). Well returning NULL from parse_byte_string() will cause an error to be printed by the caller... This is just a comment nitpick. I think it is clear enough but from the patch the printing is may be not so obvious. It is just fine like that. Regards, Simon Best Regards Christophe Best Regards Christophe On 23/08/2015 02:31, Simon Glass wrote: Rather then crashing when there is no data, print an error. Acked-by: Christophe Ricard Signed-off-by: Simon Glass --- Changes in v2: None common/cmd_tpm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/common/cmd_tpm.c b/common/cmd_tpm.c index 65e7371..e9c6618 100644 --- a/common/cmd_tpm.c +++ b/common/cmd_tpm.c @@ -58,6 +58,8 @@ static void *parse_byte_string(char *bytes, uint8_t *data, size_t *count_ptr) size_t count, length; int i; + if (!bytes) + return NULL; length = strlen(bytes); count = length / 2; ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
