<hurricos>
I just haven't gotten anywhere close to either SPL u-boot / RAMBOOT. I haven't even *compiled* u-boot; not sure where I'd get the toolchain (perhaps besides grabbing OpenWrt 18 and using CROSS_COMPILE=powerpc-.*musl-
<hurricos>
the most frustrating thing for me is not knowing how I'm supposed to manage u-boot build configurations
<hurricos>
There's the .config file, yes, but that is a black-box at this point. At least with OpenWrt one can generate a diffconfig and see the symbol implications
<hurricos>
but it twists me to no end that I can make menuconfig and still be asked questions on compilation
<hurricos>
or make menuconfig and compilation fails
<hurricos>
the build system is absolutely opaque to me
<hurricos>
I know in the end the process for OpenWrt will be something like:
<hurricos>
- dedicate a toolchain build to u-boot (as we do with Marvell mvebu / kirkwood)
<hurricos>
- add u-boot build configuration to the build system
<hurricos>
- build as changes occur
<hurricos>
I don't know how to do the prerequisite steps for #2. My experience so far (outdated READMEs from '13, while newer U-boot releases not having partial board configurations) tell me I have to pick one or the other
<hurricos>
if it's too new, it might not work
<hurricos>
if it's too old, it's a maintenance burden
<hurricos>
there are too many combinations for me to reasonably path through to figure out building P1020 U-boot
<hurricos>
with Okli, it's easier
<hurricos>
I have a platform, I write a program. I have examples in other ASMs, I read PPC ASM and figure out how to reproduce head.S and I let C code take care of the rest
<hurricos>
but there's a huge caveat of the u-boot platform still being inconsistent and potentially problematic
<hurricos>
"it's big and I don't know where to start or how it's supposed to be done" is my problem
<hurricos>
also, I was assuming incorrectly that P1020 was being dropped because of DM_ETH
Namidairo has joined #openwrt-devel
<hurricos>
(whatever that actually is.) Looks like support was re-added.
<hurricos>
sorry, added in the first place, for said platform's ethernet on u-boot
dangole has joined #openwrt-devel
<hurricos>
it doesn't help that I don't actually know what SPL meant
<hurricos>
err,
<hurricos>
It's still not sticking in my head that SPL is the S-code / assembly portion of U-boot
<hurricos>
because I still don't know what initialism you use to refer to U-boot as a whole, nor what you call something you chain-load off of U-boot that's not your final program
GNUmoon has quit [Quit: Leaving]
GNUmoon has joined #openwrt-devel
dangole_ has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
awgh has joined #openwrt-devel
awgh_ has quit [Ping timeout: 480 seconds]
awgh_ has joined #openwrt-devel
awgh has quit [Ping timeout: 480 seconds]
<hurricos>
u-boot/doc/README.TPL
<hurricos>
is everything
<hurricos>
I need to know
<hurricos>
apparently
<hurricos>
it discusses exactly this issue
<neggles>
hurricos: yeah it's meant to be loaded by the spl
<neggles>
as for how 2 config
<neggles>
openwrt is still notionally somewhat buildroot-y underneath right
<hurricos>
Ultimately my worry was RE: gambling with mainline u-boot
<neggles>
this https://github.com/neg2led/zynq_boards is a buildroot external tree for building images for the ebang ebaz4205 and bitmain antminer S9 zynq boards
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
fda has joined #openwrt-devel
fda- has quit [Ping timeout: 480 seconds]
rmilecki has quit [Ping timeout: 480 seconds]
hurricos has quit []
Tapper has quit [Ping timeout: 480 seconds]
noltari has quit [Ping timeout: 480 seconds]
noltari has joined #openwrt-devel
noltari_ has joined #openwrt-devel
noltari has quit [Read error: Connection reset by peer]
svlobanov has joined #openwrt-devel
<svlobanov>
hi. As I understood, px5g is not able to generate self-signed ssl certificate acceptable by chrome>58 and the only way is to use openssl to generate "valid" self-signed certs. Is it correct?
<karlp>
aiui _no_ self signed cert is acceptable in chrome/ff of any generation...
<karlp>
px5g or not.
<svlobanov>
I understand that normal certs (like letsencrypt) will be OK but I need to generate self-signed
<svlobanov>
px5g generates a certificate without alt names so chrome recognises it as invalid
<dwfreed>
if px5g can't create a self-signed cert with subjectAltNames set, then yeah, you can't use it
<dwfreed>
(CAB Baseline Requirements now require, and browsers enforce, that all certs have subjectAltNames set to include at least the Subject name)
<dwfreed>
it sounds like this is what you're referring to, vs trusted/untrusted
rmilecki has joined #openwrt-devel
svlobanov has quit [Remote host closed the connection]