Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2021.04, v2021.07-rc4 are OUT / Merge Window is CLOSED and next is OPEN / Release v2021.07 is scheduled for 05 July 2021 / http://www.denx.de/wiki/U-Boot / Channel archives at https://libera.irclog.whitequark.org/u-boot
hanetzer1 is now known as hanetzer
hanetzer has joined #u-boot
hanetzer has quit [Changing host]
mranostaj has quit [Ping timeout: 265 seconds]
mranostaj has joined #u-boot
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #u-boot
samueldr has quit [Read error: Connection reset by peer]
cpackham[m] has quit [Read error: Connection reset by peer]
mvaittin has quit [Remote host closed the connection]
cpackham[m] has joined #u-boot
mvaittin has joined #u-boot
samueldr has joined #u-boot
FO2 has joined #u-boot
tlwoerner_ has joined #u-boot
tlwoerner has quit [Ping timeout: 272 seconds]
FO3 has quit [Ping timeout: 272 seconds]
Guest38 has joined #u-boot
Guest38 has quit [Quit: Client closed]
agust has joined #u-boot
mckoan|away is now known as mckoan
guillaume_g has joined #u-boot
sszy has joined #u-boot
Ultrasauce has quit [Ping timeout: 252 seconds]
Ultrasauce has joined #u-boot
ggardet has joined #u-boot
guillaume_g has quit [Ping timeout: 244 seconds]
ggardet is now known as guillaume_g
ilunev has joined #u-boot
matthias_bgg has joined #u-boot
ggardet has joined #u-boot
guillaume_g2 has joined #u-boot
tnovotny has joined #u-boot
guillaume_g has quit [Ping timeout: 272 seconds]
monstr has joined #u-boot
ilunev has quit [Ping timeout: 272 seconds]
guillaume_g2 is now known as guillaume_g
<apalos> monstr: do all boards automatically init the hardware?
<apalos> keep in mind the EFI subsystem uses what's already 'scanned'
<apalos> So let's assumne your nvme is not working. If you load the efi subsystem prior to scanning the nvme, you wont be able to load anythying from there
alpernebbi has joined #u-boot
<monstr> apalos: there is low level initialization code in SPL
<monstr> but I would expect that if this is not done properly you won't be able to detect usb flash disk
<monstr> but grub is running out of USB already
<monstr> it means u-boot is loading it properly from USB but grub has any issue to recognize it
<monstr> and usb flash disk is the same - just plug it to 3 different boards
<monstr> that's why it is quite weird.
<monstr> do you know how grub communicates with u-boot to find out which devices are available?
<monstr> ... is now current device
<monstr> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
<monstr> Scanning usb 0:1...
<monstr> Scanning disk mmc@ff170000.blk...
<monstr> Scanning disk usb_mass_storage.lun0...
<monstr> Found 5 disks
<monstr> I can't see these scanning usb_mass_storage on others
<monstr> it means likely scanning fails that's why it is not visible
<apalos> :)
<monstr> but dm uclass is showing them fine
<apalos> that's weird,
<monstr> I found one thing - 102 didn't run on the same image
<monstr> but older one
<monstr> ok - time to bisect - have working mainline commit and not working one
<monstr> EFI_CAPSULE_ON_DISK_EARLY=y
<monstr> likely there is no EFI rescan for new block devices
<monstr> because usb starts later
<apalos> aah yes, sounds good
<monstr> should we call usb_init before calling efi_disk_register()?
<monstr> the same is there with scsi/sata
<apalos> monstr: yea
<apalos> or fix efi_disk_register() to rescan, everytime a new device is attached
ilunev has joined #u-boot
smartin has joined #u-boot
<monstr> apalos: efi_status_t efi_init_obj_list(void)
<monstr> efi_status_t ret = EFI_SUCCESS;
<monstr> /* Initialize once only */
<monstr> if (efi_obj_list_initialized != OBJ_LIST_NOT_INITIALIZED)
<monstr> {
<monstr> return efi_obj_list_initialized;
<monstr> this condition is the problematic
<apalos> yea i know :>
<apalos> I just never had the time to fix it properly
<monstr> I will just remove this feature for now till there is any resolution
tlwoerner_ has quit [Quit: Leaving]
<monstr> hacky version just like this
<monstr> diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
<monstr> index 3c5cf9a4357e..1c0472ea7d6e 100644
<monstr> +++ b/lib/efi_loader/efi_setup.c
<monstr> --- a/lib/efi_loader/efi_setup.c
<monstr> @@ -197,6 +197,8 @@ efi_status_t efi_init_obj_list(void)
<monstr> goto out;
<monstr>
<monstr> #ifdef CONFIG_PARTITIONS
<monstr> + usb_init();
<monstr> + scsi_scan(true);
<monstr> ret = efi_disk_register();
<monstr> if (ret != EFI_SUCCESS)
tlwoerner has joined #u-boot
<monstr> goto out;
<monstr> :-)
<monstr> Scanning disk mmc@ff170000.blk...
<monstr> Scanning disk usb_mass_storage.lun0...
<monstr> Found 10 disks
<monstr> ** Unrecognized filesystem type **
<monstr> Scanning disk ahci_scsi.id1lun0...
<monstr> with it wonderfully 10 disks are found
<apalos> the proper way to do it is rescan the EFI thingy, once a new media gets pluagged/scanned
<apalos> I am looking into fwupd atm, so i might have time to check that afterwards
<monstr> did you get it work with standaloneMM?
<monstr> and emmc
<apalos> fwupd?
<monstr> yep
<apalos> the ESRT table doesnt get properly populated,
<apalos> but I got setvariable working with stmm + RPMB
<apalos> So once I sort this out, it should work
MattWeb has joined #u-boot
<apalos> I;ve sent 2 fixes needed on the SMBIOS for now
<MattWeb> Within the latest u-boot has there been merged/proposed patchwork that adds fault logging with various storage backends? Cases for this would be for storing power on self test results, image integrity failures, bus faults, etc
<monstr> good - I finish reading of your blob some days ago
<apalos> MattWeb: no idea
<monstr> and that RPMB keys - is there a way back when I forget the key?
<apalos> monstr: no :)
<apalos> the rpmb is on a symetric encryption
<monstr> is there a way to remore a key when I know it
<apalos> So it mostly depends on the platform
<apalos> So on NXP hardware, it's stored in fuses which you can only read from the secure world.
<monstr> because there is any default key in optee if you don't use your own
<MattWeb> apalos thx. trying to figure out if it would be worth us starting a upstream of some work we've been carrying on a series of products
<apalos> Which means you can dump it eventually via optee
<apalos> monstr: if you programmed the op-tee key, then that's it :)
<apalos> there's a huge warning on the howto!
<monstr> and have you ever tried to have saving efi variables on SD and don't let Linux to access it?
<monstr> IIRC you said that edk2 it using any memory for saving these variables which is hidden to OS
<apalos> you can store variables in an mmc with u-boot
<apalos> and linux can read them, it just can't write them
MattWeb has quit [Quit: MattWeb]
MattWeb has joined #u-boot
MattWeb has quit [Client Quit]
monstr has quit [Ping timeout: 245 seconds]
guillaume_g2 has joined #u-boot
MattWeb has joined #u-boot
MattWeb has quit [Client Quit]
ggardet has quit [Ping timeout: 244 seconds]
guillaume_g has quit [Ping timeout: 272 seconds]
MattWeb has joined #u-boot
MattWeb has quit [Client Quit]
MattWeb has joined #u-boot
MattWeb has quit [Client Quit]
MattWeb has joined #u-boot
MattWeb has quit [Client Quit]
monstr has joined #u-boot
MattWeb has joined #u-boot
torez has joined #u-boot
guillaume_g2 has quit [Remote host closed the connection]
guillaume_g2 has joined #u-boot
<Duality> hey
<Duality> I have a question about the environmental variables
<Duality> specifically I have one that says this: arch=arm I am wondering where it is set.
<Duality> if it is set with env_set() or some other way
<Duality> just figuring out how it works and what parts are set by u-boot and which are supposed to be in env stored in emmc for example
<Sout> err is this the makefile i know have a make ARCH=arm (no idea if that is what your talking about)
<Duality> no about the environment u-boot uses to boot
gcl has joined #u-boot
gcl has quit [Client Quit]
gcl has joined #u-boot
mkstr has quit [Remote host closed the connection]
mkstr has joined #u-boot
ilunev has quit [Quit: Textual IRC Client: www.textualapp.com]
guillaume_g2 is now known as guillaume_g
<cambrian_invader> Duality: in CONFIG_EXTRA_ENV_SETTINGS?
mckoan is now known as mckoan|away
ggardet has joined #u-boot
guillaume_g has quit [Ping timeout: 272 seconds]
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
redbrain has joined #u-boot
monstr has quit [Remote host closed the connection]
tnovotny has quit [Quit: Leaving]
ggardet is now known as guillaume_g
guillaume_g has quit [Quit: Konversation terminated!]
smartin has quit [Quit: smartin]
vagrantc has joined #u-boot
Guest38 has joined #u-boot
jason1234 has joined #u-boot
<jason1234> hi
<jason1234> have you heard of the way to boot netbsd on the pandora 32bits machine?
* vagrantc misses the openpandora
<m4t> same cpu as original beagleboard (not beaglebone)
<jason1234> serious? so then, it is easy to make it run. the only problem the u-boot is on NAND, and the autoboot.txt will fatload from mmc. what would be the address to boot kernel7.img ?
redbrain has quit [Ping timeout: 268 seconds]
Guest38 has quit [Quit: Client closed]
macromorgan has quit [Quit: Leaving]
alpernebbi has quit [Quit: alpernebbi]
<m4t> not sure if there's even framebuffer support. i am not familiar with the cpu, hardware, or netbsd in general
<jason1234> well, it runs fine on pi
<jason1234> there is wsfb
<jason1234> the trick is only to stage 1/2 or uboot kernel7.img
mrnuke has joined #u-boot
<marex> jason1234: you would also need all the drivers for omap3
<marex> jason1234: the scanout engine IP in omap is not the same as scanout engine IP in broadcom SoC on RPi
<marex> same thing for all the other IPs
<marex> i.e. it is not like booting BSD on x86 box, the kernel port must support the hardware you plan to run it on
<jason1234> what a shame to run linux... it is very old linux on pandora. netbsd would be best os for this kind of machine. there is all tools., including pkgsrc
<jason1234> marex: no one has tried yet. maybe openbsd runs on openpandora, I guess. If yes, then, all might be possible. BSD is cool, more fun than just linux. Even in text / console. netbsd would maybe work, the desktop is very nice on netbsd. it use wsfb on PIs
<jason1234> omap... and lack of drivers. maybe. the ehci_hcd and wl1251 might be needed. anyhow... it is worth a try
mwalle has quit [Ping timeout: 252 seconds]
mwalle has joined #u-boot
agust has quit [Quit: Leaving.]
<vagrantc> well, that's a new one ... ERROR: arch-specific fdt fixup failed
<vagrantc> hifive-unmatched v2021.07-rc4
torez has quit [Quit: torez]