<njha>
is there a way to get a u-boot.bin that contains an EFI payload in it
<njha>
i don't have a disk attached to my chip, but there is 16GB RAM that I can write to over a debug interface
<njha>
so my boot process is opensbi payload -> u-boot -> linux, but im not sure where to put the linux image except also in memory
<marex>
njha: cant you concatenate the payload at the end of the blob ?
<njha>
marex: like literally "cat u-boot.bin Image > u-boot-concat.bin"? that seems simple enough
<marex>
njha: yeah, well if your loader can deal with that, might be the simplest
<marex>
(why not just load the payload in u-boot shell anyway?)
<njha>
marex: well i need to get the payload into memory somehow
<marex>
njha: => help load
<njha>
but there are no filesystems
<njha>
this chip/board combo only has memory :p
<njha>
well the chip has a spi interface but it's connected to an FPGA right now that emulates 30 MB of SPI flash in BRAM
<marex>
sf read
<marex>
or whatever technology you use
<marex>
if its BRAM, then why not just 'cp.b' or directly execute from that BRAM ?
<njha>
the chip doesn't directly have access to the BRAM
<njha>
like the chip is taped out on silicon and pretty much all of its pins are connected to an FPGA
<njha>
so I'm saying in theory I can do something over the FPGA but realistically I should just do everything from memory
<njha>
this is a custom chip we taped out in class and are trying to boot linux on :p
<njha>
anyway i have appended linux to u-boot and will try to copy it to memory and then boot from it... i think that should work
njha has quit [Quit: a funny/inspired quit message]
qqq has quit [Remote host closed the connection]
camus has joined #u-boot
njha has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
mmu_man has quit [Ping timeout: 252 seconds]
LeSpocky has quit [Ping timeout: 246 seconds]
LeSpocky has joined #u-boot
jclsn has quit [Ping timeout: 255 seconds]
jclsn has joined #u-boot
<njha>
so we were able to get linux up via jumping to it directly from opensbi
<njha>
the issue with u-boot is if we stick the kernel at the end and then try to bootefi, it copies things on top of itself and ends up corrupting linux
<njha>
is there a way i can *safely* embed a 20M binary into u-boot so that I can bootefi from it?
<njha>
u-boot also tries to copy itself around which is a little annoying... it starts out in ram so it doesn't need to do this
<Tartarus>
ok, i'll see about picking it up soon'ish
<Tartarus>
Was that some sort of regression or just seemingly always a problem?
<rfs613>
the latter... there are two code paths for environment, and the behaviour of the non-redundant differs slightly from the redudant, with regards to what happens if malloc() fails. THe patch makes them both the same.
frieder_ has quit [Ping timeout: 260 seconds]
devarsh has joined #u-boot
devarsh_ has joined #u-boot
mmu_man has quit [Quit: reboot]
<Tartarus>
OK
frieder_ has joined #u-boot
frieder_ has quit [Remote host closed the connection]