[coreboot] Re: Directly boot the image of Linux for RISC-V
Done! reference: https://github.com/hardenedlinux/coreboot-HiFiveUnleashed/tree/opensbi-test -- 王翔 安全研究员 广州市腾御安信息科技有限公司 广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024 -- Original -- From: "Philipp Hug"; Date: Thu, Apr 4, 2019 10:39 PM To: "王翔"; Cc: "j.neuschaefer"; "rminnich"; "coreboot"; "citypw"; Subject: Re: Directly boot the image of Linux for RISC-V Hi Xiang, I think the best way to integrate opensbi for now would be to put it into the payloads/external directory and execute it as a rampayload. (in m-mode) Philipp On Tue, 2 Apr 2019 at 11:32, 王翔 wrote: Hello Dear: I added some code to support linux binary directly as a payload to boot for RISC-V. modify: 1. opensbi is an open source sbi implementation(https://github.com/riscv/opensbi) 2. Linux binary is used as the payload of opensbi 3. The elf generated by opensbi compilation is used as the coreboot payload. Code reference: https://github.com/hardenedlinux/coreboot-HiFiveUnleashed/tree/r1 Whether to consider adding opensbi to 3rdparty? Do you have any suggestions? XiangWang -- 王翔 安全研究员 广州市腾御安信息科技有限公司 广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Directly boot the image of Linux for RISC-V
Hello Dear: I added some code to support linux binary directly as a payload to boot for RISC-V. modify: 1. opensbi is an open source sbi implementation(https://github.com/riscv/opensbi) 2. Linux binary is used as the payload of opensbi 3. The elf generated by opensbi compilation is used as the coreboot payload. Code reference: https://github.com/hardenedlinux/coreboot-HiFiveUnleashed/tree/r1 Whether to consider adding opensbi to 3rdparty? Do you have any suggestions? XiangWang -- 王翔 安全研究员 广州市腾御安信息科技有限公司 广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Please help me adapt coreboot to HiFive-Unleashed
Thank you very much, I have been changing the starting address of BBL through objcopy, I did not expect to modify the link script. By using the code provided by sifive (https://github.com/sifive/freedom-u-sdk), the Linux startup is successful. Thanks again !!! -- 王翔 安全研究员 广州市腾御安信息科技有限公司 广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024 -- Original -- From: "Jonathan Neuschäfer"; Date: Mon, Jan 7, 2019 06:24 AM To: "王翔"; Cc: "Jonathan Neuschäfer"; "philipp"; "citypw"; "coreboot"; Subject: Re: Please help me adapt coreboot to HiFive-Unleashed [resending, because I forgot to include coreboot@coreboot.org] > On Thu, Dec 20, 2018 at 11:56:17AM +0800, 王翔 wrote: > > I tried to adapt coreboot to HiFive-Unleashed and boot bbl with coreboot > > and run linux. > > My changes are as follows: > > > > https://github.com/hardenedlinux/coreboot-HiFiveUnleashed/tree/HiFive-Unleashed-Test-Change > > > > My code can run bbl, but it doesn't respond when bbl exits m-mode and > > enters linux. > > > > I use freedom-u-sdk to compile bbl. In order not to conflict with the > > coreboot memory address, execute the following command. > > riscv64-elf-objcopy --change-addresses 0x20 work/riscv-pk/bbl > > ../coreboot/payload.elf > > > > I don't know what I missed, what should I do, I hope to get your help. > > You could try to change the base address in bbl/bbl.lds. This might > help, if for example bbl finds _payload_start with a LUI instruction > rather than a AUIPC instruction. I have finally tested this. I used coreboot 4.8-2510-g75c6697322 (top of your HiFive-Unleashed-Test-Change branch), Linux 4.20, and bbl archive-1.9.1-132-ga02257a (current top of the master branch), with a patch in bbl/bbl.lds to change the base from 0x8000 to 0x8100: diff --git a/bbl/bbl.lds b/bbl/bbl.lds index 397cd3f..059d023 100644 --- a/bbl/bbl.lds +++ b/bbl/bbl.lds @@ -12,7 +12,7 @@ SECTIONS /**/ /* Begining of code and text segment */ - . = 0x8000; + . = 0x8100; _ftext = .; .text : I get the following output: > coreboot-4.8-2510-g75c6697322 Fri Jan 4 04:27:37 UTC 2019 bootblock > starting... > Boot mode: 15 > CBFS: 'Master Header Locator' located CBFS at [20100:c0) > CBFS: Locating 'fallback/romstage' > CBFS: Found @ offset 80 size 3745 > Hart 1 jumping to boot code at 0802, fdt: 00010dc8 > *(uint32_t*)fdt: 0xedfe0dd0 > Hart 0 jumping to boot code at 0802, fdt: 00010dc8 > *(uint32_t*)fdt: 0xedfe0dd0 > Hart 4 jumping to boot code at 0802, fdt: 00010dc8 > *(uint32_t*)fdt: 0xedfe0dd0 > Hart 3 jumping to boot code at 0802, fdt: 00010dc8 > *(uint32_t*)fdt: 0xedfe0dd0 > Hart 2 jumping to boot code at 0802, fdt: 00010dc8 > *(uint32_t*)fdt: 0xedfe0dd0 > > > CBMEM:ot-4.8-2510-g75c6697322 Fri Jan 4 04:27:37 UTC 2019 romstage > starting... > IMD: root @ 00027000 254 entries. > IMD: root @ 00027fffec00 62 entries. > CBFS: 'Master Header Locator' located CBFS at [20100:c0) > CBFS: Locating 'fallback/DTB' > CBFS: Found @ offset 8fc0 size 29e4 > CBFS: 'Master Header Locator' located CBFS at [20100:c0) > CBFS: Locating 'fallback/ramstage' > CBFS: Found @ offset 3800 size 53cb > Hart 0 jumping to boot code at 8000, fdt: 00027ffdb000 > *(uint32_t*)fdt: 0xedfe0dd0 > Hart 1 jumping to boot code at 8000, fdt: 00027ffdb000 > *(uint32_t*)fdt: 0xedfe0dd0 > Hart 4 jumping to boot code at 8000, fdt: 00027ffdb000 > *(uint32_t*)fdt: 0xedfe0dd0 > Hart 3 jumping to boot code at 8000, fdt: 00027ffdb000 > *(uint32_t*)fdt: 0xedfe0dd0 > Hart 2 jumping to boot code at 8000, fdt: 00027ffdb000 > *(uint32_t*)fdt: 0xedfe0dd0 > > > coreboot-4.8-2510-g75c6697322 Fri Jan 4 04:27:37 UTC 2019 ramstage > starting... > BS: BS_PRE_DEVICE times (us): entry 1 run 0 exit 0 > BS: BS_DEV_INIT_CHIPS times (us): entry 1 run 0 exit 0 > Enumerating buses... > CPU_CLUSTER: 0 enabled > scan_bus: scanning of bus Root Device took 2054 usecs > done > BS: BS_DEV_ENUMERATE times (us): entry 0 run 9290 exit 0 > Allocating resources... > Reading resources... > CPU_CLUSTER: 0 missing read_resources > Done reading resources. > Setting resources... > Done setting resources. > Done allocating resources. > BS: BS_DEV_RESOURCES times (us): entry 0 run 16149 exit 0 > Enabling resources... > d
[coreboot] Re: Please help me adapt coreboot to HiFive-Unleashed
itim@180 {
compatible = "sifive,itim0";
reg = <0x 0x0180 0x 0x4000>;
reg-names = "mem";
linux,phandle = <0x0004>;
phandle = <0x0004>;
}
itim@1808000 {
compatible = "sifive,itim0";
reg = <0x 0x01808000 0x 0x8000>;
reg-names = "mem";
linux,phandle = <0x0005>;
phandle = <0x0005>;
}
itim@181 {
compatible = "sifive,itim0";
reg = <0x 0x0181 0x 0x8000>;
reg-names = "mem";
linux,phandle = <0x0006>;
phandle = <0x0006>;
}
itim@1818000 {
compatible = "sifive,itim0";
reg = <0x 0x01818000 0x 0x8000>;
reg-names = "mem";
linux,phandle = <0x0007>;
phandle = <0x0007>;
}
itim@182 {
compatible = "sifive,itim0";
reg = <0x 0x0182 0x 0x8000>;
reg-names = "mem";
linux,phandle = <0x0008>;
phandle = <0x0008>;
}
memory-controller@100b {
compatible = "sifive,aloeddr0";
interrupt-parent = <0x000b>;
interrupts = <0x001f>;
reg = <0x 0x100b 0x 0x4000>;
reg-names = "control";
}
pci@20 {
#address-cells = <0x0003>;
#interrupt-cells = <0x0001>;
#size-cells = <0x0002>;
compatible = <0x786c6e78 0x2c617869 0x2d706369 0x652d686f 0x73742d31
0x2e30302e>;
device_type = "pci";
interrupt-map = <0x 0x 0x 0x0001 0x0017
0x0001 0x 0x 0x 0x0002 0x0017 0x0002
0x 0x 0x 0x0003 0x0017 0x0003 0x
0x000;
interrupt-map-mask = <0x 0x 0x 0x0007>;
interrupt-parent = <0x000b>;
interrupts = <0x0020>;
ranges = <0x0200 0x 0x4000 0x 0x4000
0x 0x2000>;
reg = <0x0020 0x 0x 0x0400>;
reg-names = "control";
interrupt-controller {
#address-cells = <0x>;
#interrupt-cells = <0x0001>;
interrupt-controller;
linux,phandle = <0x0017>;
phandle = <0x0017>;
}
}
pinctrl@1008 {
compatible = "sifive,pinctrl0";
reg = <0x 0x1008 0x 0x1000>;
reg-names = "control";
}
pwm@1002 {
compatible = "sifive,pwm0";
interrupt-parent = <0x000b>;
interrupts = <0x002a 0x002b 0x002c 0x002d>;
reg = <0x 0x1002 0x 0x1000>;
reg-names = "control";
clocks = <0x0016>;
sifive,approx-period = <0x000f4240>;
#pwm-cells = <0x0002>;
linux,phandle = <0x0018>;
phandle = <0x0018>;
}
pwm@10021000 {
compatible = "sifive,pwm0";
interrupt-parent = <0x000b>;
interrupts = <0x002e 0x002f 0x0030 0x0031>;
reg = <0x 0x10021000 0x 0x1000>;
reg-names = "control";
clocks = <0x0016>;
sifive,approx-period = <0x000f4240>;
#pwm-cells = <0x0002>;
}
pwmleds {
compatible = "pwm-leds";
heartbeat {
pwms = <0x0018 0x 0x>;
max-brightness = <0x00ff>;
linux,default-trigger = "heartbeat";
}
mtd {
pwms = <0x0018 0x0001 0x>;
max-brightness = <0x00ff>;
linux,default-trigger = "mtd";
}
netdev {
pwms = <0x0018 0x0002 0x>;
max-brightness = <0x00ff>;
linux,default-trigger = "netdev";
}
panic {
pwms = <0x0018 0x0003 0x>;
max-brightness = <0x00ff>;
linux,default-trigger = "panic";
}
}
rom@1000 {
compatible = "sifive,modeselect0";
reg = <0x 0x1000 0x 0x1000>;
reg-names = "mem";
}
rom@1 {
compatible = "sifive,maskrom0";
reg = <0x 0x0001 0x 0x8000>;
reg-names = "mem";
}
rom@a00 {
compatible = "ucbbar,cacheable-zero0";
reg = <0x 0x0a00 0x 0x0200>;
reg-names = &
[coreboot] Re: Please help me adapt coreboot to HiFive-Unleashed
> You could try to change the base address in bbl/bbl.lds. This might > help, if for example bbl finds _payload_start with a LUI instruction > rather than a AUIPC instruction. There is no problem loading the address of _payload_start, the machine code is as follows 8020038c:00200797 auipca5,0x200 80200390:c7478793 addia5,a5,-908 # 8040 <_payload_start> 80200394:4501lia0,0 80200396:00012717 auipca4,0x12 8020039a:c6f73523 sda5,-918(a4) # 80212000 8020039e:f4bff0ef jalra,802002e8 > Does bbl print its logo (the RV banner)? Yes, bbl print its logo. -- 王翔 安全研究员 广州市腾御安信息科技有限公司 广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024 -- Original -- From: "Jonathan Neuschäfer"; Date: Fri, Dec 21, 2018 03:59 PM To: "王翔"; Cc: "coreboot"; "j.neuschaefer"; "philipp"; "citypw"; Subject: Re: Please help me adapt coreboot to HiFive-Unleashed Hi, I'll be busy with christmas or travelling until January, so I can't spend much time on this now. Sorry. Please remind me in January. On Thu, Dec 20, 2018 at 11:56:17AM +0800, 王翔 wrote: > I tried to adapt coreboot to HiFive-Unleashed and boot bbl with coreboot and > run linux. > My changes are as follows: > > https://github.com/hardenedlinux/coreboot-HiFiveUnleashed/tree/HiFive-Unleashed-Test-Change > > My code can run bbl, but it doesn't respond when bbl exits m-mode and enters > linux. > > I use freedom-u-sdk to compile bbl. In order not to conflict with the > coreboot memory address, execute the following command. > riscv64-elf-objcopy --change-addresses 0x20 work/riscv-pk/bbl > ../coreboot/payload.elf > > I don't know what I missed, what should I do, I hope to get your help. You could try to change the base address in bbl/bbl.lds. This might help, if for example bbl finds _payload_start with a LUI instruction rather than a AUIPC instruction. Does bbl print its logo (the RV banner)? Jonathan___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Please help me adapt coreboot to HiFive-Unleashed
I tried to adapt coreboot to HiFive-Unleashed and boot bbl with coreboot and run linux. My changes are as follows: https://github.com/hardenedlinux/coreboot-HiFiveUnleashed/tree/HiFive-Unleashed-Test-Change My code can run bbl, but it doesn't respond when bbl exits m-mode and enters linux. I use freedom-u-sdk to compile bbl. In order not to conflict with the coreboot memory address, execute the following command. riscv64-elf-objcopy --change-addresses 0x20 work/riscv-pk/bbl ../coreboot/payload.elf I don't know what I missed, what should I do, I hope to get your help. -- 王翔 安全研究员 广州市腾御安信息科技有限公司 广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] The problem of coreboot porting to fu540
This is the code used to exits M-Mode. hart0 was paused before , because hart0 does not support S-Mode and cannot run kernel code. So there is no status information for hart0. -- 王翔 安全研究员 广州市腾御安信息科技有限公司 广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024 This is the code used to exits M-Mode. hart0 was paused before , because hart0 does not support S-Mode and cannot run kernel code. -- Original --This is the code used to exits M-Mode. hart0 was paused before , because hart0 does not support S-Mode and cannot run kernel code. From: "Jonathan Neuschäfer";This is the code used to exits M-Mode. hart0 was paused before , because hart0 does not supThis is the code used to exits M-Mode. hart0 was paused before , because hart0 does not support S-Mode and cannot run kernel code. port S-Mode and cannot run kernel code.This is the code used to exits M-Mode. hart0 was paused before , because hart0 does not support S-Mode and cannot run kernel code. Date: Mon, Dec 10, 2018 07:16 PMThis is the code used to exits M-Mode. hart0 was paused before , because hart0 does not support S-Mode and cannot run kernel code. To: "王翔"; Cc: "coreboot"; "j.neuschaefer"; "philipp"; "citypw"; This is the code used to exits M-Mode. hart0 was paused before , because hart0 does not support S-Mode and cannot run kernel code. Subject: Re: The problem of coreboot porting to fu540 Hi, On Mon, Dec 10, 2018 at 05:29:44PM +0800, 王翔 wrote:This is the code used to exits M-Mode. hart0 was paused before , because hart0 does not support S-Mode and cannot run kernel code. This is the code used to exits M-Mode. hart0 was paused before , because hart0 does not support S-Mode and cannot run kernThis is the code used to exits M-Mode. hart0 was paused before , because hart0 does not support S-Mode and cannot run kernel code. el code. > I use bbl as the coreboot's payload, bbl can start and running into the > enter_supervisor_mode function, but can't continue. This is the code used to > exits M-Mode. hart0 was paused before , because hart0 does not support > S-Mode and cannot run kernel code. > > I added some code to print register state before mret and print memory on > target address. > I debugged it for a long time and didn't know where the problem was. hoping > to get your help. > > > Below is my output: > > ``` > > mhartid : 2 [...] > mhartid : 1 [...] > mhartid : 3 [...] > mhartid : 4 [...] My first guess is that BBL is waiting for Hart 0, but I have not looked at BBL's code to verify that this could be the case. Jonathan-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] The problem of coreboot porting to fu540
I use bbl as the coreboot's payload, bbl can start and running into the enter_supervisor_mode function, but can't continue. I added some code to print register state before mret and print memory on target address. I debugged it for a long time and didn't know where the problem was. hoping to get your help. Below is my output: ``` mhartid : 2 mstatus : 800a6800 mie : 0008 mtvec: 80080004 mscratch : 8008cec0 mepc : 8028 mcause : 0002 mip : 0200 sstatus : 80026000 sie : stvec: 80280100 sscratch : sepc : ffe000927ff8 scause : 8005 sip : 0200 satp : mhartid : 1 mstatus : 800a6800 mie : 0008 mtvec: 80080004 mscratch : 8008bec0 mepc : 8028 mcause : 0002 mip : 0200 sstatus : 80026000 sie : stvec: 80280100 sscratch : sepc : ffe000927ff8 scause : 8005 sip : 0200 satp : mhartid : 3 mstatus : 800a6800 mie : 0008 mtvec: 80080004 mscratch : 8008dec0 mepc : 8028 mcause : 0002 mip : 0200 sstatus : 80026000 sie : stvec: 80280100 sscratch : sepc : ffe000927ff8 scause : 8005 sip : 0200 satp : mhartid : 4 mstatus : 800a6800 mie : 0008 mtvec: 80080004 mscratch : 8008eec0 mepc : 8028 mcause : 0001 mip : 0200 sstatus : 80026000 sie : stvec: ffe000927c74 sscratch : sepc : 80282240 scause : 0003 sip : 0200 satp : 8028: 73 10 40 10 97 31 d3 00 80280008: 93 81 c1 8d 99 62 73 b0 80280010: 02 10 93 86 01 16 05 46 80280018: af a6 c6 00 d9 ee 2a 84 80280020: ae 84 17 01 d0 00 13 01 80280028: e1 fd ef 20 00 1f ef 00 80280030: 80 02 17 62 d0 00 13 02 80280038: e2 a8 23 24 82 02 17 e1 80280040: cf 00 13 01 21 fc 09 65 80280048: 2a 91 22 85 a6 85 ef 20 80280050: 80 27 6f 00 40 68 9b 05 80280058: f0 ff 93 95 55 02 17 05 80280060: 00 00 13 05 25 fa 89 8d 80280068: ae 90 17 05 00 00 13 05 80280070: 65 03 2e 95 73 10 55 10 80280078: 17 56 db 00 13 06 86 f8 ``` ------ 王翔 安全研究员 广州市腾御安信息科技有限公司 广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] riscv: how to running coreboot on HiFive Unleashed?
I tried it again. Press reset key can see the serial output. Maybe the power is turned on too fast. The computer does not capture the serial port data. Below is my serial output > Welcome to minicom 2.7 > > OPTIONS: I18n > Compiled on Apr 22 2017, 09:14:19. > Port /dev/ttyUSB1, 12:14:37 > > Press CTRL-A Z for help on special keys > > > > coreboot-4.8-2282-gc88828daeb Mon Nov 26 09:56:26 UTC 2018 bootblock > starting... > Boot mode: 15 > Couldn't load romstage. Thank you for your help. 在2018年11月27 10时56分, "王翔"写道: I am sure my uart configuration is 115200 8N1 on /dev/ttyUSB1. I have a power cycle after the burn is complete. 在2018年11月26 18时03分, "Jonathan Neuschäfer"写道: Hi! On Mon, Nov 26, 2018 at 02:54:46PM +0800, 王翔 wrote: > I try to running coreboot on HiFive Unleashed, but nothing come from uart. > > > I tested by the following steps: > > > 1. Write hifive-unleashed-a00-1.0-2018-03-20.gpt to TF card. > 2. Change MSEL to 11 and boot linux > 3. Copy coreboot.rom via scp > 4. Write coreboot.rom to /dev/mtd0 by flashcp. > 5. Change MSEL to 15 and boot coreboot. No response on uart. > > > > Do you have any suggestions? How did you listen to the UART? Note that the FTDI Chip on the H5U will show up as two serial ports on the computer that it is connected to (usually /dev/ttyUSB0 and /dev/ttyUSB1). The first one is for JTAG and the second one is for UART. Also make sure that you configure the right baud rate (115200 usually) on /dev/ttyUSB1. You might also have to power-cycle the board and/or press the reset button. Sometimes that helps. If you continue to see no output, perhaps there is a bug in coreboot that prevents the output. Whenever I tested coreboot on the H5U, I could always see output, but I haven't tested it recently. Jonathan Neuschäfer -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] riscv: how to running coreboot on HiFive Unleashed?
I am sure my uart configuration is 115200 8N1 on /dev/ttyUSB1. I have a power cycle after the burn is complete. 在2018年11月26 18时03分, "Jonathan Neuschäfer"写道: Hi! On Mon, Nov 26, 2018 at 02:54:46PM +0800, 王翔 wrote: > I try to running coreboot on HiFive Unleashed, but nothing come from uart. > > > I tested by the following steps: > > > 1. Write hifive-unleashed-a00-1.0-2018-03-20.gpt to TF card. > 2. Change MSEL to 11 and boot linux > 3. Copy coreboot.rom via scp > 4. Write coreboot.rom to /dev/mtd0 by flashcp. > 5. Change MSEL to 15 and boot coreboot. No response on uart. > > > > Do you have any suggestions? How did you listen to the UART? Note that the FTDI Chip on the H5U will show up as two serial ports on the computer that it is connected to (usually /dev/ttyUSB0 and /dev/ttyUSB1). The first one is for JTAG and the second one is for UART. Also make sure that you configure the right baud rate (115200 usually) on /dev/ttyUSB1. You might also have to power-cycle the board and/or press the reset button. Sometimes that helps. If you continue to see no output, perhaps there is a bug in coreboot that prevents the output. Whenever I tested coreboot on the H5U, I could always see output, but I haven't tested it recently. Jonathan Neuschäfer -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] riscv: how to running coreboot on HiFive Unleashed?
I try to running coreboot on HiFive Unleashed, but nothing come from uart. I tested by the following steps: 1. Write hifive-unleashed-a00-1.0-2018-03-20.gpt to TF card. 2. Change MSEL to 11 and boot linux 3. Copy coreboot.rom via scp 4. Write coreboot.rom to /dev/mtd0 by flashcp. 5. Change MSEL to 15 and boot coreboot. No response on uart. Do you have any suggestions? -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] riscv: how to running coreboot on HiFive Unleashed?
I try to running coreboot on HiFive Unleashed, but nothing come from uart. I tested by the following steps: 1. Write hifive-unleashed-a00-1.0-2018-03-20.gpt to TF card. 2. Change MSEL to 11 and boot linux 3. Copy coreboot.rom via scp 4. Write coreboot.rom to /dev/mtd0 by flashcp. 5. Change MSEL to 15 and boot coreboot. No response on uart. Do you have any suggestions? -- 王翔 安全研究员 广州市腾御安信息科技有限公司 广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Loading Linux payloads on RISC-V
Yes, kernel can be start at any address.
You can refer to BBL implementation : https://github.com/riscv/riscv-pk
BBL converts vmlinux to binary and inserts it into the section named .payload
which is one section of BBL.
Because the size of the BBL cannot be known before compiling and linking, the
address of the payload is not specific.
在2018年09月27 04时29分, "Philipp Hug"写道:
In my local tree I just added the ram address in selfboot.
Doing this beforehand with cbfstool would be even better. (E.g. only when
choosing linux payload)
The FIT probably needs to be created by distro tools: assembling kernel, dt and
initramfs.
On Wed, Sep 26, 2018, 17:42 ron minnich wrote:
But the kernel can start anywhere. I don't see a reason to do this complex
objcopy step when all that is needed is to have cbfstool set some entries in
the SELF or just have selfboot use "0" to mean "somewhere useful"? Did I miss
something?
On Tue, Sep 25, 2018 at 10:32 PM 王翔 wrote:
This elf file is position-independent and can be loaded to any location. We can
add a simple script to handle it.
1. Convert vmlinux to binary by objcopy, the binary file name is flat_file
2. Write a simple assembly file (tmp.S), convert binary to object, the file
name is obj_file
```
.section .text
.globl _start
_start:
.incbin "flat_file"
```
command: as tmp.S -o obj_file
3. Relink. Linker script like this(tmp.ld):
```
ENTRY(_start)
SECTIONS {
. = target_address;
.text : { *(.text) }
}
```
command: ld -T tmp.ld obj_file
在2018年09月25 20时51分, "Philipp Hug"写道:
Am Di., 25. Sep. 2018 um 13:50 Uhr schrieb Jonathan Neuschäfer
:
Would FIT support require discussion/cooperation with other projects
like Linux or u-boot?
What seems to be missing is the kernel image format to be used within the FIT.
e.g. look at arm64:
https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/head.S#L73
https://github.com/coreboot/coreboot/blob/master/src/arch/arm64/fit_payload.c#L29
Philipp
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Loading Linux payloads on RISC-V
This elf file is position-independent and can be loaded to any location. We can
add a simple script to handle it.
1. Convert vmlinux to binary by objcopy, the binary file name is flat_file
2. Write a simple assembly file (tmp.S), convert binary to object, the file
name is obj_file
```
.section .text
.globl _start
_start:
.incbin "flat_file"
```
command: as tmp.S -o obj_file
3. Relink. Linker script like this(tmp.ld):
```
ENTRY(_start)
SECTIONS {
. = target_address;
.text : { *(.text) }
}
```
command: ld -T tmp.ld obj_file
在2018年09月25 20时51分, "Philipp Hug"写道:
Am Di., 25. Sep. 2018 um 13:50 Uhr schrieb Jonathan Neuschäfer
:
Would FIT support require discussion/cooperation with other projects
like Linux or u-boot?
What seems to be missing is the kernel image format to be used within the FIT.
e.g. look at arm64:
https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/head.S#L73
https://github.com/coreboot/coreboot/blob/master/src/arch/arm64/fit_payload.c#L29
Philipp
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Doubts about link scripts
I try to read link scripts of coreboot. In addition to the x86 platform, code segments and data segments are contiguous during the bootblock/romstage phase. However, only CAR/SRAM can be used as memory in the bootblock/romstage stage, this should be separate from the flash where the program is located. Why this is not reflected in the link script？ Does the machine have a special mechanism ? Looking forward to your reply !!! WangXiang-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Whether coreboot has restrictions on the bootblock program, cannot use static variables with initial values.
I am try to read the code that cache-as-ram of bootblock stage. And found that just cleared the memory and did not initialize the data segment code. So, I want to ask : "Whether coreboot has restrictions on the bootblock program, cannot use static variables with initial values." Looking forward to your reply！Thank you! XiangWang-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Fw:Re: I want to submit some code, but there aresomeproblems.
>```
>if (running_on_hart(active)) { ... }
>```
>Yes, these codes are clearer.
>
>/*
> * If your code needs to temporarily block multiple-threads, do this:
> * SMP_PAUSE(active)// `active` is hartid of working thread
> * ... single-threaded work ...
> * SMP_RESUME()
> * ... multi-threaded work ...
> */
>But sometimes multi-threaded work has to wait for the single-threaded work to
>complete.
>
>etc:
>single-threaded work : init ddr controller
>multi-threaded work : some operations related to memory
>
>It is necessary to wait for the completion of single-threaded work.
>
>Xiang Wang
There is other solution here.
```
#define HART_NUM 5
void smp_sync(unsigned long *cnt)
{
atomic_add(cnt,1);
do {
barrier();
}while(*cnt < HART_MAX);
}
static unsigned long cnt;
if (running_on_hart(active)) { ... }
smp_sync(&cnt);
```
This solution must define HART_NUM.
I think this solution is not as flexible as SMP_PAUSE/SMP_RESUME.
Which solution do you want to use?
Xiang Wang--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Fw:Re: I want to submit some code, but there aresomeproblems.
> Oh! SMP_PAUSE actually jumps here! I would *not* expect that, when I
> read code like this:
>
> SMP_PAUSE(active);
> foo();
> bar(42);
> SMP_RESUME();
>
> Something like the following would be a lot clearer for me:
>
> if (mhartid() == active) {
> foo();
> bar(42);
> }
>
> Or maybe:
>
> if (running_on_hart(active)) { ... }
>
> But note that this lacks the barriers/locking that your code has.
>
> Jonathan Neuschäfer
```
if (running_on_hart(active)) { ... }
```
Yes, these codes are clearer.
/*
* If your code needs to temporarily block multiple-threads, do this:
* SMP_PAUSE(active)// `active` is hartid of working thread
* ... single-threaded work ...
* SMP_RESUME()
* ... multi-threaded work ...
*/
But sometimes multi-threaded work has to wait for the single-threaded work to
complete.
etc:
single-threaded work : init ddr controller
multi-threaded work : some operations related to memory
It is necessary to wait for the completion of single-threaded work.
Xiang Wang--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Fw:Re: I want to submit some code, but there are someproblems.
>On Tue, Jul 03, 2018 at 04:23:07PM +0800, 王翔 wrote:
>> I want submit some code to support temporarily block multiple-threads.
> >But this code can't pass check by `checkpatch`.
>What is the error that checkpatch prints out?
>If you can't see it, try running
> util/lint/checkpatch.pl -f src/path/to/your/file.h
>directly.
>Hope that helps,
>Jonathan Neuschäfer
Error print like this:
```
WARNING: Macros with flow control statements should be avoided
#43: FILE: src/arch/riscv/include/smp.h:43:
+#define SMP_PAUSE(active) do \
+{ \
+__label__ l_entry, l_exit; \
+static int _flag_; \
+if (active == read_csr(mhartid)) \
+goto l_entry; \
+do {barrier(); } while (!_flag_); \
+goto l_exit; \
+l_entry:
WARNING: please, no spaces at the start of a line
#45: FILE: src/arch/riscv/include/smp.h:45:
+__label__ l_entry, l_exit; \$
WARNING: please, no spaces at the start of a line
#46: FILE: src/arch/riscv/include/smp.h:46:
+static int _flag_; \$
WARNING: please, no spaces at the start of a line
#47: FILE: src/arch/riscv/include/smp.h:47:
+if (active == read_csr(mhartid)) \$
ERROR: code indent should use tabs where possible
#48: FILE: src/arch/riscv/include/smp.h:48:
+goto l_entry; \$
WARNING: please, no spaces at the start of a line
#48: FILE: src/arch/riscv/include/smp.h:48:
+goto l_entry; \$
WARNING: please, no spaces at the start of a line
#49: FILE: src/arch/riscv/include/smp.h:49:
+do {barrier(); } while (!_flag_); \$
WARNING: please, no spaces at the start of a line
#50: FILE: src/arch/riscv/include/smp.h:50:
+goto l_exit; \$
ERROR: Macros with multiple statements should be enclosed in a do - while loop
#54: FILE: src/arch/riscv/include/smp.h:54:
+#define SMP_RESUME() \
+_flag_ = 1; \
+l_exit: \
+barrier(); \
+} while (0)
WARNING: please, no spaces at the start of a line
#55: FILE: src/arch/riscv/include/smp.h:55:
+_flag_ = 1; \$
WARNING: please, no spaces at the start of a line
#57: FILE: src/arch/riscv/include/smp.h:57:
+barrier(); \$
total: 2 errors, 9 warnings, 65 lines checked
```--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] I want submit some code, but there are some problem
I want submit some code to support temporarily block multiple-threads.
But this code can't pass check by `checkpatch`.
This code look like this:
```
#define barrier() {asm volatile ("fence" ::: "memory"); }
/*
* If your code needs to temporarily block multiple-threads, do this:
* SMP_PAUSE(active)// `active` is hartid of working thread
* ... single-threaded work ...
* SMP_RESUME()
* ... multi-threaded work ...
*/
#define SMP_PAUSE(active) do \
{ \
__label__ l_entry, l_exit; \
static int _flag_; \
if (active == read_csr(mhartid)) \
goto l_entry; \
do {barrier(); } while (!_flag_); \
goto l_exit; \
l_entry:
#define SMP_RESUME() \
_flag_ = 1; \
l_exit: \
barrier(); \
} while (0)
```
Xiang Wang--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] I want to submit some code, but there are some problems.
I want submit some code to support temporarily block multiple-threads.
But this code can't pass check by `checkpatch`.
This code look like this:
```
#define barrier() {asm volatile ("fence" ::: "memory"); }
/*
* If your code needs to temporarily block multiple-threads, do this:
* SMP_PAUSE(active)// `active` is hartid of working thread
* ... single-threaded work ...
* SMP_RESUME()
* ... multi-threaded work ...
*/
#define SMP_PAUSE(active) do \
{ \
__label__ l_entry, l_exit; \
static int _flag_; \
if (active == read_csr(mhartid)) \
goto l_entry; \
do {barrier(); } while (!_flag_); \
goto l_exit; \
l_entry:
#define SMP_RESUME() \
_flag_ = 1; \
l_exit: \
barrier(); \
} while (0)
```
Xiang Wang--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Why coreboot for riscv does not support multi-core?
> In short: Because it was easier to delay the problem until later. > >On Thu, May 17, 2018 at 03:55:37PM +0800, 王翔 wrote: >> The current code does not set the stack pointer for hart alone. >> The Linux kernel runs in s-mode and cannot set the stack pointer for m-mode. >> If m-mode does not have a separate stack for hart, then m-mode cannot save >> any state about the current hart. >> >> Is it necessary to initialize the stack pointer for each hart? > >Yes, I think this needs to be implemented. > >Note also, that the new SBI based on the ecall instruction is not >implemented in coreboot. > > >Jonathan Neuschäfer Is coreboot's payload a bootloader running in m-mode ? If not, how does the SBI interrupt service be implemented ? WangXiang-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Why coreboot for riscv does not support multi-core?
The current code does not set the stack pointer for hart alone. The Linux kernel runs in s-mode and cannot set the stack pointer for m-mode. If m-mode does not have a separate stack for hart, then m-mode cannot save any state about the current hart. Is it necessary to initialize the stack pointer for each hart? Looking forward to your reply. Thank you. WangXiang-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Problem about GPIO
I try to porting coreboot to msi's Motherboard(H110 chipset). I read GPIO config from PCR config space under linux. But the value I got was very strange. eg: //DW0 and DW1 cannot be 0x according to the data sheet PIN:GPP_C6 DW1,DW0:, FUNC:(null) PULL:NATIVE RESET:RSMRST TX_DISABLE:1 RX_DISABLE:1 RXINV:INVERT TRIG:EDGE_BOTH ROUTE:NMI SMI SCI IOACPI PIN:GPP_C7 DW1,DW0:, FUNC:(null) PULL:NATIVE RESET:RSMRST TX_DISABLE:1 RX_DISABLE:1 RXINV:INVERT TRIG:EDGE_BOTH ROUTE:NMI SMI SCI IOACPI //TX_DISABLE and RX_DISABLE should be 0 ,if a GPIO is configured as NFx. PIN:GPP_A0 DW1,DW0:0018,84000502 FUNC:NF1 PULL:NONE RESET:PLTRST TX_DISABLE:1 RX_DISABLE:0 RXINV:NONE TRIG:OFF ROUTE: PIN:GPP_A1 DW1,DW0:3019,84000402 FUNC:NF1 PULL:UP_20K RESET:PLTRST TX_DISABLE:0 RX_DISABLE:0 RXINV:NONE TRIG:OFF ROUTE: PIN:GPP_A2 DW1,DW0:301a,84000402 FUNC:NF1 PULL:UP_20K RESET:PLTRST TX_DISABLE:0 RX_DISABLE:0 RXINV:NONE TRIG:OFF ROUTE: PIN:GPP_A3 DW1,DW0:301b,84000402 FUNC:NF1 PULL:UP_20K RESET:PLTRST TX_DISABLE:0 RX_DISABLE:0 RXINV:NONE TRIG:OFF ROUTE: PIN:GPP_A4 DW1,DW0:301c,84000402 FUNC:NF1 PULL:UP_20K RESET:PLTRST TX_DISABLE:0 RX_DISABLE:0 RXINV:NONE TRIG:OFF ROUTE: PIN:GPP_A5 DW1,DW0:001d,84000600 FUNC:NF1 PULL:NONE RESET:PLTRST TX_DISABLE:0 RX_DISABLE:1 RXINV:NONE TRIG:OFF ROUTE: Thank you very much，if you can help me. Wang Xiang-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problem with super io NCT6793D
Thank you very much. 王翔 -- 王翔 安全研究员 广州市腾御安信息科技有限公司 广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024 -- Original -- From: "Nico Huber"; Date: 2018年4月9日(星期一) 晚上11:56 To: "王翔"; "coreboot"; Subject: Re: [coreboot] Problem with super io NCT6793D On 09.04.2018 11:37, 王翔 wrote: > I want to porting coreboot to MSI's motherboard. > However, the super io of this motherboard is the NCT6793D. > Which chip is like NCT6793D? Or give me datasheet of the NCT6793D. You can inquire about the datasheet at Nuvoton They are usually very responsive. Nico-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Problem with super io NCT6793D
I want to porting coreboot to MSI's motherboard. However, the super io of this motherboard is the NCT6793D. Which chip is like NCT6793D? Or give me datasheet of the NCT6793D. Thank you very much. -- 王翔 安全研究员 广州市腾御安信息科技有限公司 广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Doubt about SPD init in Skylake
The system must initialize some arrays before initializing the SPD in order to execute FspMemoryInit. I do not know what these arrays do, and how do I get these values when porting new motherboard. These codes exist on the SKYLAKE platform which using FSP2.0. Call path : fsp_memory_init->do_fsp_memory_init->platform_fsp_memory_init_params_cb->mainboard_memory_init_params array list : FSPM_UPD->FspmConfig->DqByteMapCh0 FSPM_UPD->FspmConfig->DqByteMapCh1 FSPM_UPD->FspmConfig->DqsMapCpu2DramCh0 FSPM_UPD->FspmConfig->DqsMapCpu2DramCh1 FSPM_UPD->FspmConfig->RcompResistor FSPM_UPD->FspmConfig->RcompTarget If you can help me extremely grateful ! ! ! -- 王翔 安全研究员 广州市腾御安信息科技有限公司 广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] doubts on FSP
I try to understand coreboot source for x86 (intel/kblrvp). But I have
encountered some difficulties.
In romstage fsp_memory_init, try to find fspm.bin.
```
if (cbfs_boot_locate(&file_desc, name, NULL)) {
printk(BIOS_CRIT, "Could not locate %s in CBFS\n", name);
die("FSPM not available!\n");
}
```
But my firmware not contain.
```
➜ coreboot git:(master) build/cbfstool build/coreboot.rom print
Name Offset Type Size
cbfs master header 0x0cbfs header 32
fallback/romstage 0x80 stage36876
cpu_microcode_blob.bin 0x9100 microcode0
fallback/ramstage 0x9180 stage75335
vgaroms/seavgabios.bin 0x1b800raw 27648
config 0x22480raw 107
revision 0x22540raw 570
spd.bin0x227c0spd 2048
cmos_layout.bin0x23000cmos_layout 1132
fallback/postcar 0x234c0stage24932
fallback/dsdt.aml 0x29680raw 16738
fallback/payload 0x2d840payload 63916
payload_config 0x3d240raw 1652
payload_revision 0x3d900raw 234
(empty)0x3da40null 1713240
mrc.cache 0x1dfec0 mrc_cache65536
(empty)0x1eff00 null 16280
bootblock 0x1f3ec0 bootblock49152
➜ coreboot git:(master) build/cbfstool build/coreboot.rom layout -w
This image contains the following sections that can be accessed with this tool:
'BIOS' (read-only, size 2097152)
'FMAP' (read-only, size 256)
'COREBOOT' (CBFS, size 2096896)
It is at least possible to perform the read action on every section listed
above.
```
--
王翔
安全研究员
广州市腾御安信息科技有限公司
广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] x86 : Puzzles about init IDT
The source code may have a problem when the IDT is initialized. This code is located in `src/cpu/x86/16bit/entry16.inc`. -- movw%cs, %ax shlw$4, %ax movw$nullidt_offset, %bx subw%ax, %bx lidt%cs:(%bx) —> this mybe lidtl movw$gdtptr16_offset, %bx subw%ax, %bx lgdtl %cs:(%bx) -- lidt only used for base 0-16M. But nullidt located in (4G-64k) - 4G space. This instruct must be **lidtl** Description of LIDT IF Instruction is LIDT THEN IF OperandSize = 16 THEN IDTR(Limit) ← SRC[0:15]; IDTR(Base) ← SRC[16:47] AND 00FFH; ELSE IF 32-bit Operand Size THEN IDTR(Limit) ← SRC[0:15]; IDTR(Base) ← SRC[16:47]; FI; ELSE IF 64-bit Operand Size (* In 64-Bit Mode *) THEN IDTR(Limit) ← SRC[0:15]; IDTR(Base) ← SRC[16:79]; FI; FI; ELSE (* Instruction is LGDT *) IF OperandSize = 16 THEN GDTR(Limit) ← SRC[0:15]; GDTR(Base) ← SRC[16:47] AND 00FFH; ELSE IF 32-bit Operand Size THEN GDTR(Limit) ← SRC[0:15]; GDTR(Base) ← SRC[16:47]; FI; ELSE IF 64-bit Operand Size (* In 64-Bit Mode *) THEN GDTR(Limit) ← SRC[0:15]; GDTR(Base) ← SRC[16:79]; FI; FI; FI; -- 王翔 安全研究员 广州市腾御安信息科技有限公司 广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] x86 : Puzzles about reset code
source code like this: - .section ".reset", "ax", %progbits .code16 .globl _start _start: .byte 0xe9 .int _start16bit - ( . + 2 ) /* Note: The above jump is hand coded to work around bugs in binutils. * 5 byte are used for a 3 byte instruction. This works because x86 * is little endian and allows us to use supported 32bit relocations * instead of the weird 16 bit relocations that binutils does not * handle consistently between versions because they are used so rarely. */ .previous - I tried to modify the code and passed test (use qemu test). My code like this: - .section ".reset", "ax", %progbits .code16 .globl _start _start: jmp _start16bit .previous - What is the meaning of hand coding? In 16-bit mode, the last two bytes are ignored. -- 王翔 安全研究员 广州市腾御安信息科技有限公司 广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] riscv: How to implement configstring
I try to boot linux use coreboot. But I get some error.
Jumping to boot code at 9000()
CPU0: stack: 8080 - 80801000, lowest used address
8084, stack used: 4092 bytes
Config string: ''
We don't have virtual memory...
OK, let's go
Got timer interrupt but found no timer.
This is due to the inability to get configstring.
const char *configstring(void)
{
uint32_t addr = *(uint32_t *)CONFIG_RISCV_CONFIGSTRING;
return (const char *)(uintptr_t)addr;
}
The configstring implement by spike or other SOC?
If this is done through coreboot, maybe a global variable is more appropriate.
This avoids modifying the link script.
------
王翔
安全研究员
广州市腾御安信息科技有限公司
广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] riscv: How to debug (王翔)
On Friday,June 9, 2017 at 12:34 PM,王翔 wrote:
>On Friday,June 9, 2017 9:17 AM, Jonathan Neuschäfer wrote:
>>On Thu, Jun 08, 2017 at 05:32:31PM +0800, 王翔 wrote:
>>> I try to debug coreboot with **spike**.
>>> I has apply the **8250 usart patch** to **spike**.
>>I haven't updated the patches at [1] in a while. Please check if the two
>>patches in [2] work for you if you also apply the following patch to
>>coreboot:
>>
>>diff --git a/src/mainboard/emulation/spike-riscv/uart.c
>>b/src/mainboard/emulation/spike-riscv/uart.c
>>index 57647fee1d..26ab630091 100644
>>--- a/src/mainboard/emulation/spike-riscv/uart.c
>>+++ b/src/mainboard/emulation/spike-riscv/uart.c
>>@@ -20,5 +20,5 @@
> >uintptr_t uart_platform_base(int idx)
>>{
>>- return (uintptr_t) 0x40001000;
>>+ return (uintptr_t) 0x0210;
>>}
>>
>>[1]: https://github.com/riscv/riscv-isa-sim/pull/53
>>[2]: https://github.com/neuschaefer/riscv-isa-sim/commits/uart-update
>I get source frome https://github.com/riscv/riscv-tools.git.
>Compare the difference with https://github.com/riscv/riscv-isa-sim/pull/53 and
>fix the code.
>The difference of Our patch is **UART_BASE**. You use 0x0210, me use
>0x40001000.
>In my test 0x40001000 can be work with **coreboot**, but 0x0210 can not.
>My patch is in the attachment of the message.
I'm sorry. I not change **uintptr_t uart_platform_base(int idx)**
>>> But I get from the official website of the code can not pass the test.
>>> I found some BUG when I debug this.
>>What did you test? How did it fail?
>I test by **spike**. I have report the patch.
>https://review.coreboot.org/#/c/20043/
>https://review.coreboot.org/#/c/20105/
But these bugs still exist.
>>Regards,
>>Jonathan Neuschäfer
>Regards,
>王翔
Regards,
王翔
--
王翔
安全研究员
广州市腾御安信息科技有限公司
广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] riscv: How to debug (王翔)
On Friday,June 9, 2017 9:17 AM, Jonathan Neuschäfer wrote:
>On Thu, Jun 08, 2017 at 05:32:31PM +0800, 王翔 wrote:
>> I try to debug coreboot with **spike**.
>> I has apply the **8250 usart patch** to **spike**.
>I haven't updated the patches at [1] in a while. Please check if the two
>patches in [2] work for you if you also apply the following patch to
>coreboot:
>
>diff --git a/src/mainboard/emulation/spike-riscv/uart.c
>b/src/mainboard/emulation/spike-riscv/uart.c
>index 57647fee1d..26ab630091 100644
>--- a/src/mainboard/emulation/spike-riscv/uart.c
>+++ b/src/mainboard/emulation/spike-riscv/uart.c
>@@ -20,5 +20,5 @@
>uintptr_t uart_platform_base(int idx)
>{
>- return (uintptr_t) 0x40001000;
>+ return (uintptr_t) 0x0210;
>}
>
>[1]: https://github.com/riscv/riscv-isa-sim/pull/53
>[2]: https://github.com/neuschaefer/riscv-isa-sim/commits/uart-update
I get source frome https://github.com/riscv/riscv-tools.git.
Compare the difference with https://github.com/riscv/riscv-isa-sim/pull/53 and
fix the code.
The difference of Our patch is **UART_BASE**. You use 0x0210, me use
0x40001000.
In my test 0x40001000 can be work with **coreboot**, but 0x0210 can not.
My patch is in the attachment of the message.
>> But I get from the official website of the code can not pass the test.
>> I found some BUG when I debug this.
>What did you test? How did it fail?
I test by **spike**. I have report the patch.
https://review.coreboot.org/#/c/20043/
https://review.coreboot.org/#/c/20105/
>Regards,
>Jonathan Neuschäfer
Regards,
王翔
--
王翔
安全研究员
广州市腾御安信息科技有限公司
广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024
0001-uart-patch.patch
Description: Binary data
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] riscv: How to debug
I try to debug coreboot with **spike**. I has apply the **8250 usart patch** to **spike**. But I get from the official website of the code can not pass the test. I found some BUG when I debug this. I want to submit the code but I can't test it. What can i do, who can help me. I get code from `https://review.coreboot.org/coreboot.git` -- 王翔 安全研究员 广州市腾御安信息科技有限公司 广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] BUG : riscv register address is incorrect
I tried using spike to debug the coreboot code. But encountered a problem: **mcounteren/smcounteren** address is not correct. The bug code is in `src/arch/riscv/virtual_memory.c` ``` 313 // Enable all user/supervisor-mode counters using 314 // v1.9.1 register addresses. 315 // They moved from the earlier spec. 316 // Until we trust our toolchain use the hardcoded constants. 317 // These were in flux and people who get the older toolchain 318 // will have difficult-to-debug failures. 319 write_csr(/*mcounteren*/0x320, 7); //this address shoud fix to 0x306 320 write_csr(/*scounteren*/0x321, 7);//this address shoud fix to 0x106 ``` I have already submitted a patch. https://review.coreboot.org/#/c/20043/ -- 王翔 安全研究员 广州市腾御安信息科技有限公司 广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Some qustion about riscv implement
# Some qustion about riscv implement ## 1. SMP Coreboot for riscv does not support SMP, now. why does the secondary hart not halt in **src/arch/riscv/bootblock.S**? Now, secondary hart halts in **src/arch/riscv/trap_util.S**. This may affect playload implementation. ## 2. Privilege level for hypervisor Privilege level2 is Reserved In newest **rescv-privileged-v1.10.pdf**. According to the latest **rescv-privileged-v1.10.pdf**, the privilege level 2 is reserved. However, it appears in the source code. ## 3. Exception Both **supervisor_trap_entry** and **trap_entry** in **src/arch/riscv/trap_util.S** have similar functionality. The only difference is the latter halts the secondary hart. **supervisor_trap_entry** is unused currently, what's the purpose of that? The two restore context handlers **supervisor_call_return** **machine_call_return** in **src/arch/riscv/trap_util.S** are the same and they're in another section. Why not put these codes right after **supervisor_trap_entry**/**trap_entry** so there's no need to insert assembly codes in **src/arch/riscv/trap_handler.c**. ## 4. CSR(mtime mtimecmp) Hart-local storage records the address of mtime/mtimecmp. However, I could not find information regarding CSR mapped to memory space in the latest document **rescv-privileged-v1.10.pdf**. ## 5. S/M Privilege level use same stack Function **riscvpayload** in **src/arch/riscv/payload.S** does not create a new stack for S privilege level. This may destroy the stack of M privilege level. ------ 王翔 安全研究员 广州市腾御安信息科技有限公司 广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
