Robert Marshall <robert.marshall@...>
Zoran, Zoran S <zoran.stojsavljevic.de@gmail.com> writes: Hello Chris,
And so li'll I have requested (namely this: console=ttySC0)! It does the magic... It works, man! Works with: uname -a Linux 192.168.15.189 4.4.120-cip20-rt13-dirty #2 SMP Tue Mar 13 15:21:30 GMT 2018 armv7l GNU/Linux
Within one day I set the whole iwg2x device type and iwg20m device forU-Boot and Lava V2: vagrant@stretch:~$ dpkg -l lava-server lava-dispatcher ||/ Name Version Architecture Description +++-=======================-================-================-===================================================
ii lava-dispatcher 2018.2.post2-1+s amd64 Linaro Automated Validation Architecture dispatcher ii lava-server 2018.2-1+stretch all Linaro Automated Validation Architecture server vagrant@stretch:~$
And I missed the one very small step for me, but very big for my Alter Ego Confidence... ;-)
And, yes, I did NOT try it with U-Boot, I went straight to VBox VM, to Lava 2018.2 and set all the ingredients (3 of them) in the iwg2x device type definition, namely in iwg2x.jinja2:
{% set console_device = console_device|default('ttySC0') %} {% set baud_rate = baud_rate|default(115200) %} {% set device_type = "iwg2x" %} {% set bootm_kernel_addr = '0x40007fc0' %} {% set bootm_ramdisk_addr = '0x41000000' %} {% set bootm_dtb_addr = '0x40f00000' %} {% set bootm_low = '0x41e00000' %} {% set bootm_size = '0x1000000' %} ...
It works (with difficulties) with the natively generated r8a7743-iwg20d-q7.dtb'.
Filename '149/tftp-deploy-rkMXw2/dtb/r8a7743-iwg20d-q7.dtb'. Load address: 0x40f00000 Loading: * T ## 3.9 KiB/s done Bytes transferred = 24725 (6095 hex) ## Loading init Ramdisk from Legacy Image at 41000000 ... Image Name: Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 5861271 Bytes = 5.6 MiB Load Address: 00000000 Entry Point: 00000000 ## 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 ...
Wow! Now, I am for last few days (few hours per day) trying (very unsuccessfully, sorry) to set Daniel's Sangorrin's: kas build kas-iwg20m.yml in my Vbox Fedora 24 generated environment, since I desperately need TRUE initramfs in order to make iwg20m rt-tests with cyclic (hackbench assisting in there)!
Here is the log of the native Lava shell test commands (the most important is uname -a): https://pastebin.com/LKfJs4mn
Here is the iwg20m smoking test log: https://pastebin.com/PWy4xWpG
I guess, Robert/Agustin Benito, we should close CIP testing issue #167, shouldn't we? ;-)
Let me see if I can replicate your success first. Thanks to both for the pointers! Robert Have all nice weekend! Zoran _______
On Fri, Mar 23, 2018 at 11:55 AM, Chris Paterson <Chris.Paterson2@renesas.com> wrote:
Hello Zoran,
Sorry for the slow response.
Could you try setting the following in u-boot?
setenv bootm_low '0x41e00000'
setenv bootm_size '0x1000000'
Looking at https://pastebin.com/AjRdTZKx, line 268, you are setting:
setenv bootargs 'console=ttyO0,115200n8 root=/dev/ram0 ip=dhcp';
I’m guessing the console should be set to ttySC0.
If you still see no output from the Kernel, have you tried enabling low-level debugging?
CONFIG_DEBUG_LL, CONFIG_DEBUG_RCAR_GEN2_SCIF0, CONFIG_EARLY_PRINTK
Kind regards, Chris
From: cip-dev-bounces@lists.cip-project.org [mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Zoran S Sent: 13 March 2018 16:26 To: Agustin Benito Bethencourt Codethink <agustin.benito@codethink.co.uk> Cc: cip-dev@lists.cip-project.org Subject: Re: [cip-dev] Progress on the CIP kernel maintenance and testing for your ELC talk
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@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-config/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-config/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@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@D is being updated to include the latest kernelci
Link: https://gitlab.com/cip-project/cip-testing/board-at-desk-single-dev/ merge_requests/53
* Work in progress to support Renesas iw20gm in B@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@D description and deploy.
Description: https://wiki.linuxfoundation.org/civilinfrastructureplatform/ ciptestingboardatdesksingledevfeaturepage
Deploy: 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@lists.cip-project.org https://lists.cip-project.org/mailman/listinfo/cip-dev
_______________________________________________ cip-dev mailing list cip-dev@lists.cip-project.org https://lists.cip-project.org/mailman/listinfo/cip-dev
|