[U-Boot] [PATCH] sunxi: Allow booting from 128KB SD/eMMC offset
On modern Allwinner SoCs (tested: H2+, A64, H5, H6) the BootROM can
actually load the SPL also from sector 256 (128KB) of an SD card or eMMC
chip. For more details, see [1].
In this case the boot source indicator (written at offset 0x28 of SRAM A1)
has bit 4 set, so it's 0x10 for SD card and 0x12 for eMMC.
Add those new values to the existing boot source check to allow booting
the SPL from those "high" disk offsets as well. For this to work, the
value of CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR needs to be adjusted,
for instance to 0x140 (right after the high SPL). Doing this dynamically
sounds desirable, but looks nasty to implement.
[1] https://groups.google.com/forum/#!topic/linux-sunxi/MaiijyaAFjk
Signed-off-by: Andre Przywara
---
arch/arm/include/asm/arch-sunxi/spl.h | 2 ++
arch/arm/mach-sunxi/board.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/arm/include/asm/arch-sunxi/spl.h
b/arch/arm/include/asm/arch-sunxi/spl.h
index 4baba38b00..8c916e8c75 100644
--- a/arch/arm/include/asm/arch-sunxi/spl.h
+++ b/arch/arm/include/asm/arch-sunxi/spl.h
@@ -28,6 +28,8 @@
#define SUNXI_BOOTED_FROM_NAND 1
#define SUNXI_BOOTED_FROM_MMC2 2
#define SUNXI_BOOTED_FROM_SPI 3
+#define SUNXI_BOOTED_FROM_MMC0_HIGH0x10
+#define SUNXI_BOOTED_FROM_MMC2_HIGH0x12
/* boot head definition from sun4i boot code */
struct boot_file_head {
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index b74eaf2a0e..c6dd7b8e54 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -240,10 +240,12 @@ uint32_t sunxi_get_boot_device(void)
boot_source = readb(SPL_ADDR + 0x28);
switch (boot_source) {
case SUNXI_BOOTED_FROM_MMC0:
+ case SUNXI_BOOTED_FROM_MMC0_HIGH:
return BOOT_DEVICE_MMC1;
case SUNXI_BOOTED_FROM_NAND:
return BOOT_DEVICE_NAND;
case SUNXI_BOOTED_FROM_MMC2:
+ case SUNXI_BOOTED_FROM_MMC2_HIGH:
return BOOT_DEVICE_MMC2;
case SUNXI_BOOTED_FROM_SPI:
return BOOT_DEVICE_SPI;
--
2.14.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] U-Boot 2019.01-rc1-00337-g42cc2cf partition table issues on imx6
Hi,
I'm having problems with my bootscript which works on 2018.03 but is having
problems on latest master. I need to run `mmc part` to get it working.
U-Boot 2019.01-rc1-00337-g42cc2cf (Dec 16 2018 - 01:02:22 +0100)
Model: Toradex Apalis iMX6 Quad 2GB IT V1.1A, Serial# 04875944
# mmc dev 0
switch to partitions #0, OK
mmc0(part 0) is current device
# load mmc 0:1 ${loadaddr} ${script}
** No partition table - mmc 0 **
# mmc part
Partition Map for MMC device 0 -- Partition Type: DOS
PartStart SectorNum Sectors UUIDType
1 204832768 5452574f-01 83 Boot
2 36864 524288 5452574f-02 83a
# load mmc 0:1 ${loadaddr} ${script}
641 bytes read in 26 ms (23.4 KiB/s)
Same problem with `ext4ls`:
# mmc dev 0
switch to partitions #0, OK
mmc0(part 0) is current device
# ext4ls mmc 0:1
** No partition table - mmc 0 **
# mmc part
Partition Map for MMC device 0 -- Partition Type: DOS
PartStart SectorNum Sectors UUIDType
1 204832768 5452574f-01 83 Boot
2 36864 524288 5452574f-02 83
# ext4ls mmc 0:1
4096 .
4096 ..
4096 lost+found
641 boot.scr
47312 imx6q-apalis-ixora.dtb
2521736 uImage
-- ynezz
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: efi_guid_t must be 64-bit aligned
The UEFI Specification Version 2.7 Errata A defines:
"EFI_GUID
128-bit buffer containing a unique identifier value.
Unless otherwise specified, aligned on a 64-bit boundary."
Before this patch efi_guid_t was 8-bit aligned.
Signed-off-by: Heinrich Schuchardt
---
include/efi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/efi.h b/include/efi.h
index b5e2c64f38b..3018c61b373 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -49,7 +49,7 @@ struct efi_device_path;
typedef struct {
u8 b[16];
-} efi_guid_t;
+} efi_guid_t __attribute__ ((aligned (8)));
#define EFI_BITS_PER_LONG (sizeof(long) * 8)
--
2.19.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v2 2/6] efi_loader: Initial HII database protocols
On 12/14/18 11:10 AM, AKASHI Takahiro wrote:
> From: Leif Lindholm
>
> This patch provides enough implementation of the following protocols to
> run EDKII's Shell.efi and UEFI SCT:
>
> * EfiHiiDatabaseProtocol
> * EfiHiiStringProtocol
>
> Not implemented are:
> * ExportPackageLists()
> * RegisterPackageNotify()/UnregisterPackageNotify()
> * SetKeyboardLayout() (i.e. *current* keyboard layout)
>
> HII database protocol can handle only:
> * GUID package
> * string package
> * keyboard layout package
> (The other packages, except Device path package, will be necessary
>for interactive and graphical UI.)
>
> We'll fill in the rest once SCT is running properly so we can validate
> the implementation against the conformance test suite.
>
> Cc: Leif Lindholm
> Signed-off-by: Rob Clark
> Signed-off-by: AKASHI Takahiro
> ---
> include/efi_api.h | 242 ++
> include/efi_loader.h | 4 +
> lib/efi_loader/Makefile | 1 +
> lib/efi_loader/efi_boottime.c | 12 +
> lib/efi_loader/efi_hii.c | 886 ++
> 5 files changed, 1145 insertions(+)
> create mode 100644 lib/efi_loader/efi_hii.c
>
> diff --git a/include/efi_api.h b/include/efi_api.h
> index aef77b6319de..c9dbd5a6037d 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -17,6 +17,7 @@
> #define _EFI_API_H
>
> #include
> +#include
>
> #ifdef CONFIG_EFI_LOADER
> #include
> @@ -697,6 +698,247 @@ struct efi_device_path_utilities_protocol {
> uint16_t node_length);
> };
>
> +typedef u16 efi_string_id_t;
> +
> +#define EFI_HII_DATABASE_PROTOCOL_GUID\
> + EFI_GUID(0xef9fc172, 0xa1b2, 0x4693, \
> + 0xb3, 0x27, 0x6d, 0x32, 0xfc, 0x41, 0x60, 0x42)
> +
> +typedef enum {
> + EFI_KEY_LCTRL, EFI_KEY_A0, EFI_KEY_LALT, EFI_KEY_SPACE_BAR,
> + EFI_KEY_A2, EFI_KEY_A3, EFI_KEY_A4, EFI_KEY_RCTRL, EFI_KEY_LEFT_ARROW,
> + EFI_KEY_DOWN_ARROW, EFI_KEY_RIGHT_ARROW, EFI_KEY_ZERO,
> + EFI_KEY_PERIOD, EFI_KEY_ENTER, EFI_KEY_LSHIFT, EFI_KEY_B0,
> + EFI_KEY_B1, EFI_KEY_B2, EFI_KEY_B3, EFI_KEY_B4, EFI_KEY_B5, EFI_KEY_B6,
> + EFI_KEY_B7, EFI_KEY_B8, EFI_KEY_B9, EFI_KEY_B10, EFI_KEY_RSHIFT,
> + EFI_KEY_UP_ARROW, EFI_KEY_ONE, EFI_KEY_TWO, EFI_KEY_THREE,
> + EFI_KEY_CAPS_LOCK, EFI_KEY_C1, EFI_KEY_C2, EFI_KEY_C3, EFI_KEY_C4,
> + EFI_KEY_C5, EFI_KEY_C6, EFI_KEY_C7, EFI_KEY_C8, EFI_KEY_C9,
> + EFI_KEY_C10, EFI_KEY_C11, EFI_KEY_C12, EFI_KEY_FOUR, EFI_KEY_FIVE,
> + EFI_KEY_SIX, EFI_KEY_PLUS, EFI_KEY_TAB, EFI_KEY_D1, EFI_KEY_D2,
> + EFI_KEY_D3, EFI_KEY_D4, EFI_KEY_D5, EFI_KEY_D6, EFI_KEY_D7, EFI_KEY_D8,
> + EFI_KEY_D9, EFI_KEY_D10, EFI_KEY_D11, EFI_KEY_D12, EFI_KEY_D13,
> + EFI_KEY_DEL, EFI_KEY_END, EFI_KEY_PG_DN, EFI_KEY_SEVEN, EFI_KEY_EIGHT,
> + EFI_KEY_NINE, EFI_KEY_E0, EFI_KEY_E1, EFI_KEY_E2, EFI_KEY_E3,
> + EFI_KEY_E4, EFI_KEY_E5, EFI_KEY_E6, EFI_KEY_E7, EFI_KEY_E8, EFI_KEY_E9,
> + EFI_KEY_E10, EFI_KEY_E11, EFI_KEY_E12, EFI_KEY_BACK_SPACE,
> + EFI_KEY_INS, EFI_KEY_HOME, EFI_KEY_PG_UP, EFI_KEY_NLCK, EFI_KEY_SLASH,
> + EFI_KEY_ASTERISK, EFI_KEY_MINUS, EFI_KEY_ESC, EFI_KEY_F1, EFI_KEY_F2,
> + EFI_KEY_F3, EFI_KEY_F4, EFI_KEY_F5, EFI_KEY_F6, EFI_KEY_F7, EFI_KEY_F8,
> + EFI_KEY_F9, EFI_KEY_F10, EFI_KEY_F11, EFI_KEY_F12, EFI_KEY_PRINT,
> + EFI_KEY_SLCK, EFI_KEY_PAUSE,
> +} efi_key;
> +
> +struct efi_key_descriptor {
> + efi_key key;
The size of enum is not defined in the C standard. Please, use u32 or s32.
> + u16 unicode;
> + u16 shifted_unicode;
> + u16 alt_gr_unicode;
> + u16 shifted_alt_gr_unicode;
> + u16 modifier;
> + u16 affected_attribute;
> +};
> +
> +struct efi_hii_keyboard_layout {
> + u16 layout_length;
> + efi_guid_t guid;
This structure is not packed correctly:
The UEFI spec defines EFI_GUID as a 128 bit buffer that is 64 bit
aligned if not otherwise specified.
Our efi_guid_t is 8 bit aligned.
EDK2 has in base.h, UefiBaseType.h, and HiiDatabase.h:
///
/// 128 bit buffer containing a unique identifier value.
/// Unless otherwise specified, aligned on a 64 bit boundary.
///
typedef struct {
UINT32 Data1;
UINT16 Data2;
UINT16 Data3;
UINT8 Data4[8];
} GUID;
typedef GUID EFI_GUID;
typedef struct {
UINT16 LayoutLength;
EFI_GUIDGuid;
UINT32 LayoutDescriptorStringOffset;
UINT8 DescriptorCount;
// EFI_KEY_DESCRIPTORDescriptors[];
} EFI_HII_KEYBOARD_LAYOUT;
For sure this EDK2 Guid is not 64bit aligned but 32bit aligned.
Same wrong 32bit alignment in GRUB:
struct grub_efi_guid
{
grub_uint32_t data1;
grub_uint16_t data2;
grub_uint16_t data3;
grub_uint8_t data4[8];
} __attribute__ ((aligned(8)));
typedef struct grub_efi_guid grub_efi_guid_t;
Linux uses 8bit alignment:
typedef struct {
__u8 b[16];
} guid_t;
typedef guid_t efi_guid_t;
There are other places where the same problem may hit us,
cf.
Re: [U-Boot] [PATCH v1 1/2] dm: usb: udc: Use SEQ_ALIAS to index the USB gadget ports
On 12/15/2018 05:43 PM, Jean-Jacques Hiblot wrote:
> dfu, fastbot and other usb gadget commands take the USB port index as a
fastboot.
Looks good to me, I expect Lukasz to pick it, test it and send me a PR.
> parameter. Currently this index is assigned in the order of the driver
> bindings.
> Changing this behavior using the SEQ_ALIAS feature. This option assign to
> the device a SEQ number based on its alias (if it exists)
>
> To use it we must set the DM_UC_FLAG_SEQ_ALIAS flag and follow the existing
> naming convention: use "usb" for the name of the gadget UCLASS_DRIVER
> (same as for the UCLASS_USB).
>
> If no alias is provided, then the index falls back to the order in which
> the bindings took place.
>
> Signed-off-by: Jean-Jacques Hiblot
> Reported-by: Sam Protsenko
> ---
>
> drivers/usb/gadget/udc/udc-uclass.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/udc-uclass.c
> b/drivers/usb/gadget/udc/udc-uclass.c
> index 0620518..e9f8f5f 100644
> --- a/drivers/usb/gadget/udc/udc-uclass.c
> +++ b/drivers/usb/gadget/udc/udc-uclass.c
> @@ -20,7 +20,7 @@ int usb_gadget_initialize(int index)
> return -EINVAL;
> if (dev_array[index])
> return 0;
> - ret = uclass_get_device(UCLASS_USB_GADGET_GENERIC, index, );
> + ret = uclass_get_device_by_seq(UCLASS_USB_GADGET_GENERIC, index, );
> if (!dev || ret) {
> pr_err("No USB device found\n");
> return -ENODEV;
> @@ -54,5 +54,6 @@ int usb_gadget_handle_interrupts(int index)
>
> UCLASS_DRIVER(usb_gadget_generic) = {
> .id = UCLASS_USB_GADGET_GENERIC,
> - .name = "usb_gadget_generic",
> + .name = "usb",
> + .flags = DM_UC_FLAG_SEQ_ALIAS,
> };
>
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL] u-boot-usb/master
As much as I hate sending so many patches after RC, apparently this is second half of USB gadget DM conversion, so be it. The following changes since commit d117d8f19b0625f88309e47a8a32c2faa384dddc: Merge branch 'master' of git://git.denx.de/u-boot-i2c (2018-12-13 09:36:55 -0500) are available in the Git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to 46a3f276549f3e5720b6e80278cda354c7fa859f: usb: musb-new: sunxi: Fix null pointer access (2018-12-14 17:59:10 +0100) Adam Ford (2): usb: musb: Remove Legacy CONFIG_USB_DAVINCI usb: musb: Remove legacy CONFIG_USB_DA8XX Jean-Jacques Hiblot (20): usb: dwc3-generic: make it compatible with "ti, keystone-dwc3" board: ks2_evm: Enable the USB clocks if DM_USB is used ARM: dts: k2g-evm: enable USB0 and USB1 PHY: Add phy driver for the keystone USB PHY usb: host: replace xhci-keystone driver by the generic dwc3 driver configs: k2g_evm: Enable DFU on K2G EVM spl: drivers: Link usb common library to SPL if USB gadget is enabled spl: net: dm: usb: bind the gadget before attempting to load the image phy: omap_usb2: Add support for am437x dwc3-generic: Add support for the am437x board: ti: am43xx: turn on USB clocks dts: Add a u-boot specific dtsi file for the am4372 dts: am4372: Enable USB1 in SPL configs: am43xx_evm: Enable DM_USB and DM_USB_GADGET configs: am43xx: Enable RNDIS support in SPL usb: musb-new: Allow the diver not to use the set_phy_power() callback usb: musb-new: Add support for DM_USB arm: am33xx: Register USB controllers if DM_USB is used but not OF_CONTROL configs: am335x_evm: Do not disable DM_USB in SPL configs: am335x_boneblack_vboot: enable DM_USB and RNDIS boot in SPl Lukasz Majewski (1): usb: composite: Move bitmap related operations to ./include/linux/bitmap.h Martyn Welch (1): usb: Don't enable CONFIG_SPL_DM_USB for non-DM SPL Petr Štetiar (1): usb: gadget: f_sdp: Provide filesize env variable for downloaded images Siva Durga Prasad Paladugu (1): usb: composite: Fix max packet size for USB3.0 Stefan Mavrodiev (1): usb: musb-new: sunxi: Fix null pointer access arch/arm/dts/am4372-generic-u-boot.dtsi | 2 ++ arch/arm/dts/am4372-u-boot.dtsi | 40 + arch/arm/dts/am437x-gp-evm-u-boot.dtsi | 2 ++ arch/arm/dts/am437x-idk-evm-u-boot.dtsi | 2 ++ arch/arm/dts/am437x-sk-evm-u-boot.dtsi | 2 ++ arch/arm/dts/keystone-k2g-evm.dts| 28 + arch/arm/dts/keystone-k2g.dtsi | 56 ++ arch/arm/include/asm/omap_musb.h | 8 + arch/arm/mach-omap2/am33xx/board.c | 58 +++- board/ti/am43xx/board.c | 22 ++ board/ti/ks2_evm/board.c | 12 common/Makefile | 3 ++ common/spl/spl_net.c | 4 ++- configs/am335x_boneblack_vboot_defconfig | 10 +++ configs/am43xx_evm_defconfig | 19 configs/k2e_evm_defconfig| 7 + configs/k2e_hs_evm_defconfig | 7 + configs/k2g_evm_defconfig| 12 configs/k2g_hs_evm_defconfig | 12 configs/k2hk_evm_defconfig | 7 + configs/k2hk_hs_evm_defconfig| 7 + configs/k2l_evm_defconfig| 7 + configs/k2l_hs_evm_defconfig | 7 + drivers/Makefile | 1 + drivers/phy/Kconfig | 10 +++ drivers/phy/Makefile | 1 + drivers/phy/keystone-usb-phy.c | 109 ++ drivers/phy/omap-usb2-phy.c | 45 +--- drivers/usb/Kconfig | 2 +- drivers/usb/dwc3/dwc3-generic.c | 2 ++ drivers/usb/dwc3/gadget.c| 1 - drivers/usb/dwc3/ti_usb_phy.c| 1 - drivers/usb/eth/r8152.c | 1 - drivers/usb/gadget/at91_udc.c| 1 - drivers/usb/gadget/atmel_usba_udc.c | 1 - drivers/usb/gadget/composite.c | 17 +-- drivers/usb/gadget/dwc2_udc_otg.c| 1 - drivers/usb/gadget/dwc2_udc_otg_phy.c| 1 - drivers/usb/gadget/dwc2_udc_otg_priv.h | 1 - drivers/usb/gadget/f_mass_storage.c | 2 +- drivers/usb/gadget/f_sdp.c | 5 drivers/usb/gadget/pxa25x_udc.c | 1 - drivers/usb/host/Makefile| 1 - drivers/usb/host/xhci-keystone.c | 240 --
[U-Boot] [PATCH] mips: xilfpga: fix DTC warnings
This fixes following DTC warning:
arch/mips/dts/nexys4ddr.dtb: Warning (compatible_is_string_list):
/ethernet@10e0/mdio/phy@1:compatible: property is not a string list
As upstream DTS in Linux doesn't have the offending property,
simply remove it to fix the warning.
Signed-off-by: Daniel Schwierzeck
---
arch/mips/dts/nexys4ddr.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/mips/dts/nexys4ddr.dts b/arch/mips/dts/nexys4ddr.dts
index e254ab1eaa..6de8584ea7 100644
--- a/arch/mips/dts/nexys4ddr.dts
+++ b/arch/mips/dts/nexys4ddr.dts
@@ -40,7 +40,6 @@
#address-cells = <1>;
#size-cells = <0>;
phy0: phy@1 {
- compatible = <0x0007c0f0 0xfff0>;
device_type = "ethernet-phy";
reg = <1>;
} ;
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mips: ath79: fix DTC warnings
Remove all interrupt nodes that cause warnings regarding a missing
interrupt parent. There are no interrupt controller nodes defined
and the device trees don't match the ones in Linux anymore.
Signed-off-by: Daniel Schwierzeck
---
arch/mips/dts/ar933x.dtsi | 3 ---
arch/mips/dts/qca953x.dtsi | 3 ---
2 files changed, 6 deletions(-)
diff --git a/arch/mips/dts/ar933x.dtsi b/arch/mips/dts/ar933x.dtsi
index 85fb14b13b..37354324fe 100644
--- a/arch/mips/dts/ar933x.dtsi
+++ b/arch/mips/dts/ar933x.dtsi
@@ -3,7 +3,6 @@
* Copyright (C) 2015-2016 Wills Wang
*/
-#include
#include "skeleton.dtsi"
/ {
@@ -68,7 +67,6 @@
uart0: uart@1802 {
compatible = "qca,ar9330-uart";
reg = <0x1802 0x20>;
- interrupts = <128 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
};
@@ -103,7 +101,6 @@
spi0: spi@1f00 {
compatible = "qca,ar7100-spi";
reg = <0x1f00 0x10>;
- interrupts = <129 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
diff --git a/arch/mips/dts/qca953x.dtsi b/arch/mips/dts/qca953x.dtsi
index 599e809c47..ba29ea287e 100644
--- a/arch/mips/dts/qca953x.dtsi
+++ b/arch/mips/dts/qca953x.dtsi
@@ -3,7 +3,6 @@
* Copyright (C) 2015-2016 Wills Wang
*/
-#include
#include "skeleton.dtsi"
/ {
@@ -63,7 +62,6 @@
reg = <0x1802 0x20>;
reg-shift = <2>;
clock-frequency = <2500>;
- interrupts = <128 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
};
@@ -72,7 +70,6 @@
spi0: spi@1f00 {
compatible = "qca,ar7100-spi";
reg = <0x1f00 0x10>;
- interrupts = <129 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 6/7] MSCC: add board support for the Luton based evaluation board
Am 14.12.18 um 16:16 schrieb Gregory CLEMENT: > Adding the support for the Luton boards PCB91 which share common code with > the Ocelots boards, including board code, device tree and configuration. > > Signed-off-by: Gregory CLEMENT > --- > MAINTAINERS| 1 + > arch/mips/dts/luton_pcb091.dts | 36 ++ > arch/mips/dts/mscc,luton.dtsi | 87 ++ > arch/mips/mach-mscc/Kconfig| 2 + > board/mscc/luton/Kconfig | 14 ++ > board/mscc/luton/Makefile | 3 ++ > board/mscc/luton/luton.c | 28 +++ > configs/mscc_luton_defconfig | 66 ++ > 8 files changed, 237 insertions(+) > create mode 100644 arch/mips/dts/luton_pcb091.dts > create mode 100644 arch/mips/dts/mscc,luton.dtsi > create mode 100644 board/mscc/luton/Kconfig > create mode 100644 board/mscc/luton/Makefile > create mode 100644 board/mscc/luton/luton.c > create mode 100644 configs/mscc_luton_defconfig > > diff --git a/configs/mscc_luton_defconfig b/configs/mscc_luton_defconfig > new file mode 100644 > index 00..47fe12b6ee > --- /dev/null > +++ b/configs/mscc_luton_defconfig > @@ -0,0 +1,66 @@ > +CONFIG_MIPS=y > +CONFIG_SYS_TEXT_BASE=0x4000 > +CONFIG_SYS_MALLOC_F_LEN=0x2000 > +CONFIG_DEBUG_UART_BOARD_INIT=y > +CONFIG_DEBUG_UART_BASE=0x7010 > +CONFIG_DEBUG_UART_CLOCK=20833 > +CONFIG_ARCH_MSCC=y > +CONFIG_TARGET_LUTON_PCB091=y > +CONFIG_DDRTYPE_MT47H128M8HQ=y > +CONFIG_SYS_LITTLE_ENDIAN=y > +CONFIG_MIPS_BOOT_FDT=y > +CONFIG_DEFAULT_DEVICE_TREE="luton_pcb091" > +CONFIG_DEBUG_UART=y > +CONFIG_FIT=y > +CONFIG_BOOTDELAY=3 > +CONFIG_USE_BOOTARGS=y > +CONFIG_BOOTARGS="console=ttyS0,115200" > +CONFIG_LOGLEVEL=7 > +CONFIG_DISPLAY_CPUINFO=y > +CONFIG_SYS_PROMPT="pcb091 # " > +# CONFIG_CMD_BDI is not set > +# CONFIG_CMD_CONSOLE is not set > +# CONFIG_CMD_ELF is not set > +# CONFIG_CMD_EXPORTENV is not set > +# CONFIG_CMD_IMPORTENV is not set > +# CONFIG_CMD_CRC32 is not set > +CONFIG_CMD_MD5SUM=y > +CONFIG_CMD_MEMINFO=y > +CONFIG_CMD_MEMTEST=y > +# CONFIG_CMD_FLASH is not set > +CONFIG_CMD_GPIO=y > +CONFIG_CMD_SF=y > +CONFIG_CMD_SPI=y > +CONFIG_CMD_DHCP=y > +# CONFIG_NET_TFTP_VARS is not set > +# CONFIG_CMD_NFS is not set > +CONFIG_CMD_PING=y > +CONFIG_CMD_MTDPARTS=y > +CONFIG_MTDIDS_DEFAULT="nor0=spi_flash" > +CONFIG_MTDPARTS_DEFAULT="mtdparts=spi_flash:512k(UBoot),256k(Env),256k(conf),6m@1m(linux)" > +# CONFIG_ISO_PARTITION is not set > +CONFIG_OF_EMBED=y this gives now a build warning = WARNING == CONFIG_OF_EMBED is enabled. This option should only be used for debugging purposes. Please use CONFIG_OF_SEPARATE for boards in mainline. See doc/README.fdt-control for more info. Shall I change it when applying or do you want to test it first and send a follow-up patch? > +CONFIG_ENV_IS_IN_SPI_FLASH=y > +CONFIG_NET_RANDOM_ETHADDR=y > +CONFIG_CLK=y > +CONFIG_DM_GPIO=y > +CONFIG_DM_SPI_FLASH=y > +CONFIG_SPI_FLASH=y > +CONFIG_SPI_FLASH_BAR=y > +CONFIG_SPI_FLASH_GIGADEVICE=y > +CONFIG_SPI_FLASH_MACRONIX=y > +CONFIG_SPI_FLASH_SPANSION=y > +CONFIG_SPI_FLASH_STMICRO=y > +CONFIG_SPI_FLASH_WINBOND=y > +CONFIG_SPI_FLASH_MTD=y > +CONFIG_DM_ETH=y > +CONFIG_PINCTRL=y > +CONFIG_PINCONF=y > +CONFIG_DM_SERIAL=y > +CONFIG_DEBUG_UART_SHIFT=2 > +CONFIG_SYS_NS16550=y > +CONFIG_SPI=y > +CONFIG_DM_SPI=y > +CONFIG_SOFT_SPI=y > +CONFIG_LZMA=y > +CONFIG_XZ=y > -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 2/2] ARM: dts: define USB aliases for all omap5 platforms
This allows us to properly map the USB controller indexes
Tested on dra76 evm, am572 evm
Signed-off-by: Jean-Jacques Hiblot
---
arch/arm/dts/omap5-u-boot.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/dts/omap5-u-boot.dtsi b/arch/arm/dts/omap5-u-boot.dtsi
index 1eb50cd..54a7285 100644
--- a/arch/arm/dts/omap5-u-boot.dtsi
+++ b/arch/arm/dts/omap5-u-boot.dtsi
@@ -12,6 +12,11 @@
tick-timer =
};
+ aliases {
+ usb0 =
+ usb1 =
+ };
+
ocp {
u-boot,dm-spl;
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 1/2] dm: usb: udc: Use SEQ_ALIAS to index the USB gadget ports
dfu, fastbot and other usb gadget commands take the USB port index as a
parameter. Currently this index is assigned in the order of the driver
bindings.
Changing this behavior using the SEQ_ALIAS feature. This option assign to
the device a SEQ number based on its alias (if it exists)
To use it we must set the DM_UC_FLAG_SEQ_ALIAS flag and follow the existing
naming convention: use "usb" for the name of the gadget UCLASS_DRIVER
(same as for the UCLASS_USB).
If no alias is provided, then the index falls back to the order in which
the bindings took place.
Signed-off-by: Jean-Jacques Hiblot
Reported-by: Sam Protsenko
---
drivers/usb/gadget/udc/udc-uclass.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/udc/udc-uclass.c
b/drivers/usb/gadget/udc/udc-uclass.c
index 0620518..e9f8f5f 100644
--- a/drivers/usb/gadget/udc/udc-uclass.c
+++ b/drivers/usb/gadget/udc/udc-uclass.c
@@ -20,7 +20,7 @@ int usb_gadget_initialize(int index)
return -EINVAL;
if (dev_array[index])
return 0;
- ret = uclass_get_device(UCLASS_USB_GADGET_GENERIC, index, );
+ ret = uclass_get_device_by_seq(UCLASS_USB_GADGET_GENERIC, index, );
if (!dev || ret) {
pr_err("No USB device found\n");
return -ENODEV;
@@ -54,5 +54,6 @@ int usb_gadget_handle_interrupts(int index)
UCLASS_DRIVER(usb_gadget_generic) = {
.id = UCLASS_USB_GADGET_GENERIC,
- .name = "usb_gadget_generic",
+ .name = "usb",
+ .flags = DM_UC_FLAG_SEQ_ALIAS,
};
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 0/2] Fix USB port indexes for USB gadget commands
The USB gadget commands take the USB port index as a parameter. This is not playing well with the current DM support for gadget when USB0 is dedicated to host and USB1 dedicated to gadget. This problem has been reported by Sam Protsenko This patch fixes this by using the aliases provided by the DT to get the port index right. Tested on: - dra76 evm - am572 evm Jean-Jacques Hiblot (2): dm: usb: udc: Use SEQ_ALIAS to index the USB gadget ports ARM: dts: define USB aliases for all omap5 platforms arch/arm/dts/omap5-u-boot.dtsi | 5 + drivers/usb/gadget/udc/udc-uclass.c | 5 +++-- 2 files changed, 8 insertions(+), 2 deletions(-) -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/16] SF: Migrate to Linux SPI NOR framework
>>> 2) For BAR support, lets place it as it is and support via spi-nor >> >> Problem is, it not desirable to use BAR as default because its not >> stateless and does not work with all flash parts. OTOH, it seems like 4 >> byte addressing (stateless dedicated opcode or with enter/exit 4 byte >> mode) seems to be standard. >> Also, Linux doesn't support BAR and haven't seen any request for BAR >> support. Why support additional feature and burden of maintaining when >> it may not be needed. >> >> But if you insist, I just have to add BAR support back. > > It's not about insistence, ie how we support since from long and > u-boot bootloader project does in general. bootloader can be some > certain boot difference functionalities unlike Linux, it's better not > to compare u-boot with Linux in all cases. > > Example we have SPI_TX_BYTE which usually not supported in Linux. > Since it's ich controller specific and it require for bootloader to do > byte tx on that specific controller, so we supported. Same for the > case with the BAR, this specific controller(or supported boards) has > been in U-Boot since from long and they do upstream well. So we need > to support BAR in any case or we can find any alternative to work the > same functionalities. (we tried before but ended-up adding BAR) > How about this instead? Lets use 4 byte addressing opcodes as default for >16MB flashes. But if CONFIG_SPI_FLASH_BAR is enabled then, spi-nor layer will use BAR registers for >16MB access instead of 4 byte addressing. I will remove SPI_FLASH_BAR from defconfigs from all boards expect those controllers that really cannot handle 4 byte addressing. From a quick glance it looks following controllers support only 3 byte addresses: stm32_qspi.c ich.c fsl_qspi.c renesas_rpc_spi.c mtk_qspi.c So, except for boards with above controllers, I will remove SPI_FLASH_BAR for all other boards. If there is a regression, then such boards can go back to enabling CONFIG_SPI_FLASH_BAR. AFAIU, above controller HWs(except ich) can support 4 byte addressing but would need to move to spi-mem. Regards Vignesh ex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/16] SF: Migrate to Linux SPI NOR framework
>>> 2) For BAR support, lets place it as it is and support via spi-nor >> >> Problem is, it not desirable to use BAR as default because its not >> stateless and does not work with all flash parts. OTOH, it seems like 4 >> byte addressing (stateless dedicated opcode or with enter/exit 4 byte >> mode) seems to be standard. >> Also, Linux doesn't support BAR and haven't seen any request for BAR >> support. Why support additional feature and burden of maintaining when >> it may not be needed. >> >> But if you insist, I just have to add BAR support back. > > It's not about insistence, ie how we support since from long and > u-boot bootloader project does in general. bootloader can be some > certain boot difference functionalities unlike Linux, it's better not > to compare u-boot with Linux in all cases. > > Example we have SPI_TX_BYTE which usually not supported in Linux. > Since it's ich controller specific and it require for bootloader to do > byte tx on that specific controller, so we supported. Same for the > case with the BAR, this specific controller(or supported boards) has > been in U-Boot since from long and they do upstream well. So we need > to support BAR in any case or we can find any alternative to work the > same functionalities. (we tried before but ended-up adding BAR) > How about this instead? Lets use 4 byte addressing opcodes as default for >16MB flashes. But if CONFIG_SPI_FLASH_BAR is enabled then, spi-nor layer will use BAR registers for >16MB access instead of 4 byte addressing. I will remove SPI_FLASH_BAR from defconfigs from all boards expect those controllers that really cannot handle 4 byte addressing. From a quick glance it looks following controllers support only 3 byte addresses: stm32_qspi.c ich.c fsl_qspi.c renesas_rpc_spi.c mtk_qspi.c So, except for boards with above controllers, I will remove SPI_FLASH_BAR for all other boards. If there is a regression, then such boards can go back to enabling CONFIG_SPI_FLASH_BAR. AFAIU, above controller HWs(except ich perhaps) can support 4 byte addressing but would need to move to spi-mem. Regards Vignesh ex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6 3/9] lib: lmb: reserving overlapping regions should fail
On Fri, Dec 14, 2018 at 09:13:51PM +0100, Simon Goldschmidt wrote: > lmb_add_region handles overlapping regions wrong: instead of merging > or rejecting to add a new reserved region that overlaps an existing > one, it just adds the new region. > > Since internally the same function is used for lmb_alloc, change > lmb_add_region to reject overlapping regions. > > Also, to keep reserved memory correct after 'free', reserved entries > created by allocating memory must not set their size to a multiple > of alignment but to the original size. This ensures the reserved > region is completely removed when the caller calls 'lmb_free', as > this one takes the same size as passed to 'lmb_alloc' etc. > > Add test to assert this. > > Signed-off-by: Simon Goldschmidt [snip] > + if (alloc_size == alloc_size_aligned) > + ASSERT_LMB(, ram, ram_size, 1, ram + ram_size - > +(alloc_size_aligned * 2), alloc_size * 2, 0, 0, 0, > +0); > + else > + ASSERT_LMB(, ram, ram_size, 2, ram + ram_size - > +(alloc_size_aligned * 2), alloc_size, ram + ram_size > +- alloc_size_aligned, alloc_size, 0, 0); I've fixed this inline for testing but, we need braces with this if/else as I guess due to all of the macro expansion it's more than one line and both gcc and clang fail. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] image: fix compiling without CMD_FDT
On Sat, Dec 15, 2018 at 04:00:33PM +0100, Simon Goldschmidt wrote:
> Am Sa., 15. Dez. 2018, 15:56 hat Tom Rini geschrieben:
>
> > On Fri, Dec 14, 2018 at 08:42:18AM +0100, Simon Goldschmidt wrote:
> >
> > > Booting an image currently sets the environment variable "fdtaddr"
> > > by calling into 'cmd/fdt.c'. As a result, linking U-Boot fails if
> > > CMD_FDT is not enabled.
> > >
> > > Fix this by adding 'if (CONFIG_IS_ENABLED(CMD_FDT))' to the two
> > > places where 'set_working_fdt_addr()' is called.
> > >
> > > Signed-off-by: Simon Goldschmidt
> > > ---
> > > common/bootm.c | 3 ++-
> > > common/image-fdt.c | 3 ++-
> > > 2 files changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/common/bootm.c b/common/bootm.c
> > > index 8bf84ebcb7..80f304ce9f 100644
> > > --- a/common/bootm.c
> > > +++ b/common/bootm.c
> > > @@ -262,7 +262,8 @@ int bootm_find_images(int flag, int argc, char *
> > > const argv[])
> > > puts("Could not find a valid device tree\n");
> > > return 1;
> > > }
> > > -set_working_fdt_addr(map_to_sysmem(images.ft_addr));
> > > +if (CONFIG_IS_ENABLED(CMD_FDT))
> > > +set_working_fdt_addr(map_to_sysmem(images.ft_addr));
> > > #endif
> > >
> > > #if IMAGE_ENABLE_FIT
> > > diff --git a/common/image-fdt.c b/common/image-fdt.c
> > > index 95748f0ae1..8ee5a13352 100644
> > > --- a/common/image-fdt.c
> > > +++ b/common/image-fdt.c
> > > @@ -193,7 +193,8 @@ int boot_relocate_fdt(struct lmb *lmb, char
> > > **of_flat_tree, ulong *of_size)
> > > *of_flat_tree = of_start;
> > > *of_size = of_len;
> > >
> > > -set_working_fdt_addr(map_to_sysmem(*of_flat_tree));
> > > +if (CONFIG_IS_ENABLED(CMD_FDT))
> > > +set_working_fdt_addr(map_to_sysmem(*of_flat_tree));
> > > return 0;
> > >
> > > error:
> >
> > Your whitespace was totally destroyed, please v2, thanks!
> >
>
> Sorry for not noticing that. That was my editor at work... :-(
Not a huge deal, but I see that my "just apply it and ignore whitespace"
is making the compiler very mad, ha.
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] image: fix compiling without CMD_FDT
Am Sa., 15. Dez. 2018, 15:56 hat Tom Rini geschrieben:
> On Fri, Dec 14, 2018 at 08:42:18AM +0100, Simon Goldschmidt wrote:
>
> > Booting an image currently sets the environment variable "fdtaddr"
> > by calling into 'cmd/fdt.c'. As a result, linking U-Boot fails if
> > CMD_FDT is not enabled.
> >
> > Fix this by adding 'if (CONFIG_IS_ENABLED(CMD_FDT))' to the two
> > places where 'set_working_fdt_addr()' is called.
> >
> > Signed-off-by: Simon Goldschmidt
> > ---
> > common/bootm.c | 3 ++-
> > common/image-fdt.c | 3 ++-
> > 2 files changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/common/bootm.c b/common/bootm.c
> > index 8bf84ebcb7..80f304ce9f 100644
> > --- a/common/bootm.c
> > +++ b/common/bootm.c
> > @@ -262,7 +262,8 @@ int bootm_find_images(int flag, int argc, char *
> > const argv[])
> > puts("Could not find a valid device tree\n");
> > return 1;
> > }
> > -set_working_fdt_addr(map_to_sysmem(images.ft_addr));
> > +if (CONFIG_IS_ENABLED(CMD_FDT))
> > +set_working_fdt_addr(map_to_sysmem(images.ft_addr));
> > #endif
> >
> > #if IMAGE_ENABLE_FIT
> > diff --git a/common/image-fdt.c b/common/image-fdt.c
> > index 95748f0ae1..8ee5a13352 100644
> > --- a/common/image-fdt.c
> > +++ b/common/image-fdt.c
> > @@ -193,7 +193,8 @@ int boot_relocate_fdt(struct lmb *lmb, char
> > **of_flat_tree, ulong *of_size)
> > *of_flat_tree = of_start;
> > *of_size = of_len;
> >
> > -set_working_fdt_addr(map_to_sysmem(*of_flat_tree));
> > +if (CONFIG_IS_ENABLED(CMD_FDT))
> > +set_working_fdt_addr(map_to_sysmem(*of_flat_tree));
> > return 0;
> >
> > error:
>
> Your whitespace was totally destroyed, please v2, thanks!
>
Sorry for not noticing that. That was my editor at work... :-(
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] image: fix compiling without CMD_FDT
On Fri, Dec 14, 2018 at 08:42:18AM +0100, Simon Goldschmidt wrote:
> Booting an image currently sets the environment variable "fdtaddr"
> by calling into 'cmd/fdt.c'. As a result, linking U-Boot fails if
> CMD_FDT is not enabled.
>
> Fix this by adding 'if (CONFIG_IS_ENABLED(CMD_FDT))' to the two
> places where 'set_working_fdt_addr()' is called.
>
> Signed-off-by: Simon Goldschmidt
> ---
> common/bootm.c | 3 ++-
> common/image-fdt.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/common/bootm.c b/common/bootm.c
> index 8bf84ebcb7..80f304ce9f 100644
> --- a/common/bootm.c
> +++ b/common/bootm.c
> @@ -262,7 +262,8 @@ int bootm_find_images(int flag, int argc, char *
> const argv[])
> puts("Could not find a valid device tree\n");
> return 1;
> }
> -set_working_fdt_addr(map_to_sysmem(images.ft_addr));
> +if (CONFIG_IS_ENABLED(CMD_FDT))
> +set_working_fdt_addr(map_to_sysmem(images.ft_addr));
> #endif
>
> #if IMAGE_ENABLE_FIT
> diff --git a/common/image-fdt.c b/common/image-fdt.c
> index 95748f0ae1..8ee5a13352 100644
> --- a/common/image-fdt.c
> +++ b/common/image-fdt.c
> @@ -193,7 +193,8 @@ int boot_relocate_fdt(struct lmb *lmb, char
> **of_flat_tree, ulong *of_size)
> *of_flat_tree = of_start;
> *of_size = of_len;
>
> -set_working_fdt_addr(map_to_sysmem(*of_flat_tree));
> +if (CONFIG_IS_ENABLED(CMD_FDT))
> +set_working_fdt_addr(map_to_sysmem(*of_flat_tree));
> return 0;
>
> error:
Your whitespace was totally destroyed, please v2, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/16] SF: Migrate to Linux SPI NOR framework
On Sat, Dec 15, 2018 at 7:29 PM Jagan Teki wrote: > > On Fri, Dec 14, 2018 at 10:12 PM Vignesh R wrote: > > > > >> > > >> > 2) For BAR support, lets place it as it is and support via > > > spi-nor > > >> > > > > Problem is, it not desirable to use BAR as default because its > > > not > > > > stateless and does not work with all flash parts. OTOH, it > > > seems like 4 > > > > byte addressing (stateless dedicated opcode or with enter/exit > > > 4 byte > > > > mode) seems to be standard. > > > > Also, Linux doesn't support BAR and haven't seen any request > > > for BAR > > > > support. Why support additional feature and burden of > > > maintaining when > > > > it may not be needed. > > > > > > > > But if you insist, I just have to add BAR support back. > > > > > > > > > > > > But if we do that, could we please have a config option so that I > > > can > > > > somehow ensure only 4 byte opcoses are used that don't change some > > > state > > > > in the chip? > > > > > > > > > > I am afraid BAR support would be the default as Jagan suggests not to > > > change existing behavior. You would have to disable SPI_FLASH_BAR to > > > use > > > 4 Byte addressing opcodes. > > > > > > > > > Honestly, I don't like the idea of making BAR the default. Why can't we > > > go the Linux way and enable BAR (maybe then as default) for boards that > > > need it only? > > > > > > > Jagan, would that be acceptable? > > Better way to have some controller flag to check we go with 3-byte or > 4-byte addressing if flash > 16MiB. anyway let me give some time, will > come back for the better to way to go this. ofcourse CONFIG would > require if BAR handling code occupy more foot-print, but we have to > enable based some controller indication. another approach can be do some sanity transfer if the flash > 16MiB with 4-byte addressing failure can lead to enable BAR. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-dm
On Fri, Dec 14, 2018 at 08:43:09AM -0700, Simon Glass wrote: > Hi Tom, > > See here (the one failure seems to be a network error) > https://travis-ci.org/sglass68/u-boot/builds/46333 Those are annoying and I wish it would auto-restart those jobs since it should be able to catch that as the failure most of the time. You can restart individual tasks BTW, I do that as needed. > > > The following changes since commit d117d8f19b0625f88309e47a8a32c2faa384dddc: > > Merge branch 'master' of git://git.denx.de/u-boot-i2c (2018-12-13 > 09:36:55 -0500) > > are available in the Git repository at: > > git://git.denx.de/u-boot-dm.git tags/dm-pull-14dec18 > > for you to fetch changes up to f987177db9c988142032ed8142a093cce2378a90: > > dm: sound: Use the correct number of channels for sound (2018-12-13 > 16:37:10 -0700) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/16] SF: Migrate to Linux SPI NOR framework
On Fri, Dec 14, 2018 at 10:12 PM Vignesh R wrote: > > >> > >> > 2) For BAR support, lets place it as it is and support via > > spi-nor > >> > > > Problem is, it not desirable to use BAR as default because its not > > > stateless and does not work with all flash parts. OTOH, it > > seems like 4 > > > byte addressing (stateless dedicated opcode or with enter/exit > > 4 byte > > > mode) seems to be standard. > > > Also, Linux doesn't support BAR and haven't seen any request > > for BAR > > > support. Why support additional feature and burden of > > maintaining when > > > it may not be needed. > > > > > > But if you insist, I just have to add BAR support back. > > > > > > > > > But if we do that, could we please have a config option so that I can > > > somehow ensure only 4 byte opcoses are used that don't change some > > state > > > in the chip? > > > > > > > I am afraid BAR support would be the default as Jagan suggests not to > > change existing behavior. You would have to disable SPI_FLASH_BAR to use > > 4 Byte addressing opcodes. > > > > > > Honestly, I don't like the idea of making BAR the default. Why can't we > > go the Linux way and enable BAR (maybe then as default) for boards that > > need it only? > > > > Jagan, would that be acceptable? Better way to have some controller flag to check we go with 3-byte or 4-byte addressing if flash > 16MiB. anyway let me give some time, will come back for the better to way to go this. ofcourse CONFIG would require if BAR handling code occupy more foot-print, but we have to enable based some controller indication. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/16] SF: Migrate to Linux SPI NOR framework
On Fri, Dec 14, 2018 at 9:23 PM Vignesh R wrote: > > On 14/12/18 3:43 PM, Jagan Teki wrote: > > On Wed, Dec 12, 2018 at 11:02 PM Vignesh R wrote: > >> > >> U-Boot SPI NOR support (sf layer) is quite outdated as it does not > >> support 4 byte addressing opcodes, SFDP table parsing and different types > >> of > >> quad mode enable sequences. Many newer flashes no longer support BANK > >> registers used by sf layer to a access >16MB space. > >> Also, many SPI controllers have special MMIO interfaces which provide > >> accelerated read/write access but require knowledge of flash parameters > >> to make use of it. Recent spi-mem layer provides a way to support such > >> flashes but sf layer isn't using that. > >> This patch series syncs SPI NOR framework from Linux v4.19. It also adds > >> spi-mem support on top. > >> So, we gain 4byte addressing support and SFDP support. This makes > >> migrating to U-Boot MTD framework easier. > >> > >> Tested with few Spansion, micron and macronix flashes with TI's dra7xx, > >> k2g, am43xx EVMs. I dont have access to flashes from other vendors. So, > >> I would greatly appreciate testing on other platforms. Complete series > >> with dependencies here[1] > >> > >> For clean build on some platforms, depends on CONFIG_SPI_FLASH migration > >> to defconfigs [2] > >> > >> [1] https://github.com/r-vignesh/u-boot.git branch: spi-nor-mig-patch-v1 > >> [2] https://patchwork.ozlabs.org/patch/1007485/ > >> > >> Patch 12-15 are compile tested. > > > > Fist of all thanks for your time and work on this. > > > > Since most of the discussion on the individual patches seems similar, > > repeat and never ended. I'm trying to summarize my comments here. > > 1) You can sync or add new features by grabbing the code from Linux, > > but I don't recommend __UBOOT macro or any Linux specific stuff in > > drivers/mtd/spi > > I am fine either way. > > > 2) For BAR support, lets place it as it is and support via spi-nor > > Problem is, it not desirable to use BAR as default because its not > stateless and does not work with all flash parts. OTOH, it seems like 4 > byte addressing (stateless dedicated opcode or with enter/exit 4 byte > mode) seems to be standard. > Also, Linux doesn't support BAR and haven't seen any request for BAR > support. Why support additional feature and burden of maintaining when > it may not be needed. > > But if you insist, I just have to add BAR support back. It's not about insistence, ie how we support since from long and u-boot bootloader project does in general. bootloader can be some certain boot difference functionalities unlike Linux, it's better not to compare u-boot with Linux in all cases. Example we have SPI_TX_BYTE which usually not supported in Linux. Since it's ich controller specific and it require for bootloader to do byte tx on that specific controller, so we supported. Same for the case with the BAR, this specific controller(or supported boards) has been in U-Boot since from long and they do upstream well. So we need to support BAR in any case or we can find any alternative to work the same functionalities. (we tried before but ended-up adding BAR) > > > 3) For dual flash, wait for Xilinx developers if they really want to > > support it? > > Sorry, this feature was never supported properly *in mainline U-Boot*. > If support is needed in the future, we can accept patches on top of new > framework. Siva, Michael any time-line to work on this topic? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] MIPS (mt7688): EBase change in U-Boot breaks Linux
On Thu, 13 Dec 2018, Daniel Schwierzeck wrote: > > I'm not so sure, if overwriting 0x8000 (default value of EBase on > > this SoC) with the exception handler is allowed. Is this address "zero" > > handled somewhat specific in MIPS Linux? AFAICT, the complete DDR > > area on my platform (0x8000. - 0x87ff.) is available for Linux. > > So allocating some memory for this exception handler seems the right > > way to go to me. > > > > maybe that's why some platforms define a load address of 0x80002000 or similar > to protect this area somehow. It is. MIPS processors before r2 (i.e. r1 and all the legacy ones) did not have the CP0.EBase register and the (non-CP0.Status.BEV) exception vector base was hardwired to 0x8000 or 0x8000 for 32-bit and 64-bit implementations respectively. Then bootstrap/console monitor firmware typically used some RAM right above the exception handler area for its own purposes. Consequently the load address of any executable to be run by such firmware had to be set such as to avoid clobbering these areas. HTH, Maciej ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] misc: imx8: scu: use platdata instead of priv data
+Simon
> -Original Message-
> From: Peng Fan
> Sent: 2018年12月15日 20:20
> To: sba...@denx.de
> Cc: Fabio Estevam ; u-boot@lists.denx.de;
> dl-uboot-imx ; Peng Fan
> Subject: [PATCH 3/5] misc: imx8: scu: use platdata instead of priv data
>
> priv data has not been allocated when doing bind, so it is wrong to use
> dev_get_priv in bind call back.
>
> Let's switch to use platdata in the driver to fix the issue.
>
> Signed-off-by: Peng Fan
> ---
> drivers/misc/imx8/scu.c | 26 +-
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/misc/imx8/scu.c b/drivers/misc/imx8/scu.c index
> b824ac79e6..15101b3e5f 100644
> --- a/drivers/misc/imx8/scu.c
> +++ b/drivers/misc/imx8/scu.c
> @@ -158,7 +158,7 @@ static int sc_ipc_write(struct mu_type *base, void
> *data) static int imx8_scu_call(struct udevice *dev, int no_resp, void
> *tx_msg,
>int tx_size, void *rx_msg, int rx_size) {
> - struct imx8_scu *priv = dev_get_priv(dev);
> + struct imx8_scu *plat = dev_get_platdata(dev);
> sc_err_t result;
> int ret;
>
> @@ -166,11 +166,11 @@ static int imx8_scu_call(struct udevice *dev, int
> no_resp, void *tx_msg,
> if (rx_msg && tx_msg != rx_msg)
> printf("tx_msg %p, rx_msg %p\n", tx_msg, rx_msg);
>
> - ret = sc_ipc_write(priv->base, tx_msg);
> + ret = sc_ipc_write(plat->base, tx_msg);
> if (ret)
> return ret;
> if (!no_resp) {
> - ret = sc_ipc_read(priv->base, rx_msg);
> + ret = sc_ipc_read(plat->base, rx_msg);
> if (ret)
> return ret;
> }
> @@ -182,24 +182,24 @@ static int imx8_scu_call(struct udevice *dev, int
> no_resp, void *tx_msg,
>
> static int imx8_scu_probe(struct udevice *dev) {
> - struct imx8_scu *priv = dev_get_priv(dev);
> + struct imx8_scu *plat = dev_get_platdata(dev);
> fdt_addr_t addr;
>
> - debug("%s(dev=%p) (priv=%p)\n", __func__, dev, priv);
> + debug("%s(dev=%p) (plat=%p)\n", __func__, dev, plat);
>
> addr = devfdt_get_addr(dev);
> if (addr == FDT_ADDR_T_NONE)
> return -EINVAL;
>
> - priv->base = (struct mu_type *)addr;
> + plat->base = (struct mu_type *)addr;
>
> /* U-Boot not enable interrupts, so need to enable RX interrupts */
> - mu_hal_init(priv->base);
> + mu_hal_init(plat->base);
>
> gd->arch.scu_dev = dev;
>
> - device_probe(priv->clk);
> - device_probe(priv->pinclk);
> + device_probe(plat->clk);
> + device_probe(plat->pinclk);
>
> return 0;
> }
> @@ -211,7 +211,7 @@ static int imx8_scu_remove(struct udevice *dev)
>
> static int imx8_scu_bind(struct udevice *dev) {
> - struct imx8_scu *priv = dev_get_priv(dev);
> + struct imx8_scu *plat = dev_get_platdata(dev);
> int ret;
> struct udevice *child;
> int node;
> @@ -227,7 +227,7 @@ static int imx8_scu_bind(struct udevice *dev)
> if (ret)
> return ret;
>
> - priv->clk = child;
> + plat->clk = child;
>
> node = fdt_node_offset_by_compatible(gd->fdt_blob, -1,
>"fsl,imx8qxp-iomuxc");
> @@ -238,7 +238,7 @@ static int imx8_scu_bind(struct udevice *dev)
> if (ret)
> return ret;
>
> - priv->pinclk = child;
> + plat->pinclk = child;
>
> return 0;
> }
> @@ -261,6 +261,6 @@ U_BOOT_DRIVER(imx8_scu) = {
> .bind = imx8_scu_bind,
> .remove = imx8_scu_remove,
> .ops= _scu_ops,
> - .priv_auto_alloc_size = sizeof(struct imx8_scu),
> + .platdata_auto_alloc_size = sizeof(struct imx8_scu),
> .flags = DM_FLAG_PRE_RELOC,
> };
> --
> 2.14.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/5] misc: imx: scu: avoid write null pointer
When boot_dev is true, fill boot device. However the original logic is when
boot_dev is false, fill boot device, this will trigger data abort.
Also fix sc_misc_get_control when using pointer val.
Signed-off-by: Peng Fan
---
drivers/misc/imx8/scu_api.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/imx8/scu_api.c b/drivers/misc/imx8/scu_api.c
index 65080d7544..d9c4d5d784 100644
--- a/drivers/misc/imx8/scu_api.c
+++ b/drivers/misc/imx8/scu_api.c
@@ -169,7 +169,7 @@ int sc_misc_get_control(sc_ipc_t ipc, sc_rsrc_t resource,
sc_ctrl_t ctrl,
printf("%s: ctrl:%d resource:%d: res:%d\n",
__func__, ctrl, resource, RPC_R8());
- if (!val)
+ if (val)
*val = RPC_U32(, 0U);
return ret;
@@ -194,7 +194,7 @@ void sc_misc_get_boot_dev(sc_ipc_t ipc, sc_rsrc_t *boot_dev)
if (ret)
printf("%s: res:%d\n", __func__, RPC_R8());
- if (!boot_dev)
+ if (boot_dev)
*boot_dev = RPC_U16(, 0U);
}
--
2.14.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/5] tools: imx8image: set dcd_skip to true
To B0[+] chips, dcd_skip needs to be true. For A0 chip, it needs to be false, however A0 chip is no longer being supported anymore. Considering we are moving code from imx-mkimage to uboot mkimage, to make sure we not introduce some surprise, we still keep dcd_skip code there. Signed-off-by: Peng Fan --- tools/imx8image.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/imx8image.c b/tools/imx8image.c index 6e8ac464e7..0d856b9d94 100644 --- a/tools/imx8image.c +++ b/tools/imx8image.c @@ -968,7 +968,7 @@ int imx8image_copy_image(int outfd, struct image_tool_params *mparams) fprintf(stdout, "CONTAINER SW VERSION:\t0x%04x\n", sw_version); build_container(soc, sector_size, emmc_fastboot, - img_sp, false, fuse_version, sw_version, outfd); + img_sp, true, fuse_version, sw_version, outfd); return 0; } -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/5] misc: imx8: scu: use platdata instead of priv data
priv data has not been allocated when doing bind, so it is
wrong to use dev_get_priv in bind call back.
Let's switch to use platdata in the driver to fix the issue.
Signed-off-by: Peng Fan
---
drivers/misc/imx8/scu.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/misc/imx8/scu.c b/drivers/misc/imx8/scu.c
index b824ac79e6..15101b3e5f 100644
--- a/drivers/misc/imx8/scu.c
+++ b/drivers/misc/imx8/scu.c
@@ -158,7 +158,7 @@ static int sc_ipc_write(struct mu_type *base, void *data)
static int imx8_scu_call(struct udevice *dev, int no_resp, void *tx_msg,
int tx_size, void *rx_msg, int rx_size)
{
- struct imx8_scu *priv = dev_get_priv(dev);
+ struct imx8_scu *plat = dev_get_platdata(dev);
sc_err_t result;
int ret;
@@ -166,11 +166,11 @@ static int imx8_scu_call(struct udevice *dev, int
no_resp, void *tx_msg,
if (rx_msg && tx_msg != rx_msg)
printf("tx_msg %p, rx_msg %p\n", tx_msg, rx_msg);
- ret = sc_ipc_write(priv->base, tx_msg);
+ ret = sc_ipc_write(plat->base, tx_msg);
if (ret)
return ret;
if (!no_resp) {
- ret = sc_ipc_read(priv->base, rx_msg);
+ ret = sc_ipc_read(plat->base, rx_msg);
if (ret)
return ret;
}
@@ -182,24 +182,24 @@ static int imx8_scu_call(struct udevice *dev, int
no_resp, void *tx_msg,
static int imx8_scu_probe(struct udevice *dev)
{
- struct imx8_scu *priv = dev_get_priv(dev);
+ struct imx8_scu *plat = dev_get_platdata(dev);
fdt_addr_t addr;
- debug("%s(dev=%p) (priv=%p)\n", __func__, dev, priv);
+ debug("%s(dev=%p) (plat=%p)\n", __func__, dev, plat);
addr = devfdt_get_addr(dev);
if (addr == FDT_ADDR_T_NONE)
return -EINVAL;
- priv->base = (struct mu_type *)addr;
+ plat->base = (struct mu_type *)addr;
/* U-Boot not enable interrupts, so need to enable RX interrupts */
- mu_hal_init(priv->base);
+ mu_hal_init(plat->base);
gd->arch.scu_dev = dev;
- device_probe(priv->clk);
- device_probe(priv->pinclk);
+ device_probe(plat->clk);
+ device_probe(plat->pinclk);
return 0;
}
@@ -211,7 +211,7 @@ static int imx8_scu_remove(struct udevice *dev)
static int imx8_scu_bind(struct udevice *dev)
{
- struct imx8_scu *priv = dev_get_priv(dev);
+ struct imx8_scu *plat = dev_get_platdata(dev);
int ret;
struct udevice *child;
int node;
@@ -227,7 +227,7 @@ static int imx8_scu_bind(struct udevice *dev)
if (ret)
return ret;
- priv->clk = child;
+ plat->clk = child;
node = fdt_node_offset_by_compatible(gd->fdt_blob, -1,
"fsl,imx8qxp-iomuxc");
@@ -238,7 +238,7 @@ static int imx8_scu_bind(struct udevice *dev)
if (ret)
return ret;
- priv->pinclk = child;
+ plat->pinclk = child;
return 0;
}
@@ -261,6 +261,6 @@ U_BOOT_DRIVER(imx8_scu) = {
.bind = imx8_scu_bind,
.remove = imx8_scu_remove,
.ops= _scu_ops,
- .priv_auto_alloc_size = sizeof(struct imx8_scu),
+ .platdata_auto_alloc_size = sizeof(struct imx8_scu),
.flags = DM_FLAG_PRE_RELOC,
};
--
2.14.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/5] imx8: cpu: correct info
The CPU banner printed is as following: CPU: CPU: Freescale i.MX8QXP RevB A35 at 147228 MHz 1. Drop the CPU: 2. Change vendor from Freescale to NXP Signed-off-by: Peng Fan --- arch/arm/mach-imx/imx8/cpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-imx/imx8/cpu.c b/arch/arm/mach-imx/imx8/cpu.c index f093f34ca5..7599afe720 100644 --- a/arch/arm/mach-imx/imx8/cpu.c +++ b/arch/arm/mach-imx/imx8/cpu.c @@ -573,7 +573,7 @@ int cpu_imx_get_desc(struct udevice *dev, char *buf, int size) if (size < 100) return -ENOSPC; - snprintf(buf, size, "CPU: Freescale i.MX8%s Rev%s %s at %u MHz\n", + snprintf(buf, size, "NXP i.MX8%s Rev%s %s at %u MHz\n", plat->type, plat->rev, plat->name, plat->freq_mhz); return 0; -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/5] clk: imx8: fix build warning
When build clk driver in spl, met the warning:
"
drivers/clk/imx/clk-imx8.c:21:25: warning: ‘imx8_clk_names’ defined but not
used [-Wunused-variable]
static struct imx8_clks imx8_clk_names[] = {
^~
"
Fix with wrapping the array with CONFIG_CMD_CLK.
Signed-off-by: Peng Fan
---
drivers/clk/imx/clk-imx8.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/imx/clk-imx8.c b/drivers/clk/imx/clk-imx8.c
index fcb8090d35..d03fcc2fdd 100644
--- a/drivers/clk/imx/clk-imx8.c
+++ b/drivers/clk/imx/clk-imx8.c
@@ -18,6 +18,7 @@ struct imx8_clks {
const char *name;
};
+#if CONFIG_IS_ENABLED(CMD_CLK)
static struct imx8_clks imx8_clk_names[] = {
{ IMX8QXP_A35_DIV, "A35_DIV" },
{ IMX8QXP_I2C0_CLK, "I2C0" },
@@ -39,6 +40,7 @@ static struct imx8_clks imx8_clk_names[] = {
{ IMX8QXP_ENET1_REF_DIV, "ENET1_REF" },
{ IMX8QXP_ENET1_PTP_CLK, "ENET1_PTP" },
};
+#endif
static ulong imx8_clk_get_rate(struct clk *clk)
{
--
2.14.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/5] imx8: several fixes
Several fixes when moving to support SPL. Peng Fan (5): clk: imx8: fix build warning misc: imx: scu: avoid write null pointer misc: imx8: scu: use platdata instead of priv data imx8: cpu: correct info tools: imx8image: set dcd_skip to true arch/arm/mach-imx/imx8/cpu.c | 2 +- drivers/clk/imx/clk-imx8.c | 2 ++ drivers/misc/imx8/scu.c | 26 +- drivers/misc/imx8/scu_api.c | 4 ++-- tools/imx8image.c| 2 +- 5 files changed, 19 insertions(+), 17 deletions(-) -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2] MAINTAINERS: update NXP i.MX mail list address
Update NXP i.MX mail list address Signed-off-by: Peng Fan --- V2: Update name of the mail list MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 0cec39c542..f8656fd9bd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -123,7 +123,7 @@ F: drivers/spi/bcmstb_spi.c ARM FREESCALE IMX M: Stefano Babic M: Fabio Estevam -R: NXP Linux Team +R: NXP i.MX U-Boot Team S: Maintained T: git git://git.denx.de/u-boot-imx.git F: arch/arm/cpu/arm1136/mx*/ -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] MAINTAINERS: update NXP i.MX mail list address
On Sat, Dec 15, 2018 at 11:19 AM Peng Fan wrote: > > Update NXP i.MX mail list address > > Signed-off-by: Peng Fan > --- > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 0cec39c542..fe2a1c9db5 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -123,7 +123,7 @@ F: drivers/spi/bcmstb_spi.c > ARM FREESCALE IMX > M: Stefano Babic > M: Fabio Estevam > -R: NXP Linux Team > +R: NXP Linux Team Shouldn't it be NXP i.MX U-Boot team? The email address indicates it's for i.MX U-Boot, not for everything else that NXP manufactures, eg: QorIQ series. > S: Maintained > T: git git://git.denx.de/u-boot-imx.git > F: arch/arm/cpu/arm1136/mx*/ Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] MAINTAINERS: update NXP i.MX mail list address
> On 15.12.2018, at 04:19, Peng Fan wrote: > > Update NXP i.MX mail list address > > Signed-off-by: Peng Fan > --- > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 0cec39c542..fe2a1c9db5 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -123,7 +123,7 @@ F:drivers/spi/bcmstb_spi.c > ARM FREESCALE IMX > M:Stefano Babic > M:Fabio Estevam > -R: NXP Linux Team > +R: NXP Linux Team Shouldn’t this update the “real name” component as well? > S:Maintained > T:git git://git.denx.de/u-boot-imx.git > F:arch/arm/cpu/arm1136/mx*/ > -- > 2.14.1 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
