From owner-freebsd-mips@freebsd.org Sat Dec 26 12:05:00 2015 Return-Path: Delivered-To: freebsd-mips@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7D08DA512A8 for ; Sat, 26 Dec 2015 12:05:00 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 436F01B0E for ; Sat, 26 Dec 2015 12:04:59 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 88936153465; Sat, 26 Dec 2015 13:04:55 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfesoa7wr9qA; Sat, 26 Dec 2015 13:04:24 +0100 (CET) Received: from [192.168.10.10] (asus [192.168.10.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 196E9153401; Sat, 26 Dec 2015 12:27:05 +0100 (CET) Subject: Re: mt7620 works! To: Stanislav Galabov , "Rodney W. Grimes" References: <201512260057.tBQ0vcVO005566@pdx.rh.CN85.chatusa.com> <10F858B5-2F48-4E23-996A-E6D9663FEB46@gmail.com> Cc: "freebsd-mips@freebsd.org" From: Willem Jan Withagen X-Enigmail-Draft-Status: N1110 Message-ID: <567E798A.3040808@digiware.nl> Date: Sat, 26 Dec 2015 12:27:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <10F858B5-2F48-4E23-996A-E6D9663FEB46@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2015 12:05:00 -0000 On 26-12-2015 06:15, Stanislav Galabov wrote: > >> On 26.12.2015 г., at 2:57, Rodney W. Grimes >> wrote: >> >> ... >>>> But if you're trying to build a kernel for the WiTi board >>>> (MT7621) you won't be able to as the MT7621 bits are still not >>>> in -head. >>>> >>>> The last commits by Adrian only support RT305x and introduce >>>> support for RT5350 (basic support) and MT7620. The MT7620 is >>>> substantially different than the MT7621, so it's not a >>>> straightforward thing to make it work (UART is different for >>>> one). >>>> >>>> I'll continue working on Mediatek/Ralink support in the new >>>> year, so hopefully things are going to get easier then. >>> >>> Sort of informative, but the page refers to 'oldlzma'. Which I >>> suspect is needed otherwise Uboot starts complaining about during >>> decompressing and aborts. >> Stanislav, I indeed started used none as compression, which appeased the loader. But getting it to boot is another issue. Just loading it by letting uboot figure it out, does nog show/boot anything. Which I now understand could be because the uart is differntly defined, and as such does not work >> Also I see in the page where some of the magic 0x80xxxxxx addresses >> come from, but where did the magic number come from for these two >> commands: >> >> tftpboot 0x80800000 DIR-620/kernel.oldlzma.uboot bootm 0x80800000 >> > 0x80800000 is u-boot's default value for the loadaddr environment > variable on some Ralink/Mediatek boards. This is the address which is > used for loading stuff via tftp for example. In any case, it could be > any valid memory address, which wouldn't cause overwriting u-boot > itself while loading a file (kernel image in this case) via tftp. > U-boot will then properly relocate the loaded file to the address > inside the image header before booting the kernel as part of > executing the bootm command. I guess the page author didn't think it > was necessary to add this information... That was the other thing I was wondering about. But I would expect that all information in the header added by mkimage would do the trick and make uboot do the "right" thing. I works for the early version for MT7621 that you build. --WjW