[cip-dev] [cip-testing] Issue #167 - Build & test iw20gm kernel outside of cip-core/bitbake env

[cip-dev] [cip-testing] Issue #167 - Build & test iw20gm kernel outside of cip-core/bitbake env

[Zoran S]

Hello to everyone,

I did some testing on this issue: 167, which appear to be a show stopper
for Renesas iwg20m platform. I did change several times shmobile_defconfig
in order to build better CIP 4.4.120 kernel. Unfortunately, every time (4
in total) I failed.

Both me (testing CIP 4.4.120) and Robert (testing CIP 4.4.112) have
problems with iwg20m ETH1000 port. I am able to progress up to running the
"starting kernel" message, then my tests fail (they hang).

I have a gut feeling that some untested RT patch, influencing the iwg20m
clocking tree, makes this mess. I guess, the ETH1000 problems are NOT the
cause, rather the effect of this timing caused by buggy clocking tree
iwg20m patch.

I need to think more about all of this. The next obvious step is to start
switching off/changing some of the timers' options in kernel's .config. To
have bare minimum/simplistic/minimalistic clocking tree which still makes
iwg20m platform to perform. In other words, failsafe clocking tree option.

Next week I'll continue the research, switching/changing/eliminating some
of the clocking tree options, where possible.

If anybody from developers can recall any of such clocking tree patch,
which made to the kernel prior CIP 4.4.112 version, this will be a great
test to point to it, so I can try to revert such a patch, and see what
happens.

Thank you,
Zoran
_______

On Tue, Mar 13, 2018 at 5:26 PM, Zoran S <zoran.stojsavljevic.de@gmail.com>
wrote:

> Hello Augustin,
>
> I have update on iwg20m... Straight to the newest kernel
> 4.4.120-cip20-rt13! ;-)
>
> You write:
>
> > Work in progress to support Renesas iw20gm in B at D in the coming weeks.
> > Link: https://gitlab.com/cip-project/cip-testing/testing/issues/167
>
> I spent today whole day home alone to play with board (called
> iW-RainboW-G20D), based on iwg20m which was given to me by Jan (Kiszka).
>
> It has RENESAS r8a7743 (armv7h, if I am not mistaken), and it is quite an
> interesting board, I must admit).
>
> The task: make it compliant with CIP VM Lava testing in one (1) one single
> day, since I do not have too much experience with this board.
>
> This one is initial which was used by Lava 2017.7 bring-up.
>
> I was able today to do the following:
> [1] Add passthrough to the Vagrantfile, so I can have iwg20m ser2net on
> the VM;
> [2] Create the new device-type in Lava: /etc/lava-server/dispatcher-co
> nfig/device-types/iwg2x.jinja
> [3] Add this device type to Lava using Django management, with several
> tests to see how the device type iwg2x behaves;
> [4] Add the concrete device to device type: /etc/lava-server/dispatcher-co
> nfig/devices/iwg20m.jinja;
> [5] Handled/prepared the newest kernel CIP 4.4.120-cip20 (released last
> week, by Daniel Wagner);
>      v4.4.120-cip20-iwg20m/v4.4.120-cip20-rt13
>      https://pastebin.com/gv0cg3PD
>
> Now, after some triages, and some .jinja2 fixes, some u-boot adjustments
> in the device-type script, I was able to run the Lava .yaml test on
> raminitfs.
>
> It behaves correctly (local/private network is the problem here) till it
> needs to start kernel, which it tftp-ed correctly from localhost://8010 ---
> where kernel ingredients are located.
>
> But, it fails since it looses a mac/physical address, it seems. So,
> something is not correct with ETH100/ETH1000 driver, since I see these
> problems popping up again, and again, and again... But my dhcpd daemon is
> very robust, and it keeps pounding/adding lost address to the ETH on
> Renesas board.
>
> The .yaml test I am running to test this board is here: job_name:
> local test of ramdisk test on iwg20
> https://pastebin.com/8ngYQzha
>
> And the Lava initramfs test results are captured here:
> https://pastebin.com/AjRdTZKx
>
> Please, note the point of failure:
>
> ## Flattened Device Tree blob at 40f00000
>    Booting using the fdt blob at 0x40f00000
>    Using Device Tree in place at 40f00000, end 40f09094
> *Unable to update property <NULL>:mac-address, err=FDT_ERR_BADPATH*
> *Unable to update property <NULL>:local-mac-address, err=FDT_ERR_BADPATH*
> *Unable to update property /iwg20m_q7_common:vin2-ov5640,
> err=FDT_ERR_NOTFOUND*
> *Starting kernel ...*
> end: 2.4.3 bootloader-commands (duration 00:00:58) [common]
> start: 2.4.4 auto-login-action (timeout 00:04:00) [common]
> boot_message is being deprecated in favour of kernel-start-message in
> constants
> auto-login-action: Wait for prompt ['Booting Linux', 'Resetting CPU', *'Must
> RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The
> remote end did not respond in time.'] *(timeout 00:05:00)
> auto-login-action timed out after 240 seconds
>
> Any guidance/help from Renesas people and others on The Far East using
> this iwg20m technology is appreciated and welcome!
>
> Thank you,
> Zoran Stojsavljevic
> _______
>
> On Tue, Mar 13, 2018 at 3:58 PM, Agust?n Benito Bethencourt <
> agustin.benito at codethink.co.uk> wrote:
>
>> Hi Yoshi,
>>
>> since you usually provide an update of the technical work done within CIP
>> in
>> your talks, here are some bullet points you can add in tomorrow's talk at
>> ELC
>> if you like.
>>
>> ## Kernel maintenance
>>
>> * CIP 4.4.120-cip20 released last week.
>>
>> Link: https://gitlab.com/cip-project/linux-cip
>>
>> Comment: Ben Hutchings, from Codethink, releases a kernel version every 4
>> to 6
>> weeks approx., depending on the amount and relevance of upstream patches
>> landing on 4.4 LTS. Ben H. collaborates in the 4.4 LTS process directly.
>>
>> * Effort in ensuring Meltdown and Spectre fixes land in the CIP kernel
>> and CIP
>> Members are informed about the current situation.
>>
>> * Review of platform specific backported patches, specially from Renesas
>> platforms.
>>
>> Comment: Renesas backports patches to 4.4 from mainline that are reviewed
>> and
>> merged into CIP kernel when appropriate.
>>
>> * CIP 4.4.120-cip120-rt13 released
>>
>> Link: git://git.kernel.org/pub/scm/linux/kernel/git/wagi/linux-cip-rt.git
>>
>> Comment: I would name Daniel Wagner, Siemens, as maintainer and say a few
>> words about the release process if you have time.
>>
>> ## Kernel testing
>>
>> * B at D is being updated to include the latest kernelci
>>
>> Link: https://gitlab.com/cip-project/cip-testing/board-at-desk-sin
>> gle-dev/
>> merge_requests/53
>> <https://gitlab.com/cip-project/cip-testing/board-at-desk-single-dev/merge_requests/53>
>>
>> * Work in progress to support Renesas iw20gm in B at D in the coming weeks.
>>
>> Link: https://gitlab.com/cip-project/cip-testing/testing/issues/167
>>
>> * Improvements in networking and Vagrant configurations.
>>
>> * Next steps: deployment through containers.
>>
>> * B at D description and deploy.
>>
>> Description: https://wiki.linuxfoundation.org/civilinfrastructureplatform
>> /
>> ciptestingboardatdesksingledevfeaturepage
>>
>> Deploy: https://wiki.linuxfoundation.org/civilinfrastructureplatform/
>> ciptestingboardatdeskdingledevdeployment#b-d-deployment-meth
>> od-2-building-vm-
>> from-scratch-using-vagrant-15
>> <https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptestingboardatdeskdingledevdeployment#b-d-deployment-method-2-building-vm-from-scratch-using-vagrant-15>
>>
>> Any additional feedback from participants on this list is welcome.
>>
>> Best Regards
>> --
>> Agust?n Benito Bethencourt
>> Principal Consultant
>> Codethink Ltd
>> _______________________________________________
>> cip-dev mailing list
>> cip-dev at lists.cip-project.org
>> https://lists.cip-project.org/mailman/listinfo/cip-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20180315/1a509adf/attachment-0001.html>

[cip-dev] [cip-testing] Issue #167 - Build & test iw20gm kernel outside of cip-core/bitbake env

[Daniel Wagner]

Hi Zoran,

> I have a gut feeling that some untested RT patch, influencing the iwg20m
> clocking tree, makes this mess. I guess, the ETH1000 problems are NOT
> the cause, rather the effect of this timing caused by buggy clocking
> tree iwg20m patch.

If you think -rt is a problem, test without it. Though I don't expect
that will be the source of this problem. When the -rt patch set creates
a problem the symptoms are quite different.

> I need to think more about all of this. The next obvious step is to
> start switching off/changing some of the timers' options in kernel's
> .config. To have bare minimum/simplistic/minimalistic clocking tree
> which still makes iwg20m platform to perform. In other words, failsafe
> clocking tree option.

IIRC, there was a working configuration on installed on the SD card. I
suggest you compare the DT with the new one.

Daniel

[cip-dev] [cip-testing] Issue #167 - Build & test iw20gm kernel outside of cip-core/bitbake env

[Ben Hutchings]

On Thu, 2018-03-15 at 16:52 +0100, Zoran S wrote:
> Hello to everyone,
> 
> I did some testing on this issue: 167, which appear to be a show
> stopper for Renesas iwg20m platform. I did change several times
> shmobile_defconfig in order to build better CIP 4.4.120 kernel.
> Unfortunately, every time (4 in total) I failed.
> 
> Both me (testing CIP 4.4.120) and Robert (testing CIP 4.4.112) have
> problems with iwg20m ETH1000 port.

That's interesting. I've also sometimes had trouble getting a reliable
link at 1000 Mbps.  When I discussed this with Robert he hadn't yet seen the problem so I though it might be cable-dependent.  (We are sharing the board but have used different Ethernet cables.)

When I reconfigured my laptop's Ethernet port to only support 100 Mbps
(ethtool -s <device> speed 100 duplex full) the link became more
reliable.

> I am able to progress up to running the "starting kernel" message,
> then my tests fail (they hang).?
[...]

So u-boot starts the kernel, but you don't get any kernel log messages?
 Are you certain that the device tree is loaded successfully?  I don't
know whether LAVA checks for error messages from u-boot.

Ben.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.

[cip-dev] [cip-testing] Issue #167 - Build & test iw20gm kernel outside of cip-core/bitbake env

[Zoran S]

> When I discussed this with Robert he hadn't yet seen the
> problem so I though it might be cable-dependent. (We are
> sharing the board but have used different Ethernet cables.)

As I see, Robert has also the problems with ETH1000. Please, find Robert's
Lava traces:
https://paste.baserock.org/selefaxabo

> Are you certain that the device tree is loaded successfully?  I don't
> know whether LAVA checks for error messages from u-boot.

Nope. You are correct. In order to do much better analysis, I need to make
iwg20m YOCTO load to work. But this task appeared to be NOT at all easy.

Since I have as host Fedora 27 with latest updates about two weeks ago, I
need to setup/make a Vbox VM of a supported at that time host distribution
(Jethro - EOL Fedora 22).

Zoran
_______

On Tue, Mar 20, 2018 at 7:50 PM, Ben Hutchings <
ben.hutchings@codethink.co.uk> wrote:

> On Thu, 2018-03-15 at 16:52 +0100, Zoran S wrote:
> > Hello to everyone,
> >
> > I did some testing on this issue: 167, which appear to be a show
> > stopper for Renesas iwg20m platform. I did change several times
> > shmobile_defconfig in order to build better CIP 4.4.120 kernel.
> > Unfortunately, every time (4 in total) I failed.
> >
> > Both me (testing CIP 4.4.120) and Robert (testing CIP 4.4.112) have
> > problems with iwg20m ETH1000 port.
>
> That's interesting. I've also sometimes had trouble getting a reliable
> link at 1000 Mbps.  When I discussed this with Robert he hadn't yet seen
> the problem so I though it might be cable-dependent.  (We are sharing the
> board but have used different Ethernet cables.)
>
> When I reconfigured my laptop's Ethernet port to only support 100 Mbps
> (ethtool -s <device> speed 100 duplex full) the link became more
> reliable.
>
> > I am able to progress up to running the "starting kernel" message,
> > then my tests fail (they hang).
> [...]
>
> So u-boot starts the kernel, but you don't get any kernel log messages?
>  Are you certain that the device tree is loaded successfully?  I don't
> know whether LAVA checks for error messages from u-boot.
>
> Ben.
>
> --
> Ben Hutchings
> Software Developer, Codethink Ltd.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20180321/8fd73444/attachment.html>