<Sofia>
jrtc27: Do you mean the 64-bit ARM machines had the support to run 32-bit ARM programs; and _that_ included a bunch of complexity which was removed. Meanwhile the 64-bit machines still support operating over 32-bit integers a la RV64I's ADDW ?
<HdkR>
Yes. AArch64 still has the 32-bit sized operations
<Sofia>
Then that article _really_ did indeed mess up with the communication on this. :)
aburgess has quit [Remote host closed the connection]
aburgess has joined #riscv
jmdaemon has quit [Ping timeout: 240 seconds]
GenTooMan has quit [Ping timeout: 255 seconds]
GenTooMan has joined #riscv
BootLayer has joined #riscv
theruran has quit [Quit: Connection closed for inactivity]
BootLayer has quit [Client Quit]
<dh`>
afaicr, there have been 64-bit arm machines that can boot 32-bit kernels, and 64-bit arm machines that cannot but can run 32-bit user code under a 64-bit kernel, and if there are now some that can't do that either I wouldn't be terribly surprised
<dh`>
compatibility hasn't ever been the arm ecosystem's strong suit
BootLayer has joined #riscv
mahk has quit [Quit: WeeChat 3.0]
uzix has joined #riscv
uzix has quit [Changing host]
uzix has joined #riscv
uzix is now known as mahk
rvalles has quit [Ping timeout: 240 seconds]
rvalles has joined #riscv
rvalles has quit [Read error: Connection reset by peer]
jacklsw has quit [Read error: Connection reset by peer]
jacklsw has joined #riscv
rvalles has joined #riscv
pecastro has joined #riscv
bauruine has joined #riscv
sympt6 has joined #riscv
sympt has quit [Ping timeout: 260 seconds]
sympt6 is now known as sympt
<nelnire>
/18
zjason` is now known as zjason
jack_lsw has joined #riscv
aerkiaga has joined #riscv
jacklsw has quit [Ping timeout: 246 seconds]
compscipunk has quit [Ping timeout: 256 seconds]
compscipunk has joined #riscv
jack_lsw has quit [Ping timeout: 246 seconds]
<courmisch>
Esmil: will try
<courmisch>
Esmil: any chance to lift the staging wave driver from linux-media list?
<Esmil>
courmisch: I haven't seen that can you send me a link?
<mps>
Esmil: does poweroff works in your branch for visionfive kernel
<Esmil>
mps: linux stops if that's what you mean, but i'm not sure the hardware can do anything sensible on poweroff other than spinning
<Esmil>
you'll need to add or extend a driver to tell the pmic to power down on powerdown
<Esmil>
..but these days I think reset and poweroff is supposed to go into OpenSBI
<Esmil>
..so that's ideally where you need to add the driver
<mps>
Esmil: ah, ok. didn't thought about opensbi
GenTooMan has joined #riscv
<Esmil>
mps: the pmic has a FORCESHUTDN register, but that just resets the pmic (that's how the BeagleV resets itself)
<Esmil>
mps: maybe you can play with turning off individual power rails until you hit the one that powers the SoC
<mps>
Esmil: reset (by reboot) works
<Esmil>
yes
<mps>
and reset deactivates GPIO
<Esmil>
on the visionfive they also wired a gpio to the pmic to do the same, so there you have multiple options to reset the board ;)
<Esmil>
mps: resetting the pmic will trigger the SoC reset pin, and then all register will be reset to their default state
<mps>
I didn't had time to look deeply in schematic so I'm just guessing about some things
<Esmil>
you could definitely do the same on powerdown, but then the SoC would just boot up again which is not what you want
<mps>
right
pecastro has quit [Quit: Lost terminal]
pecastro has joined #riscv
<xypron>
Did anybody have success with running U-Boot on QEMU with KVM? I could not get qemu-riscv64_smode_defconfig running with it. Without -kvm and using OpenSBI as bios it is not a problem.
<Esmil>
smaeul: is your d1-wip branch the tree I shoud be running on my nezha?
<Esmil>
it keeps getting read errors from the sdcard at boot. I've tried different cards, but they all seem to fail at boot. afterwards fsck says everything is fine, and so does fsck run from another machine
tsraoien has joined #riscv
<Esmil>
ah, maybe I just didn't read the instructions on https://linux-sunxi.org/Allwinner_Nezha closely enough. not loading the allwinner/sun20i-d1-nezha.dtb seems to work better.
<Esmil>
smaeul: do you know why that might be?
mahk has quit [Quit: WeeChat 3.0]
uzix has joined #riscv
uzix has joined #riscv
uzix is now known as mahk
GenTooMan has quit [Ping timeout: 240 seconds]
<mmind00>
Esmil: the wiki page doesn't seem to explain the why (for the don't load a dtb) it seems ... on my nezha I do tftp-load a FIT image for u-boot to use ... including a dtb ... and at least the network works nicely for nfsroot ... now that I think about it, I never checked weather the sd-card worked, I guess I should remedy that ;-)
<Esmil>
mmind00: yeah, everything else seemed to work fine with the dt from the d1-wip branch
GenTooMan has joined #riscv
gdd1 has quit [Ping timeout: 255 seconds]
gdd1 has joined #riscv
jack_lsw has joined #riscv
gdd1 has quit [Excess Flood]
gdd1 has joined #riscv
gdd1 has quit [Excess Flood]
gdd1 has joined #riscv
<smaeul>
Esmil: yes, that is the right branch to run
<smaeul>
Esmil: mmind00: the reason not to load a DTB is that only the DTB in RAM has been patched by platform firmware to 1) supply the /memory node 2) reserve memory for the SBI implementation and 3) reserve devices for the SBI implementation
<smaeul>
the other reason is that delegating DTB loading to the firmware makes your filesystem device-independent
<mmind00>
smaeul: that's the reason why I carry this memory node in the kernel-dts :-) ... though I guess u-boot should be made to patch loaded dtb's as well ... arm stuff does this a lot already
<mmind00>
I guess I never learned to trust u-boot-provided devicetrees :-D
<smaeul>
please please please don't do that
<smaeul>
the end goal here is to put the firmware on SPI NAND/NOR, and EFI boot a generic RISC-V distro kernel
<Esmil>
smaeul: hmm.. but why is this needed on the D1? on other platforms the EfiDtFixupProtocol is able to take care of that, so you can test new devicetrees without involving u-boot
<mmind00>
still I would expect to be able to also supply a dtb with said distro-kernel ... and be it only for debugging purposes
<la_mettrie>
by the way, do you know if DTB files are the same in every operating system?
<smaeul>
we have the opportunity to do things _better_ than "arm stuff" where you have to ship a bunch of DTBs with the kernel
<smaeul>
la_mettrie: ideally, they are the same. in practice, not so much
<la_mettrie>
smaeul: but the format is the same?
<smaeul>
yes
unlord has quit [Changing host]
unlord has joined #riscv
<Esmil>
smaeul: sure ideally the dt would describe everything from the board is born, but until that happens it's quite a nice feature to be able to update the dt without updating u-boot
<smaeul>
you can still load a separate DTB, by any of 1) rebuilding the firmware 2) decompiling/patching the DTB provided by firmware 3) loading an overlay
<Esmil>
i mean that's why the efi dt fixup protocol exists
<mmind00>
smaeul: though flashing firmware on every development step does not bode well for any sort of work rhythm
<smaeul>
you shouldn't need to change the devicetree to do development. the hardware didn't change, after all :)
<mmind00>
smaeul: idealist :-D ... that would require that all bindings are reviewed in advance
<smaeul>
and that's exactly what I've been trying to do
EchelonX has joined #riscv
bauruine has quit [Remote host closed the connection]
<conchuod>
palmer: btw what's the craic with Atul? You know if he's gonna resend his dts cleanup? I asked him a couple weeks ago but heard nothing.
<conchuod>
His mail client is also doing some line wrapping of patches too :/
<palmer>
ya, looks like he just did git-format-patch and then gmail
<palmer>
I'll try and get something saner set up
<palmer>
looks like he's the victim of another laptop failure, we seem to have bad luck around here ;)
vagrantc has quit [Quit: leaving]
<conchuod>
I can resend them I guess on his behalf?
<conchuod>
palmer: multiple laptops dying is rather bad luck!
<palmer>
he's got a spare, so let's see if he can get them out
<palmer>
best to get that going right, so he can teach other folks here how to get mail through
<conchuod>
Yeah, I'd rather he sent them than I resent
cwebber has quit [Remote host closed the connection]
<conchuod>
I hate to point out stuff like top posting b/c you always sound like an ass
<conchuod>
I assume commerical gmail is easy to use with send-email palmer? App password etc (or does that change with 2fa?)
<palmer>
it's actually kind of a headache
<palmer>
I'm using an OAUTH2 mechanism that's been deprecated, for example
<palmer>
but I think that's a holdover from Google, we should be able to get something saner here
LordDoskias has quit [Quit: Leaving]
<conchuod>
I wonder if send-email with exchange is even possible
<conchuod>
^ with 2FA
<palmer>
everyone I know who works at a company with exchange ends up sending broken email
<palmer>
IIRC at Tilera we just set up a second mail server for that
<conchuod>
Yeah, we have exchange & we have a special mail server just for send-email etc
<conchuod>
Although, thunderbird has a plugin that at allows us to send plaintext formatted replies.
BootLayer has quit [Quit: Leaving]
Andre_H has joined #riscv
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #riscv
* mmind00
hugs his exim running on a kvm slice :-)
<mmind00>
(exim mailer daemon)
<conchuod>
You have the freedom to do what you like I'd assume
<mmind00>
that whole gmail thing is totally cumbersome ... and git-send-email can handle things nicely even when the commit author is different from the sender, so I try not to invest time into gmail madness :-)
<conchuod>
gmail works just fine with send-email w/ app passwords
radu2423598 has joined #riscv
<la_mettrie>
jlink's debugger gives me a mystical "emulator is out of memory" error when trying to start with Logan Nano. maybe i should try to find different version of that software from somewhere
motherfsck has joined #riscv
theruran has joined #riscv
<Esmil>
courmisch: the series you linked + this gets as far as asking for firmware http://sprunge.us/7EREpa
<Esmil>
courmisch: do you know where that can be found?
radu2423598 has quit [Read error: Connection reset by peer]
radu2423598 has joined #riscv
Andre_H has quit [Quit: Leaving.]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #riscv
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #riscv
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #riscv
eroux has quit [Ping timeout: 276 seconds]
pecastro has quit [Ping timeout: 246 seconds]
RAMIII has quit [Remote host closed the connection]