Skip to content
This repository has been archived by the owner on Apr 25, 2020. It is now read-only.

added block command which returns the block size #2

Conversation

razvan-becheriu
Copy link

No description provided.

@htot
Copy link
Member

htot commented Oct 26, 2019

This v2 of PR #1

Thanks @razvan-becheriu I will test this patch and have the u-boot recipe apply it from here https://github.com/htot/meta-intel-edison/tree/master/meta-intel-edison-bsp/recipes-bsp/u-boot/files (it will take a little time from there to get into edision-fw).

That way it will survive u-boot updates automatically (until it breaks). Will you send this patch to upstream?

@razvan-becheriu
Copy link
Author

razvan-becheriu commented Oct 27, 2019 via email

@htot
Copy link
Member

htot commented Oct 27, 2019

yes I will. please let me how to proceed. Regards, Razvan.

I think you would need to rebase against u-boot master and send to ML here https://lists.denx.de/listinfo/u-boot

PS: please let me know when it will be included in the thud build.

It will go into warrior.

@htot
Copy link
Member

htot commented Oct 27, 2019

@razvan-becheriu I took your U-Boot patch and added it into the u-boot recipe. This way it will survive u-boot updates automatically, until you patch get upstreamed or until it breaks otherwise.

I force pushed this into htoth/meta-intel-edison master and warrior. Eventually this will go into edison-fw. It builds but I would appreciate if you test it..

htot pushed a commit that referenced this pull request Jan 11, 2020
Add support to boot some remoteprocs at U-boot prompt on the J721E EVM
boards by using the 'boot_rprocs' and other env variables defined in the
common environment file k3_rproc.h, and updating the 'DEFAULT_RPROCS'
macro.

The list of R5F cores to be started before loading and booting the Linux
kernel are as follows, and in this order:
   Main R5FSS0 (Split) Core1 : 3 /lib/firmware/j7-main-r5f0_1-fw
   Main R5FSS1 (LockStep)    : 4 /lib/firmware/j7-main-r5f1_0-fw

The MCU R5FSS0 and Main R5FSS1 are currently in LockStep mode, so the
equivalent Core1 rprocs (rproc #1 and #5) are not included. The Main
R5FSS0 Core0 (rproc #2) is already started by R5 SPL, so is not included
in the list either.

The DSP cores are started in the following order before loading and
booting the Linux kernel:
   C66_0: 6 /lib/firmware/j7-c66_0-fw
   C66_1: 7 /lib/firmware/j7-c66_1-fw
   C71_0: 8 /lib/firmware/j7-c71_0-fw

The order of the rprocs to boot can be changed at runtime if desired by
overwriting the 'rproc_fw_binaries' environment variable at U-boot prompt.

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
htot pushed a commit that referenced this pull request Jan 11, 2020
After updating libavb to most recent version from AOSP/master, two new
warnings appear:

Warning #1:

    lib/libavb/avb_cmdline.c: In function 'avb_append_options':
    lib/libavb/avb_cmdline.c:365:15: warning: 'dm_verity_mode' may be
                                     used uninitialized in this function
                                     [-Wmaybe-uninitialized]
         new_ret = avb_replace(
                   ^~~~~~~~~~~~
             slot_data->cmdline, "$(ANDROID_VERITY_MODE)", dm_verity_mode);
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    lib/libavb/avb_cmdline.c:374:8: warning: 'verity_mode' may be used
                                    uninitialized in this function
                                    [-Wmaybe-uninitialized]
       if (!cmdline_append_option(
            ^~~~~~~~~~~~~~~~~~~~~~
               slot_data, "androidboot.veritymode", verity_mode)) {
               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Warning #2:

    lib/libavb/avb_slot_verify.c: In function 'avb_slot_verify':
    lib/libavb/avb_slot_verify.c:1349:23: warning: 'ret' may be used
                                          uninitialized in this function
                                          [-Wmaybe-uninitialized]
       AvbSlotVerifyResult ret;
                           ^~~

Fix those by providing default return values to affected functions.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
@htot
Copy link
Member

htot commented Apr 19, 2020

@razvan-becheriu: @andy-shev has declared that all his edison patches are now in upstream and therefore edison-fw should use that. His repo will now be used for experimental work from now on.

So edison-fw will now switch to upstream, but add (non-essential) patches from @andy-shev and the patch from this PR. Are you planning to send your patch upstream (please do)?

@htot htot closed this Apr 19, 2020
@razvan-becheriu
Copy link
Author

I don't understand. Is there something I should do. I would like to send the patch upstream, but I thing only you or andy-shev can do that.

Hasn't this patch been merged yet?

@razvan-becheriu
Copy link
Author

oh, just read previous posts. I think I can do that. I'll let you know when it is done.

@razvan-becheriu
Copy link
Author

razvan-becheriu commented Apr 19, 2020 via email

@razvan-becheriu
Copy link
Author

razvan-becheriu commented Apr 19, 2020 via email

@htot
Copy link
Member

htot commented Apr 20, 2020

hm...it seems that fw-intel-edison (https://github.com/edison-fw/u-boot.git)
master is missing command 'number'.

It should be in upstream master already.
be68375
400b955

@andy-shev
Copy link

@razvan-becheriu
Follow
https://www.denx.de/wiki/U-Boot/Patches and send directly to upstream. Thanks!

@razvan-becheriu
Copy link
Author

razvan-becheriu commented Apr 21, 2020 via email

@htot
Copy link
Member

htot commented Apr 21, 2020

No, it's not a mistake. meta-intel-edison has your patch in the recipe for U-Boot. But this U-Boot repo will be archived any moment now. So your patch should go to upstream U-Boot (sent to mailing list so it will go into master).

@razvan-becheriu
Copy link
Author

razvan-becheriu commented Apr 21, 2020 via email

@razvan-becheriu
Copy link
Author

razvan-becheriu commented Apr 21, 2020 via email

@htot
Copy link
Member

htot commented Apr 21, 2020

You mean to rebase against? https://github.com/u-boot/u-boot

But they don't take PR's from github. You should send the patch to the mailing list (that is: by e-mail)

@razvan-becheriu
Copy link
Author

razvan-becheriu commented Apr 21, 2020 via email

@htot
Copy link
Member

htot commented Apr 23, 2020

Your patch made it to the list. I think you didn't follow the guide on using patchman? So there is no one on the CC. But maybe @andy-shev will care to review it?
I can add Tested-by: tag. But I sure they will want you to add Signed-off-by: tag. You will probably be asked to resend anyway.

@razvan-becheriu
Copy link
Author

razvan-becheriu commented Apr 23, 2020 via email

@htot
Copy link
Member

htot commented Apr 23, 2020

I don't know. Just my git is configured to automatically add signed-off.

@andy-shev
Copy link

andy-shev commented Apr 23, 2020

@razvan-becheriu
Read my previous comment here. It has a link to the documentation on how to contribute to U-Boot.

For your convenience:
https://www.denx.de/wiki/U-Boot/Patches

@htot
Without SoB tag nobody gonna touch that...

@htot htot mentioned this pull request Sep 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
3 participants