All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] test/py main_signon
@ 2016-02-16 12:12 Michal Simek
  2016-02-16 13:32 ` Heiko Schocher
  0 siblings, 1 reply; 11+ messages in thread
From: Michal Simek @ 2016-02-16 12:12 UTC (permalink / raw)
  To: u-boot

Hi Stephen,

trying to run the latest testing on zynq board and getting this
main_signon error.

This is what I am running
./test/py/test.py --bd zynq_zc702  --build --board-identity zc702
and getting below.

Thanks,
Michal

U-Boot 2016.03-rc2 (Feb 16 2016 - 13:10:03 +0100)

Model: Zynq ZC702 Development Board
Board: Xilinx Zynq
I2C:   ready
DRAM:  ECC disabled 1 GiB

Bad pattern found on console: main_signon

FAILED:
request = <SubRequest 'u_boot_console' for <Function 'test_version'>>

    @pytest.fixture(scope='function')
    def u_boot_console(request):
        """Generate the value of a test's u_boot_console fixture.

        Args:
            request: The pytest request.

        Returns:
            The fixture value.
        """

>       console.ensure_spawned()

test/py/conftest.py:311:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

self = <u_boot_console_exec_attach.ConsoleExecAttach object at
0x7f2b33dee8d0>

    def ensure_spawned(self):
        """Ensure a connection to a correctly running U-Boot instance.

            This may require spawning a new Sandbox process or resetting
target
            hardware, as defined by the implementation sub-class.

            This is an internal function and should not be called directly.

            Args:
                None.

            Returns:
                Nothing.
            """

        if self.p:
            return
        try:
            self.log.start_section('Starting U-Boot')
            self.at_prompt = False
            self.p = self.get_spawn()
            # Real targets can take a long time to scroll large amounts of
            # text if LCD is enabled. This value may need tweaking in the
            # future, possibly per-test to be optimal. This works for 'help'
            # on board 'seaboard'.
            if not self.config.gdbserver:
                self.p.timeout = 30000
            self.p.logfile_read = self.logstream
            if self.config.buildconfig.get('config_spl', False) == 'y':
                m = self.p.expect([pattern_u_boot_spl_signon] +
self.bad_patterns)
                if m != 0:
                    raise Exception('Bad pattern found on console: ' +
>                                   self.bad_pattern_ids[m - 1])
E                                   Exception: Bad pattern found on
console: main_signon

test/py/u_boot_console_base.py:310: Exception

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [U-Boot] test/py main_signon
  2016-02-16 12:12 [U-Boot] test/py main_signon Michal Simek
@ 2016-02-16 13:32 ` Heiko Schocher
  2016-02-16 16:04   ` Michal Simek
  0 siblings, 1 reply; 11+ messages in thread
From: Heiko Schocher @ 2016-02-16 13:32 UTC (permalink / raw)
  To: u-boot

Hello Michal,

Am 16.02.2016 um 13:12 schrieb Michal Simek:
> Hi Stephen,
>
> trying to run the latest testing on zynq board and getting this
> main_signon error.
>
> This is what I am running
> ./test/py/test.py --bd zynq_zc702  --build --board-identity zc702
> and getting below.

Does this board has SPL support without SPL serial output?

If so, can you try my patch:
http://patchwork.ozlabs.org/patch/583348/

Thanks!

bye,
Heiko
>
> Thanks,
> Michal
>
> U-Boot 2016.03-rc2 (Feb 16 2016 - 13:10:03 +0100)
>
> Model: Zynq ZC702 Development Board
> Board: Xilinx Zynq
> I2C:   ready
> DRAM:  ECC disabled 1 GiB
>
> Bad pattern found on console: main_signon
>
> FAILED:
> request = <SubRequest 'u_boot_console' for <Function 'test_version'>>
>
>      @pytest.fixture(scope='function')
>      def u_boot_console(request):
>          """Generate the value of a test's u_boot_console fixture.
>
>          Args:
>              request: The pytest request.
>
>          Returns:
>              The fixture value.
>          """
>
>>        console.ensure_spawned()
>
> test/py/conftest.py:311:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _
>
> self = <u_boot_console_exec_attach.ConsoleExecAttach object at
> 0x7f2b33dee8d0>
>
>      def ensure_spawned(self):
>          """Ensure a connection to a correctly running U-Boot instance.
>
>              This may require spawning a new Sandbox process or resetting
> target
>              hardware, as defined by the implementation sub-class.
>
>              This is an internal function and should not be called directly.
>
>              Args:
>                  None.
>
>              Returns:
>                  Nothing.
>              """
>
>          if self.p:
>              return
>          try:
>              self.log.start_section('Starting U-Boot')
>              self.at_prompt = False
>              self.p = self.get_spawn()
>              # Real targets can take a long time to scroll large amounts of
>              # text if LCD is enabled. This value may need tweaking in the
>              # future, possibly per-test to be optimal. This works for 'help'
>              # on board 'seaboard'.
>              if not self.config.gdbserver:
>                  self.p.timeout = 30000
>              self.p.logfile_read = self.logstream
>              if self.config.buildconfig.get('config_spl', False) == 'y':
>                  m = self.p.expect([pattern_u_boot_spl_signon] +
> self.bad_patterns)
>                  if m != 0:
>                      raise Exception('Bad pattern found on console: ' +
>>                                    self.bad_pattern_ids[m - 1])
> E                                   Exception: Bad pattern found on
> console: main_signon
>
> test/py/u_boot_console_base.py:310: Exception
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [U-Boot] test/py main_signon
  2016-02-16 13:32 ` Heiko Schocher
@ 2016-02-16 16:04   ` Michal Simek
  2016-02-16 16:39     ` Stephen Warren
  2016-02-17  6:34     ` Heiko Schocher
  0 siblings, 2 replies; 11+ messages in thread
From: Michal Simek @ 2016-02-16 16:04 UTC (permalink / raw)
  To: u-boot

Hi Heiko,

On 16.2.2016 14:32, Heiko Schocher wrote:
> Hello Michal,
> 
> Am 16.02.2016 um 13:12 schrieb Michal Simek:
>> Hi Stephen,
>>
>> trying to run the latest testing on zynq board and getting this
>> main_signon error.
>>
>> This is what I am running
>> ./test/py/test.py --bd zynq_zc702  --build --board-identity zc702
>> and getting below.
> 
> Does this board has SPL support without SPL serial output?

I do load u-boot via jtag that's why SPL logs are not visible.

> If so, can you try my patch:
> http://patchwork.ozlabs.org/patch/583348/

I have applied your patch but it is still not working.

If I run full flow with SPL then I can't see any issue.

Thanks,
Michal

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [U-Boot] test/py main_signon
  2016-02-16 16:04   ` Michal Simek
@ 2016-02-16 16:39     ` Stephen Warren
  2016-02-16 19:08       ` Michal Simek
  2016-02-17  6:34     ` Heiko Schocher
  1 sibling, 1 reply; 11+ messages in thread
From: Stephen Warren @ 2016-02-16 16:39 UTC (permalink / raw)
  To: u-boot

On 02/16/2016 09:04 AM, Michal Simek wrote:
> Hi Heiko,
>
> On 16.2.2016 14:32, Heiko Schocher wrote:
>> Hello Michal,
>>
>> Am 16.02.2016 um 13:12 schrieb Michal Simek:
>>> Hi Stephen,
>>>
>>> trying to run the latest testing on zynq board and getting this
>>> main_signon error.
>>>
>>> This is what I am running
>>> ./test/py/test.py --bd zynq_zc702  --build --board-identity zc702
>>> and getting below.
>>
>> Does this board has SPL support without SPL serial output?
>
> I do load u-boot via jtag that's why SPL logs are not visible.
>
>> If so, can you try my patch:
>> http://patchwork.ozlabs.org/patch/583348/
>
> I have applied your patch but it is still not working.
>
> If I run full flow with SPL then I can't see any issue.

I assume this is resolved then?

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [U-Boot] test/py main_signon
  2016-02-16 16:39     ` Stephen Warren
@ 2016-02-16 19:08       ` Michal Simek
  2016-02-16 21:38         ` Stephen Warren
  0 siblings, 1 reply; 11+ messages in thread
From: Michal Simek @ 2016-02-16 19:08 UTC (permalink / raw)
  To: u-boot

Hi Stephen,

2016-02-16 17:39 GMT+01:00 Stephen Warren <swarren@wwwdotorg.org>:

> On 02/16/2016 09:04 AM, Michal Simek wrote:
>
>> Hi Heiko,
>>
>> On 16.2.2016 14:32, Heiko Schocher wrote:
>>
>>> Hello Michal,
>>>
>>> Am 16.02.2016 um 13:12 schrieb Michal Simek:
>>>
>>>> Hi Stephen,
>>>>
>>>> trying to run the latest testing on zynq board and getting this
>>>> main_signon error.
>>>>
>>>> This is what I am running
>>>> ./test/py/test.py --bd zynq_zc702  --build --board-identity zc702
>>>> and getting below.
>>>>
>>>
>>> Does this board has SPL support without SPL serial output?
>>>
>>
>> I do load u-boot via jtag that's why SPL logs are not visible.
>>
>> If so, can you try my patch:
>>> http://patchwork.ozlabs.org/patch/583348/
>>>
>>
>> I have applied your patch but it is still not working.
>>
>> If I run full flow with SPL then I can't see any issue.
>>
>
> I assume this is resolved then?
>

Unfortunately both cases should work because SPL is not only one first
stage bootloader
which can be used. I didn't test zynqmp but there is no SPL and the same
problem is
probably there too. Or is there any dependency that if SPL is not build
than testing system
is not expecting it?

I will look tmr at jtag boot mode with SPL if I can get it work.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [U-Boot] test/py main_signon
  2016-02-16 19:08       ` Michal Simek
@ 2016-02-16 21:38         ` Stephen Warren
  2016-02-17  8:42           ` Michal Simek
  0 siblings, 1 reply; 11+ messages in thread
From: Stephen Warren @ 2016-02-16 21:38 UTC (permalink / raw)
  To: u-boot

On 02/16/2016 12:08 PM, Michal Simek wrote:
> Hi Stephen,
>
> 2016-02-16 17:39 GMT+01:00 Stephen Warren <swarren@wwwdotorg.org
> <mailto:swarren@wwwdotorg.org>>:
>
>     On 02/16/2016 09:04 AM, Michal Simek wrote:
>
>         Hi Heiko,
>
>         On 16.2.2016 14:32, Heiko Schocher wrote:
>
>             Hello Michal,
>
>             Am 16.02.2016 um 13:12 schrieb Michal Simek:
>
>                 Hi Stephen,
>
>                 trying to run the latest testing on zynq board and
>                 getting this
>                 main_signon error.
>
>                 This is what I am running
>                 ./test/py/test.py --bd zynq_zc702  --build
>                 --board-identity zc702
>                 and getting below.
>
>
>             Does this board has SPL support without SPL serial output?
>
>
>         I do load u-boot via jtag that's why SPL logs are not visible.
>
>             If so, can you try my patch:
>             http://patchwork.ozlabs.org/patch/583348/
>
>
>         I have applied your patch but it is still not working.
>
>         If I run full flow with SPL then I can't see any issue.
>
>
>     I assume this is resolved then?
>
>
> Unfortunately both cases should work because SPL is not only one first
> stage bootloader
> which can be used. I didn't test zynqmp but there is no SPL and the same
> problem is
> probably there too. Or is there any dependency that if SPL is not build
> than testing system
> is not expecting it?
>
> I will look tmr at jtag boot mode with SPL if I can get it work.

The test scripts currently assume that if SPL is enabled in the U-Boot 
configuration file, then U-Boot SPL will run and print its signon 
message to the serial console. If you're starting U-Boot using a 
technique that invalidates this assumption, it won't work currently, as 
you found.

It's pretty easy to add a flag in the boardenv file to tell the system 
not to expect SPL signon. If you take a look at my second suggestion in:

http://lists.denx.de/pipermail/u-boot/2016-February/245759.html
[U-Boot] [PATCH] test/py: only check for SPL signature if SPL uses 
serial output

... then it's probably a simple as adding a third variable into the if 
condition, where that variable gets looks up from the "board 
environment", similar to:

spl_skipped = u_boot_console.config.env.get('env__spl_skipped', False)

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [U-Boot] test/py main_signon
  2016-02-16 16:04   ` Michal Simek
  2016-02-16 16:39     ` Stephen Warren
@ 2016-02-17  6:34     ` Heiko Schocher
  2016-02-17  7:24       ` Michal Simek
  1 sibling, 1 reply; 11+ messages in thread
From: Heiko Schocher @ 2016-02-17  6:34 UTC (permalink / raw)
  To: u-boot

Hello Michal,

Am 16.02.2016 um 17:04 schrieb Michal Simek:
> Hi Heiko,
>
> On 16.2.2016 14:32, Heiko Schocher wrote:
>> Hello Michal,
>>
>> Am 16.02.2016 um 13:12 schrieb Michal Simek:
>>> Hi Stephen,
>>>
>>> trying to run the latest testing on zynq board and getting this
>>> main_signon error.
>>>
>>> This is what I am running
>>> ./test/py/test.py --bd zynq_zc702  --build --board-identity zc702
>>> and getting below.
>>
>> Does this board has SPL support without SPL serial output?
>
> I do load u-boot via jtag that's why SPL logs are not visible.
>
>> If so, can you try my patch:
>> http://patchwork.ozlabs.org/patch/583348/
>
> I have applied your patch but it is still not working.
>
> If I run full flow with SPL then I can't see any issue.

I am not an expert of test/py (I still try to dig into it), but as
I understand it, it looks if CONFIG_SPL is defined, if so, the
framework expects a SPL output first, if not found, it raises
the error you see ...

My patch fixes this, for boards which use SPL, but without serial
SPL output ...

Now you test only u-boot with SPL configured with SPL serial output ...

I think Stephen can say here more, how to solve this ...

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [U-Boot] test/py main_signon
  2016-02-17  6:34     ` Heiko Schocher
@ 2016-02-17  7:24       ` Michal Simek
  0 siblings, 0 replies; 11+ messages in thread
From: Michal Simek @ 2016-02-17  7:24 UTC (permalink / raw)
  To: u-boot

Hi Heiko,

On 17.2.2016 07:34, Heiko Schocher wrote:
> Hello Michal,
> 
> Am 16.02.2016 um 17:04 schrieb Michal Simek:
>> Hi Heiko,
>>
>> On 16.2.2016 14:32, Heiko Schocher wrote:
>>> Hello Michal,
>>>
>>> Am 16.02.2016 um 13:12 schrieb Michal Simek:
>>>> Hi Stephen,
>>>>
>>>> trying to run the latest testing on zynq board and getting this
>>>> main_signon error.
>>>>
>>>> This is what I am running
>>>> ./test/py/test.py --bd zynq_zc702  --build --board-identity zc702
>>>> and getting below.
>>>
>>> Does this board has SPL support without SPL serial output?
>>
>> I do load u-boot via jtag that's why SPL logs are not visible.
>>
>>> If so, can you try my patch:
>>> http://patchwork.ozlabs.org/patch/583348/
>>
>> I have applied your patch but it is still not working.
>>
>> If I run full flow with SPL then I can't see any issue.
> 
> I am not an expert of test/py (I still try to dig into it), but as
> I understand it, it looks if CONFIG_SPL is defined, if so, the
> framework expects a SPL output first, if not found, it raises
> the error you see ...
> 
> My patch fixes this, for boards which use SPL, but without serial
> SPL output ...
> 
> Now you test only u-boot with SPL configured with SPL serial output ...
> 
> I think Stephen can say here more, how to solve this ...

Ok. I have spent some time on this. Your patch is covering a little bit
different case than I have.
We have in general two used cases. One is to use SPL as first stage
bootloader and then private full featured FSBL.
Both of them works with the same u-boot image. It means I can build
uboot with SPL and run two test sets. One with SPL which is working fine
and the second without but there is no reason to rebuild u-boot without
SPL just to pass testing.
It means the feature I am looking for is more about ignoring SPL signon
instead of supporting cases where SPL doesn't print anything.

Thanks,
Michal

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [U-Boot] test/py main_signon
  2016-02-16 21:38         ` Stephen Warren
@ 2016-02-17  8:42           ` Michal Simek
  2016-02-17  9:05             ` Heiko Schocher
  2016-02-17 18:38             ` Stephen Warren
  0 siblings, 2 replies; 11+ messages in thread
From: Michal Simek @ 2016-02-17  8:42 UTC (permalink / raw)
  To: u-boot

Hi Stephen,

On 16.2.2016 22:38, Stephen Warren wrote:
> On 02/16/2016 12:08 PM, Michal Simek wrote:
>> Hi Stephen,
>>
>> 2016-02-16 17:39 GMT+01:00 Stephen Warren <swarren@wwwdotorg.org
>> <mailto:swarren@wwwdotorg.org>>:
>>
>>     On 02/16/2016 09:04 AM, Michal Simek wrote:
>>
>>         Hi Heiko,
>>
>>         On 16.2.2016 14:32, Heiko Schocher wrote:
>>
>>             Hello Michal,
>>
>>             Am 16.02.2016 um 13:12 schrieb Michal Simek:
>>
>>                 Hi Stephen,
>>
>>                 trying to run the latest testing on zynq board and
>>                 getting this
>>                 main_signon error.
>>
>>                 This is what I am running
>>                 ./test/py/test.py --bd zynq_zc702  --build
>>                 --board-identity zc702
>>                 and getting below.
>>
>>
>>             Does this board has SPL support without SPL serial output?
>>
>>
>>         I do load u-boot via jtag that's why SPL logs are not visible.
>>
>>             If so, can you try my patch:
>>             http://patchwork.ozlabs.org/patch/583348/
>>
>>
>>         I have applied your patch but it is still not working.
>>
>>         If I run full flow with SPL then I can't see any issue.
>>
>>
>>     I assume this is resolved then?
>>
>>
>> Unfortunately both cases should work because SPL is not only one first
>> stage bootloader
>> which can be used. I didn't test zynqmp but there is no SPL and the same
>> problem is
>> probably there too. Or is there any dependency that if SPL is not build
>> than testing system
>> is not expecting it?
>>
>> I will look tmr at jtag boot mode with SPL if I can get it work.
> 
> The test scripts currently assume that if SPL is enabled in the U-Boot
> configuration file, then U-Boot SPL will run and print its signon
> message to the serial console. If you're starting U-Boot using a
> technique that invalidates this assumption, it won't work currently, as
> you found.
> 
> It's pretty easy to add a flag in the boardenv file to tell the system
> not to expect SPL signon. If you take a look at my second suggestion in:
> 
> http://lists.denx.de/pipermail/u-boot/2016-February/245759.html
> [U-Boot] [PATCH] test/py: only check for SPL signature if SPL uses
> serial output
> 
> ... then it's probably a simple as adding a third variable into the if
> condition, where that variable gets looks up from the "board
> environment", similar to:
> 
> spl_skipped = u_boot_console.config.env.get('env__spl_skipped', False)

ok. I see. Anyway I have done this change locally and it is working good.
Heiko: Are you able to add this one more checking to your patch? Or
should I wait till you add your patch to the tree?

Stephen: Do you have your u-boot-test-hooks for qemu?

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160217/e7c4d476/attachment.sig>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [U-Boot] test/py main_signon
  2016-02-17  8:42           ` Michal Simek
@ 2016-02-17  9:05             ` Heiko Schocher
  2016-02-17 18:38             ` Stephen Warren
  1 sibling, 0 replies; 11+ messages in thread
From: Heiko Schocher @ 2016-02-17  9:05 UTC (permalink / raw)
  To: u-boot

Hello Michal,

Am 17.02.2016 um 09:42 schrieb Michal Simek:
> Hi Stephen,
>
> On 16.2.2016 22:38, Stephen Warren wrote:
>> On 02/16/2016 12:08 PM, Michal Simek wrote:
>>> Hi Stephen,
>>>
>>> 2016-02-16 17:39 GMT+01:00 Stephen Warren <swarren@wwwdotorg.org
>>> <mailto:swarren@wwwdotorg.org>>:
>>>
>>>      On 02/16/2016 09:04 AM, Michal Simek wrote:
>>>
>>>          Hi Heiko,
>>>
>>>          On 16.2.2016 14:32, Heiko Schocher wrote:
>>>
>>>              Hello Michal,
>>>
>>>              Am 16.02.2016 um 13:12 schrieb Michal Simek:
>>>
>>>                  Hi Stephen,
>>>
>>>                  trying to run the latest testing on zynq board and
>>>                  getting this
>>>                  main_signon error.
>>>
>>>                  This is what I am running
>>>                  ./test/py/test.py --bd zynq_zc702  --build
>>>                  --board-identity zc702
>>>                  and getting below.
>>>
>>>
>>>              Does this board has SPL support without SPL serial output?
>>>
>>>
>>>          I do load u-boot via jtag that's why SPL logs are not visible.
>>>
>>>              If so, can you try my patch:
>>>              http://patchwork.ozlabs.org/patch/583348/
>>>
>>>
>>>          I have applied your patch but it is still not working.
>>>
>>>          If I run full flow with SPL then I can't see any issue.
>>>
>>>
>>>      I assume this is resolved then?
>>>
>>>
>>> Unfortunately both cases should work because SPL is not only one first
>>> stage bootloader
>>> which can be used. I didn't test zynqmp but there is no SPL and the same
>>> problem is
>>> probably there too. Or is there any dependency that if SPL is not build
>>> than testing system
>>> is not expecting it?
>>>
>>> I will look tmr at jtag boot mode with SPL if I can get it work.
>>
>> The test scripts currently assume that if SPL is enabled in the U-Boot
>> configuration file, then U-Boot SPL will run and print its signon
>> message to the serial console. If you're starting U-Boot using a
>> technique that invalidates this assumption, it won't work currently, as
>> you found.
>>
>> It's pretty easy to add a flag in the boardenv file to tell the system
>> not to expect SPL signon. If you take a look at my second suggestion in:
>>
>> http://lists.denx.de/pipermail/u-boot/2016-February/245759.html
>> [U-Boot] [PATCH] test/py: only check for SPL signature if SPL uses
>> serial output
>>
>> ... then it's probably a simple as adding a third variable into the if
>> condition, where that variable gets looks up from the "board
>> environment", similar to:
>>
>> spl_skipped = u_boot_console.config.env.get('env__spl_skipped', False)
>
> ok. I see. Anyway I have done this change locally and it is working good.
> Heiko: Are you able to add this one more checking to your patch? Or
> should I wait till you add your patch to the tree?

I just posted a v2 of my patch ... I vote, that you send your patch
based on mine to the ML.

bye,
Heiko
>
> Stephen: Do you have your u-boot-test-hooks for qemu?
>
> Thanks,
> Michal
>

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [U-Boot] test/py main_signon
  2016-02-17  8:42           ` Michal Simek
  2016-02-17  9:05             ` Heiko Schocher
@ 2016-02-17 18:38             ` Stephen Warren
  1 sibling, 0 replies; 11+ messages in thread
From: Stephen Warren @ 2016-02-17 18:38 UTC (permalink / raw)
  To: u-boot

On 02/17/2016 01:42 AM, Michal Simek wrote:
...
> Stephen: Do you have your u-boot-test-hooks for qemu?

I only have some local hacks that aren't at all generic. They're on my 
laptop at home so I can't share them right now, but I can describe them 
from memory:

u-boot-test-flash: Does nothing

u-boot-test-reset: Does nothing (I assume the test/py code will kill and 
restart the u-boot-test-console process each time it executes 
u-boot-test-reset).

u-boot-test-console: exec()s qemu with whatever target-specific options 
are required to make it execute the appropriate U-Boot binary as 
firmware (rather than the more common option of booting a Linux kernel 
for example), and with the emulated serial port connected to qemu's 
stdin/stdout. Something like:

exec qemu-system-arm -M raspi2 -serial stdio -fw /path/to/u-boot.bin ...

I had considered a new u_boot_console_qemu to standardize this a bit 
more. I'm not sure how useful this is since the user will still need to 
provide some configuration e.g. where the qemu binary is located, if 
there's a disk image to use for the emulated SD card, whether their 
system can support emulated Ethernet in qemu, etc. So, they may as well 
use u_boot_console_exec_attach, and implement the same hook scripts as 
any other system.

I had also wondered about updating .travis.yml to test via qemu too. 
Maybe that's better done by an external test system though.

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2016-02-17 18:38 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-16 12:12 [U-Boot] test/py main_signon Michal Simek
2016-02-16 13:32 ` Heiko Schocher
2016-02-16 16:04   ` Michal Simek
2016-02-16 16:39     ` Stephen Warren
2016-02-16 19:08       ` Michal Simek
2016-02-16 21:38         ` Stephen Warren
2016-02-17  8:42           ` Michal Simek
2016-02-17  9:05             ` Heiko Schocher
2016-02-17 18:38             ` Stephen Warren
2016-02-17  6:34     ` Heiko Schocher
2016-02-17  7:24       ` Michal Simek

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.