Re: [U-Boot] [PATCH] serial: ns16550: Add register shift variable
Hi Tom, Felix, all > -Original Message- > From: Tom Rini [mailto:tr...@konsulko.com] > Sent: Saturday, July 14, 2018 6:50 PM > To: Wolfgang Denk > Cc: Felix Brack ; u-boot@lists.denx.de; Stefan Roese > ; Alexey Brodkin ; > Alexander Graf ; Michal Simek > Subject: Re: [U-Boot] [PATCH] serial: ns16550: Add register shift variable > > On Sat, Jul 14, 2018 at 12:47:21PM +0200, Wolfgang Denk wrote: > > Dear Felix, > > > > In message <1531492980-16543-1-git-send-email...@ltec.ch> you wrote: > > > > > > The motivation for writing this patch originates in the > > > effort of synchronizing U-Boot DT to Linux DT for am33xx SOCs. > > > The current am33xx.dtsi file from U-Boot defines the > > > property for all UART nodes. The actual (4.18+) am33xx.dtsi > > > file from Linux does not define anymore. To prevent > > > (probably difficult) changes in many .dts and .dtsi files once > > > the synchronization is done, one can use this new variable. For > > > the pdu001 board, for example, SYS_NS16550_REG_SHIFT is set > > > to 2; no need to clutter U-Boot and board specific dts files > > > with properties. > > > > Does this mean that U-Boot will not be able to use the same DTB as > > Linux? > > To be clear, it's the other way around. We can't use the Linux dtb/dts > files as they've dropped (and in other cases, aren't adding) these > properties as it's handled differently. Any chance to get a reference to the commit in Linux kernel that introduces that change? I still see a bunch of: ->8-- reg-shift = <2>; reg-io-width = <4>; ->8-- in .dts files for ARC boards even in linux-next git tree. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v2 1/2] Add BOOTCOUNT_BOOTLIMIT to set reboot limit
> -Original Message- > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Alex Kiernan > Sent: Saturday, July 14, 2018 1:30 PM > To: u-boot@lists.denx.de > Cc: Thomas Petazzoni ; Martyn Welch > ; Ian Ray > Subject: [U-Boot] [RESEND PATCH v2 1/2] Add BOOTCOUNT_BOOTLIMIT to set > reboot limit > > Add ability to set environment bootlimit from Kconfig > > Signed-off-by: Alex Kiernan > --- > > Changes in v2: None > > drivers/bootcount/Kconfig | 8 > include/env_default.h | 3 +++ > 2 files changed, 11 insertions(+) > > diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig index > d335ed14b9..9a0bd516d9 100644 > --- a/drivers/bootcount/Kconfig > +++ b/drivers/bootcount/Kconfig > @@ -72,6 +72,14 @@ config BOOTCOUNT_AT91 > > endchoice > > +config BOOTCOUNT_BOOTLIMIT > + int "Maximum number of reboot cycles allowed" > + default 0 > + help > + Set the Maximum number of reboot cycles allowed without the boot > + counter being cleared. > + If set to 0 do not set a boot limit in the environment. > + Just a curiosity, if maximum number of reboot cycles expires, what will be the behavior of u-boot? --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: ns16550: Add register shift variable
Hello Wolfgang, On 14.07.2018 12:47, Wolfgang Denk wrote: > Dear Felix, > > In message <1531492980-16543-1-git-send-email...@ltec.ch> you wrote: >> >> The motivation for writing this patch originates in the >> effort of synchronizing U-Boot DT to Linux DT for am33xx SOCs. >> The current am33xx.dtsi file from U-Boot defines the >> property for all UART nodes. The actual (4.18+) am33xx.dtsi >> file from Linux does not define anymore. To prevent >> (probably difficult) changes in many .dts and .dtsi files once >> the synchronization is done, one can use this new variable. For >> the pdu001 board, for example, SYS_NS16550_REG_SHIFT is set >> to 2; no need to clutter U-Boot and board specific dts files >> with properties. > > Does this mean that U-Boot will not be able to use the same DTB as > Linux? > This has already been answered very accurately by Tom. I have also written an RFC dealing with this: "[RFC] arm: dts: am33xx: Sync DTS with Linux 4.16.11", posted May 24. >> +config SYS_NS16550_REG_SHIFT >> +int "Number of bytes to shift register offsets" >> +default 0 >> +depends on SYS_NS16550 >> +help >> + Use this to specify the amount of bytes between discrete >> + device registers. If, for example, the device registers are >> + located at 0x00, 0x04, 0x08, 0x0C and so forth than set >> + this to 2. The default value is 0. > > This description is inconsistent or misleading. How do you define > "space between registers"? The unused gaps? In the example, the > registers are spaced at 4 bytes intervals, so a value of 2 would > only make sense of we have 16 bit registters and you count the gap > bytes. > > But this is a very strange and uncommon way to describe such a > situation, especially when you write that you "shift register > offsets". Here I think about something like a LSL operation, so > shifing by 2 bits would result in a 2^2 = 4 byte spacing. > > This needs to be rewritten. > You are right, sorry. It seems I used my brain to mix up two different explanations and that's the result - will be fixed. > > Best regards, > > Wolfgang Denk > regards, Felix ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: ns16550: Add register shift variable
Hi Tom, On 14.07.2018 17:49, Tom Rini wrote: > On Sat, Jul 14, 2018 at 12:47:21PM +0200, Wolfgang Denk wrote: >> Dear Felix, >> >> In message <1531492980-16543-1-git-send-email...@ltec.ch> you wrote: >>> >>> The motivation for writing this patch originates in the >>> effort of synchronizing U-Boot DT to Linux DT for am33xx SOCs. >>> The current am33xx.dtsi file from U-Boot defines the >>> property for all UART nodes. The actual (4.18+) am33xx.dtsi >>> file from Linux does not define anymore. To prevent >>> (probably difficult) changes in many .dts and .dtsi files once >>> the synchronization is done, one can use this new variable. For >>> the pdu001 board, for example, SYS_NS16550_REG_SHIFT is set >>> to 2; no need to clutter U-Boot and board specific dts files >>> with properties. >> >> Does this mean that U-Boot will not be able to use the same DTB as >> Linux? > > To be clear, it's the other way around. We can't use the Linux dtb/dts > files as they've dropped (and in other cases, aren't adding) these > properties as it's handled differently. > This is exactly the point. These files have diverged quite a lot between U-Boot and Linux since the last synchronization. I am trying to find a method to re-synchronize U-Boot generating minimal collateral damage - this patch is supposed to be part of that effort. In fact we could even set the default value of SYS_NS16550_REG_SHIFT to 2 for _all_ am33xx SOC boards. That would probably further reduce possible problems. >> >>> +config SYS_NS16550_REG_SHIFT >>> + int "Number of bytes to shift register offsets" >>> + default 0 >>> + depends on SYS_NS16550 >>> + help >>> + Use this to specify the amount of bytes between discrete >>> + device registers. If, for example, the device registers are >>> + located at 0x00, 0x04, 0x08, 0x0C and so forth than set >>> + this to 2. The default value is 0. >> >> This description is inconsistent or misleading. How do you define >> "space between registers"? The unused gaps? In the example, the >> registers are spaced at 4 bytes intervals, so a value of 2 would >> only make sense of we have 16 bit registters and you count the gap >> bytes. >> >> But this is a very strange and uncommon way to describe such a >> situation, especially when you write that you "shift register >> offsets". Here I think about something like a LSL operation, so >> shifing by 2 bits would result in a 2^2 = 4 byte spacing. >> >> This needs to be rewritten. > > To try and help clarify, the property in question means "quantity to > shift the register offsets by." It should be clear in our Kconfig help > entry as well that this is what we're looking for. > Thanks for this! The help text will be fixed in v2. regards Felix ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: ns16550: Add register shift variable
Hi Alexey,
On 15.07.2018 10:43, Alexey Brodkin wrote:
> Hi Tom, Felix, all
>
>> -Original Message-
>> From: Tom Rini [mailto:tr...@konsulko.com]
>> Sent: Saturday, July 14, 2018 6:50 PM
>> To: Wolfgang Denk
>> Cc: Felix Brack ; u-boot@lists.denx.de; Stefan Roese
>> ; Alexey Brodkin ;
>> Alexander Graf ; Michal Simek
>> Subject: Re: [U-Boot] [PATCH] serial: ns16550: Add register shift variable
>>
>> On Sat, Jul 14, 2018 at 12:47:21PM +0200, Wolfgang Denk wrote:
>>> Dear Felix,
>>>
>>> In message <1531492980-16543-1-git-send-email...@ltec.ch> you wrote:
The motivation for writing this patch originates in the
effort of synchronizing U-Boot DT to Linux DT for am33xx SOCs.
The current am33xx.dtsi file from U-Boot defines the
property for all UART nodes. The actual (4.18+) am33xx.dtsi
file from Linux does not define anymore. To prevent
(probably difficult) changes in many .dts and .dtsi files once
the synchronization is done, one can use this new variable. For
the pdu001 board, for example, SYS_NS16550_REG_SHIFT is set
to 2; no need to clutter U-Boot and board specific dts files
with properties.
>>>
>>> Does this mean that U-Boot will not be able to use the same DTB as
>>> Linux?
>>
>> To be clear, it's the other way around. We can't use the Linux dtb/dts
>> files as they've dropped (and in other cases, aren't adding) these
>> properties as it's handled differently.
>
> Any chance to get a reference to the commit in Linux kernel that introduces
> that change?
>
In fact I believe that the property never existed in the
am33xx.dtsi file from Linux. U-Boot commit 85cf0e6299 shows that the
property has been added to U-Boot's am33xx.dtsi file. The commit log
clearly states why this happened:
"With the commit 'c7b9686d5d48 ("ns16550: unify serial_omap")' all
TI platforms are broken with DM/DT boot as ns16550 driver expects
reg-shift from DT which is not populated for TI platforms.
Earlier it worked as it was hard coded to 2 in serial-omap
driver. So adding the reg-shift to serial nodes for dra7, am4372
and am33xx dtsi files. Tested this patch on am437x-sk-evm,
am437x-gp-evm, am335x-boneblack, dra74x-evm and dra72x-evm."
> I still see a bunch of:
> ->8--
> reg-shift = <2>;
> reg-io-width = <4>;
> ->8--
> in .dts files for ARC boards even in linux-next git tree.
>
> -Alexey
>
regards Felix
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Raspberry Pi / fdt_addr bug with environment
Hi, I found a funny bug. I don't think that is a raspberry pi only bug. It is the handling how env restore work. We use the origin device tree from first bootloader. We store also the environment to SSD for a fallback scenario. Now it store also the fdt_addr to environment. On next boot, it overwrite the origin fdt address with last known address from environment. It look like the rpi don't change the address a lot. I see that only after I update the firmware/first stage bootloader. I can fix that inside script with a workaround, but maybe we need change the handling of restore a bit? Greets Pascal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v2 1/2] Add BOOTCOUNT_BOOTLIMIT to set reboot limit
On Sun, Jul 15, 2018 at 10:36 AM Prabhakar Kushwaha wrote: > > > > -Original Message- > > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Alex Kiernan > > Sent: Saturday, July 14, 2018 1:30 PM > > To: u-boot@lists.denx.de > > Cc: Thomas Petazzoni ; Martyn Welch > > ; Ian Ray > > Subject: [U-Boot] [RESEND PATCH v2 1/2] Add BOOTCOUNT_BOOTLIMIT to set > > reboot limit > > > > Add ability to set environment bootlimit from Kconfig > > > > Signed-off-by: Alex Kiernan > > --- > > > > Changes in v2: None > > > > drivers/bootcount/Kconfig | 8 > > include/env_default.h | 3 +++ > > 2 files changed, 11 insertions(+) > > > > diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig index > > d335ed14b9..9a0bd516d9 100644 > > --- a/drivers/bootcount/Kconfig > > +++ b/drivers/bootcount/Kconfig > > @@ -72,6 +72,14 @@ config BOOTCOUNT_AT91 > > > > endchoice > > > > +config BOOTCOUNT_BOOTLIMIT > > + int "Maximum number of reboot cycles allowed" > > + default 0 > > + help > > + Set the Maximum number of reboot cycles allowed without the boot > > + counter being cleared. > > + If set to 0 do not set a boot limit in the environment. > > + > > Just a curiosity, if maximum number of reboot cycles expires, what will be > the behavior of u-boot? > It depends on which bootcount implementation you're using, I expect some are undefined. For the default based on a u32, it'll wrap to 0 (which IIRC is defined behaviour in C) and you'll go back to the bootcmd flow rather than altbootcmd. > --pk > > -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] watchdog: dm: Support manual relocation for watchdogs
Hi Michal, On 11 July 2018 at 23:47, Michal Simek wrote: > On 11.7.2018 22:13, Simon Glass wrote: >> On 11 July 2018 at 08:41, Michal Simek wrote: >>> Relocate watchdog ops as was done by: >>> "dm: Add support for all targets which requires MANUAL_RELOC" >>> (sha1: 484fdf5ba058b07be5ca82763aa2b72063540ef3) >>> >>> Signed-off-by: Michal Simek >>> --- >>> >>> based on https://lists.denx.de/pipermail/u-boot/2018-July/334227.html >>> >>> --- >>> drivers/watchdog/wdt-uclass.c | 23 +++ >>> 1 file changed, 23 insertions(+) >>> >> >> Reviewed-by: Simon Glass >> >> When will the toolchain be fixed? > > It is really several years back when I have looked at it last time but I > think that toolchain is fixed for quite some time and only changes in > microblaze u-boot code are needed but really I would have to check and > start to play with it. I think someone should sort this out. It would be good to remove this code. Is there a toolchain group at Xilinx? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/9] usb: rockchip: implement K_FW_LBA_READ_10 command
On 12 July 2018 at 05:05, Alberto Panizzo wrote: > This patch implement reading blocks form selected device with > LBA addressing. > > Corresponding command on workstation is: > rkdeveloptool rl > > While we support reading more than one blocks per K_FW_LBA_READ_10 > request, rkdeveloptool and original rockchip tool do perform > chunk reads limiting the maximum size per chunk far lower > than max int values. > > Signed-off-by: Alberto Panizzo > --- > arch/arm/include/asm/arch-rockchip/f_rockusb.h | 3 + > doc/README.rockusb | 1 + > drivers/usb/gadget/f_rockusb.c | 104 > - > 3 files changed, 107 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] microblaze: Do not call timer init that early
On 12 July 2018 at 00:44, Michal Simek wrote: > Timer needs to be converted to DM but as of now it can't be called so > early because intc controller is not ready. Call it later in board_r.c. > Before this patch timer_init is called twice which is wrong. > The patch is blocking initialization before relocation. > > Signed-off-by: Michal Simek > --- > > Changes in v2: > - Do not add new ifdef to board_f and use GD_FLG_RELOC instead - > reported-by sjg > - Change commit message > > arch/microblaze/cpu/timer.c | 4 > 1 file changed, 4 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 6/6] common: Generic loader for file system
Hi Tien Fong,
On 12 July 2018 at 01:19, Chee, Tien Fong wrote:
> On Wed, 2018-07-11 at 14:13 -0600, Simon Glass wrote:
>> Hi Tien,
>>
>> On 6 July 2018 at 02:28, wrote:
>> >
>> > From: Tien Fong Chee
>> >
>> > This is file system generic loader which can be used to load
>> > the file image from the storage into target such as memory.
>> > The consumer driver would then use this loader to program whatever,
>> > ie. the FPGA device.
>> >
>> > Signed-off-by: Tien Fong Chee
>> > ---
>> > drivers/misc/Kconfig | 10 ++
>> > drivers/misc/Makefile| 1 +
>> > drivers/misc/fs_loader.c | 295
>> > +++
>> > include/dm/uclass-id.h | 1 +
>> > include/fs_loader.h | 79 +
>> > 5 files changed, 386 insertions(+)
>> > create mode 100644 drivers/misc/fs_loader.c
>> > create mode 100644 include/fs_loader.h
>> >
[..]
>>
>> >
>> > + (*firmwarep)->priv = calloc(1, sizeof(struct
>> > firmware_priv));
>> > + if (!(*firmwarep)->priv) {
>> > + free(*firmwarep);
>> > + return -ENOMEM;
>> > + }
>> > + }
>> > +
>> > + ((struct firmware_priv *)((*firmwarep)->priv))->name =
>> > name;
>> Again this needs a local variable.
> Why?
Because these casts are really ugly and repetitive, particularly when
used for assignments :-)
[..]
>> > + * release_firmware - Release the resource associated with a
>> > firmware image
>> > + * @firmware: Firmware resource to release
>> > + */
>> > +void release_firmware(struct firmware *firmware);
>> > +
>> > +/**
>> > + * request_firmware_into_buf - Load firmware into a previously
>> > allocated buffer.
>> > + * @plat: Platform data such as storage and partition firmware
>> > loading from.
>> > + * @name: Name of firmware file.
>> > + * @buf: Address of buffer to load firmware into.
>> > + * @size: Size of buffer.
>> > + * @offset: Offset of a file for start reading into buffer.
>> > + * @firmwarep: Pointer to firmware image.
>> > + *
>> > + * The firmware is loaded directly into the buffer pointed to by
>> > @buf and
>> > + * the @firmwarep data member is pointed at @buf.
>> > + *
>> > + * Return: Size of total read, negative value when error.
>> > + */
>> > +int request_firmware_into_buf(struct device_platdata *plat,
>> > + const char *name,
>> > + void *buf, size_t size, u32 offset,
>> > + struct firmware **firmwarep);
>> Without a test it's hard to see how this is used, but I'm not keen on
>> the struct firmware ** here.
>>
>> Can you just use struct firmware * instead?
>>
>> Or maybe just return the fields individually since you only have
>> start
>> address and size, I think.
> I can try to remove struct firmware, let driver model handles all
> memory allocation, and then struct device_platdata *plat will change
> to struct udevice *dev. So, it would become like this
> int request_firmware_into_buf(struct udevice *dev,
> const char *name,
> void *buf, size_t size, u32 offset);
> I will remove release_firmware() after letting driver model to handle
> all memory deallocation.
> So, the API interface would looks a bit different compare to Linux
> firmware API interface. Does this change OK for you?
I believe you would need:
> int request_firmware_into_buf(struct udevice *dev,
> const char *name,
> void **bufp, size_t *sizep, u32 offset);
since you need to return the buffer and size?
What exactly is 'dev'? Is it the device in the FS_LOADER uclass?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] gpio: zynq: Read of mach data in platdata with dev_get_driver_data
On 12 July 2018 at 05:49, Michal Simek wrote: > Remove bogus zynq_gpio_getplat_data() and read driver data directly. > > Signed-off-by: Michal Simek > --- > > Driver should use platdata structure but this change should be fine > before this is fixed. > Simon: Is ofdata_to_platdata correct function where this should be read? Yes. > > --- > drivers/gpio/zynq_gpio.c | 29 ++--- > 1 file changed, 2 insertions(+), 27 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] gpio: dm: Support manual relocation for gpio
On 12 July 2018 at 05:36, Michal Simek wrote: > Relocate gpio ops as was done by: > "dm: Add support for all targets which requires MANUAL_RELOC" > (sha1: 484fdf5ba058b07be5ca82763aa2b72063540ef3) > > Signed-off-by: Michal Simek > --- > > drivers/gpio/gpio-uclass.c | 35 +++ > 1 file changed, 35 insertions(+) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sysreset: dm: Support manual relocation for sysreset
On 12 July 2018 at 05:35, Michal Simek wrote: > Relocate sysreset ops as was done by: > "dm: Add support for all targets which requires MANUAL_RELOC" > (sha1: 484fdf5ba058b07be5ca82763aa2b72063540ef3) > > Signed-off-by: Michal Simek > --- > > drivers/sysreset/sysreset-uclass.c | 16 > 1 file changed, 16 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] test: Fix test_vboot to call openssl without redirection
Hi Stephen, On 8 June 2018 at 00:02, Simon Glass wrote: > > Hi Stephen, > > On 16 May 2018 at 12:57, Simon Glass wrote: > > Hi Stephen, > > > > On 16 May 2018 at 09:55, Stephen Warren wrote: > >> On 05/16/2018 01:10 AM, Simon Glass wrote: > >>> > >>> The redirection seems to cause this test to fail now. It isn't needed, so > >>> drop it. > >> > >> > >> I guess I have no particular objection to this, but I will point out that > >> the test is working just fine as-is right now, so it might be worth > >> investigating more re: what the error is and why it's happening... It'd be > >> good to describe the details of the failure in the commit description too. > > > > So the test works OK for you? For me it fails. I'll update the commit > > message. > > > > # Store the output so it can be accessed if we raise an exception. > > self.output = output > > self.exit_status = exit_status > > if exception: > >> raise exception > > E Exception: Exit code: 1 > > > > test/py/multiplexed_log.py:173: Exception > > --- Captured stdout call > > --- > > +openssl genpkey -algorithm RSA -out > > /usr/local/google/home/sjg/cosarm/src/third_party/u-boot/files/build-sandbox/dev.key > > -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537 > > 2>/dev/null > > genpkey: Use -help for summary. > > Exit code: 1 > > > > From Stephen: > > > Yes. I just double-checked and it's definitely running in Jenkins for me; > > not being skipped or anything. It's running on Denx u-boot.git, > > u-boot-dm.git and a slew of others too. I assume it's running on Travis CI > > without issue too. > > > I'm running Ubuntu 16.04 right now, but only recently upgraded from 14.04 > > where I believe the test was running without issue too. Is this issue > > OS-specific or Python-version-specific (I have 2.7.12)? > > I am really not sure what is going on...I can definitely repeat this > but only on my workstation, not my laptop. > > I will see if I can dig into it further. I found a patch from someone else from a while back, which you had reviewed :-) So I applied that. The redirection only works if a shell is being used, and it normally isn't. We certainly are not requesting a shell when calling subprocess. As to why on some machines we appear to get one anyway, I cannot comment. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/9] usb: rockchip: boost up write speed from 4MB/s to 15MB/s
On 12 July 2018 at 05:05, Alberto Panizzo wrote: > Speedup transfers increasing the max chunk size. > Buffers are allocated with memalign thus developer is noticed when heap is > full and in current configuration a buffer allocation of 64K till now > is safe. > > Signed-off-by: Alberto Panizzo > --- > arch/arm/include/asm/arch-rockchip/f_rockusb.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Really your commit subject should say that you are increasing the buffer size IMO, since that is the change. Then your commit message can discuss motivation and impact. Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/9] usb: rockchip: implement K_FW_LBA_ERASE_10 command
On 12 July 2018 at 05:05, Alberto Panizzo wrote: > This command is part of the write partition sequence performed by > rkdeveloptool: one partition is first completely erased and > than wrote. > > Signed-off-by: Alberto Panizzo > --- > arch/arm/include/asm/arch-rockchip/f_rockusb.h | 1 + > doc/README.rockusb | 1 + > drivers/usb/gadget/f_rockusb.c | 48 > ++ > 3 files changed, 50 insertions(+) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/9] rockchip: rk3288: implement reading chip version from bootrom code
On 12 July 2018 at 05:05, Alberto Panizzo wrote: > This allows rockusb code to reply correctly to K_FW_GET_CHIP_VER > command. > > On RK3288 chip version is at 0x4ff0 and on tested hardware it > corresponds at the string "320A20140813V200" > > Signed-off-by: Alberto Panizzo > --- > arch/arm/mach-rockchip/rk3288/Makefile | 1 + > arch/arm/mach-rockchip/rk3288/rockusb_rk3288.c | 30 > ++ > 2 files changed, 31 insertions(+) > create mode 100644 arch/arm/mach-rockchip/rk3288/rockusb_rk3288.c Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/1] Sandbox: provide default dtb
Hi Heinrich, On 15 June 2018 at 14:06, Heinrich Schuchardt wrote: > Provide sandbox.dtb as default device tree for sandbox_defconfig. > > We can use the dtb with > > ./u-boot -d u-boot.dtb > > Signed-off-by: Heinrich Schuchardt > --- > v2 > adjust commit message > --- > configs/sandbox_defconfig | 1 + > 1 file changed, 1 insertion(+) I afraid I still don't understand the purpose of this patch. Can you please expand the commit message? Also please reference -D since that is supposed to provide the default DT. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] gpio: zynq: Setup bank_name to dev->name
On 12 July 2018 at 08:04, Michal Simek wrote: > There should be proper bank name setup to distiguish between different > gpio drivers. Use dev->name for it. > > Signed-off-by: Michal Simek > --- > > drivers/gpio/zynq_gpio.c | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Simon Glass Normally these would be named A, B, C, etc. Is there no such naming convention on zynq? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Microblaze gpio reset handling
Hi Michal,
On 12 July 2018 at 08:28, Michal Simek wrote:
> Hi Simon,
>
> I have looked at converting the rest of microblaze drivers to DM and I
> am curious why I can't use top level compatible string in DM based drivers.
> I am looking at ways how to move gpio and microblaze soft reset to
> sysreset framework and I see that core is not able to find out my high
> level xlnx,microblaze compatible string.
>
>
> / {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "xlnx,microblaze";
> model = "Xilinx MicroBlaze";
> hard-reset-gpios = <&reset_gpio 0 1>;
>
> As far I have seen only nodes are checked but unfortunately Microblaze
> is using hard-reset-gpios in root for years and will be good to keep it
> like that.
>
> I have already tested to bind that driver from board file like
> device_bind_driver(gd->dm_root, "microblaze_sysreset", "reset", NULL);
> which is working fine but just asking if there is another solution for this.
Not at present. But I think we should actually try to bind a driver to
the root node. Probably needs changes to root.c.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4 v3] armv8: fsl: remove sata support
On 13 July 2018 at 03:25, wrote: > From: Yuantian Tang > > Remove the old implementation in order to enable DM for sata > > Signed-off-by: Tang Yuantian > --- > v3: > - rebase to latest code > v2: > - no changes > > arch/arm/cpu/armv8/fsl-layerscape/soc.c| 54 > > arch/arm/include/asm/arch-fsl-layerscape/soc.h | 32 -- > 2 files changed, 0 insertions(+), 86 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4 v3] armv8: dts: fsl-ls1012a: add sata node support
On 13 July 2018 at 03:25, wrote: > From: Yuantian Tang > > One ls1012a, there is one SATA 3.0 advanced host controller interface > which is a high-performance SATA solution that delivers comprehensive > and fully-compliant generation 3 (1.5 Gb/s - 6.0 Gb/s) serial ATA > capabilities, in accordance with the serial ATA revision 3.0 of Serial > ATA International Organization. > Add sata node to support this feature. > > Signed-off-by: Tang Yuantian > --- > v3: > - no changes > v2: > - add qds and 2g5rdb board support > > arch/arm/dts/fsl-ls1012a-2g5rdb.dts |4 > arch/arm/dts/fsl-ls1012a-qds.dtsi |4 > arch/arm/dts/fsl-ls1012a-rdb.dtsi |4 > arch/arm/dts/fsl-ls1012a.dtsi |8 > 4 files changed, 20 insertions(+), 0 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] stm32mp1: add gpio led support
On 13 July 2018 at 09:21, Patrick Delaunay wrote: > This patch add the 4 LED available on the ED1 board and activated > gpio led driver. > > Signed-off-by: Patrick Delaunay > --- > > arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 24 > configs/stm32mp15_basic_defconfig| 2 ++ > 2 files changed, 26 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ v2 03/10] video: add support of MIPI DSI interface
On 13 July 2018 at 06:11, Yannick Fertré wrote:
> Mipi_display.c contains a set of dsi helpers.
> This file is a copy of file drm_mipi_dsi.c (linux kernel).
>
> Signed-off-by: Yannick Fertré
> ---
> drivers/video/Kconfig| 9 +
> drivers/video/Makefile | 1 +
> drivers/video/mipi_display.c | 817
> +++
> include/mipi_display.h | 257 +-
> 4 files changed, 1083 insertions(+), 1 deletion(-)
> create mode 100644 drivers/video/mipi_display.c
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 5ee9032..560da1a 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -73,6 +73,15 @@ config VIDEO_ANSI
> Enable ANSI escape sequence decoding for a more fully functional
> console.
>
> +config VIDEO_MIPI_DSI
> + bool "Support MIPI DSI interface"
> + depends on DM_VIDEO
> + default y if DM_VIDEO
Why default y? Many boards won't use MIPI.
> + help
> + Support MIPI DSI interface for driving a MIPI compatible device.
> + The MIPI Display Serial Interface (MIPI DSI) defines a high-speed
> + serial interface between a host processor and a display module.
> +
> config CONSOLE_NORMAL
[..]
> diff --git a/include/mipi_display.h b/include/mipi_display.h
> index ddcc8ca..5c3dbbe 100644
> --- a/include/mipi_display.h
> +++ b/include/mipi_display.h
> @@ -4,12 +4,16 @@
> *
> * Copyright (C) 2010 Guennadi Liakhovetski
> * Copyright (C) 2006 Nokia Corporation
> - * Author: Imre Deak
> + * Copyright (C) 2018 STMicroelectronics - All Rights Reserved
> + * Author(s): Imre Deak
> + *Yannick Fertre
> + *Philippe Cornu
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 as
> * published by the Free Software Foundation.
> */
> +
> #ifndef MIPI_DISPLAY_H
> #define MIPI_DISPLAY_H
>
> @@ -115,6 +119,14 @@ enum {
> MIPI_DCS_READ_MEMORY_CONTINUE = 0x3E,
> MIPI_DCS_SET_TEAR_SCANLINE = 0x44,
> MIPI_DCS_GET_SCANLINE = 0x45,
> + MIPI_DCS_SET_DISPLAY_BRIGHTNESS = 0x51, /* MIPI DCS 1.3 */
> + MIPI_DCS_GET_DISPLAY_BRIGHTNESS = 0x52, /* MIPI DCS 1.3 */
> + MIPI_DCS_WRITE_CONTROL_DISPLAY = 0x53, /* MIPI DCS 1.3 */
> + MIPI_DCS_GET_CONTROL_DISPLAY= 0x54, /* MIPI DCS 1.3 */
> + MIPI_DCS_WRITE_POWER_SAVE = 0x55, /* MIPI DCS 1.3 */
> + MIPI_DCS_GET_POWER_SAVE = 0x56, /* MIPI DCS 1.3 */
> + MIPI_DCS_SET_CABC_MIN_BRIGHTNESS = 0x5E,/* MIPI DCS 1.3 */
> + MIPI_DCS_GET_CABC_MIN_BRIGHTNESS = 0x5F,/* MIPI DCS 1.3 */
> MIPI_DCS_READ_DDB_START = 0xA1,
> MIPI_DCS_READ_DDB_CONTINUE = 0xA8,
> };
> @@ -127,4 +139,247 @@ enum {
> #define MIPI_DCS_PIXEL_FMT_8BIT2
> #define MIPI_DCS_PIXEL_FMT_3BIT1
>
> +struct mipi_dsi_host;
> +struct mipi_dsi_device;
> +
> +/* request ACK from peripheral */
> +#define MIPI_DSI_MSG_REQ_ACK BIT(0)
> +/* use Low Power Mode to transmit message */
> +#define MIPI_DSI_MSG_USE_LPM BIT(1)
> +
> +/**
> + * struct mipi_dsi_msg - read/write DSI buffer
> + * @channel: virtual channel id
> + * @type: payload data type
> + * @flags: flags controlling this message transmission
> + * @tx_len: length of @tx_buf
> + * @tx_buf: data to be written
> + * @rx_len: length of @rx_buf
> + * @rx_buf: data to be read, or NULL
> + */
> +struct mipi_dsi_msg {
> + u8 channel;
> + u8 type;
> + u16 flags;
> +
> + size_t tx_len;
> + const void *tx_buf;
> +
> + size_t rx_len;
> + void *rx_buf;
> +};
> +
> +bool mipi_dsi_packet_format_is_short(u8 type);
> +bool mipi_dsi_packet_format_is_long(u8 type);
> +
> +/**
> + * struct mipi_dsi_packet - represents a MIPI DSI packet in protocol format
> + * @size: size (in bytes) of the packet
> + * @header: the four bytes that make up the header (Data ID, Word Count or
> + * Packet Data, and ECC)
> + * @payload_length: number of bytes in the payload
> + * @payload: a pointer to a buffer containing the payload, if any
> + */
> +struct mipi_dsi_packet {
> + size_t size;
> + u8 header[4];
> + size_t payload_length;
> + const u8 *payload;
> +};
> +
> +int mipi_dsi_create_packet(struct mipi_dsi_packet *packet,
> + const struct mipi_dsi_msg *msg);
> +
> +/**
> + * struct mipi_dsi_host_ops - DSI bus operations
> + * @attach: attach DSI device to DSI host
> + * @detach: detach DSI device from DSI host
> + * @transfer: transmit a DSI packet
> + *
> + * DSI packets transmitted by .transfer() are passed in as mipi_dsi_msg
> + * structures. This structure contains information about the type of packet
> + * being transmitted as well as the transmit and receive buffers. When an
> + * error is encoun
Re: [U-Boot] [ v2 06/10] video: add MIPI DSI host controller bridge
Hi Yannick,
On 13 July 2018 at 06:11, Yannick Fertré wrote:
> Add a Synopsys Designware MIPI DSI host bridge driver, based on the
> Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.
>
> Signed-off-by: Yannick Fertré
> ---
> drivers/video/Kconfig | 9 +
> drivers/video/Makefile | 1 +
> drivers/video/dw_mipi_dsi.c | 826
>
> include/dw_mipi_dsi.h | 32 ++
> 4 files changed, 868 insertions(+)
> create mode 100644 drivers/video/dw_mipi_dsi.c
> create mode 100644 include/dw_mipi_dsi.h
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index e1029e5..3ccc8df 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -674,6 +674,15 @@ config VIDEO_DW_HDMI
> rather requires a SoC-specific glue driver to call it), it
> can not be enabled from the configuration menu.
>
> +config VIDEO_DW_MIPI_DSI
> + bool
> + help
> + Enables the common driver code for the Synopsis Designware
> + MIPI DSI block found in SoCs from various vendors.
> + As this does not provide any functionality by itself (but
> + rather requires a SoC-specific glue driver to call it), it
> + can not be enabled from the configuration menu.
> +
> config VIDEO_SIMPLE
> bool "Simple display driver for preconfigured display"
> help
> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> index 018343f..bb2fd3c 100644
> --- a/drivers/video/Makefile
> +++ b/drivers/video/Makefile
> @@ -52,6 +52,7 @@ obj-$(CONFIG_FORMIKE) += formike.o
> obj-$(CONFIG_LG4573) += lg4573.o
> obj-$(CONFIG_AM335X_LCD) += am335x-fb.o
> obj-$(CONFIG_VIDEO_DW_HDMI) += dw_hdmi.o
> +obj-$(CONFIG_VIDEO_DW_MIPI_DSI) += dw_mipi_dsi.o
> obj-${CONFIG_VIDEO_MIPI_DSI} += mipi_display.o
> obj-$(CONFIG_VIDEO_SIMPLE) += simplefb.o
> obj-${CONFIG_VIDEO_TEGRA124} += tegra124/
> diff --git a/drivers/video/dw_mipi_dsi.c b/drivers/video/dw_mipi_dsi.c
> new file mode 100644
> index 000..db278c5
> --- /dev/null
> +++ b/drivers/video/dw_mipi_dsi.c
> @@ -0,0 +1,826 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2016, Fuzhou Rockchip Electronics Co., Ltd
> + * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
> + * Author(s): Philippe Cornu for STMicroelectronics.
> + *Yannick Fertre for STMicroelectronics.
> + *
> + * This generic Synopsys DesignWare MIPI DSI host driver is inspired from
> + * the Linux Kernel driver drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Please check the ordering here.
> +
> +#define HWVER_131 0x31333100 /* IP version 1.31 */
> +
> +#define DSI_VERSION0x00
> +#define VERSIONGENMASK(31, 8)
> +
> +#define DSI_PWR_UP 0x04
> +#define RESET 0
> +#define POWERUPBIT(0)
> +
> +#define DSI_CLKMGR_CFG 0x08
> +#define TO_CLK_DIVISION(div) (((div) & 0xff) << 8)
> +#define TX_ESC_CLK_DIVISION(div) ((div) & 0xff)
Instead of this can you use something like:
#define TO_CLK_DIVISION_SHIFT 8
#define TO_CLK_DIVISION_MASK (0xff << TO_CLK_DIVISION_SHIFT)
then do the shift in the code which need it below.
xxx << TO_CLK_DIVISION_SHIFT
> diff --git a/include/dw_mipi_dsi.h b/include/dw_mipi_dsi.h
> new file mode 100644
> index 000..f8482f7
> --- /dev/null
> +++ b/include/dw_mipi_dsi.h
> @@ -0,0 +1,32 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (C) 2017-2018, STMicroelectronics - All Rights Reserved
> + *
> + * Authors: Yannick Fertre
> + * Philippe Cornu
> + *
> + * This generic Synopsys DesignWare MIPI DSI host include is inspired from
> + * the Linux Kernel include file include/drm/bridge/dw_mipi_dsi.h.
> + */
> +
> +#ifndef __DW_MIPI_DSI__
> +#define __DW_MIPI_DSI__
> +
> +#include
> +
> +struct dw_mipi_dsi_phy_ops {
> + int (*init)(void *priv_data);
> + int (*get_lane_mbps)(void *priv_data, struct display_timing *timings,
> +u32 lanes, u32 format, unsigned int *lane_mbps);
> +};
> +
> +struct dw_mipi_dsi_plat_data {
> + unsigned int max_data_lanes;
> + const struct dw_mipi_dsi_phy_ops *phy_ops;
> + struct udevice *panel;
> +};
> +
> +int dw_mipi_dsi_init_bridge(struct mipi_dsi_device *device);
> +void dw_mipi_dsi_bridge_enable(struct mipi_dsi_device *device);
This should be in a uclass I think.
Regards
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] stm32mp1: use new function led default state
On 13 July 2018 at 09:21, Patrick Delaunay wrote: > Initialize the led with the default state defined in device tree. > > Signed-off-by: Patrick Delaunay > --- > > board/st/stm32mp1/stm32mp1.c | 4 > 1 file changed, 4 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ v2 01/10] dm: panel: get timings from panel
On 13 July 2018 at 06:11, Yannick Fertré wrote: > Get timings from panel instead of read device tree. > > Signed-off-by: Yannick Fertré > --- > drivers/video/panel-uclass.c | 11 +++ > include/panel.h | 18 ++ > 2 files changed, 29 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] dm: led: move default state support in led uclass
On 13 July 2018 at 09:21, Patrick Delaunay wrote: > This patch save common LED property "default-state" value > in post bind of LED uclass. > The configuration for this default state is only performed when > led_default_state() is called; > It can be called in your board_init() > or it could added in init_sequence_r[] in future. > > Signed-off-by: Patrick Delaunay > --- > > drivers/led/led-uclass.c | 54 > > drivers/led/led_gpio.c | 8 --- > include/led.h| 23 + > 3 files changed, 77 insertions(+), 8 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ v2 05/10] video: add support of panel RM68200
On 13 July 2018 at 06:11, Yannick Fertré wrote: > Support for Raydium RM68200 720p dsi 2dl video mode panel. > This rm68200 panel driver is based on the Linux Kernel driver from > drivers/gpu/drm/panel/panel-raydium-rm68200.c. > > Signed-off-by: Yannick Fertré > --- > drivers/video/Kconfig | 8 + > drivers/video/Makefile | 1 + > drivers/video/raydium-rm68200.c | 338 > > 3 files changed, 347 insertions(+) > create mode 100644 drivers/video/raydium-rm68200.c > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ v2 04/10] video: add support of panel OTM8009A
On 13 July 2018 at 06:11, Yannick Fertré wrote: > Support for Orise Tech otm8009a 480p dsi 2dl video mode panel. > > Signed-off-by: Yannick Fertré > --- > drivers/video/Kconfig | 8 + > drivers/video/Makefile | 1 + > drivers/video/orisetech_otm8009a.c | 366 > + > 3 files changed, 375 insertions(+) > create mode 100644 drivers/video/orisetech_otm8009a.c Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sysreset: Add support for gpio-restart
Hi Michal,
On 13 July 2018 at 03:15, Michal Simek wrote:
> The Linux kernel has binding for gpio-restart node.
> This patch is adding basic support without supporting any optional
> properties.
> This driver was tested on Microblaze system where gpio is connected to
> SoC reset logic.
> Output value is handled via gpios cells values.
>
> In gpio_reboot_request() set_value is writing 1 because
> dm_gpio_set_value() is capable to changing it when it is ACTIVE_LOW.
> ...
> if (desc->flags & GPIOD_ACTIVE_LOW)
> value = !value;
> ...
>
> Signed-off-by: Michal Simek
> ---
>
> drivers/sysreset/Kconfig | 6
> drivers/sysreset/Makefile| 1 +
> drivers/sysreset/sysreset_gpio.c | 59
>
> 3 files changed, 66 insertions(+)
> create mode 100644 drivers/sysreset/sysreset_gpio.c
Reviewed-by: Simon Glass
But please see below.
>
> diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
> index a6d48e8a662c..1e228b97443a 100644
> --- a/drivers/sysreset/Kconfig
> +++ b/drivers/sysreset/Kconfig
> @@ -15,6 +15,12 @@ config SYSRESET
>
> if SYSRESET
>
> +config SYSRESET_GPIO
> + bool "Enable support for GPIO restart driver"
> + select GPIO
> + help
> + Restart support via GPIO pin connected reset logic.
What does this mean? Please expand this to explain what it means.
Also, what is the difference between restart and reset? If there is no
difference please use the word 'reset'. If there is a difference,
please explain it here.
> +
> config SYSRESET_PSCI
> bool "Enable support for PSCI System Reset"
> depends on ARM_PSCI_FW
> diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
> index 0da58a1cf6ad..ca533cfefaad 100644
> --- a/drivers/sysreset/Makefile
> +++ b/drivers/sysreset/Makefile
> @@ -3,6 +3,7 @@
> # (C) Copyright 2016 Cadence Design Systems Inc.
>
> obj-$(CONFIG_SYSRESET) += sysreset-uclass.o
> +obj-$(CONFIG_SYSRESET_GPIO) += sysreset_gpio.o
> obj-$(CONFIG_SYSRESET_PSCI) += sysreset_psci.o
> obj-$(CONFIG_SYSRESET_SYSCON) += sysreset_syscon.o
> obj-$(CONFIG_SYSRESET_WATCHDOG) += sysreset_watchdog.o
> diff --git a/drivers/sysreset/sysreset_gpio.c
> b/drivers/sysreset/sysreset_gpio.c
> new file mode 100644
> index ..4c1c1510f285
> --- /dev/null
> +++ b/drivers/sysreset/sysreset_gpio.c
> @@ -0,0 +1,59 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 Xilinx, Inc. - Michal Simek
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct gpio_reboot_priv {
> + struct gpio_desc gpio;
> +};
> +
> +static int gpio_reboot_request(struct udevice *dev, enum sysreset_t type)
> +{
> + struct gpio_reboot_priv *priv = dev_get_priv(dev);
> +
> + /*
> +* When debug log is enabled please make sure that chars won't end up
> +* in output fifo. Or you can append udelay(); to get enough time
> +* to HW to emit output fifo.
> +*/
> + debug("GPIO restart\n");
> +
> + /* 1 is just setting value - based on gpio->flags 0 or 1 is written */
Do you mean that it respects polarity (active high/low)? If so, it
might be less confusing to state that.
> + return dm_gpio_set_value(&priv->gpio, 1);
> +}
> +
> +static struct sysreset_ops gpio_reboot_ops = {
> + .request = gpio_reboot_request,
> +};
> +
> +int gpio_reboot_probe(struct udevice *dev)
> +{
> + struct gpio_reboot_priv *priv = dev_get_priv(dev);
> +
> + /*
> +* Linux kernel DT binding contain others optional properties
> +* which are not supported now
> +*/
> +
> + return gpio_request_by_name(dev, "gpios", 0, &priv->gpio,
> GPIOD_IS_OUT);
> +}
> +
> +static const struct udevice_id led_gpio_ids[] = {
> + { .compatible = "gpio-restart" },
> + { }
> +};
> +
> +U_BOOT_DRIVER(gpio_reboot) = {
> + .id = UCLASS_SYSRESET,
> + .name = "gpio_restart",
> + .of_match = led_gpio_ids,
> + .ops = &gpio_reboot_ops,
> + .priv_auto_alloc_size = sizeof(struct gpio_reboot_priv),
> + .probe = gpio_reboot_probe,
> +};
> --
> 1.9.1
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] Revert "dm: led: auto probe() LEDs with "default-state""
On 13 July 2018 at 09:21, Patrick Delaunay wrote: > This reverts commit bc882f5d5c7b4d6ed5e927bf838863af43c786e7. > > Signed-off-by: Patrick Delaunay > --- > > drivers/led/led_gpio.c | 9 - > 1 file changed, 9 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: fix fdtdec_setup_memory_banksize()
On 13 July 2018 at 04:12, Jens Wiklander wrote: > Prior to this patch is fdtdec_setup_memory_banksize() incorrectly > ignoring the "status" field. This patch fixes that by testing the status > with fdtdec_get_is_enabled() before using a memory node. > > Signed-off-by: Jens Wiklander > --- > lib/fdtdec.c | 20 +++- > 1 file changed, 15 insertions(+), 5 deletions(-) Reviewed-by: Simon Glass But can you convert this to livetree at the same time? E.g. use ofnode functions. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] gpio: zynq: Setup bank_name to dev->name
On 16.7.2018 07:19, Simon Glass wrote: > On 12 July 2018 at 08:04, Michal Simek wrote: >> There should be proper bank name setup to distiguish between different >> gpio drivers. Use dev->name for it. >> >> Signed-off-by: Michal Simek >> --- >> >> drivers/gpio/zynq_gpio.c | 2 ++ >> 1 file changed, 2 insertions(+) > > Reviewed-by: Simon Glass > > Normally these would be named A, B, C, etc. Is there no such naming > convention on zynq? PS(Hard) part has only one gpio controller with several banks with are using the same address space. We are using from the beginning flat number scheme that's why only one name is used for all banks. Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/1] Sandbox: provide default dtb
On 07/15/2018 11:22 PM, Simon Glass wrote: > Hi Heinrich, > > On 15 June 2018 at 14:06, Heinrich Schuchardt wrote: >> Provide sandbox.dtb as default device tree for sandbox_defconfig. >> >> We can use the dtb with >> >> ./u-boot -d u-boot.dtb >> >> Signed-off-by: Heinrich Schuchardt >> --- >> v2 >> adjust commit message >> --- >> configs/sandbox_defconfig | 1 + >> 1 file changed, 1 insertion(+) > > I afraid I still don't understand the purpose of this patch. Can you > please expand the commit message? Also please reference -D since that > is supposed to provide the default DT. > > Regards, > Simon > With current master ./u-boot -D provides ethernet. So we don't this patch. Regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sysreset: Add support for gpio-restart
On 16.7.2018 07:20, Simon Glass wrote:
> Hi Michal,
>
> On 13 July 2018 at 03:15, Michal Simek wrote:
>> The Linux kernel has binding for gpio-restart node.
>> This patch is adding basic support without supporting any optional
>> properties.
>> This driver was tested on Microblaze system where gpio is connected to
>> SoC reset logic.
>> Output value is handled via gpios cells values.
>>
>> In gpio_reboot_request() set_value is writing 1 because
>> dm_gpio_set_value() is capable to changing it when it is ACTIVE_LOW.
>> ...
>> if (desc->flags & GPIOD_ACTIVE_LOW)
>> value = !value;
>> ...
>>
>> Signed-off-by: Michal Simek
>> ---
>>
>> drivers/sysreset/Kconfig | 6
>> drivers/sysreset/Makefile| 1 +
>> drivers/sysreset/sysreset_gpio.c | 59
>>
>> 3 files changed, 66 insertions(+)
>> create mode 100644 drivers/sysreset/sysreset_gpio.c
>
> Reviewed-by: Simon Glass
>
> But please see below.
>
>>
>> diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
>> index a6d48e8a662c..1e228b97443a 100644
>> --- a/drivers/sysreset/Kconfig
>> +++ b/drivers/sysreset/Kconfig
>> @@ -15,6 +15,12 @@ config SYSRESET
>>
>> if SYSRESET
>>
>> +config SYSRESET_GPIO
>> + bool "Enable support for GPIO restart driver"
>> + select GPIO
>> + help
>> + Restart support via GPIO pin connected reset logic.
>
> What does this mean? Please expand this to explain what it means.
>
> Also, what is the difference between restart and reset? If there is no
> difference please use the word 'reset'. If there is a difference,
> please explain it here.
I have taken restart name because this is what it is written Linux kernel.
Based on this explanation:
https://kb.netgear.com/1001/Defining-Terms-Power-Cycle-Boot-Reboot-Restart-Reset-and-Hard-Reset
"Unlike a reset which changes something, a restart means to turn
something on, possibly without changing settings. When upgrading
firmware or software you are often asked to restart. A restart would be
probably be used if there were a major change to functionality, while a
reset often just changes settings of existing functionality."
>> +
>> config SYSRESET_PSCI
>> bool "Enable support for PSCI System Reset"
>> depends on ARM_PSCI_FW
>> diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
>> index 0da58a1cf6ad..ca533cfefaad 100644
>> --- a/drivers/sysreset/Makefile
>> +++ b/drivers/sysreset/Makefile
>> @@ -3,6 +3,7 @@
>> # (C) Copyright 2016 Cadence Design Systems Inc.
>>
>> obj-$(CONFIG_SYSRESET) += sysreset-uclass.o
>> +obj-$(CONFIG_SYSRESET_GPIO) += sysreset_gpio.o
>> obj-$(CONFIG_SYSRESET_PSCI) += sysreset_psci.o
>> obj-$(CONFIG_SYSRESET_SYSCON) += sysreset_syscon.o
>> obj-$(CONFIG_SYSRESET_WATCHDOG) += sysreset_watchdog.o
>> diff --git a/drivers/sysreset/sysreset_gpio.c
>> b/drivers/sysreset/sysreset_gpio.c
>> new file mode 100644
>> index ..4c1c1510f285
>> --- /dev/null
>> +++ b/drivers/sysreset/sysreset_gpio.c
>> @@ -0,0 +1,59 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (C) 2018 Xilinx, Inc. - Michal Simek
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +struct gpio_reboot_priv {
>> + struct gpio_desc gpio;
>> +};
>> +
>> +static int gpio_reboot_request(struct udevice *dev, enum sysreset_t type)
>> +{
>> + struct gpio_reboot_priv *priv = dev_get_priv(dev);
>> +
>> + /*
>> +* When debug log is enabled please make sure that chars won't end up
>> +* in output fifo. Or you can append udelay(); to get enough time
>> +* to HW to emit output fifo.
>> +*/
>> + debug("GPIO restart\n");
>> +
>> + /* 1 is just setting value - based on gpio->flags 0 or 1 is written
>> */
>
> Do you mean that it respects polarity (active high/low)? If so, it
> might be less confusing to state that.
ok - will update.
>
>> + return dm_gpio_set_value(&priv->gpio, 1);
>> +}
>> +
>> +static struct sysreset_ops gpio_reboot_ops = {
>> + .request = gpio_reboot_request,
>> +};
>> +
>> +int gpio_reboot_probe(struct udevice *dev)
>> +{
>> + struct gpio_reboot_priv *priv = dev_get_priv(dev);
>> +
>> + /*
>> +* Linux kernel DT binding contain others optional properties
>> +* which are not supported now
>> +*/
>> +
>> + return gpio_request_by_name(dev, "gpios", 0, &priv->gpio,
>> GPIOD_IS_OUT);
>> +}
>> +
>> +static const struct udevice_id led_gpio_ids[] = {
>> + { .compatible = "gpio-restart" },
>> + { }
>> +};
>> +
>> +U_BOOT_DRIVER(gpio_reboot) = {
>> + .id = UCLASS_SYSRESET,
>> + .name = "gpio_restart",
>> + .of_match = led_gpio_ids,
>> + .ops = &gpio_reboot_ops,
>> + .priv_auto_alloc_size = sizeof(struct gpio_reboot_priv),
>> + .probe = gpio_reboot_probe,
>> +};
>> --
>> 1.9.1
>>
>
Thanks,
Michal
___
Re: [U-Boot] [PATCH] watchdog: dm: Support manual relocation for watchdogs
On 15.7.2018 23:21, Simon Glass wrote: > Hi Michal, > > On 11 July 2018 at 23:47, Michal Simek wrote: >> On 11.7.2018 22:13, Simon Glass wrote: >>> On 11 July 2018 at 08:41, Michal Simek wrote: Relocate watchdog ops as was done by: "dm: Add support for all targets which requires MANUAL_RELOC" (sha1: 484fdf5ba058b07be5ca82763aa2b72063540ef3) Signed-off-by: Michal Simek --- based on https://lists.denx.de/pipermail/u-boot/2018-July/334227.html --- drivers/watchdog/wdt-uclass.c | 23 +++ 1 file changed, 23 insertions(+) >>> >>> Reviewed-by: Simon Glass >>> >>> When will the toolchain be fixed? >> >> It is really several years back when I have looked at it last time but I >> think that toolchain is fixed for quite some time and only changes in >> microblaze u-boot code are needed but really I would have to check and >> start to play with it. > > I think someone should sort this out. It would be good to remove this > code. Is there a toolchain group at Xilinx? Xilinx has a toolchain group. I just looked a I was playing with it in January 2015 but didn't finish that. It is still on my long todo list. Will see when I have a time to look at it. Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] efi: Fix truncation of constant value
On 07/14/2018 10:53 PM, Eugeniu Rosca wrote:
> Starting with commit 867a6ac86dd8 ("efi: Add start-up library code"),
> sparse constantly complains about truncated constant value in efi.h:
>
> include/efi.h:176:35: warning: cast truncates bits from constant value
> (8000 becomes 0)
>
> This can get quite noisy, preventing real issues to be noticed:
>
> $ make defconfig
> *** Default configuration is based on 'sandbox_defconfig'
> $ make C=2 -j12 2>&1 | grep truncates | wc -l
> 441
>
> After the patch is applied:
> $ make C=2 -j12 2>&1 | grep truncates | wc -l
> 0
> $ sparse --version
> v0.5.2
>
> Following the suggestion of Heinrich Schuchardt, instead of only
> fixing the root-cause, I replaced the whole enum of _SHIFT values
> by ULL defines. This matches both the UEFI 2.7 spec and the Linux
> kernel implementation.
>
> Some ELF size comparison before and after the patch (gcc 7.3.0):
>
> efi-x86_payload64_defconfig:
> textdatabss dec hex filename
> 407174 29432 278676 715282aea12 u-boot.old
> 407152 29464 278676 715292aea1c u-boot.new
> -22 +32 0 +10
>
> efi-x86_payload32_defconfig:
> textdatabss dec hex filename
> 447075 30308 280076 757459b8ed3 u-boot.old
> 447053 30340 280076 757469b8edd u-boot.new
> -22 +32 0 +10
>
> Fixes: 867a6ac86dd8 ("efi: Add start-up library code")
> Suggested-by: Heinrich Schuchardt
> Signed-off-by: Eugeniu Rosca
> ---
>
> v2:
> - Replace _SHIFT enum values by ULL defines to match UEFI 2.7 spec
> - Add ELF size comparison to patch description
>
> cmd/efi.c | 22 +++---
> include/efi.h | 24 ++--
> lib/efi_loader/efi_memory.c | 7 +++
> 3 files changed, 24 insertions(+), 29 deletions(-)
>
> diff --git a/cmd/efi.c b/cmd/efi.c
> index 6c1eb88424be..92a565f71373 100644
> --- a/cmd/efi.c
> +++ b/cmd/efi.c
> @@ -28,18 +28,18 @@ static const char *const type_name[] = {
> };
>
> static struct attr_info {
> - int shift;
> + u64 val;
> const char *name;
> } mem_attr[] = {
> - { EFI_MEMORY_UC_SHIFT, "uncached" },
> - { EFI_MEMORY_WC_SHIFT, "write-coalescing" },
> - { EFI_MEMORY_WT_SHIFT, "write-through" },
> - { EFI_MEMORY_WB_SHIFT, "write-back" },
> - { EFI_MEMORY_UCE_SHIFT, "uncached & exported" },
> - { EFI_MEMORY_WP_SHIFT, "write-protect" },
> - { EFI_MEMORY_RP_SHIFT, "read-protect" },
> - { EFI_MEMORY_XP_SHIFT, "execute-protect" },
> - { EFI_MEMORY_RUNTIME_SHIFT, "needs runtime mapping" }
> + { EFI_MEMORY_UC, "uncached" },
> + { EFI_MEMORY_WC, "write-coalescing" },
> + { EFI_MEMORY_WT, "write-through" },
> + { EFI_MEMORY_WB, "write-back" },
> + { EFI_MEMORY_UCE, "uncached & exported" },
> + { EFI_MEMORY_WP, "write-protect" },
> + { EFI_MEMORY_RP, "read-protect" },
> + { EFI_MEMORY_XP, "execute-protect" },
> + { EFI_MEMORY_RUNTIME, "needs runtime mapping" }
> };
>
> /* Maximum different attribute values we can track */
> @@ -173,7 +173,7 @@ static void efi_print_mem_table(struct efi_entry_memmap
> *map,
> printf("%c%llx: ", attr & EFI_MEMORY_RUNTIME ? 'r' : ' ',
> attr & ~EFI_MEMORY_RUNTIME);
> for (j = 0, first = true; j < ARRAY_SIZE(mem_attr); j++) {
> - if (attr & (1ULL << mem_attr[j].shift)) {
> + if (attr & mem_attr[j].val) {
> if (first)
> first = false;
> else
> diff --git a/include/efi.h b/include/efi.h
> index 0fe15e65c06c..eb2a569fe010 100644
> --- a/include/efi.h
> +++ b/include/efi.h
> @@ -162,20 +162,16 @@ enum efi_mem_type {
> };
>
> /* Attribute values */
> -enum {
> - EFI_MEMORY_UC_SHIFT = 0,/* uncached */
> - EFI_MEMORY_WC_SHIFT = 1,/* write-coalescing */
> - EFI_MEMORY_WT_SHIFT = 2,/* write-through */
> - EFI_MEMORY_WB_SHIFT = 3,/* write-back */
> - EFI_MEMORY_UCE_SHIFT= 4,/* uncached, exported */
> - EFI_MEMORY_WP_SHIFT = 12, /* write-protect */
> - EFI_MEMORY_RP_SHIFT = 13, /* read-protect */
> - EFI_MEMORY_XP_SHIFT = 14, /* execute-protect */
> - EFI_MEMORY_RUNTIME_SHIFT = 63, /* range requires runtime mapping */
> -
> - EFI_MEMORY_RUNTIME = 1ULL << EFI_MEMORY_RUNTIME_SHIFT,
> - EFI_MEM_DESC_VERSION= 1,
> -};
> +#define EFI_MEMORY_UC((u64)0x0001ULL)/*
> uncached */
Unsigned long long int (ULL) is at least 64bit wide and unsigned (cf.
https://gcc.gnu.org/onlinedocs/gcc/Long-Long.html). Why do you introduce
the (u64) conversion?
Otherwise
Reviewed-by: Heinrich Schuchardt
> +#define EFI_MEMORY_WC((u64)0x0002ULL)/*
> write-coalescing */
> +#define EFI_MEMORY_WT((u64)0x0004ULL)/*
> w
Re: [U-Boot] [PATCH v2 2/3] efi: Add EFI_MEMORY_{NV, MORE_RELIABLE, RO} attributes
On 07/14/2018 10:53 PM, Eugeniu Rosca wrote: > With this update, the memory attributes are in sync with Linux > kernel v4.18-rc4. They also match page 190 of UEFI 2.7 spec [1]. > > [1] http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf > > Suggested-by: Heinrich Schuchardt > Signed-off-by: Eugeniu Rosca > --- > Reviewed-by: Heinrich Schuchardt ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] cmd: efi: Clarify calculation precedence for '&' and '?'
On 07/14/2018 10:53 PM, Eugeniu Rosca wrote:
> Fix cppcheck complaint:
> [cmd/efi.c:173]: (style) Clarify calculation precedence for '&' and '?'.
>
> Fixes: f1a0bafb5802 ("efi: Add a command to display the memory map")
> Signed-off-by: Eugeniu Rosca
> ---
Reviewed-by: Heinrich Schuchardt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] cmd: add bootslot command to select/boot slot based on boot counts
Hi,
On 2018-07-13 14:34, Martin Hundebøll wrote:
The existing bootcount feature is targeted systems with a primary, and a
rescue boot setup, where the number of boot tries to the primary boot is
tracked. If the number exceeds the limit, the alternative/rescue is
booted.
This patch adds support for a more sophisticated setup, where more than
two boot slots can exist, and the order of slots can be configured.
The 'bootcommand' command reads the configured slots (and their
priority/order) from a configured environment variable ("bootslots" by
default). For each conifgured slot, a remaining boot count is maintained
in an evnironment variable ("bootcount_" by default). If the first
boot slot has positive boot count, it is booted using the slot specific
boot command ("bootcmd_" by default). Otherwise the next slot is
checked.
An example environment when using the bootslot command with two slots
("a" and "b"):
With RAUC bootslot's is specified with uppercase letters, uppercase is
not preserved.
We end up with BOOT_b_LEFT=2...
botocmd_* is with lowercase, just to make things easier.
/Sean
bootslots=a b
bootcount_a=3
bootcount_b=3
bootcmd_a=setenv bootargs $bootargs root=/dev/mmcblk0p1; booti $loadaddr
bootcmd_b=setenv bootargs $bootargs root=/dev/mmcblk0p2; booti $loadaddr
Once linux is booted, it resets the bootcount variable for the booted
slot using "fw_setenv":
fw_setenv bootcount_a 3
When the non-booted slot is updated, the order is updated by setting the
bootslots variable with "fw_setenv":
fw_setenv bootslots=b a
Signed-off-by: Martin Hundebøll
Tested-by: Sean Nyekjaer
---
cmd/Kconfig| 42 +
cmd/Makefile | 1 +
cmd/bootslot.c | 225 +
3 files changed, 268 insertions(+)
create mode 100644 cmd/bootslot.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index aec209006d..3919606e74 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1277,6 +1277,48 @@ config CMD_BOOTCOUNT
Enable the bootcount command, which allows interrogation and
reset of the bootcounter.
+config CMD_BOOTSLOT
+ bool "Enable support for multiple boot slots"
+ help
+ Parses an ordered list of configured boot slot names (e.g. "a b")
+ and selects a corresponding boot command based on the current
+ boot counter for each slot.
+
+config CMD_BOOTSLOT_ENV_SLOTS
+ string "Environment variable to read bootslots from"
+ depends on CMD_BOOTSLOT
+ default "bootslots"
+ help
+ Configures the environment variable to read out when looking for a
+ list of available boot sloots.
+
+config CMD_BOOTSLOT_ENV_COUNT
+ string "Environment variable format string to read/write slot boot count
from/to"
+ depends on CMD_BOOTSLOT
+ default "bootcount_%s"
+ help
+ Configures the prefix to use when reading the boot count for a
+ specific slot. The prefix is concatenated with the slot name, so
+ that the boot count for slot "a" is read and saved to "a".
+
+config CMD_BOOTSLOT_ENV_CMD
+ string "Environment variable format string to read slot boot command
from"
+ depends on CMD_BOOTSLOT
+ default "bootcmd_%s"
+ help
+ Configures the prefix to use when reading the boot command for
+ specific slot. The prefix is concatenated with the slot name, so
+ that the boot command for slot "a" is read from "a".
+
+config CMD_BOOTSLOT_DEFAULT_COUNT
+ int "Default boot count for each configured slot"
+ depends on CMD_BOOTSLOT
+ default 3
+ help
+ The default number of times a slot is tried before proceeding to the
+ slot. The default is used when a slot has no count yet, or when it
+ is reset with the "bootslot reset" command.
+
config CMD_BSP
bool "Enable board-specific commands"
help
diff --git a/cmd/Makefile b/cmd/Makefile
index 323f1fd2c7..68c8e50c91 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_CMD_BOOTCOUNT) += bootcount.o
obj-$(CONFIG_CMD_BOOTEFI) += bootefi.o
obj-$(CONFIG_CMD_BOOTMENU) += bootmenu.o
obj-$(CONFIG_CMD_BOOTSTAGE) += bootstage.o
+obj-$(CONFIG_CMD_BOOTSLOT) += bootslot.o
obj-$(CONFIG_CMD_BOOTZ) += bootz.o
obj-$(CONFIG_CMD_BOOTI) += booti.o
obj-$(CONFIG_CMD_BTRFS) += btrfs.o
diff --git a/cmd/bootslot.c b/cmd/bootslot.c
new file mode 100644
index 00..03897b1f60
--- /dev/null
+++ b/cmd/bootslot.c
@@ -0,0 +1,225 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2018, Geanix, All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static char *bootslot_envname(const char *fmt, const char *slot)
+{
+ int len = strlen(fmt) + strlen(slot);
+ char *envname = malloc(len + 1);
+
+ sprintf(envname, fmt, slot);
+
+ return envname;
+}
+
+static unsigned long bootslot_get_count(const char *slot)
+{
+
Re: [U-Boot] [Arm.ebbr-discuss] EBBR v0.6 Release Announcement
- ancient mailing list + proper u-boot mailing list. M On 14.7.2018 00:34, Grant Likely wrote: > I'm pleased to announce the release of version 0.6 of the Embedded Base > Boot Requirements (EBBR) specification. > > https://github.com/ARM-software/ebbr/releases/tag/v0.6 > > EBBR is a new specification defining a standard boot environment > suitable for full feature operating systems running on embedded > platforms... > > Well, it will when it's finished. > > It is well know that firmware for embedded systems is a fragmented area > with each platform behaving in subtly incompatible ways. It is also > completely different from the firmware interface used on general purpose > desktops and servers. For OSes, this makes supporting more than a > handful of platforms a nearly impossible affair. EBBR aims to solve this > problem by defining a standard boot interface that can easily be > implemented using either U-Boot or Tianocore, and is based on the same > UEFI specification used on general purpose computers. > > By adopting EBBR, platform vendors can reduce the amount of engineering > effort required to support their products and make them easier to use. > As EBBR is being developed in conjunction with the U-Boot, Tianocore, > and Trusted Firmware projects, most of the functionality required is > already implemented and ready to be used if one uses an up to date > release of U-Boot or Tianocore. > > For OS vendors, this makes far easier to support embedded platforms > because they don't need to tailor the boot process for each platform. > The same boot infrastructure works on both desktop/servers and on EBBR > compliant embedded platforms. > > And finally, for end users, working with an EBBR compliant platform > means they can boot the OS of their choice without needing to learn low > level details of the platform firmware. > > This v0.6 release of EBBR is a pre-release document. The contents are > not final. The purpose of this release is to raise awareness of the EBBR > project, and to solicit feedback on the current draft. Please do read > and provide comments on the boot-architect...@lists.linaro.org mailing > list. > > The plan is to release v1.0 before the end of the 2018. > > Thanks to the EBBR committee members who contributed to this release: > > Andreas Färber (SUSE) > Alex Graf (SUSE) > Ryan Harkin (Linaro) > Rob Herring (Linaro) > Udit Kumar (NXP) > Leif Lindholm (Linaro) > Bill Mills (TI) > Peter Robinson (Red Hat) > Tom Rini (Konsulko) > Daniel Thompson (Linaro) > Dong Wei (Arm) > > Sincerely, > Grant Likely, EBBR committee co-chair > > > Note on U-Boot implementations > -- > It is expected that EBBR compliant can be achieved by using a recent > version of U-Boot with the appropriate configuration options. An > implementers guide for U-Boot will be written before EBBR v1.0 is released. > > There is also work ongoing to get the UEFI Self Certification Test > running on U-Boot. Once working, this will be a tool for vendors to test > their platforms for EBBR compliance. > > FAQ > --- > 1. Does EBBR define a new interface? > > No. EBBR builds on the existing UEFI spec by requiring a specific > subset that can be implemented today using U-Boot, and either Devicetree > or ACPI. > > 2. Does EBBR require Devicetree? ACPI? > > EBBR allows platforms to provide either ACPI or Devicetree. Linux > supports both system description languages equally well, and Devicetree > is in common use on embedded platforms. As long as the platform supplies > a system description that can boot a mainline operating system. > > EBBR does not attempt to define a common base standard for Devicetree > platforms because of the wide variety of platforms needed to be > supported. The one assumption EBBR does make is that the target > operating system already has support for the SoC on the platform. > > 3. Is EBBR only for U-Boot and Linux embedded systems? > > No. While U-Boot+Linux platforms were certainly the primary audience > when EBBR was first conceived, the spec is very purposefully written to > be OS-independent. EBBR requires specific interfaces, but those > interface can be implemented by any firmware project. > > We would absolutely like to have review, feedback and contributions > from non-Linux, non-U-Boot users. > > 4. Can I contribute to the EBBR specification? > > Yes. The EBBR source document is on GitHub, and we use the > boot-architect...@lists.linaro.org mailing list. > > https://github.com/ARM-Software/ebbr > ___ > Arm.ebbr-discuss mailing list > arm.ebbr-disc...@arm.com ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] efi: Fix truncation of constant value
Hi Heinrich,
Thanks for your review comments. See my reply below.
On Mon, Jul 16, 2018 at 07:52:20AM +0200, Heinrich Schuchardt wrote:
[--snip--]
> > diff --git a/include/efi.h b/include/efi.h
> > index 0fe15e65c06c..eb2a569fe010 100644
> > --- a/include/efi.h
> > +++ b/include/efi.h
> > @@ -162,20 +162,16 @@ enum efi_mem_type {
> > };
> >
> > /* Attribute values */
> > -enum {
> > - EFI_MEMORY_UC_SHIFT = 0,/* uncached */
> > - EFI_MEMORY_WC_SHIFT = 1,/* write-coalescing */
> > - EFI_MEMORY_WT_SHIFT = 2,/* write-through */
> > - EFI_MEMORY_WB_SHIFT = 3,/* write-back */
> > - EFI_MEMORY_UCE_SHIFT= 4,/* uncached, exported */
> > - EFI_MEMORY_WP_SHIFT = 12, /* write-protect */
> > - EFI_MEMORY_RP_SHIFT = 13, /* read-protect */
> > - EFI_MEMORY_XP_SHIFT = 14, /* execute-protect */
> > - EFI_MEMORY_RUNTIME_SHIFT = 63, /* range requires runtime mapping */
> > -
> > - EFI_MEMORY_RUNTIME = 1ULL << EFI_MEMORY_RUNTIME_SHIFT,
> > - EFI_MEM_DESC_VERSION= 1,
> > -};
> > +#define EFI_MEMORY_UC ((u64)0x0001ULL)/*
> > uncached */
>
> Unsigned long long int (ULL) is at least 64bit wide and unsigned (cf.
> https://gcc.gnu.org/onlinedocs/gcc/Long-Long.html). Why do you introduce
> the (u64) conversion?
Because this is how it appears in Linux kernel:
$ git blame ./include/linux/efi.h | grep 'define EFI_MEMORY_.*u64'
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 90) #define
EFI_MEMORY_UC((u64)0x0001ULL)/* uncached */
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 91) #define
EFI_MEMORY_WC((u64)0x0002ULL)/*
write-coalescing */
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 92) #define
EFI_MEMORY_WT((u64)0x0004ULL)/* write-through */
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 93) #define
EFI_MEMORY_WB((u64)0x0008ULL)/* write-back */
9c97e0bdd4b4a (Laszlo Ersek2014-09-03 13:32:19 +0200 94) #define
EFI_MEMORY_UCE ((u64)0x0010ULL)/* uncached,
exported */
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 95) #define
EFI_MEMORY_WP((u64)0x1000ULL)/* write-protect */
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 96) #define
EFI_MEMORY_RP((u64)0x2000ULL)/* read-protect */
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 97) #define
EFI_MEMORY_XP((u64)0x4000ULL)/* execute-protect
*/
c016ca08f89c6 (Robert Elliott 2016-02-01 22:07:06 + 98) #define
EFI_MEMORY_NV((u64)0x8000ULL)/* non-volatile */
87db73aebf555 (Ard Biesheuvel 2015-08-07 09:36:54 +0100 101) #define
EFI_MEMORY_RO((u64)0x0002ULL)/* read-only */
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 102) #define
EFI_MEMORY_RUNTIME ((u64)0x8000ULL)/* range requires runtime
mapping */
Unless we see a potential issue with that (and I don't see), IMO we
should stick to kernel sources as much as possible, since this makes
integration/re-sync process easier.
>
> Otherwise
>
> Reviewed-by: Heinrich Schuchardt
>
> > +#define EFI_MEMORY_WC ((u64)0x0002ULL)/*
> > write-coalescing */
> > +#define EFI_MEMORY_WT ((u64)0x0004ULL)/*
> > write-through */
> > +#define EFI_MEMORY_WB ((u64)0x0008ULL)/*
> > write-back */
> > +#define EFI_MEMORY_UCE ((u64)0x0010ULL)/*
> > uncached, exported */
> > +#define EFI_MEMORY_WP ((u64)0x1000ULL)/*
> > write-protect */
> > +#define EFI_MEMORY_RP ((u64)0x2000ULL)/*
> > read-protect */
> > +#define EFI_MEMORY_XP ((u64)0x4000ULL)/*
> > execute-protect */
> > +#define EFI_MEMORY_RUNTIME ((u64)0x8000ULL)/* range
> > requires runtime mapping */
> > +#define EFI_MEM_DESC_VERSION 1
> >
> > #define EFI_PAGE_SHIFT 12
> > #define EFI_PAGE_SIZE (1UL << EFI_PAGE_SHIFT)
Best regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v7 0/6] sunxi: sync H3, H5, A64 DTs from mainline Linux
On Wed, Jul 4, 2018 at 6:46 PM, Andre Przywara wrote: > This is an updated version of the series which brings the exact mainline > Linux device tree files for various Allwinner boards into U-Boot. > Apart from using the usually more correct reference DT files, this offers > the big benefit of being able to use U-Boot's DT copy for directly passing > it to the kernel. This avoids to actually load a .dtb file from somewhere, > and allows seamless and automatic UEFI booting, so distribution installer > images should just work (TM). > > This covers the ARMv8 SoCs (H5, A64), but also all boards with the H3, as > this is somewhat married to the H5 and can only be updated together. > The H3 and H5 DT files have diverged quite a bit, but as U-Boot's own > usage of the DT is (yet) quite limited, there should be no regressions. > The patches are split to first update the SoC .dtsi file, then the board > .dts files in a second patch. They are grouped to handle the A64 first, > then the H5 and H3. I put the respective kernel commit IDs in the commit > messages. > Patch 6 brings in the mainline DT for the SoPine baseboard, for which we > didn't have a separate .dts in U-Boot so far. > > This is based on origin/master, and requires the USB shutdown fix. > Please let me know what I should it base it against, maybe closer to the > time we actually want to merge this (to avoid playing cat and mouse here). > > Maxime, I kept you Acked-by: from the previous posts, as I literally > just updated to the latest Linux master, which went through your review > anyway. Hope that's OK for you. > > Cheers, > Andre. > > Changelog v6 .. v7: > - drop Pine64-LTS DT (will send it to Linux first) > - update to Linux v4.18-rc3 > > Changelog v5 .. v6: > - bring back DT update patches > - update to Linux v4.17-rc5 > > Changelog v4 .. v5: > - drop Linux DT update patches for now > - fix minor checkpatch complaints > > Changelog v3 .. v4: > - remove MMC environment for all Allwinner boards (including 32 bit ones) > - keep MMC environment offset to the old values > - drop DT adjustments to use fixed MMC regulator > > Changelog v2 .. v3: > 01: added, was on the list before > 02: drop redundant H5 line > 03-08: unchanged > 09-20: added > > Changelog v1 .. v2: > 01, 02, 03: unchanged > 04, 05, 06, 07: added > > Andre Przywara (6): > sunxi: DT: A64: update device tree file for Allwinner A64 SoC > sunxi: DT: A64: update board .dts files from Linux > sunxi: DT: update device tree files for Allwinner H3 and H5 SoCs > sunxi: DT: H5: update board .dts files from Linux > sunxi: DT: H3: update board .dts files from Linux > sunxi: DT: A64: add proper SoPine baseboard device tree Applied to u-boot-sunxi/master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] dm: mmc: sunxi: Add A10/A20 compatible strings
On Sat, Jun 30, 2018 at 5:32 AM, Adam Sampson wrote:
> Commit dd27918c2252 ("dm: mmc: sunxi: Add support for driver model")
> only added the allwinner,sun5i-a13-mmc compatible string for this
> driver. The DM initialisation code here also works with (at least) A10
> and A20, so add the appropriate compatible strings as per Linux 4.17's
> driver.
>
> Tested on A10 Cubieboard and A20 pcDuino3 Nano with CONFIG_DM_MMC.
> (A20 worked already, because sun7i-a20.dtsi specifies both the A13 and
> A20 strings.)
>
> Signed-off-by: Adam Sampson
> ---
Applied to u-boot-sunxi/master
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] dm: sunxi: Use DM for MMC and SATA on all A10 boards
On Thu, Jul 12, 2018 at 1:52 PM, Adam Sampson wrote: > On Thu, Jul 12, 2018 at 12:40:14PM +0530, Jagan Teki wrote: >> Did you test eMMC in any of A10 look it is not detecting during SD >> boot and vice-versa happened during eMMC boot. May be it's because of >> pincrtrl for U-Boot which is not initializing for in DM_MMC. > > No, I don't have any boards with eMMC, so I haven't tested eMMC with > either A10 or A20, I'm afraid. > > (I also haven't been able to find an A13 board to test with -- if there > are any A13 owners reading this, I suspect a similar change would work, > and it'll need doing before the A13 boards get removed for not having DM > support...) Look like there is no eMMC on A10, atleast on existing boards in ML. I understand the eMMC issues with existing dt driver will send the patches for the same. sun4i iNet 3F, 3W has missing mmc0 node on DT, DM_MMC need to have this. anyway I'm sending all in one series. Applied to u-boot-sunxi/master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2018.07 released
Dear Wolfgang, On 10.7.2018 19:21, Wolfgang Denk wrote: > Dear Michal, > > In message <9ef1c57c-5bf6-4730-6b67-466709cc0...@monstr.eu> you wrote: >> >>> Here the short summary: >> >> Is this generating script somewhere? > > It's a clone of Jonathan Corbet's gitdm script; the U-Boot > configuration can be found at [1]. > > [1] http://git.denx.de/?p=gitdm.git looks good. I expect there was consideration to keep these config files out of the main repo. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
