* Re: 9FRONT "EMAILSCHADEN" RELEASED [not found] <0230698894072CDFA179F53B8EE1DA03@ewsd.inri.net> @ 2020-10-19 22:38 ` Anthony Martin 2020-10-24 22:29 ` [9front] " cinap_lenrek 2020-10-24 23:28 ` cinap_lenrek 0 siblings, 2 replies; 10+ messages in thread From: Anthony Martin @ 2020-10-19 22:38 UTC (permalink / raw) To: 9front sl@stanleylieber.com once said: > pc, pc64: remove mystery "type" bits in pcicfgrw*raw() (fixes qemu, thanks mischief) In changeset 78891f472fbf, cinap wrote: the access functions for pci config space in config mode #1 used to set bit 0 in the register offset if the access was to a device on any bus different from 0. it is completely unclear why this was done and i can't find any documentation on this. but for sure, this breaks all pci config spacess access to pci devices behind a bridge on qemu. with -trace pci* it was discovered that all config space register offsets on devies behind pci brige where off by one. Our code looks like it was a slight misreading of the specification and the change looks good. However, the original behavior should have been innocuous for any conforming host bridge: For Type 1 translations, the host bridge directly copies the contents of the CONFIG_ADDRESS register (excluding bits 31 and 0) onto the PCI AD lines during the address phase of a configuration transaction making sure that AD[1::0] is "01". (from PCI Local Bus Specification, Revision 3.0, §3.2.2.3.2) Note the phrase "excluding bits 31 and 0". Also, the PCI-PCI bridge in QEMU should be doing a Type 1 to Type 0 translation before the device behind the bridge sees the address. Cheers, Anthony ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9front] Re: 9FRONT "EMAILSCHADEN" RELEASED 2020-10-19 22:38 ` 9FRONT "EMAILSCHADEN" RELEASED Anthony Martin @ 2020-10-24 22:29 ` cinap_lenrek 2020-10-24 23:28 ` cinap_lenrek 1 sibling, 0 replies; 10+ messages in thread From: cinap_lenrek @ 2020-10-24 22:29 UTC (permalink / raw) To: 9front excellent follow up. thank you! -- cinap ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9front] Re: 9FRONT "EMAILSCHADEN" RELEASED 2020-10-19 22:38 ` 9FRONT "EMAILSCHADEN" RELEASED Anthony Martin 2020-10-24 22:29 ` [9front] " cinap_lenrek @ 2020-10-24 23:28 ` cinap_lenrek 2020-10-24 23:57 ` Thaddeus Woskowiak 1 sibling, 1 reply; 10+ messages in thread From: cinap_lenrek @ 2020-10-24 23:28 UTC (permalink / raw) To: 9front filed a bug: https://bugs.lunchpad.net/qemu/+bug/1901359 -- cinap ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9front] Re: 9FRONT "EMAILSCHADEN" RELEASED 2020-10-24 23:28 ` cinap_lenrek @ 2020-10-24 23:57 ` Thaddeus Woskowiak 2020-10-25 0:49 ` Alex Musolino 0 siblings, 1 reply; 10+ messages in thread From: Thaddeus Woskowiak @ 2020-10-24 23:57 UTC (permalink / raw) To: 9front On Sat, Oct 24, 2020 at 7:29 PM <cinap_lenrek@felloff.net> wrote: > > filed a bug: > > https://bugs.lunchpad.net/qemu/+bug/1901359 > > -- > cinap Why is that link serving malware? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9front] Re: 9FRONT "EMAILSCHADEN" RELEASED 2020-10-24 23:57 ` Thaddeus Woskowiak @ 2020-10-25 0:49 ` Alex Musolino 2020-11-02 0:54 ` kokamoto 0 siblings, 1 reply; 10+ messages in thread From: Alex Musolino @ 2020-10-25 0:49 UTC (permalink / raw) To: 9front Should be launchpad not lunchpad. Try this: https://bugs.launchpad.net/qemu/+bug/1901359 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9front] Re: 9FRONT "EMAILSCHADEN" RELEASED 2020-10-25 0:49 ` Alex Musolino @ 2020-11-02 0:54 ` kokamoto 2020-11-02 5:22 ` Eli Cohen ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: kokamoto @ 2020-11-02 0:54 UTC (permalink / raw) To: 9front > https://bugs.launchpad.net/qemu/+bug/1901359 Please let me allow write here. 1) 4GB rpi4 does not boot only biginning color image appears /sys/src/boot/bcm --rw-rw-r-- M 231 sys sys 1594 Oct 31 09:17 LICENCE.broadcom --rw-rw-r-- M 231 sys sys 47516 Oct 31 09:17 bcm2711-rpi-4-b.dtb --rw-rw-r-- M 231 sys sys 52480 Oct 31 09:17 bootcode.bin --rw-rw-r-- M 231 sys sys 3166 Oct 31 09:17 fixup4cd.dat --rw-rw-r-- M 231 sys sys 3166 Oct 31 09:17 fixup_cd.dat --rw-rw-r-- M 231 sys sys 260 Oct 5 2019 mkfile --rw-rw-r-- M 231 sys sys 784796 Oct 31 09:17 start4cd.elf --rw-rw-r-- M 231 sys sys 784796 Oct 31 09:17 start_cd.elf 2) /shr does not show usb stick's dos /shr/usb/sdUxxxxx shows dos etc partions, and then dossrv and then mout it makes enable to show the contents. (3) Elli, your wifi version of rpi3 includes sdmmc.c which is conflict with port/sdmmc.c. I changed that name to sdmmcM.c Kenji ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9front] Re: 9FRONT "EMAILSCHADEN" RELEASED 2020-11-02 0:54 ` kokamoto @ 2020-11-02 5:22 ` Eli Cohen 2020-11-04 13:24 ` cinap_lenrek 2020-11-04 13:29 ` cinap_lenrek 2 siblings, 0 replies; 10+ messages in thread From: Eli Cohen @ 2020-11-02 5:22 UTC (permalink / raw) To: 9front Hey Kenji, I haven't had much time to look at it recently. If I recall correctly, I only made minor changes to sdmmc.c and realized I could have left it in the port directory. I was basically just copying files from Richard Miller's version and making very minor changes so they would work. Last time I was looking at it, I was trying to get it working on the bcm64 kernel, and encountered trouble with sdhost.c not writing to the SD card correctly under the 64-bit kernel. I haven't looked at it much since then. - Eli ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9front] Re: 9FRONT "EMAILSCHADEN" RELEASED 2020-11-02 0:54 ` kokamoto 2020-11-02 5:22 ` Eli Cohen @ 2020-11-04 13:24 ` cinap_lenrek 2020-11-04 13:29 ` cinap_lenrek 2 siblings, 0 replies; 10+ messages in thread From: cinap_lenrek @ 2020-11-04 13:24 UTC (permalink / raw) To: 9front >> https://bugs.launchpad.net/qemu/+bug/1901359 > > Please let me allow write here. > > 1) 4GB rpi4 does not boot > only biginning color image appears i do not see how the qemu link is related. the pci controller on the raspberry pi4 uses completely different code to access pci config space: /sys/src/9/bcm64/pcibcm.c it was not affected by this bug. second, i have tested the pi3 image before release on my raspi4 8gb model and it works just fine. -- cinap ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9front] Re: 9FRONT "EMAILSCHADEN" RELEASED 2020-11-02 0:54 ` kokamoto 2020-11-02 5:22 ` Eli Cohen 2020-11-04 13:24 ` cinap_lenrek @ 2020-11-04 13:29 ` cinap_lenrek 2020-11-05 3:27 ` kokamoto 2 siblings, 1 reply; 10+ messages in thread From: cinap_lenrek @ 2020-11-04 13:29 UTC (permalink / raw) To: 9front i'v now also tested on raspberry pi4 2gb model and it boots fine too. -- cinap ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9front] Re: 9FRONT "EMAILSCHADEN" RELEASED 2020-11-04 13:29 ` cinap_lenrek @ 2020-11-05 3:27 ` kokamoto 0 siblings, 0 replies; 10+ messages in thread From: kokamoto @ 2020-11-05 3:27 UTC (permalink / raw) To: 9front > i'v now also tested on raspberry pi4 2gb > model and it boots fine too. Sorry, sorry, very sorry my noise, cinap. I used your time... I mixed elli's /sys/src/9/bcm/emmc.c with original one. I replaced that emmc.c by original one, and recompiled 9pi4, which made the problem away! Now, I can boot rpi4 with new sources, and am writing this mail by it. Kenji ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-11-05 3:27 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <0230698894072CDFA179F53B8EE1DA03@ewsd.inri.net> 2020-10-19 22:38 ` 9FRONT "EMAILSCHADEN" RELEASED Anthony Martin 2020-10-24 22:29 ` [9front] " cinap_lenrek 2020-10-24 23:28 ` cinap_lenrek 2020-10-24 23:57 ` Thaddeus Woskowiak 2020-10-25 0:49 ` Alex Musolino 2020-11-02 0:54 ` kokamoto 2020-11-02 5:22 ` Eli Cohen 2020-11-04 13:24 ` cinap_lenrek 2020-11-04 13:29 ` cinap_lenrek 2020-11-05 3:27 ` kokamoto
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).