Bug 195525 - Carambola2 (or any ar71xx devices) don't parse uboot arguments and environment variables
Summary: Carambola2 (or any ar71xx devices) don't parse uboot arguments and environmen...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.1-RELEASE
Hardware: mips Any
: --- Affects Some People
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-30 12:28 UTC by bugs
Modified: 2014-11-30 12:28 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bugs 2014-11-30 12:28:33 UTC
I have a carambola2 which I build FreeBSD using freebsd-wifi-build.
The kernel fails to read the uboot environment, producing the following errors:

    argv is invalid
    envp is invalid

I tracked this down to sys/mips/.atheros/ar71xx_machdep.c and the following code fragment:

	/*
	 * Until some more sensible abstractions for uboot/redboot
	 * environment handling, we have to make this a compile-time
	 * hack.  The existing code handles the uboot environment
	 * very incorrectly so we should just ignore initialising
	 * the relevant pointers.
	 */
#ifndef	AR71XX_ENV_UBOOT
	argc = a0;
	argv = (char**)a1;
	envp = (char**)a2;


For the Carambola2, those registers are in fact accurate and should not be #ifdef'd out.  However, the variables are in fact an array of strings of "name=value" not pairs of strings "name", "value", so to fix this for my own case I had to extend the code that parses them later in the file.

Notwithstanding the comment regards 'more sensible abstractions', I have a patch that makes the variables work (for the carambola2, at least)

https://github.com/pastcompute/freebsd/commit/9d06660cb53ff4c07048aaab0b086e612f5f155f

However, I suspect you may wish to restrict this fix to _just_ the carambola2 board, lest it break other peoples systems.  Any advice on how to filter a fragment of code to a specific kernel configuration would be appreciated, as I am mostly experienced with hacking other systems kernels...