sng has quit [Read error: Connection reset by peer]
sng_ has quit [Remote host closed the connection]
apritzel has joined #u-boot
sng has joined #u-boot
apritzel has quit [Ping timeout: 245 seconds]
stefanro has joined #u-boot
sng has quit [Remote host closed the connection]
sszy has joined #u-boot
mckoan|away is now known as mckoan
sng has joined #u-boot
<milkylainen>
Does u-boot have alignment requirements of fit image constituents, beside the one generated by mkimage? 4-byte align?
<milkylainen>
I've stumbled upon a comment in a project that claims that u-boot leaves the images in situ, hence ignoring the alignment requirements of starting kernel / ramdisk etc? I find that hard to believe.
<marex>
was that about fdt_high=0xffffffff ? that uses fdt in place and causes weird failures on arm64 which has 8 byte alignment requirements, so do not use it
paulbarker has joined #u-boot
<marex>
the fitimage components are loaded to their respective load addresses, with the exception of fdt_high=-1 and initrd_high=-1 which inhibits it for fdt and initrd respectively (and you should not use that)
LetoThe2nd has joined #u-boot
<LetoThe2nd>
howdy! missing something obvious here I think - what are the conditions for u-boot.env being generated as part of the build process?
manchaw has quit [Quit: Connection closed for inactivity]
ikarso has joined #u-boot
apritzel has joined #u-boot
camus has quit [Ping timeout: 246 seconds]
sng has quit [Remote host closed the connection]
brujah has joined #u-boot
mmu_man has joined #u-boot
mmu_man has quit [Ping timeout: 245 seconds]
sng has joined #u-boot
jpanisbl has joined #u-boot
camus has joined #u-boot
apritzel has quit [Ping timeout: 245 seconds]
jpanisbl has quit [Ping timeout: 245 seconds]
jpanisbl has joined #u-boot
<jclsn>
sjg1: rfs613: Thanks for the explanation. I just had a look at the data sheet of our flash chip. Seems like it supports hardware and software write protection.
<jclsn>
sjg1: I have tried building the database and using the command you posted. When I run ./tools/moveconfig.py -f GPIO, I get 0 boards. What is the ~DM_GPIO in your case? Is that an environment variable you have?
stefanro has quit [Quit: Leaving.]
<jclsn>
I still don't get how U-Boot knows the BP[3:0] bits are located. Is this some kind of standardized memory location? I guess not, so it probably should be defined somewhere in the device tree, right?
<marex>
LetoThe2nd: you mean make u-boot-initial-env ?
<LetoThe2nd>
marex: not sure, was hunting down some pains in a Yocto release migration. but yeah, sounds accurate. has this been split out into a distinct make target at some point in the past?
<marex>
LetoThe2nd: you can emit board builtin environment into a file now
<marex>
thats what it is
<LetoThe2nd>
marex: yeah got that. but was that implicit in the default make target earlier? like, some years back?
<marex>
the uboot source tree has to be configured for a specific board obv, then you can use this target to exfil whatever is in include/configs/*h env settings
<marex>
LetoThe2nd: no, it wasnt
<marex>
LetoThe2nd: this was added fairly recently
<LetoThe2nd>
ok, thanks.
<marex>
LetoThe2nd: could it be you mean something else ?
<marex>
LetoThe2nd: OE could ship a custom env and package it as env for e.g. libubootenv or uboot env tools
<LetoThe2nd>
marex: probably. i think it meant an environment that would go into a boot partition.
<LetoThe2nd>
e.g. not the payload exfilled as human readable, but the one that is used during boot.
<LetoThe2nd>
will need to look into libubootenv ther.
<marex>
LetoThe2nd: ah, so you wouldnt have to run saveenv once or twice on first boot ?
<marex>
LetoThe2nd: so that tools can populate it with the right stuff when they cannot read out the content ?
<LetoThe2nd>
yeah as far as I can see thats the point.
<marex>
thats what the initial env is for, just install it into the rootfs and libubootenv tools would pick it up
mmu_man has joined #u-boot
jpanisbl has quit [Ping timeout: 245 seconds]
apritzel has joined #u-boot
jpanisbl has joined #u-boot
vigneshr has quit [Quit: Connection closed for inactivity]
<sjg1>
jclsn: I don't know how you can get zero boards with GPIO. Are you perhaps getting errors about missing toolchains? Do scan all boards you will need a toolchain for each arch (buildman --fetch-arch ...)
<sjg1>
perhaps moveconfig.failed is full and moveconfig.db is empty?
jpanisbl has quit [Ping timeout: 246 seconds]
hanetzer has quit [Ping timeout: 245 seconds]
hanetzer has joined #u-boot
<jclsn>
sjg1: Thank you. I will try that on Monday :)
<jclsn>
I guess it is because I did it in the Yocto workspace. I would probably have to use the toolchain generated by Yocto, but it is missing asteval
ikarso has quit [Quit: Connection closed for inactivity]
jpanisbl has quit [Quit: Konversation terminated!]
flyback has quit [Remote host closed the connection]
apritzel has joined #u-boot
<rfs613>
hmm, spi_nor_read_data() has a while (remaining) loop around the calls to do each read. So for example if spi_mem_adjust_op_size() reduced the transfer size, the loop will issue multiple reads, with the address/length adjusted, etc.
<rfs613>
but spi_nor_write_data() does not have this loop. So it can write less tha was requested.
<rfs613>
the actual lenght written is returned, so callers can of course handle this. Though the nomal call path (from spi_flash_write() downwards) does not seem to handle it.
<rfs613>
anyone know why spi_nor_read_data and spi_nor_write_data differ in having this while (remaining) loop?
monstr has quit [Remote host closed the connection]
flyback has joined #u-boot
vagrantc has joined #u-boot
Gravis has quit [Ping timeout: 250 seconds]
Gravis has joined #u-boot
mckoan is now known as mckoan|away
paulbarker has quit [Quit: Connection closed for inactivity]