12 Jun, 2017

7 commits

  • There was for long time no activity in the 5xx area.
    We need to go further and convert to Kconfig, but it
    turned out, nobody is interested anymore in 5xx,
    so remove it.

    Signed-off-by: Heiko Schocher

    Heiko Schocher
     
  • There was for long time no activity in the 8260 area.
    We need to go further and convert to Kconfig, but it
    turned out, nobody is interested anymore in 8260,
    so remove it.

    Signed-off-by: Heiko Schocher

    Heiko Schocher
     
  • There was for long time no activity in the 8xx area.
    We need to go further and convert to Kconfig, but it
    turned out, nobody is interested anymore in 8xx,
    so remove it (with a heavy heart, knowing that I remove
    here the root of U-Boot).

    Signed-off-by: Heiko Schocher

    Heiko Schocher
     
  • One can obtain those variables using next commands:

    $ fastboot getvar cpu
    $ fastboot getvar secure
    $ fastboot getvar board_rev
    $ fastboot getvar userdata_size

    Those variables are needed for fastboot.sh script.

    Signed-off-by: Sam Protsenko
    Reviewed-by: Tom Rini

    Semen Protsenko
     
  • One can obtain those variables using next commands:

    $ fastboot getvar cpu
    $ fastboot getvar secure
    $ fastboot getvar board_rev
    $ fastboot getvar userdata_size

    Those variables are needed for fastboot.sh script.

    Signed-off-by: Sam Protsenko
    Reviewed-by: Tom Rini

    Semen Protsenko
     
  • This patch reuses new option, which allows us to expose variables
    from environment to "fastboot getvar" command. Those variables must be
    of "fastboot.%s" format.

    Signed-off-by: Sam Protsenko

    Semen Protsenko
     
  • Using u-boot-2017.05 on i.MX6UL we ran into following problem:
    Initially U-Boot could be started normally.
    If we added one random command in configuration, the newly generated
    image hung at startup (last output was DRAM: 256 MiB).

    We tracked this down to a data abort within relocation (relocated_code).

    relocated_code in arch/arm/lib/relocate.S copies 8 bytes per loop
    iteration until the source pointer is equal to __image_copy_end.
    In a good case __image_copy_end was aligned to 8 bytes, so the loop
    stopped as suggested, but in an errornous case __image_copy_end was
    not aligned to 8 bytes, so the loop ran out of bounds and caused a
    data abort exception.

    This patches solves the issue by aligning __image_copy_end to 8 byte
    using the linker script related to arm.

    I don't know if it's the correct way to solve this, so some review would
    be very appreciated.

    Manfred Schlaegl
     

11 Jun, 2017

1 commit


10 Jun, 2017

32 commits