Message ID | 1563181721-5055-1-git-send-email-chihmin.chao@sifive.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [v2] tests/boot_linux_console: add a test for riscv64 + virt | expand |
On 7/15/19 11:08 AM, Chih-Min Chao wrote: > Similar to the mips + malta test, it boots a Linux kernel on a virt > board and verify the serial is working. Also, it relies on the serial > device set by the machine itself. > > If riscv64 is a target being built, "make check-acceptance" will > automatically include this test by the use of the "arch:riscv64" tags. > > Alternatively, this test can be run using: > > $ avocado run -t arch:riscv64 tests/acceptance > > packages > debian official > binutils-riscv64-linux-gnu_2.32-8 > opensbi_0.4-1_all > linux-image-4.19.0-5-riscv64 4.19.37-4 > third-party > https://github.com/groeck/linux-build-test/rootfs/riscv64/rootfs.cpio.gz > (the repo is also used in mips target acceptance) > > Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com> > --- > .travis.yml | 2 +- > tests/acceptance/boot_linux_console.py | 66 ++++++++++++++++++++++++++++++++++ > 2 files changed, 67 insertions(+), 1 deletion(-) > > diff --git a/.travis.yml b/.travis.yml > index 5d3d6ee..21fcead 100644 > --- a/.travis.yml > +++ b/.travis.yml > @@ -232,7 +232,7 @@ matrix: > > # Acceptance (Functional) tests > - env: > - - CONFIG="--python=/usr/bin/python3 --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu" > + - CONFIG="--python=/usr/bin/python3 --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu,riscv64-softmmu" > - TEST_CMD="make check-acceptance" > after_failure: > - cat tests/results/latest/job.log > diff --git a/tests/acceptance/boot_linux_console.py b/tests/acceptance/boot_linux_console.py > index 3215950..0f638bc 100644 > --- a/tests/acceptance/boot_linux_console.py > +++ b/tests/acceptance/boot_linux_console.py > @@ -354,3 +354,69 @@ class BootLinuxConsole(Test): > self.vm.launch() > console_pattern = 'Kernel command line: %s' % kernel_command_line > self.wait_for_console_pattern(console_pattern) > + > + def test_riscv64_virt(self): > + """ > + :avocado: tags=arch:riscv64 > + :avocado: tags=machine:virt > + """ > + deb_url = ('https://snapshot.debian.org/archive/debian/' > + '20190424T171759Z/pool/main/b/binutils/' > + 'binutils-riscv64-linux-gnu_2.32-8_amd64.deb') > + deb_hash = ('7fe376fd4452696c03acd508d6d613ca553ea15e') > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) > + objcopy_path = '/usr/bin/riscv64-linux-gnu-objcopy' > + objcopy_path = self.extract_from_deb(deb_path, objcopy_path) > + libbfd_path = '/usr/lib/x86_64-linux-gnu/libbfd-2.32-riscv64.so' > + libbfd_path = self.extract_from_deb(deb_path, libbfd_path) > + process.run('ls -al %s' % (objcopy_path)) > + > + deb_url = ('https://snapshot.debian.org/archive/debian/' > + '20190708T032337Z/pool/main/o/opensbi/' > + 'opensbi_0.4-1_all.deb') > + deb_hash = ('2319dcd702958291d323acf5649fd98a11d90112') > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) > + opensbi_path = ('/usr/lib/riscv64-linux-gnu/opensbi/' > + 'qemu/virt/fw_jump.elf') > + opensbi_path = self.extract_from_deb(deb_path, opensbi_path) > + > + deb_url = ('https://snapshot.debian.org/archive/debian-ports/' > + '20190620T095935Z/pool-riscv64/main/l/linux/' > + 'linux-image-4.19.0-5-riscv64_4.19.37-4_riscv64.deb') > + deb_hash = ('bf5b5680c41d92134d22caef4fbd277c5217e1f0') > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) > + kernel_path = '/boot/vmlinux-4.19.0-5-riscv64' > + kernel_path = self.extract_from_deb(deb_path, kernel_path) > + kimage_path = self.workdir + "/Image" > + env = os.environ > + env['LD_LIBRARY_PATH'] = ('%s:' % (os.path.dirname(libbfd_path)) + > + env.get('LD_LIBRARY_PATH', '')) > + process.run(('%s -O binary -O binary -R' > + '.note -R .note.gnu.build-id -R .comment -S %s %s') % > + (objcopy_path, kernel_path, kimage_path)) Please explain why you need to do that... Also note these tests are run on other host architecture than x86, at least ppc64/s390x (so this won't work there). > + > + initrd_url = ('https://github.com/groeck/linux-build-test/raw/' > + '8584a59ed9e5eb5ee7ca91f6d74bbb06619205b8/rootfs/' > + 'riscv64/rootfs.cpio.gz') > + initrd_hash = 'f4867d263754961b6f626cdcdc0cb334c47e3b49' > + initrd_path = self.fetch_asset(initrd_url, asset_hash=initrd_hash) > + > + self.vm.set_machine('virt') > + self.vm.set_console() > + kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE > + + 'console=ttyS0 noreboot') > + self.vm.add_args('-bios', opensbi_path, > + '-kernel', kimage_path, > + '-initrd', initrd_path, > + '-append', kernel_command_line, > + '-no-reboot') > + > + self.vm.launch() > + self.wait_for_console_pattern('Boot successful.') > + > + self.exec_command_and_wait_for_pattern('cat /proc/cpuinfo', > + 'isa') > + self.exec_command_and_wait_for_pattern('uname -a', > + 'SMP Debian') > + self.exec_command_and_wait_for_pattern('reboot', > + 'reboot: Restarting system') >
On Mon, Jul 15, 2019 at 5:15 PM Philippe Mathieu-Daudé <philmd@redhat.com> wrote: > On 7/15/19 11:08 AM, Chih-Min Chao wrote: > > Similar to the mips + malta test, it boots a Linux kernel on a virt > > board and verify the serial is working. Also, it relies on the serial > > device set by the machine itself. > > > > If riscv64 is a target being built, "make check-acceptance" will > > automatically include this test by the use of the "arch:riscv64" tags. > > > > Alternatively, this test can be run using: > > > > $ avocado run -t arch:riscv64 tests/acceptance > > > > packages > > debian official > > binutils-riscv64-linux-gnu_2.32-8 > > opensbi_0.4-1_all > > linux-image-4.19.0-5-riscv64 4.19.37-4 > > third-party > > > https://github.com/groeck/linux-build-test/rootfs/riscv64/rootfs.cpio.gz > > (the repo is also used in mips target acceptance) > > > > Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com> > > --- > > .travis.yml | 2 +- > > tests/acceptance/boot_linux_console.py | 66 > ++++++++++++++++++++++++++++++++++ > > 2 files changed, 67 insertions(+), 1 deletion(-) > > > > diff --git a/.travis.yml b/.travis.yml > > index 5d3d6ee..21fcead 100644 > > --- a/.travis.yml > > +++ b/.travis.yml > > @@ -232,7 +232,7 @@ matrix: > > > > # Acceptance (Functional) tests > > - env: > > - - CONFIG="--python=/usr/bin/python3 > --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu" > > + - CONFIG="--python=/usr/bin/python3 > --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu,riscv64-softmmu" > > - TEST_CMD="make check-acceptance" > > after_failure: > > - cat tests/results/latest/job.log > > diff --git a/tests/acceptance/boot_linux_console.py > b/tests/acceptance/boot_linux_console.py > > index 3215950..0f638bc 100644 > > --- a/tests/acceptance/boot_linux_console.py > > +++ b/tests/acceptance/boot_linux_console.py > > @@ -354,3 +354,69 @@ class BootLinuxConsole(Test): > > self.vm.launch() > > console_pattern = 'Kernel command line: %s' % > kernel_command_line > > self.wait_for_console_pattern(console_pattern) > > + > > + def test_riscv64_virt(self): > > + """ > > + :avocado: tags=arch:riscv64 > > + :avocado: tags=machine:virt > > + """ > > + deb_url = ('https://snapshot.debian.org/archive/debian/' > > + '20190424T171759Z/pool/main/b/binutils/' > > + 'binutils-riscv64-linux-gnu_2.32-8_amd64.deb') > > + deb_hash = ('7fe376fd4452696c03acd508d6d613ca553ea15e') > > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) > > + objcopy_path = '/usr/bin/riscv64-linux-gnu-objcopy' > > + objcopy_path = self.extract_from_deb(deb_path, objcopy_path) > > + libbfd_path = '/usr/lib/x86_64-linux-gnu/libbfd-2.32-riscv64.so > ' > > + libbfd_path = self.extract_from_deb(deb_path, libbfd_path) > > + process.run('ls -al %s' % (objcopy_path)) > > + > > + deb_url = ('https://snapshot.debian.org/archive/debian/' > > + '20190708T032337Z/pool/main/o/opensbi/' > > + 'opensbi_0.4-1_all.deb') > > + deb_hash = ('2319dcd702958291d323acf5649fd98a11d90112') > > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) > > + opensbi_path = ('/usr/lib/riscv64-linux-gnu/opensbi/' > > + 'qemu/virt/fw_jump.elf') > > + opensbi_path = self.extract_from_deb(deb_path, opensbi_path) > > + > > + deb_url = ('https://snapshot.debian.org/archive/debian-ports/' > > + '20190620T095935Z/pool-riscv64/main/l/linux/' > > + 'linux-image-4.19.0-5-riscv64_4.19.37-4_riscv64.deb') > > + deb_hash = ('bf5b5680c41d92134d22caef4fbd277c5217e1f0') > > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) > > + kernel_path = '/boot/vmlinux-4.19.0-5-riscv64' > > + kernel_path = self.extract_from_deb(deb_path, kernel_path) > > + kimage_path = self.workdir + "/Image" > > + env = os.environ > > + env['LD_LIBRARY_PATH'] = ('%s:' % > (os.path.dirname(libbfd_path)) + > > + env.get('LD_LIBRARY_PATH', '')) > > + process.run(('%s -O binary -O binary -R' > > + '.note -R .note.gnu.build-id -R .comment -S %s > %s') % > > + (objcopy_path, kernel_path, kimage_path)) > > Please explain why you need to do that... > > Also note these tests are run on other host architecture than x86, at > least ppc64/s390x (so this won't work there). > > it is because riscv64 vmlinux doesn't have physical loading address information and depends on certain stage bootloader to move kernel raw data to specific physical address (0x8020_0000) The vmlinux program headers are Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x001000 0xffffffe000000000 0x0000000000000000 0x0303a6 0x0303a6 R E 0x1000 LOAD 0x032000 0xffffffe000031000 0x0000000000031000 0x828f0c 0x828f0c RWE 0x1000 NOTE 0x85aec0 0xffffffe000859ec0 0x0000000000859ec0 0x00004c 0x00004c R 0x4 For legacy bootloader, bbl, It can handle payload in ELF format. However, for the newer OpenSBI, it can only handle raw data and debian doesn't provide linux image in raw data format. > > + > > + initrd_url = ('https://github.com/groeck/linux-build-test/raw/' > > + '8584a59ed9e5eb5ee7ca91f6d74bbb06619205b8/rootfs/' > > + 'riscv64/rootfs.cpio.gz') > > + initrd_hash = 'f4867d263754961b6f626cdcdc0cb334c47e3b49' > > + initrd_path = self.fetch_asset(initrd_url, > asset_hash=initrd_hash) > > + > > + self.vm.set_machine('virt') > > + self.vm.set_console() > > + kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE > > + + 'console=ttyS0 noreboot') > > + self.vm.add_args('-bios', opensbi_path, > > + '-kernel', kimage_path, > > + '-initrd', initrd_path, > > + '-append', kernel_command_line, > > + '-no-reboot') > > + > > + self.vm.launch() > > + self.wait_for_console_pattern('Boot successful.') > > + > > + self.exec_command_and_wait_for_pattern('cat /proc/cpuinfo', > > + 'isa') > > + self.exec_command_and_wait_for_pattern('uname -a', > > + 'SMP Debian') > > + self.exec_command_and_wait_for_pattern('reboot', > > + 'reboot: Restarting > system') > > >
On 7/15/19 1:09 PM, Chih-Min Chao wrote: > On Mon, Jul 15, 2019 at 5:15 PM Philippe Mathieu-Daudé > <philmd@redhat.com <mailto:philmd@redhat.com>> wrote: > > On 7/15/19 11:08 AM, Chih-Min Chao wrote: > > Similar to the mips + malta test, it boots a Linux kernel on a virt > > board and verify the serial is working. Also, it relies on the serial > > device set by the machine itself. > > > > If riscv64 is a target being built, "make check-acceptance" will > > automatically include this test by the use of the "arch:riscv64" tags. > > > > Alternatively, this test can be run using: > > > > $ avocado run -t arch:riscv64 tests/acceptance > > > > packages > > debian official > > binutils-riscv64-linux-gnu_2.32-8 > > opensbi_0.4-1_all > > linux-image-4.19.0-5-riscv64 4.19.37-4 > > third-party > > > https://github.com/groeck/linux-build-test/rootfs/riscv64/rootfs.cpio.gz > > (the repo is also used in mips target acceptance) > > > > Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com > <mailto:chihmin.chao@sifive.com>> > > --- > > .travis.yml | 2 +- > > tests/acceptance/boot_linux_console.py | 66 > ++++++++++++++++++++++++++++++++++ > > 2 files changed, 67 insertions(+), 1 deletion(-) > > > > diff --git a/.travis.yml b/.travis.yml > > index 5d3d6ee..21fcead 100644 > > --- a/.travis.yml > > +++ b/.travis.yml > > @@ -232,7 +232,7 @@ matrix: > > > > # Acceptance (Functional) tests > > - env: > > - - CONFIG="--python=/usr/bin/python3 > --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu" > > + - CONFIG="--python=/usr/bin/python3 > --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu,riscv64-softmmu" > > - TEST_CMD="make check-acceptance" > > after_failure: > > - cat tests/results/latest/job.log > > diff --git a/tests/acceptance/boot_linux_console.py > b/tests/acceptance/boot_linux_console.py > > index 3215950..0f638bc 100644 > > --- a/tests/acceptance/boot_linux_console.py > > +++ b/tests/acceptance/boot_linux_console.py > > @@ -354,3 +354,69 @@ class BootLinuxConsole(Test): > > self.vm.launch() > > console_pattern = 'Kernel command line: %s' % > kernel_command_line > > self.wait_for_console_pattern(console_pattern) > > + > > + def test_riscv64_virt(self): > > + """ > > + :avocado: tags=arch:riscv64 > > + :avocado: tags=machine:virt > > + """ > > + deb_url = ('https://snapshot.debian.org/archive/debian/' > > + '20190424T171759Z/pool/main/b/binutils/' > > + > 'binutils-riscv64-linux-gnu_2.32-8_amd64.deb') > > + deb_hash = ('7fe376fd4452696c03acd508d6d613ca553ea15e') > > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) > > + objcopy_path = '/usr/bin/riscv64-linux-gnu-objcopy' > > + objcopy_path = self.extract_from_deb(deb_path, objcopy_path) > > + libbfd_path = > '/usr/lib/x86_64-linux-gnu/libbfd-2.32-riscv64.so > <http://libbfd-2.32-riscv64.so>' > > + libbfd_path = self.extract_from_deb(deb_path, libbfd_path) > > + process.run('ls -al %s' % (objcopy_path)) > > + > > + deb_url = ('https://snapshot.debian.org/archive/debian/' > > + '20190708T032337Z/pool/main/o/opensbi/' > > + 'opensbi_0.4-1_all.deb') > > + deb_hash = ('2319dcd702958291d323acf5649fd98a11d90112') > > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) > > + opensbi_path = ('/usr/lib/riscv64-linux-gnu/opensbi/' > > + 'qemu/virt/fw_jump.elf') > > + opensbi_path = self.extract_from_deb(deb_path, opensbi_path) > > + > > + deb_url = > ('https://snapshot.debian.org/archive/debian-ports/' > > + '20190620T095935Z/pool-riscv64/main/l/linux/' > > + > 'linux-image-4.19.0-5-riscv64_4.19.37-4_riscv64.deb') > > + deb_hash = ('bf5b5680c41d92134d22caef4fbd277c5217e1f0') > > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) > > + kernel_path = '/boot/vmlinux-4.19.0-5-riscv64' > > + kernel_path = self.extract_from_deb(deb_path, kernel_path) > > + kimage_path = self.workdir + "/Image" > > + env = os.environ > > + env['LD_LIBRARY_PATH'] = ('%s:' % > (os.path.dirname(libbfd_path)) + > > + env.get('LD_LIBRARY_PATH', '')) > > + process.run(('%s -O binary -O binary -R' > > + '.note -R .note.gnu.build-id -R .comment -S > %s %s') % > > + (objcopy_path, kernel_path, kimage_path)) > > Please explain why you need to do that... > > Also note these tests are run on other host architecture than x86, at > least ppc64/s390x (so this won't work there). > > it is because riscv64 vmlinux doesn't have physical loading address > information and > depends on certain stage bootloader to move kernel raw data to specific > physical address (0x8020_0000) > > The vmlinux program headers are > Type Offset VirtAddr PhysAddr > FileSiz MemSiz Flg Align > LOAD 0x001000 0xffffffe000000000 0x0000000000000000 0x0303a6 > 0x0303a6 R E 0x1000 > LOAD 0x032000 0xffffffe000031000 0x0000000000031000 0x828f0c > 0x828f0c RWE 0x1000 > NOTE 0x85aec0 0xffffffe000859ec0 0x0000000000859ec0 0x00004c > 0x00004c R 0x4 > > For legacy bootloader, bbl, It can handle payload in ELF format. > However, for the newer OpenSBI, it can only handle raw data and > debian doesn't provide linux image in raw data format. I think you should be able to use -device loader,file=... here, then no need to use objcopy. Cc'ing Alistair who is an expert on this. > > + > > + initrd_url = > ('https://github.com/groeck/linux-build-test/raw/' > > + > '8584a59ed9e5eb5ee7ca91f6d74bbb06619205b8/rootfs/' > > + 'riscv64/rootfs.cpio.gz') > > + initrd_hash = 'f4867d263754961b6f626cdcdc0cb334c47e3b49' > > + initrd_path = self.fetch_asset(initrd_url, > asset_hash=initrd_hash) > > + > > + self.vm.set_machine('virt') > > + self.vm.set_console() > > + kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE > > + + 'console=ttyS0 noreboot') > > + self.vm.add_args('-bios', opensbi_path, > > + '-kernel', kimage_path, > > + '-initrd', initrd_path, > > + '-append', kernel_command_line, > > + '-no-reboot') > > + > > + self.vm.launch() > > + self.wait_for_console_pattern('Boot successful.') > > + > > + self.exec_command_and_wait_for_pattern('cat /proc/cpuinfo', > > + 'isa') > > + self.exec_command_and_wait_for_pattern('uname -a', > > + 'SMP Debian') > > + self.exec_command_and_wait_for_pattern('reboot', > > + 'reboot: > Restarting system') > > >
On Mon, Jul 15, 2019 at 6:02 AM Philippe Mathieu-Daudé <philmd@redhat.com> wrote: > > On 7/15/19 1:09 PM, Chih-Min Chao wrote: > > On Mon, Jul 15, 2019 at 5:15 PM Philippe Mathieu-Daudé > > <philmd@redhat.com <mailto:philmd@redhat.com>> wrote: > > > > On 7/15/19 11:08 AM, Chih-Min Chao wrote: > > > Similar to the mips + malta test, it boots a Linux kernel on a virt > > > board and verify the serial is working. Also, it relies on the serial > > > device set by the machine itself. > > > > > > If riscv64 is a target being built, "make check-acceptance" will > > > automatically include this test by the use of the "arch:riscv64" tags. > > > > > > Alternatively, this test can be run using: > > > > > > $ avocado run -t arch:riscv64 tests/acceptance > > > > > > packages > > > debian official > > > binutils-riscv64-linux-gnu_2.32-8 > > > opensbi_0.4-1_all > > > linux-image-4.19.0-5-riscv64 4.19.37-4 > > > third-party > > > > > https://github.com/groeck/linux-build-test/rootfs/riscv64/rootfs.cpio.gz > > > (the repo is also used in mips target acceptance) > > > > > > Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com > > <mailto:chihmin.chao@sifive.com>> > > > --- > > > .travis.yml | 2 +- > > > tests/acceptance/boot_linux_console.py | 66 > > ++++++++++++++++++++++++++++++++++ > > > 2 files changed, 67 insertions(+), 1 deletion(-) > > > > > > diff --git a/.travis.yml b/.travis.yml > > > index 5d3d6ee..21fcead 100644 > > > --- a/.travis.yml > > > +++ b/.travis.yml > > > @@ -232,7 +232,7 @@ matrix: > > > > > > # Acceptance (Functional) tests > > > - env: > > > - - CONFIG="--python=/usr/bin/python3 > > --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu" > > > + - CONFIG="--python=/usr/bin/python3 > > --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu,riscv64-softmmu" > > > - TEST_CMD="make check-acceptance" > > > after_failure: > > > - cat tests/results/latest/job.log > > > diff --git a/tests/acceptance/boot_linux_console.py > > b/tests/acceptance/boot_linux_console.py > > > index 3215950..0f638bc 100644 > > > --- a/tests/acceptance/boot_linux_console.py > > > +++ b/tests/acceptance/boot_linux_console.py > > > @@ -354,3 +354,69 @@ class BootLinuxConsole(Test): > > > self.vm.launch() > > > console_pattern = 'Kernel command line: %s' % > > kernel_command_line > > > self.wait_for_console_pattern(console_pattern) > > > + > > > + def test_riscv64_virt(self): > > > + """ > > > + :avocado: tags=arch:riscv64 > > > + :avocado: tags=machine:virt > > > + """ > > > + deb_url = ('https://snapshot.debian.org/archive/debian/' > > > + '20190424T171759Z/pool/main/b/binutils/' > > > + > > 'binutils-riscv64-linux-gnu_2.32-8_amd64.deb') > > > + deb_hash = ('7fe376fd4452696c03acd508d6d613ca553ea15e') > > > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) > > > + objcopy_path = '/usr/bin/riscv64-linux-gnu-objcopy' > > > + objcopy_path = self.extract_from_deb(deb_path, objcopy_path) > > > + libbfd_path = > > '/usr/lib/x86_64-linux-gnu/libbfd-2.32-riscv64.so > > <http://libbfd-2.32-riscv64.so>' > > > + libbfd_path = self.extract_from_deb(deb_path, libbfd_path) > > > + process.run('ls -al %s' % (objcopy_path)) > > > + > > > + deb_url = ('https://snapshot.debian.org/archive/debian/' > > > + '20190708T032337Z/pool/main/o/opensbi/' > > > + 'opensbi_0.4-1_all.deb') > > > + deb_hash = ('2319dcd702958291d323acf5649fd98a11d90112') > > > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) > > > + opensbi_path = ('/usr/lib/riscv64-linux-gnu/opensbi/' > > > + 'qemu/virt/fw_jump.elf') > > > + opensbi_path = self.extract_from_deb(deb_path, opensbi_path) > > > + > > > + deb_url = > > ('https://snapshot.debian.org/archive/debian-ports/' > > > + '20190620T095935Z/pool-riscv64/main/l/linux/' > > > + > > 'linux-image-4.19.0-5-riscv64_4.19.37-4_riscv64.deb') > > > + deb_hash = ('bf5b5680c41d92134d22caef4fbd277c5217e1f0') > > > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) > > > + kernel_path = '/boot/vmlinux-4.19.0-5-riscv64' > > > + kernel_path = self.extract_from_deb(deb_path, kernel_path) > > > + kimage_path = self.workdir + "/Image" > > > + env = os.environ > > > + env['LD_LIBRARY_PATH'] = ('%s:' % > > (os.path.dirname(libbfd_path)) + > > > + env.get('LD_LIBRARY_PATH', '')) > > > + process.run(('%s -O binary -O binary -R' > > > + '.note -R .note.gnu.build-id -R .comment -S > > %s %s') % > > > + (objcopy_path, kernel_path, kimage_path)) > > > > Please explain why you need to do that... > > > > Also note these tests are run on other host architecture than x86, at > > least ppc64/s390x (so this won't work there). > > > > it is because riscv64 vmlinux doesn't have physical loading address > > information and > > depends on certain stage bootloader to move kernel raw data to specific > > physical address (0x8020_0000) > > > > The vmlinux program headers are > > Type Offset VirtAddr PhysAddr > > FileSiz MemSiz Flg Align > > LOAD 0x001000 0xffffffe000000000 0x0000000000000000 0x0303a6 > > 0x0303a6 R E 0x1000 > > LOAD 0x032000 0xffffffe000031000 0x0000000000031000 0x828f0c > > 0x828f0c RWE 0x1000 > > NOTE 0x85aec0 0xffffffe000859ec0 0x0000000000859ec0 0x00004c > > 0x00004c R 0x4 > > > > For legacy bootloader, bbl, It can handle payload in ELF format. > > However, for the newer OpenSBI, it can only handle raw data and > > debian doesn't provide linux image in raw data format. This doesn't sound right. You should just be able to say -kernel <anything> and it should work. It has worked for me with vmlinux and Image files when using master (not the 4.0 release but master/4.1). Although all of my testing was with the 5.1 kernel, so maybe there is a difference there? What isn't working for you? Can you include the errors and output of -d in_asm? Alistair > > I think you should be able to use -device loader,file=... here, then no > need to use objcopy. > > Cc'ing Alistair who is an expert on this. > > > > + > > > + initrd_url = > > ('https://github.com/groeck/linux-build-test/raw/' > > > + > > '8584a59ed9e5eb5ee7ca91f6d74bbb06619205b8/rootfs/' > > > + 'riscv64/rootfs.cpio.gz') > > > + initrd_hash = 'f4867d263754961b6f626cdcdc0cb334c47e3b49' > > > + initrd_path = self.fetch_asset(initrd_url, > > asset_hash=initrd_hash) > > > + > > > + self.vm.set_machine('virt') > > > + self.vm.set_console() > > > + kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE > > > + + 'console=ttyS0 noreboot') > > > + self.vm.add_args('-bios', opensbi_path, > > > + '-kernel', kimage_path, > > > + '-initrd', initrd_path, > > > + '-append', kernel_command_line, > > > + '-no-reboot') > > > + > > > + self.vm.launch() > > > + self.wait_for_console_pattern('Boot successful.') > > > + > > > + self.exec_command_and_wait_for_pattern('cat /proc/cpuinfo', > > > + 'isa') > > > + self.exec_command_and_wait_for_pattern('uname -a', > > > + 'SMP Debian') > > > + self.exec_command_and_wait_for_pattern('reboot', > > > + 'reboot: > > Restarting system') > > > > > >
On Tue, Jul 16, 2019 at 12:34 AM Alistair Francis <alistair23@gmail.com> wrote: > On Mon, Jul 15, 2019 at 6:02 AM Philippe Mathieu-Daudé > <philmd@redhat.com> wrote: > > > > On 7/15/19 1:09 PM, Chih-Min Chao wrote: > > > On Mon, Jul 15, 2019 at 5:15 PM Philippe Mathieu-Daudé > > > <philmd@redhat.com <mailto:philmd@redhat.com>> wrote: > > > > > > On 7/15/19 11:08 AM, Chih-Min Chao wrote: > > > > Similar to the mips + malta test, it boots a Linux kernel on a > virt > > > > board and verify the serial is working. Also, it relies on the > serial > > > > device set by the machine itself. > > > > > > > > If riscv64 is a target being built, "make check-acceptance" will > > > > automatically include this test by the use of the "arch:riscv64" > tags. > > > > > > > > Alternatively, this test can be run using: > > > > > > > > $ avocado run -t arch:riscv64 tests/acceptance > > > > > > > > packages > > > > debian official > > > > binutils-riscv64-linux-gnu_2.32-8 > > > > opensbi_0.4-1_all > > > > linux-image-4.19.0-5-riscv64 4.19.37-4 > > > > third-party > > > > > > > > https://github.com/groeck/linux-build-test/rootfs/riscv64/rootfs.cpio.gz > > > > (the repo is also used in mips target acceptance) > > > > > > > > Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com > > > <mailto:chihmin.chao@sifive.com>> > > > > --- > > > > .travis.yml | 2 +- > > > > tests/acceptance/boot_linux_console.py | 66 > > > ++++++++++++++++++++++++++++++++++ > > > > 2 files changed, 67 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/.travis.yml b/.travis.yml > > > > index 5d3d6ee..21fcead 100644 > > > > --- a/.travis.yml > > > > +++ b/.travis.yml > > > > @@ -232,7 +232,7 @@ matrix: > > > > > > > > # Acceptance (Functional) tests > > > > - env: > > > > - - CONFIG="--python=/usr/bin/python3 > > > > --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu" > > > > + - CONFIG="--python=/usr/bin/python3 > > > > --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu,riscv64-softmmu" > > > > - TEST_CMD="make check-acceptance" > > > > after_failure: > > > > - cat tests/results/latest/job.log > > > > diff --git a/tests/acceptance/boot_linux_console.py > > > b/tests/acceptance/boot_linux_console.py > > > > index 3215950..0f638bc 100644 > > > > --- a/tests/acceptance/boot_linux_console.py > > > > +++ b/tests/acceptance/boot_linux_console.py > > > > @@ -354,3 +354,69 @@ class BootLinuxConsole(Test): > > > > self.vm.launch() > > > > console_pattern = 'Kernel command line: %s' % > > > kernel_command_line > > > > self.wait_for_console_pattern(console_pattern) > > > > + > > > > + def test_riscv64_virt(self): > > > > + """ > > > > + :avocado: tags=arch:riscv64 > > > > + :avocado: tags=machine:virt > > > > + """ > > > > + deb_url = ('https://snapshot.debian.org/archive/debian/ > ' > > > > + > '20190424T171759Z/pool/main/b/binutils/' > > > > + > > > 'binutils-riscv64-linux-gnu_2.32-8_amd64.deb') > > > > + deb_hash = ('7fe376fd4452696c03acd508d6d613ca553ea15e') > > > > + deb_path = self.fetch_asset(deb_url, > asset_hash=deb_hash) > > > > + objcopy_path = '/usr/bin/riscv64-linux-gnu-objcopy' > > > > + objcopy_path = self.extract_from_deb(deb_path, > objcopy_path) > > > > + libbfd_path = > > > '/usr/lib/x86_64-linux-gnu/libbfd-2.32-riscv64.so > > > <http://libbfd-2.32-riscv64.so>' > > > > + libbfd_path = self.extract_from_deb(deb_path, > libbfd_path) > > > > + process.run('ls -al %s' % (objcopy_path)) > > > > + > > > > + deb_url = ('https://snapshot.debian.org/archive/debian/ > ' > > > > + '20190708T032337Z/pool/main/o/opensbi/' > > > > + 'opensbi_0.4-1_all.deb') > > > > + deb_hash = ('2319dcd702958291d323acf5649fd98a11d90112') > > > > + deb_path = self.fetch_asset(deb_url, > asset_hash=deb_hash) > > > > + opensbi_path = ('/usr/lib/riscv64-linux-gnu/opensbi/' > > > > + 'qemu/virt/fw_jump.elf') > > > > + opensbi_path = self.extract_from_deb(deb_path, > opensbi_path) > > > > + > > > > + deb_url = > > > ('https://snapshot.debian.org/archive/debian-ports/' > > > > + '20190620T095935Z/pool-riscv64/main/l/linux/' > > > > + > > > 'linux-image-4.19.0-5-riscv64_4.19.37-4_riscv64.deb') > > > > + deb_hash = ('bf5b5680c41d92134d22caef4fbd277c5217e1f0') > > > > + deb_path = self.fetch_asset(deb_url, > asset_hash=deb_hash) > > > > + kernel_path = '/boot/vmlinux-4.19.0-5-riscv64' > > > > + kernel_path = self.extract_from_deb(deb_path, > kernel_path) > > > > + kimage_path = self.workdir + "/Image" > > > > + env = os.environ > > > > + env['LD_LIBRARY_PATH'] = ('%s:' % > > > (os.path.dirname(libbfd_path)) + > > > > + env.get('LD_LIBRARY_PATH', '')) > > > > + process.run(('%s -O binary -O binary -R' > > > > + '.note -R .note.gnu.build-id -R .comment -S > > > %s %s') % > > > > + (objcopy_path, kernel_path, kimage_path)) > > > > > > Please explain why you need to do that... > > > > > > Also note these tests are run on other host architecture than x86, > at > > > least ppc64/s390x (so this won't work there). > > > > > > it is because riscv64 vmlinux doesn't have physical loading address > > > information and > > > depends on certain stage bootloader to move kernel raw data to specific > > > physical address (0x8020_0000) > > > > > > The vmlinux program headers are > > > Type Offset VirtAddr PhysAddr > > > FileSiz MemSiz Flg Align > > > LOAD 0x001000 0xffffffe000000000 0x0000000000000000 > 0x0303a6 > > > 0x0303a6 R E 0x1000 > > > LOAD 0x032000 0xffffffe000031000 0x0000000000031000 > 0x828f0c > > > 0x828f0c RWE 0x1000 > > > NOTE 0x85aec0 0xffffffe000859ec0 0x0000000000859ec0 > 0x00004c > > > 0x00004c R 0x4 > > > > > > For legacy bootloader, bbl, It can handle payload in ELF format. > > > However, for the newer OpenSBI, it can only handle raw data and > > > debian doesn't provide linux image in raw data format. > > This doesn't sound right. You should just be able to say -kernel > <anything> and it should work. It has worked for me with vmlinux and > Image files when using master (not the 4.0 release but master/4.1). > Although all of my testing was with the 5.1 kernel, so maybe there is > a difference there? > > What isn't working for you? Can you include the errors and output of -d > in_asm? > > > Alistair > Hi Alistair, I have come across error before starting target simulation. What I means is to execute qemu-system-riscv64 -M virt -m 256M -nographic -bios ./opensbi/build/platform/qemu/virt/firmware/fw_jump.elf -kernel vmlinux then get the error message rom: requested regions overlap (rom mrom.reset. free=0x000000000001eb7c, addr=0x0000000000001000) qemu-system-riscv64: rom check and register reset failed chihmin.chao > > > > I think you should be able to use -device loader,file=... here, then no > > need to use objcopy. > > > > Cc'ing Alistair who is an expert on this. > > > > > > + > > > > + initrd_url = > > > ('https://github.com/groeck/linux-build-test/raw/' > > > > + > > > '8584a59ed9e5eb5ee7ca91f6d74bbb06619205b8/rootfs/' > > > > + 'riscv64/rootfs.cpio.gz') > > > > + initrd_hash = 'f4867d263754961b6f626cdcdc0cb334c47e3b49' > > > > + initrd_path = self.fetch_asset(initrd_url, > > > asset_hash=initrd_hash) > > > > + > > > > + self.vm.set_machine('virt') > > > > + self.vm.set_console() > > > > + kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE > > > > + + 'console=ttyS0 noreboot') > > > > + self.vm.add_args('-bios', opensbi_path, > > > > + '-kernel', kimage_path, > > > > + '-initrd', initrd_path, > > > > + '-append', kernel_command_line, > > > > + '-no-reboot') > > > > + > > > > + self.vm.launch() > > > > + self.wait_for_console_pattern('Boot successful.') > > > > + > > > > + self.exec_command_and_wait_for_pattern('cat > /proc/cpuinfo', > > > > + 'isa') > > > > + self.exec_command_and_wait_for_pattern('uname -a', > > > > + 'SMP Debian') > > > > + self.exec_command_and_wait_for_pattern('reboot', > > > > + 'reboot: > > > Restarting system') > > > > > > > > > >
On Tue, Jul 16, 2019 at 6:56 AM Chih-Min Chao <chihmin.chao@sifive.com> wrote: > > > On Tue, Jul 16, 2019 at 12:34 AM Alistair Francis <alistair23@gmail.com> wrote: >> >> On Mon, Jul 15, 2019 at 6:02 AM Philippe Mathieu-Daudé >> <philmd@redhat.com> wrote: >> > >> > On 7/15/19 1:09 PM, Chih-Min Chao wrote: >> > > On Mon, Jul 15, 2019 at 5:15 PM Philippe Mathieu-Daudé >> > > <philmd@redhat.com <mailto:philmd@redhat.com>> wrote: >> > > >> > > On 7/15/19 11:08 AM, Chih-Min Chao wrote: >> > > > Similar to the mips + malta test, it boots a Linux kernel on a virt >> > > > board and verify the serial is working. Also, it relies on the serial >> > > > device set by the machine itself. >> > > > >> > > > If riscv64 is a target being built, "make check-acceptance" will >> > > > automatically include this test by the use of the "arch:riscv64" tags. >> > > > >> > > > Alternatively, this test can be run using: >> > > > >> > > > $ avocado run -t arch:riscv64 tests/acceptance >> > > > >> > > > packages >> > > > debian official >> > > > binutils-riscv64-linux-gnu_2.32-8 >> > > > opensbi_0.4-1_all >> > > > linux-image-4.19.0-5-riscv64 4.19.37-4 >> > > > third-party >> > > > >> > > https://github.com/groeck/linux-build-test/rootfs/riscv64/rootfs.cpio.gz >> > > > (the repo is also used in mips target acceptance) >> > > > >> > > > Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com >> > > <mailto:chihmin.chao@sifive.com>> >> > > > --- >> > > > .travis.yml | 2 +- >> > > > tests/acceptance/boot_linux_console.py | 66 >> > > ++++++++++++++++++++++++++++++++++ >> > > > 2 files changed, 67 insertions(+), 1 deletion(-) >> > > > >> > > > diff --git a/.travis.yml b/.travis.yml >> > > > index 5d3d6ee..21fcead 100644 >> > > > --- a/.travis.yml >> > > > +++ b/.travis.yml >> > > > @@ -232,7 +232,7 @@ matrix: >> > > > >> > > > # Acceptance (Functional) tests >> > > > - env: >> > > > - - CONFIG="--python=/usr/bin/python3 >> > > --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu" >> > > > + - CONFIG="--python=/usr/bin/python3 >> > > --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu,riscv64-softmmu" >> > > > - TEST_CMD="make check-acceptance" >> > > > after_failure: >> > > > - cat tests/results/latest/job.log >> > > > diff --git a/tests/acceptance/boot_linux_console.py >> > > b/tests/acceptance/boot_linux_console.py >> > > > index 3215950..0f638bc 100644 >> > > > --- a/tests/acceptance/boot_linux_console.py >> > > > +++ b/tests/acceptance/boot_linux_console.py >> > > > @@ -354,3 +354,69 @@ class BootLinuxConsole(Test): >> > > > self.vm.launch() >> > > > console_pattern = 'Kernel command line: %s' % >> > > kernel_command_line >> > > > self.wait_for_console_pattern(console_pattern) >> > > > + >> > > > + def test_riscv64_virt(self): >> > > > + """ >> > > > + :avocado: tags=arch:riscv64 >> > > > + :avocado: tags=machine:virt >> > > > + """ >> > > > + deb_url = ('https://snapshot.debian.org/archive/debian/' >> > > > + '20190424T171759Z/pool/main/b/binutils/' >> > > > + >> > > 'binutils-riscv64-linux-gnu_2.32-8_amd64.deb') >> > > > + deb_hash = ('7fe376fd4452696c03acd508d6d613ca553ea15e') >> > > > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) >> > > > + objcopy_path = '/usr/bin/riscv64-linux-gnu-objcopy' >> > > > + objcopy_path = self.extract_from_deb(deb_path, objcopy_path) >> > > > + libbfd_path = >> > > '/usr/lib/x86_64-linux-gnu/libbfd-2.32-riscv64.so >> > > <http://libbfd-2.32-riscv64.so>' >> > > > + libbfd_path = self.extract_from_deb(deb_path, libbfd_path) >> > > > + process.run('ls -al %s' % (objcopy_path)) >> > > > + >> > > > + deb_url = ('https://snapshot.debian.org/archive/debian/' >> > > > + '20190708T032337Z/pool/main/o/opensbi/' >> > > > + 'opensbi_0.4-1_all.deb') >> > > > + deb_hash = ('2319dcd702958291d323acf5649fd98a11d90112') >> > > > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) >> > > > + opensbi_path = ('/usr/lib/riscv64-linux-gnu/opensbi/' >> > > > + 'qemu/virt/fw_jump.elf') >> > > > + opensbi_path = self.extract_from_deb(deb_path, opensbi_path) >> > > > + >> > > > + deb_url = >> > > ('https://snapshot.debian.org/archive/debian-ports/' >> > > > + '20190620T095935Z/pool-riscv64/main/l/linux/' >> > > > + >> > > 'linux-image-4.19.0-5-riscv64_4.19.37-4_riscv64.deb') >> > > > + deb_hash = ('bf5b5680c41d92134d22caef4fbd277c5217e1f0') >> > > > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) >> > > > + kernel_path = '/boot/vmlinux-4.19.0-5-riscv64' >> > > > + kernel_path = self.extract_from_deb(deb_path, kernel_path) >> > > > + kimage_path = self.workdir + "/Image" >> > > > + env = os.environ >> > > > + env['LD_LIBRARY_PATH'] = ('%s:' % >> > > (os.path.dirname(libbfd_path)) + >> > > > + env.get('LD_LIBRARY_PATH', '')) >> > > > + process.run(('%s -O binary -O binary -R' >> > > > + '.note -R .note.gnu.build-id -R .comment -S >> > > %s %s') % >> > > > + (objcopy_path, kernel_path, kimage_path)) >> > > >> > > Please explain why you need to do that... >> > > >> > > Also note these tests are run on other host architecture than x86, at >> > > least ppc64/s390x (so this won't work there). >> > > >> > > it is because riscv64 vmlinux doesn't have physical loading address >> > > information and >> > > depends on certain stage bootloader to move kernel raw data to specific >> > > physical address (0x8020_0000) >> > > >> > > The vmlinux program headers are >> > > Type Offset VirtAddr PhysAddr >> > > FileSiz MemSiz Flg Align >> > > LOAD 0x001000 0xffffffe000000000 0x0000000000000000 0x0303a6 >> > > 0x0303a6 R E 0x1000 >> > > LOAD 0x032000 0xffffffe000031000 0x0000000000031000 0x828f0c >> > > 0x828f0c RWE 0x1000 >> > > NOTE 0x85aec0 0xffffffe000859ec0 0x0000000000859ec0 0x00004c >> > > 0x00004c R 0x4 >> > > >> > > For legacy bootloader, bbl, It can handle payload in ELF format. >> > > However, for the newer OpenSBI, it can only handle raw data and >> > > debian doesn't provide linux image in raw data format. >> >> This doesn't sound right. You should just be able to say -kernel >> <anything> and it should work. It has worked for me with vmlinux and >> Image files when using master (not the 4.0 release but master/4.1). >> Although all of my testing was with the 5.1 kernel, so maybe there is >> a difference there? >> >> What isn't working for you? Can you include the errors and output of -d in_asm? >> >> >> Alistair > > > Hi Alistair, > I have come across error before starting target simulation. What I means is to execute > qemu-system-riscv64 -M virt -m 256M -nographic -bios ./opensbi/build/platform/qemu/virt/firmware/fw_jump.elf -kernel vmlinux > then get the error message > rom: requested regions overlap (rom mrom.reset. free=0x000000000001eb7c, addr=0x0000000000001000) > qemu-system-riscv64: rom check and register reset failed Hmmm.... I don't remember seeing this problem in my testing, but it does seem to make sense. We have two options here: 1. Use the Image file from Linux 5.0+ (my preferred option as 4.19 is getting old) 2. Use the device loader (documented here: https://github.com/riscv/opensbi/blob/master/docs/platform/qemu_virt.md) Alistair
On 7/16/19 10:43 PM, Alistair Francis wrote: > On Tue, Jul 16, 2019 at 6:56 AM Chih-Min Chao <chihmin.chao@sifive.com> wrote: >> >> >> On Tue, Jul 16, 2019 at 12:34 AM Alistair Francis <alistair23@gmail.com> wrote: >>> >>> On Mon, Jul 15, 2019 at 6:02 AM Philippe Mathieu-Daudé >>> <philmd@redhat.com> wrote: >>>> >>>> On 7/15/19 1:09 PM, Chih-Min Chao wrote: >>>>> On Mon, Jul 15, 2019 at 5:15 PM Philippe Mathieu-Daudé >>>>> <philmd@redhat.com <mailto:philmd@redhat.com>> wrote: >>>>> >>>>> On 7/15/19 11:08 AM, Chih-Min Chao wrote: >>>>> > Similar to the mips + malta test, it boots a Linux kernel on a virt >>>>> > board and verify the serial is working. Also, it relies on the serial >>>>> > device set by the machine itself. >>>>> > >>>>> > If riscv64 is a target being built, "make check-acceptance" will >>>>> > automatically include this test by the use of the "arch:riscv64" tags. >>>>> > >>>>> > Alternatively, this test can be run using: >>>>> > >>>>> > $ avocado run -t arch:riscv64 tests/acceptance >>>>> > >>>>> > packages >>>>> > debian official >>>>> > binutils-riscv64-linux-gnu_2.32-8 >>>>> > opensbi_0.4-1_all >>>>> > linux-image-4.19.0-5-riscv64 4.19.37-4 >>>>> > third-party >>>>> > >>>>> https://github.com/groeck/linux-build-test/rootfs/riscv64/rootfs.cpio.gz >>>>> > (the repo is also used in mips target acceptance) >>>>> > >>>>> > Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com >>>>> <mailto:chihmin.chao@sifive.com>> >>>>> > --- >>>>> > .travis.yml | 2 +- >>>>> > tests/acceptance/boot_linux_console.py | 66 >>>>> ++++++++++++++++++++++++++++++++++ >>>>> > 2 files changed, 67 insertions(+), 1 deletion(-) >>>>> > >>>>> > diff --git a/.travis.yml b/.travis.yml >>>>> > index 5d3d6ee..21fcead 100644 >>>>> > --- a/.travis.yml >>>>> > +++ b/.travis.yml >>>>> > @@ -232,7 +232,7 @@ matrix: >>>>> > >>>>> > # Acceptance (Functional) tests >>>>> > - env: >>>>> > - - CONFIG="--python=/usr/bin/python3 >>>>> --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu" >>>>> > + - CONFIG="--python=/usr/bin/python3 >>>>> --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu,riscv64-softmmu" >>>>> > - TEST_CMD="make check-acceptance" >>>>> > after_failure: >>>>> > - cat tests/results/latest/job.log >>>>> > diff --git a/tests/acceptance/boot_linux_console.py >>>>> b/tests/acceptance/boot_linux_console.py >>>>> > index 3215950..0f638bc 100644 >>>>> > --- a/tests/acceptance/boot_linux_console.py >>>>> > +++ b/tests/acceptance/boot_linux_console.py >>>>> > @@ -354,3 +354,69 @@ class BootLinuxConsole(Test): >>>>> > self.vm.launch() >>>>> > console_pattern = 'Kernel command line: %s' % >>>>> kernel_command_line >>>>> > self.wait_for_console_pattern(console_pattern) >>>>> > + >>>>> > + def test_riscv64_virt(self): >>>>> > + """ >>>>> > + :avocado: tags=arch:riscv64 >>>>> > + :avocado: tags=machine:virt >>>>> > + """ >>>>> > + deb_url = ('https://snapshot.debian.org/archive/debian/' >>>>> > + '20190424T171759Z/pool/main/b/binutils/' >>>>> > + >>>>> 'binutils-riscv64-linux-gnu_2.32-8_amd64.deb') >>>>> > + deb_hash = ('7fe376fd4452696c03acd508d6d613ca553ea15e') >>>>> > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) >>>>> > + objcopy_path = '/usr/bin/riscv64-linux-gnu-objcopy' >>>>> > + objcopy_path = self.extract_from_deb(deb_path, objcopy_path) >>>>> > + libbfd_path = >>>>> '/usr/lib/x86_64-linux-gnu/libbfd-2.32-riscv64.so >>>>> <http://libbfd-2.32-riscv64.so>' >>>>> > + libbfd_path = self.extract_from_deb(deb_path, libbfd_path) >>>>> > + process.run('ls -al %s' % (objcopy_path)) >>>>> > + >>>>> > + deb_url = ('https://snapshot.debian.org/archive/debian/' >>>>> > + '20190708T032337Z/pool/main/o/opensbi/' >>>>> > + 'opensbi_0.4-1_all.deb') >>>>> > + deb_hash = ('2319dcd702958291d323acf5649fd98a11d90112') >>>>> > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) >>>>> > + opensbi_path = ('/usr/lib/riscv64-linux-gnu/opensbi/' >>>>> > + 'qemu/virt/fw_jump.elf') >>>>> > + opensbi_path = self.extract_from_deb(deb_path, opensbi_path) >>>>> > + >>>>> > + deb_url = >>>>> ('https://snapshot.debian.org/archive/debian-ports/' >>>>> > + '20190620T095935Z/pool-riscv64/main/l/linux/' >>>>> > + >>>>> 'linux-image-4.19.0-5-riscv64_4.19.37-4_riscv64.deb') >>>>> > + deb_hash = ('bf5b5680c41d92134d22caef4fbd277c5217e1f0') >>>>> > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) >>>>> > + kernel_path = '/boot/vmlinux-4.19.0-5-riscv64' >>>>> > + kernel_path = self.extract_from_deb(deb_path, kernel_path) >>>>> > + kimage_path = self.workdir + "/Image" >>>>> > + env = os.environ >>>>> > + env['LD_LIBRARY_PATH'] = ('%s:' % >>>>> (os.path.dirname(libbfd_path)) + >>>>> > + env.get('LD_LIBRARY_PATH', '')) >>>>> > + process.run(('%s -O binary -O binary -R' >>>>> > + '.note -R .note.gnu.build-id -R .comment -S >>>>> %s %s') % >>>>> > + (objcopy_path, kernel_path, kimage_path)) >>>>> >>>>> Please explain why you need to do that... >>>>> >>>>> Also note these tests are run on other host architecture than x86, at >>>>> least ppc64/s390x (so this won't work there). >>>>> >>>>> it is because riscv64 vmlinux doesn't have physical loading address >>>>> information and >>>>> depends on certain stage bootloader to move kernel raw data to specific >>>>> physical address (0x8020_0000) >>>>> >>>>> The vmlinux program headers are >>>>> Type Offset VirtAddr PhysAddr >>>>> FileSiz MemSiz Flg Align >>>>> LOAD 0x001000 0xffffffe000000000 0x0000000000000000 0x0303a6 >>>>> 0x0303a6 R E 0x1000 >>>>> LOAD 0x032000 0xffffffe000031000 0x0000000000031000 0x828f0c >>>>> 0x828f0c RWE 0x1000 >>>>> NOTE 0x85aec0 0xffffffe000859ec0 0x0000000000859ec0 0x00004c >>>>> 0x00004c R 0x4 >>>>> >>>>> For legacy bootloader, bbl, It can handle payload in ELF format. >>>>> However, for the newer OpenSBI, it can only handle raw data and >>>>> debian doesn't provide linux image in raw data format. >>> >>> This doesn't sound right. You should just be able to say -kernel >>> <anything> and it should work. It has worked for me with vmlinux and >>> Image files when using master (not the 4.0 release but master/4.1). >>> Although all of my testing was with the 5.1 kernel, so maybe there is >>> a difference there? >>> >>> What isn't working for you? Can you include the errors and output of -d in_asm? >>> >>> >>> Alistair >> >> >> Hi Alistair, >> I have come across error before starting target simulation. What I means is to execute >> qemu-system-riscv64 -M virt -m 256M -nographic -bios ./opensbi/build/platform/qemu/virt/firmware/fw_jump.elf -kernel vmlinux >> then get the error message >> rom: requested regions overlap (rom mrom.reset. free=0x000000000001eb7c, addr=0x0000000000001000) >> qemu-system-riscv64: rom check and register reset failed > > Hmmm.... I don't remember seeing this problem in my testing, but it > does seem to make sense. > > We have two options here: > 1. Use the Image file from Linux 5.0+ (my preferred option as 4.19 is > getting old) > 2. Use the device loader (documented here: > https://github.com/riscv/opensbi/blob/master/docs/platform/qemu_virt.md) Nice doc, this example is exactly what I had in mind: qemu-system-riscv64 -M virt -m 256M -nographic \ -kernel build/platform/qemu/virt/firmware/fw_jump.elf \ -device loader,file=<linux_build_directory>/arch/riscv/boot/Image,addr=0x80200000 \ -drive file=<path_to_linux_rootfs>,format=raw,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -append "root=/dev/vda rw console=ttyS0" If the Image is an ELF, I assume we don't need to specify the address, because the device loader knows how to parse this format. Again, Alistair is the expert ;) If for some reason it only works with Linux 5.0+, let's use these! Regards, Phil.
On Tue, Jul 16, 2019 at 2:50 PM Philippe Mathieu-Daudé <philmd@redhat.com> wrote: > > On 7/16/19 10:43 PM, Alistair Francis wrote: > > On Tue, Jul 16, 2019 at 6:56 AM Chih-Min Chao <chihmin.chao@sifive.com> wrote: > >> > >> > >> On Tue, Jul 16, 2019 at 12:34 AM Alistair Francis <alistair23@gmail.com> wrote: > >>> > >>> On Mon, Jul 15, 2019 at 6:02 AM Philippe Mathieu-Daudé > >>> <philmd@redhat.com> wrote: > >>>> > >>>> On 7/15/19 1:09 PM, Chih-Min Chao wrote: > >>>>> On Mon, Jul 15, 2019 at 5:15 PM Philippe Mathieu-Daudé > >>>>> <philmd@redhat.com <mailto:philmd@redhat.com>> wrote: > >>>>> > >>>>> On 7/15/19 11:08 AM, Chih-Min Chao wrote: > >>>>> > Similar to the mips + malta test, it boots a Linux kernel on a virt > >>>>> > board and verify the serial is working. Also, it relies on the serial > >>>>> > device set by the machine itself. > >>>>> > > >>>>> > If riscv64 is a target being built, "make check-acceptance" will > >>>>> > automatically include this test by the use of the "arch:riscv64" tags. > >>>>> > > >>>>> > Alternatively, this test can be run using: > >>>>> > > >>>>> > $ avocado run -t arch:riscv64 tests/acceptance > >>>>> > > >>>>> > packages > >>>>> > debian official > >>>>> > binutils-riscv64-linux-gnu_2.32-8 > >>>>> > opensbi_0.4-1_all > >>>>> > linux-image-4.19.0-5-riscv64 4.19.37-4 > >>>>> > third-party > >>>>> > > >>>>> https://github.com/groeck/linux-build-test/rootfs/riscv64/rootfs.cpio.gz > >>>>> > (the repo is also used in mips target acceptance) > >>>>> > > >>>>> > Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com > >>>>> <mailto:chihmin.chao@sifive.com>> > >>>>> > --- > >>>>> > .travis.yml | 2 +- > >>>>> > tests/acceptance/boot_linux_console.py | 66 > >>>>> ++++++++++++++++++++++++++++++++++ > >>>>> > 2 files changed, 67 insertions(+), 1 deletion(-) > >>>>> > > >>>>> > diff --git a/.travis.yml b/.travis.yml > >>>>> > index 5d3d6ee..21fcead 100644 > >>>>> > --- a/.travis.yml > >>>>> > +++ b/.travis.yml > >>>>> > @@ -232,7 +232,7 @@ matrix: > >>>>> > > >>>>> > # Acceptance (Functional) tests > >>>>> > - env: > >>>>> > - - CONFIG="--python=/usr/bin/python3 > >>>>> --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu" > >>>>> > + - CONFIG="--python=/usr/bin/python3 > >>>>> --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu,riscv64-softmmu" > >>>>> > - TEST_CMD="make check-acceptance" > >>>>> > after_failure: > >>>>> > - cat tests/results/latest/job.log > >>>>> > diff --git a/tests/acceptance/boot_linux_console.py > >>>>> b/tests/acceptance/boot_linux_console.py > >>>>> > index 3215950..0f638bc 100644 > >>>>> > --- a/tests/acceptance/boot_linux_console.py > >>>>> > +++ b/tests/acceptance/boot_linux_console.py > >>>>> > @@ -354,3 +354,69 @@ class BootLinuxConsole(Test): > >>>>> > self.vm.launch() > >>>>> > console_pattern = 'Kernel command line: %s' % > >>>>> kernel_command_line > >>>>> > self.wait_for_console_pattern(console_pattern) > >>>>> > + > >>>>> > + def test_riscv64_virt(self): > >>>>> > + """ > >>>>> > + :avocado: tags=arch:riscv64 > >>>>> > + :avocado: tags=machine:virt > >>>>> > + """ > >>>>> > + deb_url = ('https://snapshot.debian.org/archive/debian/' > >>>>> > + '20190424T171759Z/pool/main/b/binutils/' > >>>>> > + > >>>>> 'binutils-riscv64-linux-gnu_2.32-8_amd64.deb') > >>>>> > + deb_hash = ('7fe376fd4452696c03acd508d6d613ca553ea15e') > >>>>> > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) > >>>>> > + objcopy_path = '/usr/bin/riscv64-linux-gnu-objcopy' > >>>>> > + objcopy_path = self.extract_from_deb(deb_path, objcopy_path) > >>>>> > + libbfd_path = > >>>>> '/usr/lib/x86_64-linux-gnu/libbfd-2.32-riscv64.so > >>>>> <http://libbfd-2.32-riscv64.so>' > >>>>> > + libbfd_path = self.extract_from_deb(deb_path, libbfd_path) > >>>>> > + process.run('ls -al %s' % (objcopy_path)) > >>>>> > + > >>>>> > + deb_url = ('https://snapshot.debian.org/archive/debian/' > >>>>> > + '20190708T032337Z/pool/main/o/opensbi/' > >>>>> > + 'opensbi_0.4-1_all.deb') > >>>>> > + deb_hash = ('2319dcd702958291d323acf5649fd98a11d90112') > >>>>> > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) > >>>>> > + opensbi_path = ('/usr/lib/riscv64-linux-gnu/opensbi/' > >>>>> > + 'qemu/virt/fw_jump.elf') > >>>>> > + opensbi_path = self.extract_from_deb(deb_path, opensbi_path) > >>>>> > + > >>>>> > + deb_url = > >>>>> ('https://snapshot.debian.org/archive/debian-ports/' > >>>>> > + '20190620T095935Z/pool-riscv64/main/l/linux/' > >>>>> > + > >>>>> 'linux-image-4.19.0-5-riscv64_4.19.37-4_riscv64.deb') > >>>>> > + deb_hash = ('bf5b5680c41d92134d22caef4fbd277c5217e1f0') > >>>>> > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) > >>>>> > + kernel_path = '/boot/vmlinux-4.19.0-5-riscv64' > >>>>> > + kernel_path = self.extract_from_deb(deb_path, kernel_path) > >>>>> > + kimage_path = self.workdir + "/Image" > >>>>> > + env = os.environ > >>>>> > + env['LD_LIBRARY_PATH'] = ('%s:' % > >>>>> (os.path.dirname(libbfd_path)) + > >>>>> > + env.get('LD_LIBRARY_PATH', '')) > >>>>> > + process.run(('%s -O binary -O binary -R' > >>>>> > + '.note -R .note.gnu.build-id -R .comment -S > >>>>> %s %s') % > >>>>> > + (objcopy_path, kernel_path, kimage_path)) > >>>>> > >>>>> Please explain why you need to do that... > >>>>> > >>>>> Also note these tests are run on other host architecture than x86, at > >>>>> least ppc64/s390x (so this won't work there). > >>>>> > >>>>> it is because riscv64 vmlinux doesn't have physical loading address > >>>>> information and > >>>>> depends on certain stage bootloader to move kernel raw data to specific > >>>>> physical address (0x8020_0000) > >>>>> > >>>>> The vmlinux program headers are > >>>>> Type Offset VirtAddr PhysAddr > >>>>> FileSiz MemSiz Flg Align > >>>>> LOAD 0x001000 0xffffffe000000000 0x0000000000000000 0x0303a6 > >>>>> 0x0303a6 R E 0x1000 > >>>>> LOAD 0x032000 0xffffffe000031000 0x0000000000031000 0x828f0c > >>>>> 0x828f0c RWE 0x1000 > >>>>> NOTE 0x85aec0 0xffffffe000859ec0 0x0000000000859ec0 0x00004c > >>>>> 0x00004c R 0x4 > >>>>> > >>>>> For legacy bootloader, bbl, It can handle payload in ELF format. > >>>>> However, for the newer OpenSBI, it can only handle raw data and > >>>>> debian doesn't provide linux image in raw data format. > >>> > >>> This doesn't sound right. You should just be able to say -kernel > >>> <anything> and it should work. It has worked for me with vmlinux and > >>> Image files when using master (not the 4.0 release but master/4.1). > >>> Although all of my testing was with the 5.1 kernel, so maybe there is > >>> a difference there? > >>> > >>> What isn't working for you? Can you include the errors and output of -d in_asm? > >>> > >>> > >>> Alistair > >> > >> > >> Hi Alistair, > >> I have come across error before starting target simulation. What I means is to execute > >> qemu-system-riscv64 -M virt -m 256M -nographic -bios ./opensbi/build/platform/qemu/virt/firmware/fw_jump.elf -kernel vmlinux > >> then get the error message > >> rom: requested regions overlap (rom mrom.reset. free=0x000000000001eb7c, addr=0x0000000000001000) > >> qemu-system-riscv64: rom check and register reset failed > > > > Hmmm.... I don't remember seeing this problem in my testing, but it > > does seem to make sense. > > > > We have two options here: > > 1. Use the Image file from Linux 5.0+ (my preferred option as 4.19 is > > getting old) > > 2. Use the device loader (documented here: > > https://github.com/riscv/opensbi/blob/master/docs/platform/qemu_virt.md) > > Nice doc, this example is exactly what I had in mind: > > qemu-system-riscv64 -M virt -m 256M -nographic \ > -kernel build/platform/qemu/virt/firmware/fw_jump.elf \ > -device > loader,file=<linux_build_directory>/arch/riscv/boot/Image,addr=0x80200000 \ > -drive file=<path_to_linux_rootfs>,format=raw,id=hd0 \ > -device virtio-blk-device,drive=hd0 \ > -append "root=/dev/vda rw console=ttyS0" > > If the Image is an ELF, I assume we don't need to specify the address, > because the device loader knows how to parse this format. Again, > Alistair is the expert ;) Yep, an elf should just work. > > If for some reason it only works with Linux 5.0+, let's use these! Only 5.0+ builds an elf. Alistair > > Regards, > > Phil.
On Wed, Jul 17, 2019 at 6:59 AM Alistair Francis <alistair23@gmail.com> wrote: > On Tue, Jul 16, 2019 at 2:50 PM Philippe Mathieu-Daudé > <philmd@redhat.com> wrote: > > > > On 7/16/19 10:43 PM, Alistair Francis wrote: > > > On Tue, Jul 16, 2019 at 6:56 AM Chih-Min Chao <chihmin.chao@sifive.com> > wrote: > > >> > > >> > > >> On Tue, Jul 16, 2019 at 12:34 AM Alistair Francis < > alistair23@gmail.com> wrote: > > >>> > > >>> On Mon, Jul 15, 2019 at 6:02 AM Philippe Mathieu-Daudé > > >>> <philmd@redhat.com> wrote: > > >>>> > > >>>> On 7/15/19 1:09 PM, Chih-Min Chao wrote: > > >>>>> On Mon, Jul 15, 2019 at 5:15 PM Philippe Mathieu-Daudé > > >>>>> <philmd@redhat.com <mailto:philmd@redhat.com>> wrote: > > >>>>> > > >>>>> On 7/15/19 11:08 AM, Chih-Min Chao wrote: > > >>>>> > Similar to the mips + malta test, it boots a Linux kernel on > a virt > > >>>>> > board and verify the serial is working. Also, it relies on > the serial > > >>>>> > device set by the machine itself. > > >>>>> > > > >>>>> > If riscv64 is a target being built, "make check-acceptance" > will > > >>>>> > automatically include this test by the use of the > "arch:riscv64" tags. > > >>>>> > > > >>>>> > Alternatively, this test can be run using: > > >>>>> > > > >>>>> > $ avocado run -t arch:riscv64 tests/acceptance > > >>>>> > > > >>>>> > packages > > >>>>> > debian official > > >>>>> > binutils-riscv64-linux-gnu_2.32-8 > > >>>>> > opensbi_0.4-1_all > > >>>>> > linux-image-4.19.0-5-riscv64 4.19.37-4 > > >>>>> > third-party > > >>>>> > > > >>>>> > https://github.com/groeck/linux-build-test/rootfs/riscv64/rootfs.cpio.gz > > >>>>> > (the repo is also used in mips target acceptance) > > >>>>> > > > >>>>> > Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com > > >>>>> <mailto:chihmin.chao@sifive.com>> > > >>>>> > --- > > >>>>> > .travis.yml | 2 +- > > >>>>> > tests/acceptance/boot_linux_console.py | 66 > > >>>>> ++++++++++++++++++++++++++++++++++ > > >>>>> > 2 files changed, 67 insertions(+), 1 deletion(-) > > >>>>> > > > >>>>> > diff --git a/.travis.yml b/.travis.yml > > >>>>> > index 5d3d6ee..21fcead 100644 > > >>>>> > --- a/.travis.yml > > >>>>> > +++ b/.travis.yml > > >>>>> > @@ -232,7 +232,7 @@ matrix: > > >>>>> > > > >>>>> > # Acceptance (Functional) tests > > >>>>> > - env: > > >>>>> > - - CONFIG="--python=/usr/bin/python3 > > >>>>> > --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu" > > >>>>> > + - CONFIG="--python=/usr/bin/python3 > > >>>>> > --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu,riscv64-softmmu" > > >>>>> > - TEST_CMD="make check-acceptance" > > >>>>> > after_failure: > > >>>>> > - cat tests/results/latest/job.log > > >>>>> > diff --git a/tests/acceptance/boot_linux_console.py > > >>>>> b/tests/acceptance/boot_linux_console.py > > >>>>> > index 3215950..0f638bc 100644 > > >>>>> > --- a/tests/acceptance/boot_linux_console.py > > >>>>> > +++ b/tests/acceptance/boot_linux_console.py > > >>>>> > @@ -354,3 +354,69 @@ class BootLinuxConsole(Test): > > >>>>> > self.vm.launch() > > >>>>> > console_pattern = 'Kernel command line: %s' % > > >>>>> kernel_command_line > > >>>>> > self.wait_for_console_pattern(console_pattern) > > >>>>> > + > > >>>>> > + def test_riscv64_virt(self): > > >>>>> > + """ > > >>>>> > + :avocado: tags=arch:riscv64 > > >>>>> > + :avocado: tags=machine:virt > > >>>>> > + """ > > >>>>> > + deb_url = (' > https://snapshot.debian.org/archive/debian/' > > >>>>> > + > '20190424T171759Z/pool/main/b/binutils/' > > >>>>> > + > > >>>>> 'binutils-riscv64-linux-gnu_2.32-8_amd64.deb') > > >>>>> > + deb_hash = > ('7fe376fd4452696c03acd508d6d613ca553ea15e') > > >>>>> > + deb_path = self.fetch_asset(deb_url, > asset_hash=deb_hash) > > >>>>> > + objcopy_path = '/usr/bin/riscv64-linux-gnu-objcopy' > > >>>>> > + objcopy_path = self.extract_from_deb(deb_path, > objcopy_path) > > >>>>> > + libbfd_path = > > >>>>> '/usr/lib/x86_64-linux-gnu/libbfd-2.32-riscv64.so > > >>>>> <http://libbfd-2.32-riscv64.so>' > > >>>>> > + libbfd_path = self.extract_from_deb(deb_path, > libbfd_path) > > >>>>> > + process.run('ls -al %s' % (objcopy_path)) > > >>>>> > + > > >>>>> > + deb_url = (' > https://snapshot.debian.org/archive/debian/' > > >>>>> > + '20190708T032337Z/pool/main/o/opensbi/' > > >>>>> > + 'opensbi_0.4-1_all.deb') > > >>>>> > + deb_hash = > ('2319dcd702958291d323acf5649fd98a11d90112') > > >>>>> > + deb_path = self.fetch_asset(deb_url, > asset_hash=deb_hash) > > >>>>> > + opensbi_path = > ('/usr/lib/riscv64-linux-gnu/opensbi/' > > >>>>> > + 'qemu/virt/fw_jump.elf') > > >>>>> > + opensbi_path = self.extract_from_deb(deb_path, > opensbi_path) > > >>>>> > + > > >>>>> > + deb_url = > > >>>>> ('https://snapshot.debian.org/archive/debian-ports/' > > >>>>> > + > '20190620T095935Z/pool-riscv64/main/l/linux/' > > >>>>> > + > > >>>>> 'linux-image-4.19.0-5-riscv64_4.19.37-4_riscv64.deb') > > >>>>> > + deb_hash = > ('bf5b5680c41d92134d22caef4fbd277c5217e1f0') > > >>>>> > + deb_path = self.fetch_asset(deb_url, > asset_hash=deb_hash) > > >>>>> > + kernel_path = '/boot/vmlinux-4.19.0-5-riscv64' > > >>>>> > + kernel_path = self.extract_from_deb(deb_path, > kernel_path) > > >>>>> > + kimage_path = self.workdir + "/Image" > > >>>>> > + env = os.environ > > >>>>> > + env['LD_LIBRARY_PATH'] = ('%s:' % > > >>>>> (os.path.dirname(libbfd_path)) + > > >>>>> > + env.get('LD_LIBRARY_PATH', > '')) > > >>>>> > + process.run(('%s -O binary -O binary -R' > > >>>>> > + '.note -R .note.gnu.build-id -R > .comment -S > > >>>>> %s %s') % > > >>>>> > + (objcopy_path, kernel_path, > kimage_path)) > > >>>>> > > >>>>> Please explain why you need to do that... > > >>>>> > > >>>>> Also note these tests are run on other host architecture than > x86, at > > >>>>> least ppc64/s390x (so this won't work there). > > >>>>> > > >>>>> it is because riscv64 vmlinux doesn't have physical loading address > > >>>>> information and > > >>>>> depends on certain stage bootloader to move kernel raw data to > specific > > >>>>> physical address (0x8020_0000) > > >>>>> > > >>>>> The vmlinux program headers are > > >>>>> Type Offset VirtAddr PhysAddr > > >>>>> FileSiz MemSiz Flg Align > > >>>>> LOAD 0x001000 0xffffffe000000000 0x0000000000000000 > 0x0303a6 > > >>>>> 0x0303a6 R E 0x1000 > > >>>>> LOAD 0x032000 0xffffffe000031000 0x0000000000031000 > 0x828f0c > > >>>>> 0x828f0c RWE 0x1000 > > >>>>> NOTE 0x85aec0 0xffffffe000859ec0 0x0000000000859ec0 > 0x00004c > > >>>>> 0x00004c R 0x4 > > >>>>> > > >>>>> For legacy bootloader, bbl, It can handle payload in ELF format. > > >>>>> However, for the newer OpenSBI, it can only handle raw data and > > >>>>> debian doesn't provide linux image in raw data format. > > >>> > > >>> This doesn't sound right. You should just be able to say -kernel > > >>> <anything> and it should work. It has worked for me with vmlinux and > > >>> Image files when using master (not the 4.0 release but master/4.1). > > >>> Although all of my testing was with the 5.1 kernel, so maybe there is > > >>> a difference there? > > >>> > > >>> What isn't working for you? Can you include the errors and output of > -d in_asm? > > >>> > > >>> > > >>> Alistair > > >> > > >> > > >> Hi Alistair, > > >> I have come across error before starting target simulation. What > I means is to execute > > >> qemu-system-riscv64 -M virt -m 256M -nographic -bios > ./opensbi/build/platform/qemu/virt/firmware/fw_jump.elf -kernel vmlinux > > >> then get the error message > > >> rom: requested regions overlap (rom mrom.reset. > free=0x000000000001eb7c, addr=0x0000000000001000) > > >> qemu-system-riscv64: rom check and register reset failed > > > > > > Hmmm.... I don't remember seeing this problem in my testing, but it > > > does seem to make sense. > > > > > > We have two options here: > > > 1. Use the Image file from Linux 5.0+ (my preferred option as 4.19 is > > > getting old) > I choose 4.19 version rather than 5.0+ because 4.19 is stable branch maintained by Greg. But it is ok to use 5.0 trunk, the latest version provided by debian. > > > 2. Use the device loader (documented here: > > > > https://github.com/riscv/opensbi/blob/master/docs/platform/qemu_virt.md) > The document describes two user cases 1. fw_payload.elf a. include the Image (raw data file, not elf) into data section b. -kernel load the each part to the correct address the program header of fw_payload.elf are Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x0000b0 0x0000000080000000 0x0000000080000000 0x00a008 0x00b0b8 RWE 0x10 <- fw_payload main program LOAD 0x00a0b8 0x0000000080200000 0x0000000080200000 0x8dbe20 0x8dbe20 R E 0x1 <- arch/riscv/boot/Image or u-boot.bin 2. fw_jump.elf a. use "-kernel <raw image> or -device loader,file=<raw Image>,addr=0x80200000" to load correct address b. fw_jump.elf just jump to the entry address 0x80200000 The issues are a. debian linux-image package only provides vmlinux. so I use objcopy in acceptance test b. riscv64 vmlinux doesn't have correct PhysAddr and -kernel can't move data to expected address explicit load the Image to specific -kernel raw_image (if file is not elf or uImage, riscv_kerner_loader treat it is as raw image and place it at 0x8020_0000) -device loader,file=<raw_image>,0x80200000 (do the same thing) ELF should work only if it has correct loading information. chihmin.chao > > > > Nice doc, this example is exactly what I had in mind: > > > > qemu-system-riscv64 -M virt -m 256M -nographic \ > > -kernel build/platform/qemu/virt/firmware/fw_jump.elf \ > > -device > > > loader,file=<linux_build_directory>/arch/riscv/boot/Image,addr=0x80200000 \ > > -drive file=<path_to_linux_rootfs>,format=raw,id=hd0 \ > > -device virtio-blk-device,drive=hd0 \ > > -append "root=/dev/vda rw console=ttyS0" > > > > If the Image is an ELF, I assume we don't need to specify the address, > > because the device loader knows how to parse this format. Again, > > Alistair is the expert ;) > > Yep, an elf should just work. > > describe the issue above > > > > If for some reason it only works with Linux 5.0+, let's use these! > > Only 5.0+ builds an elf. > > Alistair > > > > > Regards, > > > > Phil. >
On Tue, Jul 16, 2019 at 10:21 PM Chih-Min Chao <chihmin.chao@sifive.com> wrote: > > > > On Wed, Jul 17, 2019 at 6:59 AM Alistair Francis <alistair23@gmail.com> wrote: >> >> On Tue, Jul 16, 2019 at 2:50 PM Philippe Mathieu-Daudé >> <philmd@redhat.com> wrote: >> > >> > On 7/16/19 10:43 PM, Alistair Francis wrote: >> > > On Tue, Jul 16, 2019 at 6:56 AM Chih-Min Chao <chihmin.chao@sifive.com> wrote: >> > >> >> > >> >> > >> On Tue, Jul 16, 2019 at 12:34 AM Alistair Francis <alistair23@gmail.com> wrote: >> > >>> >> > >>> On Mon, Jul 15, 2019 at 6:02 AM Philippe Mathieu-Daudé >> > >>> <philmd@redhat.com> wrote: >> > >>>> >> > >>>> On 7/15/19 1:09 PM, Chih-Min Chao wrote: >> > >>>>> On Mon, Jul 15, 2019 at 5:15 PM Philippe Mathieu-Daudé >> > >>>>> <philmd@redhat.com <mailto:philmd@redhat.com>> wrote: >> > >>>>> >> > >>>>> On 7/15/19 11:08 AM, Chih-Min Chao wrote: >> > >>>>> > Similar to the mips + malta test, it boots a Linux kernel on a virt >> > >>>>> > board and verify the serial is working. Also, it relies on the serial >> > >>>>> > device set by the machine itself. >> > >>>>> > >> > >>>>> > If riscv64 is a target being built, "make check-acceptance" will >> > >>>>> > automatically include this test by the use of the "arch:riscv64" tags. >> > >>>>> > >> > >>>>> > Alternatively, this test can be run using: >> > >>>>> > >> > >>>>> > $ avocado run -t arch:riscv64 tests/acceptance >> > >>>>> > >> > >>>>> > packages >> > >>>>> > debian official >> > >>>>> > binutils-riscv64-linux-gnu_2.32-8 >> > >>>>> > opensbi_0.4-1_all >> > >>>>> > linux-image-4.19.0-5-riscv64 4.19.37-4 >> > >>>>> > third-party >> > >>>>> > >> > >>>>> https://github.com/groeck/linux-build-test/rootfs/riscv64/rootfs.cpio.gz >> > >>>>> > (the repo is also used in mips target acceptance) >> > >>>>> > >> > >>>>> > Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com >> > >>>>> <mailto:chihmin.chao@sifive.com>> >> > >>>>> > --- >> > >>>>> > .travis.yml | 2 +- >> > >>>>> > tests/acceptance/boot_linux_console.py | 66 >> > >>>>> ++++++++++++++++++++++++++++++++++ >> > >>>>> > 2 files changed, 67 insertions(+), 1 deletion(-) >> > >>>>> > >> > >>>>> > diff --git a/.travis.yml b/.travis.yml >> > >>>>> > index 5d3d6ee..21fcead 100644 >> > >>>>> > --- a/.travis.yml >> > >>>>> > +++ b/.travis.yml >> > >>>>> > @@ -232,7 +232,7 @@ matrix: >> > >>>>> > >> > >>>>> > # Acceptance (Functional) tests >> > >>>>> > - env: >> > >>>>> > - - CONFIG="--python=/usr/bin/python3 >> > >>>>> --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu" >> > >>>>> > + - CONFIG="--python=/usr/bin/python3 >> > >>>>> --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu,riscv64-softmmu" >> > >>>>> > - TEST_CMD="make check-acceptance" >> > >>>>> > after_failure: >> > >>>>> > - cat tests/results/latest/job.log >> > >>>>> > diff --git a/tests/acceptance/boot_linux_console.py >> > >>>>> b/tests/acceptance/boot_linux_console.py >> > >>>>> > index 3215950..0f638bc 100644 >> > >>>>> > --- a/tests/acceptance/boot_linux_console.py >> > >>>>> > +++ b/tests/acceptance/boot_linux_console.py >> > >>>>> > @@ -354,3 +354,69 @@ class BootLinuxConsole(Test): >> > >>>>> > self.vm.launch() >> > >>>>> > console_pattern = 'Kernel command line: %s' % >> > >>>>> kernel_command_line >> > >>>>> > self.wait_for_console_pattern(console_pattern) >> > >>>>> > + >> > >>>>> > + def test_riscv64_virt(self): >> > >>>>> > + """ >> > >>>>> > + :avocado: tags=arch:riscv64 >> > >>>>> > + :avocado: tags=machine:virt >> > >>>>> > + """ >> > >>>>> > + deb_url = ('https://snapshot.debian.org/archive/debian/' >> > >>>>> > + '20190424T171759Z/pool/main/b/binutils/' >> > >>>>> > + >> > >>>>> 'binutils-riscv64-linux-gnu_2.32-8_amd64.deb') >> > >>>>> > + deb_hash = ('7fe376fd4452696c03acd508d6d613ca553ea15e') >> > >>>>> > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) >> > >>>>> > + objcopy_path = '/usr/bin/riscv64-linux-gnu-objcopy' >> > >>>>> > + objcopy_path = self.extract_from_deb(deb_path, objcopy_path) >> > >>>>> > + libbfd_path = >> > >>>>> '/usr/lib/x86_64-linux-gnu/libbfd-2.32-riscv64.so >> > >>>>> <http://libbfd-2.32-riscv64.so>' >> > >>>>> > + libbfd_path = self.extract_from_deb(deb_path, libbfd_path) >> > >>>>> > + process.run('ls -al %s' % (objcopy_path)) >> > >>>>> > + >> > >>>>> > + deb_url = ('https://snapshot.debian.org/archive/debian/' >> > >>>>> > + '20190708T032337Z/pool/main/o/opensbi/' >> > >>>>> > + 'opensbi_0.4-1_all.deb') >> > >>>>> > + deb_hash = ('2319dcd702958291d323acf5649fd98a11d90112') >> > >>>>> > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) >> > >>>>> > + opensbi_path = ('/usr/lib/riscv64-linux-gnu/opensbi/' >> > >>>>> > + 'qemu/virt/fw_jump.elf') >> > >>>>> > + opensbi_path = self.extract_from_deb(deb_path, opensbi_path) >> > >>>>> > + >> > >>>>> > + deb_url = >> > >>>>> ('https://snapshot.debian.org/archive/debian-ports/' >> > >>>>> > + '20190620T095935Z/pool-riscv64/main/l/linux/' >> > >>>>> > + >> > >>>>> 'linux-image-4.19.0-5-riscv64_4.19.37-4_riscv64.deb') >> > >>>>> > + deb_hash = ('bf5b5680c41d92134d22caef4fbd277c5217e1f0') >> > >>>>> > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) >> > >>>>> > + kernel_path = '/boot/vmlinux-4.19.0-5-riscv64' >> > >>>>> > + kernel_path = self.extract_from_deb(deb_path, kernel_path) >> > >>>>> > + kimage_path = self.workdir + "/Image" >> > >>>>> > + env = os.environ >> > >>>>> > + env['LD_LIBRARY_PATH'] = ('%s:' % >> > >>>>> (os.path.dirname(libbfd_path)) + >> > >>>>> > + env.get('LD_LIBRARY_PATH', '')) >> > >>>>> > + process.run(('%s -O binary -O binary -R' >> > >>>>> > + '.note -R .note.gnu.build-id -R .comment -S >> > >>>>> %s %s') % >> > >>>>> > + (objcopy_path, kernel_path, kimage_path)) >> > >>>>> >> > >>>>> Please explain why you need to do that... >> > >>>>> >> > >>>>> Also note these tests are run on other host architecture than x86, at >> > >>>>> least ppc64/s390x (so this won't work there). >> > >>>>> >> > >>>>> it is because riscv64 vmlinux doesn't have physical loading address >> > >>>>> information and >> > >>>>> depends on certain stage bootloader to move kernel raw data to specific >> > >>>>> physical address (0x8020_0000) >> > >>>>> >> > >>>>> The vmlinux program headers are >> > >>>>> Type Offset VirtAddr PhysAddr >> > >>>>> FileSiz MemSiz Flg Align >> > >>>>> LOAD 0x001000 0xffffffe000000000 0x0000000000000000 0x0303a6 >> > >>>>> 0x0303a6 R E 0x1000 >> > >>>>> LOAD 0x032000 0xffffffe000031000 0x0000000000031000 0x828f0c >> > >>>>> 0x828f0c RWE 0x1000 >> > >>>>> NOTE 0x85aec0 0xffffffe000859ec0 0x0000000000859ec0 0x00004c >> > >>>>> 0x00004c R 0x4 >> > >>>>> >> > >>>>> For legacy bootloader, bbl, It can handle payload in ELF format. >> > >>>>> However, for the newer OpenSBI, it can only handle raw data and >> > >>>>> debian doesn't provide linux image in raw data format. >> > >>> >> > >>> This doesn't sound right. You should just be able to say -kernel >> > >>> <anything> and it should work. It has worked for me with vmlinux and >> > >>> Image files when using master (not the 4.0 release but master/4.1). >> > >>> Although all of my testing was with the 5.1 kernel, so maybe there is >> > >>> a difference there? >> > >>> >> > >>> What isn't working for you? Can you include the errors and output of -d in_asm? >> > >>> >> > >>> >> > >>> Alistair >> > >> >> > >> >> > >> Hi Alistair, >> > >> I have come across error before starting target simulation. What I means is to execute >> > >> qemu-system-riscv64 -M virt -m 256M -nographic -bios ./opensbi/build/platform/qemu/virt/firmware/fw_jump.elf -kernel vmlinux >> > >> then get the error message >> > >> rom: requested regions overlap (rom mrom.reset. free=0x000000000001eb7c, addr=0x0000000000001000) >> > >> qemu-system-riscv64: rom check and register reset failed >> > > >> > > Hmmm.... I don't remember seeing this problem in my testing, but it >> > > does seem to make sense. >> > > >> > > We have two options here: >> > > 1. Use the Image file from Linux 5.0+ (my preferred option as 4.19 is >> > > getting old) > > I choose 4.19 version rather than 5.0+ because 4.19 is stable branch maintained by Greg. > But it is ok to use 5.0 trunk, the latest version provided by debian. > >> >> > > 2. Use the device loader (documented here: >> > > https://github.com/riscv/opensbi/blob/master/docs/platform/qemu_virt.md) > > > The document describes two user cases > 1. fw_payload.elf > a. include the Image (raw data file, not elf) into data section > b. -kernel load the each part to the correct address > > the program header of fw_payload.elf are > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > LOAD 0x0000b0 0x0000000080000000 0x0000000080000000 0x00a008 0x00b0b8 RWE 0x10 <- fw_payload main program > LOAD 0x00a0b8 0x0000000080200000 0x0000000080200000 0x8dbe20 0x8dbe20 R E 0x1 <- arch/riscv/boot/Image or u-boot.bin > > 2. fw_jump.elf > a. use "-kernel <raw image> or -device loader,file=<raw Image>,addr=0x80200000" to load correct address > b. fw_jump.elf just jump to the entry address 0x80200000 > > > The issues are > a. debian linux-image package only provides vmlinux. This can be fixed by upgrading the kernel version. Fedora should have a 5.2 kernel that you can use instead of Debian. > so I use objcopy in acceptance test > b. riscv64 vmlinux doesn't have correct PhysAddr and -kernel can't move data to expected address > explicit load the Image to specific > -kernel raw_image (if file is not elf or uImage, riscv_kerner_loader treat it is as raw image and place it at 0x8020_0000) > -device loader,file=<raw_image>,0x80200000 (do the same thing) Does the device loader not work? Alistair > > ELF should work only if it has correct loading information. > > chihmin.chao >> >> > >> > Nice doc, this example is exactly what I had in mind: >> > >> > qemu-system-riscv64 -M virt -m 256M -nographic \ >> > -kernel build/platform/qemu/virt/firmware/fw_jump.elf \ >> > -device >> > loader,file=<linux_build_directory>/arch/riscv/boot/Image,addr=0x80200000 \ >> > -drive file=<path_to_linux_rootfs>,format=raw,id=hd0 \ >> > -device virtio-blk-device,drive=hd0 \ >> > -append "root=/dev/vda rw console=ttyS0" >> > >> > If the Image is an ELF, I assume we don't need to specify the address, >> > because the device loader knows how to parse this format. Again, >> > Alistair is the expert ;) >> >> Yep, an elf should just work. >> > describe the issue above > >> >> > >> > If for some reason it only works with Linux 5.0+, let's use these! >> >> Only 5.0+ builds an elf. >> >> Alistair >> >> > >> > Regards, >> > >> > Phil.
On Thu, Jul 18, 2019 at 6:47 AM Alistair Francis <alistair23@gmail.com> wrote: > On Tue, Jul 16, 2019 at 10:21 PM Chih-Min Chao <chihmin.chao@sifive.com> > wrote: > > > > > > > > On Wed, Jul 17, 2019 at 6:59 AM Alistair Francis <alistair23@gmail.com> > wrote: > >> > >> On Tue, Jul 16, 2019 at 2:50 PM Philippe Mathieu-Daudé > >> <philmd@redhat.com> wrote: > >> > > >> > On 7/16/19 10:43 PM, Alistair Francis wrote: > >> > > On Tue, Jul 16, 2019 at 6:56 AM Chih-Min Chao < > chihmin.chao@sifive.com> wrote: > >> > >> > >> > >> > >> > >> On Tue, Jul 16, 2019 at 12:34 AM Alistair Francis < > alistair23@gmail.com> wrote: > >> > >>> > >> > >>> On Mon, Jul 15, 2019 at 6:02 AM Philippe Mathieu-Daudé > >> > >>> <philmd@redhat.com> wrote: > >> > >>>> > >> > >>>> On 7/15/19 1:09 PM, Chih-Min Chao wrote: > >> > >>>>> On Mon, Jul 15, 2019 at 5:15 PM Philippe Mathieu-Daudé > >> > >>>>> <philmd@redhat.com <mailto:philmd@redhat.com>> wrote: > >> > >>>>> > >> > >>>>> On 7/15/19 11:08 AM, Chih-Min Chao wrote: > >> > >>>>> > Similar to the mips + malta test, it boots a Linux kernel > on a virt > >> > >>>>> > board and verify the serial is working. Also, it relies > on the serial > >> > >>>>> > device set by the machine itself. > >> > >>>>> > > >> > >>>>> > If riscv64 is a target being built, "make > check-acceptance" will > >> > >>>>> > automatically include this test by the use of the > "arch:riscv64" tags. > >> > >>>>> > > >> > >>>>> > Alternatively, this test can be run using: > >> > >>>>> > > >> > >>>>> > $ avocado run -t arch:riscv64 tests/acceptance > >> > >>>>> > > >> > >>>>> > packages > >> > >>>>> > debian official > >> > >>>>> > binutils-riscv64-linux-gnu_2.32-8 > >> > >>>>> > opensbi_0.4-1_all > >> > >>>>> > linux-image-4.19.0-5-riscv64 4.19.37-4 > >> > >>>>> > third-party > >> > >>>>> > > >> > >>>>> > https://github.com/groeck/linux-build-test/rootfs/riscv64/rootfs.cpio.gz > >> > >>>>> > (the repo is also used in mips target acceptance) > >> > >>>>> > > >> > >>>>> > Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com > >> > >>>>> <mailto:chihmin.chao@sifive.com>> > >> > >>>>> > --- > >> > >>>>> > .travis.yml | 2 +- > >> > >>>>> > tests/acceptance/boot_linux_console.py | 66 > >> > >>>>> ++++++++++++++++++++++++++++++++++ > >> > >>>>> > 2 files changed, 67 insertions(+), 1 deletion(-) > >> > >>>>> > > >> > >>>>> > diff --git a/.travis.yml b/.travis.yml > >> > >>>>> > index 5d3d6ee..21fcead 100644 > >> > >>>>> > --- a/.travis.yml > >> > >>>>> > +++ b/.travis.yml > >> > >>>>> > @@ -232,7 +232,7 @@ matrix: > >> > >>>>> > > >> > >>>>> > # Acceptance (Functional) tests > >> > >>>>> > - env: > >> > >>>>> > - - CONFIG="--python=/usr/bin/python3 > >> > >>>>> > --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu" > >> > >>>>> > + - CONFIG="--python=/usr/bin/python3 > >> > >>>>> > --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu,riscv64-softmmu" > >> > >>>>> > - TEST_CMD="make check-acceptance" > >> > >>>>> > after_failure: > >> > >>>>> > - cat tests/results/latest/job.log > >> > >>>>> > diff --git a/tests/acceptance/boot_linux_console.py > >> > >>>>> b/tests/acceptance/boot_linux_console.py > >> > >>>>> > index 3215950..0f638bc 100644 > >> > >>>>> > --- a/tests/acceptance/boot_linux_console.py > >> > >>>>> > +++ b/tests/acceptance/boot_linux_console.py > >> > >>>>> > @@ -354,3 +354,69 @@ class BootLinuxConsole(Test): > >> > >>>>> > self.vm.launch() > >> > >>>>> > console_pattern = 'Kernel command line: %s' % > >> > >>>>> kernel_command_line > >> > >>>>> > self.wait_for_console_pattern(console_pattern) > >> > >>>>> > + > >> > >>>>> > + def test_riscv64_virt(self): > >> > >>>>> > + """ > >> > >>>>> > + :avocado: tags=arch:riscv64 > >> > >>>>> > + :avocado: tags=machine:virt > >> > >>>>> > + """ > >> > >>>>> > + deb_url = (' > https://snapshot.debian.org/archive/debian/' > >> > >>>>> > + > '20190424T171759Z/pool/main/b/binutils/' > >> > >>>>> > + > >> > >>>>> 'binutils-riscv64-linux-gnu_2.32-8_amd64.deb') > >> > >>>>> > + deb_hash = > ('7fe376fd4452696c03acd508d6d613ca553ea15e') > >> > >>>>> > + deb_path = self.fetch_asset(deb_url, > asset_hash=deb_hash) > >> > >>>>> > + objcopy_path = > '/usr/bin/riscv64-linux-gnu-objcopy' > >> > >>>>> > + objcopy_path = self.extract_from_deb(deb_path, > objcopy_path) > >> > >>>>> > + libbfd_path = > >> > >>>>> '/usr/lib/x86_64-linux-gnu/libbfd-2.32-riscv64.so > >> > >>>>> <http://libbfd-2.32-riscv64.so>' > >> > >>>>> > + libbfd_path = self.extract_from_deb(deb_path, > libbfd_path) > >> > >>>>> > + process.run('ls -al %s' % (objcopy_path)) > >> > >>>>> > + > >> > >>>>> > + deb_url = (' > https://snapshot.debian.org/archive/debian/' > >> > >>>>> > + > '20190708T032337Z/pool/main/o/opensbi/' > >> > >>>>> > + 'opensbi_0.4-1_all.deb') > >> > >>>>> > + deb_hash = > ('2319dcd702958291d323acf5649fd98a11d90112') > >> > >>>>> > + deb_path = self.fetch_asset(deb_url, > asset_hash=deb_hash) > >> > >>>>> > + opensbi_path = > ('/usr/lib/riscv64-linux-gnu/opensbi/' > >> > >>>>> > + 'qemu/virt/fw_jump.elf') > >> > >>>>> > + opensbi_path = self.extract_from_deb(deb_path, > opensbi_path) > >> > >>>>> > + > >> > >>>>> > + deb_url = > >> > >>>>> ('https://snapshot.debian.org/archive/debian-ports/' > >> > >>>>> > + > '20190620T095935Z/pool-riscv64/main/l/linux/' > >> > >>>>> > + > >> > >>>>> 'linux-image-4.19.0-5-riscv64_4.19.37-4_riscv64.deb') > >> > >>>>> > + deb_hash = > ('bf5b5680c41d92134d22caef4fbd277c5217e1f0') > >> > >>>>> > + deb_path = self.fetch_asset(deb_url, > asset_hash=deb_hash) > >> > >>>>> > + kernel_path = '/boot/vmlinux-4.19.0-5-riscv64' > >> > >>>>> > + kernel_path = self.extract_from_deb(deb_path, > kernel_path) > >> > >>>>> > + kimage_path = self.workdir + "/Image" > >> > >>>>> > + env = os.environ > >> > >>>>> > + env['LD_LIBRARY_PATH'] = ('%s:' % > >> > >>>>> (os.path.dirname(libbfd_path)) + > >> > >>>>> > + > env.get('LD_LIBRARY_PATH', '')) > >> > >>>>> > + process.run(('%s -O binary -O binary -R' > >> > >>>>> > + '.note -R .note.gnu.build-id -R > .comment -S > >> > >>>>> %s %s') % > >> > >>>>> > + (objcopy_path, kernel_path, > kimage_path)) > >> > >>>>> > >> > >>>>> Please explain why you need to do that... > >> > >>>>> > >> > >>>>> Also note these tests are run on other host architecture > than x86, at > >> > >>>>> least ppc64/s390x (so this won't work there). > >> > >>>>> > >> > >>>>> it is because riscv64 vmlinux doesn't have physical loading > address > >> > >>>>> information and > >> > >>>>> depends on certain stage bootloader to move kernel raw data to > specific > >> > >>>>> physical address (0x8020_0000) > >> > >>>>> > >> > >>>>> The vmlinux program headers are > >> > >>>>> Type Offset VirtAddr > PhysAddr > >> > >>>>> FileSiz MemSiz Flg Align > >> > >>>>> LOAD 0x001000 0xffffffe000000000 0x0000000000000000 > 0x0303a6 > >> > >>>>> 0x0303a6 R E 0x1000 > >> > >>>>> LOAD 0x032000 0xffffffe000031000 0x0000000000031000 > 0x828f0c > >> > >>>>> 0x828f0c RWE 0x1000 > >> > >>>>> NOTE 0x85aec0 0xffffffe000859ec0 0x0000000000859ec0 > 0x00004c > >> > >>>>> 0x00004c R 0x4 > >> > >>>>> > >> > >>>>> For legacy bootloader, bbl, It can handle payload in ELF format. > >> > >>>>> However, for the newer OpenSBI, it can only handle raw data and > >> > >>>>> debian doesn't provide linux image in raw data format. > >> > >>> > >> > >>> This doesn't sound right. You should just be able to say -kernel > >> > >>> <anything> and it should work. It has worked for me with vmlinux > and > >> > >>> Image files when using master (not the 4.0 release but > master/4.1). > >> > >>> Although all of my testing was with the 5.1 kernel, so maybe > there is > >> > >>> a difference there? > >> > >>> > >> > >>> What isn't working for you? Can you include the errors and output > of -d in_asm? > >> > >>> > >> > >>> > >> > >>> Alistair > >> > >> > >> > >> > >> > >> Hi Alistair, > >> > >> I have come across error before starting target simulation. > What I means is to execute > >> > >> qemu-system-riscv64 -M virt -m 256M -nographic -bios > ./opensbi/build/platform/qemu/virt/firmware/fw_jump.elf -kernel vmlinux > >> > >> then get the error message > >> > >> rom: requested regions overlap (rom mrom.reset. > free=0x000000000001eb7c, addr=0x0000000000001000) > >> > >> qemu-system-riscv64: rom check and register reset > failed > >> > > > >> > > Hmmm.... I don't remember seeing this problem in my testing, but it > >> > > does seem to make sense. > >> > > > >> > > We have two options here: > >> > > 1. Use the Image file from Linux 5.0+ (my preferred option as 4.19 > is > >> > > getting old) > > > > I choose 4.19 version rather than 5.0+ because 4.19 is stable branch > maintained by Greg. > > But it is ok to use 5.0 trunk, the latest version provided by debian. > > > >> > >> > > 2. Use the device loader (documented here: > >> > > > https://github.com/riscv/opensbi/blob/master/docs/platform/qemu_virt.md) > > > > > > The document describes two user cases > > 1. fw_payload.elf > > a. include the Image (raw data file, not elf) into data section > > b. -kernel load the each part to the correct address > > > > the program header of fw_payload.elf are > > Type Offset VirtAddr PhysAddr > FileSiz MemSiz Flg Align > > LOAD 0x0000b0 0x0000000080000000 0x0000000080000000 > 0x00a008 0x00b0b8 RWE 0x10 <- fw_payload main program > > LOAD 0x00a0b8 0x0000000080200000 0x0000000080200000 > 0x8dbe20 0x8dbe20 R E 0x1 <- arch/riscv/boot/Image or > u-boot.bin > > > > 2. fw_jump.elf > > a. use "-kernel <raw image> or -device loader,file=<raw > Image>,addr=0x80200000" to load correct address > > b. fw_jump.elf just jump to the entry address 0x80200000 > > > > > > The issues are > > a. debian linux-image package only provides vmlinux. > > This can be fixed by upgrading the kernel version. Fedora should have > a 5.2 kernel that you can use instead of Debian. > > > so I use objcopy in acceptance test > > b. riscv64 vmlinux doesn't have correct PhysAddr and -kernel can't > move data to expected address > > explicit load the Image to specific > > -kernel raw_image (if file is not elf or uImage, > riscv_kerner_loader treat it is as raw image and place it at 0x8020_0000) > > -device loader,file=<raw_image>,0x80200000 (do the same > thing) > > Does the device loader not work? > > Alistair > The device loader works for "Image" case (raw data) If the data is raw image, for riscv_load_kernel implementation, "-kernel <raw_image>" and -device loader,file=<raw_image>,0x80200000 are the same. They finally call "load_image_targphys_as" The only difference is that target address is hardcoded or feed from command line option. I don't prefe one than the other. Both of them are Ok to me. I could refine that if one of them is more preferable. chihmin.chao > > > > > ELF should work only if it has correct loading information. > > > > chihmin.chao > >> > >> > > >> > Nice doc, this example is exactly what I had in mind: > >> > > >> > qemu-system-riscv64 -M virt -m 256M -nographic \ > >> > -kernel build/platform/qemu/virt/firmware/fw_jump.elf \ > >> > -device > >> > > loader,file=<linux_build_directory>/arch/riscv/boot/Image,addr=0x80200000 \ > >> > -drive file=<path_to_linux_rootfs>,format=raw,id=hd0 \ > >> > -device virtio-blk-device,drive=hd0 \ > >> > -append "root=/dev/vda rw console=ttyS0" > >> > > >> > If the Image is an ELF, I assume we don't need to specify the address, > >> > because the device loader knows how to parse this format. Again, > >> > Alistair is the expert ;) > >> > >> Yep, an elf should just work. > >> > > describe the issue above > > > >> > >> > > >> > If for some reason it only works with Linux 5.0+, let's use these! > >> > >> Only 5.0+ builds an elf. > >> > >> Alistair > >> > >> > > >> > Regards, > >> > > >> > Phil. >
On Thu, Jul 18, 2019 at 8:00 AM Chih-Min Chao <chihmin.chao@sifive.com> wrote: > > > > On Thu, Jul 18, 2019 at 6:47 AM Alistair Francis <alistair23@gmail.com> wrote: >> >> On Tue, Jul 16, 2019 at 10:21 PM Chih-Min Chao <chihmin.chao@sifive.com> wrote: >> > >> > >> > >> > On Wed, Jul 17, 2019 at 6:59 AM Alistair Francis <alistair23@gmail.com> wrote: >> >> >> >> On Tue, Jul 16, 2019 at 2:50 PM Philippe Mathieu-Daudé >> >> <philmd@redhat.com> wrote: >> >> > >> >> > On 7/16/19 10:43 PM, Alistair Francis wrote: >> >> > > On Tue, Jul 16, 2019 at 6:56 AM Chih-Min Chao <chihmin.chao@sifive.com> wrote: >> >> > >> >> >> > >> >> >> > >> On Tue, Jul 16, 2019 at 12:34 AM Alistair Francis <alistair23@gmail.com> wrote: >> >> > >>> >> >> > >>> On Mon, Jul 15, 2019 at 6:02 AM Philippe Mathieu-Daudé >> >> > >>> <philmd@redhat.com> wrote: >> >> > >>>> >> >> > >>>> On 7/15/19 1:09 PM, Chih-Min Chao wrote: >> >> > >>>>> On Mon, Jul 15, 2019 at 5:15 PM Philippe Mathieu-Daudé >> >> > >>>>> <philmd@redhat.com <mailto:philmd@redhat.com>> wrote: >> >> > >>>>> >> >> > >>>>> On 7/15/19 11:08 AM, Chih-Min Chao wrote: >> >> > >>>>> > Similar to the mips + malta test, it boots a Linux kernel on a virt >> >> > >>>>> > board and verify the serial is working. Also, it relies on the serial >> >> > >>>>> > device set by the machine itself. >> >> > >>>>> > >> >> > >>>>> > If riscv64 is a target being built, "make check-acceptance" will >> >> > >>>>> > automatically include this test by the use of the "arch:riscv64" tags. >> >> > >>>>> > >> >> > >>>>> > Alternatively, this test can be run using: >> >> > >>>>> > >> >> > >>>>> > $ avocado run -t arch:riscv64 tests/acceptance >> >> > >>>>> > >> >> > >>>>> > packages >> >> > >>>>> > debian official >> >> > >>>>> > binutils-riscv64-linux-gnu_2.32-8 >> >> > >>>>> > opensbi_0.4-1_all >> >> > >>>>> > linux-image-4.19.0-5-riscv64 4.19.37-4 >> >> > >>>>> > third-party >> >> > >>>>> > >> >> > >>>>> https://github.com/groeck/linux-build-test/rootfs/riscv64/rootfs.cpio.gz >> >> > >>>>> > (the repo is also used in mips target acceptance) >> >> > >>>>> > >> >> > >>>>> > Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com >> >> > >>>>> <mailto:chihmin.chao@sifive.com>> >> >> > >>>>> > --- >> >> > >>>>> > .travis.yml | 2 +- >> >> > >>>>> > tests/acceptance/boot_linux_console.py | 66 >> >> > >>>>> ++++++++++++++++++++++++++++++++++ >> >> > >>>>> > 2 files changed, 67 insertions(+), 1 deletion(-) >> >> > >>>>> > >> >> > >>>>> > diff --git a/.travis.yml b/.travis.yml >> >> > >>>>> > index 5d3d6ee..21fcead 100644 >> >> > >>>>> > --- a/.travis.yml >> >> > >>>>> > +++ b/.travis.yml >> >> > >>>>> > @@ -232,7 +232,7 @@ matrix: >> >> > >>>>> > >> >> > >>>>> > # Acceptance (Functional) tests >> >> > >>>>> > - env: >> >> > >>>>> > - - CONFIG="--python=/usr/bin/python3 >> >> > >>>>> --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu" >> >> > >>>>> > + - CONFIG="--python=/usr/bin/python3 >> >> > >>>>> --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu,riscv64-softmmu" >> >> > >>>>> > - TEST_CMD="make check-acceptance" >> >> > >>>>> > after_failure: >> >> > >>>>> > - cat tests/results/latest/job.log >> >> > >>>>> > diff --git a/tests/acceptance/boot_linux_console.py >> >> > >>>>> b/tests/acceptance/boot_linux_console.py >> >> > >>>>> > index 3215950..0f638bc 100644 >> >> > >>>>> > --- a/tests/acceptance/boot_linux_console.py >> >> > >>>>> > +++ b/tests/acceptance/boot_linux_console.py >> >> > >>>>> > @@ -354,3 +354,69 @@ class BootLinuxConsole(Test): >> >> > >>>>> > self.vm.launch() >> >> > >>>>> > console_pattern = 'Kernel command line: %s' % >> >> > >>>>> kernel_command_line >> >> > >>>>> > self.wait_for_console_pattern(console_pattern) >> >> > >>>>> > + >> >> > >>>>> > + def test_riscv64_virt(self): >> >> > >>>>> > + """ >> >> > >>>>> > + :avocado: tags=arch:riscv64 >> >> > >>>>> > + :avocado: tags=machine:virt >> >> > >>>>> > + """ >> >> > >>>>> > + deb_url = ('https://snapshot.debian.org/archive/debian/' >> >> > >>>>> > + '20190424T171759Z/pool/main/b/binutils/' >> >> > >>>>> > + >> >> > >>>>> 'binutils-riscv64-linux-gnu_2.32-8_amd64.deb') >> >> > >>>>> > + deb_hash = ('7fe376fd4452696c03acd508d6d613ca553ea15e') >> >> > >>>>> > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) >> >> > >>>>> > + objcopy_path = '/usr/bin/riscv64-linux-gnu-objcopy' >> >> > >>>>> > + objcopy_path = self.extract_from_deb(deb_path, objcopy_path) >> >> > >>>>> > + libbfd_path = >> >> > >>>>> '/usr/lib/x86_64-linux-gnu/libbfd-2.32-riscv64.so >> >> > >>>>> <http://libbfd-2.32-riscv64.so>' >> >> > >>>>> > + libbfd_path = self.extract_from_deb(deb_path, libbfd_path) >> >> > >>>>> > + process.run('ls -al %s' % (objcopy_path)) >> >> > >>>>> > + >> >> > >>>>> > + deb_url = ('https://snapshot.debian.org/archive/debian/' >> >> > >>>>> > + '20190708T032337Z/pool/main/o/opensbi/' >> >> > >>>>> > + 'opensbi_0.4-1_all.deb') >> >> > >>>>> > + deb_hash = ('2319dcd702958291d323acf5649fd98a11d90112') >> >> > >>>>> > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) >> >> > >>>>> > + opensbi_path = ('/usr/lib/riscv64-linux-gnu/opensbi/' >> >> > >>>>> > + 'qemu/virt/fw_jump.elf') >> >> > >>>>> > + opensbi_path = self.extract_from_deb(deb_path, opensbi_path) >> >> > >>>>> > + >> >> > >>>>> > + deb_url = >> >> > >>>>> ('https://snapshot.debian.org/archive/debian-ports/' >> >> > >>>>> > + '20190620T095935Z/pool-riscv64/main/l/linux/' >> >> > >>>>> > + >> >> > >>>>> 'linux-image-4.19.0-5-riscv64_4.19.37-4_riscv64.deb') >> >> > >>>>> > + deb_hash = ('bf5b5680c41d92134d22caef4fbd277c5217e1f0') >> >> > >>>>> > + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) >> >> > >>>>> > + kernel_path = '/boot/vmlinux-4.19.0-5-riscv64' >> >> > >>>>> > + kernel_path = self.extract_from_deb(deb_path, kernel_path) >> >> > >>>>> > + kimage_path = self.workdir + "/Image" >> >> > >>>>> > + env = os.environ >> >> > >>>>> > + env['LD_LIBRARY_PATH'] = ('%s:' % >> >> > >>>>> (os.path.dirname(libbfd_path)) + >> >> > >>>>> > + env.get('LD_LIBRARY_PATH', '')) >> >> > >>>>> > + process.run(('%s -O binary -O binary -R' >> >> > >>>>> > + '.note -R .note.gnu.build-id -R .comment -S >> >> > >>>>> %s %s') % >> >> > >>>>> > + (objcopy_path, kernel_path, kimage_path)) >> >> > >>>>> >> >> > >>>>> Please explain why you need to do that... >> >> > >>>>> >> >> > >>>>> Also note these tests are run on other host architecture than x86, at >> >> > >>>>> least ppc64/s390x (so this won't work there). >> >> > >>>>> >> >> > >>>>> it is because riscv64 vmlinux doesn't have physical loading address >> >> > >>>>> information and >> >> > >>>>> depends on certain stage bootloader to move kernel raw data to specific >> >> > >>>>> physical address (0x8020_0000) >> >> > >>>>> >> >> > >>>>> The vmlinux program headers are >> >> > >>>>> Type Offset VirtAddr PhysAddr >> >> > >>>>> FileSiz MemSiz Flg Align >> >> > >>>>> LOAD 0x001000 0xffffffe000000000 0x0000000000000000 0x0303a6 >> >> > >>>>> 0x0303a6 R E 0x1000 >> >> > >>>>> LOAD 0x032000 0xffffffe000031000 0x0000000000031000 0x828f0c >> >> > >>>>> 0x828f0c RWE 0x1000 >> >> > >>>>> NOTE 0x85aec0 0xffffffe000859ec0 0x0000000000859ec0 0x00004c >> >> > >>>>> 0x00004c R 0x4 >> >> > >>>>> >> >> > >>>>> For legacy bootloader, bbl, It can handle payload in ELF format. >> >> > >>>>> However, for the newer OpenSBI, it can only handle raw data and >> >> > >>>>> debian doesn't provide linux image in raw data format. >> >> > >>> >> >> > >>> This doesn't sound right. You should just be able to say -kernel >> >> > >>> <anything> and it should work. It has worked for me with vmlinux and >> >> > >>> Image files when using master (not the 4.0 release but master/4.1). >> >> > >>> Although all of my testing was with the 5.1 kernel, so maybe there is >> >> > >>> a difference there? >> >> > >>> >> >> > >>> What isn't working for you? Can you include the errors and output of -d in_asm? >> >> > >>> >> >> > >>> >> >> > >>> Alistair >> >> > >> >> >> > >> >> >> > >> Hi Alistair, >> >> > >> I have come across error before starting target simulation. What I means is to execute >> >> > >> qemu-system-riscv64 -M virt -m 256M -nographic -bios ./opensbi/build/platform/qemu/virt/firmware/fw_jump.elf -kernel vmlinux >> >> > >> then get the error message >> >> > >> rom: requested regions overlap (rom mrom.reset. free=0x000000000001eb7c, addr=0x0000000000001000) >> >> > >> qemu-system-riscv64: rom check and register reset failed >> >> > > >> >> > > Hmmm.... I don't remember seeing this problem in my testing, but it >> >> > > does seem to make sense. >> >> > > >> >> > > We have two options here: >> >> > > 1. Use the Image file from Linux 5.0+ (my preferred option as 4.19 is >> >> > > getting old) >> > >> > I choose 4.19 version rather than 5.0+ because 4.19 is stable branch maintained by Greg. >> > But it is ok to use 5.0 trunk, the latest version provided by debian. >> > >> >> >> >> > > 2. Use the device loader (documented here: >> >> > > https://github.com/riscv/opensbi/blob/master/docs/platform/qemu_virt.md) >> > >> > >> > The document describes two user cases >> > 1. fw_payload.elf >> > a. include the Image (raw data file, not elf) into data section >> > b. -kernel load the each part to the correct address >> > >> > the program header of fw_payload.elf are >> > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align >> > LOAD 0x0000b0 0x0000000080000000 0x0000000080000000 0x00a008 0x00b0b8 RWE 0x10 <- fw_payload main program >> > LOAD 0x00a0b8 0x0000000080200000 0x0000000080200000 0x8dbe20 0x8dbe20 R E 0x1 <- arch/riscv/boot/Image or u-boot.bin >> > >> > 2. fw_jump.elf >> > a. use "-kernel <raw image> or -device loader,file=<raw Image>,addr=0x80200000" to load correct address >> > b. fw_jump.elf just jump to the entry address 0x80200000 >> > >> > >> > The issues are >> > a. debian linux-image package only provides vmlinux. >> >> This can be fixed by upgrading the kernel version. Fedora should have >> a 5.2 kernel that you can use instead of Debian. >> >> > so I use objcopy in acceptance test >> > b. riscv64 vmlinux doesn't have correct PhysAddr and -kernel can't move data to expected address >> > explicit load the Image to specific >> > -kernel raw_image (if file is not elf or uImage, riscv_kerner_loader treat it is as raw image and place it at 0x8020_0000) >> > -device loader,file=<raw_image>,0x80200000 (do the same thing) >> >> Does the device loader not work? >> >> Alistair > > > The device loader works for "Image" case (raw data) > If the data is raw image, for riscv_load_kernel implementation, "-kernel <raw_image>" and -device loader,file=<raw_image>,0x80200000 are the same. > They finally call "load_image_targphys_as" > The only difference is that target address is hardcoded or feed from command line option. > > I don't prefe one than the other. Both of them are Ok to me. I could refine that if one of them is more preferable. I'm a little confused with what you mean, so if you have something that will work just send a new version and we can discuss it there. PS: I'm still in favour of just using a newer kernel and a Image file. Alistair > > > chihmin.chao >> >> >> > >> > ELF should work only if it has correct loading information. >> > >> > chihmin.chao >> >> >> >> > >> >> > Nice doc, this example is exactly what I had in mind: >> >> > >> >> > qemu-system-riscv64 -M virt -m 256M -nographic \ >> >> > -kernel build/platform/qemu/virt/firmware/fw_jump.elf \ >> >> > -device >> >> > loader,file=<linux_build_directory>/arch/riscv/boot/Image,addr=0x80200000 \ >> >> > -drive file=<path_to_linux_rootfs>,format=raw,id=hd0 \ >> >> > -device virtio-blk-device,drive=hd0 \ >> >> > -append "root=/dev/vda rw console=ttyS0" >> >> > >> >> > If the Image is an ELF, I assume we don't need to specify the address, >> >> > because the device loader knows how to parse this format. Again, >> >> > Alistair is the expert ;) >> >> >> >> Yep, an elf should just work. >> >> >> > describe the issue above >> > >> >> >> >> > >> >> > If for some reason it only works with Linux 5.0+, let's use these! >> >> >> >> Only 5.0+ builds an elf. >> >> >> >> Alistair >> >> >> >> > >> >> > Regards, >> >> > >> >> > Phil.
On Thu, Jul 18, 2019 at 11:34 PM Alistair Francis <alistair23@gmail.com> wrote: > On Thu, Jul 18, 2019 at 8:00 AM Chih-Min Chao <chihmin.chao@sifive.com> > wrote: > > > > > > > > On Thu, Jul 18, 2019 at 6:47 AM Alistair Francis <alistair23@gmail.com> > wrote: > >> > >> On Tue, Jul 16, 2019 at 10:21 PM Chih-Min Chao <chihmin.chao@sifive.com> > wrote: > >> > > >> > > >> > > >> > On Wed, Jul 17, 2019 at 6:59 AM Alistair Francis < > alistair23@gmail.com> wrote: > >> >> > >> >> On Tue, Jul 16, 2019 at 2:50 PM Philippe Mathieu-Daudé > >> >> <philmd@redhat.com> wrote: > >> >> > > >> >> > On 7/16/19 10:43 PM, Alistair Francis wrote: > >> >> > > On Tue, Jul 16, 2019 at 6:56 AM Chih-Min Chao < > chihmin.chao@sifive.com> wrote: > >> >> > >> > >> >> > >> > >> >> > >> On Tue, Jul 16, 2019 at 12:34 AM Alistair Francis < > alistair23@gmail.com> wrote: > >> >> > >>> > >> >> > >>> On Mon, Jul 15, 2019 at 6:02 AM Philippe Mathieu-Daudé > >> >> > >>> <philmd@redhat.com> wrote: > >> >> > >>>> > >> >> > >>>> On 7/15/19 1:09 PM, Chih-Min Chao wrote: > >> >> > >>>>> On Mon, Jul 15, 2019 at 5:15 PM Philippe Mathieu-Daudé > >> >> > >>>>> <philmd@redhat.com <mailto:philmd@redhat.com>> wrote: > >> >> > >>>>> > >> >> > >>>>> On 7/15/19 11:08 AM, Chih-Min Chao wrote: > >> >> > >>>>> > Similar to the mips + malta test, it boots a Linux > kernel on a virt > >> >> > >>>>> > board and verify the serial is working. Also, it > relies on the serial > >> >> > >>>>> > device set by the machine itself. > >> >> > >>>>> > > >> >> > >>>>> > If riscv64 is a target being built, "make > check-acceptance" will > >> >> > >>>>> > automatically include this test by the use of the > "arch:riscv64" tags. > >> >> > >>>>> > > >> >> > >>>>> > Alternatively, this test can be run using: > >> >> > >>>>> > > >> >> > >>>>> > $ avocado run -t arch:riscv64 tests/acceptance > >> >> > >>>>> > > >> >> > >>>>> > packages > >> >> > >>>>> > debian official > >> >> > >>>>> > binutils-riscv64-linux-gnu_2.32-8 > >> >> > >>>>> > opensbi_0.4-1_all > >> >> > >>>>> > linux-image-4.19.0-5-riscv64 4.19.37-4 > >> >> > >>>>> > third-party > >> >> > >>>>> > > >> >> > >>>>> > https://github.com/groeck/linux-build-test/rootfs/riscv64/rootfs.cpio.gz > >> >> > >>>>> > (the repo is also used in mips target acceptance) > >> >> > >>>>> > > >> >> > >>>>> > Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com > >> >> > >>>>> <mailto:chihmin.chao@sifive.com>> > >> >> > >>>>> > --- > >> >> > >>>>> > .travis.yml | 2 +- > >> >> > >>>>> > tests/acceptance/boot_linux_console.py | 66 > >> >> > >>>>> ++++++++++++++++++++++++++++++++++ > >> >> > >>>>> > 2 files changed, 67 insertions(+), 1 deletion(-) > >> >> > >>>>> > > >> >> > >>>>> > diff --git a/.travis.yml b/.travis.yml > >> >> > >>>>> > index 5d3d6ee..21fcead 100644 > >> >> > >>>>> > --- a/.travis.yml > >> >> > >>>>> > +++ b/.travis.yml > >> >> > >>>>> > @@ -232,7 +232,7 @@ matrix: > >> >> > >>>>> > > >> >> > >>>>> > # Acceptance (Functional) tests > >> >> > >>>>> > - env: > >> >> > >>>>> > - - CONFIG="--python=/usr/bin/python3 > >> >> > >>>>> > --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu" > >> >> > >>>>> > + - CONFIG="--python=/usr/bin/python3 > >> >> > >>>>> > --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu,riscv64-softmmu" > >> >> > >>>>> > - TEST_CMD="make check-acceptance" > >> >> > >>>>> > after_failure: > >> >> > >>>>> > - cat tests/results/latest/job.log > >> >> > >>>>> > diff --git a/tests/acceptance/boot_linux_console.py > >> >> > >>>>> b/tests/acceptance/boot_linux_console.py > >> >> > >>>>> > index 3215950..0f638bc 100644 > >> >> > >>>>> > --- a/tests/acceptance/boot_linux_console.py > >> >> > >>>>> > +++ b/tests/acceptance/boot_linux_console.py > >> >> > >>>>> > @@ -354,3 +354,69 @@ class BootLinuxConsole(Test): > >> >> > >>>>> > self.vm.launch() > >> >> > >>>>> > console_pattern = 'Kernel command line: %s' % > >> >> > >>>>> kernel_command_line > >> >> > >>>>> > self.wait_for_console_pattern(console_pattern) > >> >> > >>>>> > + > >> >> > >>>>> > + def test_riscv64_virt(self): > >> >> > >>>>> > + """ > >> >> > >>>>> > + :avocado: tags=arch:riscv64 > >> >> > >>>>> > + :avocado: tags=machine:virt > >> >> > >>>>> > + """ > >> >> > >>>>> > + deb_url = (' > https://snapshot.debian.org/archive/debian/' > >> >> > >>>>> > + > '20190424T171759Z/pool/main/b/binutils/' > >> >> > >>>>> > + > >> >> > >>>>> 'binutils-riscv64-linux-gnu_2.32-8_amd64.deb') > >> >> > >>>>> > + deb_hash = > ('7fe376fd4452696c03acd508d6d613ca553ea15e') > >> >> > >>>>> > + deb_path = self.fetch_asset(deb_url, > asset_hash=deb_hash) > >> >> > >>>>> > + objcopy_path = > '/usr/bin/riscv64-linux-gnu-objcopy' > >> >> > >>>>> > + objcopy_path = > self.extract_from_deb(deb_path, objcopy_path) > >> >> > >>>>> > + libbfd_path = > >> >> > >>>>> '/usr/lib/x86_64-linux-gnu/libbfd-2.32-riscv64.so > >> >> > >>>>> <http://libbfd-2.32-riscv64.so>' > >> >> > >>>>> > + libbfd_path = self.extract_from_deb(deb_path, > libbfd_path) > >> >> > >>>>> > + process.run('ls -al %s' % (objcopy_path)) > >> >> > >>>>> > + > >> >> > >>>>> > + deb_url = (' > https://snapshot.debian.org/archive/debian/' > >> >> > >>>>> > + > '20190708T032337Z/pool/main/o/opensbi/' > >> >> > >>>>> > + 'opensbi_0.4-1_all.deb') > >> >> > >>>>> > + deb_hash = > ('2319dcd702958291d323acf5649fd98a11d90112') > >> >> > >>>>> > + deb_path = self.fetch_asset(deb_url, > asset_hash=deb_hash) > >> >> > >>>>> > + opensbi_path = > ('/usr/lib/riscv64-linux-gnu/opensbi/' > >> >> > >>>>> > + 'qemu/virt/fw_jump.elf') > >> >> > >>>>> > + opensbi_path = > self.extract_from_deb(deb_path, opensbi_path) > >> >> > >>>>> > + > >> >> > >>>>> > + deb_url = > >> >> > >>>>> ('https://snapshot.debian.org/archive/debian-ports/' > >> >> > >>>>> > + > '20190620T095935Z/pool-riscv64/main/l/linux/' > >> >> > >>>>> > + > >> >> > >>>>> 'linux-image-4.19.0-5-riscv64_4.19.37-4_riscv64.deb') > >> >> > >>>>> > + deb_hash = > ('bf5b5680c41d92134d22caef4fbd277c5217e1f0') > >> >> > >>>>> > + deb_path = self.fetch_asset(deb_url, > asset_hash=deb_hash) > >> >> > >>>>> > + kernel_path = '/boot/vmlinux-4.19.0-5-riscv64' > >> >> > >>>>> > + kernel_path = self.extract_from_deb(deb_path, > kernel_path) > >> >> > >>>>> > + kimage_path = self.workdir + "/Image" > >> >> > >>>>> > + env = os.environ > >> >> > >>>>> > + env['LD_LIBRARY_PATH'] = ('%s:' % > >> >> > >>>>> (os.path.dirname(libbfd_path)) + > >> >> > >>>>> > + > env.get('LD_LIBRARY_PATH', '')) > >> >> > >>>>> > + process.run(('%s -O binary -O binary -R' > >> >> > >>>>> > + '.note -R .note.gnu.build-id -R > .comment -S > >> >> > >>>>> %s %s') % > >> >> > >>>>> > + (objcopy_path, kernel_path, > kimage_path)) > >> >> > >>>>> > >> >> > >>>>> Please explain why you need to do that... > >> >> > >>>>> > >> >> > >>>>> Also note these tests are run on other host architecture > than x86, at > >> >> > >>>>> least ppc64/s390x (so this won't work there). > >> >> > >>>>> > >> >> > >>>>> it is because riscv64 vmlinux doesn't have physical loading > address > >> >> > >>>>> information and > >> >> > >>>>> depends on certain stage bootloader to move kernel raw data > to specific > >> >> > >>>>> physical address (0x8020_0000) > >> >> > >>>>> > >> >> > >>>>> The vmlinux program headers are > >> >> > >>>>> Type Offset VirtAddr > PhysAddr > >> >> > >>>>> FileSiz MemSiz Flg Align > >> >> > >>>>> LOAD 0x001000 0xffffffe000000000 > 0x0000000000000000 0x0303a6 > >> >> > >>>>> 0x0303a6 R E 0x1000 > >> >> > >>>>> LOAD 0x032000 0xffffffe000031000 > 0x0000000000031000 0x828f0c > >> >> > >>>>> 0x828f0c RWE 0x1000 > >> >> > >>>>> NOTE 0x85aec0 0xffffffe000859ec0 > 0x0000000000859ec0 0x00004c > >> >> > >>>>> 0x00004c R 0x4 > >> >> > >>>>> > >> >> > >>>>> For legacy bootloader, bbl, It can handle payload in ELF > format. > >> >> > >>>>> However, for the newer OpenSBI, it can only handle raw data > and > >> >> > >>>>> debian doesn't provide linux image in raw data format. > >> >> > >>> > >> >> > >>> This doesn't sound right. You should just be able to say > -kernel > >> >> > >>> <anything> and it should work. It has worked for me with > vmlinux and > >> >> > >>> Image files when using master (not the 4.0 release but > master/4.1). > >> >> > >>> Although all of my testing was with the 5.1 kernel, so maybe > there is > >> >> > >>> a difference there? > >> >> > >>> > >> >> > >>> What isn't working for you? Can you include the errors and > output of -d in_asm? > >> >> > >>> > >> >> > >>> > >> >> > >>> Alistair > >> >> > >> > >> >> > >> > >> >> > >> Hi Alistair, > >> >> > >> I have come across error before starting target simulation. > What I means is to execute > >> >> > >> qemu-system-riscv64 -M virt -m 256M -nographic > -bios ./opensbi/build/platform/qemu/virt/firmware/fw_jump.elf -kernel > vmlinux > >> >> > >> then get the error message > >> >> > >> rom: requested regions overlap (rom mrom.reset. > free=0x000000000001eb7c, addr=0x0000000000001000) > >> >> > >> qemu-system-riscv64: rom check and register reset > failed > >> >> > > > >> >> > > Hmmm.... I don't remember seeing this problem in my testing, but > it > >> >> > > does seem to make sense. > >> >> > > > >> >> > > We have two options here: > >> >> > > 1. Use the Image file from Linux 5.0+ (my preferred option as > 4.19 is > >> >> > > getting old) > >> > > >> > I choose 4.19 version rather than 5.0+ because 4.19 is stable > branch maintained by Greg. > >> > But it is ok to use 5.0 trunk, the latest version provided by debian. > >> > > >> >> > >> >> > > 2. Use the device loader (documented here: > >> >> > > > https://github.com/riscv/opensbi/blob/master/docs/platform/qemu_virt.md) > >> > > >> > > >> > The document describes two user cases > >> > 1. fw_payload.elf > >> > a. include the Image (raw data file, not elf) into data section > >> > b. -kernel load the each part to the correct address > >> > > >> > the program header of fw_payload.elf are > >> > Type Offset VirtAddr PhysAddr > FileSiz MemSiz Flg Align > >> > LOAD 0x0000b0 0x0000000080000000 0x0000000080000000 > 0x00a008 0x00b0b8 RWE 0x10 <- fw_payload main program > >> > LOAD 0x00a0b8 0x0000000080200000 0x0000000080200000 > 0x8dbe20 0x8dbe20 R E 0x1 <- arch/riscv/boot/Image or > u-boot.bin > >> > > >> > 2. fw_jump.elf > >> > a. use "-kernel <raw image> or -device loader,file=<raw > Image>,addr=0x80200000" to load correct address > >> > b. fw_jump.elf just jump to the entry address 0x80200000 > >> > > >> > > >> > The issues are > >> > a. debian linux-image package only provides vmlinux. > >> > >> This can be fixed by upgrading the kernel version. Fedora should have > >> a 5.2 kernel that you can use instead of Debian. > >> > >> > so I use objcopy in acceptance test > >> > b. riscv64 vmlinux doesn't have correct PhysAddr and -kernel can't > move data to expected address > >> > explicit load the Image to specific > >> > -kernel raw_image (if file is not elf or uImage, > riscv_kerner_loader treat it is as raw image and place it at 0x8020_0000) > >> > -device loader,file=<raw_image>,0x80200000 (do the same > thing) > >> > >> Does the device loader not work? > >> > >> Alistair > > > > > > The device loader works for "Image" case (raw data) > > If the data is raw image, for riscv_load_kernel implementation, > "-kernel <raw_image>" and -device loader,file=<raw_image>,0x80200000 are > the same. > > They finally call "load_image_targphys_as" > > The only difference is that target address is hardcoded or feed from > command line option. > > > > I don't prefe one than the other. Both of them are Ok to me. I could > refine that if one of them is more preferable. > > I'm a little confused with what you mean, so if you have something > that will work just send a new version and we can discuss it there. > > PS: I'm still in favour of just using a newer kernel and a Image file. > > Alistair > > ok, I will use the latest kernel available in Debian package and refine the command in next version. chihmin.chao > > > > > > chihmin.chao > >> > >> > >> > > >> > ELF should work only if it has correct loading information. > >> > > >> > chihmin.chao > >> >> > >> >> > > >> >> > Nice doc, this example is exactly what I had in mind: > >> >> > > >> >> > qemu-system-riscv64 -M virt -m 256M -nographic \ > >> >> > -kernel build/platform/qemu/virt/firmware/fw_jump.elf \ > >> >> > -device > >> >> > > loader,file=<linux_build_directory>/arch/riscv/boot/Image,addr=0x80200000 \ > >> >> > -drive file=<path_to_linux_rootfs>,format=raw,id=hd0 \ > >> >> > -device virtio-blk-device,drive=hd0 \ > >> >> > -append "root=/dev/vda rw console=ttyS0" > >> >> > > >> >> > If the Image is an ELF, I assume we don't need to specify the > address, > >> >> > because the device loader knows how to parse this format. Again, > >> >> > Alistair is the expert ;) > >> >> > >> >> Yep, an elf should just work. > >> >> > >> > describe the issue above > >> > > >> >> > >> >> > > >> >> > If for some reason it only works with Linux 5.0+, let's use these! > >> >> > >> >> Only 5.0+ builds an elf. > >> >> > >> >> Alistair > >> >> > >> >> > > >> >> > Regards, > >> >> > > >> >> > Phil. >
diff --git a/.travis.yml b/.travis.yml index 5d3d6ee..21fcead 100644 --- a/.travis.yml +++ b/.travis.yml @@ -232,7 +232,7 @@ matrix: # Acceptance (Functional) tests - env: - - CONFIG="--python=/usr/bin/python3 --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu" + - CONFIG="--python=/usr/bin/python3 --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,aarch64-softmmu,arm-softmmu,s390x-softmmu,alpha-softmmu,riscv64-softmmu" - TEST_CMD="make check-acceptance" after_failure: - cat tests/results/latest/job.log diff --git a/tests/acceptance/boot_linux_console.py b/tests/acceptance/boot_linux_console.py index 3215950..0f638bc 100644 --- a/tests/acceptance/boot_linux_console.py +++ b/tests/acceptance/boot_linux_console.py @@ -354,3 +354,69 @@ class BootLinuxConsole(Test): self.vm.launch() console_pattern = 'Kernel command line: %s' % kernel_command_line self.wait_for_console_pattern(console_pattern) + + def test_riscv64_virt(self): + """ + :avocado: tags=arch:riscv64 + :avocado: tags=machine:virt + """ + deb_url = ('https://snapshot.debian.org/archive/debian/' + '20190424T171759Z/pool/main/b/binutils/' + 'binutils-riscv64-linux-gnu_2.32-8_amd64.deb') + deb_hash = ('7fe376fd4452696c03acd508d6d613ca553ea15e') + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) + objcopy_path = '/usr/bin/riscv64-linux-gnu-objcopy' + objcopy_path = self.extract_from_deb(deb_path, objcopy_path) + libbfd_path = '/usr/lib/x86_64-linux-gnu/libbfd-2.32-riscv64.so' + libbfd_path = self.extract_from_deb(deb_path, libbfd_path) + process.run('ls -al %s' % (objcopy_path)) + + deb_url = ('https://snapshot.debian.org/archive/debian/' + '20190708T032337Z/pool/main/o/opensbi/' + 'opensbi_0.4-1_all.deb') + deb_hash = ('2319dcd702958291d323acf5649fd98a11d90112') + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) + opensbi_path = ('/usr/lib/riscv64-linux-gnu/opensbi/' + 'qemu/virt/fw_jump.elf') + opensbi_path = self.extract_from_deb(deb_path, opensbi_path) + + deb_url = ('https://snapshot.debian.org/archive/debian-ports/' + '20190620T095935Z/pool-riscv64/main/l/linux/' + 'linux-image-4.19.0-5-riscv64_4.19.37-4_riscv64.deb') + deb_hash = ('bf5b5680c41d92134d22caef4fbd277c5217e1f0') + deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash) + kernel_path = '/boot/vmlinux-4.19.0-5-riscv64' + kernel_path = self.extract_from_deb(deb_path, kernel_path) + kimage_path = self.workdir + "/Image" + env = os.environ + env['LD_LIBRARY_PATH'] = ('%s:' % (os.path.dirname(libbfd_path)) + + env.get('LD_LIBRARY_PATH', '')) + process.run(('%s -O binary -O binary -R' + '.note -R .note.gnu.build-id -R .comment -S %s %s') % + (objcopy_path, kernel_path, kimage_path)) + + initrd_url = ('https://github.com/groeck/linux-build-test/raw/' + '8584a59ed9e5eb5ee7ca91f6d74bbb06619205b8/rootfs/' + 'riscv64/rootfs.cpio.gz') + initrd_hash = 'f4867d263754961b6f626cdcdc0cb334c47e3b49' + initrd_path = self.fetch_asset(initrd_url, asset_hash=initrd_hash) + + self.vm.set_machine('virt') + self.vm.set_console() + kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE + + 'console=ttyS0 noreboot') + self.vm.add_args('-bios', opensbi_path, + '-kernel', kimage_path, + '-initrd', initrd_path, + '-append', kernel_command_line, + '-no-reboot') + + self.vm.launch() + self.wait_for_console_pattern('Boot successful.') + + self.exec_command_and_wait_for_pattern('cat /proc/cpuinfo', + 'isa') + self.exec_command_and_wait_for_pattern('uname -a', + 'SMP Debian') + self.exec_command_and_wait_for_pattern('reboot', + 'reboot: Restarting system')
Similar to the mips + malta test, it boots a Linux kernel on a virt board and verify the serial is working. Also, it relies on the serial device set by the machine itself. If riscv64 is a target being built, "make check-acceptance" will automatically include this test by the use of the "arch:riscv64" tags. Alternatively, this test can be run using: $ avocado run -t arch:riscv64 tests/acceptance packages debian official binutils-riscv64-linux-gnu_2.32-8 opensbi_0.4-1_all linux-image-4.19.0-5-riscv64 4.19.37-4 third-party https://github.com/groeck/linux-build-test/rootfs/riscv64/rootfs.cpio.gz (the repo is also used in mips target acceptance) Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com> --- .travis.yml | 2 +- tests/acceptance/boot_linux_console.py | 66 ++++++++++++++++++++++++++++++++++ 2 files changed, 67 insertions(+), 1 deletion(-)