[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Add gnu/packages/u-boot.scm with all the boards that u-boot
Re: [PATCH] Add gnu/packages/u-boot.scm with all the boards that u-boot supports right now
Thu, 21 Jul 2016 19:56:33 +0200
> This note should go to the top of the .patch file, along with one or two
> sentences explaining what it does and why we need it.
OK, will do that.
> It seems to me that a lot of stuff is Debian-specific and not needed
> (the debian/ directory is definitely not needed.)
I agree. However, I figured it would be better for ... maintenance... if we
didn't fiddle around with other people's distributed patches.
Mainstream dtc work is kinda... stalled and so lots of people made custom
patches to make basic functionality work. For example there is no fdtget
support in the normal device-tree-compiler. Also, the documentation actually
doesn't build otherwise.
One can search for "patches/" in the patch which yields:
Should we carry those? If so, should we split them into extra files and put
them into our "patches" directory?
> This leads to packages with different names but that are otherwise
> completely identical. I suppose the configure flags must also be
> changed as a function of the board?
Yeah, something like that. That's what the part below is supposed to do:
+ #:phases (modify-phases %standard-phases
+ (zero? (system* "make" "HOSTCC=gcc" configname))
It's like in the Linux kernel. One does
$ make foobar_defconfig
in order to load the default config.
in order to compile. The result is incompatible with other boards.
> In that case, I’d suggest writing a procedure like:
> (define (make-u-boot-package board)
> (inherit u-boot)
> (name (string-append "u-boot-" (string-downcase board)))
> ;; … pass the right configure flags etc.
> Then it’s probably enough to export ‘u-boot’ and ‘make-u-boot’—having a
> zillion variables doesn’t seem very helpful. People can explicitly call
> ‘make-u-boot’ with the right board name
Yeah, sounds much nicer.
How do I test this? How can I call it?
Is it also possible to have a function which finds out which defconfig files
are in the source tarball and tells about them? Maybe have some nice error
message if someone guesses the wrong board name?
Yeah, I will send an updated patch :D
Re: GuixSD on ARM, Ludovic Courtès, 2016/07/13
Re: GuixSD on ARM, Eric Bavier, 2016/07/18