<marex>
shyeline: it probably won't help on its own, the bug is likely somewhere in mctl_auto_detect_dram_size() in arch/arm/mach-sunxi/dram_sun50i_h616.c
<marex>
so you'd have to sprinkle printf()s and try and find out why does it detect 2 GiB of DRAM on 1 GiB machine sometimes
<marex>
probably para->rows or para->cols matches wrongly
doppo has quit [Read error: Connection reset by peer]
doppo has joined #u-boot
frieder has joined #u-boot
ldevulder has quit [Read error: Connection reset by peer]
ldevulder has joined #u-boot
frieder has quit [Ping timeout: 264 seconds]
frieder has joined #u-boot
PhoenixMage has joined #u-boot
<PhoenixMage>
I have a fitImage I want to load, how do I know where in memory I should load it? I am sure its board specific but where should I be able to find the details?
monstr has joined #u-boot
mmu_man has quit [Ping timeout: 268 seconds]
teejay_ is now known as teejay
mmu_man has joined #u-boot
kwizart is now known as kwizart|fedora
kwizart|fedora is now known as nchauvet
nchauvet is now known as kwizart
frieder has quit [Ping timeout: 252 seconds]
frieder has joined #u-boot
frieder has quit [Ping timeout: 268 seconds]
frieder has joined #u-boot
haritz has quit [Ping timeout: 260 seconds]
<sjg1>
apalos: Yes that patch is OK, as I said. I suggest putting the sequence of commands you mention in the email into a single command, then calling that code from your event on restart
<sjg1>
apalos: Then split the sandbox test into two parts. One that checks that the event is run on start (trivial test) and 2) the update test which just runs the command instead of rebooting
<sjg1>
apalos: We need more 'design for test'. I already hit a problem where an EFI test failed and had no idea where to start looking. It is not a useful test for development.
<sjg1>
apalos: It is good to have 'happy path' large, functional tests, but we must have smaller tests that we actually rely on for development
<sjg1>
apalos: Anyway, this is sideways of your patch. I just wanted to mention it
<Tartarus>
lucenera: we pass args to the kernel, in the "bootargs" variable typically, yes
<apalos>
sjg1 ok
<apalos>
So here's what I am going to do,
<apalos>
Clean up some TPM crud, because we are kind of wrong in the way we treat a tpm
<apalos>
in order for it to be usable we must start it up from the command line
<apalos>
So I'll clean that up and on DM init the TPM will be fully usable
<apalos>
I'll adjust the TPM tests
<apalos>
and then I'll resend my series with an extra event which runs post preboot commands
<apalos>
So people can put whatever they want there
<apalos>
(e.g the tftp update as well)
<apalos>
but for the command I dont think I can do it like that
<apalos>
I'd like u-boot to adhere to the spec without a need for special preboot commands
<apalos>
So I'd still much prefer calling the efi_capsule_update function from C
mmu_man has quit [Ping timeout: 260 seconds]
<lucenera>
Tartarus The device is a router with modified OpenWrt. Where can I find an example of bootargs syntax?
frieder has quit [Remote host closed the connection]
<sjg1>
apalos: What is this 'adhere to the spec' stuff you and xypron are referring to?
<sjg1>
apalos: I am not suggesting a preboot command. You can still use an event. But the sandbox test needs to work without a reboot, that's all. Design for test
<kallisti5[m]>
oof. but is that from the qemu dtb that's passed to u-boot 🤔
<marex>
Tartarus: ns16550 red alert ^
<marex>
qschulz: ^
<kallisti5[m]>
lol. sorry for the spam. I'm rubber ducking to like 700 people
<marex>
kallisti5[m]: no worries, this reg shift mess is not new here
<kallisti5[m]>
as I understand it, most serial uart drivers can assume 2. The big exception is x86,x86_64 which assumes 0 for legacy reasons
<kallisti5[m]>
that line above in ns16550 says "if no reg-shift property", shift by 0
<kallisti5[m]>
which is what the generated u-boot dtb is based on?
<kallisti5[m]>
anyway.. i think 8250 (aka ns16550) on riscv64 likely needs to be changed to 2 in all cases. (unless an override is specified by the dtb as reg-shift)
<marex>
AFAICT, QEMU builds the DT up from scratch from its hardware model(s)
<kallisti5[m]>
ok. then the bug would be in qemu? qemu is setting up a ns16550 on riscv64 virt with an assumed reg-shift of 0... then u-boot is passing on that assumption
<kallisti5[m]>
I did a dumpdtb in qemu-system-riscv64, and confirmed the dtb it spits out is also missing the reg-shift property
<marex>
kallisti5[m]: isn't the reg-shift property deprecated ?
<kallisti5[m]>
if it is, then qemu is doubley wrong for having an assumed reg-shift of anything except 2 on non-x86
<marex>
but qemu has to pass it to be compatible with legacy software running on it
<kallisti5[m]>
except riscv64 has no legacy software?
<kallisti5[m]>
that only covers x86 afaik
<kallisti5[m]>
also, physical riscv64 devices like the sifive unmatched have an assumed reg-shift of 2
<kallisti5[m]>
We're mapping EFI Loader and Code... is that something we shouldn't be doing?
<kallisti5[m]>
actually.. I bet I need to add the other sections there (boot services code / data, conventional memory)
<xypron>
kallisti5[m]: If you want to know the location of the bootloader you should use fields from the loaded image protocol on the handle received at the main entry point.
goliath has quit [Quit: SIGSEGV]
<kallisti5[m]>
this is the mapping prior to handoff to the kernel
<xypron>
kallisti5[m]: look in the spec's ExitBootServices description to see which memory types are reserved after this call.
<kallisti5[m]>
I bet y'all were mapping everything which we leveraged somehow accidently
<kallisti5[m]>
cool. I'll check
lucenera2 has joined #u-boot
lucenera has quit [Ping timeout: 252 seconds]
lucenera2 is now known as lucenera
<xypron>
kallisti5[m]: The device-tree specification says EfiReservedMemoryType must not be mapped.
<kallisti5[m]>
Yeah, we only mapped EfiLoaderCode/Data before
<xypron>
kallisti5[m]: in the UEFI spec see Table 7.10: Memory Type Usage after ExitBootServices()
<kallisti5[m]>
looking at x86, we map BootServices Code/Data and EfiConvMemory before jumping
<kallisti5[m]>
I added these three to riscv64, and our memory access error seen with that commit above is solved
<xypron>
kallisti5[m]: How about ConventionalMemory which is everything that was never used?
<xypron>
kallisti5[m]: EfiACPIReclaimMemory may be used after you have consumed the ACPI tables.
<kallisti5[m]>
yeah, page 166 shows it's a seperate type
<xypron>
kallisti5[m]: All mappable reserved memory is EfiBootServicesData according to the device-treee specification.
<xypron>
kallisti5[m]: So you have to read the device-tree to know how you can use it in the kernel.
lucenera has quit [Ping timeout: 252 seconds]
lucenera7 is now known as lucenera
<kallisti5[m]>
yeah, we do fully support fdt and use it in our allocations
<xypron>
kallisti5[m]: QEMU uses compatible "ns16550a". Documentation/devicetree/bindings/serial/8250.yaml does not make any assumption about the value of reg-shift of ns16550a. Furthermore reg-shift is not marked as required. So if it is missing assume 0. The SiFive Unmatched has compatible "sifive,fu740-c000-uart","sifive,uart0" which is described in Documentation/devicetree/bindings/serial/sifive-serial.yaml. And that document does not
<xypron>
know any reg-shift. You have to evaluate the compatible string to determine which driver to use.