Re: [U-Boot] [PATCH 0/4] net: phy: Add Broadcom BCM53xx switch driver

[Stefan Roese]

On 19.10.2017 23:50, Florian Fainelli wrote:

On 10/14/2017 06:00 PM, Florian Fainelli wrote:

(this time after subscribing to the list)

Hi all,

This patch series adds support for the Broadcom BCM53xx switches, in particular
BCM53125 which is found no the Lamobo R1 board.


Thanks Stefan for the review. I suppose Joe should now queue those up,
provided that he is happy with the patches and then submit a pull request?


Yes, this is how it usually works.

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCHv2] dm: pci: change bus number register setting compliant with Linux

[Bin Meng]

On Fri, Oct 20, 2017 at 10:45 AM, Zhiqiang Hou  wrote:
> From: Minghuan Lian 
>
> This patch is to change U-Boot PCI bus assignement compliant with Linux.
> It means each PCIe controller's bus number is 0, not the current maximum
> PCI bus number, when start to scan this controller.
>
> Signed-off-by: Minghuan Lian 
> Signed-off-by: Hou Zhiqiang 
> ---
> V2:
>  - Change uboot to U-Boot in commit message.
>
>  drivers/pci/pci_auto.c| 6 +++---
>  drivers/pci/pcie_dw_mvebu.c   | 1 +
>  drivers/pci/pcie_layerscape.c | 2 +-
>  drivers/pci/pcie_xilinx.c | 2 ++
>  4 files changed, 7 insertions(+), 4 deletions(-)
>

Reviewed-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCHv2] dm: pci: change bus number register setting compliant with Linux

[Zhiqiang Hou]

From: Minghuan Lian 

This patch is to change U-Boot PCI bus assignement compliant with Linux.
It means each PCIe controller's bus number is 0, not the current maximum
PCI bus number, when start to scan this controller.

Signed-off-by: Minghuan Lian 
Signed-off-by: Hou Zhiqiang 
---
V2:
 - Change uboot to U-Boot in commit message.

 drivers/pci/pci_auto.c| 6 +++---
 drivers/pci/pcie_dw_mvebu.c   | 1 +
 drivers/pci/pcie_layerscape.c | 2 +-
 drivers/pci/pcie_xilinx.c | 2 ++
 4 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index ee9a854bda..c2bc32678a 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -181,8 +181,8 @@ void dm_pciauto_prescan_setup_bridge(struct udevice *dev, 
int sub_bus)
 
/* Configure bus number registers */
dm_pci_write_config8(dev, PCI_PRIMARY_BUS,
-PCI_BUS(dm_pci_get_bdf(dev)));
-   dm_pci_write_config8(dev, PCI_SECONDARY_BUS, sub_bus);
+PCI_BUS(dm_pci_get_bdf(dev)) - ctlr->seq);
+   dm_pci_write_config8(dev, PCI_SECONDARY_BUS, sub_bus - ctlr->seq);
dm_pci_write_config8(dev, PCI_SUBORDINATE_BUS, 0xff);
 
if (pci_mem) {
@@ -257,7 +257,7 @@ void dm_pciauto_postscan_setup_bridge(struct udevice *dev, 
int sub_bus)
pci_io = ctlr_hose->pci_io;
 
/* Configure bus number registers */
-   dm_pci_write_config8(dev, PCI_SUBORDINATE_BUS, sub_bus);
+   dm_pci_write_config8(dev, PCI_SUBORDINATE_BUS, sub_bus - ctlr->seq);
 
if (pci_mem) {
/* Round memory allocator to 1MB boundary */
diff --git a/drivers/pci/pcie_dw_mvebu.c b/drivers/pci/pcie_dw_mvebu.c
index 202cfe9d03..a19885501c 100644
--- a/drivers/pci/pcie_dw_mvebu.c
+++ b/drivers/pci/pcie_dw_mvebu.c
@@ -162,6 +162,7 @@ static uintptr_t set_cfg_address(struct pcie_dw_mvebu *pcie,
/* Accessing root port configuration space. */
va_address = (uintptr_t)pcie->ctrl_base;
} else {
+   d = PCI_MASK_BUS(d) | (PCI_BUS(d) - pcie->first_busno);
writel(d << 8, pcie->ctrl_base + PCIE_ATU_LOWER_TARGET);
va_address = (uintptr_t)pcie->cfg_base;
}
diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index 610f85c4e8..48fc4efc75 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -250,7 +250,7 @@ void *ls_pcie_conf_address(struct ls_pcie *pcie, pci_dev_t 
bdf,
if (PCI_BUS(bdf) == bus->seq)
return pcie->dbi + offset;
 
-   busdev = PCIE_ATU_BUS(PCI_BUS(bdf)) |
+   busdev = PCIE_ATU_BUS(PCI_BUS(bdf) - bus->seq) |
 PCIE_ATU_DEV(PCI_DEV(bdf)) |
 PCIE_ATU_FUNC(PCI_FUNC(bdf));
 
diff --git a/drivers/pci/pcie_xilinx.c b/drivers/pci/pcie_xilinx.c
index 4ba32df516..72fc0f3c43 100644
--- a/drivers/pci/pcie_xilinx.c
+++ b/drivers/pci/pcie_xilinx.c
@@ -105,6 +105,7 @@ static int pcie_xilinx_read_config(struct udevice *bus, 
pci_dev_t bdf,
void *address;
int err;
 
+   bdf = PCI_MASK_BUS(bdf) | (PCI_BUS(bdf) - bus->seq);
err = pcie_xilinx_config_address(pcie, bdf, offset, );
if (err < 0) {
*valuep = pci_get_ff(size);
@@ -148,6 +149,7 @@ static int pcie_xilinx_write_config(struct udevice *bus, 
pci_dev_t bdf,
void *address;
int err;
 
+   bdf = PCI_MASK_BUS(bdf) | (PCI_BUS(bdf) - bus->seq);
err = pcie_xilinx_config_address(pcie, bdf, offset, );
if (err < 0)
return 0;
-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] mtd: nand: fsl-ifc: fix support of multiple NAND devices

[Scott Wood]

On Tue, Oct 17, 2017 at 10:00:45AM +0200, Kurt Kanzenbach wrote:
> Currently the chipselect used to identify the corresponding NAND chip is 
> stored
> at the controller and only set during fsl_ifc_chip_init(). This way, only the
> last NAND chip is working, as the previous value of cs_nand gets overwritten.
> 
> In order to solve this issue the chipselect is moved from the controller to 
> the
> NAND chip structure. Thus, the correct chipselect for each NAND chip operation
> is used.
> 
> Tested on hardware with two NAND chips connected to the IFC controller.
> 
> Signed-off-by: Kurt Kanzenbach 
> ---
>  drivers/mtd/nand/fsl_ifc_nand.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
> index bc6bdc9b2c..57737dbe94 100644
> --- a/drivers/mtd/nand/fsl_ifc_nand.c
> +++ b/drivers/mtd/nand/fsl_ifc_nand.c
> @@ -36,6 +36,7 @@ struct fsl_ifc_mtd {
>  
>   struct device *dev;
>   int bank;   /* Chip select bank number*/
> + unsigned int cs_nand;   /* On which chipsel NAND is connected */

This is redundant with "bank" -- just do like the Linux driver does
and write "priv->bank << IFC_NAND_CSEL_SHIFT" directly to the register
when needed.

> -static int fsl_ifc_sram_init(uint32_t ver)
> +static int fsl_ifc_sram_init(struct mtd_info *mtd, uint32_t ver)
>  {
> + struct nand_chip *chip = mtd_to_nand(mtd);
> + struct fsl_ifc_mtd *priv = nand_get_controller_data(chip);

Could pass in priv instead of mtd to make it more like the Linux driver. 
It's best to avoid gratuitous differences.

-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] fsl_esdhc driver is broken with DM

[Adam Ford]

On Thu, Oct 19, 2017 at 5:44 PM, Fabio Estevam  wrote:
> On Thu, Oct 19, 2017 at 7:52 PM, Adam Ford  wrote:
>
>> The Logic PD board is also broken as well. When I did a git bisect on
>> mine, it shows:
>
> Does this help?

Yes it did.  Thank you

I'll submit a patch.  Should I indicate it 'fixes' that commit I
referenced, or is there some other commit that I should reference?

thanks

adam
> --- a/configs/imx6q_logic_defconfig
> +++ b/configs/imx6q_logic_defconfig
> @@ -28,7 +28,6 @@ CONFIG_CMD_FAT=y
>  CONFIG_CMD_FS_GENERIC=y
>  CONFIG_CMD_MTDPARTS=y
>  CONFIG_ENV_IS_IN_NAND=y
> -# CONFIG_BLK is not set
>  CONFIG_SYS_I2C_MXC=y
>  CONFIG_NAND=y
>  CONFIG_NAND_MXS=y
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Rockchip GRF/PMUGRF/CRU reg access in U-Boot

[Kever Yang]

Hi Simon and Philipp.

I would like to include Heiko who is maintainer of upstream kernel 
Rockchip SoC for this topic.


For the driver related to grf, which including pinctrl, usb phy, gmac 
and many other modules, we would like to sync with kernel, so that we 
can re-use the dtsi from kernel. The use of grf register have many 
discuss on upstream kernel already, and all modules use grf with a  
reference and offset in dts.


U-Boot coding style says "Use structures for I/O access", in my opinion, 
this is good for most case, but not for registers like Rockchip grf, 
because it's related for many modules, and it's different in different 
SoC, use "base addr + offset" for grf reg in dtsi and decode it in 
driver is much more reasonable for grf related driver setting. Just like 
the line size 80 is max, we follow the rule in most case, but in some 
case, more than 80 characters is better for read, then we use more than 
80 characters. We can merge pinctrl driver into one file like kernel if 
we can use this feature, and the same with sysreset, soft reset...We are 
not going to follow the dead rules for all cases, we have to use the one 
which is better for us.


To make it more clear, here is an example:

Looking at drivers/sysreset/sysreset_rk3xxx.c(there are 8 files and more 
to come), the source code are almost the same, the only difference is 
the reg address of glb_srst_snd_value and glb_srst_fst_value in cru,  we 
can very easy to decode this from dts in one common driver if we use 
'base + offset'. If we insist on using structure for this kind of reg 
access, to merge them into one common driver we have to including all 
different SoC cru definition and use different variable for different 
SoC, there would be many '#ifdef ... #else' in the file like this:


#ifdef CONFIG_ROCKCHIP_RK3036

#include 

#else ifdef CONFIG_ROCKCHIP_RK3188

#include 

#else ifdef CONFIG_ROCKCHIP_RK322x

#include 

#else ifdef CONFIG_ROCKCHIP_RK3288

#include 

#else ifdef CONFIG_ROCKCHIP_RK3328

#include 

#else ifdef CONFIG_ROCKCHIP_RK3368

#include 

...
#endif

and also this is need when we define and use the cru variant.


I would like to use two dts decode instead like this for all SoCs:
rphy->grf_base = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
ofnode_read_u32(dev_ofnode(dev), "reg", )
sysreset_reg = rphy->grf_base + reg;

and dts for different SoC like this:
rockchip,grf = <>;
reg = <0x017c>;

We wish upstream U-Boot can accept this kind of coding, I believe when 
the coding style was made, it does not met the controller reg like 
Rockchip GRF.
We will follow the coding style requirement in all other normal 
controller like I2C/SPI/USB/SDMMC/DISPLAY and etc.


Thanks,
- Kever
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] ChormeBook Tegra TK1 HP 14 " running Mainline Kernel Linux (Ubuntu - Xenial) -- Signing Kernel Almost Done !!

[Simon Glass]

Hi,

On 6 September 2017 at 17:07, Alexandre N. Perfeito
 wrote:
> Hi Everyone , almost done here !!! I Need  Help !!! to make the chromebook 
> TegraTk1 model running Ubuntu-Xenial Mainline v4.4.0.70
>
>
>   After I compiled the zImage  with this:
>
>
> root@alarm:/# sudo make -j5 zImage dtbs modules
>
>
>   Second: I caught this file in attached Then I runing this command:
>
> root@alarm:/# sudo /u-boot-tegra/b/nyan-big/tools/mkimage -D "-I dts -O dtb 
> -p 2048" -f kernel.its vmlinux.uimg
>
>   Third:
>
> file bootloader create with:
>
>
> root@alarm:/#sudo dd if=/dev/zero of=bootloader.bin bs=512 count=1
>
>Fourth:
>
> file config.txt create with:
>
> echo 'console=tty0 init=/sbin/init root=PARTUUID=%U/PARTNROFF=1 rootwait rw 
> noinitrd' > config.txt
>
> Fifth :
>
> After The files created I runnig this scripth  fileKernel.sh below:
>
> vbutil_kernel \
> --pack vmlinux.kpart \
> --version 1 \
> --vmlinuz vmlinux.uimg \
> --arch arm \
> --keyblock  /usr/share/vboot/devkeys/kernel.keyblock \
> --signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \
> --config config.txt \
> --bootloader bootloader.bin
>
> file vmlinux.kpart created
>
>  Sixth : Put the file vmlinux.kpart in Kernel Partition /dev/sda6
>
> root@alarm:/# sudo dd if=vmlinux.kpart of=/dev/sda6
>
>   Seventh:
>
> I copy this file in /boot from my USB drive Rootfs partition
>
>
>
> Follow my USB /dev/sda parttion:
>
> [aperfeito@alarm ~]$ sudo cgpt show /dev/sda
> [sudo] password for aperfeito:
>startsizepart   contents
>0   1PMBR (Boot GUID: 
> AD11024D-1016-B345-A21D-F7B823B0318A)
>1   1Pri GPT header
>2  32   Pri GPT table
>   64   32768   6  Label: "KERN-A"
>   Type: ChromeOS 
> kernel
>   UUID: 
> D43B02E7-AF2D-3642-93D8-370D84193655
>   Attr: priority=0 
> tries=0 successful=0
>6560053542815 7 Label: "ROOT-A"
>  Type: 
> 0FC63DAF-8483-4772-8E79-3D69D8477DE4
>  UUID: 
> A01D12A1-C0E2-D54C-B68A-6E24E3896AE2
> 61997023  32   Sec GPT table
> 61997055   1Sec GPT header
>
>
>
> What I have doing wrong ? Chromebook Bleps when using ctlr+U

Can you press 'tab' at that point and see what it says?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCH] rockchip: asus c201 support

[Simon Glass]

Hi Marty,

On 3 October 2017 at 16:03, Marty E. Plummer  wrote:
>
> From: "Marty E. Plummer" 
>
> I realize this patch is not up to standards for the sake of mainlining
> right now, but I'm mostly interested in getting some feedback on how
> to make it work before getting into the nicities of mainline inclusion.
>
> As of right now the bulk of this is the rk3288-veyron-speedy.dts file,
> which I assume has a similar enough boot system to the jerry and minnie.
>
> If the resultant u-boot-spl.bin and u-boot-dtb.img are prepared according
> to the instructions in doc/README.rockchip and then flashed to the c201's
> spi memory I get very little in the way of result; the most I/O that to
> be seen is the board reacts to the power switch (led on, led off). I can
> not seem to get it to output the u-boot console to the built-in screen,
> and currently do not have a mini-hdmi cable to see if that is working or
> not (one is ordered, arrives thursday). Can't find a location to purchase
> a servo board for better debugging possibilities.
>
> I was hoping someone on this mailing list could assist me in getting this
> to work; once a working setup is figured I'll do  proper patchset for
> mainline inclusion.

This boots for me:

U-Boot SPL 2017.11-rc2-00017-g6cda208-dirty (Oct 19 2017 - 17:20:26)
Trying to boot from SPI


U-Boot 2017.11-rc2-00017-g6cda208-dirty (Oct 19 2017 - 17:20:26 -0600)

Model: Google Speedy
DRAM:  2 GiB
MMC:   dwmmc@ff0c: 1, dwmmc@ff0d: 2, dwmmc@ff0f: 0
Using default environment

In:cros-ec-keyb
Out:   vidconsole
Err:   vidconsole
Model: Google Speedy
Net:   Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot:  0
=>

The display and keyboard work also. About 15% of the time it hangs at
'Using default environment' for about 5 seconds. Not sure why.
Sometimes I see a blank screen in that case. Also the screen is very
slow (as if the cache is off), even through the 'dhrystone' command
shows a healthy 2421 DMIPS.

After building in b/chromebook_speedy I use this to write it to an
em100 SPI emulator:

./b/chromebook_speedy/tools/mkimage -n rk3288 -T rkspi -d
b/chromebook_speedy/spl/u-boot-spl.bin spl.bin && dd if=spl.bin
of=spl-out.bin bs=128K conv=sync && cat spl-out.bin
b/chromebook_speedy/u-boot.img >out.bin && dd if=out.bin
of=out.bin.pad bs=4M conv=sync && sudo em100 -s -c GD25LQ32 -d
out.bin.pad -r

The image is out.bin.pad. See here for my version:

https://drive.google.com/open?id=0B7WYZbZ9zd-3ZUJPUHItejR0QnM

I applied your patch to:

0def58f (upstream/master) Merge git://git.denx.de/u-boot-x86

and my only change was to change the model to 'Google Speedy' in the .dts file.

I wonder if you might have a different model to me? You can check this
by booting into dev mode, logging in as root and typing:

cbmem -c |grep -i ram

My 'RAM Config' is 0.

Also with cbmem -c I can see that it has a compat preference of
google,veyron-speedy-rev5

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] fsl_esdhc driver is broken with DM

[Fabio Estevam]

On Thu, Oct 19, 2017 at 7:52 PM, Adam Ford  wrote:

> The Logic PD board is also broken as well. When I did a git bisect on
> mine, it shows:

Does this help?

--- a/configs/imx6q_logic_defconfig
+++ b/configs/imx6q_logic_defconfig
@@ -28,7 +28,6 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_CMD_MTDPARTS=y
 CONFIG_ENV_IS_IN_NAND=y
-# CONFIG_BLK is not set
 CONFIG_SYS_I2C_MXC=y
 CONFIG_NAND=y
 CONFIG_NAND_MXS=y
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Unexpected saving of all environment variables during EFI boot

[Heinrich Schuchardt]

On 10/19/2017 11:28 PM, Alexander Graf wrote:
> 
> 
> On 19.10.17 23:15, Rob Clark wrote:
>> On Thu, Oct 19, 2017 at 5:05 PM, Alexander Graf  wrote:
>>>
>>>
>>> On 19.10.17 22:40, Heinrich Schuchardt wrote:
 This was merged as
 ad644e7c18238026fecc647f62584d87d2c5b0a3
 efi_loader: efi variable support

> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index ec40f41bcb..c406ff82ff 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -8,6 +8,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -942,6 +943,11 @@ static efi_status_t EFIAPI 
> efi_exit_boot_services(void *image_handle,
>  {
>  EFI_ENTRY("%p, %ld", image_handle, map_key);
>
> +#if defined(CONFIG_CMD_SAVEENV) && !defined(CONFIG_ENV_IS_NOWHERE)
> +/* save any EFI variables that have been written: */
> +env_save();

 You save all changed variables and not specifically those bound to EFI.
 This is completely unexpected behavior for the user and not covered by
 the commit message.

 Furthermore you call env_save even if no EFI variable has been touched
 at all.

 This leads to writing to flash on every boot via EFI. Depending on
 technology this might ruin the flash after a few hundred reboots.
>>>
>>> I agree that overwriting flash on every boot isn't a terribly smart idea.
>>>
>>> Also saving random environment variables that are set while we are in a
>>> distro loop to persistent storage isn't great either.
>>>
>>> I agree that we should probably improve this code to only save efi
>>> variables.
>>>
>>> Rob, how bad would it be for Fedora if we remove the persistent variable
>>> store call (just the env_save() line) for 2017.11 to not kill people's
>>> storage devices? Then for the next version tackle it for real and only
>>> save efi variable changes here and only if anything really did change.
>>>
>>
>> As I mentioned on #u-boot, I think we can just comment the
>> env_save().. or perhaps make it a config option.  It will be mildly
>> annoying, since it means every boot is "first boot", ie. falling back
>> to fallback.efi to populate BootOrder/Boot variables, and never
>> using bootmgr.  But since we can't set EFI variables from userspace
>> yet, it isn't really a regression (yet).
> 
> Ok, I sent a patch to remove the env_save() line.

Seems we worked in parallel :)

> 
>> Longer term, maybe we need to split out EFI variables from u-boot env
>> vars..  I thought it would be nice to store them together, since it
>> gives a convenient way to set EFI variables from script or cmdline.
>> But at least a subset of the EFI vars should be persisted to reach
>> EBBR, and if that breaks expectations about u-boot env vars, then I
>> guess we need to split them.
> 
> I really like the sharing of the env space. We just need to have a
> different write mechanism for EFI variables: Instead of writing the
> current env, we could for example reread the original env, copy all
> current efi variables into that and write it back?

That is why I said we have to add read and write methods in struct
env_driver.

> 
>>
>> Side note, devices that can't repeatedly save env (even if we split
>> out the EFI variables to be stored separately) might be problematic
>> with EFI_LOADER.  Maybe we need a build option they can set to have a
>> more crippled version of EFI_LOADER, so as to not penalize more
>> capable devices.
> 
> Every flash device self-destroys :).

There are also env implementations in U-Boot writing to disk:
- env/ext4.c
- env/fat.c

> 
> Really, it boils down to the amount of saves. Writing to flash on every
> boot is a pretty bad idea. If we simply only write when a variable write
> actually occurred (which in most cases won't), then we should be ok on
> all devices I think.

According to the UEFI standard we should save the monotonic counter on
every boot.

Regards

Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] efi_loader: Disable env_save() call on boot

[Heinrich Schuchardt]

On 10/19/2017 11:23 PM, Alexander Graf wrote:
> With the introduction of EFI variable support, we also wanted to persist
> these EFI variables. However, the way it was implemented we ended up
> persisting all U-Boot environment variables on every EFI boot.
> 
> That could potentially lead to unexpected side effects because variables
> that were not supposed to be written to persisted env get written. It also
> means we may end up writing the environment more often than we should.
> 
> For this release, let's just disable EFI variable persistence and instead
> implement it properly for the next one.
> 
> Reported-by: Heinrich Schuchardt 
> Fixes: ad644e7c182 ("efi_loader: efi variable support")
> Signed-off-by: Alexander Graf 
> ---
>  lib/efi_loader/efi_boottime.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index f627340de4..743b84864f 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -1439,10 +1439,7 @@ static efi_status_t EFIAPI efi_exit_boot_services(void 
> *image_handle,
>   /* Make sure that notification functions are not called anymore */
>   efi_tpl = TPL_HIGH_LEVEL;
>  
> -#if defined(CONFIG_CMD_SAVEENV) && !defined(CONFIG_ENV_IS_NOWHERE)
> - /* save any EFI variables that have been written: */
> - env_save();
> -#endif
> + /* XXX Should persist EFI variables here */
>  
>   board_quiesce_devices();
>  
> 
Reviewed-by: Heinrich Schuchardt 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/1] efi_loader: disable saving of EFI variables

[Heinrich Schuchardt]

The current implementation of saving of EFI variables has
unwanted side effects:

- Writing to flash on every boot may harm the memory.
- All variables are saved. Not only the EFI ones.
- Variables are saved even if there is not change.

So let us disable saving for now until we have a complete
solution.

This will also mean every boot is "first boot", ie. falling back
to fallback.efi to populate BootOrder/Boot variables, and
never using bootmgr.

Fixes: ad644e7c1823 efi_loader: efi variable support
Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_boottime.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index f627340de4..a734d84d38 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1440,8 +1440,17 @@ static efi_status_t EFIAPI efi_exit_boot_services(void 
*image_handle,
efi_tpl = TPL_HIGH_LEVEL;
 
 #if defined(CONFIG_CMD_SAVEENV) && !defined(CONFIG_ENV_IS_NOWHERE)
-   /* save any EFI variables that have been written: */
-   env_save();
+   /*
+* save any EFI variables that have been written:
+*
+* This feature is disabled due to the following deficiencies:
+* Writing to flash on every boot may ruin the memory.
+* We should not save non-EFI variables here.
+* We should only save if an EFI variable has actually been
+* changed.
+*
+* env_save();
+*/
 #endif
 
board_quiesce_devices();
-- 
2.14.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/2] sunxi: Fix boot of Cubietruk and al.

[André Przywara]

Hi Maxime,

On 19/10/17 15:04, Maxime Ripard wrote:



> The final one that has been implemented would be to just build U-Boot
> using thumb2 to push back the issue until hopefully I'm no longer
> maintainer or the switch to the env filesystem would have been done.
> 
> I've also added a patch to make sure that the compilation breaks and
> that we can notice.

Can you please swap the patches? So that we get the fix before we break
the build? This looks better in bisecting and buildman.

Cheers,
Andre.

> 
> Maxime
> 
> 
> Maxime Ripard (2):
>   sunxi: binman: Add U-Boot binary size check
>   sunxi: Enable THUMB build for the U-Boot binary
> 
>  arch/arm/Kconfig   |  1 +
>  arch/arm/dts/sunxi-u-boot.dtsi | 11 +++
>  2 files changed, 12 insertions(+)
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] fsl_esdhc driver is broken with DM

[Adam Ford]

On Mon, Oct 16, 2017 at 4:52 PM, Fabio Estevam  wrote:
> On Mon, Oct 16, 2017 at 6:51 PM, Jagan Teki  wrote:
>> On Fri, Oct 13, 2017 at 7:03 PM, Fabio Estevam  wrote:
>>> Hi Lukasz,
>>>
>>> On Fri, Oct 13, 2017 at 5:16 AM, Lukasz Majewski  wrote:
>>>
 There is some ongoing work to provide such facility. for imx6
 boards. I will keep you informed.
>>>
>>> That's good news! Please keep me in the loop as well.

The Logic PD board is also broken as well. When I did a git bisect on
mine, it shows:

6eb25e9878617f9a1d7f06ec21c9b981bb0a4e5 is the first bad commit
commit d6eb25e9878617f9a1d7f06ec21c9b981bb0a4e5
Author: Simon Glass 
Date:   Sat Jul 29 11:35:22 2017 -0600

dm: mmc: fsl_esdhc: Drop mmc_init() call from fsl_esdhc_init()

We want to use fsl_esdhc_init() with driver model. Move the mmc_init() out
of this function so that we can use it for our common init.

Signed-off-by: Simon Glass 

I will admit, I haven't been as quick on checking this, so I feel bad
for not noticing issues sooner.  It could have been fixed, then later
broken again, but 2017.07 work and 2017.09 did not.

adam

>>
>> Would be good  if we have some kind of discussion together on this
>> topic on next week, ELCE Prague. Any plan?
>
> Yes, that would be nice. I will attend ELCE next week.
>
> Thanks
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/1] Kconfig: add CONFIG_BROKEN

[Heinrich Schuchardt]

Provide a Kconfig option that we can use as dependency for
features that are broken. This allows to easily disable them
without removing the code.

As no short text is supplied the option will not appear in
menuconfig.

Signed-off-by: Heinrich Schuchardt 
---
 Kconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Kconfig b/Kconfig
index 227fb17dd9..e57fad4592 100644
--- a/Kconfig
+++ b/Kconfig
@@ -14,6 +14,12 @@ source "arch/Kconfig"
 
 menu "General setup"
 
+config BROKEN
+   bool
+   help
+ This option cannot be enabled. It is used as dependency
+ for broken and incomplete features.
+
 config LOCALVERSION
string "Local version - append to U-Boot release"
help
-- 
2.14.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/4] net: phy: Add Broadcom BCM53xx switch driver

[Florian Fainelli]

On 10/14/2017 06:00 PM, Florian Fainelli wrote:
> (this time after subscribing to the list)
> 
> Hi all,
> 
> This patch series adds support for the Broadcom BCM53xx switches, in 
> particular
> BCM53125 which is found no the Lamobo R1 board.

Thanks Stefan for the review. I suppose Joe should now queue those up,
provided that he is happy with the patches and then submit a pull request?

> 
> The driver is largely based on the DSA/b53 driver Linux driver and only
> incorporates what is necessary to succesfully bring-up all ports (including 
> the
> management port) for boot over the network:
> 
> => dhcp
> dw_adjust_link: Speed: 1000, full duplex
> BOOTP broadcast 1
> DHCP client bound to address 192.168.0.11 (3 ms)
> Using ethernet@01c5 device
> TFTP from server 192.168.0.1; our IP address is 192.168.0.11
> Filename 'sun7i-a20-lamobo-r1-kernel.bin'.
> Load address: 0x4200
> Loading: #
>  #
>  
>  11.6 MiB/s
> done
> Bytes transferred = 2371552 (242fe0 hex)
> => 
> 
> 
> Florian Fainelli (4):
>   net: phy: Add Broadcom BCM53xx switch driver
>   net: designware: Pad small packets
>   net: phy: b53: Add b53_reg read/write commands
>   configs: Update Lamobo_R1 with B53 switch options
> 
>  configs/Lamobo_R1_defconfig |   3 +
>  drivers/net/designware.c|   4 +
>  drivers/net/phy/Kconfig |  14 +
>  drivers/net/phy/Makefile|   1 +
>  drivers/net/phy/b53.c   | 767 
> 
>  drivers/net/phy/phy.c   |   3 +
>  include/phy.h   |   1 +
>  7 files changed, 793 insertions(+)
>  create mode 100644 drivers/net/phy/b53.c
> 


-- 
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] efi_loader: Disable env_save() call on boot

[Rob Clark]

On Thu, Oct 19, 2017 at 5:23 PM, Alexander Graf  wrote:
> With the introduction of EFI variable support, we also wanted to persist
> these EFI variables. However, the way it was implemented we ended up
> persisting all U-Boot environment variables on every EFI boot.
>
> That could potentially lead to unexpected side effects because variables
> that were not supposed to be written to persisted env get written. It also
> means we may end up writing the environment more often than we should.
>
> For this release, let's just disable EFI variable persistence and instead
> implement it properly for the next one.
>

Acked-by: Rob Clark 

> Reported-by: Heinrich Schuchardt 
> Fixes: ad644e7c182 ("efi_loader: efi variable support")
> Signed-off-by: Alexander Graf 
> ---
>  lib/efi_loader/efi_boottime.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index f627340de4..743b84864f 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -1439,10 +1439,7 @@ static efi_status_t EFIAPI efi_exit_boot_services(void 
> *image_handle,
> /* Make sure that notification functions are not called anymore */
> efi_tpl = TPL_HIGH_LEVEL;
>
> -#if defined(CONFIG_CMD_SAVEENV) && !defined(CONFIG_ENV_IS_NOWHERE)
> -   /* save any EFI variables that have been written: */
> -   env_save();
> -#endif
> +   /* XXX Should persist EFI variables here */
>
> board_quiesce_devices();
>
> --
> 2.12.3
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Rob Clark]

On Thu, Oct 19, 2017 at 7:43 AM, Maxime Ripard
 wrote:
> On Thu, Oct 19, 2017 at 10:12:36AM +0100, Peter Robinson wrote:
>> On Thu, Oct 19, 2017 at 10:06 AM, Peter Robinson  
>> wrote:
>> > On Thu, Oct 19, 2017 at 10:01 AM, Maxime Ripard
>> >  wrote:
>> >> On Thu, Oct 19, 2017 at 09:43:20AM +0100, Peter Robinson wrote:
>> >>> On Thu, Oct 19, 2017 at 9:26 AM, Maxime Ripard
>> >>>  wrote:
>> >>> > The EFI loader support takes around 31kB on an ARMv7 board, which 
>> >>> > makes us
>> >>> > trip across the size limit we've had on the U-Boot binary.
>> >>> >
>> >>> > Since it's not an essential feature, disable it by default for 
>> >>> > ARCH_SUNXI
>> >>> > so that we get back some extra room for user customisations.
>> >>>
>> >>> Does this disable it on aarch64 boards by default such as the Pine64?
>> >>> If so NAK as Fedora, SUSE and I'm pretty sure Debian all use EFI to
>> >>> boot aarch64 devices and this would regress this for all those
>> >>> distros.
>> >>
>> >> This is something that Fedora, Suse and I'm pretty sure Debian can add
>> >> to their defconfig. These are just default configuration, not
>> >> one-size-fits-all configuration.
>> >
>> > So you're making at least three groups of users do more work? It could
>> > also be argued that those that need the smaller space could disable it
>> > if they don't need it in their configuration.
>>
>> Ultimately the problem with the argument about disabling it by default
>> and distros can enable it if they want to is a false one.
>
> If it's a false one, then I guess Red Hat doesn't have any kind of
> custom defconfigs for Fedora or RHEL for the kernel?

kernel is part of the distro, "firmware" (ie. u-boot or whatever
implements UEFI) should not be.. so this argument is a bit of a red
herring.

Maybe the solution is a "distro.config" option to separate options
that make sense for distro/EBBR from what people who are doing more
non-standard boot-chains are wanting.  For example, for UEFI boot, we
can disable all the filesystems other than FAT if you need to trim
some space.  And maybe doing a more simplified (ie. add it to
efi_bootmgr.c) alternative to distro bootcmd could save a bunch of
.text space.  In fact we don't really need the scripting env at all.
Probably there are other options for things to disable that I haven't
thought of if you *really* needed to trim down.

BR,
-R

>> By enabling it by default we have devices that ship with SPI or NAND
>> flash, like a bunch of the OrangePis do now, be able to work with
>> all distributions out of the box without any requirements of distros
>> to produce a firmware (something I'd really prefer to leave to the
>> device makers) to boot a number of Linux OSes OOTB.
>
> That one is the false argument in the discussion. No vendor is
> providing such a U-Boot, all of them provide a vendor one that will
> not even be able to boot a mainline kernel, let alone supporting
> EFI. So having something that works out of the box is just a pipe
> dream.
>
>> I think this is a good thing for the entire ecosystem. I don't want
>> to regress that, I'd sooner get the size checks in place and then
>> review rather than what seems like a "quick win"
>
> I've added a size check. 3 boards are broken:
>   - A20-OLinuXino-Lime2-eMMC
>   - A20-OLinuXino-Lime2
>   - Cubietruck
>
> What now?
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Unexpected saving of all environment variables during EFI boot

[Alexander Graf]

On 19.10.17 23:15, Rob Clark wrote:
> On Thu, Oct 19, 2017 at 5:05 PM, Alexander Graf  wrote:
>>
>>
>> On 19.10.17 22:40, Heinrich Schuchardt wrote:
>>> This was merged as
>>> ad644e7c18238026fecc647f62584d87d2c5b0a3
>>> efi_loader: efi variable support
>>>
 diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
 index ec40f41bcb..c406ff82ff 100644
 --- a/lib/efi_loader/efi_boottime.c
 +++ b/lib/efi_loader/efi_boottime.c
 @@ -8,6 +8,7 @@

  #include 
  #include 
 +#include 
  #include 
  #include 
  #include 
 @@ -942,6 +943,11 @@ static efi_status_t EFIAPI 
 efi_exit_boot_services(void *image_handle,
  {
  EFI_ENTRY("%p, %ld", image_handle, map_key);

 +#if defined(CONFIG_CMD_SAVEENV) && !defined(CONFIG_ENV_IS_NOWHERE)
 +/* save any EFI variables that have been written: */
 +env_save();
>>>
>>> You save all changed variables and not specifically those bound to EFI.
>>> This is completely unexpected behavior for the user and not covered by
>>> the commit message.
>>>
>>> Furthermore you call env_save even if no EFI variable has been touched
>>> at all.
>>>
>>> This leads to writing to flash on every boot via EFI. Depending on
>>> technology this might ruin the flash after a few hundred reboots.
>>
>> I agree that overwriting flash on every boot isn't a terribly smart idea.
>>
>> Also saving random environment variables that are set while we are in a
>> distro loop to persistent storage isn't great either.
>>
>> I agree that we should probably improve this code to only save efi
>> variables.
>>
>> Rob, how bad would it be for Fedora if we remove the persistent variable
>> store call (just the env_save() line) for 2017.11 to not kill people's
>> storage devices? Then for the next version tackle it for real and only
>> save efi variable changes here and only if anything really did change.
>>
> 
> As I mentioned on #u-boot, I think we can just comment the
> env_save().. or perhaps make it a config option.  It will be mildly
> annoying, since it means every boot is "first boot", ie. falling back
> to fallback.efi to populate BootOrder/Boot variables, and never
> using bootmgr.  But since we can't set EFI variables from userspace
> yet, it isn't really a regression (yet).

Ok, I sent a patch to remove the env_save() line.

> Longer term, maybe we need to split out EFI variables from u-boot env
> vars..  I thought it would be nice to store them together, since it
> gives a convenient way to set EFI variables from script or cmdline.
> But at least a subset of the EFI vars should be persisted to reach
> EBBR, and if that breaks expectations about u-boot env vars, then I
> guess we need to split them.

I really like the sharing of the env space. We just need to have a
different write mechanism for EFI variables: Instead of writing the
current env, we could for example reread the original env, copy all
current efi variables into that and write it back?

> 
> Side note, devices that can't repeatedly save env (even if we split
> out the EFI variables to be stored separately) might be problematic
> with EFI_LOADER.  Maybe we need a build option they can set to have a
> more crippled version of EFI_LOADER, so as to not penalize more
> capable devices.

Every flash device self-destroys :).

Really, it boils down to the amount of saves. Writing to flash on every
boot is a pretty bad idea. If we simply only write when a variable write
actually occurred (which in most cases won't), then we should be ok on
all devices I think.


Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] efi_loader: Disable env_save() call on boot

[Alexander Graf]

With the introduction of EFI variable support, we also wanted to persist
these EFI variables. However, the way it was implemented we ended up
persisting all U-Boot environment variables on every EFI boot.

That could potentially lead to unexpected side effects because variables
that were not supposed to be written to persisted env get written. It also
means we may end up writing the environment more often than we should.

For this release, let's just disable EFI variable persistence and instead
implement it properly for the next one.

Reported-by: Heinrich Schuchardt 
Fixes: ad644e7c182 ("efi_loader: efi variable support")
Signed-off-by: Alexander Graf 
---
 lib/efi_loader/efi_boottime.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index f627340de4..743b84864f 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1439,10 +1439,7 @@ static efi_status_t EFIAPI efi_exit_boot_services(void 
*image_handle,
/* Make sure that notification functions are not called anymore */
efi_tpl = TPL_HIGH_LEVEL;
 
-#if defined(CONFIG_CMD_SAVEENV) && !defined(CONFIG_ENV_IS_NOWHERE)
-   /* save any EFI variables that have been written: */
-   env_save();
-#endif
+   /* XXX Should persist EFI variables here */
 
board_quiesce_devices();
 
-- 
2.12.3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Unexpected saving of all environment variables during EFI boot

[Rob Clark]

On Thu, Oct 19, 2017 at 5:05 PM, Alexander Graf  wrote:
>
>
> On 19.10.17 22:40, Heinrich Schuchardt wrote:
>> This was merged as
>> ad644e7c18238026fecc647f62584d87d2c5b0a3
>> efi_loader: efi variable support
>>
>>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>>> index ec40f41bcb..c406ff82ff 100644
>>> --- a/lib/efi_loader/efi_boottime.c
>>> +++ b/lib/efi_loader/efi_boottime.c
>>> @@ -8,6 +8,7 @@
>>>
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -942,6 +943,11 @@ static efi_status_t EFIAPI efi_exit_boot_services(void 
>>> *image_handle,
>>>  {
>>>  EFI_ENTRY("%p, %ld", image_handle, map_key);
>>>
>>> +#if defined(CONFIG_CMD_SAVEENV) && !defined(CONFIG_ENV_IS_NOWHERE)
>>> +/* save any EFI variables that have been written: */
>>> +env_save();
>>
>> You save all changed variables and not specifically those bound to EFI.
>> This is completely unexpected behavior for the user and not covered by
>> the commit message.
>>
>> Furthermore you call env_save even if no EFI variable has been touched
>> at all.
>>
>> This leads to writing to flash on every boot via EFI. Depending on
>> technology this might ruin the flash after a few hundred reboots.
>
> I agree that overwriting flash on every boot isn't a terribly smart idea.
>
> Also saving random environment variables that are set while we are in a
> distro loop to persistent storage isn't great either.
>
> I agree that we should probably improve this code to only save efi
> variables.
>
> Rob, how bad would it be for Fedora if we remove the persistent variable
> store call (just the env_save() line) for 2017.11 to not kill people's
> storage devices? Then for the next version tackle it for real and only
> save efi variable changes here and only if anything really did change.
>

As I mentioned on #u-boot, I think we can just comment the
env_save().. or perhaps make it a config option.  It will be mildly
annoying, since it means every boot is "first boot", ie. falling back
to fallback.efi to populate BootOrder/Boot variables, and never
using bootmgr.  But since we can't set EFI variables from userspace
yet, it isn't really a regression (yet).

Longer term, maybe we need to split out EFI variables from u-boot env
vars..  I thought it would be nice to store them together, since it
gives a convenient way to set EFI variables from script or cmdline.
But at least a subset of the EFI vars should be persisted to reach
EBBR, and if that breaks expectations about u-boot env vars, then I
guess we need to split them.

Side note, devices that can't repeatedly save env (even if we split
out the EFI variables to be stored separately) might be problematic
with EFI_LOADER.  Maybe we need a build option they can set to have a
more crippled version of EFI_LOADER, so as to not penalize more
capable devices.

BR,
-R
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Unexpected saving of all environment variables during EFI boot

[Alexander Graf]

On 19.10.17 22:40, Heinrich Schuchardt wrote:
> This was merged as
> ad644e7c18238026fecc647f62584d87d2c5b0a3
> efi_loader: efi variable support
> 
>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>> index ec40f41bcb..c406ff82ff 100644
>> --- a/lib/efi_loader/efi_boottime.c
>> +++ b/lib/efi_loader/efi_boottime.c
>> @@ -8,6 +8,7 @@
>>  
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -942,6 +943,11 @@ static efi_status_t EFIAPI efi_exit_boot_services(void 
>> *image_handle,
>>  {
>>  EFI_ENTRY("%p, %ld", image_handle, map_key);
>>  
>> +#if defined(CONFIG_CMD_SAVEENV) && !defined(CONFIG_ENV_IS_NOWHERE)
>> +/* save any EFI variables that have been written: */
>> +env_save();
> 
> You save all changed variables and not specifically those bound to EFI.
> This is completely unexpected behavior for the user and not covered by
> the commit message.
> 
> Furthermore you call env_save even if no EFI variable has been touched
> at all.
> 
> This leads to writing to flash on every boot via EFI. Depending on
> technology this might ruin the flash after a few hundred reboots.

I agree that overwriting flash on every boot isn't a terribly smart idea.

Also saving random environment variables that are set while we are in a
distro loop to persistent storage isn't great either.

I agree that we should probably improve this code to only save efi
variables.

Rob, how bad would it be for Fedora if we remove the persistent variable
store call (just the env_save() line) for 2017.11 to not kill people's
storage devices? Then for the next version tackle it for real and only
save efi variable changes here and only if anything really did change.


Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-x86

[Tom Rini]

On Thu, Oct 19, 2017 at 11:55:13AM +0800, Bin Meng wrote:

> Hi Tom,
> 
> This includes a critical bug fix for Baytrail ACPI suspend/resume and
> some other minor clean ups.
> 
> The following changes since commit 6b0fea33424dcce82b6df0c6b3774601eb1ff36a:
> 
>   Merge git://git.denx.de/u-boot-i2c (2017-10-18 09:32:35 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-x86.git
> 
> for you to fetch changes up to 9af43acba6ea1fe6de29150b8bd3eb0126ba6a15:
> 
>   x86: conga-qeval20-qa3-e3845-internal-uart_defconfig: Add ACPI
> resume support (2017-10-19 11:37:51 +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Unexpected saving of all environment variables during EFI boot

[Heinrich Schuchardt]

This was merged as
ad644e7c18238026fecc647f62584d87d2c5b0a3
efi_loader: efi variable support

> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index ec40f41bcb..c406ff82ff 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -8,6 +8,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -942,6 +943,11 @@ static efi_status_t EFIAPI efi_exit_boot_services(void 
> *image_handle,
>  {
>   EFI_ENTRY("%p, %ld", image_handle, map_key);
>  
> +#if defined(CONFIG_CMD_SAVEENV) && !defined(CONFIG_ENV_IS_NOWHERE)
> + /* save any EFI variables that have been written: */
> + env_save();

You save all changed variables and not specifically those bound to EFI.
This is completely unexpected behavior for the user and not covered by
the commit message.

Furthermore you call env_save even if no EFI variable has been touched
at all.

This leads to writing to flash on every boot via EFI. Depending on
technology this might ruin the flash after a few hundred reboots.

Please, revert this part of the change.

Best regards

Heinrich Schuchardt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] ARM: imx6: Enable UMS and DFU on DHCOM i.MX6 PDK

[Marek Vasut]

Enable UMS and DFU, so that the eMMC can be accessed via the
USB gadget port on the board.

Signed-off-by: Marek Vasut 
Cc: Stefano Babic 
---
 board/dhelectronics/dh_imx6/dh_imx6.c | 10 ++
 configs/dh_imx6_defconfig |  8 
 include/configs/dh_imx6.h | 12 
 3 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/board/dhelectronics/dh_imx6/dh_imx6.c 
b/board/dhelectronics/dh_imx6/dh_imx6.c
index e372fbad32..f730e5febd 100644
--- a/board/dhelectronics/dh_imx6/dh_imx6.c
+++ b/board/dhelectronics/dh_imx6/dh_imx6.c
@@ -253,16 +253,10 @@ static void setup_usb(void)
 
 int board_usb_phy_mode(int port)
 {
-   return USB_INIT_HOST;
-}
-
-/* Use only Port 1 == DHCOM USB Host 1 */
-int board_ehci_hcd_init(int port)
-{
if (port == 1)
-   return 0;
+   return USB_INIT_HOST;
else
-   return -ENODEV;
+   return USB_INIT_DEVICE;
 }
 
 int board_ehci_power(int port, int on)
diff --git a/configs/dh_imx6_defconfig b/configs/dh_imx6_defconfig
index 5125260ee4..ef6dc564d1 100644
--- a/configs/dh_imx6_defconfig
+++ b/configs/dh_imx6_defconfig
@@ -20,6 +20,7 @@ CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_IMLS is not set
 CONFIG_CMD_MEMTEST=y
 CONFIG_CMD_UNZIP=y
+CONFIG_CMD_DFU=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
@@ -28,6 +29,7 @@ CONFIG_CMD_PART=y
 CONFIG_CMD_SATA=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_USB=y
+CONFIG_CMD_USB_MASS_STORAGE=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
@@ -48,4 +50,10 @@ CONFIG_NETDEVICES=y
 CONFIG_FEC_MXC=y
 CONFIG_USB=y
 CONFIG_USB_STORAGE=y
+CONFIG_USB_GADGET=y
+CONFIG_CI_UDC=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_G_DNL_MANUFACTURER="dh"
+CONFIG_G_DNL_VENDOR_NUM=0x0525
+CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
 CONFIG_OF_LIBFDT=y
diff --git a/include/configs/dh_imx6.h b/include/configs/dh_imx6.h
index 0595f60e32..11a01d476f 100644
--- a/include/configs/dh_imx6.h
+++ b/include/configs/dh_imx6.h
@@ -115,6 +115,18 @@
 #define CONFIG_MXC_USB_PORTSC  (PORT_PTS_UTMI | PORT_PTS_PTW)
 #define CONFIG_MXC_USB_FLAGS   0
 #define CONFIG_USB_MAX_CONTROLLER_COUNT2 /* Enabled USB controller 
number */
+
+/* USB Gadget (DFU, UMS) */
+#if defined(CONFIG_CMD_DFU) || defined(CONFIG_CMD_USB_MASS_STORAGE)
+#define CONFIG_USB_FUNCTION_MASS_STORAGE
+
+#define CONFIG_SYS_DFU_DATA_BUF_SIZE   (16 * 1024 * 1024)
+#define DFU_DEFAULT_POLL_TIMEOUT   300
+
+/* USB IDs */
+#define CONFIG_G_DNL_UMS_VENDOR_NUM0x0525
+#define CONFIG_G_DNL_UMS_PRODUCT_NUM   0xA4A5
+#endif
 #endif
 
 /* Watchdog */
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] usb: gadget: storage: Increase FSG_BUFLEN

[Marek Vasut]

Increase the buffer length to be just above maximum permissible value
of 128 kiB . This increases the performance of the UMS and alike by a
factor of 2 - 2.5 as the buffers are less fragmented.

Signed-off-by: Marek Vasut 
Cc: Lukasz Majewski 
---
 drivers/usb/gadget/storage_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/storage_common.c 
b/drivers/usb/gadget/storage_common.c
index b6df130a14..4d5a9a8c42 100644
--- a/drivers/usb/gadget/storage_common.c
+++ b/drivers/usb/gadget/storage_common.c
@@ -309,7 +309,7 @@ static struct fsg_lun *fsg_lun_from_dev(struct device *dev)
 #define FSG_NUM_BUFFERS2
 
 /* Default size of buffer length. */
-#define FSG_BUFLEN ((u32)16384)
+#define FSG_BUFLEN ((u32)131072)
 
 /* Maximal number of LUNs supported in mass storage function */
 #define FSG_MAX_LUNS   8
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCH u-boot v2] ARM: arch-meson: build memory banks using reported memory from registers

[Ben Dooks]

On 2017-10-19 14:22, Neil Armstrong wrote:
As discussed at [1], the Amlogic Meson GX SoCs can embed a BL31 
firmware

and a secondary BL32 firmware.
Since mid-2017, the reserved memory address of the BL31 firmware was 
moved

and grown for security reasons.

But mainline U-boot and Linux has the old address and size fixed.

These SoCs have a register interface to get the two firmware reserved
memory start and sizes.

This patch adds a dynamic reservation of the memory zones in the
device tree bootmem
reserved memory zone used by the kernel in early boot.
To be complete, the memory zones are also added to the EFI reserved 
zones.


[1] 
http://lists.infradead.org/pipermail/linux-amlogic/2017-October/004860.html


Changes since v1:
- switch to fdt rsv mem table and efi reserve memory
- replaced in_le32 by readl()

Signed-off-by: Neil Armstrong 
---
 arch/arm/include/asm/arch-meson/gxbb.h |  17 +
 arch/arm/mach-meson/board.c| 117 
++---

 board/amlogic/odroid-c2/odroid-c2.c|   7 ++
 board/amlogic/p212/p212.c  |   7 ++
 configs/odroid-c2_defconfig|   1 +
 configs/p212_defconfig |   1 +
 include/configs/meson-gxbb-common.h|   2 +-
 7 files changed, 143 insertions(+), 9 deletions(-)

diff --git a/arch/arm/include/asm/arch-meson/gxbb.h
b/arch/arm/include/asm/arch-meson/gxbb.h
index 74d5290..117f796 100644
--- a/arch/arm/include/asm/arch-meson/gxbb.h
+++ b/arch/arm/include/asm/arch-meson/gxbb.h
@@ -7,10 +7,27 @@
 #ifndef __GXBB_H__
 #define __GXBB_H__

+#define GXBB_FIRMWARE_MEM_SIZE 0x100
+
+#define GXBB_AOBUS_BASE0xc810
 #define GXBB_PERIPHS_BASE  0xc8834400
 #define GXBB_HIU_BASE  0xc883c000
 #define GXBB_ETH_BASE  0xc941

+/* Always-On Peripherals registers */
+#define GXBB_AO_ADDR(off)  (GXBB_AOBUS_BASE + ((off) << 2))
+
+#define GXBB_AO_SEC_GP_CFG0GXBB_AO_ADDR(0x90)
+#define GXBB_AO_SEC_GP_CFG3GXBB_AO_ADDR(0x93)
+#define GXBB_AO_SEC_GP_CFG4GXBB_AO_ADDR(0x94)
+#define GXBB_AO_SEC_GP_CFG5GXBB_AO_ADDR(0x95)
+
+#define GXBB_AO_MEM_SIZE_MASK  0x
+#define GXBB_AO_MEM_SIZE_SHIFT 16
+#define GXBB_AO_BL31_RSVMEM_SIZE_MASK  0x
+#define GXBB_AO_BL31_RSVMEM_SIZE_SHIFT 16
+#define GXBB_AO_BL32_RSVMEM_SIZE_MASK  0x
+
 /* Peripherals registers */
 #define GXBB_PERIPHS_ADDR(off) (GXBB_PERIPHS_BASE + ((off) << 2))

diff --git a/arch/arm/mach-meson/board.c b/arch/arm/mach-meson/board.c
index e89c6aa..24733e1 100644
--- a/arch/arm/mach-meson/board.c
+++ b/arch/arm/mach-meson/board.c
@@ -11,6 +11,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 

 DECLARE_GLOBAL_DATA_PTR;

@@ -34,16 +37,114 @@ int dram_init(void)
return 0;
 }

-int dram_init_banksize(void)
+phys_size_t get_effective_memsize(void)
 {
-   /* Reserve first 16 MiB of RAM for firmware */
-   gd->bd->bi_dram[0].start = 0x100;
-   gd->bd->bi_dram[0].size  = 0xf00;
-   /* Reserve 2 MiB for ARM Trusted Firmware (BL31) */
-   gd->bd->bi_dram[1].start = 0x1000;
-   gd->bd->bi_dram[1].size  = gd->ram_size - 0x1020;
-   return 0;
+   /* Size is reported in MiB, convert it in bytes */
+   return ((readl(GXBB_AO_SEC_GP_CFG0) & GXBB_AO_MEM_SIZE_MASK)
+   >> GXBB_AO_MEM_SIZE_SHIFT) * SZ_1M;
+}
+
+#ifdef CONFIG_MESON_GXBB
+/*
+ * Early Meson GXBB Firmware revision did not provide the reserved
+ * memory zones in the registers, keep fixed memory zone handling.
+ */
+
+void ft_cpu_setup(void *fdt, bd_t *bd)
+{
+   int ret;
+
+   /* Add first 16MiB reserved zone */
+   ret = fdt_add_mem_rsv(fdt, 0, GXBB_FIRMWARE_MEM_SIZE);
+   if (ret)
+   printf("Could not reserve zone @ 0x0\n");
+
+#if defined(CONFIG_EFI_LOADER)
+   efi_add_memory_map(0, ALIGN(GXBB_FIRMWARE_MEM_SIZE, EFI_PAGE_SIZE)
+   >> EFI_PAGE_SHIFT,
+  EFI_RESERVED_MEMORY_TYPE, false);
+#endif


Could you make a sub function that does most of this and then have
only one set of #if defined ?

Would anyone mind if efi_add_memory_map had a default 'null' 
implementation

if !CONFIG_EFI_LOADER ?


+
+   /* Add BL31 reserved zone */
+   ret = fdt_add_mem_rsv(fdt, 0x1000, 0x20);
+   if (ret)
+   printf("Could not reserve BL1 zone @ 0x1000\n");
+
+#if defined(CONFIG_EFI_LOADER)
+   efi_add_memory_map(0x1000,
+  ALIGN(0x20, EFI_PAGE_SIZE)
+   >> EFI_PAGE_SHIFT,
+  EFI_RESERVED_MEMORY_TYPE, false);
+#endif
+}
+#endif


Can we reduce the pre-processor load here, I'm not even sure
we're testing the entire file can be compiled.


+
+#ifdef CONFIG_MESON_GXL


you're mixing #ifdef and #if defined.


+void ft_cpu_setup(void *fdt, bd_t *bd)
+{
+   u64 bl31_size, bl31_start;
+   u64 bl32_size, bl32_start;
+   u32 reg;
+ 

Re: [U-Boot] [PATCH v2] DW SPI: Get clock value from Device Tree

[Dinh Nguyen]

On 10/19/2017 10:51 AM, Marek Vasut wrote:
> On 10/19/2017 05:36 PM, Eugeniy Paltsev wrote:
>> On Tue, 2017-10-17 at 20:32 +0530, Jagan Teki wrote:
>>> On Tue, Oct 17, 2017 at 8:27 PM, Alexey Brodkin
>>>  wrote:
 Hi Jagan,

> -Original Message-
> From: Eugeniy Paltsev [mailto:palt...@synopsys.com]
> Sent: Tuesday, October 17, 2017 4:33 PM
> To: jagannadh.t...@gmail.com
> Cc: u-boot@lists.denx.de; uboot-snps-...@synopsys.com
> Subject: [uboot-snps-arc] Re: [PATCH v2] DW SPI: Get clock value from 
> Device Tree
>>
>> How hard it is to make others to use clock manager? do you have any list?
>
> clock_manager.h is an old (and non-generic) way to deal with different 
> clocks.
> For example in SOCFPGA_GEN5 and SOCFPGA_ARRIA10 clock_manager.h provides
> cm_get_spi_controller_clk_hz function to deal with spi controller clock.
>
> But today we have another, linux-like alternative: to bind clocks via 
> device tree
> and manipulate with clocks via generic functions provided by clk.h
>
> In this patch I added option to get clock via device tree using standard 
> bindings
> and restrict clock_manager.h functions usage only to targets which still 
> use it,
> so new targets can simply bind clock via device tree and they do not need 
> to
> implement/define something in clock_manager.h
>
> So we don't need to make others to use clock manager :)

 Maybe it worth trying the other way around and think about switching 
 SOCFPGA platforms to
 generic clk framework?
>>>
>>> Yes, ie what exactly I thought of, thanks!
>>
>> I checked cm_get_spi_controller_clk_hz implementation in SOCFPGA_GEN5 and
>> SOCFPGA_ARRIA10: we can't simply replace it with "fixed-clock" driver as it 
>> manipulate with real hardware.
>> The only way to do it is to replace SOCFPGA* clock manager functions by real
>> clock driver.
>>
>> And given I don't have mentioned hardware so I barely can help with
>> those improvements on SOCFPGA. That said if there're no short-term plans to
>> switch SOCFPGA to clk framework maybe we'll be OK with my workaround with 
>> #ifdefs?
> 
> Wait for Dinh's reply ...
> 

Honestly, I don't have too much time to work on this right now. So I
really don't when it can get done. But it'll go on my to-do list.

Dinh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] test/py: fix typos in README.md

[Stephen Warren]

On 10/19/2017 04:08 AM, Masahiro Yamada wrote:

Signed-off-by: Masahiro Yamada 
---

  test/py/README.md | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)


Reviewed-by: Stephen Warren 

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] DW SPI: Get clock value from Device Tree

[Marek Vasut]

On 10/19/2017 05:36 PM, Eugeniy Paltsev wrote:
> On Tue, 2017-10-17 at 20:32 +0530, Jagan Teki wrote:
>> On Tue, Oct 17, 2017 at 8:27 PM, Alexey Brodkin
>>  wrote:
>>> Hi Jagan,
>>>
 -Original Message-
 From: Eugeniy Paltsev [mailto:palt...@synopsys.com]
 Sent: Tuesday, October 17, 2017 4:33 PM
 To: jagannadh.t...@gmail.com
 Cc: u-boot@lists.denx.de; uboot-snps-...@synopsys.com
 Subject: [uboot-snps-arc] Re: [PATCH v2] DW SPI: Get clock value from 
 Device Tree
>
> How hard it is to make others to use clock manager? do you have any list?

 clock_manager.h is an old (and non-generic) way to deal with different 
 clocks.
 For example in SOCFPGA_GEN5 and SOCFPGA_ARRIA10 clock_manager.h provides
 cm_get_spi_controller_clk_hz function to deal with spi controller clock.

 But today we have another, linux-like alternative: to bind clocks via 
 device tree
 and manipulate with clocks via generic functions provided by clk.h

 In this patch I added option to get clock via device tree using standard 
 bindings
 and restrict clock_manager.h functions usage only to targets which still 
 use it,
 so new targets can simply bind clock via device tree and they do not need 
 to
 implement/define something in clock_manager.h

 So we don't need to make others to use clock manager :)
>>>
>>> Maybe it worth trying the other way around and think about switching 
>>> SOCFPGA platforms to
>>> generic clk framework?
>>
>> Yes, ie what exactly I thought of, thanks!
> 
> I checked cm_get_spi_controller_clk_hz implementation in SOCFPGA_GEN5 and
> SOCFPGA_ARRIA10: we can't simply replace it with "fixed-clock" driver as it 
> manipulate with real hardware.
> The only way to do it is to replace SOCFPGA* clock manager functions by real
> clock driver.
> 
> And given I don't have mentioned hardware so I barely can help with
> those improvements on SOCFPGA. That said if there're no short-term plans to
> switch SOCFPGA to clk framework maybe we'll be OK with my workaround with 
> #ifdefs?

Wait for Dinh's reply ...

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] DW SPI: Get clock value from Device Tree

[Eugeniy Paltsev]

On Tue, 2017-10-17 at 20:32 +0530, Jagan Teki wrote:
> On Tue, Oct 17, 2017 at 8:27 PM, Alexey Brodkin
>  wrote:
> > Hi Jagan,
> > 
> > > -Original Message-
> > > From: Eugeniy Paltsev [mailto:palt...@synopsys.com]
> > > Sent: Tuesday, October 17, 2017 4:33 PM
> > > To: jagannadh.t...@gmail.com
> > > Cc: u-boot@lists.denx.de; uboot-snps-...@synopsys.com
> > > Subject: [uboot-snps-arc] Re: [PATCH v2] DW SPI: Get clock value from 
> > > Device Tree
> > > > 
> > > > How hard it is to make others to use clock manager? do you have any 
> > > > list?
> > > 
> > > clock_manager.h is an old (and non-generic) way to deal with different 
> > > clocks.
> > > For example in SOCFPGA_GEN5 and SOCFPGA_ARRIA10 clock_manager.h provides
> > > cm_get_spi_controller_clk_hz function to deal with spi controller clock.
> > > 
> > > But today we have another, linux-like alternative: to bind clocks via 
> > > device tree
> > > and manipulate with clocks via generic functions provided by clk.h
> > > 
> > > In this patch I added option to get clock via device tree using standard 
> > > bindings
> > > and restrict clock_manager.h functions usage only to targets which still 
> > > use it,
> > > so new targets can simply bind clock via device tree and they do not need 
> > > to
> > > implement/define something in clock_manager.h
> > > 
> > > So we don't need to make others to use clock manager :)
> > 
> > Maybe it worth trying the other way around and think about switching 
> > SOCFPGA platforms to
> > generic clk framework?
> 
> Yes, ie what exactly I thought of, thanks!

I checked cm_get_spi_controller_clk_hz implementation in SOCFPGA_GEN5 and
SOCFPGA_ARRIA10: we can't simply replace it with "fixed-clock" driver as it 
manipulate with real hardware.
The only way to do it is to replace SOCFPGA* clock manager functions by real
clock driver.

And given I don't have mentioned hardware so I barely can help with
those improvements on SOCFPGA. That said if there're no short-term plans to
switch SOCFPGA to clk framework maybe we'll be OK with my workaround with 
#ifdefs?

-- 
 Eugeniy Paltsev
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] sunxi: binman: Add U-Boot binary size check

[Andre Przywara]

Hi,

On 19/10/17 15:04, Maxime Ripard wrote:
> The U-boot binary may trip over its actual allocated size in the storage.
> In such a case, the environment will not be readable anymore (because
> corrupted when the new image was flashed), and any attempt at using saveenv
> to reconstruct the environment will result in a corrupted U-boot binary.

Merci beaucoup for that v2 series!

> Signed-off-by: Maxime Ripard 
> ---
>  arch/arm/dts/sunxi-u-boot.dtsi | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi
> index 5adfd9bca2ec..b44660e8d37e 100644
> --- a/arch/arm/dts/sunxi-u-boot.dtsi
> +++ b/arch/arm/dts/sunxi-u-boot.dtsi
> @@ -1,5 +1,13 @@
>  #include 
>  
> +/*
> + * This is the maximum size the U-boot binary can be, which is
> + * basically the start of the environment, minus the (padded) size of
> + * the SPL), minus the offset at which the generated file is supposed
> + * to be flashed in the MMC.
> + */
> +#define UBOOT_MAX_SIZE   (CONFIG_ENV_OFFSET - CONFIG_SPL_PAD_TO - (8 << 
> 10))

Just bikeshedding: Can't we use:
(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR << 9)
for the last two expressions?

But that's just a nit, so:

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> +
>  / {
>   binman {
>   filename = "u-boot-sunxi-with-spl.bin";
> @@ -8,6 +16,9 @@
>   filename = "spl/sunxi-spl.bin";
>   };
>   u-boot-img {
> +#ifdef CONFIG_MMC
> + size = ;
> +#endif
>   pos = ;
>   };
>   };
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Maxime Ripard]

On Thu, Oct 19, 2017 at 03:42:11PM +0100, Andre Przywara wrote:
> Hi,
> 
> On 19/10/17 14:24, Maxime Ripard wrote:
> > On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote:
> >> Hi,
> >>
> >> On 19/10/17 09:26, Maxime Ripard wrote:
> >>> Hi,
> >>>
> >>> Most featureful boards, such as the Cubietruck, have been broken since
> >>> the release 2017.09.
> >>>
> >>> This is due to a size increase of the binary that will trip us across
> >>> the size we've been using in the u-boot-sunxi-with-spl.bin file.
> >>>
> >>> We would have two ways to work around it. The first one would be to
> >>> just increase the offset of the environment. However, since it would
> >>> break all the environments of our users and possibly the custom
> >>> partition scheme that they would have created, it doesn't really seem
> >>> like a smart move.
> >>
> >> Is that really such a problem? How many people rely on having their
> >> custom environment preserved over an update? (That's an honest question)
> > 
> > All of them, I guess. In your U-boot upgrade script, do you do a 'env
> > default -a; saveenv' all the time ?
> > 
> > I know I don't.
> 
> Well, I never use the saved environment and always expected some user or
> board specific environment to come from some file (boot.scr or something
> loaded via TFTP). But that's just my personal use, hence I was asking.

Well, even if you want to boot to tftp, you'll need to have some setup
to do, even just to use a different server IP, and that will be in the
environment.

> And I was wondering if it hasn't been broken in the past for arm64 sunxi
> boards already, because aarch64 code is usually bigger (I remember
> seeing like +20% for u-boot.bin in the past).
> 
> > And I guess the question should be turned the other way around. Should
> > you expect your environment to be erased / ignored by any upgrade?
> 
> I think this is usually the case for a BIOS upgrade on a PC.

Yeah, so definitely not the U-Boot habits :)

> >> I believe the real limit should be 1MB - ENV_SIZE.
> >> Most sane partitioning tools put the first partition at 1MB, so this
> >> leaves the space below that to the bootloader/firmware.
> > 
> > Is that 1MB after the partition table or 1MB since the beginning of
> > the device?
> 
> The beginning of the device. I would expect a (legacy) layout to be:
> @0: MBR (1 sector)
> @8K: SPL (up to 32KB)
> @40K: U-Boot image
> (@544K: environment)
> @1MB: first primary partition
> Not sure if there is anything else in there.
> 
> I wonder if we could insert some code in U-Boot to move the environment
> in preparation for a hard change? Like:
> - Before looking at 544K, check for a valid environment at 896K.
> - If an env is found @544K: move it to 896K, invalidate the 544K copy.
> 
> If we have this algorithm live for some time, we might be able to catch
> and migrate many users, without making life miserable for *everyone*.
> Not perfect, I know, but better than a hard cut.

I guess if we were to do this, we'd better store it in a filesystem
file directly like Tom suggested, and just skip the increase of the
size.

> >> This would put the actual limit at 856 KB for now - that should be
> >> enough for everybody ;-)
> >> We could even push this further by reducing ENV_SIZE to say 64KB.
> >>
> >> At least that would buy us some time to address this issue in a more
> >> sustainable way.
> > 
> > Yeah, but even if we could address the issues mentionned above, we'd
> > still need to take care of the partitions for let's say the
> > environment that would need to be moved as well. This is just not
> > practical.
> 
> I don't understand. What partitions? Android? Do they start between 544K
> and 1MB?

I've seen (and built) setups where you would have a partition
dedicated to the U-Boot environment and binaries so that you can
upgrade / switch them easily.

fastboot (and I suspect dfu) makes that really convenient.

> > I guess we could introduce a new image with more room for the u-boot
> > binary, and advertise it as such. But we would still have to build the
> > old one for quite some time.
> 
> Who would be "we", exactly? Distributions?

U-Boot upstream

> I guess this is the only case where we want to preserve the ENV
> location? Could they mitigate this by using the transitional schema as
> described above?
> For new (whole) images this would certainly not be a problem, would it?

Even in the transition scheme, let's say you have a user that would
use a 'legacy' offset for its environment, you will not want to
overwrite it, so you'll need the size check for as long as the
transition period last.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 5/5] mmc: arm_pl180_mmci: add .getcd callback

[patrice.chotard]

From: Patrice Chotard 

Add .getcd callback to check is MMC card is present

Signed-off-by: Patrice Chotard 
---
 drivers/mmc/arm_pl180_mmci.c | 24 ++--
 drivers/mmc/arm_pl180_mmci.h |  4 
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index f060c64..a827a1e 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -18,9 +18,10 @@
 #include 
 #include 
 
-#include "arm_pl180_mmci.h"
-
 #include 
+#include 
+
+#include "arm_pl180_mmci.h"
 
 #ifdef CONFIG_DM_MMC
 #include 
@@ -431,6 +432,8 @@ static int arm_pl180_mmc_probe(struct udevice *dev)
host->clock_max = dev_read_u32_default(dev, "max-frequency", 4800);
host->version2 = dev_get_driver_data(dev);
 
+   gpio_request_by_name(dev, "cd-gpios", 0, >cd_gpio, GPIOD_IS_IN);
+
bus_width = dev_read_u32_default(dev, "bus-width", 1);
switch (bus_width) {
case 8:
@@ -474,9 +477,26 @@ static int dm_host_set_ios(struct udevice *dev)
return host_set_ios(mmc);
 }
 
+static int dm_mmc_getcd(struct udevice *dev)
+{
+   struct arm_pl180_mmc_plat *pdata = dev_get_platdata(dev);
+   struct mmc *mmc = >mmc;
+   struct pl180_mmc_host *host = mmc->priv;
+   int value = 1;
+
+   if (dm_gpio_is_valid(>cd_gpio)) {
+   value = dm_gpio_get_value(>cd_gpio);
+   if (host->cd_inverted)
+   return !value;
+   }
+
+   return value;
+}
+
 static const struct dm_mmc_ops arm_pl180_dm_mmc_ops = {
.send_cmd = dm_host_request,
.set_ios = dm_host_set_ios,
+   .get_cd = dm_mmc_getcd,
 };
 
 static int arm_pl180_mmc_ofdata_to_platdata(struct udevice *dev)
diff --git a/drivers/mmc/arm_pl180_mmci.h b/drivers/mmc/arm_pl180_mmci.h
index b935288..9df4b75 100644
--- a/drivers/mmc/arm_pl180_mmci.h
+++ b/drivers/mmc/arm_pl180_mmci.h
@@ -191,6 +191,10 @@ struct pl180_mmc_host {
unsigned int pwr_init;
int version2;
struct mmc_config cfg;
+#ifdef CONFIG_DM_MMC
+   struct gpio_desc cd_gpio;
+   bool cd_inverted;
+#endif
 };
 
 int arm_pl180_mmci_init(struct pl180_mmc_host *host, struct mmc **mmc);
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 4/5] mmc: arm_pl180_mmci: add clock support

[patrice.chotard]

From: Patrice Chotard 

Allow to get and enable MMC related clock

Signed-off-by: Patrice Chotard 
---
 drivers/mmc/arm_pl180_mmci.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index 6ee77b1..f060c64 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -13,6 +13,7 @@
 /* #define DEBUG */
 
 #include "common.h"
+#include 
 #include 
 #include 
 #include 
@@ -405,17 +406,28 @@ static int arm_pl180_mmc_probe(struct udevice *dev)
struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
struct mmc *mmc = >mmc;
struct pl180_mmc_host *host = mmc->priv;
+   struct clk clk;
u32 bus_width;
int ret;
 
+   ret = clk_get_by_index(dev, 0, );
+   if (ret < 0)
+   return ret;
+
+   ret = clk_enable();
+   if (ret) {
+   dev_err(dev, "failed to enable clock\n");
+   return ret;
+   }
+
strcpy(host->name, "MMC");
host->pwr_init = INIT_PWR;
host->clkdiv_init = SDI_CLKCR_CLKDIV_INIT_V1 | SDI_CLKCR_CLKEN |
SDI_CLKCR_HWFC_EN;
host->voltages = VOLTAGE_WINDOW_SD;
host->caps = 0;
-   host->clock_in = 4800;
-   host->clock_min = 40;
+   host->clock_in = clk_get_rate();
+   host->clock_min = host->clock_in / (2 * (SDI_CLKCR_CLKDIV_INIT_V1 + 1));
host->clock_max = dev_read_u32_default(dev, "max-frequency", 4800);
host->version2 = dev_get_driver_data(dev);
 
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 3/5] mmc: arm_pl180_mmci: add bus_width DT property support

[patrice.chotard]

From: Patrice Chotard 

Allow to get "bus-width" property from device tree

Signed-off-by: Patrice Chotard 
---
 drivers/mmc/arm_pl180_mmci.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index 61dbbfb..6ee77b1 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -405,6 +405,7 @@ static int arm_pl180_mmc_probe(struct udevice *dev)
struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
struct mmc *mmc = >mmc;
struct pl180_mmc_host *host = mmc->priv;
+   u32 bus_width;
int ret;
 
strcpy(host->name, "MMC");
@@ -417,6 +418,22 @@ static int arm_pl180_mmc_probe(struct udevice *dev)
host->clock_min = 40;
host->clock_max = dev_read_u32_default(dev, "max-frequency", 4800);
host->version2 = dev_get_driver_data(dev);
+
+   bus_width = dev_read_u32_default(dev, "bus-width", 1);
+   switch (bus_width) {
+   case 8:
+   host->caps |= MMC_MODE_8BIT;
+   /* Hosts capable of 8-bit transfers can also do 4 bits */
+   case 4:
+   host->caps |= MMC_MODE_4BIT;
+   break;
+   case 1:
+   break;
+   default:
+   dev_err(dev, "Invalid bus-width value %u\n", bus_width);
+   return -EINVAL;
+   }
+
ret = arm_pl180_mmci_init(host, );
if (ret) {
dev_err(dev, "arm_pl180_mmci init failed\n");
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/5] mmc: arm_pl180_mmci: adapt driver to DM usage

[patrice.chotard]

From: Patrice Chotard 

Convert this driver to driver model.
This driver is also used by VEXPRESS platforms which doesn't
use driver model.

Tested on STM32F746 and STM32F769 platforms.

Signed-off-by: Christophe Priouzeau 
Signed-off-by: Patrice Chotard 
---
 drivers/mmc/Kconfig  |   9 
 drivers/mmc/arm_pl180_mmci.c | 125 ++-
 drivers/mmc/arm_pl180_mmci.h |   3 ++
 3 files changed, 125 insertions(+), 12 deletions(-)

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 94050836..62ce0af 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -33,6 +33,15 @@ config SPL_DM_MMC
 
 if MMC
 
+config ARM_PL180_MMCI
+   bool "ARM AMBA Multimedia Card Interface and compatible support"
+   depends on DM_MMC && OF_CONTROL
+   help
+ This selects the ARM(R) AMBA(R) PrimeCell Multimedia Card
+ Interface (PL180, PL181 and compatible) support.
+ If you have an ARM(R) platform with a Multimedia Card slot,
+ say Y or M here.
+
 config SPL_MMC_TINY
bool "Tiny MMC framework in SPL"
help
diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index 7898b0d..61dbbfb 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -12,12 +12,24 @@
 
 /* #define DEBUG */
 
-#include 
 #include "common.h"
 #include 
+#include 
 #include 
+
 #include "arm_pl180_mmci.h"
-#include 
+
+#include 
+
+#ifdef CONFIG_DM_MMC
+#include 
+DECLARE_GLOBAL_DATA_PTR;
+
+struct arm_pl180_mmc_plat {
+   struct mmc_config cfg;
+   struct mmc mmc;
+};
+#endif
 
 static int wait_for_command_end(struct mmc *dev, struct mmc_cmd *cmd)
 {
@@ -265,16 +277,6 @@ static int host_request(struct mmc *dev,
return result;
 }
 
-/* MMC uses open drain drivers in the enumeration phase */
-static int mmc_host_reset(struct mmc *dev)
-{
-   struct pl180_mmc_host *host = dev->priv;
-
-   writel(host->pwr_init, >base->power);
-
-   return 0;
-}
-
 static int  host_set_ios(struct mmc *dev)
 {
struct pl180_mmc_host *host = dev->priv;
@@ -337,11 +339,23 @@ static int  host_set_ios(struct mmc *dev)
return 0;
 }
 
+#ifndef CONFIG_DM_MMC
+/* MMC uses open drain drivers in the enumeration phase */
+static int mmc_host_reset(struct mmc *dev)
+{
+   struct pl180_mmc_host *host = dev->priv;
+
+   writel(host->pwr_init, >base->power);
+
+   return 0;
+}
+
 static const struct mmc_ops arm_pl180_mmci_ops = {
.send_cmd = host_request,
.set_ios = host_set_ios,
.init = mmc_host_reset,
 };
+#endif
 
 /*
  * mmc_host_init - initialize the mmc controller.
@@ -361,7 +375,9 @@ int arm_pl180_mmci_init(struct pl180_mmc_host *host, struct 
mmc **mmc)
writel(sdi_u32, >base->mask0);
 
host->cfg.name = host->name;
+#ifndef CONFIG_DM_MMC
host->cfg.ops = _pl180_mmci_ops;
+#endif
/* TODO remove the duplicates */
host->cfg.host_caps = host->caps;
host->cfg.voltages = host->voltages;
@@ -381,3 +397,88 @@ int arm_pl180_mmci_init(struct pl180_mmc_host *host, 
struct mmc **mmc)
 
return 0;
 }
+
+#ifdef CONFIG_DM_MMC
+static int arm_pl180_mmc_probe(struct udevice *dev)
+{
+   struct arm_pl180_mmc_plat *pdata = dev_get_platdata(dev);
+   struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
+   struct mmc *mmc = >mmc;
+   struct pl180_mmc_host *host = mmc->priv;
+   int ret;
+
+   strcpy(host->name, "MMC");
+   host->pwr_init = INIT_PWR;
+   host->clkdiv_init = SDI_CLKCR_CLKDIV_INIT_V1 | SDI_CLKCR_CLKEN |
+   SDI_CLKCR_HWFC_EN;
+   host->voltages = VOLTAGE_WINDOW_SD;
+   host->caps = 0;
+   host->clock_in = 4800;
+   host->clock_min = 40;
+   host->clock_max = dev_read_u32_default(dev, "max-frequency", 4800);
+   host->version2 = dev_get_driver_data(dev);
+   ret = arm_pl180_mmci_init(host, );
+   if (ret) {
+   dev_err(dev, "arm_pl180_mmci init failed\n");
+   return ret;
+   }
+
+   mmc->dev = dev;
+   dev->priv = host;
+   upriv->mmc = mmc;
+
+   return 0;
+}
+
+static int dm_host_request(struct udevice *dev, struct mmc_cmd *cmd,
+  struct mmc_data *data)
+{
+   struct mmc *mmc = mmc_get_mmc_dev(dev);
+
+   return host_request(mmc, cmd, data);
+}
+
+static int dm_host_set_ios(struct udevice *dev)
+{
+   struct mmc *mmc = mmc_get_mmc_dev(dev);
+
+   return host_set_ios(mmc);
+}
+
+static const struct dm_mmc_ops arm_pl180_dm_mmc_ops = {
+   .send_cmd = dm_host_request,
+   .set_ios = dm_host_set_ios,
+};
+
+static int arm_pl180_mmc_ofdata_to_platdata(struct udevice *dev)
+{
+   struct arm_pl180_mmc_plat *pdata = dev_get_platdata(dev);
+   struct mmc *mmc = >mmc;
+   struct pl180_mmc_host *host = mmc->priv;
+   fdt_addr_t addr;
+

[U-Boot] [PATCH 1/5] mmc: arm_pl180_mmci: update arm_pl180_mmci_init() prototype

[patrice.chotard]

From: Patrice Chotard 

Update arm_pl180_mmci_init() prototype by adding struct mmc**
param. This is needed before converting this driver to driver model
in order to use arm_pl180_mmci_init() in driver model and in none
driver model implementation

Signed-off-by: Patrice Chotard 
---
 board/armltd/vexpress/vexpress_common.c |  3 ++-
 drivers/mmc/arm_pl180_mmci.c| 10 +-
 drivers/mmc/arm_pl180_mmci.h|  2 +-
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/board/armltd/vexpress/vexpress_common.c 
b/board/armltd/vexpress/vexpress_common.c
index 89ab8f7..37b8d7f 100644
--- a/board/armltd/vexpress/vexpress_common.c
+++ b/board/armltd/vexpress/vexpress_common.c
@@ -76,6 +76,7 @@ int cpu_mmc_init(bd_t *bis)
(void) bis;
 #ifdef CONFIG_ARM_PL180_MMCI
struct pl180_mmc_host *host;
+   struct mmc *mmc;
 
host = malloc(sizeof(struct pl180_mmc_host));
if (!host)
@@ -91,7 +92,7 @@ int cpu_mmc_init(bd_t *bis)
host->clock_in = ARM_MCLK;
host->clock_min = ARM_MCLK / (2 * (SDI_CLKCR_CLKDIV_INIT_V1 + 1));
host->clock_max = CONFIG_ARM_PL180_MMCI_CLOCK_FREQ;
-   rc = arm_pl180_mmci_init(host);
+   rc = arm_pl180_mmci_init(host, );
 #endif
return rc;
 }
diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index ddf8383..7898b0d 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -348,9 +348,8 @@ static const struct mmc_ops arm_pl180_mmci_ops = {
  * Set initial clock and power for mmc slot.
  * Initialize mmc struct and register with mmc framework.
  */
-int arm_pl180_mmci_init(struct pl180_mmc_host *host)
+int arm_pl180_mmci_init(struct pl180_mmc_host *host, struct mmc **mmc)
 {
-   struct mmc *mmc;
u32 sdi_u32;
 
writel(host->pwr_init, >base->power);
@@ -373,11 +372,12 @@ int arm_pl180_mmci_init(struct pl180_mmc_host *host)
else
host->cfg.b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 
-   mmc = mmc_create(>cfg, host);
-   if (mmc == NULL)
+   *mmc = mmc_create(>cfg, host);
+   if (!*mmc)
return -1;
 
-   debug("registered mmc interface number is:%d\n", mmc->block_dev.devnum);
+   debug("registered mmc interface number is:%d\n",
+ (*mmc)->block_dev.devnum);
 
return 0;
 }
diff --git a/drivers/mmc/arm_pl180_mmci.h b/drivers/mmc/arm_pl180_mmci.h
index f23bd39..6e232f7 100644
--- a/drivers/mmc/arm_pl180_mmci.h
+++ b/drivers/mmc/arm_pl180_mmci.h
@@ -190,6 +190,6 @@ struct pl180_mmc_host {
struct mmc_config cfg;
 };
 
-int arm_pl180_mmci_init(struct pl180_mmc_host *);
+int arm_pl180_mmci_init(struct pl180_mmc_host *host, struct mmc **mmc);
 
 #endif
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 0/5] Extend ARM_PL180_MMCI

[patrice.chotard]

From: Patrice Chotard 

Currently this driver is used by VEXPRESS platform which doesn't support
Driver Model.
ARM_PL180_MMCI IP is embedded on STM32F4 and F7 platforms. In order to add 
SD support on these 2 STM32 family SoCs, the following reworks are needed:
_ update arm_pl180_mmci_init() prototype to make this driver working 
with
  DM and none DM platforms
_ addapt driver to driver model
_ add bus_width device tree support
_ add clock support
_ add .get_cd callback support

This series has been tested internally on both STM32F4 and STM32F7 SoCs
family. Future SD support for these 2 platforms will be added soon.

Patrice Chotard (5):
  mmc: arm_pl180_mmci: update arm_pl180_mmci_init() prototype
  mmc: arm_pl180_mmci: adapt driver to DM usage
  mmc: arm_pl180_mmci: add bus_width DT property support
  mmc: arm_pl180_mmci: add clock support
  mmc: arm_pl180_mmci: add .getcd callback

 board/armltd/vexpress/vexpress_common.c |   3 +-
 drivers/mmc/Kconfig |   9 ++
 drivers/mmc/arm_pl180_mmci.c| 184 +---
 drivers/mmc/arm_pl180_mmci.h|   9 +-
 4 files changed, 186 insertions(+), 19 deletions(-)

-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Andre Przywara]

Hi,

On 19/10/17 14:24, Maxime Ripard wrote:
> On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote:
>> Hi,
>>
>> On 19/10/17 09:26, Maxime Ripard wrote:
>>> Hi,
>>>
>>> Most featureful boards, such as the Cubietruck, have been broken since
>>> the release 2017.09.
>>>
>>> This is due to a size increase of the binary that will trip us across
>>> the size we've been using in the u-boot-sunxi-with-spl.bin file.
>>>
>>> We would have two ways to work around it. The first one would be to
>>> just increase the offset of the environment. However, since it would
>>> break all the environments of our users and possibly the custom
>>> partition scheme that they would have created, it doesn't really seem
>>> like a smart move.
>>
>> Is that really such a problem? How many people rely on having their
>> custom environment preserved over an update? (That's an honest question)
> 
> All of them, I guess. In your U-boot upgrade script, do you do a 'env
> default -a; saveenv' all the time ?
> 
> I know I don't.

Well, I never use the saved environment and always expected some user or
board specific environment to come from some file (boot.scr or something
loaded via TFTP). But that's just my personal use, hence I was asking.
And I was wondering if it hasn't been broken in the past for arm64 sunxi
boards already, because aarch64 code is usually bigger (I remember
seeing like +20% for u-boot.bin in the past).

> And I guess the question should be turned the other way around. Should
> you expect your environment to be erased / ignored by any upgrade?

I think this is usually the case for a BIOS upgrade on a PC.

> There's never been any documentation on this as far as I know, so
> there's probably people that will expect it to be fixed, and things
> keep on booting.

That's probably right and we should be nice ;-)

>> I see that the environment is hardcoded to 0x88000 in env/Kconfig.
>> Where does this value come from? Why is it this rather arbitrary value?
> 
> It predates my involvement in U-Boot, so I don't really know, but I
> guess some arbitrary value needed to be picked and someone did (maybe
> Hans or Enrick) because it seemed reasonable at the time.

I chased it down to:
commit e24ea55c04a8ee9c273dd879edda23bbde3d807a
Author: Ian Campbell 
Date:   Mon May 5 14:42:31 2014 +0100

sunxi: mmc support

So yeah, dawn of time (for upstream sunxi support).

>> I believe the real limit should be 1MB - ENV_SIZE.
>> Most sane partitioning tools put the first partition at 1MB, so this
>> leaves the space below that to the bootloader/firmware.
> 
> Is that 1MB after the partition table or 1MB since the beginning of
> the device?

The beginning of the device. I would expect a (legacy) layout to be:
@0: MBR (1 sector)
@8K: SPL (up to 32KB)
@40K: U-Boot image
(@544K: environment)
@1MB: first primary partition
Not sure if there is anything else in there.

I wonder if we could insert some code in U-Boot to move the environment
in preparation for a hard change? Like:
- Before looking at 544K, check for a valid environment at 896K.
- If an env is found @544K: move it to 896K, invalidate the 544K copy.

If we have this algorithm live for some time, we might be able to catch
and migrate many users, without making life miserable for *everyone*.
Not perfect, I know, but better than a hard cut.
Meanwhile we switch to Thumb2 to buy us some time and add a build time
check to be alerted when future builds exceed the current limit.

>> This would put the actual limit at 856 KB for now - that should be
>> enough for everybody ;-)
>> We could even push this further by reducing ENV_SIZE to say 64KB.
>>
>> At least that would buy us some time to address this issue in a more
>> sustainable way.
> 
> Yeah, but even if we could address the issues mentionned above, we'd
> still need to take care of the partitions for let's say the
> environment that would need to be moved as well. This is just not
> practical.

I don't understand. What partitions? Android? Do they start between 544K
and 1MB?

> I guess we could introduce a new image with more room for the u-boot
> binary, and advertise it as such. But we would still have to build the
> old one for quite some time.

Who would be "we", exactly? Distributions?
I guess this is the only case where we want to preserve the ENV
location? Could they mitigate this by using the transitional schema as
described above?
For new (whole) images this would certainly not be a problem, would it?

Cheers,
Andre.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] sunxi: binman: Add U-Boot binary size check

[Bin Meng]

On Thu, Oct 19, 2017 at 10:04 PM, Maxime Ripard
 wrote:
> The U-boot binary may trip over its actual allocated size in the storage.
> In such a case, the environment will not be readable anymore (because
> corrupted when the new image was flashed), and any attempt at using saveenv
> to reconstruct the environment will result in a corrupted U-boot binary.
>

nits: U-boot -> U-Boot

Please fix this globally in this commit.

> Signed-off-by: Maxime Ripard 
> ---
>  arch/arm/dts/sunxi-u-boot.dtsi | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi
> index 5adfd9bca2ec..b44660e8d37e 100644
> --- a/arch/arm/dts/sunxi-u-boot.dtsi
> +++ b/arch/arm/dts/sunxi-u-boot.dtsi
> @@ -1,5 +1,13 @@
>  #include 
>
> +/*
> + * This is the maximum size the U-boot binary can be, which is
> + * basically the start of the environment, minus the (padded) size of
> + * the SPL), minus the offset at which the generated file is supposed
> + * to be flashed in the MMC.
> + */
> +#define UBOOT_MAX_SIZE (CONFIG_ENV_OFFSET - CONFIG_SPL_PAD_TO - (8 << 10))
> +
>  / {
> binman {
> filename = "u-boot-sunxi-with-spl.bin";
> @@ -8,6 +16,9 @@
> filename = "spl/sunxi-spl.bin";
> };
> u-boot-img {
> +#ifdef CONFIG_MMC
> +   size = ;
> +#endif
> pos = ;
> };
> };
> --


Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/2] sunxi: binman: Add U-Boot binary size check

[Maxime Ripard]

The U-boot binary may trip over its actual allocated size in the storage.
In such a case, the environment will not be readable anymore (because
corrupted when the new image was flashed), and any attempt at using saveenv
to reconstruct the environment will result in a corrupted U-boot binary.

Signed-off-by: Maxime Ripard 
---
 arch/arm/dts/sunxi-u-boot.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi
index 5adfd9bca2ec..b44660e8d37e 100644
--- a/arch/arm/dts/sunxi-u-boot.dtsi
+++ b/arch/arm/dts/sunxi-u-boot.dtsi
@@ -1,5 +1,13 @@
 #include 
 
+/*
+ * This is the maximum size the U-boot binary can be, which is
+ * basically the start of the environment, minus the (padded) size of
+ * the SPL), minus the offset at which the generated file is supposed
+ * to be flashed in the MMC.
+ */
+#define UBOOT_MAX_SIZE (CONFIG_ENV_OFFSET - CONFIG_SPL_PAD_TO - (8 << 10))
+
 / {
binman {
filename = "u-boot-sunxi-with-spl.bin";
@@ -8,6 +16,9 @@
filename = "spl/sunxi-spl.bin";
};
u-boot-img {
+#ifdef CONFIG_MMC
+   size = ;
+#endif
pos = ;
};
};
-- 
2.14.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 0/2] sunxi: Fix boot of Cubietruk and al.

[Maxime Ripard]

Hi

Most featureful boards, such as the Cubietruck, have been broken since
the release 2017.09 (the two variants of the Olinuxino-Lime2 and the
cubietruck at least, possibly more since then).

This is due to a size increase of the binary that will trip us across
the size we've been using in our default configuration since forever,
and widely distributed through the u-boot-sunxi-with-spl.bin file.

We would have several ways to work around it. The first one would be
to just increase the offset of the environment. However, since it
would break all the environments of our users and possibly the custom
partition scheme that they would have created, it doesn't really seem
like a smart move.

The second one would be to move the environment to a filesystem file,
which would also break all the existing users. This can be envisionned
as a long term fix though.

Another one would be to start trimming down a bit our enabled options
in order to reduce the size and to gain some extra space for users
customisations. However, this will always result in pointless and
endless discussions, so let's move away from that.

The final one that has been implemented would be to just build U-Boot
using thumb2 to push back the issue until hopefully I'm no longer
maintainer or the switch to the env filesystem would have been done.

I've also added a patch to make sure that the compilation breaks and
that we can notice.

Maxime


Maxime Ripard (2):
  sunxi: binman: Add U-Boot binary size check
  sunxi: Enable THUMB build for the U-Boot binary

 arch/arm/Kconfig   |  1 +
 arch/arm/dts/sunxi-u-boot.dtsi | 11 +++
 2 files changed, 12 insertions(+)

-- 
2.14.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/2] sunxi: Enable THUMB build for the U-Boot binary

[Maxime Ripard]

We start to get to the limit of our main U-Boot binary size (with some
boards even crossing it). Enable its build using thumb2 to get some extra
room.

Suggested-by: Siarhei Siamashka 
Signed-off-by: Maxime Ripard 
---
 arch/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 64e0ee43f112..83b7aa51dc2c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -698,6 +698,7 @@ config ARCH_SUNXI
select SPL_SYS_MALLOC_SIMPLE if SPL
select SYS_NS16550
select SPL_SYS_THUMB_BUILD if !ARM64
+   select SYS_THUMB_BUILD if !ARM64
select USB if DISTRO_DEFAULTS
select USB_STORAGE if DISTRO_DEFAULTS
select USB_KEYBOARD if DISTRO_DEFAULTS
-- 
2.14.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Maxime Ripard]

On Thu, Oct 19, 2017 at 09:28:03AM -0400, Tom Rini wrote:
> On Thu, Oct 19, 2017 at 10:26:46AM +0200, Maxime Ripard wrote:
> > Hi,
> > 
> > Most featureful boards, such as the Cubietruck, have been broken since
> > the release 2017.09.
> > 
> > This is due to a size increase of the binary that will trip us across
> > the size we've been using in the u-boot-sunxi-with-spl.bin file.
> > 
> > We would have two ways to work around it. The first one would be to
> > just increase the offset of the environment. However, since it would
> > break all the environments of our users and possibly the custom
> > partition scheme that they would have created, it doesn't really seem
> > like a smart move.
> > 
> > Another one would be to start trimming down a bit our enabled options
> > in order to reduce the size and to gain some extra space for users
> > customisations. I've taken care some of the low hanging fruits, and we
> > should probably take another go at it in the future (and add a size
> > check in the image build somehow?)
> 
> So, where is the over-run exactly?  We have CONFIG_SPL_MAX_SIZE to
> ensure that we have SPL fitting within constraints.  For U-Boot itself
> we don't have a generic check but it's usually done with a custom linker
> script (which could in turn just #include the regular one I think).

The overlap is between the end of the U-Boot binary (so
SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR in this case + U-Boot size) and
ENV_OFFSET.

I've been able to add a check in the u-boot-sunxi-with-spl.bin for the
size, but I guess we could have something generic as well. This seems
to not be very trivial to do though, since some offsets (ENV_OFFSET)
are in bytes, and some other in storage units
(SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR in blocks, SYS_SPI_U_BOOT_OFFS and
SYS_NAND_U_BOOT_OFFS in bytes), and then some other are just booting
from a partition and we can't really do anything there.

I'll send the patches, let's start the discussion from there.

Maxime


-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Tom Rini]

On Thu, Oct 19, 2017 at 03:24:57PM +0200, Maxime Ripard wrote:
> On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote:
> > Hi,
> > 
> > On 19/10/17 09:26, Maxime Ripard wrote:
> > > Hi,
> > > 
> > > Most featureful boards, such as the Cubietruck, have been broken since
> > > the release 2017.09.
> > > 
> > > This is due to a size increase of the binary that will trip us across
> > > the size we've been using in the u-boot-sunxi-with-spl.bin file.
> > > 
> > > We would have two ways to work around it. The first one would be to
> > > just increase the offset of the environment. However, since it would
> > > break all the environments of our users and possibly the custom
> > > partition scheme that they would have created, it doesn't really seem
> > > like a smart move.
> > 
> > Is that really such a problem? How many people rely on having their
> > custom environment preserved over an update? (That's an honest question)
> 
> All of them, I guess. In your U-boot upgrade script, do you do a 'env
> default -a; saveenv' all the time ?
> 
> I know I don't.
> 
> And I guess the question should be turned the other way around. Should
> you expect your environment to be erased / ignored by any upgrade?
> 
> There's never been any documentation on this as far as I know, so
> there's probably people that will expect it to be fixed, and things
> keep on booting.

There is a strong expectation that environment is preserved.  In
deployment cases, it's a must, and when it's not able to happen, people
have to work their upgrade such that it knows and the flag-day type
action happens.

It's certainly not unprecedented to change the env location / size /
type (we've done it on am335x_evm/related a few times) but it usually
requires a good reason and communication outward too.

> > I see that the environment is hardcoded to 0x88000 in env/Kconfig.
> > Where does this value come from? Why is it this rather arbitrary value?
> 
> It predates my involvement in U-Boot, so I don't really know, but I
> guess some arbitrary value needed to be picked and someone did (maybe
> Hans or Enrick) because it seemed reasonable at the time.

Yes, it's likely a reasonable at the time choice.  This is also, FWIW, I
try and encourage new SoCs to pick env in filesystem options instead as
it's generally more friendly for reference / general purpose type
builds, and custom designs can still easily figure out where they want
to store env and do so.

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Tom Rini]

On Thu, Oct 19, 2017 at 10:26:46AM +0200, Maxime Ripard wrote:
> Hi,
> 
> Most featureful boards, such as the Cubietruck, have been broken since
> the release 2017.09.
> 
> This is due to a size increase of the binary that will trip us across
> the size we've been using in the u-boot-sunxi-with-spl.bin file.
> 
> We would have two ways to work around it. The first one would be to
> just increase the offset of the environment. However, since it would
> break all the environments of our users and possibly the custom
> partition scheme that they would have created, it doesn't really seem
> like a smart move.
> 
> Another one would be to start trimming down a bit our enabled options
> in order to reduce the size and to gain some extra space for users
> customisations. I've taken care some of the low hanging fruits, and we
> should probably take another go at it in the future (and add a size
> check in the image build somehow?)

So, where is the over-run exactly?  We have CONFIG_SPL_MAX_SIZE to
ensure that we have SPL fitting within constraints.  For U-Boot itself
we don't have a generic check but it's usually done with a custom linker
script (which could in turn just #include the regular one I think).

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Maxime Ripard]

Hi Siarhei,

On Thu, Oct 19, 2017 at 12:10:44PM +0300, Siarhei Siamashka wrote:
> On Thu, Oct 19, 2017 at 11:26 AM, Maxime Ripard
>  wrote:
> > Hi,
> >
> > Most featureful boards, such as the Cubietruck, have been broken since
> > the release 2017.09.
> >
> > This is due to a size increase of the binary that will trip us across
> > the size we've been using in the u-boot-sunxi-with-spl.bin file.
> >
> > We would have two ways to work around it. The first one would be to
> > just increase the offset of the environment. However, since it would
> > break all the environments of our users and possibly the custom
> > partition scheme that they would have created, it doesn't really seem
> > like a smart move.
> >
> > Another one would be to start trimming down a bit our enabled options
> > in order to reduce the size and to gain some extra space for users
> > customisations. I've taken care some of the low hanging fruits, and we
> > should probably take another go at it in the future (and add a size
> > check in the image build somehow?)
> >
> > Maxime
> >
> > Maxime Ripard (3):
> >   ARM: sunxi: Disable USB host options by default
> >   ARM: sunxi: Disable FAT write by default
> >   efi_loader: Do not enable it by default for sunxi
> >
> >  arch/arm/Kconfig   | 4 
> >  lib/efi_loader/Kconfig | 2 +-
> >  2 files changed, 1 insertion(+), 5 deletions(-)
> 
> We can first enable Thumb2 build by default for 32-bit sunxi boards
> and this should fix Cubietruck problems.
> 
> $ cat .config | grep THUMB
> CONFIG_HAS_THUMB2=y
> # CONFIG_SYS_THUMB_BUILD is not set
> CONFIG_SPL_SYS_THUMB_BUILD=y
> 
> As a test, enabling CONFIG_SYS_THUMB_BUILD=y in Cubietruck_defconfig
> reduces the size of the resulting U-Boot binary.
> 
> == Before: ==
> 
> $ arm-linux-gnueabihf-size u-boot
>text   databssdechexfilename
>  489398  26492 249240 765130  baccau-boot.orig
> 
> == After: ==
> 
> $ arm-linux-gnueabihf-size u-boot
>text   databssdechexfilename
>  366314  26492 249232 642038  9cbf6u-boot

I just gave it a try, and indeed it solves the issue for all the
boards. Thanks for the suggestion!

I'll send the patches.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Maxime Ripard]

On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote:
> Hi,
> 
> On 19/10/17 09:26, Maxime Ripard wrote:
> > Hi,
> > 
> > Most featureful boards, such as the Cubietruck, have been broken since
> > the release 2017.09.
> > 
> > This is due to a size increase of the binary that will trip us across
> > the size we've been using in the u-boot-sunxi-with-spl.bin file.
> > 
> > We would have two ways to work around it. The first one would be to
> > just increase the offset of the environment. However, since it would
> > break all the environments of our users and possibly the custom
> > partition scheme that they would have created, it doesn't really seem
> > like a smart move.
> 
> Is that really such a problem? How many people rely on having their
> custom environment preserved over an update? (That's an honest question)

All of them, I guess. In your U-boot upgrade script, do you do a 'env
default -a; saveenv' all the time ?

I know I don't.

And I guess the question should be turned the other way around. Should
you expect your environment to be erased / ignored by any upgrade?

There's never been any documentation on this as far as I know, so
there's probably people that will expect it to be fixed, and things
keep on booting.

> I see that the environment is hardcoded to 0x88000 in env/Kconfig.
> Where does this value come from? Why is it this rather arbitrary value?

It predates my involvement in U-Boot, so I don't really know, but I
guess some arbitrary value needed to be picked and someone did (maybe
Hans or Enrick) because it seemed reasonable at the time.

> I believe the real limit should be 1MB - ENV_SIZE.
> Most sane partitioning tools put the first partition at 1MB, so this
> leaves the space below that to the bootloader/firmware.

Is that 1MB after the partition table or 1MB since the beginning of
the device?

> This would put the actual limit at 856 KB for now - that should be
> enough for everybody ;-)
> We could even push this further by reducing ENV_SIZE to say 64KB.
> 
> At least that would buy us some time to address this issue in a more
> sustainable way.

Yeah, but even if we could address the issues mentionned above, we'd
still need to take care of the partitions for let's say the
environment that would need to be moved as well. This is just not
practical.

I guess we could introduce a new image with more room for the u-boot
binary, and advertise it as such. But we would still have to build the
old one for quite some time.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Tom Rini]

On Thu, Oct 19, 2017 at 10:26:49AM +0200, Maxime Ripard wrote:

> The EFI loader support takes around 31kB on an ARMv7 board, which makes us
> trip across the size limit we've had on the U-Boot binary.
> 
> Since it's not an essential feature, disable it by default for ARCH_SUNXI
> so that we get back some extra room for user customisations.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  lib/efi_loader/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index d2b6327119b4..a80a914b2fe8 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -1,7 +1,7 @@
>  config EFI_LOADER
>   bool "Support running EFI Applications in U-Boot"
>   depends on (ARM || X86) && OF_LIBFDT
> - default y
> + default y if !ARCH_SUNXI
>   help
> Select this option if you want to run EFI applications (like grub2)
> on top of U-Boot. If this option is enabled, U-Boot will expose EFI

I want to speak against this particular option.  "U-Boot boots EFI
application, $distro just works" is a huge deal right now.  As much as I
would have preferred various other things happen at various points in
the past, kicking off an EFI application to boot Linux is huge and
important outside of the embedded space (and ARM Ltd is pushing this
path within the embedded space).  There are cases where we don't want
the EFI loader, but for ARMv7/AArch64 this should be enabled by default
and turned off at the board level for specific use cases.

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [RFC PATCH u-boot v2] ARM: arch-meson: build memory banks using reported memory from registers

[Neil Armstrong]

As discussed at [1], the Amlogic Meson GX SoCs can embed a BL31 firmware
and a secondary BL32 firmware.
Since mid-2017, the reserved memory address of the BL31 firmware was moved
and grown for security reasons.

But mainline U-boot and Linux has the old address and size fixed.

These SoCs have a register interface to get the two firmware reserved
memory start and sizes.

This patch adds a dynamic reservation of the memory zones in the device tree 
bootmem
reserved memory zone used by the kernel in early boot.
To be complete, the memory zones are also added to the EFI reserved zones.

[1] http://lists.infradead.org/pipermail/linux-amlogic/2017-October/004860.html

Changes since v1:
- switch to fdt rsv mem table and efi reserve memory
- replaced in_le32 by readl()

Signed-off-by: Neil Armstrong 
---
 arch/arm/include/asm/arch-meson/gxbb.h |  17 +
 arch/arm/mach-meson/board.c| 117 ++---
 board/amlogic/odroid-c2/odroid-c2.c|   7 ++
 board/amlogic/p212/p212.c  |   7 ++
 configs/odroid-c2_defconfig|   1 +
 configs/p212_defconfig |   1 +
 include/configs/meson-gxbb-common.h|   2 +-
 7 files changed, 143 insertions(+), 9 deletions(-)

diff --git a/arch/arm/include/asm/arch-meson/gxbb.h 
b/arch/arm/include/asm/arch-meson/gxbb.h
index 74d5290..117f796 100644
--- a/arch/arm/include/asm/arch-meson/gxbb.h
+++ b/arch/arm/include/asm/arch-meson/gxbb.h
@@ -7,10 +7,27 @@
 #ifndef __GXBB_H__
 #define __GXBB_H__
 
+#define GXBB_FIRMWARE_MEM_SIZE 0x100
+
+#define GXBB_AOBUS_BASE0xc810
 #define GXBB_PERIPHS_BASE  0xc8834400
 #define GXBB_HIU_BASE  0xc883c000
 #define GXBB_ETH_BASE  0xc941
 
+/* Always-On Peripherals registers */
+#define GXBB_AO_ADDR(off)  (GXBB_AOBUS_BASE + ((off) << 2))
+
+#define GXBB_AO_SEC_GP_CFG0GXBB_AO_ADDR(0x90)
+#define GXBB_AO_SEC_GP_CFG3GXBB_AO_ADDR(0x93)
+#define GXBB_AO_SEC_GP_CFG4GXBB_AO_ADDR(0x94)
+#define GXBB_AO_SEC_GP_CFG5GXBB_AO_ADDR(0x95)
+
+#define GXBB_AO_MEM_SIZE_MASK  0x
+#define GXBB_AO_MEM_SIZE_SHIFT 16
+#define GXBB_AO_BL31_RSVMEM_SIZE_MASK  0x
+#define GXBB_AO_BL31_RSVMEM_SIZE_SHIFT 16
+#define GXBB_AO_BL32_RSVMEM_SIZE_MASK  0x
+
 /* Peripherals registers */
 #define GXBB_PERIPHS_ADDR(off) (GXBB_PERIPHS_BASE + ((off) << 2))
 
diff --git a/arch/arm/mach-meson/board.c b/arch/arm/mach-meson/board.c
index e89c6aa..24733e1 100644
--- a/arch/arm/mach-meson/board.c
+++ b/arch/arm/mach-meson/board.c
@@ -11,6 +11,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -34,16 +37,114 @@ int dram_init(void)
return 0;
 }
 
-int dram_init_banksize(void)
+phys_size_t get_effective_memsize(void)
 {
-   /* Reserve first 16 MiB of RAM for firmware */
-   gd->bd->bi_dram[0].start = 0x100;
-   gd->bd->bi_dram[0].size  = 0xf00;
-   /* Reserve 2 MiB for ARM Trusted Firmware (BL31) */
-   gd->bd->bi_dram[1].start = 0x1000;
-   gd->bd->bi_dram[1].size  = gd->ram_size - 0x1020;
-   return 0;
+   /* Size is reported in MiB, convert it in bytes */
+   return ((readl(GXBB_AO_SEC_GP_CFG0) & GXBB_AO_MEM_SIZE_MASK)
+   >> GXBB_AO_MEM_SIZE_SHIFT) * SZ_1M;
+}
+
+#ifdef CONFIG_MESON_GXBB
+/*
+ * Early Meson GXBB Firmware revision did not provide the reserved
+ * memory zones in the registers, keep fixed memory zone handling.
+ */
+
+void ft_cpu_setup(void *fdt, bd_t *bd)
+{
+   int ret;
+
+   /* Add first 16MiB reserved zone */
+   ret = fdt_add_mem_rsv(fdt, 0, GXBB_FIRMWARE_MEM_SIZE);
+   if (ret)
+   printf("Could not reserve zone @ 0x0\n");
+
+#if defined(CONFIG_EFI_LOADER)
+   efi_add_memory_map(0, ALIGN(GXBB_FIRMWARE_MEM_SIZE, EFI_PAGE_SIZE)
+   >> EFI_PAGE_SHIFT,
+  EFI_RESERVED_MEMORY_TYPE, false);
+#endif
+
+   /* Add BL31 reserved zone */
+   ret = fdt_add_mem_rsv(fdt, 0x1000, 0x20);
+   if (ret)
+   printf("Could not reserve BL1 zone @ 0x1000\n");
+
+#if defined(CONFIG_EFI_LOADER)
+   efi_add_memory_map(0x1000,
+  ALIGN(0x20, EFI_PAGE_SIZE)
+   >> EFI_PAGE_SHIFT,
+  EFI_RESERVED_MEMORY_TYPE, false);
+#endif
+}
+#endif
+
+#ifdef CONFIG_MESON_GXL
+void ft_cpu_setup(void *fdt, bd_t *bd)
+{
+   u64 bl31_size, bl31_start;
+   u64 bl32_size, bl32_start;
+   u32 reg;
+   int ret;
+
+   /*
+* Get ARM Trusted Firmware reserved memory zones in :
+* - AO_SEC_GP_CFG3: bl32 & bl31 size in KiB, can be 0
+* - AO_SEC_GP_CFG5: bl31 physical start address, can be NULL
+* - AO_SEC_GP_CFG4: bl32 physical start address, can be NULL
+*/
+
+   reg = readl(GXBB_AO_SEC_GP_CFG3);
+
+   bl31_size = ((reg & 

Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Tom Rini]

On Thu, Oct 19, 2017 at 12:10:44PM +0300, Siarhei Siamashka wrote:
> On Thu, Oct 19, 2017 at 11:26 AM, Maxime Ripard
>  wrote:
> > Hi,
> >
> > Most featureful boards, such as the Cubietruck, have been broken since
> > the release 2017.09.
> >
> > This is due to a size increase of the binary that will trip us across
> > the size we've been using in the u-boot-sunxi-with-spl.bin file.
> >
> > We would have two ways to work around it. The first one would be to
> > just increase the offset of the environment. However, since it would
> > break all the environments of our users and possibly the custom
> > partition scheme that they would have created, it doesn't really seem
> > like a smart move.
> >
> > Another one would be to start trimming down a bit our enabled options
> > in order to reduce the size and to gain some extra space for users
> > customisations. I've taken care some of the low hanging fruits, and we
> > should probably take another go at it in the future (and add a size
> > check in the image build somehow?)
> >
> > Maxime
> >
> > Maxime Ripard (3):
> >   ARM: sunxi: Disable USB host options by default
> >   ARM: sunxi: Disable FAT write by default
> >   efi_loader: Do not enable it by default for sunxi
> >
> >  arch/arm/Kconfig   | 4 
> >  lib/efi_loader/Kconfig | 2 +-
> >  2 files changed, 1 insertion(+), 5 deletions(-)
> 
> We can first enable Thumb2 build by default for 32-bit sunxi boards
> and this should fix Cubietruck problems.
> 
> $ cat .config | grep THUMB
> CONFIG_HAS_THUMB2=y
> # CONFIG_SYS_THUMB_BUILD is not set
> CONFIG_SPL_SYS_THUMB_BUILD=y
> 
> As a test, enabling CONFIG_SYS_THUMB_BUILD=y in Cubietruck_defconfig
> reduces the size of the resulting U-Boot binary.
> 
> == Before: ==
> 
> $ arm-linux-gnueabihf-size u-boot
>text   databssdechexfilename
>  489398  26492 249240 765130  baccau-boot.orig
> 
> == After: ==
> 
> $ arm-linux-gnueabihf-size u-boot
>text   databssdechexfilename
>  366314  26492 249232 642038  9cbf6u-boot

Yes, I would strongly encourage enabling Thumb2 support instead of
removing various features.

I would also encourage looking at moving environment either "up", or
switching to env in filesystem in the future as a "Yes, we broke your
existing setup, but we gave you a real useful feature".

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCH u-boot] ARM: arch-meson: build memory banks using reported memory from registers

[Neil Armstrong]

On 19/10/2017 12:45, Ben Dooks wrote:
> On 2017-10-19 10:04, Neil Armstrong wrote:
>> As discussed at [1], the Amlogic Meson GX SoCs can embed a BL31 firmware
>> and a secondary BL32 firmware.
>> Since mid-2017, the reserved memory address of the BL31 firmware was moved
>> and grown for security reasons.
>>
>> But mainline U-boot and Linux has the old address and size fixed.
>>
>> These SoCs have a register interface to get the two firmware reserved
>> memory start and sizes.
>>
>> This patch adds a dynamic memory bank redistribution according to the
>> values in the firmware.
>>
>> Note that the memory address ordering between BL31 and BL32 is not 
>> etablished,
>> so it must be determined dynamically.
>>
>> [1] 
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-October/004860.html
>>
>> Signed-off-by: Neil Armstrong 
>> ---
>>  arch/arm/include/asm/arch-meson/gxbb.h | 15 ++
>>  arch/arm/mach-meson/board.c    | 99 
>> +++---
>>  include/configs/meson-gxbb-common.h    |  2 +-
>>  3 files changed, 109 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/arch-meson/gxbb.h
>> b/arch/arm/include/asm/arch-meson/gxbb.h
>> index 74d5290..57db37e 100644
>> --- a/arch/arm/include/asm/arch-meson/gxbb.h
>> +++ b/arch/arm/include/asm/arch-meson/gxbb.h
>> @@ -7,10 +7,25 @@
>>  #ifndef __GXBB_H__
>>  #define __GXBB_H__
>>
>> +#define GXBB_AOBUS_BASE    0xc810
>>  #define GXBB_PERIPHS_BASE    0xc8834400
>>  #define GXBB_HIU_BASE    0xc883c000
>>  #define GXBB_ETH_BASE    0xc941
>>
>> +/* Always-On Peripherals registers */
>> +#define GXBB_AO_ADDR(off)    (GXBB_AOBUS_BASE + ((off) << 2))
>> +
>> +#define GXBB_AO_SEC_GP_CFG0    GXBB_AO_ADDR(0x90)
>> +#define GXBB_AO_SEC_GP_CFG3    GXBB_AO_ADDR(0x93)
>> +#define GXBB_AO_SEC_GP_CFG4    GXBB_AO_ADDR(0x94)
>> +#define GXBB_AO_SEC_GP_CFG5    GXBB_AO_ADDR(0x95)
>> +
>> +#define GXBB_AO_MEM_SIZE_MASK    0x
>> +#define GXBB_AO_MEM_SIZE_SHIFT    16
>> +#define GXBB_AO_BL31_RSVMEM_SIZE_MASK    0x
>> +#define GXBB_AO_BL31_RSVMEM_SIZE_SHIFT    16
>> +#define GXBB_AO_BL32_RSVMEM_SIZE_MASK    0x
>> +
>>  /* Peripherals registers */
>>  #define GXBB_PERIPHS_ADDR(off)    (GXBB_PERIPHS_BASE + ((off) << 2))
>>
>> diff --git a/arch/arm/mach-meson/board.c b/arch/arm/mach-meson/board.c
>> index e89c6aa..bd330af 100644
>> --- a/arch/arm/mach-meson/board.c
>> +++ b/arch/arm/mach-meson/board.c
>> @@ -11,6 +11,8 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>
>>  DECLARE_GLOBAL_DATA_PTR;
>>
>> @@ -34,14 +36,99 @@ int dram_init(void)
>>  return 0;
>>  }
>>
>> +phys_size_t get_effective_memsize(void)
>> +{
>> +    /* Size is reported in MiB, convert it in bytes */
>> +    return ((in_le32(GXBB_AO_SEC_GP_CFG0) & GXBB_AO_MEM_SIZE_MASK)
>> +    >> GXBB_AO_MEM_SIZE_SHIFT) * SZ_1M;
> 
> Is in_le32 suitable here?

Yes, but replace with readl.

> 
>> +}
>> +
>>  int dram_init_banksize(void)
>>  {
>> -    /* Reserve first 16 MiB of RAM for firmware */
>> -    gd->bd->bi_dram[0].start = 0x100;
>> -    gd->bd->bi_dram[0].size  = 0xf00;
>> -    /* Reserve 2 MiB for ARM Trusted Firmware (BL31) */
>> -    gd->bd->bi_dram[1].start = 0x1000;
>> -    gd->bd->bi_dram[1].size  = gd->ram_size - 0x1020;
>> +    u32 bl31_size, bl31_start;
>> +    u32 bl32_size, bl32_start;
>> +    /* Start after first 16MiB reserved zone */
>> +    unsigned int next = 0;
>> +    u32 last = 0x100;
>> +    u32 reg;
>> +
>> +    /*
>> + * Get ARM Trusted Firmware reserved memory zones in :
>> + * - AO_SEC_GP_CFG3: bl32 & bl31 size in KiB, can be 0
>> + * - AO_SEC_GP_CFG5: bl31 physical start address, can be NULL
>> + * - AO_SEC_GP_CFG4: bl32 physical start address, can be NULL
>> + */
> 
> Can you use bootmem reserve to do this?

Yes, you are right, I switched to fdt_add_mem_rsv() and it gets much simpler.

But I now need to also reserve it for EFI.

I'll post a v2 with it.

> 
>> +
>> +    reg = in_le32(GXBB_AO_SEC_GP_CFG3);
>> +
>> +    bl31_size = ((reg & GXBB_AO_BL31_RSVMEM_SIZE_MASK)
>> +    >> GXBB_AO_BL31_RSVMEM_SIZE_SHIFT) * SZ_1K;
>> +    bl32_size = (reg & GXBB_AO_BL32_RSVMEM_SIZE_MASK) * SZ_1K;
>> +
>> +    bl31_start = in_le32(GXBB_AO_SEC_GP_CFG5);
>> +    bl32_start = in_le32(GXBB_AO_SEC_GP_CFG4);
>> +
>> +    if (bl31_size && bl31_start && bl32_size && bl32_start) {
>> +    /* Reserve memory for ARM Trusted Firmware (BL31 && BL32) */
>> +    gd->bd->bi_dram[next].start = last;
>> +    if (bl31_start > bl32_start)
>> +    gd->bd->bi_dram[next].size = bl32_start - last;
>> +    else
>> +    gd->bd->bi_dram[next].size = bl31_start - last;
>> +
>> +    last = gd->bd->bi_dram[next].start +
>> +    gd->bd->bi_dram[next].size;
>> +
>> +    if (bl31_start > bl32_start)
>> +    last += bl32_size;
>> +    else
>> +    last += bl31_size;
>> +    

Re: [U-Boot] [PATCH v3 6/6] cmd: gpt: solve issue for swap and rename command

[Patrick DELAUNAY]

Hi,

> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> 
> On 10/18/2017 07:11 AM, Patrick Delaunay wrote:
> > don't use prettyprint_part_size() in create_gpt_partitions_list() that
> > avoid to align offset and size to 1 MiB and increase precision for
> > start and size.
> > This patch avoid the risk to change partition size and lost data
> > during rename or swap.
> 
> All the test/py changes in this series,
> Acked-by: Stephen Warren 
> 
> The series,
> Tested-by: Stephen Warren 
> 
> If you're looking for more things to change(!), perhaps change the sgdisk
> commands so that the partitions are big enough that 'gpt read host 0' says
> something other than 'size 0MiB' for the partitions; when I saw that, I was
> initially rather confused until I realized that the partitions were less than 
> 1MiB!

I don't really looking...
but I agree: size 0MiB is confusing, I had the same reaction the first time.

So I will propose something when this serie will be accepted,
just update the test to have 2 partitions with different size and > 1MiB.

Regards
Patrick
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Andre Przywara]

Hi,

On 19/10/17 09:26, Maxime Ripard wrote:
> Hi,
> 
> Most featureful boards, such as the Cubietruck, have been broken since
> the release 2017.09.
> 
> This is due to a size increase of the binary that will trip us across
> the size we've been using in the u-boot-sunxi-with-spl.bin file.
> 
> We would have two ways to work around it. The first one would be to
> just increase the offset of the environment. However, since it would
> break all the environments of our users and possibly the custom
> partition scheme that they would have created, it doesn't really seem
> like a smart move.

Is that really such a problem? How many people rely on having their
custom environment preserved over an update? (That's an honest question)

I see that the environment is hardcoded to 0x88000 in env/Kconfig.
Where does this value come from? Why is it this rather arbitrary value?

I believe the real limit should be 1MB - ENV_SIZE.
Most sane partitioning tools put the first partition at 1MB, so this
leaves the space below that to the bootloader/firmware.

This would put the actual limit at 856 KB for now - that should be
enough for everybody ;-)
We could even push this further by reducing ENV_SIZE to say 64KB.

At least that would buy us some time to address this issue in a more
sustainable way.

Cheers,
Andre.

> Another one would be to start trimming down a bit our enabled options
> in order to reduce the size and to gain some extra space for users
> customisations. I've taken care some of the low hanging fruits, and we
> should probably take another go at it in the future (and add a size
> check in the image build somehow?)
> 
> Maxime
> 
> Maxime Ripard (3):
>   ARM: sunxi: Disable USB host options by default
>   ARM: sunxi: Disable FAT write by default
>   efi_loader: Do not enable it by default for sunxi
> 
>  arch/arm/Kconfig   | 4 
>  lib/efi_loader/Kconfig | 2 +-
>  2 files changed, 1 insertion(+), 5 deletions(-)
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Benoît Thébaudeau]

On 19/10/2017 at 14:52, Fabio Estevam wrote:
> On Thu, Oct 19, 2017 at 10:46 AM, Otavio Salvador
>  wrote:
> 
>> I think the original RFC is better as workaround as it solves the
>> issue for other boards. This does not mean we shouldn't fix the root
>> cause ...
> 
> Actually I don't know if this issue happens with other mx25/mx51 boards.
> 
> Benoit says his mx25 board can operate with high speed SD card in a
> modified version of U-Boot.
> I asked him if he could test his board with mainline U-Boot instead
> for comparison.

I will try to quickly run mainline U-Boot on my board as asked to see.

Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Fabio Estevam]

On Thu, Oct 19, 2017 at 10:46 AM, Otavio Salvador
 wrote:

> I think the original RFC is better as workaround as it solves the
> issue for other boards. This does not mean we shouldn't fix the root
> cause ...

Actually I don't know if this issue happens with other mx25/mx51 boards.

Benoit says his mx25 board can operate with high speed SD card in a
modified version of U-Boot.
I asked him if he could test his board with mainline U-Boot instead
for comparison.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Otavio Salvador]

On Thu, Oct 19, 2017 at 10:42 AM, Fabio Estevam  wrote:
> On Thu, Oct 19, 2017 at 9:57 AM, Fabio Estevam  wrote:
>
>> On my tests I need to force it 25MHz operation to be able to use the SD card.
>
> A "less ugly" workaround that affects only mx25pdk:
>
> --- a/board/freescale/mx25pdk/mx25pdk.c
> +++ b/board/freescale/mx25pdk/mx25pdk.c
> @@ -180,7 +180,7 @@ int board_mmc_init(bd_t *bis)
>  * to 50 MHz that can be obtained, which requires to use UPLL as the
>  * clock source. This actually gives 48 MHz.
>  */
> -   imx_set_perclk(MXC_ESDHC1_CLK, true, 5000);
> +   imx_set_perclk(MXC_ESDHC1_CLK, true, 2500);
> esdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC1_CLK);
> return fsl_esdhc_initialize(bis, _cfg[0]);
>  }
>
> For mx51evk this also fixes the issue:
>
> diff --git a/board/freescale/mx51evk/mx51evk.c
> b/board/freescale/mx51evk/mx51evk.c
> index 9e8a02e..72b09b5 100644
> --- a/board/freescale/mx51evk/mx51evk.c
> +++ b/board/freescale/mx51evk/mx51evk.c
> @@ -323,7 +323,7 @@ int board_mmc_init(bd_t *bis)
> u32 index;
> int ret;
>
> -   esdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK);
> +   esdhc_cfg[0].sdhc_clk = 2500;
> esdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC2_CLK);
>
> for (index = 0; index < CONFIG_SYS_FSL_ESDHC_NUM;

I think the original RFC is better as workaround as it solves the
issue for other boards. This does not mean we shouldn't fix the root
cause ...

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Fabio Estevam]

On Thu, Oct 19, 2017 at 9:57 AM, Fabio Estevam  wrote:

> On my tests I need to force it 25MHz operation to be able to use the SD card.

A "less ugly" workaround that affects only mx25pdk:

--- a/board/freescale/mx25pdk/mx25pdk.c
+++ b/board/freescale/mx25pdk/mx25pdk.c
@@ -180,7 +180,7 @@ int board_mmc_init(bd_t *bis)
 * to 50 MHz that can be obtained, which requires to use UPLL as the
 * clock source. This actually gives 48 MHz.
 */
-   imx_set_perclk(MXC_ESDHC1_CLK, true, 5000);
+   imx_set_perclk(MXC_ESDHC1_CLK, true, 2500);
esdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC1_CLK);
return fsl_esdhc_initialize(bis, _cfg[0]);
 }

For mx51evk this also fixes the issue:

diff --git a/board/freescale/mx51evk/mx51evk.c
b/board/freescale/mx51evk/mx51evk.c
index 9e8a02e..72b09b5 100644
--- a/board/freescale/mx51evk/mx51evk.c
+++ b/board/freescale/mx51evk/mx51evk.c
@@ -323,7 +323,7 @@ int board_mmc_init(bd_t *bis)
u32 index;
int ret;

-   esdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK);
+   esdhc_cfg[0].sdhc_clk = 2500;
esdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC2_CLK);

for (index = 0; index < CONFIG_SYS_FSL_ESDHC_NUM;
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Alexander Graf]

On 10/19/2017 11:11 AM, Maxime Ripard wrote:

On Thu, Oct 19, 2017 at 10:44:54AM +0200, Alexander Graf wrote:

On 10/19/2017 10:26 AM, Maxime Ripard wrote:

Hi,

Most featureful boards, such as the Cubietruck, have been broken since
the release 2017.09.

This is due to a size increase of the binary that will trip us across
the size we've been using in the u-boot-sunxi-with-spl.bin file.

We would have two ways to work around it. The first one would be to
just increase the offset of the environment. However, since it would
break all the environments of our users and possibly the custom
partition scheme that they would have created, it doesn't really seem
like a smart move.

Another one would be to start trimming down a bit our enabled options
in order to reduce the size and to gain some extra space for users
customisations. I've taken care some of the low hanging fruits, and we
should probably take another go at it in the future (and add a size
check in the image build somehow?)

How about we add the size check first before crippling the feature
set of sunxi boards? Then maybe rather disable lesser used features
than efi_loader?

All the features have some users. All the kind of arguments that have
been sent so far are that "but I use this feature". Yes. You probably
do. But you can have the same kind of argument for any of the features
enabled.


I agree, but my first statement still holds: Please make sure we don't 
overrun our size restrictions first so that these issue get caught early 
during the development cycle, not when U-Boot is already released.


That said, how about we just imply SYS_THUMB_BUILD in ARCH_SUNXI? That 
way we save even more (going from 537K to 417K with gcc7.1) without 
losing any feature set on 32bit systems.



Alex

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Fabio Estevam]

Hi Benoît,

On Wed, Oct 18, 2017 at 6:10 PM, Benoît Thébaudeau
 wrote:

> Can you try with this?
>
> static const iomux_v3_cfg_t sdhc1_pads[] = {
> NEW_PAD_CTRL(MX25_PAD_SD1_CMD__SD1_CMD, PAD_CTL_PUS_47K_UP | 
> PAD_CTL_SRE_FAST),
> NEW_PAD_CTRL(MX25_PAD_SD1_CLK__SD1_CLK, PAD_CTL_SRE_FAST),
> NEW_PAD_CTRL(MX25_PAD_SD1_DATA0__SD1_DATA0, PAD_CTL_PUS_47K_UP |
> PAD_CTL_SRE_FAST),
> NEW_PAD_CTRL(MX25_PAD_SD1_DATA1__SD1_DATA1, PAD_CTL_PUS_47K_UP |
> PAD_CTL_SRE_FAST),
> NEW_PAD_CTRL(MX25_PAD_SD1_DATA2__SD1_DATA2, PAD_CTL_PUS_47K_UP |
> PAD_CTL_SRE_FAST),
> NEW_PAD_CTRL(MX25_PAD_SD1_DATA3__SD1_DATA3, PAD_CTL_PUS_47K_UP |
> PAD_CTL_SRE_FAST),
> NEW_PAD_CTRL(MX25_PAD_CTL_GRP_DSE_SDHC1, PAD_CTL_DSE_HIGH),
> };

Unfortunately it does not help. Same error:

U-Boot 2017.11-rc2-1-g1f16d26-dirty (Oct 19 2017 - 09:47:25 -0200)

CPU:   Freescale i.MX25 rev1.2 at 399 MHz
Reset cause: POR
Board: MX25PDK
I2C:   ready
DRAM:  64 MiB
No arch specific invalidate_icache_all available!
MMC:   FSL_SDHC: 0
*** Warning - read failed, using default environment

In:serial
Out:   serial
Err:   serial
Net:   FEC
Hit any key to stop autoboot:  0
=> saveenv
Saving Environment to MMC...
Writing to MMC(0)... failed
=> saveenv
Saving Environment to MMC...
Writing to MMC(0)... failed
=>

I don't think it is an IOMUX issue as the kernel has no issues in with
SD high speed card and it uses the same IOMUX settings from U-Boot.

> If you scope the SD clock during U-Boot HS SD transfers, do you get 48
> MHz as expected?

I do see 48MHz.

I would be interested to see if you can get an SD card high speed to
work with mainline U-Boot on your board.

On my tests I need to force it 25MHz operation to be able to use the SD card.

Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] ARM: sunxi: Disable USB host options by default

[Maxime Ripard]

Hi Andre,

On Thu, Oct 19, 2017 at 10:11:19AM +0100, Andre Przywara wrote:
> So while I see that this series fixes a particular problem, I am a bit
> wary of this solution, as this just papers over the issue and will
> likely break in the future again.
> 
> Can't we somehow fix the environment problem? Possibly via the upgrade
> process (save the environment, update U-Boot, re-install the
> environment)? Or some other clever way? That would be more future proof,
> I believe.

That would be the ideal solution, but it would also assume that you
have an upgrade mechanism in the first place. It might work for the
distros, but it will not for anyone else that will just upgrade as
they did it for the last 5 years and suddenly everything is broken.

And part of that upgrade would also be to change the partition layout
if you created partitions that match the various offsets, which is
basically impossible without reflashing everything again.

So yeah, I would very much favor that, but that's not really doable.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Maxime Ripard]

On Thu, Oct 19, 2017 at 10:51:04AM +0200, Alexander Graf wrote:
> >   lib/efi_loader/Kconfig | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index d2b6327119b4..a80a914b2fe8 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -1,7 +1,7 @@
> >   config EFI_LOADER
> > bool "Support running EFI Applications in U-Boot"
> > depends on (ARM || X86) && OF_LIBFDT
> > -   default y
> > +   default y if !ARCH_SUNXI
> 
> Nack on any change to that default line. If you must disable efi_loader (and
> really, I strongly advise not to do so for sunxi), please do so in the
> defconfigs, as nothing prohibits the architecture to work with it.

That's a bit of a separate discussion. We don't want to have too much
churn in the defconfig, as it is basically boilerplate that some will
get wrong, and then you won't have a consistent tool set between
boards, which is also a pain. A pain both to maintain and use if you
want to ship something board agnostic.

However, the preferred way expressed by Tom to change defaults has
been to change those defaults directly in the Kconfig option, instead
of them creeping in everywhere in the arch's or platform Kconfig
files.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Maxime Ripard]

On Thu, Oct 19, 2017 at 01:39:28PM +0200, Mark Kettenis wrote:
> > From: Maxime Ripard 
> > Date: Thu, 19 Oct 2017 10:26:49 +0200
> > 
> > The EFI loader support takes around 31kB on an ARMv7 board, which makes us
> > trip across the size limit we've had on the U-Boot binary.
> > 
> > Since it's not an essential feature, disable it by default for ARCH_SUNXI
> > so that we get back some extra room for user customisations.
> 
> This is an essential feature for booting OpenBSD.  And I believe it is
> a requirement for several Linux distros as well.  I don't think
> disabling this by default is a good idea.

I get it, every one wants its old features. We can't have that. Can we
move forward in the discussion?

> How much of that 31kB is due to recent improvements of the EFI loader
> support?  I understand the desire to have a more complete EFI
> implementation, but if the consequence of that is that the EFI loader
> gets disabled by default on many boards I think we're throwing out the
> baby with the bathwater...

Bisection led to a meaningless (as in not relevant to the current
discussion) commit that was just adding a bit of code, and probably
was just tripping over the limit.

So it's basically only a symptom, and it shouldn't prevent any
development from happening.

What I'd like to happen though is a real discussion on why on Earth we
should have all the usecases in the worlds supported in our
defconfigs, especially for distros that will package and build U-Boot
themselves.

Everyone has a custom defconfig for the kernel. What's so different?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] ARM: sunxi: Disable USB host options by default

[Mark Kettenis]

> From: Maxime Ripard 
> Date: Thu, 19 Oct 2017 10:26:47 +0200
> 
> The USB keyboard and USB storage support are non-essential from an
> architecture-wide sense.
> 
> Remove the selection so that we can trim down the size of our binaries a
> bit.

But many people rely on these options and I'd say they should be
enabled on the majority of the boards out there.

If you really want to go this way, I'd say you should enable these
options in all the board-specific configs and subsequently remove them
from those boards where they're not useful.

> Signed-off-by: Maxime Ripard 
> ---
>  arch/arm/Kconfig | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 64e0ee43f112..0eaf54bd8ddb 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -688,7 +688,6 @@ config ARCH_SUNXI
>   select DM
>   select DM_ETH
>   select DM_GPIO
> - select DM_KEYBOARD
>   select DM_SERIAL
>   select DM_USB if DISTRO_DEFAULTS
>   select OF_BOARD_SETUP
> @@ -699,8 +698,6 @@ config ARCH_SUNXI
>   select SYS_NS16550
>   select SPL_SYS_THUMB_BUILD if !ARM64
>   select USB if DISTRO_DEFAULTS
> - select USB_STORAGE if DISTRO_DEFAULTS
> - select USB_KEYBOARD if DISTRO_DEFAULTS
>   select USE_TINY_PRINTF
>   imply CMD_GPT
>   imply FAT_WRITE
> -- 
> 2.14.2
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Maxime Ripard]

On Thu, Oct 19, 2017 at 10:12:36AM +0100, Peter Robinson wrote:
> On Thu, Oct 19, 2017 at 10:06 AM, Peter Robinson  wrote:
> > On Thu, Oct 19, 2017 at 10:01 AM, Maxime Ripard
> >  wrote:
> >> On Thu, Oct 19, 2017 at 09:43:20AM +0100, Peter Robinson wrote:
> >>> On Thu, Oct 19, 2017 at 9:26 AM, Maxime Ripard
> >>>  wrote:
> >>> > The EFI loader support takes around 31kB on an ARMv7 board, which makes 
> >>> > us
> >>> > trip across the size limit we've had on the U-Boot binary.
> >>> >
> >>> > Since it's not an essential feature, disable it by default for 
> >>> > ARCH_SUNXI
> >>> > so that we get back some extra room for user customisations.
> >>>
> >>> Does this disable it on aarch64 boards by default such as the Pine64?
> >>> If so NAK as Fedora, SUSE and I'm pretty sure Debian all use EFI to
> >>> boot aarch64 devices and this would regress this for all those
> >>> distros.
> >>
> >> This is something that Fedora, Suse and I'm pretty sure Debian can add
> >> to their defconfig. These are just default configuration, not
> >> one-size-fits-all configuration.
> >
> > So you're making at least three groups of users do more work? It could
> > also be argued that those that need the smaller space could disable it
> > if they don't need it in their configuration.
> 
> Ultimately the problem with the argument about disabling it by default
> and distros can enable it if they want to is a false one.

If it's a false one, then I guess Red Hat doesn't have any kind of
custom defconfigs for Fedora or RHEL for the kernel?

> By enabling it by default we have devices that ship with SPI or NAND
> flash, like a bunch of the OrangePis do now, be able to work with
> all distributions out of the box without any requirements of distros
> to produce a firmware (something I'd really prefer to leave to the
> device makers) to boot a number of Linux OSes OOTB.

That one is the false argument in the discussion. No vendor is
providing such a U-Boot, all of them provide a vendor one that will
not even be able to boot a mainline kernel, let alone supporting
EFI. So having something that works out of the box is just a pipe
dream.

> I think this is a good thing for the entire ecosystem. I don't want
> to regress that, I'd sooner get the size checks in place and then
> review rather than what seems like a "quick win"

I've added a size check. 3 boards are broken:
  - A20-OLinuXino-Lime2-eMMC
  - A20-OLinuXino-Lime2
  - Cubietruck

What now?
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Mark Kettenis]

> From: Maxime Ripard 
> Date: Thu, 19 Oct 2017 10:26:49 +0200
> 
> The EFI loader support takes around 31kB on an ARMv7 board, which makes us
> trip across the size limit we've had on the U-Boot binary.
> 
> Since it's not an essential feature, disable it by default for ARCH_SUNXI
> so that we get back some extra room for user customisations.

This is an essential feature for booting OpenBSD.  And I believe it is
a requirement for several Linux distros as well.  I don't think
disabling this by default is a good idea.

How much of that 31kB is due to recent improvements of the EFI loader
support?  I understand the desire to have a more complete EFI
implementation, but if the consequence of that is that the EFI loader
gets disabled by default on many boards I think we're throwing out the
baby with the bathwater...

> Signed-off-by: Maxime Ripard 
> ---
>  lib/efi_loader/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index d2b6327119b4..a80a914b2fe8 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -1,7 +1,7 @@
>  config EFI_LOADER
>   bool "Support running EFI Applications in U-Boot"
>   depends on (ARM || X86) && OF_LIBFDT
> - default y
> + default y if !ARCH_SUNXI
>   help
> Select this option if you want to run EFI applications (like grub2)
> on top of U-Boot. If this option is enabled, U-Boot will expose EFI
> -- 
> 2.14.2
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Jonathan Gray]

On Thu, Oct 19, 2017 at 10:51:04AM +0200, Alexander Graf wrote:
> On 10/19/2017 10:26 AM, Maxime Ripard wrote:
> > The EFI loader support takes around 31kB on an ARMv7 board, which makes us
> > trip across the size limit we've had on the U-Boot binary.
> > 
> > Since it's not an essential feature, disable it by default for ARCH_SUNXI
> > so that we get back some extra room for user customisations.
> > 
> > Signed-off-by: Maxime Ripard 
> 
> Quite the contrary - it is essential. All major distributions are going for
> distro boot + EFI at least for 64bit platforms now. Disabling it by default
> means you basically kill your user base on those.

EFI is mandatory for 32 and 64 bit OpenBSD arm.  I would not be
surprised if others made similiar choices to be able to boot off
filesystems unsupported by U-Boot and have something close to a real
firmware interface.

> 
> > ---
> >   lib/efi_loader/Kconfig | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index d2b6327119b4..a80a914b2fe8 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -1,7 +1,7 @@
> >   config EFI_LOADER
> > bool "Support running EFI Applications in U-Boot"
> > depends on (ARM || X86) && OF_LIBFDT
> > -   default y
> > +   default y if !ARCH_SUNXI
> 
> Nack on any change to that default line. If you must disable efi_loader (and
> really, I strongly advise not to do so for sunxi), please do so in the
> defconfigs, as nothing prohibits the architecture to work with it.
> 
> 
> Alex
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCH u-boot] ARM: arch-meson: build memory banks using reported memory from registers

[Ben Dooks]

On 2017-10-19 10:04, Neil Armstrong wrote:
As discussed at [1], the Amlogic Meson GX SoCs can embed a BL31 
firmware

and a secondary BL32 firmware.
Since mid-2017, the reserved memory address of the BL31 firmware was 
moved

and grown for security reasons.

But mainline U-boot and Linux has the old address and size fixed.

These SoCs have a register interface to get the two firmware reserved
memory start and sizes.

This patch adds a dynamic memory bank redistribution according to the
values in the firmware.

Note that the memory address ordering between BL31 and BL32 is not 
etablished,

so it must be determined dynamically.

[1] 
http://lists.infradead.org/pipermail/linux-amlogic/2017-October/004860.html


Signed-off-by: Neil Armstrong 
---
 arch/arm/include/asm/arch-meson/gxbb.h | 15 ++
 arch/arm/mach-meson/board.c| 99 
+++---

 include/configs/meson-gxbb-common.h|  2 +-
 3 files changed, 109 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/arch-meson/gxbb.h
b/arch/arm/include/asm/arch-meson/gxbb.h
index 74d5290..57db37e 100644
--- a/arch/arm/include/asm/arch-meson/gxbb.h
+++ b/arch/arm/include/asm/arch-meson/gxbb.h
@@ -7,10 +7,25 @@
 #ifndef __GXBB_H__
 #define __GXBB_H__

+#define GXBB_AOBUS_BASE0xc810
 #define GXBB_PERIPHS_BASE  0xc8834400
 #define GXBB_HIU_BASE  0xc883c000
 #define GXBB_ETH_BASE  0xc941

+/* Always-On Peripherals registers */
+#define GXBB_AO_ADDR(off)  (GXBB_AOBUS_BASE + ((off) << 2))
+
+#define GXBB_AO_SEC_GP_CFG0GXBB_AO_ADDR(0x90)
+#define GXBB_AO_SEC_GP_CFG3GXBB_AO_ADDR(0x93)
+#define GXBB_AO_SEC_GP_CFG4GXBB_AO_ADDR(0x94)
+#define GXBB_AO_SEC_GP_CFG5GXBB_AO_ADDR(0x95)
+
+#define GXBB_AO_MEM_SIZE_MASK  0x
+#define GXBB_AO_MEM_SIZE_SHIFT 16
+#define GXBB_AO_BL31_RSVMEM_SIZE_MASK  0x
+#define GXBB_AO_BL31_RSVMEM_SIZE_SHIFT 16
+#define GXBB_AO_BL32_RSVMEM_SIZE_MASK  0x
+
 /* Peripherals registers */
 #define GXBB_PERIPHS_ADDR(off) (GXBB_PERIPHS_BASE + ((off) << 2))

diff --git a/arch/arm/mach-meson/board.c b/arch/arm/mach-meson/board.c
index e89c6aa..bd330af 100644
--- a/arch/arm/mach-meson/board.c
+++ b/arch/arm/mach-meson/board.c
@@ -11,6 +11,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 DECLARE_GLOBAL_DATA_PTR;

@@ -34,14 +36,99 @@ int dram_init(void)
return 0;
 }

+phys_size_t get_effective_memsize(void)
+{
+   /* Size is reported in MiB, convert it in bytes */
+   return ((in_le32(GXBB_AO_SEC_GP_CFG0) & GXBB_AO_MEM_SIZE_MASK)
+   >> GXBB_AO_MEM_SIZE_SHIFT) * SZ_1M;


Is in_le32 suitable here?


+}
+
 int dram_init_banksize(void)
 {
-   /* Reserve first 16 MiB of RAM for firmware */
-   gd->bd->bi_dram[0].start = 0x100;
-   gd->bd->bi_dram[0].size  = 0xf00;
-   /* Reserve 2 MiB for ARM Trusted Firmware (BL31) */
-   gd->bd->bi_dram[1].start = 0x1000;
-   gd->bd->bi_dram[1].size  = gd->ram_size - 0x1020;
+   u32 bl31_size, bl31_start;
+   u32 bl32_size, bl32_start;
+   /* Start after first 16MiB reserved zone */
+   unsigned int next = 0;
+   u32 last = 0x100;
+   u32 reg;
+
+   /*
+* Get ARM Trusted Firmware reserved memory zones in :
+* - AO_SEC_GP_CFG3: bl32 & bl31 size in KiB, can be 0
+* - AO_SEC_GP_CFG5: bl31 physical start address, can be NULL
+* - AO_SEC_GP_CFG4: bl32 physical start address, can be NULL
+*/


Can you use bootmem reserve to do this?



+
+   reg = in_le32(GXBB_AO_SEC_GP_CFG3);
+
+   bl31_size = ((reg & GXBB_AO_BL31_RSVMEM_SIZE_MASK)
+   >> GXBB_AO_BL31_RSVMEM_SIZE_SHIFT) * SZ_1K;
+   bl32_size = (reg & GXBB_AO_BL32_RSVMEM_SIZE_MASK) * SZ_1K;
+
+   bl31_start = in_le32(GXBB_AO_SEC_GP_CFG5);
+   bl32_start = in_le32(GXBB_AO_SEC_GP_CFG4);
+
+   if (bl31_size && bl31_start && bl32_size && bl32_start) {
+   /* Reserve memory for ARM Trusted Firmware (BL31 && BL32) */
+   gd->bd->bi_dram[next].start = last;
+   if (bl31_start > bl32_start)
+   gd->bd->bi_dram[next].size = bl32_start - last;
+   else
+   gd->bd->bi_dram[next].size = bl31_start - last;
+
+   last = gd->bd->bi_dram[next].start +
+   gd->bd->bi_dram[next].size;
+
+   if (bl31_start > bl32_start)
+   last += bl32_size;
+   else
+   last += bl31_size;
+   next++;
+
+   gd->bd->bi_dram[next].start = last;
+   if (bl31_start > bl32_start)
+   gd->bd->bi_dram[next].size = bl31_start - last;
+   else
+   gd->bd->bi_dram[next].size = bl32_start - last;
+
+   last = gd->bd->bi_dram[next].start +
+   gd->bd->bi_dram[next].size;
+
+   

Re: [U-Boot] [PATCH v6] cmd: usb: ignore blk, emulation devices in usb tree/info display

[Marek Vasut]

On 10/19/2017 11:52 AM, Bin Meng wrote:
> Hi Marek,
> 
> On Thu, Oct 19, 2017 at 5:47 PM, Marek Vasut  wrote:
>> On 10/19/2017 10:56 AM, Bin Meng wrote:
>>> Hi Marek,
>>>
>>> On Thu, Oct 19, 2017 at 4:43 PM, Marek Vasut  wrote:
 On 10/19/2017 10:37 AM, Bin Meng wrote:
> Hi Marek,

 Hi,

> On Thu, Oct 19, 2017 at 3:33 PM, Marek Vasut  wrote:
>> On 10/19/2017 05:24 AM, Suneel Garapati wrote:
>>> On Wed, Oct 18, 2017 at 6:39 PM, Marek Vasut  wrote:
 On 10/19/2017 03:22 AM, Suneel Garapati wrote:
> usb tree/info commands iterate over all usb uclass devices
> recursively. blk uclass child devices are created for mass storage,
> treating these as usb uclass devices and referencing usb config
> interface descriptors cause crash. To fix, ignore blk and usb_emul
> uclass devices(sandbox)
  ^^^ what's this about ? USB_EMUL devices can be
 enables elsewhere too, right ?
>>> Only disabled during the tree/info dump.
>>
>> I don't understand this answer. Can USB_EMUL devices be enabled on any
>> other machine than sandbox or not ? I presume it can ...
>>
>
> No, it cannot.

 Why ? Because of the Kconfig thing ? That can easily change and then
 this breaks ...
>>>
>>> Yes, it's currently on on Sandbox. But whether it's on Sandbox or not
>>> does not matter. These devices are should be filtered out as they are
>>> not supposed to be on the USB topology.
>>
>> I agree with that, I was just commenting on this "(sandbox)" in the
>> description, which IMO is not precise.
>>
 Anyway, shouldn't you rather filter for positive matches (usb uclass
 devices etc) , rather than filtering out a few negative matches (blk
 etc) which might break in the future ?
>>> usb_for_each_root_dev does that but we dont have 
>>> uclass_find_first_child_device
>>> to call on UCLASS_USB like uclass_find_first_device.
>>> So, device_find_first_child and check on uclass id is performed.
>>
>> I mean, rather than doing
>> (device_get_uclass_id(child) != UCLASS_USB_xxx &&
>> device_get_uclass_id(child) != UCLASS_USB_yyy)
>>dump
>>
>> do
>>
>> (device_get_uclass_id(child) == UCLASS_USB_nnn)
>>dump
>>
>> for nnn being only the relevant USB classes for which we actually want
>> to dump.
>>
>> Does that work ?
>>
>
> No, I don't think you can enumerate all USB devices here. It can be
> any uclass device.

 And only the blk one breaks things ?
>>>
>>> Yes, blk devices are not "struct usb_device" declared, as they are not
>>> USB devices. However their parent is.
>>
>> In which case, _that_ should be in the commit message.
>>
>> Anyway, is there any chance something else will come in, ie. net device
>> for USB ethernet devices ?
>>
> 
> No problem with any USB devices that end up in the leaf node in the DM tree.

So what triggers this issue are partitions and co. then ?

> Regards,
> Bin
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] doc: verified-boot: fix crypto algorithm examples

[Masahiro Yamada]

As you see in crypto_algos in common/image-sig.c, the algorithm
should be either "rsa2048" or "rsa4096".  "rs2048" is a typo.

Signed-off-by: Masahiro Yamada 
---

 doc/uImage.FIT/signature.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt
index a57cdab..2ece4c4 100644
--- a/doc/uImage.FIT/signature.txt
+++ b/doc/uImage.FIT/signature.txt
@@ -85,7 +85,7 @@ allow the signer to operate. These should be added to the 
.its file.
 Signature nodes sit at the same level as hash nodes and are called
 signature@1, signature@2, etc.
 
-- algo: Algorithm name (e.g. "sha1,rs2048")
+- algo: Algorithm name (e.g. "sha1,rsa2048")
 
 - key-name-hint: Name of key to use for signing. The keys will normally be in
 a single directory (parameter -k to mkimage). For a given key , its
@@ -139,7 +139,7 @@ public key in U-Boot's control FDT (using 
CONFIG_OF_CONTROL).
 Public keys should be stored as sub-nodes in a /signature node. Required
 properties are:
 
-- algo: Algorithm name (e.g. "sha1,rs2048")
+- algo: Algorithm name (e.g. "sha1,rsa2048")
 
 Optional properties are:
 
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] ARM: uniphier: increase CONFIG_SYS_BOOTM_LEN to 32MB

[Masahiro Yamada]

The default value of CONFIG_SYS_BOOTM_LEN, 0x80, causes error
when uncompressing Image.gz out of fit.

   Uncompressing Kernel Image ... Error: inflate() returned -5
Image too large: increase CONFIG_SYS_BOOTM_LEN

Signed-off-by: Masahiro Yamada 
---

 include/configs/uniphier.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h
index 1d3bf98..abee461 100644
--- a/include/configs/uniphier.h
+++ b/include/configs/uniphier.h
@@ -105,6 +105,7 @@
 
 #define CONFIG_LOADADDR0x8400
 #define CONFIG_SYS_LOAD_ADDR   CONFIG_LOADADDR
+#define CONFIG_SYS_BOOTM_LEN   (32 << 20)
 
 #define CONFIG_CMDLINE_EDITING /* add command line history */
 
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] tools: image: fix node name of signature node in FIT

[Masahiro Yamada]

Both "conf_name" and "sig_name" point to the name of config node.
The latter should be the name of the signature node.

Signed-off-by: Masahiro Yamada 
---

 tools/image-host.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/image-host.c b/tools/image-host.c
index e82020b..eaa9c41 100644
--- a/tools/image-host.c
+++ b/tools/image-host.c
@@ -515,7 +515,7 @@ static int fit_config_get_data(void *fit, int conf_noffset, 
int noffset,
int ret, len;
 
conf_name = fit_get_name(fit, conf_noffset, NULL);
-   sig_name = fit_get_name(fit, conf_noffset, NULL);
+   sig_name = fit_get_name(fit, noffset, NULL);
debug("%s: conf='%s', sig='%s'\n", __func__, conf_name, sig_name);
 
/* Get a list of nodes we want to hash */
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] test/py: fix typos in README.md

[Masahiro Yamada]

Signed-off-by: Masahiro Yamada 
---

 test/py/README.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/test/py/README.md b/test/py/README.md
index ea4b66a..eefac37 100644
--- a/test/py/README.md
+++ b/test/py/README.md
@@ -11,7 +11,7 @@ results. Advantages of this approach are:
   U-Boot; there can be no disconnect.
 - There is no need to write or embed test-related code into U-Boot itself.
   It is asserted that writing test-related code in Python is simpler and more
-  flexible that writing it all in C.
+  flexible than writing it all in C.
 - It is reasonably simple to interact with U-Boot in this way.
 
 ## Requirements
@@ -183,7 +183,7 @@ The following environment variables are set when running 
hook scripts:
 - `UBOOT_TEST_PY_DIR` the full path to `test/py/` in the source directory.
 - `UBOOT_BUILD_DIR` the U-Boot build directory.
 - `UBOOT_RESULT_DIR` the test result directory.
-- `UBOOT_PERSISTENT_DATA_DIR` the test peristent data directory.
+- `UBOOT_PERSISTENT_DATA_DIR` the test persistent data directory.
 
  `u-boot-test-console`
 
@@ -222,7 +222,7 @@ the following cases:
   from there. Use of this feature will reduce wear on the board's flash, so
   may be preferable if available, and if cold boot testing of U-Boot is not
   required. If this feature is used, the `u-boot-test-reset` script should
-  peform this download, since the board could conceivably be reset multiple
+  perform this download, since the board could conceivably be reset multiple
   times in a single test run.
 
 It is up to the user to determine if those situations exist, and to code this
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v6] cmd: usb: ignore blk, emulation devices in usb tree/info display

[Bin Meng]

Hi Marek,

On Thu, Oct 19, 2017 at 5:47 PM, Marek Vasut  wrote:
> On 10/19/2017 10:56 AM, Bin Meng wrote:
>> Hi Marek,
>>
>> On Thu, Oct 19, 2017 at 4:43 PM, Marek Vasut  wrote:
>>> On 10/19/2017 10:37 AM, Bin Meng wrote:
 Hi Marek,
>>>
>>> Hi,
>>>
 On Thu, Oct 19, 2017 at 3:33 PM, Marek Vasut  wrote:
> On 10/19/2017 05:24 AM, Suneel Garapati wrote:
>> On Wed, Oct 18, 2017 at 6:39 PM, Marek Vasut  wrote:
>>> On 10/19/2017 03:22 AM, Suneel Garapati wrote:
 usb tree/info commands iterate over all usb uclass devices
 recursively. blk uclass child devices are created for mass storage,
 treating these as usb uclass devices and referencing usb config
 interface descriptors cause crash. To fix, ignore blk and usb_emul
 uclass devices(sandbox)
>>>  ^^^ what's this about ? USB_EMUL devices can be
>>> enables elsewhere too, right ?
>> Only disabled during the tree/info dump.
>
> I don't understand this answer. Can USB_EMUL devices be enabled on any
> other machine than sandbox or not ? I presume it can ...
>

 No, it cannot.
>>>
>>> Why ? Because of the Kconfig thing ? That can easily change and then
>>> this breaks ...
>>
>> Yes, it's currently on on Sandbox. But whether it's on Sandbox or not
>> does not matter. These devices are should be filtered out as they are
>> not supposed to be on the USB topology.
>
> I agree with that, I was just commenting on this "(sandbox)" in the
> description, which IMO is not precise.
>
>>> Anyway, shouldn't you rather filter for positive matches (usb uclass
>>> devices etc) , rather than filtering out a few negative matches (blk
>>> etc) which might break in the future ?
>> usb_for_each_root_dev does that but we dont have 
>> uclass_find_first_child_device
>> to call on UCLASS_USB like uclass_find_first_device.
>> So, device_find_first_child and check on uclass id is performed.
>
> I mean, rather than doing
> (device_get_uclass_id(child) != UCLASS_USB_xxx &&
> device_get_uclass_id(child) != UCLASS_USB_yyy)
>dump
>
> do
>
> (device_get_uclass_id(child) == UCLASS_USB_nnn)
>dump
>
> for nnn being only the relevant USB classes for which we actually want
> to dump.
>
> Does that work ?
>

 No, I don't think you can enumerate all USB devices here. It can be
 any uclass device.
>>>
>>> And only the blk one breaks things ?
>>
>> Yes, blk devices are not "struct usb_device" declared, as they are not
>> USB devices. However their parent is.
>
> In which case, _that_ should be in the commit message.
>
> Anyway, is there any chance something else will come in, ie. net device
> for USB ethernet devices ?
>

No problem with any USB devices that end up in the leaf node in the DM tree.

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v6] cmd: usb: ignore blk, emulation devices in usb tree/info display

[Marek Vasut]

On 10/19/2017 10:56 AM, Bin Meng wrote:
> Hi Marek,
> 
> On Thu, Oct 19, 2017 at 4:43 PM, Marek Vasut  wrote:
>> On 10/19/2017 10:37 AM, Bin Meng wrote:
>>> Hi Marek,
>>
>> Hi,
>>
>>> On Thu, Oct 19, 2017 at 3:33 PM, Marek Vasut  wrote:
 On 10/19/2017 05:24 AM, Suneel Garapati wrote:
> On Wed, Oct 18, 2017 at 6:39 PM, Marek Vasut  wrote:
>> On 10/19/2017 03:22 AM, Suneel Garapati wrote:
>>> usb tree/info commands iterate over all usb uclass devices
>>> recursively. blk uclass child devices are created for mass storage,
>>> treating these as usb uclass devices and referencing usb config
>>> interface descriptors cause crash. To fix, ignore blk and usb_emul
>>> uclass devices(sandbox)
>>  ^^^ what's this about ? USB_EMUL devices can be
>> enables elsewhere too, right ?
> Only disabled during the tree/info dump.

 I don't understand this answer. Can USB_EMUL devices be enabled on any
 other machine than sandbox or not ? I presume it can ...

>>>
>>> No, it cannot.
>>
>> Why ? Because of the Kconfig thing ? That can easily change and then
>> this breaks ...
> 
> Yes, it's currently on on Sandbox. But whether it's on Sandbox or not
> does not matter. These devices are should be filtered out as they are
> not supposed to be on the USB topology.

I agree with that, I was just commenting on this "(sandbox)" in the
description, which IMO is not precise.

>> Anyway, shouldn't you rather filter for positive matches (usb uclass
>> devices etc) , rather than filtering out a few negative matches (blk
>> etc) which might break in the future ?
> usb_for_each_root_dev does that but we dont have 
> uclass_find_first_child_device
> to call on UCLASS_USB like uclass_find_first_device.
> So, device_find_first_child and check on uclass id is performed.

 I mean, rather than doing
 (device_get_uclass_id(child) != UCLASS_USB_xxx &&
 device_get_uclass_id(child) != UCLASS_USB_yyy)
dump

 do

 (device_get_uclass_id(child) == UCLASS_USB_nnn)
dump

 for nnn being only the relevant USB classes for which we actually want
 to dump.

 Does that work ?

>>>
>>> No, I don't think you can enumerate all USB devices here. It can be
>>> any uclass device.
>>
>> And only the blk one breaks things ?
> 
> Yes, blk devices are not "struct usb_device" declared, as they are not
> USB devices. However their parent is.

In which case, _that_ should be in the commit message.

Anyway, is there any chance something else will come in, ie. net device
for USB ethernet devices ?

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Maxime Ripard]

On Thu, Oct 19, 2017 at 10:06:15AM +0100, Peter Robinson wrote:
> On Thu, Oct 19, 2017 at 10:01 AM, Maxime Ripard
>  wrote:
> > On Thu, Oct 19, 2017 at 09:43:20AM +0100, Peter Robinson wrote:
> >> On Thu, Oct 19, 2017 at 9:26 AM, Maxime Ripard
> >>  wrote:
> >> > The EFI loader support takes around 31kB on an ARMv7 board, which makes 
> >> > us
> >> > trip across the size limit we've had on the U-Boot binary.
> >> >
> >> > Since it's not an essential feature, disable it by default for ARCH_SUNXI
> >> > so that we get back some extra room for user customisations.
> >>
> >> Does this disable it on aarch64 boards by default such as the Pine64?
> >> If so NAK as Fedora, SUSE and I'm pretty sure Debian all use EFI to
> >> boot aarch64 devices and this would regress this for all those
> >> distros.
> >
> > This is something that Fedora, Suse and I'm pretty sure Debian can add
> > to their defconfig. These are just default configuration, not
> > one-size-fits-all configuration.
> 
> So you're making at least three groups of users do more work? It could
> also be argued that those that need the smaller space could disable it
> if they don't need it in their configuration.

I don't think asking people to modify their default configuration in
order to have U-Boot booting is reasonable, is it?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Peter Robinson]

On Thu, Oct 19, 2017 at 10:06 AM, Peter Robinson  wrote:
> On Thu, Oct 19, 2017 at 10:01 AM, Maxime Ripard
>  wrote:
>> On Thu, Oct 19, 2017 at 09:43:20AM +0100, Peter Robinson wrote:
>>> On Thu, Oct 19, 2017 at 9:26 AM, Maxime Ripard
>>>  wrote:
>>> > The EFI loader support takes around 31kB on an ARMv7 board, which makes us
>>> > trip across the size limit we've had on the U-Boot binary.
>>> >
>>> > Since it's not an essential feature, disable it by default for ARCH_SUNXI
>>> > so that we get back some extra room for user customisations.
>>>
>>> Does this disable it on aarch64 boards by default such as the Pine64?
>>> If so NAK as Fedora, SUSE and I'm pretty sure Debian all use EFI to
>>> boot aarch64 devices and this would regress this for all those
>>> distros.
>>
>> This is something that Fedora, Suse and I'm pretty sure Debian can add
>> to their defconfig. These are just default configuration, not
>> one-size-fits-all configuration.
>
> So you're making at least three groups of users do more work? It could
> also be argued that those that need the smaller space could disable it
> if they don't need it in their configuration.

Ultimately the problem with the argument about disabling it by default
and distros can enable it if they want to is a false one. By enabling
it by default we have devices that ship with SPI  or NAND flash, like
a bunch of the OrangePis do now, be able to work with all
distributions out of the box without any requirements of distros to
produce a firmware (something I'd really prefer to leave to the device
makers) to boot a number of Linux OSes OOTB. I think this is a good
thing for the entire ecosystem. I don't want to regress that, I'd
sooner get the size checks in place and then review rather than what
seems like a "quick win"
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Maxime Ripard]

On Thu, Oct 19, 2017 at 10:44:54AM +0200, Alexander Graf wrote:
> On 10/19/2017 10:26 AM, Maxime Ripard wrote:
> > Hi,
> > 
> > Most featureful boards, such as the Cubietruck, have been broken since
> > the release 2017.09.
> > 
> > This is due to a size increase of the binary that will trip us across
> > the size we've been using in the u-boot-sunxi-with-spl.bin file.
> > 
> > We would have two ways to work around it. The first one would be to
> > just increase the offset of the environment. However, since it would
> > break all the environments of our users and possibly the custom
> > partition scheme that they would have created, it doesn't really seem
> > like a smart move.
> > 
> > Another one would be to start trimming down a bit our enabled options
> > in order to reduce the size and to gain some extra space for users
> > customisations. I've taken care some of the low hanging fruits, and we
> > should probably take another go at it in the future (and add a size
> > check in the image build somehow?)
> 
> How about we add the size check first before crippling the feature
> set of sunxi boards? Then maybe rather disable lesser used features
> than efi_loader?

All the features have some users. All the kind of arguments that have
been sent so far are that "but I use this feature". Yes. You probably
do. But you can have the same kind of argument for any of the features
enabled.

Let's look at the features enabled by a Cubietruck defconfig:
  - GMAC: I'm pretty sure there's some people using network out there,
and you don't want to break those.
  - AHCI: I'm pretty sure there's some people using their SATA disk
out there, and you don't want to break those.
  - PSCI: I'm pretty sure there's some people using multiple CPUs out
there, and you don't want to break those.
  - Fastboot: I'm pretty sure there's some people reflashing their
systems out there, and you don't want to break those.
  - DFU: I'm pretty sure there's some people reflashing their systems
out there and that don't like fastboot, and you don't want to
break those.
  - MMC: I'm pretty sure there's some people using their MMC card
out there, and you don't want to break those.
  - USB: I'm pretty sure there's some people using their USB devices
out there, and you don't want to break those.

tl; dr: using that kind of argument, nothing is removed, and we keep
building non-functional (as in, non-booting) binaries. Is that
*really* what you're suggesting?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] ARM: sunxi: Disable USB host options by default

[Andre Przywara]

Hi,

On 19/10/17 09:48, Alexander Graf wrote:
> On 10/19/2017 10:26 AM, Maxime Ripard wrote:
>> The USB keyboard and USB storage support are non-essential from an
>> architecture-wide sense.
>>
>> Remove the selection so that we can trim down the size of our binaries a
>> bit.
>>
>> Signed-off-by: Maxime Ripard 
> 
> Most users out there that I'm aware of use U-Boot without serial port
> attached. Disabling USB keyboard support means they can no longer
> interact with their firmware. That's a terrible thing to do.

Also USB storage is the canonical way of installing distributions, by
using an USB flash drive with a generic (UEFI) installer on it.

And I second the concerns about removal of UEFI support and USB
keyboard. Especially UEFI is a real deal breaker for ARM64 boards.

So while I see that this series fixes a particular problem, I am a bit
wary of this solution, as this just papers over the issue and will
likely break in the future again.

Can't we somehow fix the environment problem? Possibly via the upgrade
process (save the environment, update U-Boot, re-install the
environment)? Or some other clever way? That would be more future proof,
I believe.

Cheers,
Andre.


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Siarhei Siamashka]

On Thu, Oct 19, 2017 at 11:26 AM, Maxime Ripard
 wrote:
> Hi,
>
> Most featureful boards, such as the Cubietruck, have been broken since
> the release 2017.09.
>
> This is due to a size increase of the binary that will trip us across
> the size we've been using in the u-boot-sunxi-with-spl.bin file.
>
> We would have two ways to work around it. The first one would be to
> just increase the offset of the environment. However, since it would
> break all the environments of our users and possibly the custom
> partition scheme that they would have created, it doesn't really seem
> like a smart move.
>
> Another one would be to start trimming down a bit our enabled options
> in order to reduce the size and to gain some extra space for users
> customisations. I've taken care some of the low hanging fruits, and we
> should probably take another go at it in the future (and add a size
> check in the image build somehow?)
>
> Maxime
>
> Maxime Ripard (3):
>   ARM: sunxi: Disable USB host options by default
>   ARM: sunxi: Disable FAT write by default
>   efi_loader: Do not enable it by default for sunxi
>
>  arch/arm/Kconfig   | 4 
>  lib/efi_loader/Kconfig | 2 +-
>  2 files changed, 1 insertion(+), 5 deletions(-)

We can first enable Thumb2 build by default for 32-bit sunxi boards
and this should fix Cubietruck problems.

$ cat .config | grep THUMB
CONFIG_HAS_THUMB2=y
# CONFIG_SYS_THUMB_BUILD is not set
CONFIG_SPL_SYS_THUMB_BUILD=y

As a test, enabling CONFIG_SYS_THUMB_BUILD=y in Cubietruck_defconfig
reduces the size of the resulting U-Boot binary.

== Before: ==

$ arm-linux-gnueabihf-size u-boot
   text   databssdechexfilename
 489398  26492 249240 765130  baccau-boot.orig

== After: ==

$ arm-linux-gnueabihf-size u-boot
   text   databssdechexfilename
 366314  26492 249232 642038  9cbf6u-boot

-- 
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Peter Robinson]

On Thu, Oct 19, 2017 at 10:01 AM, Maxime Ripard
 wrote:
> On Thu, Oct 19, 2017 at 09:43:20AM +0100, Peter Robinson wrote:
>> On Thu, Oct 19, 2017 at 9:26 AM, Maxime Ripard
>>  wrote:
>> > The EFI loader support takes around 31kB on an ARMv7 board, which makes us
>> > trip across the size limit we've had on the U-Boot binary.
>> >
>> > Since it's not an essential feature, disable it by default for ARCH_SUNXI
>> > so that we get back some extra room for user customisations.
>>
>> Does this disable it on aarch64 boards by default such as the Pine64?
>> If so NAK as Fedora, SUSE and I'm pretty sure Debian all use EFI to
>> boot aarch64 devices and this would regress this for all those
>> distros.
>
> This is something that Fedora, Suse and I'm pretty sure Debian can add
> to their defconfig. These are just default configuration, not
> one-size-fits-all configuration.

So you're making at least three groups of users do more work? It could
also be argued that those that need the smaller space could disable it
if they don't need it in their configuration.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [RFC PATCH u-boot] ARM: arch-meson: build memory banks using reported memory from registers

[Neil Armstrong]

As discussed at [1], the Amlogic Meson GX SoCs can embed a BL31 firmware
and a secondary BL32 firmware.
Since mid-2017, the reserved memory address of the BL31 firmware was moved
and grown for security reasons.

But mainline U-boot and Linux has the old address and size fixed.

These SoCs have a register interface to get the two firmware reserved
memory start and sizes.

This patch adds a dynamic memory bank redistribution according to the
values in the firmware.

Note that the memory address ordering between BL31 and BL32 is not etablished,
so it must be determined dynamically.

[1] http://lists.infradead.org/pipermail/linux-amlogic/2017-October/004860.html

Signed-off-by: Neil Armstrong 
---
 arch/arm/include/asm/arch-meson/gxbb.h | 15 ++
 arch/arm/mach-meson/board.c| 99 +++---
 include/configs/meson-gxbb-common.h|  2 +-
 3 files changed, 109 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/arch-meson/gxbb.h 
b/arch/arm/include/asm/arch-meson/gxbb.h
index 74d5290..57db37e 100644
--- a/arch/arm/include/asm/arch-meson/gxbb.h
+++ b/arch/arm/include/asm/arch-meson/gxbb.h
@@ -7,10 +7,25 @@
 #ifndef __GXBB_H__
 #define __GXBB_H__
 
+#define GXBB_AOBUS_BASE0xc810
 #define GXBB_PERIPHS_BASE  0xc8834400
 #define GXBB_HIU_BASE  0xc883c000
 #define GXBB_ETH_BASE  0xc941
 
+/* Always-On Peripherals registers */
+#define GXBB_AO_ADDR(off)  (GXBB_AOBUS_BASE + ((off) << 2))
+
+#define GXBB_AO_SEC_GP_CFG0GXBB_AO_ADDR(0x90)
+#define GXBB_AO_SEC_GP_CFG3GXBB_AO_ADDR(0x93)
+#define GXBB_AO_SEC_GP_CFG4GXBB_AO_ADDR(0x94)
+#define GXBB_AO_SEC_GP_CFG5GXBB_AO_ADDR(0x95)
+
+#define GXBB_AO_MEM_SIZE_MASK  0x
+#define GXBB_AO_MEM_SIZE_SHIFT 16
+#define GXBB_AO_BL31_RSVMEM_SIZE_MASK  0x
+#define GXBB_AO_BL31_RSVMEM_SIZE_SHIFT 16
+#define GXBB_AO_BL32_RSVMEM_SIZE_MASK  0x
+
 /* Peripherals registers */
 #define GXBB_PERIPHS_ADDR(off) (GXBB_PERIPHS_BASE + ((off) << 2))
 
diff --git a/arch/arm/mach-meson/board.c b/arch/arm/mach-meson/board.c
index e89c6aa..bd330af 100644
--- a/arch/arm/mach-meson/board.c
+++ b/arch/arm/mach-meson/board.c
@@ -11,6 +11,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -34,14 +36,99 @@ int dram_init(void)
return 0;
 }
 
+phys_size_t get_effective_memsize(void)
+{
+   /* Size is reported in MiB, convert it in bytes */
+   return ((in_le32(GXBB_AO_SEC_GP_CFG0) & GXBB_AO_MEM_SIZE_MASK)
+   >> GXBB_AO_MEM_SIZE_SHIFT) * SZ_1M;
+}
+
 int dram_init_banksize(void)
 {
-   /* Reserve first 16 MiB of RAM for firmware */
-   gd->bd->bi_dram[0].start = 0x100;
-   gd->bd->bi_dram[0].size  = 0xf00;
-   /* Reserve 2 MiB for ARM Trusted Firmware (BL31) */
-   gd->bd->bi_dram[1].start = 0x1000;
-   gd->bd->bi_dram[1].size  = gd->ram_size - 0x1020;
+   u32 bl31_size, bl31_start;
+   u32 bl32_size, bl32_start;
+   /* Start after first 16MiB reserved zone */
+   unsigned int next = 0;
+   u32 last = 0x100;
+   u32 reg;
+
+   /*
+* Get ARM Trusted Firmware reserved memory zones in :
+* - AO_SEC_GP_CFG3: bl32 & bl31 size in KiB, can be 0
+* - AO_SEC_GP_CFG5: bl31 physical start address, can be NULL
+* - AO_SEC_GP_CFG4: bl32 physical start address, can be NULL
+*/
+
+   reg = in_le32(GXBB_AO_SEC_GP_CFG3);
+
+   bl31_size = ((reg & GXBB_AO_BL31_RSVMEM_SIZE_MASK)
+   >> GXBB_AO_BL31_RSVMEM_SIZE_SHIFT) * SZ_1K;
+   bl32_size = (reg & GXBB_AO_BL32_RSVMEM_SIZE_MASK) * SZ_1K;
+
+   bl31_start = in_le32(GXBB_AO_SEC_GP_CFG5);
+   bl32_start = in_le32(GXBB_AO_SEC_GP_CFG4);
+
+   if (bl31_size && bl31_start && bl32_size && bl32_start) {
+   /* Reserve memory for ARM Trusted Firmware (BL31 && BL32) */
+   gd->bd->bi_dram[next].start = last;
+   if (bl31_start > bl32_start)
+   gd->bd->bi_dram[next].size = bl32_start - last;
+   else
+   gd->bd->bi_dram[next].size = bl31_start - last;
+
+   last = gd->bd->bi_dram[next].start +
+   gd->bd->bi_dram[next].size;
+
+   if (bl31_start > bl32_start)
+   last += bl32_size;
+   else
+   last += bl31_size;
+   next++;
+
+   gd->bd->bi_dram[next].start = last;
+   if (bl31_start > bl32_start)
+   gd->bd->bi_dram[next].size = bl31_start - last;
+   else
+   gd->bd->bi_dram[next].size = bl32_start - last;
+
+   last = gd->bd->bi_dram[next].start +
+   gd->bd->bi_dram[next].size;
+
+   if (bl31_start > bl32_start)
+   last += bl31_size;
+   else
+

Re: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Maxime Ripard]

On Thu, Oct 19, 2017 at 09:43:20AM +0100, Peter Robinson wrote:
> On Thu, Oct 19, 2017 at 9:26 AM, Maxime Ripard
>  wrote:
> > The EFI loader support takes around 31kB on an ARMv7 board, which makes us
> > trip across the size limit we've had on the U-Boot binary.
> >
> > Since it's not an essential feature, disable it by default for ARCH_SUNXI
> > so that we get back some extra room for user customisations.
> 
> Does this disable it on aarch64 boards by default such as the Pine64?
> If so NAK as Fedora, SUSE and I'm pretty sure Debian all use EFI to
> boot aarch64 devices and this would regress this for all those
> distros.

This is something that Fedora, Suse and I'm pretty sure Debian can add
to their defconfig. These are just default configuration, not
one-size-fits-all configuration.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v6] cmd: usb: ignore blk, emulation devices in usb tree/info display

[Bin Meng]

Hi Marek,

On Thu, Oct 19, 2017 at 4:43 PM, Marek Vasut  wrote:
> On 10/19/2017 10:37 AM, Bin Meng wrote:
>> Hi Marek,
>
> Hi,
>
>> On Thu, Oct 19, 2017 at 3:33 PM, Marek Vasut  wrote:
>>> On 10/19/2017 05:24 AM, Suneel Garapati wrote:
 On Wed, Oct 18, 2017 at 6:39 PM, Marek Vasut  wrote:
> On 10/19/2017 03:22 AM, Suneel Garapati wrote:
>> usb tree/info commands iterate over all usb uclass devices
>> recursively. blk uclass child devices are created for mass storage,
>> treating these as usb uclass devices and referencing usb config
>> interface descriptors cause crash. To fix, ignore blk and usb_emul
>> uclass devices(sandbox)
>  ^^^ what's this about ? USB_EMUL devices can be
> enables elsewhere too, right ?
 Only disabled during the tree/info dump.
>>>
>>> I don't understand this answer. Can USB_EMUL devices be enabled on any
>>> other machine than sandbox or not ? I presume it can ...
>>>
>>
>> No, it cannot.
>
> Why ? Because of the Kconfig thing ? That can easily change and then
> this breaks ...

Yes, it's currently on on Sandbox. But whether it's on Sandbox or not
does not matter. These devices are should be filtered out as they are
not supposed to be on the USB topology.

>
> Anyway, shouldn't you rather filter for positive matches (usb uclass
> devices etc) , rather than filtering out a few negative matches (blk
> etc) which might break in the future ?
 usb_for_each_root_dev does that but we dont have 
 uclass_find_first_child_device
 to call on UCLASS_USB like uclass_find_first_device.
 So, device_find_first_child and check on uclass id is performed.
>>>
>>> I mean, rather than doing
>>> (device_get_uclass_id(child) != UCLASS_USB_xxx &&
>>> device_get_uclass_id(child) != UCLASS_USB_yyy)
>>>dump
>>>
>>> do
>>>
>>> (device_get_uclass_id(child) == UCLASS_USB_nnn)
>>>dump
>>>
>>> for nnn being only the relevant USB classes for which we actually want
>>> to dump.
>>>
>>> Does that work ?
>>>
>>
>> No, I don't think you can enumerate all USB devices here. It can be
>> any uclass device.
>
> And only the blk one breaks things ?

Yes, blk devices are not "struct usb_device" declared, as they are not
USB devices. However their parent is.

>
>> in usb_show_info and usb_tree_graph.
>> also avoid addition of preamble for blk uclass child devices,
>> otherwise tree dump gets messed up.
>
> Also, sentences start with capital letter. This should be in a separate
> patch if it's a separate change ...
 Ignoring preamble and device should go together, hence cannot be
 separate change.


Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] ARM: sunxi: Disable USB host options by default

[Peter Robinson]

On Thu, Oct 19, 2017 at 9:26 AM, Maxime Ripard
 wrote:
> The USB keyboard and USB storage support are non-essential from an
> architecture-wide sense.

A lot of Fedora users boot from USB HDDs by having a small (say an old
128Mb mSD card from a phone) SD card and then boot the OS from the
disk so this will break all of those, plus if they don't have a serial
console it means they can't do things like debug or select an older
kernel to boot if there was an issue.

> Remove the selection so that we can trim down the size of our binaries a
> bit.
>
> Signed-off-by: Maxime Ripard 
> ---
>  arch/arm/Kconfig | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 64e0ee43f112..0eaf54bd8ddb 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -688,7 +688,6 @@ config ARCH_SUNXI
> select DM
> select DM_ETH
> select DM_GPIO
> -   select DM_KEYBOARD
> select DM_SERIAL
> select DM_USB if DISTRO_DEFAULTS
> select OF_BOARD_SETUP
> @@ -699,8 +698,6 @@ config ARCH_SUNXI
> select SYS_NS16550
> select SPL_SYS_THUMB_BUILD if !ARM64
> select USB if DISTRO_DEFAULTS
> -   select USB_STORAGE if DISTRO_DEFAULTS
> -   select USB_KEYBOARD if DISTRO_DEFAULTS
> select USE_TINY_PRINTF
> imply CMD_GPT
> imply FAT_WRITE
> --
> 2.14.2
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Alexander Graf]

On 10/19/2017 10:26 AM, Maxime Ripard wrote:

The EFI loader support takes around 31kB on an ARMv7 board, which makes us
trip across the size limit we've had on the U-Boot binary.

Since it's not an essential feature, disable it by default for ARCH_SUNXI
so that we get back some extra room for user customisations.

Signed-off-by: Maxime Ripard 


Quite the contrary - it is essential. All major distributions are going 
for distro boot + EFI at least for 64bit platforms now. Disabling it by 
default means you basically kill your user base on those.



---
  lib/efi_loader/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index d2b6327119b4..a80a914b2fe8 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -1,7 +1,7 @@
  config EFI_LOADER
bool "Support running EFI Applications in U-Boot"
depends on (ARM || X86) && OF_LIBFDT
-   default y
+   default y if !ARCH_SUNXI


Nack on any change to that default line. If you must disable efi_loader 
(and really, I strongly advise not to do so for sunxi), please do so in 
the defconfigs, as nothing prohibits the architecture to work with it.



Alex

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] ARM: sunxi: Disable USB host options by default

[Alexander Graf]

On 10/19/2017 10:26 AM, Maxime Ripard wrote:

The USB keyboard and USB storage support are non-essential from an
architecture-wide sense.

Remove the selection so that we can trim down the size of our binaries a
bit.

Signed-off-by: Maxime Ripard 


Most users out there that I'm aware of use U-Boot without serial port 
attached. Disabling USB keyboard support means they can no longer 
interact with their firmware. That's a terrible thing to do.



Alex

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Alexander Graf]

On 10/19/2017 10:26 AM, Maxime Ripard wrote:

Hi,

Most featureful boards, such as the Cubietruck, have been broken since
the release 2017.09.

This is due to a size increase of the binary that will trip us across
the size we've been using in the u-boot-sunxi-with-spl.bin file.

We would have two ways to work around it. The first one would be to
just increase the offset of the environment. However, since it would
break all the environments of our users and possibly the custom
partition scheme that they would have created, it doesn't really seem
like a smart move.

Another one would be to start trimming down a bit our enabled options
in order to reduce the size and to gain some extra space for users
customisations. I've taken care some of the low hanging fruits, and we
should probably take another go at it in the future (and add a size
check in the image build somehow?)


How about we add the size check first before crippling the feature set 
of sunxi boards? Then maybe rather disable lesser used features than 
efi_loader?



Alex

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Peter Robinson]

On Thu, Oct 19, 2017 at 9:26 AM, Maxime Ripard
 wrote:
> The EFI loader support takes around 31kB on an ARMv7 board, which makes us
> trip across the size limit we've had on the U-Boot binary.
>
> Since it's not an essential feature, disable it by default for ARCH_SUNXI
> so that we get back some extra room for user customisations.

Does this disable it on aarch64 boards by default such as the Pine64?
If so NAK as Fedora, SUSE and I'm pretty sure Debian all use EFI to
boot aarch64 devices and this would regress this for all those
distros.

Peter

> Signed-off-by: Maxime Ripard 
> ---
>  lib/efi_loader/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index d2b6327119b4..a80a914b2fe8 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -1,7 +1,7 @@
>  config EFI_LOADER
> bool "Support running EFI Applications in U-Boot"
> depends on (ARM || X86) && OF_LIBFDT
> -   default y
> +   default y if !ARCH_SUNXI
> help
>   Select this option if you want to run EFI applications (like grub2)
>   on top of U-Boot. If this option is enabled, U-Boot will expose EFI
> --
> 2.14.2
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v6] cmd: usb: ignore blk, emulation devices in usb tree/info display

[Marek Vasut]

On 10/19/2017 10:37 AM, Bin Meng wrote:
> Hi Marek,

Hi,

> On Thu, Oct 19, 2017 at 3:33 PM, Marek Vasut  wrote:
>> On 10/19/2017 05:24 AM, Suneel Garapati wrote:
>>> On Wed, Oct 18, 2017 at 6:39 PM, Marek Vasut  wrote:
 On 10/19/2017 03:22 AM, Suneel Garapati wrote:
> usb tree/info commands iterate over all usb uclass devices
> recursively. blk uclass child devices are created for mass storage,
> treating these as usb uclass devices and referencing usb config
> interface descriptors cause crash. To fix, ignore blk and usb_emul
> uclass devices(sandbox)
  ^^^ what's this about ? USB_EMUL devices can be
 enables elsewhere too, right ?
>>> Only disabled during the tree/info dump.
>>
>> I don't understand this answer. Can USB_EMUL devices be enabled on any
>> other machine than sandbox or not ? I presume it can ...
>>
> 
> No, it cannot.

Why ? Because of the Kconfig thing ? That can easily change and then
this breaks ...

 Anyway, shouldn't you rather filter for positive matches (usb uclass
 devices etc) , rather than filtering out a few negative matches (blk
 etc) which might break in the future ?
>>> usb_for_each_root_dev does that but we dont have 
>>> uclass_find_first_child_device
>>> to call on UCLASS_USB like uclass_find_first_device.
>>> So, device_find_first_child and check on uclass id is performed.
>>
>> I mean, rather than doing
>> (device_get_uclass_id(child) != UCLASS_USB_xxx &&
>> device_get_uclass_id(child) != UCLASS_USB_yyy)
>>dump
>>
>> do
>>
>> (device_get_uclass_id(child) == UCLASS_USB_nnn)
>>dump
>>
>> for nnn being only the relevant USB classes for which we actually want
>> to dump.
>>
>> Does that work ?
>>
> 
> No, I don't think you can enumerate all USB devices here. It can be
> any uclass device.

And only the blk one breaks things ?

> in usb_show_info and usb_tree_graph.
> also avoid addition of preamble for blk uclass child devices,
> otherwise tree dump gets messed up.

 Also, sentences start with capital letter. This should be in a separate
 patch if it's a separate change ...
>>> Ignoring preamble and device should go together, hence cannot be
>>> separate change.
>>>
> 
> [snip]
> 
> Regards,
> Bin
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v6] cmd: usb: ignore blk, emulation devices in usb tree/info display

[Bin Meng]

Hi Marek,

On Thu, Oct 19, 2017 at 3:33 PM, Marek Vasut  wrote:
> On 10/19/2017 05:24 AM, Suneel Garapati wrote:
>> On Wed, Oct 18, 2017 at 6:39 PM, Marek Vasut  wrote:
>>> On 10/19/2017 03:22 AM, Suneel Garapati wrote:
 usb tree/info commands iterate over all usb uclass devices
 recursively. blk uclass child devices are created for mass storage,
 treating these as usb uclass devices and referencing usb config
 interface descriptors cause crash. To fix, ignore blk and usb_emul
 uclass devices(sandbox)
>>>  ^^^ what's this about ? USB_EMUL devices can be
>>> enables elsewhere too, right ?
>> Only disabled during the tree/info dump.
>
> I don't understand this answer. Can USB_EMUL devices be enabled on any
> other machine than sandbox or not ? I presume it can ...
>

No, it cannot.

>>> Anyway, shouldn't you rather filter for positive matches (usb uclass
>>> devices etc) , rather than filtering out a few negative matches (blk
>>> etc) which might break in the future ?
>> usb_for_each_root_dev does that but we dont have 
>> uclass_find_first_child_device
>> to call on UCLASS_USB like uclass_find_first_device.
>> So, device_find_first_child and check on uclass id is performed.
>
> I mean, rather than doing
> (device_get_uclass_id(child) != UCLASS_USB_xxx &&
> device_get_uclass_id(child) != UCLASS_USB_yyy)
>dump
>
> do
>
> (device_get_uclass_id(child) == UCLASS_USB_nnn)
>dump
>
> for nnn being only the relevant USB classes for which we actually want
> to dump.
>
> Does that work ?
>

No, I don't think you can enumerate all USB devices here. It can be
any uclass device.

 in usb_show_info and usb_tree_graph.
 also avoid addition of preamble for blk uclass child devices,
 otherwise tree dump gets messed up.
>>>
>>> Also, sentences start with capital letter. This should be in a separate
>>> patch if it's a separate change ...
>> Ignoring preamble and device should go together, hence cannot be
>> separate change.
>>

[snip]

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] sunxi: Add support for the Banana Pi M2-Magic

[Maxime Ripard]

The Banana Pi M2-Magic is a small board with an Allwinner A33, an eMMC, a
wifi chip and some pin headers. Enable support for it.

Signed-off-by: Maxime Ripard 
---
 arch/arm/dts/Makefile   |   1 +
 arch/arm/dts/sun8i-r16-bananapi-m2m.dts | 321 
 configs/Bananapi_m2m_defconfig  |  21 +++
 3 files changed, 343 insertions(+)
 create mode 100644 arch/arm/dts/sun8i-r16-bananapi-m2m.dts
 create mode 100644 configs/Bananapi_m2m_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 5b90280468c2..6db64f91016c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -309,6 +309,7 @@ dtb-$(CONFIG_MACH_SUN8I_A33) += \
sun8i-a33-olinuxino.dtb \
sun8i-a33-q8-tablet.dtb \
sun8i-a33-sinlinx-sina33.dtb \
+   sun8i-r16-bananapi-m2m.dtb \
sun8i-r16-nintendo-nes-classic-edition.dtb \
sun8i-r16-parrot.dtb
 dtb-$(CONFIG_MACH_SUN8I_A83T) += \
diff --git a/arch/arm/dts/sun8i-r16-bananapi-m2m.dts 
b/arch/arm/dts/sun8i-r16-bananapi-m2m.dts
new file mode 100644
index ..eaf09666720d
--- /dev/null
+++ b/arch/arm/dts/sun8i-r16-bananapi-m2m.dts
@@ -0,0 +1,321 @@
+/*
+ * Copyright (c) 2017 Free Electrons 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-a33.dtsi"
+
+#include 
+
+/ {
+   model = "BananaPi M2 Magic";
+   compatible = "sinovoip,bananapi-m2m", "allwinner,sun8i-a33";
+
+   aliases {
+   i2c0 = 
+   i2c1 = 
+   i2c2 = 
+   serial0 = 
+   serial1 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   blue {
+   label = "bpi-m2m:blue:usr";
+   gpios = < 2 7 GPIO_ACTIVE_LOW>;
+   };
+
+   green {
+   label = "bpi-m2m:green:usr";
+   gpios = <_pio 0 2 GPIO_ACTIVE_LOW>;
+   };
+
+   red {
+   label = "bpi-m2m:red:power";
+   gpios = <_pio 0 3 GPIO_ACTIVE_LOW>;
+   default-state = "on";
+   };
+   };
+
+   reg_vcc5v0: vcc5v0 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+
+   wifi_pwrseq: wifi_pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   reset-gpios = <_pio 0 6 GPIO_ACTIVE_LOW>; /* PL06 */
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   cpu-supply = <_dcdc3>;
+};
+
+_opp_table {
+   opp@110400 {
+   opp-hz = /bits/ 64 <110400>;
+   opp-microvolt = <132>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+
+   opp@12 {
+   

[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Maxime Ripard]

The EFI loader support takes around 31kB on an ARMv7 board, which makes us
trip across the size limit we've had on the U-Boot binary.

Since it's not an essential feature, disable it by default for ARCH_SUNXI
so that we get back some extra room for user customisations.

Signed-off-by: Maxime Ripard 
---
 lib/efi_loader/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index d2b6327119b4..a80a914b2fe8 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -1,7 +1,7 @@
 config EFI_LOADER
bool "Support running EFI Applications in U-Boot"
depends on (ARM || X86) && OF_LIBFDT
-   default y
+   default y if !ARCH_SUNXI
help
  Select this option if you want to run EFI applications (like grub2)
  on top of U-Boot. If this option is enabled, U-Boot will expose EFI
-- 
2.14.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/3] ARM: sunxi: Disable USB host options by default

[Maxime Ripard]

The USB keyboard and USB storage support are non-essential from an
architecture-wide sense.

Remove the selection so that we can trim down the size of our binaries a
bit.

Signed-off-by: Maxime Ripard 
---
 arch/arm/Kconfig | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 64e0ee43f112..0eaf54bd8ddb 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -688,7 +688,6 @@ config ARCH_SUNXI
select DM
select DM_ETH
select DM_GPIO
-   select DM_KEYBOARD
select DM_SERIAL
select DM_USB if DISTRO_DEFAULTS
select OF_BOARD_SETUP
@@ -699,8 +698,6 @@ config ARCH_SUNXI
select SYS_NS16550
select SPL_SYS_THUMB_BUILD if !ARM64
select USB if DISTRO_DEFAULTS
-   select USB_STORAGE if DISTRO_DEFAULTS
-   select USB_KEYBOARD if DISTRO_DEFAULTS
select USE_TINY_PRINTF
imply CMD_GPT
imply FAT_WRITE
-- 
2.14.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/3] ARM: sunxi: Disable FAT write by default

[Maxime Ripard]

Writing to FAT filesystems isn't a very widely used feature in U-Boot where
most of the interaction would be reading from such a filesystem.

Remove the imply to gain a bit of size in our binaries.

Signed-off-by: Maxime Ripard 
---
 arch/arm/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0eaf54bd8ddb..2f67ccb9df30 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -700,7 +700,6 @@ config ARCH_SUNXI
select USB if DISTRO_DEFAULTS
select USE_TINY_PRINTF
imply CMD_GPT
-   imply FAT_WRITE
imply PRE_CONSOLE_BUFFER
imply SPL_GPIO_SUPPORT
imply SPL_LIBCOMMON_SUPPORT
-- 
2.14.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Maxime Ripard]

Hi,

Most featureful boards, such as the Cubietruck, have been broken since
the release 2017.09.

This is due to a size increase of the binary that will trip us across
the size we've been using in the u-boot-sunxi-with-spl.bin file.

We would have two ways to work around it. The first one would be to
just increase the offset of the environment. However, since it would
break all the environments of our users and possibly the custom
partition scheme that they would have created, it doesn't really seem
like a smart move.

Another one would be to start trimming down a bit our enabled options
in order to reduce the size and to gain some extra space for users
customisations. I've taken care some of the low hanging fruits, and we
should probably take another go at it in the future (and add a size
check in the image build somehow?)

Maxime

Maxime Ripard (3):
  ARM: sunxi: Disable USB host options by default
  ARM: sunxi: Disable FAT write by default
  efi_loader: Do not enable it by default for sunxi

 arch/arm/Kconfig   | 4 
 lib/efi_loader/Kconfig | 2 +-
 2 files changed, 1 insertion(+), 5 deletions(-)

-- 
2.14.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v6] cmd: usb: ignore blk, emulation devices in usb tree/info display

[Suneel Garapati]

On Thu, Oct 19, 2017 at 12:33 AM, Marek Vasut  wrote:
> On 10/19/2017 05:24 AM, Suneel Garapati wrote:
>> On Wed, Oct 18, 2017 at 6:39 PM, Marek Vasut  wrote:
>>> On 10/19/2017 03:22 AM, Suneel Garapati wrote:
 usb tree/info commands iterate over all usb uclass devices
 recursively. blk uclass child devices are created for mass storage,
 treating these as usb uclass devices and referencing usb config
 interface descriptors cause crash. To fix, ignore blk and usb_emul
 uclass devices(sandbox)
>>>  ^^^ what's this about ? USB_EMUL devices can be
>>> enables elsewhere too, right ?
>> Only disabled during the tree/info dump.
>
> I don't understand this answer. Can USB_EMUL devices be enabled on any
> other machine than sandbox or not ? I presume it can ...
drivers/usb/emul/Kconfig - usb_emul depends on sandbox.
I dont see any machine config using it.
I believe USB_EMUL devices were being ignored before this patch, not sure if
the expectation has changed now.
Anyway, with the change to call only usb_xxx classes this should go
away in description.

>
>>> Anyway, shouldn't you rather filter for positive matches (usb uclass
>>> devices etc) , rather than filtering out a few negative matches (blk
>>> etc) which might break in the future ?
>> usb_for_each_root_dev does that but we dont have 
>> uclass_find_first_child_device
>> to call on UCLASS_USB like uclass_find_first_device.
>> So, device_find_first_child and check on uclass id is performed.
>
> I mean, rather than doing
> (device_get_uclass_id(child) != UCLASS_USB_xxx &&
> device_get_uclass_id(child) != UCLASS_USB_yyy)
>dump
>
> do
>
> (device_get_uclass_id(child) == UCLASS_USB_nnn)
>dump
>
> for nnn being only the relevant USB classes for which we actually want
> to dump.
>
> Does that work ?
May work, I will test and send v7

Regards,
Suneel
>
 in usb_show_info and usb_tree_graph.
 also avoid addition of preamble for blk uclass child devices,
 otherwise tree dump gets messed up.
>>>
>>> Also, sentences start with capital letter. This should be in a separate
>>> patch if it's a separate change ...
>> Ignoring preamble and device should go together, hence cannot be
>> separate change.
>>
>> Regards,
>> Suneel
>>>
 Signed-off-by: Suneel Garapati 
 Reviewed-by: Bin Meng 
 Tested-by: Bin Meng 
 Reviewed-by: Simon Glass 
 ---
 Changes v6:
  - re-write commit message with detail
 Changes v5:
  - add usb_emul to ignore list in usb_show_info
  - modify description
 Changes v4:
  - do not set preamble if child is block device for mass storage
 Changes v3:
  - remove 'check on parent uclass' in description
 Changes v2:
  - remove check on parent uclass
 Changes v1:
  - add separate check on blk uclass
  - modify description
  - add separate check on parent uclass as usb

  cmd/usb.c | 22 +++---
  1 file changed, 19 insertions(+), 3 deletions(-)

 diff --git a/cmd/usb.c b/cmd/usb.c
 index d95bcf5..907debe 100644
 --- a/cmd/usb.c
 +++ b/cmd/usb.c
 @@ -349,6 +349,16 @@ static void usb_show_tree_graph(struct usb_device 
 *dev, char *pre)
   printf(" %s", pre);
  #ifdef CONFIG_DM_USB
   has_child = device_has_active_children(dev->dev);
 + if (device_get_uclass_id(dev->dev) == UCLASS_MASS_STORAGE) {
 + struct udevice *child;
 +
 + for (device_find_first_child(dev->dev, );
 +  child;
 +  device_find_next_child()) {
 + if (device_get_uclass_id(child) == UCLASS_BLK)
 + has_child = 0;
 + }
 + }
  #else
   /* check if the device has connected children */
   int i;
 @@ -414,8 +424,12 @@ static void usb_show_tree_graph(struct usb_device 
 *dev, char *pre)

   udev = dev_get_parent_priv(child);

 - /* Ignore emulators, we only want real devices */
 - if (device_get_uclass_id(child) != UCLASS_USB_EMUL) {
 + /*
 +  * Ignore emulators and block child devices, we only want
 +  * real devices
 +  */
 + if ((device_get_uclass_id(child) != UCLASS_USB_EMUL) &&
 + (device_get_uclass_id(child) != UCLASS_BLK)) {
   usb_show_tree_graph(udev, pre);
   pre[index] = 0;
   }
 @@ -605,7 +619,9 @@ static void usb_show_info(struct usb_device *udev)
   for (device_find_first_child(udev->dev, );
child;
device_find_next_child()) {
 - if (device_active(child)) {
 + if (device_active(child) &&
 + 

Re: [U-Boot] [PATCH] i2c: remove SYS_ prefix from CONFIG options

[Heiko Schocher]

Hello Masahiro,

Am 19.10.2017 um 06:38 schrieb Heiko Schocher:

Hello Masahiro,

Am 17.10.2017 um 15:36 schrieb Masahiro Yamada:

Historically, U-Boot added CONFIG_SYS_ prefix to user-unconfigurable
options.  Somehow, this rule was not observed in some places, and
getting meaningless with Kconfig introduction where platforms can
"select" to force options.  Actually, I2C drivers are generally
configurable.

Convert the options in drivers/i2c/Kconfig.

This commit was generated by the following command.

find . -name .git -prune -o -type f -print | \
xargs sed -i -e '
s/SYS_I2C_AT91/I2C_AT91/g
s/SYS_I2C_FSL/I2C_FSL/g
s/SYS_I2C_CADENCE/I2C_CADENCE/g
s/SYS_I2C_DW/I2C_DW/g
s/SYS_I2C_DW_ENABLE_STATUS_UNSUPPORTED/I2C_DW_ENABLE_STATUS_UNSUPPORTED/g
s/SYS_I2C_ASPEED/I2C_ASPEED/g
s/SYS_I2C_INTEL/I2C_INTEL/g
s/SYS_I2C_IMX_LPI2C/I2C_IMX_LPI2C/g
s/SYS_I2C_MXC/I2C_MXC/g
s/SYS_I2C_OMAP24XX/I2C_OMAP24XX/g
s/SYS_I2C_ROCKCHIP/I2C_ROCKCHIP/g
s/SYS_I2C_SANDBOX/I2C_SANDBOX/g
s/SYS_I2C_S3C24X0/I2C_S3C24X0/g
s/SYS_I2C_STM32F7/I2C_STM32F7/g
s/SYS_I2C_UNIPHIER/I2C_UNIPHIER/g
s/SYS_I2C_UNIPHIER_F/I2C_UNIPHIER_F/g
s/SYS_I2C_MVTWSI/I2C_MVTWSI/g
s/TEGRA186_BPMP_I2C/I2C_TEGRA186_BPMP/g
s/SYS_I2C_BUS_MAX/I2C_BUS_MAX/g
'

Signed-off-by: Masahiro Yamada 



Thanks ... but why do you not convert all symbols?

With your patch there are now CONFIG_I2C and CONFIG_SYS_I2C symbols
mixed. Please send another patch where you convert the missing:

SYS_I2C_ADI
SYS_I2C
SYS_I2C_DAVINCI
SYS_I2C_FTI2C010
SYS_I2C_IHS
SYS_I2C_KONA
SYS_I2C_LPC32XX
SYS_I2C_MXS
SYS_I2C_RCAR
SYS_I2C_SH
SYS_I2C_SOFT
SYS_I2C_TEGRA
SYS_I2C_ZYNQ

Beside of this I like this change.


travis build fails, see:

https://travis-ci.org/hsdenx/u-boot-i2c/builds/289801746

All sort of:

Building current source for 11 boards (2 threads, 1 job per thread)
   arm:  +   imx31_phycore_eet
+comm: file 2 is not in sorted order
+Error: You must add new CONFIG options using Kconfig
+The following new ad-hoc CONFIG options were detected:
+CONFIG_I2C_MXC_I2C1
+CONFIG_I2C_MXC_I2C2
+CONFIG_I2C_MXC_I2C3
+
+Please add these via Kconfig instead. Find a suitable Kconfig
+file and add a 'config' or 'menuconfig' option.

Seems you cannot easy find and replace ...

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v6] cmd: usb: ignore blk, emulation devices in usb tree/info display

[Marek Vasut]

On 10/19/2017 05:24 AM, Suneel Garapati wrote:
> On Wed, Oct 18, 2017 at 6:39 PM, Marek Vasut  wrote:
>> On 10/19/2017 03:22 AM, Suneel Garapati wrote:
>>> usb tree/info commands iterate over all usb uclass devices
>>> recursively. blk uclass child devices are created for mass storage,
>>> treating these as usb uclass devices and referencing usb config
>>> interface descriptors cause crash. To fix, ignore blk and usb_emul
>>> uclass devices(sandbox)
>>  ^^^ what's this about ? USB_EMUL devices can be
>> enables elsewhere too, right ?
> Only disabled during the tree/info dump.

I don't understand this answer. Can USB_EMUL devices be enabled on any
other machine than sandbox or not ? I presume it can ...

>> Anyway, shouldn't you rather filter for positive matches (usb uclass
>> devices etc) , rather than filtering out a few negative matches (blk
>> etc) which might break in the future ?
> usb_for_each_root_dev does that but we dont have 
> uclass_find_first_child_device
> to call on UCLASS_USB like uclass_find_first_device.
> So, device_find_first_child and check on uclass id is performed.

I mean, rather than doing
(device_get_uclass_id(child) != UCLASS_USB_xxx &&
device_get_uclass_id(child) != UCLASS_USB_yyy)
   dump

do

(device_get_uclass_id(child) == UCLASS_USB_nnn)
   dump

for nnn being only the relevant USB classes for which we actually want
to dump.

Does that work ?

>>> in usb_show_info and usb_tree_graph.
>>> also avoid addition of preamble for blk uclass child devices,
>>> otherwise tree dump gets messed up.
>>
>> Also, sentences start with capital letter. This should be in a separate
>> patch if it's a separate change ...
> Ignoring preamble and device should go together, hence cannot be
> separate change.
> 
> Regards,
> Suneel
>>
>>> Signed-off-by: Suneel Garapati 
>>> Reviewed-by: Bin Meng 
>>> Tested-by: Bin Meng 
>>> Reviewed-by: Simon Glass 
>>> ---
>>> Changes v6:
>>>  - re-write commit message with detail
>>> Changes v5:
>>>  - add usb_emul to ignore list in usb_show_info
>>>  - modify description
>>> Changes v4:
>>>  - do not set preamble if child is block device for mass storage
>>> Changes v3:
>>>  - remove 'check on parent uclass' in description
>>> Changes v2:
>>>  - remove check on parent uclass
>>> Changes v1:
>>>  - add separate check on blk uclass
>>>  - modify description
>>>  - add separate check on parent uclass as usb
>>>
>>>  cmd/usb.c | 22 +++---
>>>  1 file changed, 19 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/cmd/usb.c b/cmd/usb.c
>>> index d95bcf5..907debe 100644
>>> --- a/cmd/usb.c
>>> +++ b/cmd/usb.c
>>> @@ -349,6 +349,16 @@ static void usb_show_tree_graph(struct usb_device 
>>> *dev, char *pre)
>>>   printf(" %s", pre);
>>>  #ifdef CONFIG_DM_USB
>>>   has_child = device_has_active_children(dev->dev);
>>> + if (device_get_uclass_id(dev->dev) == UCLASS_MASS_STORAGE) {
>>> + struct udevice *child;
>>> +
>>> + for (device_find_first_child(dev->dev, );
>>> +  child;
>>> +  device_find_next_child()) {
>>> + if (device_get_uclass_id(child) == UCLASS_BLK)
>>> + has_child = 0;
>>> + }
>>> + }
>>>  #else
>>>   /* check if the device has connected children */
>>>   int i;
>>> @@ -414,8 +424,12 @@ static void usb_show_tree_graph(struct usb_device 
>>> *dev, char *pre)
>>>
>>>   udev = dev_get_parent_priv(child);
>>>
>>> - /* Ignore emulators, we only want real devices */
>>> - if (device_get_uclass_id(child) != UCLASS_USB_EMUL) {
>>> + /*
>>> +  * Ignore emulators and block child devices, we only want
>>> +  * real devices
>>> +  */
>>> + if ((device_get_uclass_id(child) != UCLASS_USB_EMUL) &&
>>> + (device_get_uclass_id(child) != UCLASS_BLK)) {
>>>   usb_show_tree_graph(udev, pre);
>>>   pre[index] = 0;
>>>   }
>>> @@ -605,7 +619,9 @@ static void usb_show_info(struct usb_device *udev)
>>>   for (device_find_first_child(udev->dev, );
>>>child;
>>>device_find_next_child()) {
>>> - if (device_active(child)) {
>>> + if (device_active(child) &&
>>> + (device_get_uclass_id(child) != UCLASS_USB_EMUL) &&
>>> + (device_get_uclass_id(child) != UCLASS_BLK)) {
>>>   udev = dev_get_parent_priv(child);
>>>   usb_show_info(udev);
>>>   }
>>>
>>
>>
>> --
>> Best regards,
>> Marek Vasut


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot