Re: [U-Boot] [PATCH 3/3] imx: mx6sllevk: add usb support
On 12/22/2016 09:38 AM, Peng Fan wrote: > > >> -Original Message- >> From: Marek Vasut [mailto:ma...@denx.de] >> Sent: Thursday, December 22, 2016 3:12 PM >> To: Peng Fan ; sba...@denx.de >> Cc: u-boot@lists.denx.de; van.free...@gmail.com >> Subject: Re: [PATCH 3/3] imx: mx6sllevk: add usb support >> >> On 12/22/2016 07:38 AM, Peng Fan wrote: >>> >>> -Original Message- From: Marek Vasut [mailto:ma...@denx.de] Sent: Thursday, December 22, 2016 2:12 PM To: Peng Fan ; sba...@denx.de Cc: u-boot@lists.denx.de; van.free...@gmail.com Subject: Re: [PATCH 3/3] imx: mx6sllevk: add usb support On 12/22/2016 07:03 AM, Peng Fan wrote: > > Hi Marek, > >> -Original Message- >> From: Marek Vasut [mailto:ma...@denx.de] >> Sent: Thursday, December 22, 2016 12:40 PM >> To: Peng Fan ; sba...@denx.de >> Cc: u-boot@lists.denx.de; van.free...@gmail.com >> Subject: Re: [PATCH 3/3] imx: mx6sllevk: add usb support >> >> On 12/22/2016 02:13 AM, Peng Fan wrote: >>> >>> -Original Message- From: Marek Vasut [mailto:ma...@denx.de] Sent: Wednesday, December 21, 2016 10:10 PM To: Peng Fan ; sba...@denx.de Cc: u-boot@lists.denx.de; van.free...@gmail.com Subject: Re: [PATCH 3/3] imx: mx6sllevk: add usb support On 12/21/2016 09:14 AM, Peng Fan wrote: > Add usb support for mx6sllevk board. > > Signed-off-by: Peng Fan > Cc: Stefano Babic > --- >>> [..] >>> > + > +#define USB_OTHERREGS_OFFSET 0x800 > +#define UCTRL_PWR_POL (1 << 9) > + > +int board_ehci_hcd_init(int port) { > + u32 *usbnc_usb_ctrl; > + > + if (port > 1) > + return -EINVAL; > + > + usbnc_usb_ctrl = (u32 *)(USB_BASE_ADDR + USB_OTHERREGS_OFFSET + > + port * 4); > + > + /* Set Power polarity */ > + setbits_le32(usbnc_usb_ctrl, UCTRL_PWR_POL); > + return 0; > +} Is this function similar to what usb_oc_config() does ? >>> >>> No, this bit is not for overcurrent. According to RM, this is OTG >>> Power Polarity This bit should be set according to power switch's >>> enable >> polarity. >>> 1 Power switch has an active-high enable input >>> 0 Power switch has an active-low enable input >>> >>> This is board specific. >> >> Great, except it should also be part of the driver , the same way >> as polarity is configured, yes ? > > I just found that there is code for mx7, > http://lists.denx.de/pipermail/u-boot/2016-July/260321.html > > Then do you agree I add such piece code in usb_power_config for mx6? > " > #ifdef CONFIG_MXC_USB_OTG_HACTIVE > setbits_le32(ctrl, UCTRL_PWR_POL); #else > clrbits_le32(ctrl, UCTRL_PWR_POL); #endif " Didn't you add DT support in a patch sent like ... yesterday ? :) Just use DT property instead of ifdef. >>> >>> There is no property for otg power polatiry in upstream Linux. I would >>> not like to introduce one in U-Boot. We can drop the ifdef when there is an >> property in upstream. What do you think? >> >> So uh, how can the USB work in mainline Linux on that board ? > > Confirmed with IC, if using gpio to control vbus power, no need to configure > this bit. > Since in dts, we are using gpio regulator to control vbus, this piece code in > patch 3/3 > can be discarded. I'll drop it in V2. Hum, OK. Let's revisit this when we need this then ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] imx: mx6sllevk: add usb support
On 12/22/2016 09:55 AM, Peng Fan wrote: > > >>> +#define USB_OTHERREGS_OFFSET 0x800 >>> +#define UCTRL_PWR_POL (1 << 9) >>> + >>> +int board_ehci_hcd_init(int port) { >>> + u32 *usbnc_usb_ctrl; >>> + >>> + if (port > 1) >>> + return -EINVAL; >>> + >>> + usbnc_usb_ctrl = (u32 *)(USB_BASE_ADDR + >> USB_OTHERREGS_OFFSET >> + >>> +port * 4); >>> + >>> + /* Set Power polarity */ >>> + setbits_le32(usbnc_usb_ctrl, UCTRL_PWR_POL); >>> + return 0; >>> +} >> >> Is this function similar to what usb_oc_config() does ? > > No, this bit is not for overcurrent. According to RM, this is > OTG Power Polarity This bit should be set according to power > switch's enable polarity. > 1 Power switch has an active-high enable input > 0 Power switch has an active-low enable input > > This is board specific. Great, except it should also be part of the driver , the same way as polarity is configured, yes ? >>> >>> I just found that there is code for mx7, >>> http://lists.denx.de/pipermail/u-boot/2016-July/260321.html >>> >>> Then do you agree I add such piece code in usb_power_config for mx6? >>> " >>> #ifdef CONFIG_MXC_USB_OTG_HACTIVE >>> setbits_le32(ctrl, UCTRL_PWR_POL); #else >>> clrbits_le32(ctrl, UCTRL_PWR_POL); #endif " >> >> Didn't you add DT support in a patch sent like ... yesterday ? :) >> Just use DT property instead of ifdef. > > There is no property for otg power polatiry in upstream Linux. I > would not like to introduce one in U-Boot. We can drop the ifdef > when there is an property in upstream. What do you think? So uh, how can the USB work in mainline Linux on that board ? >>> >>> Confirmed with IC, if using gpio to control vbus power, no need to configure >> this bit. >>> Since in dts, we are using gpio regulator to control vbus, this piece >>> code in patch 3/3 can be discarded. I'll drop it in V2. >> >> Hum, OK. Let's revisit this when we need this then ? > > Take i.MX6SLL as an example, > The pin key_col4 can be configured with the two functions. > [1] MX6_PAD_KEY_COL4__USB_OTG1_PWR > [2] MX6_PAD_KEY_COL4__GPIO4_IO00 > > In fsl i.mx uboot code, the common way is to use [1] and configure the > polarity to enable the vbus power. > But in kernel, it is configured as [2] and use gpio regulator to enable the > vbus power. > > This is board specific. There is no upstream property for this bit. When > there is an upstream property for this, > We could add it in probe function for those that use [1] in dts pinmux. > > Now I am using the same dts from kernel which this pinmux configured as [2], > so this piece code is not needed for now. Well, can you submit a proposal with the new prop for devicetree@ ? It can then be improved in linux too ... -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/3] usb: ehci-mx6: handle vbus-supply
On 12/22/2016 10:06 AM, Peng Fan wrote: > Drop board_ehci_power when dm usb used and switch to use > regulator api to handle vbus. > > Signed-off-by: Peng Fan > Cc: Marek Vasut > Cc: Simon Glass > Cc: Stefano Babic Acked-by: Marek Vasut I'd like a R-B from Simon on this one. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3] usb: ehci-mx6: implement ofdata_to_platdata
On 12/22/2016 10:06 AM, Peng Fan wrote: > Implement ofdata_to_platdata to set the type to host or device. > - Check "dr-mode" property. > - If there is no "dr-mode", check phy_ctrl for i.MX6 >and phy_status for i.MX7 > > Signed-off-by: Peng Fan > Cc: Marek Vasut > Cc: Simon Glass > Cc: Stefano Babic > --- > > V2: > Add a ehci_usb_phy_mode function to check phy mode when dr-mode is otg, > or no mode property provided. > > drivers/usb/host/ehci-mx6.c | 75 > + > 1 file changed, 75 insertions(+) > > diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c > index 48889c1..18b7fc3 100644 > --- a/drivers/usb/host/ehci-mx6.c > +++ b/drivers/usb/host/ehci-mx6.c > @@ -15,10 +15,13 @@ > #include > #include > #include > +#include > #include > > #include "ehci.h" > > +DECLARE_GLOBAL_DATA_PTR; > + > #define USB_OTGREGS_OFFSET 0x000 > #define USB_H1REGS_OFFSET0x200 > #define USB_H2REGS_OFFSET0x400 > @@ -48,6 +51,7 @@ > #define ANADIG_USB2_PLL_480_CTRL_EN_USB_CLKS 0x0040 > > #define USBNC_OFFSET 0x200 > +#define USBNC_PHY_STATUS_OFFSET 0x23C > #define USBNC_PHYSTATUS_ID_DIG (1 << 4) /* otg_id status */ > #define USBNC_PHYCFG2_ACAENB (1 << 4) /* otg_id detection enable */ > #define UCTRL_PWR_POL(1 << 9) /* OTG Polarity of Power Pin */ > @@ -417,6 +421,76 @@ static const struct ehci_ops mx6_ehci_ops = { > .init_after_reset = mx6_init_after_reset > }; > > +static int ehci_usb_phy_mode(struct udevice *dev) > +{ > + struct usb_platdata *plat = dev_get_platdata(dev); > + void *__iomem addr = (void *__iomem)dev_get_addr(dev); > + void *__iomem phy_ctrl, *__iomem phy_status; > + const void *blob = gd->fdt_blob; > + int offset = dev->of_offset, phy_off; > + u32 val; > + > + /* > + * About fsl,usbphy, Refer to > + * Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt. > + */ > + if (is_mx6()) { > + phy_off = fdtdec_lookup_phandle(blob, > + offset, > + "fsl,usbphy"); This could be on a single line IMO. > + if (phy_off < 0) > + return -EINVAL; > + > + addr = (void __iomem *)fdtdec_get_addr(blob, phy_off, > +"reg"); Same here, shouldn't be over 80. Otherwise: Acked-by: Marek Vasut > + if ((fdt_addr_t)addr == FDT_ADDR_T_NONE) > + return -EINVAL; > + > + phy_ctrl = (void __iomem *)(addr + USBPHY_CTRL); > + val = readl(phy_ctrl); > + > + if (val & USBPHY_CTRL_OTG_ID) > + plat->init_type = USB_INIT_DEVICE; > + else > + plat->init_type = USB_INIT_HOST; > + } else if (is_mx7()) { > + phy_status = (void __iomem *)(addr + > + USBNC_PHY_STATUS_OFFSET); > + val = readl(phy_status); > + > + if (val & USBNC_PHYSTATUS_ID_DIG) > + plat->init_type = USB_INIT_DEVICE; > + else > + plat->init_type = USB_INIT_HOST; > + } else { > + return -EINVAL; > + } > + > + return 0; > +} > + > +static int ehci_usb_ofdata_to_platdata(struct udevice *dev) > +{ > + struct usb_platdata *plat = dev_get_platdata(dev); > + const char *mode; > + > + mode = fdt_getprop(gd->fdt_blob, dev->of_offset, "dr_mode", NULL); > + if (mode) { > + if (strcmp(mode, "peripheral") == 0) > + plat->init_type = USB_INIT_DEVICE; > + else if (strcmp(mode, "host") == 0) > + plat->init_type = USB_INIT_HOST; > + else if (strcmp(mode, "otg") == 0) > + return ehci_usb_phy_mode(dev); > + else > + return -EINVAL; > + > + return 0; > + } > + > + return ehci_usb_phy_mode(dev); > +} > + > static int ehci_usb_probe(struct udevice *dev) > { > struct usb_platdata *plat = dev_get_platdata(dev); > @@ -460,6 +534,7 @@ U_BOOT_DRIVER(usb_mx6) = { > .name = "ehci_mx6", > .id = UCLASS_USB, > .of_match = mx6_usb_ids, > + .ofdata_to_platdata = ehci_usb_ofdata_to_platdata, > .probe = ehci_usb_probe, > .remove = ehci_deregister, > .ops= &ehci_usb_ops, > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] dm: goni: support the DM PMIC
2016년 12월 22일 (목) 07:03, Jaehoon Chung 님이 작성: > Hi, > > > > On 12/21/2016 11:54 PM, Minkyu Kang wrote: > > > Hi, > > > > > > On 15 December 2016 at 18:21, Jaehoon Chung > wrote: > > > > > >> This patchest is for supporting pmic driver-model on Goni board. > > >> (Goni board is S5PC110.) > > >> > > >> For using that, add the new file as max8998.c for only driver-model. > > >> pmic_max8998.c is remained for legacy. > > >> In future, it might be removed. Instead, max8998 should be used. > > >> > > >> *dm tree > > >> serial [ + ]|-- serial@e2900800 > > >> i2c [ ]`-- i2c-pmic > > >> pmic[ ]`-- pmic@66 > > >> > > >> *dm uclass > > >> uclass 20: i2c > > >> - * i2c-pmic @ 47f6c6d0, seq 3, (req 3) > > >> > > >> uclass 22: i2c_generic > > >> uclass 42: pmic > > >> - * pmic@66 @ 47f6c748, seq 0, (req -1) > > >> > > >> * After using pmic command. > > >> Goni # pmic list > > >> | Name| Parent name | Parent uclass > @ > > >> seq > > >> | pmic@66 | i2c-pmic| i2c @ 3 > > >> > > >> Node, it needs to implement the regulator driver for using regulator > > >> framework. > > >> > > >> Jaehoon Chung (3): > > >> power: pmic: add the max8998 controller for DM > > >> arm: dts: s5pc1xx-goni: add the pmic node for using DM > > >> configs: enable the DM_PMIC and DM_I2C_GPIO for max8998 pmic > > >> > > >> arch/arm/dts/s5pc1xx-goni.dts | 165 ++ > > >> > > >> configs/s5p_goni_defconfig| 3 + > > >> drivers/power/pmic/Kconfig| 7 ++ > > >> drivers/power/pmic/Makefile | 1 + > > >> drivers/power/pmic/max8998.c | 61 > > >> 5 files changed, 237 insertions(+) > > >> create mode 100644 drivers/power/pmic/max8998.c > > >> > > >> -- > > >> 2.10.2 > > >> > > >> ___ > > >> U-Boot mailing list > > >> U-Boot@lists.denx.de > > >> http://lists.denx.de/mailman/listinfo/u-boot > > >> > > > > > > > > > This patchset seems to ready to submit. > > > Who will pick this up? power? DM? or samsang? > > > > Delegated to you (Minkyu), Could you apply on u-boot-samsung? > > There is no Power maintainer, now. > > I sent the patch for updating Power maintainer, but i didn't reply > anything. > > > > Best Regards, > > Jaehoon Chung > > > > > > > > > > > Thanks, > > > > applied to u-boot-samsung > Thanks Minkyu Kang. > > > > -- Thanks. Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 3/3] imx: mx6sllevk: add usb support
Add usb support for mx6sllevk board. Signed-off-by: Peng Fan Cc: Stefano Babic --- V2: Drop the polarity setting and CONFIG_USB_MAX_CONTROLLER_COUNT configs/mx6sllevk_defconfig| 5 + configs/mx6sllevk_plugin_defconfig | 5 + include/configs/mx6sllevk.h| 8 3 files changed, 18 insertions(+) diff --git a/configs/mx6sllevk_defconfig b/configs/mx6sllevk_defconfig index 8ae049e..267cdc6 100644 --- a/configs/mx6sllevk_defconfig +++ b/configs/mx6sllevk_defconfig @@ -10,6 +10,7 @@ CONFIG_CMD_BOOTZ=y CONFIG_CMD_MEMTEST=y CONFIG_CMD_MMC=y CONFIG_CMD_I2C=y +CONFIG_CMD_USB=y CONFIG_CMD_GPIO=y CONFIG_CMD_DHCP=y CONFIG_CMD_PING=y @@ -34,3 +35,7 @@ CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_PFUZE100=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y +CONFIG_USB=y +CONFIG_DM_USB=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_STORAGE=y diff --git a/configs/mx6sllevk_plugin_defconfig b/configs/mx6sllevk_plugin_defconfig index e6be979..63d5bbc 100644 --- a/configs/mx6sllevk_plugin_defconfig +++ b/configs/mx6sllevk_plugin_defconfig @@ -11,6 +11,7 @@ CONFIG_CMD_BOOTZ=y CONFIG_CMD_MEMTEST=y CONFIG_CMD_MMC=y CONFIG_CMD_I2C=y +CONFIG_CMD_USB=y CONFIG_CMD_GPIO=y CONFIG_CMD_DHCP=y CONFIG_CMD_PING=y @@ -35,3 +36,7 @@ CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_PFUZE100=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y +CONFIG_USB=y +CONFIG_DM_USB=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_STORAGE=y diff --git a/include/configs/mx6sllevk.h b/include/configs/mx6sllevk.h index b9f25cf..be4d147 100644 --- a/include/configs/mx6sllevk.h +++ b/include/configs/mx6sllevk.h @@ -149,4 +149,12 @@ #define CONFIG_IOMUX_LPSR +/* USB Configs */ +#ifdef CONFIG_CMD_USB +#define CONFIG_USB_HOST_ETHER +#define CONFIG_USB_ETHER_ASIX +#define CONFIG_USB_ETHER_RTL8152 +#define CONFIG_MXC_USB_PORTSC (PORT_PTS_UTMI | PORT_PTS_PTW) +#endif + #endif /* __CONFIG_H */ -- 2.6.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] imx: mx6sllevk: add usb support
> -Original Message- > From: Marek Vasut [mailto:ma...@denx.de] > Sent: Thursday, December 22, 2016 3:12 PM > To: Peng Fan ; sba...@denx.de > Cc: u-boot@lists.denx.de; van.free...@gmail.com > Subject: Re: [PATCH 3/3] imx: mx6sllevk: add usb support > > On 12/22/2016 07:38 AM, Peng Fan wrote: > > > > > >> -Original Message- > >> From: Marek Vasut [mailto:ma...@denx.de] > >> Sent: Thursday, December 22, 2016 2:12 PM > >> To: Peng Fan ; sba...@denx.de > >> Cc: u-boot@lists.denx.de; van.free...@gmail.com > >> Subject: Re: [PATCH 3/3] imx: mx6sllevk: add usb support > >> > >> On 12/22/2016 07:03 AM, Peng Fan wrote: > >>> > >>> Hi Marek, > >>> > -Original Message- > From: Marek Vasut [mailto:ma...@denx.de] > Sent: Thursday, December 22, 2016 12:40 PM > To: Peng Fan ; sba...@denx.de > Cc: u-boot@lists.denx.de; van.free...@gmail.com > Subject: Re: [PATCH 3/3] imx: mx6sllevk: add usb support > > On 12/22/2016 02:13 AM, Peng Fan wrote: > > > > > >> -Original Message- > >> From: Marek Vasut [mailto:ma...@denx.de] > >> Sent: Wednesday, December 21, 2016 10:10 PM > >> To: Peng Fan ; sba...@denx.de > >> Cc: u-boot@lists.denx.de; van.free...@gmail.com > >> Subject: Re: [PATCH 3/3] imx: mx6sllevk: add usb support > >> > >> On 12/21/2016 09:14 AM, Peng Fan wrote: > >>> Add usb support for mx6sllevk board. > >>> > >>> Signed-off-by: Peng Fan > >>> Cc: Stefano Babic > >>> --- > > [..] > > > >>> + > >>> +#define USB_OTHERREGS_OFFSET 0x800 > >>> +#define UCTRL_PWR_POL (1 << 9) > >>> + > >>> +int board_ehci_hcd_init(int port) { > >>> + u32 *usbnc_usb_ctrl; > >>> + > >>> + if (port > 1) > >>> + return -EINVAL; > >>> + > >>> + usbnc_usb_ctrl = (u32 *)(USB_BASE_ADDR + > >> USB_OTHERREGS_OFFSET > >> + > >>> + port * 4); > >>> + > >>> + /* Set Power polarity */ > >>> + setbits_le32(usbnc_usb_ctrl, UCTRL_PWR_POL); > >>> + return 0; > >>> +} > >> > >> Is this function similar to what usb_oc_config() does ? > > > > No, this bit is not for overcurrent. According to RM, this is OTG > > Power Polarity This bit should be set according to power switch's > > enable > polarity. > > 1 Power switch has an active-high enable input > > 0 Power switch has an active-low enable input > > > > This is board specific. > > Great, except it should also be part of the driver , the same way > as polarity is configured, yes ? > >>> > >>> I just found that there is code for mx7, > >>> http://lists.denx.de/pipermail/u-boot/2016-July/260321.html > >>> > >>> Then do you agree I add such piece code in usb_power_config for mx6? > >>> " > >>> #ifdef CONFIG_MXC_USB_OTG_HACTIVE > >>> setbits_le32(ctrl, UCTRL_PWR_POL); #else > >>> clrbits_le32(ctrl, UCTRL_PWR_POL); #endif " > >> > >> Didn't you add DT support in a patch sent like ... yesterday ? :) > >> Just use DT property instead of ifdef. > > > > There is no property for otg power polatiry in upstream Linux. I would > > not like to introduce one in U-Boot. We can drop the ifdef when there is an > property in upstream. What do you think? > > So uh, how can the USB work in mainline Linux on that board ? Confirmed with IC, if using gpio to control vbus power, no need to configure this bit. Since in dts, we are using gpio regulator to control vbus, this piece code in patch 3/3 can be discarded. I'll drop it in V2. Thanks, Peng. > > -- > Best regards, > Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] Re: Problems to Allwinner H3's eFUSE/SID
On Tue, Dec 20, 2016 at 12:17 AM, Hans de Goede wrote: > Hi, > > > On 19-12-16 17:06, Icenowy Zheng wrote: >> >> >> >> 19.12.2016, 23:30, "Hans de Goede" : >>> >>> Hi, >>> >>> On 19-12-16 16:22, Icenowy Zheng wrote: Hi everyone, Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID controller of H3 (incl. H2+). See https://irclog.whitequark.org/linux-sunxi/2016-12-19 . Two read method of the H3 eFUSE is used in the BSP: by register accessing, or directly access 0x01c14200. From http://linux-sunxi.org/SID_Register_Guide we can see a difference between the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in legacy kernel). According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3, 0x58 is H3D (currently not known SoC) ) However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start with 0x02004620, which do not match this rule. The readout by devmem2 is satisfying this rule: their first word is 0x02c00081, matches H3. Then I found the SID-reading code from BSP U-Boot[2], which is based on register operations. With this kind of code (I wrote one prototype in userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on my Orange Pi One. ("02004620 74358720 5027048e 3cc3" with sunxi-fel sid) And, after accessing to the SID by registers, the value of *0x01c14200 become also "02c00081". With direct access to 0x01c14200 after boot with mainline kernel, I got also "02004620". Then I altered the program to do the register operations with sunxi-fel, the result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081". Summary: +---++ | Read situation | The first word | +---++ | Direct read by sunxi-fel | 02004620 | | Direct read in mainline /dev/mem | 02004620 | | Direct read in legacy /dev/mem | 02c00081 | | Register access in FEL | 02c00081 | | Register access in mainline | 02c00081 | | Direct read after register access in FEL | 02c00081 | | Direct read after register access in mainline | 02c00081 | +---++ According to some facts: - The register based access to SID is weird: it needs ~5 register operations per word of SID. - Reading via register access will change the value when reading by accessing 0x01c14200. - In the u-boot code[2] there's some functions which read out the SID by registers and then abandoned the value. - This mismatch do not exist on A64. I think that: Allwinner designed a "cache" to the SID to make the simplify the code to read it, and it automatically loaded the cache when booting; however, when doing first cache on H3, some byte shifts occured, and the value become wrong. A manual read on H3 can make the cache right again. This is a silicon bug, and fixed in A64. This raises a problem: currently many systems has used the misread SID value to generated lots of MAC addresses, and workaround this SID bug will change them. However, if this bug is not workarounded, the sun8i-ths driver won't work well (as some calibartion value lies in eFUSE). I think some early user of this driver has already experienced bad readout value. (The calibration value differs on my opi1 and KotCzarny's opipc) And many wrong SID values have been generated by `sunxi-fel sid`. (Although I think sunxi-fel must have the workaround) Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64 at 0x01c14000, which is a OTP memory implemented by eFUSE technique. Furthermore, A83T may also have this problem, testers are welcome! [1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c [2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c Experiments: - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9 A SID readout shell script via FEL with register access. - https://31.135.195.151:20281/d/efuse/ A SID readout program via /dev/mem with register access by KotCzarny. (with statically compiled binary) >>> >>> >>> Good detective work! >>> >>> I believe this would best be fixed by making u-boot use th
Re: [U-Boot] [linux-sunxi] Re: Problems to Allwinner H3's eFUSE/SID
Hi, On 22-12-16 11:31, Chen-Yu Tsai wrote: On Tue, Dec 20, 2016 at 12:17 AM, Hans de Goede wrote: Hi, On 19-12-16 17:06, Icenowy Zheng wrote: 19.12.2016, 23:30, "Hans de Goede" : Hi, On 19-12-16 16:22, Icenowy Zheng wrote: Hi everyone, Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID controller of H3 (incl. H2+). See https://irclog.whitequark.org/linux-sunxi/2016-12-19 . Two read method of the H3 eFUSE is used in the BSP: by register accessing, or directly access 0x01c14200. From http://linux-sunxi.org/SID_Register_Guide we can see a difference between the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in legacy kernel). According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3, 0x58 is H3D (currently not known SoC) ) However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start with 0x02004620, which do not match this rule. The readout by devmem2 is satisfying this rule: their first word is 0x02c00081, matches H3. Then I found the SID-reading code from BSP U-Boot[2], which is based on register operations. With this kind of code (I wrote one prototype in userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on my Orange Pi One. ("02004620 74358720 5027048e 3cc3" with sunxi-fel sid) And, after accessing to the SID by registers, the value of *0x01c14200 become also "02c00081". With direct access to 0x01c14200 after boot with mainline kernel, I got also "02004620". Then I altered the program to do the register operations with sunxi-fel, the result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081". Summary: +---++ | Read situation | The first word | +---++ | Direct read by sunxi-fel | 02004620 | | Direct read in mainline /dev/mem | 02004620 | | Direct read in legacy /dev/mem | 02c00081 | | Register access in FEL | 02c00081 | | Register access in mainline | 02c00081 | | Direct read after register access in FEL | 02c00081 | | Direct read after register access in mainline | 02c00081 | +---++ According to some facts: - The register based access to SID is weird: it needs ~5 register operations per word of SID. - Reading via register access will change the value when reading by accessing 0x01c14200. - In the u-boot code[2] there's some functions which read out the SID by registers and then abandoned the value. - This mismatch do not exist on A64. I think that: Allwinner designed a "cache" to the SID to make the simplify the code to read it, and it automatically loaded the cache when booting; however, when doing first cache on H3, some byte shifts occured, and the value become wrong. A manual read on H3 can make the cache right again. This is a silicon bug, and fixed in A64. This raises a problem: currently many systems has used the misread SID value to generated lots of MAC addresses, and workaround this SID bug will change them. However, if this bug is not workarounded, the sun8i-ths driver won't work well (as some calibartion value lies in eFUSE). I think some early user of this driver has already experienced bad readout value. (The calibration value differs on my opi1 and KotCzarny's opipc) And many wrong SID values have been generated by `sunxi-fel sid`. (Although I think sunxi-fel must have the workaround) Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64 at 0x01c14000, which is a OTP memory implemented by eFUSE technique. Furthermore, A83T may also have this problem, testers are welcome! [1] http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c [2] http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c Experiments: - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9 A SID readout shell script via FEL with register access. - https://31.135.195.151:20281/d/efuse/ A SID readout program via /dev/mem with register access by KotCzarny. (with statically compiled binary) Good detective work! I believe this would best be fixed by making u-boot use the register access method to get the SID on affected chips, and make sure u-boot reads the SID at-least once. Yes. However, what I considered is that fixing this bug will change H3 devices' MAC addresses, as they are derived from SID. I know, but I think we will just need to accept this onetime change of the fixed MAC addresses to fix this bug. I don't think this is a big problem since the driver for the H3 ethernet has not been merged into the mainline kernel yet. Do we still need to do the CRC32 across the SID values to generate the MAC addresses?
[U-Boot] [PATCH V2 1/3] usb: ehci-mx6: implement ofdata_to_platdata
Implement ofdata_to_platdata to set the type to host or device. - Check "dr-mode" property. - If there is no "dr-mode", check phy_ctrl for i.MX6 and phy_status for i.MX7 Signed-off-by: Peng Fan Cc: Marek Vasut Cc: Simon Glass Cc: Stefano Babic --- V2: Add a ehci_usb_phy_mode function to check phy mode when dr-mode is otg, or no mode property provided. drivers/usb/host/ehci-mx6.c | 75 + 1 file changed, 75 insertions(+) diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c index 48889c1..18b7fc3 100644 --- a/drivers/usb/host/ehci-mx6.c +++ b/drivers/usb/host/ehci-mx6.c @@ -15,10 +15,13 @@ #include #include #include +#include #include #include "ehci.h" +DECLARE_GLOBAL_DATA_PTR; + #define USB_OTGREGS_OFFSET 0x000 #define USB_H1REGS_OFFSET 0x200 #define USB_H2REGS_OFFSET 0x400 @@ -48,6 +51,7 @@ #define ANADIG_USB2_PLL_480_CTRL_EN_USB_CLKS 0x0040 #define USBNC_OFFSET 0x200 +#define USBNC_PHY_STATUS_OFFSET0x23C #define USBNC_PHYSTATUS_ID_DIG (1 << 4) /* otg_id status */ #define USBNC_PHYCFG2_ACAENB (1 << 4) /* otg_id detection enable */ #define UCTRL_PWR_POL (1 << 9) /* OTG Polarity of Power Pin */ @@ -417,6 +421,76 @@ static const struct ehci_ops mx6_ehci_ops = { .init_after_reset = mx6_init_after_reset }; +static int ehci_usb_phy_mode(struct udevice *dev) +{ + struct usb_platdata *plat = dev_get_platdata(dev); + void *__iomem addr = (void *__iomem)dev_get_addr(dev); + void *__iomem phy_ctrl, *__iomem phy_status; + const void *blob = gd->fdt_blob; + int offset = dev->of_offset, phy_off; + u32 val; + + /* +* About fsl,usbphy, Refer to +* Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt. +*/ + if (is_mx6()) { + phy_off = fdtdec_lookup_phandle(blob, + offset, + "fsl,usbphy"); + if (phy_off < 0) + return -EINVAL; + + addr = (void __iomem *)fdtdec_get_addr(blob, phy_off, + "reg"); + if ((fdt_addr_t)addr == FDT_ADDR_T_NONE) + return -EINVAL; + + phy_ctrl = (void __iomem *)(addr + USBPHY_CTRL); + val = readl(phy_ctrl); + + if (val & USBPHY_CTRL_OTG_ID) + plat->init_type = USB_INIT_DEVICE; + else + plat->init_type = USB_INIT_HOST; + } else if (is_mx7()) { + phy_status = (void __iomem *)(addr + + USBNC_PHY_STATUS_OFFSET); + val = readl(phy_status); + + if (val & USBNC_PHYSTATUS_ID_DIG) + plat->init_type = USB_INIT_DEVICE; + else + plat->init_type = USB_INIT_HOST; + } else { + return -EINVAL; + } + + return 0; +} + +static int ehci_usb_ofdata_to_platdata(struct udevice *dev) +{ + struct usb_platdata *plat = dev_get_platdata(dev); + const char *mode; + + mode = fdt_getprop(gd->fdt_blob, dev->of_offset, "dr_mode", NULL); + if (mode) { + if (strcmp(mode, "peripheral") == 0) + plat->init_type = USB_INIT_DEVICE; + else if (strcmp(mode, "host") == 0) + plat->init_type = USB_INIT_HOST; + else if (strcmp(mode, "otg") == 0) + return ehci_usb_phy_mode(dev); + else + return -EINVAL; + + return 0; + } + + return ehci_usb_phy_mode(dev); +} + static int ehci_usb_probe(struct udevice *dev) { struct usb_platdata *plat = dev_get_platdata(dev); @@ -460,6 +534,7 @@ U_BOOT_DRIVER(usb_mx6) = { .name = "ehci_mx6", .id = UCLASS_USB, .of_match = mx6_usb_ids, + .ofdata_to_platdata = ehci_usb_ofdata_to_platdata, .probe = ehci_usb_probe, .remove = ehci_deregister, .ops= &ehci_usb_ops, -- 2.6.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] imx: mx6sllevk: add usb support
> > +#define USB_OTHERREGS_OFFSET 0x800 > > +#define UCTRL_PWR_POL (1 << 9) > > + > > +int board_ehci_hcd_init(int port) { > > + u32 *usbnc_usb_ctrl; > > + > > + if (port > 1) > > + return -EINVAL; > > + > > + usbnc_usb_ctrl = (u32 *)(USB_BASE_ADDR + > USB_OTHERREGS_OFFSET > + > > +port * 4); > > + > > + /* Set Power polarity */ > > + setbits_le32(usbnc_usb_ctrl, UCTRL_PWR_POL); > > + return 0; > > +} > > Is this function similar to what usb_oc_config() does ? > >>> > >>> No, this bit is not for overcurrent. According to RM, this is > >>> OTG Power Polarity This bit should be set according to power > >>> switch's enable > >> polarity. > >>> 1 Power switch has an active-high enable input > >>> 0 Power switch has an active-low enable input > >>> > >>> This is board specific. > >> > >> Great, except it should also be part of the driver , the same way > >> as polarity is configured, yes ? > > > > I just found that there is code for mx7, > > http://lists.denx.de/pipermail/u-boot/2016-July/260321.html > > > > Then do you agree I add such piece code in usb_power_config for mx6? > > " > > #ifdef CONFIG_MXC_USB_OTG_HACTIVE > > setbits_le32(ctrl, UCTRL_PWR_POL); #else > > clrbits_le32(ctrl, UCTRL_PWR_POL); #endif " > > Didn't you add DT support in a patch sent like ... yesterday ? :) > Just use DT property instead of ifdef. > >>> > >>> There is no property for otg power polatiry in upstream Linux. I > >>> would not like to introduce one in U-Boot. We can drop the ifdef > >>> when there is an > >> property in upstream. What do you think? > >> > >> So uh, how can the USB work in mainline Linux on that board ? > > > > Confirmed with IC, if using gpio to control vbus power, no need to configure > this bit. > > Since in dts, we are using gpio regulator to control vbus, this piece > > code in patch 3/3 can be discarded. I'll drop it in V2. > > Hum, OK. Let's revisit this when we need this then ? Take i.MX6SLL as an example, The pin key_col4 can be configured with the two functions. [1] MX6_PAD_KEY_COL4__USB_OTG1_PWR [2] MX6_PAD_KEY_COL4__GPIO4_IO00 In fsl i.mx uboot code, the common way is to use [1] and configure the polarity to enable the vbus power. But in kernel, it is configured as [2] and use gpio regulator to enable the vbus power. This is board specific. There is no upstream property for this bit. When there is an upstream property for this, We could add it in probe function for those that use [1] in dts pinmux. Now I am using the same dts from kernel which this pinmux configured as [2], so this piece code is not needed for now. Thanks, Peng. > > -- > Best regards, > Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/3] usb: ehci-mx6: handle vbus-supply
Drop board_ehci_power when dm usb used and switch to use regulator api to handle vbus. Signed-off-by: Peng Fan Cc: Marek Vasut Cc: Simon Glass Cc: Stefano Babic --- V2: None drivers/usb/host/ehci-mx6.c | 30 +++--- 1 file changed, 27 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c index 18b7fc3..7b309b7 100644 --- a/drivers/usb/host/ehci-mx6.c +++ b/drivers/usb/host/ehci-mx6.c @@ -17,6 +17,7 @@ #include #include #include +#include #include "ehci.h" @@ -388,6 +389,7 @@ int ehci_hcd_stop(int index) struct ehci_mx6_priv_data { struct ehci_ctrl ctrl; struct usb_ehci *ehci; + struct udevice *vbus_supply; enum usb_init_type init_type; int portnr; }; @@ -403,7 +405,15 @@ static int mx6_init_after_reset(struct ehci_ctrl *dev) if (ret) return ret; - board_ehci_power(priv->portnr, (type == USB_INIT_DEVICE) ? 0 : 1); + if (priv->vbus_supply) { + ret = regulator_set_enable(priv->vbus_supply, + (type == USB_INIT_DEVICE) ? + false : true); + if (ret) { + puts("Error enabling VBUS supply\n"); + return ret; + } + } if (type == USB_INIT_DEVICE) return 0; @@ -496,19 +506,33 @@ static int ehci_usb_probe(struct udevice *dev) struct usb_platdata *plat = dev_get_platdata(dev); struct usb_ehci *ehci = (struct usb_ehci *)dev_get_addr(dev); struct ehci_mx6_priv_data *priv = dev_get_priv(dev); + enum usb_init_type type = plat->init_type; struct ehci_hccr *hccr; struct ehci_hcor *hcor; int ret; priv->ehci = ehci; priv->portnr = dev->seq; - priv->init_type = plat->init_type; + priv->init_type = type; + + ret = device_get_supply_regulator(dev, "vbus-supply", + &priv->vbus_supply); + if (ret) + debug("%s: No vbus supply\n", dev->name); ret = ehci_mx6_common_init(ehci, priv->portnr); if (ret) return ret; - board_ehci_power(priv->portnr, (priv->init_type == USB_INIT_DEVICE) ? 0 : 1); + if (priv->vbus_supply) { + ret = regulator_set_enable(priv->vbus_supply, + (type == USB_INIT_DEVICE) ? + false : true); + if (ret) { + puts("Error enabling VBUS supply\n"); + return ret; + } + } if (priv->init_type == USB_INIT_HOST) { setbits_le32(&ehci->usbmode, CM_HOST); -- 2.6.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] i2c: cdns: Add additional compatible string for r1p14 of the IP.
Adding additional compatible string for version 1.4 of the IP block. Signed-off-by: Moritz Fischer Cc: Michal Simek Cc: Heiko Schocher --- drivers/i2c/i2c-cdns.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/i2c/i2c-cdns.c b/drivers/i2c/i2c-cdns.c index f49f60b..ef85a70 100644 --- a/drivers/i2c/i2c-cdns.c +++ b/drivers/i2c/i2c-cdns.c @@ -366,6 +366,7 @@ static const struct dm_i2c_ops cdns_i2c_ops = { static const struct udevice_id cdns_i2c_of_match[] = { { .compatible = "cdns,i2c-r1p10" }, + { .compatible = "cdns,i2c-r1p14" }, { /* end of table */ } }; -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM64: zynqmp: Fix i2c node's compatible string
The Zynq Ultrascale MP uses version 1.4 of the Cadence IP core which fixes some silicon bugs that needed software workarounds in Version 1.0 that was used on Zynq systems. Signed-off-by: Moritz Fischer Cc: Michal Simek Cc: Heiko Schocher --- arch/arm/dts/zynqmp.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi index ab5c243..20c5efc 100644 --- a/arch/arm/dts/zynqmp.dtsi +++ b/arch/arm/dts/zynqmp.dtsi @@ -619,7 +619,7 @@ }; i2c0: i2c@ff02 { - compatible = "cdns,i2c-r1p10"; + compatible = "cdns,i2c-r1p14", "cdns,i2c-r1p10"; status = "disabled"; interrupt-parent = <&gic>; interrupts = <0 17 4>; @@ -630,7 +630,7 @@ }; i2c1: i2c@ff03 { - compatible = "cdns,i2c-r1p10"; + compatible = "cdns,i2c-r1p14", "cdns,i2c-r1p10"; status = "disabled"; interrupt-parent = <&gic>; interrupts = <0 18 4>; -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] imx: mx6sllevk: add usb support
Hi Marek, > -Original Message- > From: Marek Vasut [mailto:ma...@denx.de] > Sent: Thursday, December 22, 2016 4:58 PM > To: Peng Fan ; sba...@denx.de > Cc: u-boot@lists.denx.de; van.free...@gmail.com > Subject: Re: [PATCH 3/3] imx: mx6sllevk: add usb support > > On 12/22/2016 09:55 AM, Peng Fan wrote: > > > > > >>> +#define USB_OTHERREGS_OFFSET 0x800 > >>> +#define UCTRL_PWR_POL (1 << 9) > >>> + > >>> +int board_ehci_hcd_init(int port) { > >>> + u32 *usbnc_usb_ctrl; > >>> + > >>> + if (port > 1) > >>> + return -EINVAL; > >>> + > >>> + usbnc_usb_ctrl = (u32 *)(USB_BASE_ADDR + > >> USB_OTHERREGS_OFFSET > >> + > >>> + port * 4); > >>> + > >>> + /* Set Power polarity */ > >>> + setbits_le32(usbnc_usb_ctrl, UCTRL_PWR_POL); > >>> + return 0; > >>> +} > >> > >> Is this function similar to what usb_oc_config() does ? > > > > No, this bit is not for overcurrent. According to RM, this is > > OTG Power Polarity This bit should be set according to power > > switch's enable > polarity. > > 1 Power switch has an active-high enable input > > 0 Power switch has an active-low enable input > > > > This is board specific. > > Great, except it should also be part of the driver , the same > way as polarity is configured, yes ? > >>> > >>> I just found that there is code for mx7, > >>> http://lists.denx.de/pipermail/u-boot/2016-July/260321.html > >>> > >>> Then do you agree I add such piece code in usb_power_config for > mx6? > >>> " > >>> #ifdef CONFIG_MXC_USB_OTG_HACTIVE > >>> setbits_le32(ctrl, UCTRL_PWR_POL); #else > >>> clrbits_le32(ctrl, UCTRL_PWR_POL); #endif " > >> > >> Didn't you add DT support in a patch sent like ... yesterday ? :) > >> Just use DT property instead of ifdef. > > > > There is no property for otg power polatiry in upstream Linux. I > > would not like to introduce one in U-Boot. We can drop the ifdef > > when there is an > property in upstream. What do you think? > > So uh, how can the USB work in mainline Linux on that board ? > >>> > >>> Confirmed with IC, if using gpio to control vbus power, no need to > >>> configure > >> this bit. > >>> Since in dts, we are using gpio regulator to control vbus, this > >>> piece code in patch 3/3 can be discarded. I'll drop it in V2. > >> > >> Hum, OK. Let's revisit this when we need this then ? > > > > Take i.MX6SLL as an example, > > The pin key_col4 can be configured with the two functions. > > [1] MX6_PAD_KEY_COL4__USB_OTG1_PWR > > [2] MX6_PAD_KEY_COL4__GPIO4_IO00 > > > > In fsl i.mx uboot code, the common way is to use [1] and configure the > polarity to enable the vbus power. > > But in kernel, it is configured as [2] and use gpio regulator to enable the > > vbus > power. > > > > This is board specific. There is no upstream property for this bit. > > When there is an upstream property for this, We could add it in probe > function for those that use [1] in dts pinmux. > > > > Now I am using the same dts from kernel which this pinmux configured as [2], > so this piece code is not needed for now. > > Well, can you submit a proposal with the new prop for devicetree@ ? > It can then be improved in linux too ... I'll talk with our internal Linux usb maintainer to see whether he has plan to do this. Thanks, Peng. > > -- > Best regards, > Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] spl: move RAM boot support in separate file
From: Stefan Agner Add a new top-level config option so support booting an image stored in RAM. This allows to move the RAM boot support into a sparate file and having a single condition to compile that file. Signed-off-by: Stefan Agner --- The series has been build tested using buildman. $ ./tools/buildman/buildman ... Building current source for 1245 boards (8 threads, 1 job per thread) 10340 211 /1245 0:00:03 : P1022DS_NAND -- Stefan Changes in v3: - Use default y in ... Changes in v2: - Added missing new file spl_ram.c - Add new config also to defconfig file common/spl/Kconfig | 12 +++-- common/spl/Makefile | 1 + common/spl/spl.c | 58 - common/spl/spl_ram.c | 73 4 files changed, 84 insertions(+), 60 deletions(-) create mode 100644 common/spl/spl_ram.c diff --git a/common/spl/Kconfig b/common/spl/Kconfig index ea084f462b..b1aa1483c9 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -449,9 +449,17 @@ config SPL_POWER_SUPPORT in drivers/power, drivers/power/pmic and drivers/power/regulator as part of an SPL build. +config SPL_RAM_SUPPORT + bool "Support booting from RAM" + depends on SPL + default y if MICROBLAZE || ARCH_SOCFPGA || TEGRA || ARCH_ZYNQ + help + Enable booting of an image in RAM. The image can be preloaded or + it can be loaded by SPL directly into RAM (e.g. using USB). + config SPL_RAM_DEVICE bool "Support booting from preloaded image in RAM" - depends on SPL + depends on SPL_RAM_SUPPORT default y if MICROBLAZE || ARCH_SOCFPGA || TEGRA || ARCH_ZYNQ help Enable booting of an image already loaded in RAM. The image has to @@ -558,7 +566,7 @@ choice config SPL_DFU_RAM bool "RAM device" - depends on SPL_DFU_SUPPORT + depends on SPL_DFU_SUPPORT && SPL_RAM_SUPPORT help select RAM/DDR memory device for loading binary images (u-boot/kernel) to the selected device partition using diff --git a/common/spl/Makefile b/common/spl/Makefile index ed02635e72..1933cbdfed 100644 --- a/common/spl/Makefile +++ b/common/spl/Makefile @@ -26,4 +26,5 @@ obj-$(CONFIG_SPL_EXT_SUPPORT) += spl_ext.o obj-$(CONFIG_SPL_SATA_SUPPORT) += spl_sata.o obj-$(CONFIG_SPL_DFU_SUPPORT) += spl_dfu.o obj-$(CONFIG_SPL_SPI_LOAD) += spl_spi.o +obj-$(CONFIG_SPL_RAM_SUPPORT) += spl_ram.o endif diff --git a/common/spl/spl.c b/common/spl/spl.c index f7df834e32..2f3b6a47f8 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -170,64 +170,6 @@ __weak void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image) image_entry(); } -#ifndef CONFIG_SPL_LOAD_FIT_ADDRESS -# define CONFIG_SPL_LOAD_FIT_ADDRESS 0 -#endif - -#if defined(CONFIG_SPL_RAM_DEVICE) || defined(CONFIG_SPL_DFU_SUPPORT) -static ulong spl_ram_load_read(struct spl_load_info *load, ulong sector, - ulong count, void *buf) -{ - debug("%s: sector %lx, count %lx, buf %lx\n", - __func__, sector, count, (ulong)buf); - memcpy(buf, (void *)(CONFIG_SPL_LOAD_FIT_ADDRESS + sector), count); - return count; -} - -static int spl_ram_load_image(struct spl_image_info *spl_image, - struct spl_boot_device *bootdev) -{ - struct image_header *header; - - header = (struct image_header *)CONFIG_SPL_LOAD_FIT_ADDRESS; - -#if defined(CONFIG_SPL_DFU_SUPPORT) - if (bootdev->boot_device == BOOT_DEVICE_DFU) - spl_dfu_cmd(0, "dfu_alt_info_ram", "ram", "0"); -#endif - - if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) && - image_get_magic(header) == FDT_MAGIC) { - struct spl_load_info load; - - debug("Found FIT\n"); - load.bl_len = 1; - load.read = spl_ram_load_read; - spl_load_simple_fit(spl_image, &load, 0, header); - } else { - debug("Legacy image\n"); - /* -* Get the header. It will point to an address defined by -* handoff which will tell where the image located inside -* the flash. For now, it will temporary fixed to address -* pointed by U-Boot. -*/ - header = (struct image_header *) - (CONFIG_SYS_TEXT_BASE - sizeof(struct image_header)); - - spl_parse_image_header(spl_image, header); - } - - return 0; -} -#if defined(CONFIG_SPL_RAM_DEVICE) -SPL_LOAD_IMAGE_METHOD("RAM", 0, BOOT_DEVICE_RAM, spl_ram_load_image); -#endif -#if defined(CONFIG_SPL_DFU_SUPPORT) -SPL_LOAD_IMAGE_METHOD("USB DFU", 0, BOOT_DEVICE_DFU, spl_ram_load_image); -#endif -#endif - int spl_init(void) { int ret; diff --git a/common/spl/spl_ram.c b/common/spl/spl_ram.c new file mode 100644 index 00..b2645a1948 --- /dev/null +++ b/common/spl/sp
[U-Boot] [PATCH v3 1/2] Convert CONFIG_SPL_RAM_DEVICE to defconfig
From: Stefan Agner This converts the following to Kconfig: CONFIG_SPL_RAM_DEVICE Signed-off-by: Stefan Agner --- Changes in v3: None Changes in v2: None common/spl/Kconfig | 9 + include/configs/microblaze-generic.h | 1 - include/configs/socfpga_common.h | 1 - include/configs/tegra-common.h | 1 - include/configs/xilinx_zynqmp.h | 1 - include/configs/zynq-common.h| 1 - 6 files changed, 9 insertions(+), 5 deletions(-) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index cba51f5df6..ea084f462b 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -449,6 +449,15 @@ config SPL_POWER_SUPPORT in drivers/power, drivers/power/pmic and drivers/power/regulator as part of an SPL build. +config SPL_RAM_DEVICE + bool "Support booting from preloaded image in RAM" + depends on SPL + default y if MICROBLAZE || ARCH_SOCFPGA || TEGRA || ARCH_ZYNQ + help + Enable booting of an image already loaded in RAM. The image has to + be already in memory when SPL takes over, e.g. loaded by the boot + ROM. + config SPL_SATA_SUPPORT bool "Support loading from SATA" depends on SPL diff --git a/include/configs/microblaze-generic.h b/include/configs/microblaze-generic.h index 7abffdb2ef..cc90b73fa1 100644 --- a/include/configs/microblaze-generic.h +++ b/include/configs/microblaze-generic.h @@ -284,7 +284,6 @@ #define CONFIG_SPL_LDSCRIPT"arch/microblaze/cpu/u-boot-spl.lds" -#define CONFIG_SPL_RAM_DEVICE #ifdef CONFIG_SYS_FLASH_BASE # define CONFIG_SYS_UBOOT_BASE CONFIG_SYS_FLASH_BASE #endif diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index 58a6550844..7292469433 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -309,7 +309,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void); * 0x_FF00 .. End of SRAM */ #define CONFIG_SPL_FRAMEWORK -#define CONFIG_SPL_RAM_DEVICE #define CONFIG_SPL_TEXT_BASE CONFIG_SYS_INIT_RAM_ADDR #define CONFIG_SPL_MAX_SIZE(64 * 1024) diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h index 23a0e782e0..f30fec84a2 100644 --- a/include/configs/tegra-common.h +++ b/include/configs/tegra-common.h @@ -98,7 +98,6 @@ /* Defines for SPL */ #define CONFIG_SPL_FRAMEWORK -#define CONFIG_SPL_RAM_DEVICE #define CONFIG_SPL_BOARD_INIT #define CONFIG_SPL_NAND_SIMPLE #define CONFIG_SPL_MAX_FOOTPRINT (CONFIG_SYS_TEXT_BASE - \ diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h index fb4f6d6806..8845ff425d 100644 --- a/include/configs/xilinx_zynqmp.h +++ b/include/configs/xilinx_zynqmp.h @@ -260,7 +260,6 @@ #define CONFIG_SPL_FRAMEWORK #define CONFIG_SPL_BOARD_INIT -#define CONFIG_SPL_RAM_DEVICE /* u-boot is like dtb */ #define CONFIG_SPL_FS_LOAD_ARGS_NAME "u-boot.bin" diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h index 953e7311a6..e04be5c18c 100644 --- a/include/configs/zynq-common.h +++ b/include/configs/zynq-common.h @@ -296,7 +296,6 @@ #define CONFIG_CMD_SPL #define CONFIG_SPL_FRAMEWORK #define CONFIG_SPL_BOARD_INIT -#define CONFIG_SPL_RAM_DEVICE #define CONFIG_SPL_LDSCRIPT"arch/arm/mach-zynq/u-boot-spl.lds" -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot