Re: [U-Boot] [PATCH v3] mmc: add bkops-enable command
Hi Jaehoon, On 11/28/2016 06:58 AM, Jaehoon Chung wrote: > > Applied on u-boot-mmc. > Before applied this patch from patchwork, i changed Author from your email to > your name, is it ok? > Thanks! Yes that is perfectly ok. BR, Tomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] net: dw: Add read_rom_hwaddr net_op hook
On 27-11-16 18:02, Simon Glass wrote: Hi, On 25 November 2016 at 08:38, Olliver Schinaglwrote: Add the read_rom_hwaddr net_op hook so that it can be called from boards to read the mac from a ROM chip. Signed-off-by: Olliver Schinagl --- drivers/net/designware.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers/net/designware.c b/drivers/net/designware.c index 9e6d726..3f2f67c 100644 --- a/drivers/net/designware.c +++ b/drivers/net/designware.c @@ -230,6 +230,21 @@ static int _dw_write_hwaddr(struct dw_eth_dev *priv, u8 *mac_id) return 0; } +__weak int dw_board_read_rom_hwaddr(unsigned char *enetaddr, int id) +{ + return -ENOSYS; +} + +static int designware_eth_read_rom_hwaddr(struct udevice *dev) +{ + struct eth_pdata *pdata = dev_get_platdata(dev); + + if (!dev) + return -ENOSYS; + + return dw_board_read_rom_hwaddr(pdata->enetaddr, dev->seq); +} + static void dw_adjust_link(struct eth_mac_regs *mac_p, struct phy_device *phydev) { @@ -685,6 +700,7 @@ static const struct eth_ops designware_eth_ops = { .free_pkt = designware_eth_free_pkt, .stop = designware_eth_stop, .write_hwaddr = designware_eth_write_hwaddr, + .read_rom_hwaddr= designware_eth_read_rom_hwaddr, }; static int designware_eth_ofdata_to_platdata(struct udevice *dev) You should not call board code from a driver. But since this is a sunxi driver, why not move all the code that reads the serial number into this file? Hey Simon, unless I missunderstand, this is how Joe suggested in a while ago, and how it has been implemented in a few other drivers. Can you elaborate a bit more? Olliver Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: zynq_gem: Return 0 on success, not -ENOSYS
On 28-11-16 08:22, Michal Simek wrote: On 25.11.2016 16:41, Olliver Schinagl wrote: The .read_rom_hwaddr net_ops hook does not check the return value, which is why it was never caught that we are currently returning 0 if the read_rom_hwaddr function return -ENOSYS and -ENOSYS otherwise. In this case we can simplify this by just returning the result of the function. Signed-off-by: Olliver Schinagl--- drivers/net/zynq_gem.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c index 8b7c1be..04a3fd4 100644 --- a/drivers/net/zynq_gem.c +++ b/drivers/net/zynq_gem.c @@ -593,14 +593,12 @@ __weak int zynq_board_read_rom_ethaddr(unsigned char *ethaddr) static int zynq_gem_read_rom_mac(struct udevice *dev) { - int retval; struct eth_pdata *pdata = dev_get_platdata(dev); - retval = zynq_board_read_rom_ethaddr(pdata->enetaddr); - if (retval == -ENOSYS) - retval = 0; + if (!dev) + return -ENOSYS; - return retval; + return zynq_board_read_rom_ethaddr(pdata->enetaddr); } static int zynq_gem_miiphy_read(struct mii_dev *bus, int addr, Not a problem with the patch above but I hope to get rid of this whole function by using MAC reading from eeprom. Yeah I agree, once the eeprom bit has matured, this could (in your case for your board) be dropped. Also board specific functions should return error value when read is not possible. As an unwritten rule you mean? I think the intention is that *_board_read_rom_hwaddr returns 0 on success < 0 on error. Acked-by: Michal Simek Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv4] Retrieve MAC address from EEPROM
On 28-11-16 10:13, Igor Grinberg wrote: Hi Olliver, On 11/25/16 17:30, Olliver Schinagl wrote: [...] The current idea of the eeprom layout, is to skip the first 8 bytes, so that other information can be stored there if needed, for example a header with some magic to identify the EEPROM. Or equivalent purposes. After those 8 bytes the MAC address follows the first macaddress. The macaddress is appended by a CRC8 byte and then padded to make for nice 8 bytes. Following the first macaddress one can store a second, or a third etc etc mac address. The CRC8 is optional (via a define) but is strongly recommended to have. It helps preventing user error and more importantly, checks if the bytes read are actually a user inserted address. E.g. only writing 1 macaddress into the eeprom but trying to consume 2. While reading the above, I'm wondering, have you considered the eeprom layout feature that we have in: common/eeprom/... ? Last year, when starting this patch series, this did not really exist in so far (iirc). The layout feature was actually designed for these tasks, but in a more generic way then just Ethernet MAC address. I did see it and I was quite excited. I think a follow up patch should switch over. I did not yet use the new eeprom layout thing as I am hoping for Maxime's patches to land first, where he makes the whole eeprom interfacing more generic. What do you think? I'll have to look at the eeprom layout feature a little more in depth, the one thing that was a little 'annoying' (from a short quick glance) was that the layout was jumping around a bit (eth0, eth1, something else, eth2, eth3). But yes, I was quite intrigued herein. Olliver ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/14] net: core: Using an ethernet address from ROM is not bad
On 28-11-16 08:59, Michal Simek wrote: On 25.11.2016 16:30, Olliver Schinagl wrote: Currently we print a warning if the MAC address is read from ROM/Hardware. This should not be concidered a bad or erronous thing. A MAC address should come either from the hardware (ROM) or may be set/overriden in the environment. Neither is a warning or error case. Worthy of a warning is the case where both are set, so the user is atleast aware something special is happening. Signed-off-by: Olliver Schinagl--- net/eth-uclass.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/net/eth-uclass.c b/net/eth-uclass.c index 9703bea..aca3f6d 100644 --- a/net/eth-uclass.c +++ b/net/eth-uclass.c @@ -510,8 +510,6 @@ static int eth_post_probe(struct udevice *dev) memcpy(pdata->enetaddr, env_enetaddr, ARP_HLEN); } else if (is_valid_ethaddr(pdata->enetaddr)) { eth_setenv_enetaddr_by_index("eth", dev->seq, pdata->enetaddr); - printf("\nWarning: %s using MAC address from ROM\n", - dev->name); } else if (is_zero_ethaddr(pdata->enetaddr)) { #ifdef CONFIG_NET_RANDOM_ETHADDR net_random_ethaddr(pdata->enetaddr); User should be aware if mac is read from ROM or something else. Is there a way how to read it without this message to be generated? I think what we need is a 'source' field here to be printed at the end. I do agree the user will want to know WHERE the address came from (and what it is). I do think the warning is misplaced here however. There's nothing to be warned against. I'll look into adding the feature that prints the source at the end (as detailed as we can). Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] tools/env: fix environment alignment tests for block devices
Hi Any news on this? The env utility is currently broken for block devices. Alternatively we could also revert commit 183923d3e412500bdc597d1745e2fb6f7f679ec7. Regards Max ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 0/3] spl: Add D-cache support
This series tries to add D-cache support in spl in order to reduce boot time either in 2stage boot or Falcon Boot. Lokesh Vutla (3): arch: arm: omap: Declare size of ddr very early spl: reorder the assignment of board info to global data spl: Add support for enabling dcache arch/arm/include/asm/cache.h| 1 + arch/arm/lib/cache-cp15.c | 46 + arch/arm/mach-omap2/am33xx/board.c | 4 arch/arm/mach-omap2/hwinit-common.c | 1 + arch/arm/mach-omap2/omap-cache.c| 15 common/spl/spl.c| 42 - 6 files changed, 98 insertions(+), 11 deletions(-) -- 2.10.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 1/3] arch: arm: omap: Declare size of ddr very early
Declare the size of ddr very early in spl, so that this can be used to enable cache. Signed-off-by: Lokesh Vutla--- arch/arm/mach-omap2/am33xx/board.c | 4 arch/arm/mach-omap2/hwinit-common.c | 1 + 2 files changed, 5 insertions(+) diff --git a/arch/arm/mach-omap2/am33xx/board.c b/arch/arm/mach-omap2/am33xx/board.c index 5ebeac0..7f445ae 100644 --- a/arch/arm/mach-omap2/am33xx/board.c +++ b/arch/arm/mach-omap2/am33xx/board.c @@ -303,6 +303,10 @@ void board_init_f(ulong dummy) early_system_init(); board_early_init_f(); sdram_init(); + /* dram_init must store complete ramsize in gd->ram_size */ + gd->ram_size = get_ram_size( + (void *)CONFIG_SYS_SDRAM_BASE, + CONFIG_MAX_RAM_BANK_SIZE); } #endif diff --git a/arch/arm/mach-omap2/hwinit-common.c b/arch/arm/mach-omap2/hwinit-common.c index f317293..cac3274 100644 --- a/arch/arm/mach-omap2/hwinit-common.c +++ b/arch/arm/mach-omap2/hwinit-common.c @@ -171,6 +171,7 @@ void board_init_f(ulong dummy) #endif /* For regular u-boot sdram_init() is called from dram_init() */ sdram_init(); + gd->ram_size = omap_sdram_size(); } #endif -- 2.10.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 3/3] spl: Add support for enabling dcache
Add support for enabling d-cache in SPL. The sequence in SPL tries to replicate the sequence done in U-Boot except that MMU entries were added for SRAM. Signed-off-by: Lokesh Vutla--- arch/arm/include/asm/cache.h | 1 + arch/arm/lib/cache-cp15.c| 46 +++- arch/arm/mach-omap2/omap-cache.c | 15 + common/spl/spl.c | 40 ++ 4 files changed, 92 insertions(+), 10 deletions(-) diff --git a/arch/arm/include/asm/cache.h b/arch/arm/include/asm/cache.h index 5400cbe..20f6aca 100644 --- a/arch/arm/include/asm/cache.h +++ b/arch/arm/include/asm/cache.h @@ -39,6 +39,7 @@ void arm_init_before_mmu(void); void arm_init_domains(void); void cpu_cache_initialization(void); void dram_bank_mmu_setup(int bank); +void sram_bank_mmu_setup(phys_addr_t start, phys_addr_t size); #endif diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c index e9bbcf5..76f95d6 100644 --- a/arch/arm/lib/cache-cp15.c +++ b/arch/arm/lib/cache-cp15.c @@ -94,16 +94,8 @@ void mmu_set_region_dcache_behaviour(phys_addr_t start, size_t size, mmu_page_table_flush(startpt, stoppt); } -__weak void dram_bank_mmu_setup(int bank) +static void set_section_caches(int i) { - bd_t *bd = gd->bd; - int i; - - debug("%s: bank: %d\n", __func__, bank); - for (i = bd->bi_dram[bank].start >> MMU_SECTION_SHIFT; -i < (bd->bi_dram[bank].start >> MMU_SECTION_SHIFT) + -(bd->bi_dram[bank].size >> MMU_SECTION_SHIFT); -i++) { #if defined(CONFIG_SYS_ARM_CACHE_WRITETHROUGH) set_section_dcache(i, DCACHE_WRITETHROUGH); #elif defined(CONFIG_SYS_ARM_CACHE_WRITEALLOC) @@ -111,9 +103,33 @@ __weak void dram_bank_mmu_setup(int bank) #else set_section_dcache(i, DCACHE_WRITEBACK); #endif - } } +__weak void dram_bank_mmu_setup(int bank) +{ + bd_t *bd = gd->bd; + int i; + + debug("%s: bank: %d\n", __func__, bank); + for (i = bd->bi_dram[bank].start >> MMU_SECTION_SHIFT; +i < (bd->bi_dram[bank].start >> MMU_SECTION_SHIFT) + +(bd->bi_dram[bank].size >> MMU_SECTION_SHIFT); i++) + set_section_caches(i); +} + +#if defined(CONFIG_SPL_BUILD) && (defined(CONFIG_SPL_MAX_SIZE) || \ + defined(CONFIG_SPL_MAX_FOOTPRINT)) +__weak void sram_bank_mmu_setup(phys_addr_t start, phys_addr_t size) +{ + int i; + + for (i = start >> MMU_SECTION_SHIFT; +i < (start >> MMU_SECTION_SHIFT) + (size >> MMU_SECTION_SHIFT); +i++) + set_section_caches(i); +} +#endif + /* to activate the MMU we need to set up virtual memory: use 1M areas */ static inline void mmu_setup(void) { @@ -129,6 +145,16 @@ static inline void mmu_setup(void) dram_bank_mmu_setup(i); } +#if defined(CONFIG_SPL_BUILD) +#if defined(CONFIG_SPL_MAX_SIZE) + sram_bank_mmu_setup(CONFIG_SPL_TEXT_BASE, + ALIGN(CONFIG_SPL_MAX_SIZE, MMU_SECTION_SIZE)); +#elif defined(CONFIG_SPL_MAX_FOOTPRINT) + sram_bank_mmu_setup(CONFIG_SPL_TEXT_BASE, + ALIGN(CONFIG_SPL_MAX_FOOTPRINT, MMU_SECTION_SIZE)); +#endif +#endif + #ifdef CONFIG_ARMV7_LPAE /* Set up 4 PTE entries pointing to our 4 1GB page tables */ for (i = 0; i < 4; i++) { diff --git a/arch/arm/mach-omap2/omap-cache.c b/arch/arm/mach-omap2/omap-cache.c index b37163a..6019e0c 100644 --- a/arch/arm/mach-omap2/omap-cache.c +++ b/arch/arm/mach-omap2/omap-cache.c @@ -62,6 +62,21 @@ void dram_bank_mmu_setup(int bank) set_section_dcache(i, ARMV7_DCACHE_POLICY); } +#ifdef CONFIG_SPL_BUILD +void sram_bank_mmu_setup(phys_addr_t start, phys_addr_t size) +{ + int i; + phys_addr_t end; + + start = start >> MMU_SECTION_SHIFT; + size = size >> MMU_SECTION_SHIFT; + end = start + size; + + for (i = start; i <= end; i++) + set_section_dcache(i, ARMV7_DCACHE_POLICY); +} +#endif + void arm_init_domains(void) { u32 reg; diff --git a/common/spl/spl.c b/common/spl/spl.c index 990b700..cdd2917 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -381,6 +381,34 @@ static int spl_load_image(struct spl_image_info *spl_image, u32 boot_device) return -ENODEV; } +#if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF)) && \ + defined(CONFIG_ARM) +static int reserve_mmu(void) +{ + phys_addr_t ram_top = 0; + /* reserve TLB table */ + gd->arch.tlb_size = PGTABLE_SIZE; + +#ifdef CONFIG_SYS_SDRAM_BASE + ram_top = CONFIG_SYS_SDRAM_BASE; +#endif + ram_top += get_effective_memsize(); + gd->arch.tlb_addr = ram_top - gd->arch.tlb_size; + debug("TLB table from %08lx to %08lx\n", gd->arch.tlb_addr, + gd->arch.tlb_addr + gd->arch.tlb_size); + return 0; +}
[U-Boot] [RFC PATCH 2/3] spl: reorder the assignment of board info to global data
Move the assignment of board info to global data a bit early which is safe, so that ram details can be used to enable caches. Signed-off-by: Lokesh Vutla--- common/spl/spl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/spl/spl.c b/common/spl/spl.c index bdb165a..990b700 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -394,6 +394,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2) int i; debug(">>spl:board_init_r()\n"); + gd->bd = #if defined(CONFIG_SYS_SPL_MALLOC_START) mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START, @@ -461,7 +462,6 @@ void board_init_r(gd_t *dummy1, ulong dummy2) */ void preloader_console_init(void) { - gd->bd = gd->baudrate = CONFIG_BAUDRATE; serial_init(); /* serial communications setup */ -- 2.10.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arch/arm/lib/Makefile: Allow CONFIG_USE_ARCH_MEMSET/MEMCPY with SPL
CONFIG_USE_ARCH_MEMSET/MEMCPY are inside a "SPL" check, which makes it impossible to use CONFIG_USE_ARCH_MEMSET combined with a SPL that calls memset. This patch moves that outside of the "if spl" block, allowing the code to be used inside SPL. One use case is that when using ECC on the Zynq platform, all the DDR RAM must be written to before it's read, otherwise the system will cause a bus error and hang. Without CONFIG_USE_ARCH_MEMSET it takes over 5 seconds to clear 256MB, enabling CONFIG_USE_ARCH_MEMSET reduces that time to less than 3 seconds. Signed-off-by: Mike Looijmans--- arch/arm/lib/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index 0051f76..eac6a5d 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -30,12 +30,12 @@ obj-$(CONFIG_CMD_BOOTI) += bootm.o obj-$(CONFIG_CMD_BOOTM) += bootm.o obj-$(CONFIG_CMD_BOOTZ) += bootm.o zimage.o obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o -obj-$(CONFIG_USE_ARCH_MEMSET) += memset.o -obj-$(CONFIG_USE_ARCH_MEMCPY) += memcpy.o else obj-$(CONFIG_SPL_FRAMEWORK) += spl.o obj-$(CONFIG_SPL_FRAMEWORK) += zimage.o endif +obj-$(CONFIG_USE_ARCH_MEMSET) += memset.o +obj-$(CONFIG_USE_ARCH_MEMCPY) += memcpy.o obj-$(CONFIG_SEMIHOSTING) += semihosting.o obj-y += sections.o -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd: usb: run 'usb start' when USB is stopped
On 11/28/2016 05:11 PM, Hans de Goede wrote: > Hi, > > On 28-11-16 07:54, Minkyu Kang wrote: >> Hi Jaehoon, >> >> On 28/11/16 14:08, Jaehoon Chung wrote: >>> Hi Marek, >>> >>> On 09/23/2016 01:15 PM, Simon Glass wrote: +Marek On 9 September 2016 at 04:20, Jaehoon Chungwrote: > If USB is stopped, just run 'usb start' instead of printing message. > Then user didn't consider whether usb is started or stopped. >>> >>> Do you have any other opinion for this? :) >>> >>> Best Regards, >>> Jaehoon Chung >>> > > Signed-off-by: Jaehoon Chung > --- > cmd/usb.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/cmd/usb.c b/cmd/usb.c > index 455127c..4970851 100644 > --- a/cmd/usb.c > +++ b/cmd/usb.c > @@ -651,8 +651,8 @@ static int do_usb(cmd_tbl_t *cmdtp, int flag, int > argc, char * const argv[]) > return 0; > } > if (!usb_started) { > - printf("USB is stopped. Please issue 'usb start' > first.\n"); > - return 1; > + printf("USB is stopped. Running 'usb start' first.\n"); > + do_usb_start(); > } >> >> It seems to ambiguous whether initialization was succeed or not. > > Right at a minimum it should detect that do_usb_start succeeds. E.g. > on an otg port without an otg -> usb-host cable plugged in it will not > succeed. Got it..Then discard this patch. Thanks for pointing out. Best Regards, Jaehoon Chung > > Regards, > > Hans > > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] env_sf: use DIV_ROUND_UP to calculate number of sectors to erase
simpler, needs less thinking when reading the code Signed-off-by: Andreas Fenkart--- common/env_sf.c | 18 +- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/common/env_sf.c b/common/env_sf.c index 8a3de63..0434bb8 100644 --- a/common/env_sf.c +++ b/common/env_sf.c @@ -79,7 +79,7 @@ int saveenv(void) { env_t env_new; char*saved_buffer = NULL, flag = OBSOLETE_FLAG; - u32 saved_size, saved_offset, sector = 1; + u32 saved_size, saved_offset, sector; int ret; ret = setup_flash_device(); @@ -114,11 +114,7 @@ int saveenv(void) goto done; } - if (CONFIG_ENV_SIZE > CONFIG_ENV_SECT_SIZE) { - sector = CONFIG_ENV_SIZE / CONFIG_ENV_SECT_SIZE; - if (CONFIG_ENV_SIZE % CONFIG_ENV_SECT_SIZE) - sector++; - } + sector = DIV_ROUND_UP(CONFIG_ENV_SIZE, CONFIG_ENV_SECT_SIZE); puts("Erasing SPI flash..."); ret = spi_flash_erase(env_flash, env_new_offset, @@ -244,7 +240,7 @@ out: #else int saveenv(void) { - u32 saved_size, saved_offset, sector = 1; + u32 saved_size, saved_offset, sector; char*saved_buffer = NULL; int ret = 1; env_t env_new; @@ -267,16 +263,12 @@ int saveenv(void) goto done; } - if (CONFIG_ENV_SIZE > CONFIG_ENV_SECT_SIZE) { - sector = CONFIG_ENV_SIZE / CONFIG_ENV_SECT_SIZE; - if (CONFIG_ENV_SIZE % CONFIG_ENV_SECT_SIZE) - sector++; - } - ret = env_export(_new); if (ret) goto done; + sector = DIV_ROUND_UP(CONFIG_ENV_SIZE, CONFIG_ENV_SECT_SIZE); + puts("Erasing SPI flash..."); ret = spi_flash_erase(env_flash, CONFIG_ENV_OFFSET, sector * CONFIG_ENV_SECT_SIZE); -- 2.10.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] enf_sf: reuse setup_flash_device instead of open coding it
setup_flash_device selects one of two code paths depending on the driver model being used (=CONFIG_DM_SPI_FLASH). env_relocate_spec only used the non driver-model code path. I'm unsure why, either none of the platforms that need relocation use the driver model, or - worse - the driver model is not yet usable when relocating. Signed-off-by: Andreas Fenkart--- common/env_sf.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/common/env_sf.c b/common/env_sf.c index 5126762..ba9ac8a 100644 --- a/common/env_sf.c +++ b/common/env_sf.c @@ -175,12 +175,9 @@ void env_relocate_spec(void) goto out; } - env_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS, CONFIG_ENV_SPI_CS, - CONFIG_ENV_SPI_MAX_HZ, CONFIG_ENV_SPI_MODE); - if (!env_flash) { - set_default_env("!spi_flash_probe() failed"); + ret = setup_flash_device(); + if (ret) goto out; - } ret = spi_flash_read(env_flash, CONFIG_ENV_OFFSET, CONFIG_ENV_SIZE, tmp_env1); @@ -315,10 +312,9 @@ void env_relocate_spec(void) char *buf = NULL; buf = (char *)memalign(ARCH_DMA_MINALIGN, CONFIG_ENV_SIZE); - env_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS, CONFIG_ENV_SPI_CS, - CONFIG_ENV_SPI_MAX_HZ, CONFIG_ENV_SPI_MODE); - if (!env_flash) { - set_default_env("!spi_flash_probe() failed"); + + ret = setup_flash_device(); + if (ret) { if (buf) free(buf); return; -- 2.10.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] env_sf: factor out prepare_flash_device
copy code found in single/double buffered code path Signed-off-by: Andreas Fenkart--- common/env_sf.c | 47 ++- 1 file changed, 18 insertions(+), 29 deletions(-) diff --git a/common/env_sf.c b/common/env_sf.c index c53200f..5126762 100644 --- a/common/env_sf.c +++ b/common/env_sf.c @@ -45,13 +45,8 @@ char *env_name_spec = "SPI Flash"; static struct spi_flash *env_flash; -#if defined(CONFIG_ENV_OFFSET_REDUND) -int saveenv(void) +static int setup_flash_device(void) { - env_t env_new; - char*saved_buffer = NULL, flag = OBSOLETE_FLAG; - u32 saved_size, saved_offset, sector = 1; - int ret; #ifdef CONFIG_DM_SPI_FLASH struct udevice *new; @@ -76,6 +71,20 @@ int saveenv(void) } } #endif + return 0; +} + +#if defined(CONFIG_ENV_OFFSET_REDUND) +int saveenv(void) +{ + env_t env_new; + char*saved_buffer = NULL, flag = OBSOLETE_FLAG; + u32 saved_size, saved_offset, sector = 1; + int ret; + + ret = setup_flash_device(); + if (ret) + return ret; ret = env_export(_new); if (ret) @@ -242,30 +251,10 @@ int saveenv(void) char*saved_buffer = NULL; int ret = 1; env_t env_new; -#ifdef CONFIG_DM_SPI_FLASH - struct udevice *new; - - /* speed and mode will be read from DT */ - ret = spi_flash_probe_bus_cs(CONFIG_ENV_SPI_BUS, CONFIG_ENV_SPI_CS, -0, 0, ); - if (ret) { - set_default_env("!spi_flash_probe_bus_cs() failed"); - return 1; - } - env_flash = dev_get_uclass_priv(new); -#else - - if (!env_flash) { - env_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS, - CONFIG_ENV_SPI_CS, - CONFIG_ENV_SPI_MAX_HZ, CONFIG_ENV_SPI_MODE); - if (!env_flash) { - set_default_env("!spi_flash_probe() failed"); - return 1; - } - } -#endif + ret = setup_flash_device(); + if (ret) + return ret; /* Is the sector larger than the env (i.e. embedded) */ if (CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE) { -- 2.10.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] env_sf: re-order error handling in single-buffer env_relocate_spec
this makes it easier comparable to the double-buffered version Signed-off-by: Andreas Fenkart--- common/env_sf.c | 20 +++- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/common/env_sf.c b/common/env_sf.c index ba9ac8a..8a3de63 100644 --- a/common/env_sf.c +++ b/common/env_sf.c @@ -312,29 +312,31 @@ void env_relocate_spec(void) char *buf = NULL; buf = (char *)memalign(ARCH_DMA_MINALIGN, CONFIG_ENV_SIZE); - - ret = setup_flash_device(); - if (ret) { - if (buf) - free(buf); + if (!buf) { + set_default_env("!malloc() failed"); return; } + ret = setup_flash_device(); + if (ret) + goto out; + ret = spi_flash_read(env_flash, CONFIG_ENV_OFFSET, CONFIG_ENV_SIZE, buf); if (ret) { set_default_env("!spi_flash_read() failed"); - goto out; + goto err_read; } ret = env_import(buf, 1); if (ret) gd->env_valid = 1; -out: + +err_read: spi_flash_free(env_flash); - if (buf) - free(buf); env_flash = NULL; +out: + free(buf); } #endif -- 2.10.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] env_sf: minor cleanup
Andreas Fenkart (4): env_sf: factor out prepare_flash_device enf_sf: reuse setup_flash_device instead of open coding it env_sf: re-order error handling in single-buffer env_relocate_spec env_sf: use DIV_ROUND_UP to calculate number of sectors to erase common/env_sf.c | 91 ++--- 1 file changed, 35 insertions(+), 56 deletions(-) -- 2.10.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: dts: am437x-idk: Fix QSPI compatible string
On Tuesday 22 November 2016 01:35 PM, Vignesh R wrote: > > > On Monday 21 November 2016 11:33 PM, Jagan Teki wrote: >> On Mon, Nov 21, 2016 at 10:07 AM, Vignesh Rwrote: >>> Hi Jagan, >>> >>> On Thursday 13 October 2016 06:24 PM, Tom Rini wrote: On Thu, Oct 13, 2016 at 05:45:52PM +0530, Jagan Teki wrote: > On Thu, Oct 13, 2016 at 3:53 PM, Vignesh R wrote: >> Unlike Linux kernel, U-Boot depends on "spi-flash" compatible to probe >> m25p80 spi-nor devices. Hence, add "spi-flash" compatible string to >> m25p80 node. Without this patch, flash device DT data is not parsed and >> QSPI operates in unsupported mode leading to data corruption. >> >> Signed-off-by: Vignesh R > > Applied to u-boot-spi/master ... I don't like that we need a non u-boot prefixed string here for the binding to work as that will lead to harder re-syncs later on the dt files. Why aren't we matching on the existing part? Thanks! >>> >>> I don't see this patch in u-boot master yet. If this patch was dropped >>> due to Tom's comment above, then could you suggest how to address the issue? >> >> Some how missed this, but do you still unable to probe the flash w/o >> "spi-flash"? I think there is a device_probe when !device_active(dev) >> that will detect the flash chip. Please try once. >> > > Yes, the flash is detected. But the device is not bound due to missing > "spi-flash" compatible and hence DT properties of flash node are not > available to the driver. So, the QSPI controller tries to operate in > mode 0 instead of mode 3 and default frequency instead of 48MHz as > specified by spi-max-frequency property leading to failure of flashing > operations. > In case its not clear from above explanation, this patch is still _needed_ in order for DT properties to be picked up. Without this QSPI write operations fail on am437x. Can this patch be picked up for this rc? -- Regards Vignesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] spi: cadence_qspi_apb: Use 32 bit indirect write transaction when possible
On Friday 25 November 2016 10:21 PM, Marek Vasut wrote: > On 11/24/2016 06:35 AM, Vignesh R wrote: >> According to Section 11.15.4.9.2 Indirect Write Controller of K2G SoC >> TRM SPRUHY8D[1], the external master is only permitted to issue 32-bit >> data interface writes until the last word of an indirect transfer >> otherwise indirect writes is known to fails sometimes. So, make sure >> that QSPI indirect writes are 32 bit sized except for the last write. If >> the txbuf is unaligned then use bounce buffer to avoid data aborts. >> >> So, now that the driver uses bounce_buffer, enable CONFIG_BOUNCE_BUFFER >> for all boards that use Cadence QSPI driver. >> >> [1]www.ti.com/lit/ug/spruhy8d/spruhy8d.pdf >> >> Signed-off-by: Vignesh R>> --- > > Reviewed-by: Marek Vasut > > I'd like to have at least Dinh's/Chin's ack on this. > > btw don't you need BB for READ as well ? > I don't see any issue with READ due to non word size accesses ATM, anyways I am working on patch to use BB for READ. Will post that separately. Thanks for the review! -- Regards Vignesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] spi: cadence_qspi_apb: Use 32 bit indirect write transaction when possible
On Friday 25 November 2016 11:18 PM, Jagan Teki wrote: >>> diff --git a/include/configs/k2g_evm.h b/include/configs/k2g_evm.h >>> index a14544526c71..1d603e0c002f 100644 >>> --- a/include/configs/k2g_evm.h >>> +++ b/include/configs/k2g_evm.h >>> @@ -79,6 +79,7 @@ >>> #define CONFIG_CADENCE_QSPI >>> #define CONFIG_CQSPI_REF_CLK 38400 >>> #define CONFIG_CQSPI_DECODER 0x0 >>> +#define CONFIG_BOUNCE_BUFFER >>> >> >>> >> Better define this on Kconfig and add it on defconfig. >> > >> > Such change is unrelated to this patch and should be fixed in a >> > separate/subsequent one. > Agreed it should be a separate patch. Yes, that should be separate series. There are a bunch of drivers and couple of architectures using CONFIG_BOUNCE_BUFFER, hence the change is not trivial. -- Regards Vignesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] tools/env: fix environment alignment tests for block devices
Hi Max, LGTM, see one nit below, can fixed later On 11/19/2016 01:58 PM, Max Krummenacher wrote: commit 183923d3e412500bdc597d1745e2fb6f7f679ec7 enforces that the environment must start at an erase block boundary. For block devices the sample fw_env.config does not mandate a erase block size for block devices. A missing setting defaults to the full env size. Depending on the environment location the alignment check now errors out for perfectly legal settings. Fix this by defaulting to the standard blocksize of 0x200 for environments stored in a block device. That keeps the fw_env.config files for block devices working even with that new check. Signed-off-by: Max Krummenacher--- Changes in v2: - move default value handling from parse_config(), get_config() to check_device_config(), so that !defined(CONFIG_FILE) is covered also. - use DIV_ROUND_UP instead of doing this manually - move the check after the setting of default values in check_device_config(). - use 0 as the marker for default values to be used. tools/env/fw_env.c | 60 ++ 1 file changed, 33 insertions(+), 27 deletions(-) diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c index 3dc0d53..862a0b1 100644 --- a/tools/env/fw_env.c +++ b/tools/env/fw_env.c @@ -1291,18 +1291,6 @@ static int check_device_config(int dev) struct stat st; int fd, rc = 0; - if (DEVOFFSET(dev) % DEVESIZE(dev) != 0) { - fprintf(stderr, "Environment does not start on (erase) block boundary\n"); - errno = EINVAL; - return -1; - } - - if (ENVSIZE(dev) > ENVSECTORS(dev) * DEVESIZE(dev)) { - fprintf(stderr, "Environment does not fit into available sectors\n"); - errno = EINVAL; - return -1; - } - fd = open(DEVNAME(dev), O_RDONLY); if (fd < 0) { fprintf(stderr, @@ -1335,9 +1323,15 @@ static int check_device_config(int dev) goto err; } DEVTYPE(dev) = mtdinfo.type; + if (DEVESIZE(dev) == 0) + /* Assume the erase size is the same as the env-size */ + DEVESIZE(dev) = ENVSIZE(dev); Since we already checked for character devices, we could use the mtdinfo.erasesize. I guess we can relay on mtdinfo on new kernels, and if not there is still the fallback to specify it in fw_env.config. } else { uint64_t size; DEVTYPE(dev) = MTD_ABSENT; + if (DEVESIZE(dev) == 0) + /* Assume the erase size to be 512 bytes */ + DEVESIZE(dev) = 0x200; It doesn't even matter. In case of MTD_ABSENT, erasize is never used itself, only the tuple (DEVESIZE * ENVSECTORS) matters. /* * Check for negative offsets, treat it as backwards offset @@ -1359,6 +1353,22 @@ static int check_device_config(int dev) } } + if (ENVSECTORS(dev) == 0) + /* Assume enough sectors to cover the environment */ + ENVSECTORS(dev) = DIV_ROUND_UP(ENVSIZE(dev), DEVESIZE(dev)); + + if (DEVOFFSET(dev) % DEVESIZE(dev) != 0) { + fprintf(stderr, "Environment does not start on (erase) block boundary\n"); + errno = EINVAL; + return -1; + } + + if (ENVSIZE(dev) > ENVSECTORS(dev) * DEVESIZE(dev)) { + fprintf(stderr, "Environment does not fit into available sectors\n"); + errno = EINVAL; + return -1; + } + err: close(fd); return rc; @@ -1382,10 +1392,10 @@ static int parse_config(struct env_opts *opts) DEVNAME (0) = DEVICE1_NAME; DEVOFFSET (0) = DEVICE1_OFFSET; ENVSIZE (0) = ENV1_SIZE; - /* Default values are: erase-size=env-size */ - DEVESIZE (0) = ENVSIZE (0); - /* #sectors=env-size/erase-size (rounded up) */ - ENVSECTORS (0) = (ENVSIZE(0) + DEVESIZE(0) - 1) / DEVESIZE(0); + + /* Set defaults for DEVESIZE, ENVSECTORS later once we +* know DEVTYPE +*/ #ifdef DEVICE1_ESIZE DEVESIZE (0) = DEVICE1_ESIZE; #endif @@ -1397,10 +1407,10 @@ static int parse_config(struct env_opts *opts) DEVNAME (1) = DEVICE2_NAME; DEVOFFSET (1) = DEVICE2_OFFSET; ENVSIZE (1) = ENV2_SIZE; - /* Default values are: erase-size=env-size */ - DEVESIZE (1) = ENVSIZE (1); - /* #sectors=env-size/erase-size (rounded up) */ - ENVSECTORS (1) = (ENVSIZE(1) + DEVESIZE(1) - 1) / DEVESIZE(1); + + /* Set defaults for DEVESIZE, ENVSECTORS later once we +* know DEVTYPE +*/ #ifdef DEVICE2_ESIZE DEVESIZE (1) = DEVICE2_ESIZE; #endif @@ -1466,13 +1476,9 @@ static int get_config (char *fname) DEVNAME(i) = devname; - if (rc < 4) - /*
Re: [U-Boot] [PATCH] ARM: dts: am437x-idk: Fix QSPI compatible string
On Mon, Nov 28, 2016 at 3:04 PM, Vignesh Rwrote: > > > On Tuesday 22 November 2016 01:35 PM, Vignesh R wrote: >> >> >> On Monday 21 November 2016 11:33 PM, Jagan Teki wrote: >>> On Mon, Nov 21, 2016 at 10:07 AM, Vignesh R wrote: Hi Jagan, On Thursday 13 October 2016 06:24 PM, Tom Rini wrote: > On Thu, Oct 13, 2016 at 05:45:52PM +0530, Jagan Teki wrote: >> On Thu, Oct 13, 2016 at 3:53 PM, Vignesh R wrote: >>> Unlike Linux kernel, U-Boot depends on "spi-flash" compatible to probe >>> m25p80 spi-nor devices. Hence, add "spi-flash" compatible string to >>> m25p80 node. Without this patch, flash device DT data is not parsed and >>> QSPI operates in unsupported mode leading to data corruption. >>> >>> Signed-off-by: Vignesh R >> >> Applied to u-boot-spi/master > > ... I don't like that we need a non u-boot prefixed string here for the > binding to work as that will lead to harder re-syncs later on the dt > files. Why aren't we matching on the existing part? Thanks! > I don't see this patch in u-boot master yet. If this patch was dropped due to Tom's comment above, then could you suggest how to address the issue? >>> >>> Some how missed this, but do you still unable to probe the flash w/o >>> "spi-flash"? I think there is a device_probe when !device_active(dev) >>> that will detect the flash chip. Please try once. >>> >> >> Yes, the flash is detected. But the device is not bound due to missing >> "spi-flash" compatible and hence DT properties of flash node are not >> available to the driver. So, the QSPI controller tries to operate in >> mode 0 instead of mode 3 and default frequency instead of 48MHz as >> specified by spi-max-frequency property leading to failure of flashing >> operations. >> > > In case its not clear from above explanation, this patch is still > _needed_ in order for DT properties to be picked up. Without this QSPI > write operations fail on am437x. Can this patch be picked up for this rc? Will pick. thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] imx: mx6sxsabreauto: enable more dm drivers
Enable MMC/I2C/GPIO/PMIC/REGULATOR/PCA953X DM drivers for mx6sxsabreauto board. Drop non-DM code. Note: The i.MX DM drivers has such dependency. MXC GPIO -> MXC I2C -> PFUZE/REGULATOR MXC GPIO -> PCA953X MXC GPIO -> FSL_USDHC So the drivers needs to be enabled all to avoid compiling error. The uboot dm tree log: => dm tree Class Probed Name root[ + ]root_driver thermal [ ]|-- imx_thermal simple_bus [ + ]|-- soc simple_bus [ + ]| |-- aips-bus@0200 simple_bus [ ]| | |-- spba-bus@0200 gpio[ + ]| | |-- gpio@0209c000 gpio[ + ]| | |-- gpio@020a gpio[ + ]| | |-- gpio@020a4000 gpio[ + ]| | |-- gpio@020a8000 gpio[ + ]| | |-- gpio@020ac000 gpio[ + ]| | |-- gpio@020b gpio[ + ]| | |-- gpio@020b4000 simple_bus [ ]| | |-- anatop@020c8000 simple_bus [ ]| | |-- snvs@020cc000 pinctrl [ + ]| | `-- iomuxc@020e pinconfig [ + ]| | `-- imx6x-sabreauto pinconfig [ + ]| | |-- i2c2grp-1 pinconfig [ + ]| | |-- i2c3grp-2 pinconfig [ ]| | |-- uart1grp pinconfig [ + ]| | |-- usdhc3grp pinconfig [ ]| | |-- usdhc3grp-100mhz pinconfig [ ]| | |-- usdhc3grp-200mhz pinconfig [ + ]| | |-- usdhc4grp pinconfig [ + ]| | `-- vccsd3grp simple_bus [ + ]| |-- aips-bus@0210 mmc [ + ]| | |-- usdhc@02198000 mmc [ + ]| | |-- usdhc@0219c000 i2c [ + ]| | |-- i2c@021a4000 i2c_generic [ + ]| | | |-- generic_8 i2c_generic [ + ]| | | `-- generic_4e i2c [ + ]| | `-- i2c@021a8000 gpio[ + ]| | |-- gpio@30 gpio[ + ]| | `-- gpio@32 simple_bus [ ]| `-- aips-bus@0220 simple_bus [ ]| `-- spba-bus@0220 simple_bus [ + ]`-- regulators regulator [ + ]`-- regulator@0 Signed-off-by: Peng FanCc: Stefano Babic --- board/freescale/mx6sxsabreauto/mx6sxsabreauto.c | 258 +--- configs/mx6sxsabreauto_defconfig| 13 ++ include/configs/mx6sxsabreauto.h| 7 - 3 files changed, 69 insertions(+), 209 deletions(-) diff --git a/board/freescale/mx6sxsabreauto/mx6sxsabreauto.c b/board/freescale/mx6sxsabreauto/mx6sxsabreauto.c index 44e6a7d..e7ab810 100644 --- a/board/freescale/mx6sxsabreauto/mx6sxsabreauto.c +++ b/board/freescale/mx6sxsabreauto/mx6sxsabreauto.c @@ -16,12 +16,9 @@ #include #include #include -#include #include #include #include -#include -#include #include #include #include @@ -37,15 +34,6 @@ DECLARE_GLOBAL_DATA_PTR; PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \ PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS) -#define USDHC_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE |\ - PAD_CTL_PUS_22K_UP | PAD_CTL_SPEED_LOW | \ - PAD_CTL_DSE_80ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS) - -#define I2C_PAD_CTRL(PAD_CTL_PKE | PAD_CTL_PUE |\ - PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \ - PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \ - PAD_CTL_ODE) - #define ENET_PAD_CTRL (PAD_CTL_PUS_100K_UP | PAD_CTL_PUE | \ PAD_CTL_SPEED_HIGH | \ PAD_CTL_DSE_48ohm | PAD_CTL_SRE_FAST) @@ -56,54 +44,11 @@ DECLARE_GLOBAL_DATA_PTR; #define ENET_RX_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \ PAD_CTL_SPEED_HIGH | PAD_CTL_SRE_FAST) -#define I2C_PMIC 1 - #define GPMI_PAD_CTRL0 (PAD_CTL_PKE | PAD_CTL_PUE | PAD_CTL_PUS_100K_UP) #define GPMI_PAD_CTRL1 (PAD_CTL_DSE_40ohm | PAD_CTL_SPEED_MED | \ PAD_CTL_SRE_FAST) #define GPMI_PAD_CTRL2 (GPMI_PAD_CTRL0 | GPMI_PAD_CTRL1) -/*Define for building port exp gpio, pin starts from 0*/ -#define PORTEXP_IO_NR(chip, pin) \ - ((chip << 5) + pin) - -/*Get the chip addr from a ioexp gpio*/ -#define PORTEXP_IO_TO_CHIP(gpio_nr) \ - (gpio_nr >> 5) - -/*Get the pin number from a ioexp gpio*/ -#define PORTEXP_IO_TO_PIN(gpio_nr) \ - (gpio_nr & 0x1f) - -#define CPU_PER_RST_B PORTEXP_IO_NR(0x30, 4) -#define STEER_ENET PORTEXP_IO_NR(0x32, 2) - -static int port_exp_direction_output(unsigned gpio, int value) -{ - int ret; - - i2c_set_bus_num(2); - ret = i2c_probe(PORTEXP_IO_TO_CHIP(gpio)); - if (ret) - return ret; - - ret = pca953x_set_dir(PORTEXP_IO_TO_CHIP(gpio), - (1 << PORTEXP_IO_TO_PIN(gpio)), - (PCA953X_DIR_OUT << PORTEXP_IO_TO_PIN(gpio))); - - if (ret)
Re: [U-Boot] [PATCH 06/14] net: core: Using an ethernet address from ROM is not bad
On November 28, 2016 12:06:37 PM CET, Michal Simekwrote: >On 28.11.2016 11:48, Olliver Schinagl wrote: >> On 28-11-16 08:59, Michal Simek wrote: >>> On 25.11.2016 16:30, Olliver Schinagl wrote: Currently we print a warning if the MAC address is read from ROM/Hardware. This should not be concidered a bad or erronous >thing. A MAC address should come either from the hardware (ROM) or may be set/overriden in the environment. Neither is a warning or error >case. Worthy of a warning is the case where both are set, so the user is atleast aware something special is happening. Signed-off-by: Olliver Schinagl --- net/eth-uclass.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/net/eth-uclass.c b/net/eth-uclass.c index 9703bea..aca3f6d 100644 --- a/net/eth-uclass.c +++ b/net/eth-uclass.c @@ -510,8 +510,6 @@ static int eth_post_probe(struct udevice *dev) memcpy(pdata->enetaddr, env_enetaddr, ARP_HLEN); } else if (is_valid_ethaddr(pdata->enetaddr)) { eth_setenv_enetaddr_by_index("eth", dev->seq, pdata->enetaddr); -printf("\nWarning: %s using MAC address from ROM\n", - dev->name); } else if (is_zero_ethaddr(pdata->enetaddr)) { #ifdef CONFIG_NET_RANDOM_ETHADDR net_random_ethaddr(pdata->enetaddr); >>> User should be aware if mac is read from ROM or something else. >>> Is there a way how to read it without this message to be generated? >> I think what we need is a 'source' field here to be printed at the >end. >> I do agree the user will want to know WHERE the address came from >(and >> what it is). I do think the warning is misplaced here however. >There's >> nothing to be warned against. >> >> I'll look into adding the feature that prints the source at the end >(as >> detailed as we can). > >Maybe enough here to remove that Warning from print message. Well a later patch in this series does print it per interface. Hence why my suggestion to add the source/from. Olliver > >Thanks, >Michal -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/14] net: core: Using an ethernet address from ROM is not bad
On 28.11.2016 12:08, Olliver Schinagl wrote: > > > On November 28, 2016 12:06:37 PM CET, Michal Simek> wrote: >> On 28.11.2016 11:48, Olliver Schinagl wrote: >>> On 28-11-16 08:59, Michal Simek wrote: On 25.11.2016 16:30, Olliver Schinagl wrote: > Currently we print a warning if the MAC address is read from > ROM/Hardware. This should not be concidered a bad or erronous >> thing. A > MAC address should come either from the hardware (ROM) or may be > set/overriden in the environment. Neither is a warning or error >> case. > > Worthy of a warning is the case where both are set, so the user is > atleast aware something special is happening. > > Signed-off-by: Olliver Schinagl > --- > net/eth-uclass.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/net/eth-uclass.c b/net/eth-uclass.c > index 9703bea..aca3f6d 100644 > --- a/net/eth-uclass.c > +++ b/net/eth-uclass.c > @@ -510,8 +510,6 @@ static int eth_post_probe(struct udevice *dev) > memcpy(pdata->enetaddr, env_enetaddr, ARP_HLEN); > } else if (is_valid_ethaddr(pdata->enetaddr)) { > eth_setenv_enetaddr_by_index("eth", dev->seq, > pdata->enetaddr); > -printf("\nWarning: %s using MAC address from ROM\n", > - dev->name); > } else if (is_zero_ethaddr(pdata->enetaddr)) { > #ifdef CONFIG_NET_RANDOM_ETHADDR > net_random_ethaddr(pdata->enetaddr); > User should be aware if mac is read from ROM or something else. Is there a way how to read it without this message to be generated? >>> I think what we need is a 'source' field here to be printed at the >> end. >>> I do agree the user will want to know WHERE the address came from >> (and >>> what it is). I do think the warning is misplaced here however. >> There's >>> nothing to be warned against. >>> >>> I'll look into adding the feature that prints the source at the end >> (as >>> detailed as we can). >> >> Maybe enough here to remove that Warning from print message. > Well a later patch in this series does print it per interface. > > Hence why my suggestion to add the source/from. Definitely nice prints and if you add source/from part I will be happy with it. Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot