rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
goliath has joined #u-boot
Rahix has joined #u-boot
Poltawer has quit [Ping timeout: 276 seconds]
Poltawer has joined #u-boot
mmu_man has quit [Ping timeout: 276 seconds]
Jones42 has joined #u-boot
dhruvag2000 has quit [Quit: Connection closed for inactivity]
<Stalevar>
I have a question. if chips have BootROM anyway, why it cant just run Linux directly without any extra bootloader?
<Stalevar>
I mean of course chip manufacturers have to code it first, but why they do not do it and use the BootROM to load u-boot first and then linux?
apritzel_ has quit [Ping timeout: 244 seconds]
sszy has joined #u-boot
jistr has quit [Remote host closed the connection]
sally has joined #u-boot
jistr has joined #u-boot
apritzel has joined #u-boot
jfsimon1981 has joined #u-boot
alexxy has joined #u-boot
enok has quit [Quit: enok]
enok71 has joined #u-boot
enok71 has quit [Client Quit]
enok has joined #u-boot
enok has quit [Client Quit]
enok has joined #u-boot
enok has quit [Read error: Connection reset by peer]
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #u-boot
naoki has quit [Quit: naoki]
clamor has quit [Ping timeout: 268 seconds]
clamor has joined #u-boot
enok has joined #u-boot
Jones42 has quit [Ping timeout: 260 seconds]
sstiller has joined #u-boot
Poltawer has quit [Quit: WeeChat 4.6.0]
Jones42 has joined #u-boot
Jones42 has quit [Ping timeout: 276 seconds]
monstr has joined #u-boot
monstr has quit [Ping timeout: 252 seconds]
burlak_ is now known as burlak
<marex>
Stalevar: a lot of hardware needs extensive software configuration to bring it up (like dram, which is user-selectable and all the other peripherals on the board, like storage etc), and then there are software bugs, the bootrom cannot be upgraded
<marex>
so the bootrom has to be simple and easy to verify, because when the bugs show up, they cannot be (easily) fixed
<apalos>
marex: Jerome sent a new version of that initcall,
<apalos>
I'll be honest i didnt follow up the entire conversation, but if you have any concerns please find some time to peek into it
<Stalevar>
marex, but as far as I understand bootroms are very complex this time around, since they support various storage devices and even loading flash image via XMODEM by serial
goliath has quit [Quit: SIGSEGV]
<Stalevar>
And they have crypto verification sometimes which sucks
<marex>
apalos: I wont block it
<marex>
Stalevar: sure, that makes them harder to verify and more prone to bugs, that is not what you want baked right into your chip
<apalos>
marex: thanks, mind replying 'blah blah looks ok' so Tom is free to pick it up eventually?
<marex>
smaller bootrom with fewer features is better, statistically
<marex>
apalos: I dont think I was even CCed, was I ?
<apalos>
really?> Let me check
<Stalevar>
marex, then why chip manufacturers make bootrom complex anyway?
<Stalevar>
Though built-in debricking via serial is cool
<apalos>
you were topic is PATCH v6 1/3] arm: asm/system.h: mrc and mcr need .arm if __thumb2__ is not set
<apalos>
[PATCH v6 2/3] common: board: make initcalls static etc
<marex>
Stalevar: to boot from increasingly complex storage media
<Stalevar>
I have an idea. Why not to add simple SPI flash on board, which is easy to program and use? Or even make one built in SoC itself. Or even replace BootROM with flash which can be programmed from outside by connecting a simple programmer to chip legs?
<Stalevar>
Though it might make chip manufacturers test bootroms less thoroughly if they can be replaced
<marex>
because someone wants to boot frm eMMC because cheaper
<K900>
Some enthusiast class SBCs ship with SPI flash for second stage firmware
<K900>
Which is good
<marex>
production devices, BoM cost, and so on ... it adds up in mass production
<marex>
apalos: let me have a look at that once I finish my current topic
<apalos>
thanks
clamor has quit [Read error: Connection reset by peer]
<Stalevar>
I have a file in kwbimage format. file tool does not detect it, mkimage -l gives very little information. There is source/tools/kwbimage.h and I don't know what to make of this.
<Stalevar>
By experiment I figured it out that data takes 516 bytes less than file size, I guess 512 header and 4 byte crc32?
<cambrian_invader>
Stalevar: doc/README.kwbimage
<cambrian_invader>
and you should be able to use dumpimage to extract parts of it
<cambrian_invader>
e.g. dumpimage -T kwbimage -p 1 or whatever
<apalos>
vagrantc: I lost your last question, did you have anything else you wanted on EFI?
<vagrantc>
apalos: i think pretty well set. was looking into if debian was carrying the patches and the answer was not yet, but someone proposed to add them yesterday
<apalos>
yes a colleague of mine, I asked him to because he is involved
<vagrantc>
:)
<apalos>
xypron: Do you know if ubuntu is carrying iot
flyback has quit [Read error: Connection reset by peer]
flyback has joined #u-boot
<apalos>
vagrantc: also eficonfig does magic if you quicly want to boot something
<vagrantc>
i have played with it but still need the integration for it to be a smooth ride for distros