June 2017 - U-Boot

[U-Boot] [PATCH v2 06/10] configs: rk3328: enable dwc2 driver and config for fastboot
by Meng Dongyang 05 Jun '17

05 Jun '17

Config dwc2 driver support host and gadget function. Add support of fastboot function. Signed-off-by: Meng Dongyang <daniel.meng(a)rock-chips.com> Reviewed-by: Simon Glass <sjg(a)chromium.org> --- Changes in v2: None configs/evb-rk3328_defconfig | 14 ++++++++++++++ include/configs/rk3328_common.h | 3 +++ 2 files changed, 17 insertions(+) diff --git a/configs/evb-rk3328_defconfig b/configs/evb-rk3328_defconfig index 57aee02..833bffc 100644 --- a/configs/evb-rk3328_defconfig +++ b/configs/evb-rk3328_defconfig @@ -42,3 +42,17 @@ CONFIG_USB_OHCI_GENERIC=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_RK=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_DOWNLOAD=y +CONFIG_USB_GADGET_DUALSPEED=y +CONFIG_USB_GADGET_DWC2_OTG=y +CONFIG_USB_FUNCTION_FASTBOOT=y +CONFIG_G_DNL_MANUFACTURER="Rockchip" +CONFIG_G_DNL_VENDOR_NUM=0x2207 +CONFIG_G_DNL_PRODUCT_NUM=0x330a +CONFIG_FASTBOOT=y +CONFIG_CMD_FASTBOOT=y +CONFIG_FASTBOOT_FLASH=y +CONFIG_FASTBOOT_FLASH_MMC_DEV=1 +CONFIG_FASTBOOT_BUF_ADDR=0x00800800 +CONFIG_FASTBOOT_BUF_SIZE=0x08000000 diff --git a/include/configs/rk3328_common.h b/include/configs/rk3328_common.h index cc6c890..9121db1 100644 --- a/include/configs/rk3328_common.h +++ b/include/configs/rk3328_common.h @@ -61,6 +61,9 @@ #endif +/* dwc2 otg */ +#define CONFIG_USB_DWC2 + /* rockchip ohci host driver */ #define CONFIG_USB_OHCI_NEW #define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 1 -- 1.9.1

2 1

[U-Boot] [PATCH v2 05/10] rockchip: dts: rk3328: support and enable xhci
by Meng Dongyang 05 Jun '17

05 Jun '17

Add dts node of xhci and enable the controller. Signed-off-by: Meng Dongyang <daniel.meng(a)rock-chips.com> Reviewed-by: Simon Glass <sjg(a)chromium.org> --- Changes in v2: - Add fixed regulator of vbus for xhci controller arch/arm/dts/rk3328-evb.dts | 14 ++++++++++++++ arch/arm/dts/rk3328.dtsi | 11 +++++++++++ 2 files changed, 25 insertions(+) diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts index 9920935..4cf6d2e 100644 --- a/arch/arm/dts/rk3328-evb.dts +++ b/arch/arm/dts/rk3328-evb.dts @@ -14,6 +14,15 @@ chosen { stdout-path = &uart2; }; + + vcc5v0_host_xhci: vcc5v0-host-xhci-drv { + compatible = "regulator-fixed"; + enable-active-high; + regulator-name = "vcc5v0_host_xhci"; + gpio = <&gpio0 0 GPIO_ACTIVE_HIGH>; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + }; }; &uart2 { @@ -51,3 +60,8 @@ &usb_host0_ohci { status = "okay"; }; + +&usb_host0_xhci { + vbus-supply = <&vcc5v0_host_xhci>; + status = "okay"; +}; diff --git a/arch/arm/dts/rk3328.dtsi b/arch/arm/dts/rk3328.dtsi index e1219c3..f18cfc2 100644 --- a/arch/arm/dts/rk3328.dtsi +++ b/arch/arm/dts/rk3328.dtsi @@ -471,6 +471,17 @@ status = "disabled"; }; + usb_host0_xhci: usb@ff600000 { + compatible = "rockchip,rk3328-xhci"; + reg = <0x0 0xff600000 0x0 0x100000>; + interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>; + snps,dis-enblslpm-quirk; + snps,phyif-utmi-bits = <16>; + snps,dis-u2-freeclk-exists-quirk; + snps,dis-u2-susphy-quirk; + status = "disabled"; + }; + gic: interrupt-controller@ffb70000 { compatible = "arm,gic-400"; #interrupt-cells = <3>; -- 1.9.1

2 1

Re: [U-Boot] [PATCH 0/20] tegra: Expand Nyan-big support
by Matthew Gorski 05 Jun '17

05 Jun '17

Great Simon! That would be very appreciated! I look forward to your results. Thanks for all the guidance. If I have a servo board with serial I'm sure I could see what's going on behind the scenes ;) On May 2, 2017 10:40 PM, "Simon Glass" <sjg(a)chromium.org> wrote: Hi Matthew, On 2 May 2017 at 18:51, Matthew Gorski <matt.gorski(a)gmail.com> wrote: > I have yet to produce a u-boot command prompt. I can get the display to > flash using u-boot mainline with 0x81000100 as the SYS_TEXT_BASE and using: > > description = "Chrome OS kernel image with one or more FDT blobs"; > > but the boot process forces a reboot into recovery. > > If I use: > > description = "U-Boot + FDT --------- THIS PADDING IS NEEDED SO THE IMAGE > STARTS AT THE RIGHT OFFSET"; > Produces a blank screen with the exact u-boot.bin > > I hope someone can confirm nyan can chainboot u-boot and possibly post what > the used for their FIT its config. Thanks for all the help and guided > responses. I hope to be able to try this later in the week. - Simon > > On Tue, May 2, 2017 at 11:34 AM, Matthew Gorski <matt.gorski(a)gmail.com> > wrote: >> >> >> >> On Tue, May 2, 2017 at 9:25 AM, Matthew Gorski <matt.gorski(a)gmail.com> >> wrote: >>> >>> >>> >>> On Tue, May 2, 2017 at 2:54 AM, Sjoerd Simons >>> <sjoerd.simons(a)collabora.co.uk> wrote: >>>> >>>> On Tue, 2017-05-02 at 08:42 +0200, Tomeu Vizoso wrote: >>>> > On 2 May 2017 at 08:40, Tomeu Vizoso <tomeu(a)tomeuvizoso.net> wrote: >>>> > > On 2 May 2017 at 03:19, Matthew Gorski <matt.gorski(a)gmail.com> >>>> > > wrote: >>>> > > > Seems if you change the FIT description from anything but >>>> > > > >>>> > > > "description = "Chrome OS kernel image with one or more FDT >>>> > > > blobs";" >>>> > > > >>>> > > > the kernel wont load. So this issue has to be in the kernel- >>>> > > > big.its >>>> > > > <https://git.collabora.com/cgit/user/tomeu/u-boot.git/tree/kernel >>>> > > > -big.its?h=nyan-big&id=35bcb399c0d78ba6a050cc775d467ee75ed06923> >>>> > > > >>>> > > > https://git.collabora.com/cgit/user/tomeu/u-boot.git/tree/kernel- >>>> > > > big.its?h=nyan-big&id=35bcb399c0d78ba6a050cc775d467ee75ed06923 >>>> > > > >>>> > > > We may just need a proper working .its for nyan >>>> > > >>>> > > Hi Matthew, >>>> > > >>>> > > it has been quite a while, but I remember that if we only tried >>>> > > chainloading U-Boot was because the goal was to integrate these >>>> > > machines in our LAVA lab, which to date doesn't support Depthcharge >>>> > > (though I hope this will change once I get back some time). >>>> > > >>>> > > I cannot remember how the correct position of the kernel within the >>>> > > FIT image was calculated, but it definitely involved looking at the >>>> > > depthcharge sources. >>>> > >>>> > Actually, I have grepped my IRC logs and turns out that we need for >>>> > the start of U-Boot's code to be aligned to 64kB. >>>> >>>> Yup, U-boot both needs to be properly aligned and know its text base >>>> address. >>>> >>>> So the calculation we did was basically look at depthcharge where in >>>> memory the FIT image gets loaded, determine a suitable load address >>>> after that (e.g fit load + 64k), configure that in u-boot and then add >>>> enough padding in the fit image itself such that the u-boot code starts >>>> at the determined address in memory by putting in just the right amount >>>> of padding ;). >>>> >>>> It is rather ugly, but it does allow running u-boot without the need to >>>> change the firmware in flash. >>> >>> >>> Thank You Tomeu, Sjoerd and Simon for taking the time to chime in on an >>> old but interesting topic. >>> >>> I believe I have enough info from you all to get this figured out now. >>> >>> Since depthcharch loads the FIT image at 0x81000000 >>> https://chromium.googlesource.com/chromiumos/platform/ depthcharge/+/master/board/nyan_big/defconfig#11 >>> >>> I need to determine a suitable load address e.g fit load + 64k >>> >>> So 81000000 + 64k. >>> >>> One thing I am not certain about is adding the padding to the FIT .its >>> config. How is this done? >>> >>> description = "U-Boot + FDT --------- THIS PADDING IS NEEDED SO THE IMAGE >>> STARTS AT THE RIGHT OFFSET"; >> >> >> Seems if I use the description "description = "U-Boot + FDT --------- THIS >> PADDING IS NEEDED SO THE IMAGE STARTS AT THE RIGHT OFFSET"; " >> >> I get a blank display that shows no signs of loading uboot BUT if I use: >> >> description = "Chrome OS kernel image with one or more FDT blobs"; >> >> Nyan tries to load something because the display flashes like a normal >> bootup but immediately reboots into chromeos usb/sdcard recovery. >> >> So the hack in the the collabora uboot kernel-big.its doesnt seem to work >> anymore unless the padding is messing with the load address. >> >> I am using mainline uboot with CONFIG_SYS_TEXT_BASE 0x81000100 should this >> be changed? >> >> Also i am trying to figure out how padding is calculated in a fit image >> and this is confusing. Is the padding the actual description length? >>> >>> >>>> >>>> > Thus the padding. >>>> > >>>> > Regards, >>>> > >>>> > Tomeu >>>> > >>>> > > But I do think to remember that it was only an issue once U-Boot >>>> > > tried >>>> > > to relocate itself. >>>> > > >>>> > > I don't see any reason why my old branch wouldn't work today on >>>> > > your >>>> > > machine, other than maybe your hw is a different revision with a >>>> > > memory chip that wasn't supported back then? I also don't see why >>>> > > mainline wouldn't work, provided you have that hack in the ITS. >>>> > > >>>> > > I'm adding Sjoerd to CC in case he remembers. >>>> > > >>>> > > Good luck, >>>> > > >>>> > > Tomeu >>>> > > >>>> > > > On Mon, May 1, 2017 at 7:45 PM, Matthew Gorski <matt.gorski@gmail >>>> > > > .com> >>>> > > > wrote: >>>> > > > >>>> > > > > >>>> > > > > >>>> > > > > On Mon, May 1, 2017 at 7:34 PM, Simon Glass <sjg(a)chromium.org> >>>> > > > > wrote: >>>> > > > > >>>> > > > > > Hi Matthew, >>>> > > > > > >>>> > > > > > On 1 May 2017 at 17:27, Matthew Gorski <matt.gorski(a)gmail.com >>>> > > > > > > wrote: >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > On Mon, May 1, 2017 at 6:02 PM, Simon Glass <sjg(a)chromium.o >>>> > > > > > > rg> wrote: >>>> > > > > > > > >>>> > > > > > > > Hi Matthew, >>>> > > > > > > > >>>> > > > > > > > On 1 May 2017 at 14:30, Matthew Gorski <matt.gorski@gmail >>>> > > > > > > > .com> wrote: >>>> > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > On Mon, May 1, 2017 at 2:36 PM, Simon Glass <sjg@chromi >>>> > > > > > > > > um.org> >>>> > > > > > >>>> > > > > > wrote: >>>> > > > > > > > > > >>>> > > > > > > > > > Hi Matthew, >>>> > > > > > > > > > >>>> > > > > > > > > > On 1 May 2017 at 11:26, Matthew Gorski <matt.gorski@g >>>> > > > > > > > > > mail.com> >>>> > > > > > >>>> > > > > > wrote: >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > On Mon, May 1, 2017 at 1:03 PM, Simon Glass <sjg@ch >>>> > > > > > > > > > > romium.org> >>>> > > > > > >>>> > > > > > wrote: >>>> > > > > > > > > > > > >>>> > > > > > > > > > > > Hi Matthew, >>>> > > > > > > > > > > > >>>> > > > > > > > > > > > On 1 May 2017 at 10:40, Matthew Gorski <matt.gors >>>> > > > > > > > > > > > ki(a)gmail.com> >>>> > > > > > > > > > > > wrote: >>>> > > > > > > > > > > > > Let me repost this to the bottom. New to the >>>> > > > > > > > > > > > > mailing list ;) >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > I am using chained boot to test uboot as a FIT >>>> > > > > > > > > > > > > image so I I >>>> > > > > > >>>> > > > > > don't >>>> > > > > > > > > > > > > have to >>>> > > > > > > > > > > > > flash to spl flash. Does CONFIG_SPL_TEXT_BASE >>>> > > > > > > > > > > > > need to be >>>> > > > > > >>>> > > > > > adjusted >>>> > > > > > > > > > > > > for >>>> > > > > > > > > > > > > chained boot? >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > I am using instructions to boot Linux for Tegra >>>> > > > > > > > > > > > > from >>>> > > > > > >>>> > > > > > sdcard/USB in >>>> > > > > > > > > > > > > developer >>>> > > > > > > > > > > > > mode. I can boot L4T fine with kernel v3.10. >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > What mainline branch should I try? >>>> > > > > > > > > > > > >>>> > > > > > > > > > > > There's only one mainline, here: >>>> > > > > > > > > > > > http://git.denx.de/?p=u-boot.git;a=summary >>>> > > > > > > > > > > > >>>> > > > > > > > > > > > There are various custodian branches but I don't >>>> > > > > > > > > > > > believe the >>>> > > > > > >>>> > > > > > tegra >>>> > > > > > > > > > > > one >>>> > > > > > > > > > > > has anything different from mainline at present. >>>> > > > > > > > > > > > >>>> > > > > > > > > > > > - Simon >>>> > > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > I will give mainline a try with: >>>> > > > > > > > > > > >>>> > > > > > > > > > > CONFIG_SYS_TEXT_BASE 0x8010E000 >>>> > > > > > > > > > > and >>>> > > > > > > > > > > >>>> > > > > > > > > > > CONFIG_SPL_TEXT_BASE 0x80108000 >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > I know I will also need: >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > CONFIG_DISPLAY_PORT=y >>>> > > > > > > > > > >>>> > > > > > > > > > Do you mean CONFIG_DISPLAY? If so, it is already >>>> > > > > > > > > > defined. >>>> > > > > > > > > > >>>> > > > > > > > > > > CONFIG_VIDEO_TEGRA124=y >>>> > > > > > > > > > >>>> > > > > > > > > > That is defined in mainline >>>> > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > for the console to display command prompt. >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > The FIT config I am using is from >>>> > > > > > > > > > > >>>> > > > > > > > > > > here:https://git.collabora.com/cgit/user/tomeu/u-bo >>>> > > > > > > > > > > ot.git/ >>>> > > > > > >>>> > > > > > commit/?h=nyan-big >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > Do I need to adjust: >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > load = <0>; >>>> > > > > > > > > > > entry = <0>; >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > /dts-v1/; >>>> > > > > > > > > > > >>>> > > > > > > > > > > / { >>>> > > > > > > > > > > description = "U-Boot + FDT --------- THIS >>>> > > > > > > > > > > PADDING IS NEEDED >>>> > > > > > >>>> > > > > > SO >>>> > > > > > > > > > > THE >>>> > > > > > > > > > > IMAGE STARTS AT THE RIGHT OFFSET"; >>>> > > > > > > > > > >>>> > > > > > > > > > Perhaps you need to adjust this? How was the length >>>> > > > > > > > > > of it >>>> > > > > > >>>> > > > > > calcualted? >>>> > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > I am really not sure how the padding was calculated. I >>>> > > > > > > > > just assumed >>>> > > > > > > > > this >>>> > > > > > > > > kernel-big.its FIT config was correct for nyan_big. I >>>> > > > > > > > > will try >>>> > > > > > >>>> > > > > > using my >>>> > > > > > > > > working linux kernel fit config. >>>> > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > > > #address-cells = <1>; >>>> > > > > > > > > > > images { >>>> > > > > > > > > > > kernel@1{ >>>> > > > > > > > > > > description = "kernel"; >>>> > > > > > > > > > > data = /incbin/("u-boot-dtb.bin"); >>>> > > > > > > > > > > type = "kernel_noload"; >>>> > > > > > > > > > > arch = "arm"; >>>> > > > > > > > > > > os = "linux"; >>>> > > > > > > > > > > compression = "none"; >>>> > > > > > > > > > > load = <0>; >>>> > > > > > > > > > > entry = <0>; >>>> > > > > > > > > > > }; >>>> > > > > > > > > > > fdt@1{ >>>> > > > > > > > > > > description = "tegra124-nyan-big.dtb"; >>>> > > > > > > > > > > data = /incbin/("dts/dt.dtb"); >>>> > > > > > > > > > > type = "flat_dt"; >>>> > > > > > > > > > > arch = "arm"; >>>> > > > > > > > > > > compression = "none"; >>>> > > > > > > > > > > hash@1{ >>>> > > > > > > > > > > algo = "sha1"; >>>> > > > > > > > > > > }; >>>> > > > > > > > > > > }; >>>> > > > > > > > > > > }; >>>> > > > > > > > > > > configurations { >>>> > > > > > > > > > > default = "conf@1"; >>>> > > > > > > > > > > conf@1{ >>>> > > > > > > > > > > kernel = "kernel@1"; >>>> > > > > > > > > > > fdt = "fdt@1"; >>>> > > > > > > > > > > }; >>>> > > > > > > > > > > }; >>>> > > > > > > > > > > }; >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > please let me know if I should also adjust the SPL >>>> > > > > > > > > > > CONFIG even >>>> > > > > > >>>> > > > > > though >>>> > > > > > > > > > > I >>>> > > > > > > > > > > am chainbooting uboot: >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > https://www.chromium.org/chromium-os/firmware-porti >>>> > > > > > > > > > > ng-guide/ >>>> > > > > > >>>> > > > > > using-nv-u-boot-on-the-samsung-arm-chromebook#TOC-Installing >>>> > > > > > -nv-U-Boot-chained-U-Boot-method- >>>> > > > > > > > > > >>>> > > > > > > > > > This is exynos, where we booted directly into U-Boot. >>>> > > > > > > > > > Actually I'm >>>> > > > > > > > > > wondering we should boot directly into U-Boot >>>> > > > > > > > > > (instead of SPL) on >>>> > > > > > >>>> > > > > > nyan >>>> > > > > > > > > > also. Perhaps someone at collabora would know? Did >>>> > > > > > > > > > you search the >>>> > > > > > > > > > mailing list? >>>> > > > > > > > > > >>>> > > > > > > > > > Regards, >>>> > > > > > > > > > Simon >>>> > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > I have not searched the mailing list. What should I >>>> > > > > > > > > search for? >>>> > > > > > > > > Booting >>>> > > > > > > > > nyan to u-boot directly bypassing SPL? >>>> > > > > > > > >>>> > > > > > > > Here are two subjects to search for: >>>> > > > > > > > >>>> > > > > > > > Veyron-speedy u-boot >>>> > > > > > > > [PATCH 0/20] tegra: Expand Nyan-big support >>>> > > > > > > > >>>> > > > > > > > Regards, >>>> > > > > > > > Simon >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > Very odd if I do not use "#address-cells = <1>;" the >>>> > > > > > > display flashes and >>>> > > > > > > reboots into recovery but if I do use #address-cells = <1>; >>>> > > > > > > in my FIT >>>> > > > > > >>>> > > > > > config >>>> > > > > > > I get a blank screen >>>> > > > > > > so something is working when not using the padding. >>>> > > > > > >>>> > > > > > If you figure out where u-boot-dtb.bin needs to start by >>>> > > > > > looking at >>>> > > > > > depthcharge or where the kernel starts, then you can figure >>>> > > > > > out how >>>> > > > > > long the padding needs to be at the start of the FIT. Rather >>>> > > > > > than >>>> > > > > > guessing...! >>>> > > > > > >>>> > > > > > - Simon >>>> > > > > > >>>> > > > > > Okay so depthcharge starts at 0x81000000 from here: >>>> > > > > >>>> > > > > https://chromium.googlesource.com/chromiumos/platform/ >>>> > > > > depthcharge/+/master/board/nyan_big/defconfig#11 >>>> > > > > >>>> > > > > In my System.map for u-boot after building says the start is: >>>> > > > > 81000100 T __image_copy_start >>>> > > > > 81000100 T _start >>>> > > > > >>>> > > > > Hence the define CONFIG_SYS_TEXT_BASE 0x81000100 >>>> > > > > >>>> > > > > So you say use 0x81000000 as the CONFIG_SYS_TEXT_BASE and not >>>> > > > > 0x81000100 >>>> > > > > correct? >>>> > > > > >>>> > > > > > > >>>> > > > > > > /dts-v1/; >>>> > > > > > > >>>> > > > > > > / { >>>> > > > > > > description = "Chrome OS nyan u-boot chain boot >>>> > > > > > > method"; >>>> > > > > > > #address-cells = <1>; >>>> > > > > > > images { >>>> > > > > > > kernel@1{ >>>> > > > > > > >>>> > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > On May 1, 2017 12:11 PM, "Matthew Gorski" < >>>> > > > > > >>>> > > > > > matt.gorski(a)gmail.com> >>>> > > > > > > > > > > > > wrote: >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > On May 1, 2017 11:45 AM, "Simon Glass" <sjg@chr >>>> > > > > > > > > > > > > omium.org> >>>> > > > > > >>>> > > > > > wrote: >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > Hi Matthew, >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > On 1 May 2017 at 09:37, Matthew Gorski <matt.go >>>> > > > > > > > > > > > > rski(a)gmail.com> >>>> > > > > > > > > > > > > wrote: >>>> > > > > > > > > > > > > > Thanks for the reply Simon. >>>> > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > I have been trying to find the System.map for >>>> > > > > > > > > > > > > > depthcharge to >>>> > > > > > >>>> > > > > > see >>>> > > > > > > > > > > > > > the >>>> > > > > > > > > > > > > > kernel >>>> > > > > > > > > > > > > > load address but I am unable to find >>>> > > > > > > > > > > > > > anything. I have tried >>>> > > > > > > > > > > > > > multiple >>>> > > > > > > > > > > > > > CONFIG_SYS_TEXT_BASE settings with no luck. >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > How did you choose what to use? Also note that >>>> > > > > > > > > > > > > Tegra uses SPL >>>> > > > > > >>>> > > > > > to >>>> > > > > > > > > > > > > start, so you may need to adjust >>>> > > > > > > > > > > > > CONFIG_SPL_TEXT_BASE instead. >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > I am creating my sdcard with a standard linux >>>> > > > > > > > > > > > > > (Linux for >>>> > > > > > >>>> > > > > > Tegra) >>>> > > > > > > > > > > > > > rootfs: >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > Did these instructions come from a web site >>>> > > > > > > > > > > > > somewhere? >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > Partition an SD card >>>> > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > sudo cgpt create <MMC BLOCK DEVICE> >>>> > > > > > > > > > > > > > sudo cgpt add -b 34 -s 32768 -P 1 -S 1 -t >>>> > > > > > > > > > > > > > kernel <MMC BLOCK >>>> > > > > > > > > > > > > > DEVICE> >>>> > > > > > > > > > > > > > # 16 >>>> > > > > > > > > > > > > > MB >>>> > > > > > > > > > > > > > kernel image partition >>>> > > > > > > > > > > > > > sudo cgpt add -b 32802 -s <ROOT PARTITION >>>> > > > > > > > > > > > > > SIZE in 512B >>>> > > > > > >>>> > > > > > sectors> >>>> > > > > > > > > > > > > > -t >>>> > > > > > > > > > > > > > rootfs >>>> > > > > > > > > > > > > > <MMC BLOCK DEVICE> >>>> > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > cgpt doesn't seem to create a protective MBR. >>>> > > > > > > > > > > > > > If one is not >>>> > > > > > > > > > > > > > already >>>> > > > > > > > > > > > > > in >>>> > > > > > > > > > > > > > place, it can be created with: >>>> > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > sudo gdisk <MMC BLOCK DEVICE> # and enter >>>> > > > > > > > > > > > > > command w >>>> > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > Copy data to the SD card >>>> > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > sudo dd if=./kernelpart.bin of=<MMC BLOCK >>>> > > > > > > > > > > > > > DEVICE>p1 >>>> > > > > > > > > > > > > > sudo mkfs.ext4 <MMC BLOCK DEVICE>p2 >>>> > > > > > > > > > > > > > sudo mount <MMC BLOCK DEVICE>p2 /mnt/ >>>> > > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > How are you actually making it boot? Is this in >>>> > > > > > > > > > > > > dev mode with >>>> > > > > > >>>> > > > > > USB >>>> > > > > > > > > > > > > boot >>>> > > > > > > > > > > > > enabled and pressing Ctrl-U? >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > Also, as this is a mailing list, please avoid >>>> > > > > > > > > > > > > top-posting. >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > - Simon >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > I am using chained boot to test uboot as a FIT >>>> > > > > > > > > > > > > image so I I >>>> > > > > > >>>> > > > > > don't >>>> > > > > > > > > > > > > have to >>>> > > > > > > > > > > > > flash to spl flash. Does CONFIG_SPL_TEXT_BASE >>>> > > > > > > > > > > > > need to be >>>> > > > > > >>>> > > > > > adjusted >>>> > > > > > > > > > > > > for >>>> > > > > > > > > > > > > chained boot? >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > I am using instructions to boot Linux for Tegra >>>> > > > > > > > > > > > > from >>>> > > > > > >>>> > > > > > sdcard/USB in >>>> > > > > > > > > > > > > developer >>>> > > > > > > > > > > > > mode. I can boot L4T fine with kernel v3.10. >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > What mainline branch should I try? >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > On Mon, May 1, 2017 at 11:14 AM, Simon Glass >>>> > > > > > > > > > > > > > < >>>> > > > > > >>>> > > > > > sjg(a)chromium.org> >>>> > > > > > > > > > > > > > wrote: >>>> > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > Hi Matthew, >>>> > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > On 1 May 2017 at 08:43, Matthew Gorski < >>>> > > > > > >>>> > > > > > matt.gorski(a)gmail.com> >>>> > > > > > > > > > > > > > > wrote: >>>> > > > > > > > > > > > > > > > I am porting u-boot to nyan_big and need >>>> > > > > > > > > > > > > > > > some input. I >>>> > > > > > >>>> > > > > > have >>>> > > > > > > > > > > > > > > > been >>>> > > > > > > > > > > > > > > > searching >>>> > > > > > > > > > > > > > > > high and low and found this thread here: >>>> > > > > > > > > > > > > > > > [U-Boot] [PATCH >>>> > > > > > >>>> > > > > > 0/20] >>>> > > > > > > > > > > > > > > > tegra: >>>> > > > > > > > > > > > > > > > Expand >>>> > > > > > > > > > > > > > > > Nyan-big support >>>> > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > https://lists.denx.de/pipermail/u-boot/2 >>>> > > > > > > > > > > > > > > > 015-March/209530. >>>> > > > > > >>>> > > > > > html >>>> > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > I have tried to build u-boot with the >>>> > > > > > > > > > > > > > > > branch here: >>>> > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > https://git.collabora.com/cgit >>>> > > > > > >>>> > > > > > /user/tomeu/u-boot.git/commit/?h=nyan-big >>>> > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > and also the official chromium next >>>> > > > > > > > > > > > > > > > branch >>>> > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > Have you tried mainline U-Boot? It already >>>> > > > > > > > > > > > > > > supports nyan-big. >>>> > > > > > > > > > > > > > > I'm >>>> > > > > > > > > > > > > > > not >>>> > > > > > > > > > > > > > > sure about the situation with the >>>> > > > > > > > > > > > > > > downstream trees. >>>> > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > I followed building instructions here: >>>> > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > https://www.chromium.org/chrom >>>> > > > > > >>>> > > > > > ium-os/firmware-porting-guide/using-nv-u-boot-on-the-samsung >>>> > > > > > -arm-chromebook >>>> > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > I build with these commands: >>>> > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > mkimage -e 0x81000100 -a 0x81000100 -f >>>> > > > > > > > > > > > > > > > kernel-big.its >>>> > > > > > > > > > > > > > > > kernel-u-boot >>>> > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > (with and without the load address >>>> > > > > > > > > > > > > > > > setting) >>>> > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > vbutil_kernel --arch arm --pack >>>> > > > > > > > > > > > > > > > kernel.bin --keyblock >>>> > > > > > > > > > > > > > > > /usr/share/vboot/devkeys/kernel.keyblock >>>> > > > > > > > > > > > > > > > --signprivate >>>> > > > > > > > > > > > > > > > /usr/share/vboot/devkeys/kernel_data_key. >>>> > > > > > > > > > > > > > > > vbprivk >>>> > > > > > >>>> > > > > > --version 1 >>>> > > > > > > > > > > > > > > > --config >>>> > > > > > > > > > > > > > > > dummy.txt --vmlinuz kernel-u-boot -- >>>> > > > > > > > > > > > > > > > bootloader dummy.txt >>>> > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > I have had numerous failed attempts to >>>> > > > > > > > > > > > > > > > boot uboot from >>>> > > > > > >>>> > > > > > sdcard >>>> > > > > > > > > > > > > > > > mmcblk1p1 >>>> > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > Any help is appreciated I have only >>>> > > > > > > > > > > > > > > > gotten a blank screen >>>> > > > > > > > > > > > > > > > after >>>> > > > > > > > > > > > > > > > weeks >>>> > > > > > > > > > > > > > > > of >>>> > > > > > > > > > > > > > > > flashing. I can boot custom v3.10 >>>> > > > > > > > > > > > > > > > kernels so I assume I am >>>> > > > > > > > > > > > > > > > using >>>> > > > > > > > > > > > > > > > the >>>> > > > > > > > > > > > > > > > correct building procedure. Thanks in >>>> > > > > > > > > > > > > > > > advance for help >>>> > > > > > >>>> > > > > > from >>>> > > > > > > > > > > > > > > > the >>>> > > > > > > > > > > > > > > > u-boot >>>> > > > > > > > > > > > > > > > community. >>>> > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > It is possible that it needs a particular >>>> > > > > > > > > > > > > > > address due to >>>> > > > > > > > > > > > > > > limitations >>>> > > > > > > > > > > > > > > in the FIT support on Nyan. I'm not sure >>>> > > > > > > > > > > > > > > what it is but >>>> > > > > > >>>> > > > > > might be >>>> > > > > > > > > > > > > > > able >>>> > > > > > > > > > > > > > > to take a look at some point. >>>> > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > How are you building your SD card? Are you >>>> > > > > > > > > > > > > > > following some >>>> > > > > > > > > > > > > > > instructions >>>> > > > > > > > > > > > > > > from somewhere? >>>> > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > Regards, >>>> > > > > > > > > > > > > > > Simon >>>> > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > >>>> > > > > >>>> > > > >>>> > > > _______________________________________________ >>>> > > > U-Boot mailing list >>>> > > > U-Boot(a)lists.denx.de >>>> > > > https://lists.denx.de/listinfo/u-boot >>>> >>>> -- >>>> Sjoerd Simons >>>> Collabora Ltd. >>> >>> >> >

3 4

[U-Boot] [RESEND] drivers/usb/ehci: Use platform-specific accessors
by Alexey Brodkin 05 Jun '17

05 Jun '17

From: Alexey Brodkin <Alexey.Brodkin(a)synopsys.com> Current implementation doesn't allow utilization of platform-specific reads and writes. But some arches or platforms may want to use their accessors that do some extra work like adding barriers for data serialization etc. Interesting enough OHCI accessors already do that so just aligning EHCI to it now. This is a resend of http://patchwork.ozlabs.org/patch/726714/ Back in the day this patch broke some PPC and Sandbox boards as they we missing inclusion of "asm/io.h". Those missing items were fixed with: 1) http://patchwork.ozlabs.org/patch/751397/ 2) http://patchwork.ozlabs.org/patch/771099/ So now it should be safe to apply this patch. FWIW TravisCI builds everything with all 3 patches in place, see https://travis-ci.org/abrodkin/u-boot/builds/239563813 Signed-off-by: Alexey Brodkin <abrodkin(a)synopsys.com> Cc: Simon Glass <sjg(a)chromium.org> Cc: Mateusz Kulikowski <mateusz.kulikowski(a)gmail.com> Acked-by: Marek Vasut <marex(a)denx.de> --- drivers/usb/host/ehci.h | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h index 734d7f036278..2ab830df5155 100644 --- a/drivers/usb/host/ehci.h +++ b/drivers/usb/host/ehci.h @@ -102,13 +102,11 @@ struct usb_linux_config_descriptor { } __attribute__ ((packed)); #if defined CONFIG_EHCI_DESC_BIG_ENDIAN -#define ehci_readl(x) cpu_to_be32((*((volatile u32 *)(x)))) -#define ehci_writel(a, b) (*((volatile u32 *)(a)) = \ - cpu_to_be32(((volatile u32)b))) +#define ehci_readl(x) cpu_to_be32(readl(x)) +#define ehci_writel(a, b) writel(cpu_to_be32(b), a) #else -#define ehci_readl(x) cpu_to_le32((*((volatile u32 *)(x)))) -#define ehci_writel(a, b) (*((volatile u32 *)(a)) = \ - cpu_to_le32(((volatile u32)b))) +#define ehci_readl(x) cpu_to_le32(readl(x)) +#define ehci_writel(a, b) writel(cpu_to_le32(b), a) #endif #if defined CONFIG_EHCI_MMIO_BIG_ENDIAN -- 2.7.5

1 0

[U-Boot] [PATCH 1/2] moveconfig.py: All piping in 'git show --stat' output
by Simon Glass 05 Jun '17

05 Jun '17

It is useful to be able to process only a subset of boards to save time. Often that subset is defined by the defconfig files in a git commit. This change allows things like: ./tools.moveconfig.py -b ./tools/moveconfig.py -i CONFIG_... # add some 'imply' statements to Kconfig files git show --stat | ./tools/moveconfig.py -s -d - Where the commit contains defconfig files, this will reprocess them to take account of the imply statements that you added. Signed-off-by: Simon Glass <sjg(a)chromium.org> --- tools/moveconfig.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/moveconfig.py b/tools/moveconfig.py index 09c5a7e5cd..4295b47d7c 100755 --- a/tools/moveconfig.py +++ b/tools/moveconfig.py @@ -405,6 +405,8 @@ def get_matched_defconfigs(defconfigs_file): line = line.strip() if not line: continue # skip blank lines silently + if ' ' in line: + line = line.split(' ')[0] # handle 'git log' input matched = get_matched_defconfig(line) if not matched: print >> sys.stderr, "warning: %s:%d: no defconfig matched '%s'" % \ -- 2.13.0.506.g27d5fe0cd-goog

1 1

[U-Boot] [PATCH v2] cmd: fsfitxtract: Extract a part of a FIT multi-image stored on a filesystem
by Alexey Ignatov 05 Jun '17

05 Jun '17

Sometimes we interested only in one single small subimage from big multipart FIT. This command tries to avoid reading out the whole FIT because of memory or time considerations. Since we don't have mmap() in U-Boot, this is done by reading the file in small chunks and trying to parse FIT, skipping reading the payload data of all images before the requested one, while preserving FIT structure. Changelog: v2: * Skip unneeded subimages data instead of reading it out * Read whole data in one operation * Lot of refactoring * Faster, more versatile and robust * Improved code readability v1: * First submission to maillist Signed-off-by: Alexey Ignatov <lexszero(a)gmail.com> --- cmd/Kconfig | 7 ++ cmd/ximg.c | 356 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 363 insertions(+) diff --git a/cmd/Kconfig b/cmd/Kconfig index d9f7151bac..ff8ade96b4 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -265,6 +265,13 @@ config CMD_XIMG help Extract a part of a multi-image. +config CMD_FSFITXIMG + bool "fsfitxtract" + default y + depends on FIT + help + Extract a part of a FIT multi-image stored on a filesystem + config CMD_POWEROFF bool diff --git a/cmd/ximg.c b/cmd/ximg.c index 73a571b52b..62e2cb2ac1 100644 --- a/cmd/ximg.c +++ b/cmd/ximg.c @@ -22,6 +22,11 @@ #endif #include <asm/byteorder.h> #include <asm/io.h> +#ifdef CONFIG_CMD_FSFITXIMG +#include <fs.h> +#include <div64.h> +#include <libfdt.h> +#endif #ifndef CONFIG_SYS_XIMG_LEN /* use 8MByte as default max gunzip size */ @@ -283,3 +288,354 @@ U_BOOT_CMD( imxtract, 4, 1, do_imgextract, "extract a part of a multi-image", imgextract_help_text ); + +#if defined(CONFIG_FIT) && defined(CONFIG_CMD_FSFITXIMG) + +/* TODO: maybe make this configurable */ +#define CHUNK_SIZE (8*1024) +#define IMAGE_TAIL_SIZE CHUNK_SIZE + +struct fs_fdt_context { + const char *dev; + const char *part; + const char *name; + + ulong dest; + ulong len; + ulong src_off; + void *fdt; +}; + +static int fs_load(struct fs_fdt_context *ctx, loff_t len) +{ + int ret = 0; + loff_t len_read; + + debug("Reading %lld bytes from offset 0x%lx to 0x%lx\n", + len, ctx->src_off, ctx->dest + ctx->len); + + if (fs_set_blk_dev(ctx->dev, ctx->part, FS_TYPE_ANY)) + return -1; + + ret = fs_read(ctx->name, ctx->dest + ctx->len, ctx->src_off, len, &len_read); + + if (ret < 0) { + printf("Read failed: %d", ret); + return ret; + } + + return len_read; +} + +static int fs_load_next_chunk(struct fs_fdt_context *ctx) +{ + int ret; + ret = fs_load(ctx, CHUNK_SIZE); + if (ret < 0) + return ret; + + ctx->len += ret; + ctx->src_off += ret; + + return 0; +} + +static int fdt_err_retry(int err) +{ + return + (err == -FDT_ERR_TRUNCATED) || + (err == -FDT_ERR_BADSTRUCTURE); +} + +static int fs_fdt_wrap(struct fs_fdt_context *ctx, + int (*fdt_func)(const void *fdt, int offset), int offset) +{ + int ret = 0; + while (1) { + ret = fdt_func(ctx->fdt, offset); + + if (ret >= 0) + break; + + if (!fdt_err_retry(ret)) { + if (ret != -FDT_ERR_NOTFOUND) + printf("Error while parsing FIT: %s\n", fdt_strerror(ret)); + break; + } + + ret = fs_load_next_chunk(ctx); + if (ret < 0) + break; + } + + return ret; +} + +static inline int fs_fit_image_skip_data(struct fs_fdt_context *ctx, int noffset) +{ + int plen = 0; + int poffset = 0; + void *ptr; + const void *nptr; + int tail; + + for (poffset = fs_fdt_wrap(ctx, fdt_first_property_offset, noffset); + poffset >= 0; + poffset = fs_fdt_wrap(ctx, fdt_next_property_offset, poffset)) { + const struct fdt_property *prop = + fdt_get_property_by_offset(ctx->fdt, poffset, &plen); + const char *name; + + if (!prop) { + printf("Can't get property: %s\n", fdt_strerror(plen)); + return 1; + } + + name = fdt_string(ctx->fdt, fdt32_to_cpu(prop->nameoff)); + if (!name) { + printf("Can't get property name\n"); + return 1; + } + + if (strcmp(name, "data") == 0) + break; + }; + + if (poffset < 0) + return poffset; + + debug("data prop offset %d, len %d\n", poffset, plen); + + /* Skip the whole data property which can be quite big using + * some smart pointer arithmetic magic. + */ + printf(" Skip %d bytes of data\n", plen); + plen = ALIGN(plen + 3*4, 4); + ptr = fdt_offset_ptr_w(ctx->fdt, poffset, 0); + nptr = fdt_offset_ptr(ctx->fdt, poffset + plen, 0); + tail = ctx->fdt + ctx->len - nptr; + if (tail > 0) { + memmove(ptr, nptr, tail); + ctx->len -= plen; + debug("move tail len %d from %p to %p; ctx->len = 0x%lx\n", + tail, ptr, nptr, ctx->len); + } + else { + tail = -tail; + ctx->len = ptr - ctx->fdt; + ctx->src_off += tail; + debug("skip partial data, ctx->len = 0x%lx, ctx->src_off = 0x%lx\n", + ctx->len, ctx->src_off); + + if (fs_load_next_chunk(ctx) != 0) + return 1; + } + + return 0; +} + +static int +do_fsfitextract(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[]) +{ + int ret; + int verify; + struct fs_fdt_context ctx; + const char *uname; + const void *data; + size_t len; + int noffset = 0, tail; + uint8_t comp; + unsigned long time; + + if (argc != 6) + return CMD_RET_USAGE; + + verify = getenv_yesno("verify"); + + ctx.dev = argv[1]; + ctx.part = argv[2]; + ctx.name = argv[3]; + uname = argv[4]; + ctx.dest = simple_strtoul(argv[5], NULL, 16); + + time = get_timer(0); + + /* Load FIT from the filesystem incrementally to avoid reading data we + * won't need. If requested subimage contained in the beginning of file, + * this can make a huge speedup. + * + * First, read just the header + */ + ctx.len = 0; + ctx.src_off = 0; + printf("## Loading FIT header to 0x%08lx ...\n", ctx.dest); + ret = fs_load(&ctx, sizeof(struct fdt_header)); + if (ret < 0) + return 1; + + ctx.fdt = map_sysmem(ctx.dest, sizeof(struct fdt_header)); + ret = fdt_check_header(ctx.fdt); + if (ret) { + printf("Bad FIT header: %s\n", fdt_strerror(ret)); + return 1; + } + debug("FIT header at %p\n", ctx.fdt); + + ctx.len = sizeof(struct fdt_header); + + /* Read "strings" block to resolve all the node names, put it after the + * header and adjust offset appropriately + */ + printf("## Loading FIT strings to 0x%08lx ...\n", ctx.dest + ctx.len); + ctx.src_off = fdt_off_dt_strings(ctx.fdt); + ret = fs_load(&ctx, fdt_size_dt_strings(ctx.fdt)); + if (ret < 0) + return 1; + + fdt_set_off_dt_strings(ctx.fdt, ctx.len); + ctx.len += fdt_size_dt_strings(ctx.fdt); + + ctx.len = ALIGN(ctx.len, ARCH_DMA_MINALIGN); + + /* Save offset of "struct" block in file and set the real in-memory offset */ + ctx.src_off = fdt_off_dt_struct(ctx.fdt); + fdt_set_off_dt_struct(ctx.fdt, ctx.len); + + /* Now, start to load struct in CHUNK_SIZE chunks, and parse it at the same + * time. When libfdt notices that the data is truncated or broken, read next + * chunk from the filesystem. + */ + printf("## Loading FIT struct to 0x%08lx ...\n", ctx.dest + ctx.len); + while (1) { + if (fs_load_next_chunk(&ctx)) + return 1; + + ret = fdt_path_offset(ctx.fdt, FIT_IMAGES_PATH); + if (ret >= 0) { + noffset = ret; + break; + } + + if (!fdt_err_retry(ret)) { + printf("Can't find images parent node: %s", + fdt_strerror(ret)); + return 1; + } + }; + + /* Iterate through all images */ + for (noffset = fs_fdt_wrap(&ctx, fdt_first_subnode, noffset); + noffset >= 0; + noffset = fs_fdt_wrap(&ctx, fdt_next_subnode, noffset)) { + const char *name; + + name = fdt_get_name(ctx.fdt, noffset, NULL); + debug("node '%s' at offset %d\n", name, noffset); + + if (strcmp(name, uname) == 0) + break; + + if (fs_fit_image_skip_data(&ctx, noffset) != 0) + return 1; + } + + if (noffset < 0) { + printf("Can't find subimage '%s'\n", uname); + return 1; + } + + debug("found image node at %08x\n", noffset); + + while (1) { + /* get subimage data address and length */ + ret = fit_image_get_data(ctx.fdt, noffset, + &data, &len); + if (!ret) + break; + + if (!fdt_err_retry(len)) { + puts("Could not find subimage data\n"); + return 1; + } + + if (fs_load_next_chunk(&ctx) != 0) + return 1; + }; + + debug("data at %p, len %lu\n", data, len); + + /* Now we know the length of data, so read out the remaining part in + * a single operation. Also read some more than exact data len to + * get other properties such as hashes. + * + * The memory layout at this moment (in terms of offsets from header, + * and declared variables): + * + * offset pointers + * --------------------- + * 0 ctx.fdt + * ... + * data + * ... + * ctx.len + * ... + * <data_end> (data + len) + * + * So, size of leftover is calculated like this: + * data_end = data - ctx.fdt + len + * size_remaining = data_end - ctx.len + */ + tail = data - ctx.fdt + len - ctx.len + IMAGE_TAIL_SIZE; + if (tail > 0) { + ret = fs_load(&ctx, tail); + if (ret < 0) + return 1; + ctx.len += ret; + } + + time = get_timer(time); + + printf("%lu bytes read in %lu ms", ctx.len, time); + if (time > 0) { + puts(" ("); + print_size(lldiv(ctx.len, time) * 1000, "/s"); + puts(")"); + } + puts("\n"); + + fit_image_print(ctx.fdt, noffset, " "); + + if (fit_image_get_comp(ctx.fdt, noffset, &comp)) { + puts("Could not find FIT subimage compression type\n"); + return 1; + } + + /* verify integrity */ + if (verify) { + puts("## Verifying ... "); + if (!fit_image_verify(ctx.fdt, noffset)) { + puts("Bad data hash\n"); + return 1; + } + puts("\n"); + } + + if (!decompress_data(ctx.dest, (ulong)data, (ulong)len, comp, 0)) + return 1; + + flush_cache(ctx.dest, len); + + setenv_hex("filesize", len); + + return 0; +} + +U_BOOT_CMD( + fsfitxtract, 7, 1, do_fsfitextract, + "extract a part of a FIT stored on a filesystem", + "<interface> <dev[:part]> <filename> <uname> <addr>\n" + " - Extract subimage <uname> from FIT file <filename> from\n" + " partition <part> on device type <interface> instance <dev>\n" + " to address <addr> in memory." +); +#endif -- 2.12.2

2 1

[U-Boot] [RFC PATCH] SPL: replace ctype implementation with tiny version
by Andre Przywara 05 Jun '17

05 Jun '17

The ctype implementation (isdigit() & friends) works with an array of 256 Bytes - one for each character. This is pretty big in SPL terms, so let's replace this "bloated" implementation with a tiny version using C statements. This only implements the functions that the SPL requires and confines this change only to an actual SPL build. Saves about 200 Bytes from the SPL code size. Signed-off-by: Andre Przywara <andre.przywara(a)arm.com> --- Hi, some people voiced concerns about running out of SPL code space when adding new features. In this particular case this was an issue when looking at the SPL FIT extension series[1]. This patch here on top of this series saves more space than the SPL FIT series consumed, so I trade this as a bait to people wrestling with this problem ;-) Cheers, Andre. [1] http://lists.denx.de/pipermail/u-boot/2017-January/278772.html include/linux/tiny_ctype.h | 12 ++++++++++++ lib/Makefile | 2 ++ lib/strto.c | 4 ++++ 3 files changed, 18 insertions(+) create mode 100644 include/linux/tiny_ctype.h diff --git a/include/linux/tiny_ctype.h b/include/linux/tiny_ctype.h new file mode 100644 index 0000000..4910412 --- /dev/null +++ b/include/linux/tiny_ctype.h @@ -0,0 +1,12 @@ +#ifndef _LINUX_CTYPE_H +#define _LINUX_CTYPE_H + +#define isdigit(c) (((c) >= '0') && ((c) <= '9')) +#define isxdigit(c) (isdigit(c) || \ + ((c) >= 'A' && (c) <= 'F') || \ + ((c) >= 'a' && (c) <= 'f')) +#define islower(c) ((((c) >= 'a') && ((c) <= 'z')) || ((c) >= 223)) + +#define toupper(c) ((((c) >= 'a') && ((c) <= 'z')) ? (c) - 32 : (c)) + +#endif diff --git a/lib/Makefile b/lib/Makefile index 23e9f1e..15385fd 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -66,7 +66,9 @@ obj-y += display_options.o CFLAGS_display_options.o := $(if $(BUILD_TAG),-DBUILD_TAG='"$(BUILD_TAG)"') obj-$(CONFIG_BCH) += bch.o obj-y += crc32.o +ifndef CONFIG_SPL_BUILD obj-y += ctype.o +endif obj-y += div64.o obj-y += hang.o obj-y += linux_compat.o diff --git a/lib/strto.c b/lib/strto.c index e93a4f5..9e9ba75 100644 --- a/lib/strto.c +++ b/lib/strto.c @@ -11,7 +11,11 @@ #include <common.h> #include <errno.h> +#ifdef CONFIG_SPL_BUILD +#include <linux/tiny_ctype.h> +#else #include <linux/ctype.h> +#endif unsigned long simple_strtoul(const char *cp, char **endp, unsigned int base) -- 2.8.2

4 7

[U-Boot] [PATCH v3 00/30] ARM: k2g: Add support for new K2G ICE EVM.
by Franklin S Cooper Jr 05 Jun '17

05 Jun '17

This patchset adds support for the new Keystone 2 Industrial Communication Engine board. This patchset includes the introduction of embedded FIT images in U-boot. This creates a FIT image of dtb files that enables board specific code to select which DTB to use at runtime. Initially during boot a generic DTB is required that enables board detection to occur and once it has can later be swapped out for the correct dtb. Version 3 changes: Fixed minor comments that were missed in rev 2. Version 2 changes: Some patches were dropped since equivalent changes have already be incorporated in upstream already. The addition davinci i2c device model in upstream resulted in some patches having to be added or tweaked. The DT for K2G ICE is based on the version that has been accepted into Linux mainline https://lkml.org/lkml/2017/5/22/28 Franklin S Cooper Jr (29): spl: fit: Break out some functions into a common file boot_fit: Create helper functions that can be used to select DTB out of FIT fdt: Enable selecting correct DTB from appended FIT Image ti: common: board_detect: Add function to determine if EEPROM was read dts: Allow OF_LIST to depend on FIT_EMBED ARM: dts: k2g: Introduce U-boot specific dtsi file arm: dts: Add new "generic" 66AK2Gx device tree file. board_f: Add new function to allow runtime DTB selection Makefile: Build additional binaries for dtb FIT blobs appended to U-boot ARM: keystone2: Allow to build with all image formats ARM: k2g: Define embedded_dtb_select for runtime DTB selection in U-boot ARM: keystone2: Define board_fit_config_name_match for Keystone 2 boards ks2_evm: Add EEPROM based board detection defconfig: keystone2: Enable U-boot runtime DTB detection ARM: keystone2: Add additional fields used for DDR3 configuration ARM: k2g: Program DDR PHY MR2 register with the default value ARM: k2g: Program DDRPHY_DATX8 registers via mask and value variables ks2_evm: Add EEPROM based board detection helper functions ARM: k2g: Add pinmux support for K2G ICE evm ARM: k2g: Add DDR3 configuration for K2G ICE evm board: ks2: Use board detection to wrap code not specific to K2G ICE evm ARM: k2g: Use board detection to wrap K2G GP specific calls ARM: k2g: Update board_name u-boot env variable at runtime ARM: dts: keystone-k2g: Remove skeleton.dtsi ARM: dts: keystone-k2g-evm: Add unit address to memory node ARM: dts: k2g: Disable netcp by default ARM: dts: k2g: Add DT support for K2G Industrial Communication Engine evm ARM: k2g: Add K2G ICE DTB to the list of possible DTBs defconfig: k2g_evm_defconfig: Add K2G ICE to OF_LIST Nishanth Menon (1): ti: common: board_detect: Allow settings board detection variables manually .gitignore | 1 + Makefile | 18 +++++- arch/arm/dts/Makefile | 4 +- arch/arm/dts/keystone-k2g-evm-u-boot.dtsi | 19 ++++++ arch/arm/dts/keystone-k2g-evm.dts | 9 +++ arch/arm/dts/keystone-k2g-generic-u-boot.dtsi | 19 ++++++ arch/arm/dts/keystone-k2g-generic.dts | 28 +++++++++ arch/arm/dts/keystone-k2g-ice-u-boot.dtsi | 19 ++++++ arch/arm/dts/keystone-k2g-ice.dts | 36 +++++++++++ arch/arm/dts/keystone-k2g-netcp.dtsi | 1 + arch/arm/dts/keystone-k2g.dtsi | 8 +-- arch/arm/mach-keystone/config.mk | 4 +- arch/arm/mach-keystone/ddr3.c | 35 ++++++++--- arch/arm/mach-keystone/include/mach/ddr3.h | 14 +++++ arch/arm/mach-keystone/include/mach/hardware.h | 3 + board/ti/common/board_detect.c | 34 ++++++++++ board/ti/common/board_detect.h | 26 ++++++++ board/ti/ks2_evm/board.c | 21 +++++-- board/ti/ks2_evm/board.h | 21 +++++++ board/ti/ks2_evm/board_k2e.c | 10 +++ board/ti/ks2_evm/board_k2g.c | 86 +++++++++++++++++++++++--- board/ti/ks2_evm/board_k2hk.c | 10 +++ board/ti/ks2_evm/board_k2l.c | 10 +++ board/ti/ks2_evm/ddr3_k2g.c | 78 ++++++++++++++++++++++- board/ti/ks2_evm/mux-k2g.h | 45 +++++++++++++- common/Kconfig | 16 +++++ common/Makefile | 2 + common/board_f.c | 3 + common/boot_fit.c | 58 +++++++++++++++++ common/common_fit.c | 86 ++++++++++++++++++++++++++ common/spl/spl_fit.c | 76 +---------------------- configs/k2e_evm_defconfig | 3 + configs/k2g_evm_defconfig | 3 + configs/k2hk_evm_defconfig | 3 + configs/k2l_evm_defconfig | 3 + dts/Kconfig | 11 ++-- include/boot_fit.h | 9 +++ include/common.h | 4 ++ include/configs/k2g_evm.h | 13 +++- include/image.h | 8 +++ lib/fdtdec.c | 10 +++ 41 files changed, 749 insertions(+), 118 deletions(-) create mode 100644 arch/arm/dts/keystone-k2g-evm-u-boot.dtsi create mode 100644 arch/arm/dts/keystone-k2g-generic-u-boot.dtsi create mode 100644 arch/arm/dts/keystone-k2g-generic.dts create mode 100644 arch/arm/dts/keystone-k2g-ice-u-boot.dtsi create mode 100644 arch/arm/dts/keystone-k2g-ice.dts create mode 100644 common/boot_fit.c create mode 100644 common/common_fit.c create mode 100644 include/boot_fit.h -- 2.10.0

2 43

[U-Boot] Please pull u-boot-x86
by Bin Meng 05 Jun '17

05 Jun '17

Hi Tom, The following changes since commit 5cafcbab580bac6c7f44ca4a164c422b7e1ecf20: Merge git://git.denx.de/u-boot-net (2017-06-03 18:05:28 -0400) are available in the git repository at: git://git.denx.de/u-boot-x86.git for you to fetch changes up to d7f7ba36b2edecb16393f8373cca833adb8ea6c3: x86: fsp: Remove the call to set up internal uart in fsp_init() (2017-06-05 08:55:22 +0800) ---------------------------------------------------------------- Bin Meng (6): x86: baytrail: Change "fsp, mrc-init-tseg-size" default value to 1 x86: baytrail: Remove "serial-debug-port-*" settings x86: baytrail: Use macros instead of magic numbers for FSP settings x86: baytrail: Change lpe/lpss-sio/scc FSP properties to integer x86: baytrail: Fix boot hang with a debug build x86: fsp: Remove the call to set up internal uart in fsp_init() arch/x86/cpu/baytrail/Kconfig | 4 ++++ arch/x86/cpu/baytrail/early_uart.c | 5 +++++ arch/x86/cpu/baytrail/fsp_configs.c | 50 ++++++++++++++++++++++++++------------------------ arch/x86/dts/bayleybay.dts | 25 ++++++++++++------------- arch/x86/dts/baytrail_som-db5800-som-6867.dts | 21 ++++++++++----------- arch/x86/dts/conga-qeval20-qa3-e3845.dts | 35 ++++++++++++++++++----------------- arch/x86/dts/dfi-bt700.dtsi | 35 ++++++++++++++++++----------------- arch/x86/dts/minnowmax.dts | 37 ++++++++++++++++++------------------- arch/x86/include/asm/arch-baytrail/fsp/fsp_configs.h | 87 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ arch/x86/include/asm/arch-baytrail/fsp/fsp_vpd.h | 9 ++++----- arch/x86/lib/fsp/fsp_support.c | 4 ---- doc/device-tree-bindings/misc/intel,baytrail-fsp.txt | 88 ++++++++++++++++++++++++++++------------------------------------------------------------ 12 files changed, 230 insertions(+), 170 deletions(-) Regards, Bin

2 1

[U-Boot] [PATCH v2 07/10] usb: dwc2: fix macro error and change default config for rk3328
by Meng Dongyang 05 Jun '17

05 Jun '17

Fix macro error of dwc2 driver, add macro definition to config force mode and HNP/SRP capability. Signed-off-by: Meng Dongyang <daniel.meng(a)rock-chips.com> --- Changes in v2: - Splited from patch [07/08] of v1 drivers/usb/host/dwc2.c | 9 ++++++++- drivers/usb/host/dwc2.h | 10 ++++++---- 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index 0e5df15..51619d6 100644 --- a/drivers/usb/host/dwc2.c +++ b/drivers/usb/host/dwc2.c @@ -370,7 +370,7 @@ static void dwc_otg_core_init(struct dwc2_priv *priv) usbcfg &= ~DWC2_GUSBCFG_DDRSEL; #endif } else { /* UTMI+ interface */ -#if (CONFIG_DWC2_UTMI_PHY_WIDTH == 16) +#if (CONFIG_DWC2_UTMI_WIDTH == 16) usbcfg |= DWC2_GUSBCFG_PHYIF; #endif } @@ -394,6 +394,11 @@ static void dwc_otg_core_init(struct dwc2_priv *priv) usbcfg |= DWC2_GUSBCFG_ULPI_CLK_SUS_M; } #endif + +#ifdef CONFIG_DWC2_FORCE_HOST_MODE + usbcfg |= DWC2_GUSBCFG_FORCEHOSTMODE; +#endif + writel(usbcfg, &regs->gusbcfg); /* Program the GAHBCFG Register. */ @@ -422,8 +427,10 @@ static void dwc_otg_core_init(struct dwc2_priv *priv) writel(ahbcfg, &regs->gahbcfg); +#ifdef CONFIG_DWC2_HNP_SRP_CAP /* Program the GUSBCFG register for HNP/SRP. */ setbits_le32(&regs->gusbcfg, DWC2_GUSBCFG_HNPCAP | DWC2_GUSBCFG_SRPCAP); +#endif #ifdef CONFIG_DWC2_IC_USB_CAP setbits_le32(&regs->gusbcfg, DWC2_GUSBCFG_IC_USB_CAP); diff --git a/drivers/usb/host/dwc2.h b/drivers/usb/host/dwc2.h index 4482dc6..3c62e9b 100644 --- a/drivers/usb/host/dwc2.h +++ b/drivers/usb/host/dwc2.h @@ -771,11 +771,11 @@ struct dwc2_core_regs { #define CONFIG_DWC2_MAX_TRANSFER_SIZE 65535 #define CONFIG_DWC2_MAX_PACKET_COUNT 511 -#define DWC2_PHY_TYPE_FS 0 -#define DWC2_PHY_TYPE_UTMI 1 -#define DWC2_PHY_TYPE_ULPI 2 +#define DWC2_PHY_TYPE_UTMI 0 +#define DWC2_PHY_TYPE_ULPI 1 +#define DWC2_PHY_TYPE_FS 2 #define CONFIG_DWC2_PHY_TYPE DWC2_PHY_TYPE_UTMI /* PHY type */ -#define CONFIG_DWC2_UTMI_WIDTH 8 /* UTMI bus width (8/16) */ +#define CONFIG_DWC2_UTMI_WIDTH 16 /* UTMI bus width (8/16) */ #undef CONFIG_DWC2_PHY_ULPI_DDR /* ULPI PHY uses DDR mode */ #define CONFIG_DWC2_PHY_ULPI_EXT_VBUS /* ULPI PHY controls VBUS */ @@ -785,5 +785,7 @@ struct dwc2_core_regs { #undef CONFIG_DWC2_THR_CTL /* Threshold control */ #define CONFIG_DWC2_TX_THR_LENGTH 64 #undef CONFIG_DWC2_IC_USB_CAP /* IC Cap */ +#define CONFIG_DWC2_FORCE_HOST_MODE /* Force host mode */ +#undef CONFIG_DWC2_HNP_SRP_CAP /* HNP/SRP Cap */ #endif /* __DWC2_H__ */ -- 1.9.1

4 4