Re: linking to git revisions in bugzilla

[Oleksandr Tymoshenko]

Yuri Pankov (yur...@freebsd.org) wrote:
> Oleksandr Tymoshenko wrote:
> > Kubilay Kocak (ko...@freebsd.org) wrote:
> >> On 12/04/2021 9:02 am, Yuri Pankov wrote:
> >>> While filing a bug, I noticed that the help only mentions svn revision 
> >>> numbers, and "Preview" tab had no output when I tried putting "base 
> >>> ", so I'm wondering how do you link to git revisions?
> >>
> >> We'll (bugmeister) be adding parsing support for it (along with a few 
> >> other related auto-linking things)
> >>
> >> I'd encourage people to use " " (repo = src|doc|ports) 
> >> where short hash is at least 8 chars in the meantime. Once parsing is 
> >> added all previous references will be linked.
> > 
> > Links to git hashes should work now, please test and let us
> > know if feature works as expected. As Michael mentioned - preview
> > is a different matter, I'll try to look into it later.
> 
> Hi Oleksandr,
> 
> It seems to work except when the git hash starts with a digit, it then
> tries to link to subversion revision using all available digits at the
> start of the hash.  Or, at least, that's what I'm seeing in preview tab,
> not sure if it has been fixed yet?

This should be fixed now. If there is an example where it doesn't
work please post it to this PR:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255682

Thank you

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: WSLg update on 1-5-2021 - BSD / WSL

[Oleksandr Tymoshenko]

David Chisnall (thera...@freebsd.org) wrote:
> On 03/05/2021 22:37, Pete Wright via freebsd-current wrote:
> > On 5/1/21 12:42 PM, Chargen wrote:
> >> Dear all
> >>
> >> please note that I hope this message will be discussed to get this on the
> >> roadmap for FreeBSD. Perhaps there is already talk about &&  work done on
> >> that.
> >> I would like to suggest having a BSD side for Microsoft FOSS ambitions 
> >> and
> >> get to know the BSD license. I hope the tech people here, know which nuts
> >> and bolts would be ready to boot a *BSD subsystem kernel and make that
> >> available on Windows 10 installations.
> > 
> > I believe most of the effort make this happen lies with Microsoft - it 
> > is their product after all.
> > 
> > WSL under the covers is Hyper-V which supports FreeBSD pretty well. I 
> > believe most of the work would be on the Windows side to get the 
> > plumbing in place to spin up a FreeBSD VM.  There are open discussions 
> > on the WSL github system where people have asked for this but it has not 
> > gained much traction by Microsoft.
> 
> [ Disclaimer: I work for Microsoft, but not on WSL and this is my own 
> opinion ]
> 
> WSL is actually two things.  WSL1 is similar to the FreeBSD Linuxulator: 
> it is a Linux syscall ABI in the NT kernel that implements *NIX 
> abstractions that are not present in NT and forwards other things to 
> corresponding NT subsystems.  Like the Linuxulator, it lacks a bunch of 
> features (e.g. seccomp-bpf support, which is required for things like 
> Docker and Chrome) and is always playing catch-up with Linux.  I'd 
> personally love to see a FreeBSD version of this (though I'd be 90% 
> happy if ^T did the *BSD thing), but it's something that only Microsoft 
> can do and is currently quite difficult because the picoprocess 
> abstraction in the NT kernel only allows one kind of picoprocess and so 
> it would need to add a new abstraction layer to support both.
> 
> WSL2 is a lightweight Hyper-V VM that is set up to integrate tightly 
> with the host.  This includes:
> 
>   - Aggressively using the memory ballooning driver so that a VM can 
> start with a very small amount of committed memory and grow as needed.
> 
>   - Using Hyper-V sockets to forward things between the guest and the host.
> 
>   - Using 9p-over-VMBus (which, I hope, will eventually become 
> VirtIO-over-VMBus, but I don't know of any concrete plans for this) to 
> expose filesystems from the host to the fuest)
> 
>   - Starting using the LCOW infrastructure, which loads the kernel 
> directly rather than going via an emulated UEFI boot process.
> 
> FreeBSD is currently missing the balloon driver, I believe, has a 
> Hyper-V socket implementation contributed by Microsoft (Wei Hu), and has 
> a 9p-over-VirtIO implementation that could probably be tweaked fairly 
> easily to do 9p-over-VMBus.
>
> The WSL2 infrastructure is designed to make it possible to bring your 
> own kernel.  I think FreeBSD would need to support the Linux boot 
> protocol (initial memory layout, mechanism for passing kernel arguments 
> in memory) to fit into this infrastructure, but that wouldn't require 
> any changes to any closed-source components.

Hi David,

Do you have links to the documentation on how to replace the kernel
and the boot protocols? Or any documentation for WSL2 internals?

Thanks

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: linking to git revisions in bugzilla

[Oleksandr Tymoshenko]

Kubilay Kocak (ko...@freebsd.org) wrote:
> On 12/04/2021 9:02 am, Yuri Pankov wrote:
> > While filing a bug, I noticed that the help only mentions svn revision 
> > numbers, and "Preview" tab had no output when I tried putting "base 
> > ", so I'm wondering how do you link to git revisions?
> 
> We'll (bugmeister) be adding parsing support for it (along with a few 
> other related auto-linking things)
> 
> I'd encourage people to use " " (repo = src|doc|ports) 
> where short hash is at least 8 chars in the meantime. Once parsing is 
> added all previous references will be linked.

Links to git hashes should work now, please test and let us
know if feature works as expected. As Michael mentioned - preview
is a different matter, I'll try to look into it later.

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: geli broken in 13.0-BETA4 and later on armv8

[Oleksandr Tymoshenko]

Peter Jeremy via freebsd-current (freebsd-current@freebsd.org) wrote:
> [Adding arm@ and making it clearer that this is armv8-only]
> 
> On 2021-Mar-06 20:26:19 +1100, Peter Jeremy  wrote:
> >On 2021-Mar-06 19:18:37 +1100, Peter Jeremy via freebsd-stable 
> > wrote:
> >>Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4
> >>(releng/13.0-n244592-e32bc253629), geli (at least on my RockPro64 -
> >>RK3399, arm64) has changed so that a geli-encrypted partition (using
> >>AES-XTS 128) that was readable on 13.0-ALPHA2 becomes garbage on
> >>13.0-BETA4.
> >
> >I've confirmed that the problem is f76393a6305b - reverting that
> >commit fixes the problem in releng/13.0.
> >
> >I've further verified that the bug is still present in main (14.x)
> >at 028616d0dd69.

Could you test this patch and let me know if it fixes the issue?

https://people.freebsd.org/~gonzo/patches/armv8crypto-xts-fix.diff

Thanks

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ThinkPad: reboots after successful shutdown -p

[Oleksandr Tymoshenko]

Bjoern A. Zeeb (bzeeb-li...@lists.zabbadoz.net) wrote:
> On 18 Nov 2019, at 7:14, Xin Li wrote:
> 
> > Hi,
> >
> > I recently noticed that if I do a 'shutdown -p' from -CURRENT, the
> > system would shut down and seemingly powered off, then it would 
> > restart
> > after about 5-10 seconds.
> 
> Interesting. I have the opposite problem that a reboot does a shutdown 
> but never resets (also no reset from ddb>).  I’ve seen this on the 
> X270 and the T480.

I had this issue on my Thinkpad too. The "solution" was to disable
bluetooth chip in BIOS. I didn't try to find the root cause of this
behavior.

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: What is evdev and autoloading?

[Oleksandr Tymoshenko]

Michael Gmelin (gre...@freebsd.org) wrote:
> 
> 
> > On 18. Feb 2019, at 23:54, Mark Linimon  wrote:
> > 
> >> On Mon, Feb 18, 2019 at 08:50:27AM -0800, Rodney W. Grimes wrote:
> >> I think one serious problem here is the summary dismissal of things
> >> simply on the "5 year old" basis.
> > 
> > IIUC the graphics changes are being forced upon FreeBSD by external
> > projects (mainly Linux-based) that are making huge architectural changes
> > that rely more and more on features from newer hardware.
> > 
> > If our upstreams aren't willing to do the work to keep from violating
> > POLA on older hardware, IMHO it's an awful lot to ask of our already
> > thinly stretched graphics volunteers to provide it in their stead.
> > 
> > w/rt graphics, we are at far more danger of being left further and
> > further behind on modern hardware than we are at risk of losing users
> > on older hardware here.
> > 
> > Again all IMHO.
> > 
> > disclaimer: I don't use any fancy graphics stuff, so (as the old folks
> > say around here)
> 
> I’m very happy (and grateful) that 2018 was the first year in over a decade I 
> was able to run FreeBSD on a state of the art laptop with all the features 
> that are essential to me working - which included decent touchpad support 
> provided through evdev+libinput.

I want to second this. evdev + libinput was the only option out of
several that provided smooth multitouch experience for Xorg on my 2018
laptop I really appreciate all the efforts to make it work both on
kernel and ports side.

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: webcamd based touchscreen problem on Pi3

[Oleksandr Tymoshenko]

Bernd Walter (ti...@cicely7.cicely.de) wrote:
> On Thu, Mar 08, 2018 at 02:29:44PM -0800, Oleksandr Tymoshenko wrote:
> > Bernd Walter (ti...@cicely7.cicely.de) wrote:
> > > On Thu, Mar 08, 2018 at 12:38:38PM -0800, Oleksandr Tymoshenko wrote:
> > > > Bernd Walter (ti...@cicely7.cicely.de) wrote:
> > > > > On Thu, Mar 08, 2018 at 08:11:31PM +0100, Bernd Walter wrote:
> > > > > https://github.com/gonzoua/evdev-dump/tree/freebsd
> > > > > ...
> > > > > checking for unistd.h... yes
> > > > > checking linux/input.h usability... no
> > > > > checking linux/input.h presence... no
> > > > > checking for linux/input.h... no
> > > > > checking for /usr/include/linux/input.h... no
> > > > > configure: error: /usr/include/linux/input.h not found
> > > > > 4.765u 3.954s 0:08.64 100.8%31397+2201k 0+27io 0pf+0w
> > > > > Exit 1
> > > > 
> > > > I've just checked, evdev-dump should be buildable:
> > > > 
> > > > git clone g...@github.com:gonzoua/evdev-dump.git
> > > > cd evdev-dump
> > > > git checkout freebsd
> > > > sudo pkg install gawk gmake
> > > > sh bootstrap
> > > > ./configure
> > > > gmake
> > > 
> > > That's exactly how I did.
> > > Well - I've used git clone https://github.com/gonzoua/evdev-dump.git
> > > Even with a fresh clone it failed at the same file.
> > > 
> > > I have the following:
> > > /usr/include/dev/evdev/input.h
> > > /usr/local/include/linux/input.h
> > > /usr/local/include/xorg/input.h
> > 
> > Could you show output of "git branch" and
> > "grep -rl /usr/include/linux/input.h ." in cloned directory?
> 
> [55]sa# git branch
> * master
> [56]sa# grep -rl /usr/include/linux/input.h .
> ./configure.ac
> ./autom4te.cache/output.0
> ./autom4te.cache/output.1
> ./configure
> ./config.log

You need freebsd branch. master branch is unmodified
version of upstream, all my changes are on freebsd branch.

Run:

gmake clean
git checkout freebsd <- this step is important
sh bootstrap
./configure
gmake

Also you need bash installed, because original .h to .inc
conversion script uses some bash-isms.

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: webcamd based touchscreen problem on Pi3

[Oleksandr Tymoshenko]

Bernd Walter (ti...@cicely7.cicely.de) wrote:
> On Thu, Mar 08, 2018 at 12:38:38PM -0800, Oleksandr Tymoshenko wrote:
> > Bernd Walter (ti...@cicely7.cicely.de) wrote:
> > > On Thu, Mar 08, 2018 at 08:11:31PM +0100, Bernd Walter wrote:
> > > https://github.com/gonzoua/evdev-dump/tree/freebsd
> > > ...
> > > checking for unistd.h... yes
> > > checking linux/input.h usability... no
> > > checking linux/input.h presence... no
> > > checking for linux/input.h... no
> > > checking for /usr/include/linux/input.h... no
> > > configure: error: /usr/include/linux/input.h not found
> > > 4.765u 3.954s 0:08.64 100.8%31397+2201k 0+27io 0pf+0w
> > > Exit 1
> > 
> > I've just checked, evdev-dump should be buildable:
> > 
> > git clone g...@github.com:gonzoua/evdev-dump.git
> > cd evdev-dump
> > git checkout freebsd
> > sudo pkg install gawk gmake
> > sh bootstrap
> > ./configure
> > gmake
> 
> That's exactly how I did.
> Well - I've used git clone https://github.com/gonzoua/evdev-dump.git
> Even with a fresh clone it failed at the same file.
> 
> I have the following:
> /usr/include/dev/evdev/input.h
> /usr/local/include/linux/input.h
> /usr/local/include/xorg/input.h

Could you show output of "git branch" and
"grep -rl /usr/include/linux/input.h ." in cloned directory?

Thanks

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: webcamd based touchscreen problem on Pi3

[Oleksandr Tymoshenko]

Bernd Walter (ti...@cicely7.cicely.de) wrote:
> On Thu, Mar 08, 2018 at 08:11:31PM +0100, Bernd Walter wrote:
> https://github.com/gonzoua/evdev-dump/tree/freebsd
> ...
> checking for unistd.h... yes
> checking linux/input.h usability... no
> checking linux/input.h presence... no
> checking for linux/input.h... no
> checking for /usr/include/linux/input.h... no
> configure: error: /usr/include/linux/input.h not found
> 4.765u 3.954s 0:08.64 100.8%31397+2201k 0+27io 0pf+0w
> Exit 1

I've just checked, evdev-dump should be buildable:

git clone g...@github.com:gonzoua/evdev-dump.git
cd evdev-dump
git checkout freebsd
sudo pkg install gawk gmake
sh bootstrap
./configure
gmake

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: INTRNG

[Oleksandr Tymoshenko]

Jon Brawn (j...@brawn.org) wrote:
> Wotcha Gang!
> 
> In my travels through the arm64 GENERIC config file I came across the option 
> ‘INTRNG’, and wondered what it was:
> 
> INTeRrupt Next Generation?
> INTeger Random Number Generator?
> IN TRaiNinG?
> INTerrupt Random Number Generator?
> INdependent TRaiNinG?
> 
> So, please put me out of my misery, what does INTRNG stand for, and what are 
> its implications when selected vs not selected?

"INTeRrupt Next Generation". It's a framework to manage complex interrupt
routing cases. I think it's required for all recent ARM platforms,
you can't disable it for ARM64. It can be disabled for older
ARM/MIPS platforms that use old-style interrupt cascading.

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: I2C trackpad

[Oleksandr Tymoshenko]

Ian FREISLICH (ian.freisl...@capeaugusta.com) wrote:
> Hey,
> 
> I recently acquired a new laptop (Asus UX490U) which for the most part
> works with current except that:
> 
> 1. Sound output doesn't work.
> 2. The trackpad doesn't work.
> 
> I'm not bothered about sound and I haven't investigated that yet.  The
> trackpad not working is a nuisance, but I don't think that there's a
> short term fix.  I think it's connected via an I2C bus on one of two I2C
> controllers that don't have a driver attached:
> 
> none2@pci0:0:21:0:  class=0x118000 card=0x1c301043 chip=0x9d608086
> rev=0x21 hdr=0x00
>     vendor = 'Intel Corporation'
>     device = 'Sunrise Point-LP Serial IO I2C Controller'
>     class  = dasp
> none3@pci0:0:21:1:  class=0x118000 card=0x1c301043 chip=0x9d618086
> rev=0x21 hdr=0x00
>     vendor = 'Intel Corporation'
>     device = 'Sunrise Point-LP Serial IO I2C Controller'
>     class  = dasp
> 
> I've done some research and it looks like support is a long way off but
> I'm hoping someone has a work in progress I can test or hack on.

There is work in progress for I2C controller, not sure about touchpad
part: https://reviews.freebsd.org/D13654

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: SVN r327444 breaks current build

[Oleksandr Tymoshenko]

Ian Lepore (i...@freebsd.org) wrote:
> On Sun, 2017-12-31 at 15:53 -0800, Oleksandr Tymoshenko wrote:
> > Nathan Whitehorn (nwhiteh...@freebsd.org) wrote:
> > > 
> > > 
> > > 
> > > On 12/31/17 14:22, Oleksandr Tymoshenko wrote:
> > > > 
> > > > Michael Butler (i...@protected-networks.net) wrote:
> > > > > 
> > > > > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vt_font_default.o
> > > > > --- vt_termcolors.o ---
> > > > > /usr/src/sys/dev/vt/colors/vt_termcolors.c:158:55: error: too many
> > > > > arguments to function call, expected 4, have 5
> > > > >  if (vt_parse_rgb_triplet(rgb, strlen(rgb), 
> > > > > ,
> > > > > , ) == 0) {
> > > > >  
> > > > >    ^~
> > > > > /usr/src/sys/dev/vt/colors/vt_termcolors.c:77:1: note:
> > > > > 'vt_parse_rgb_triplet' declared here
> > > > > static int
> > > > > ^
> > > > > 1 error generated.
> > > > > *** [vt_termcolors.o] Error code 1
> > > > > 
> > > > >  .. second time today a commit wasn't tested before commit :-(
> > > > > 
> > > > >   imb
> > > > Should be fixed in r327449. It was a sloppy job, I was making iterative
> > > > improvements to the original patch following review feedback and used
> > > > out-of-tree testcases for actual testing. I appologize for the breakage.
> > > > 
> > > Still broken with GCC.
> > > 
> > > /usr/src/sys/dev/vt/colors/vt_termcolors.c:148: warning: function 
> > > declaration isn't a prototype [-Wstrict-prototypes]
> > > *** [vt_termcolors.o] Error code 1
> > *sigh* Should be fixed in r327454. Thanks for reporting
> > 
> > I wonder if we can get clang to be more strict about
> > declarations/prototypes/etc to match gcc's expectations. I understand
> > that it's developers' responsibility to make sure that kernel
> > is GCC-buildable but if raising red flag for some of the cases
> > when compiling with clang reduced number of these breakages
> > that it'd be an improvement.
> > 
> 
> I think we can get clang to do that with -Wstrict-prototypes, but I'm
> not sure when that option appeared in terms of clang version, and the
> clang site doesn't seem to provide documentation for anything other
> than the current in-development version.

-Wstrict-prototypes option was added in 5.0.0 and kernel build has
this flag enabled. But this check works only for declaration and
ignores definitions.

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: SVN r327444 breaks current build

[Oleksandr Tymoshenko]

Nathan Whitehorn (nwhiteh...@freebsd.org) wrote:
> 
> 
> On 12/31/17 14:22, Oleksandr Tymoshenko wrote:
> > Michael Butler (i...@protected-networks.net) wrote:
> >> Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vt_font_default.o
> >> --- vt_termcolors.o ---
> >> /usr/src/sys/dev/vt/colors/vt_termcolors.c:158:55: error: too many
> >> arguments to function call, expected 4, have 5
> >>  if (vt_parse_rgb_triplet(rgb, strlen(rgb), ,
> >> , ) == 0) {
> >>  
> >>^~
> >> /usr/src/sys/dev/vt/colors/vt_termcolors.c:77:1: note:
> >> 'vt_parse_rgb_triplet' declared here
> >> static int
> >> ^
> >> 1 error generated.
> >> *** [vt_termcolors.o] Error code 1
> >>
> >>  .. second time today a commit wasn't tested before commit :-(
> >>
> >>imb
> > Should be fixed in r327449. It was a sloppy job, I was making iterative
> > improvements to the original patch following review feedback and used
> > out-of-tree testcases for actual testing. I appologize for the breakage.
> >
> Still broken with GCC.
> 
> /usr/src/sys/dev/vt/colors/vt_termcolors.c:148: warning: function 
> declaration isn't a prototype [-Wstrict-prototypes]
> *** [vt_termcolors.o] Error code 1

*sigh* Should be fixed in r327454. Thanks for reporting

I wonder if we can get clang to be more strict about
declarations/prototypes/etc to match gcc's expectations. I understand
that it's developers' responsibility to make sure that kernel
is GCC-buildable but if raising red flag for some of the cases
when compiling with clang reduced number of these breakages
that it'd be an improvement.

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: SVN r327444 breaks current build

[Oleksandr Tymoshenko]

Michael Butler (i...@protected-networks.net) wrote:
> Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vt_font_default.o
> --- vt_termcolors.o ---
> /usr/src/sys/dev/vt/colors/vt_termcolors.c:158:55: error: too many
> arguments to function call, expected 4, have 5
> if (vt_parse_rgb_triplet(rgb, strlen(rgb), ,
> , ) == 0) {
> 
>   ^~
> /usr/src/sys/dev/vt/colors/vt_termcolors.c:77:1: note:
> 'vt_parse_rgb_triplet' declared here
> static int
> ^
> 1 error generated.
> *** [vt_termcolors.o] Error code 1
> 
>  .. second time today a commit wasn't tested before commit :-(
> 
>   imb

Should be fixed in r327449. It was a sloppy job, I was making iterative
improvements to the original patch following review feedback and used
out-of-tree testcases for actual testing. I appologize for the breakage.

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: invalid bcd xxx

[Oleksandr Tymoshenko]

Eric van Gyzen (vangy...@freebsd.org) wrote:
> On 03/04/2017 11:44, Oleksandr Tymoshenko wrote:
> > Adrian Chadd (adrian.ch...@gmail.com) wrote:
> >> We're not; we need to cope with crappy BIOS emulations and not crash :)
> >>
> >> What's Linux doing instead? Ignoring the RTC?
> >
> > I believe I saw the same problem on either my NUC or Minnowboard.
> > I just hacked around it to work on something else and didn't
> > have time to get back to the device since then. But it's not
> > just emulation BIOS. I think the right way to go is to perform sanity
> > check on RTC data and refuse to use it if it's not valid.
> 
> cem@ posted this patch:
> 
>   http://dpaste.com/1K2W05E
> 
> If someone can test it, I'll gladly commit it.  The real-time clock will 
> likely be wrong, but it won't panic with INVARIANTS.

I can not reproduce crash any more. Probably RTC battery got charged
again. I tested this patch with working RTC - there is no regression
and patch looks OK functional-wise. 

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: invalid bcd xxx

[Oleksandr Tymoshenko]

Adrian Chadd (adrian.ch...@gmail.com) wrote:
> On 2 March 2017 at 01:31, Matthias Apitz  wrote:
> > On Thursday, 2 March 2017 00:37:35 CET, Michael Gmelin 
> > wrote:
> >>
> >>
> >>
> >>> On 2 Mar 2017, at 00:35, Adrian Chadd  wrote:
> >>>
> >>> This is an emulated BIOS though, right?
> >>>
> >>> I don't know if we're going to get the RTC 'bugfixed'...
> >>>
> >>
> >>
> >> It's SeaBIOS, yes. I feel like this might end up in another
> >> quirk/workaround solution.
> >>
> >
> > I'm one of the C720 owners and  apart of Michael, I only know two users more
> > running FreeBSD. The SeaBIOS in our devices. is outdated, mine from 2013
> > IIRC. I dont know if there is an easy way to update this.
> 
> We're not; we need to cope with crappy BIOS emulations and not crash :)
> 
> What's Linux doing instead? Ignoring the RTC?

I believe I saw the same problem on either my NUC or Minnowboard.
I just hacked around it to work on something else and didn't
have time to get back to the device since then. But it's not
just emulation BIOS. I think the right way to go is to perform sanity
check on RTC data and refuse to use it if it's not valid.

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: basic evdev setup

[Oleksandr Tymoshenko]

Andriy Gapon (a...@freebsd.org) wrote:
> 
> Oleksandr,
> 
> at the moment the documentation for evdev on FreeBSD is very scarce, even if 
> we
> talk about wiki pages, informal howto-s or blog posts.
> So, I would like to ask your help for a very basic evdev test setup.
> 
> All input devices I have are standard keyboard and a mouse with some extra 
> keys.
> I would like to be able to use the keyboard and the mouse as usual when in the
> console.  And I would like to be able to use the extra mouse keys in X.
> 
> What steps should I take to achieve that?
> I already evdev + EVDEV_SUPPORT on the kernel side in addition to the regular
> keyboard and mouse drivers (atkbdc + ums).
> I have also installed xf86-input-evdev.
> 
> Do I need any additional kernel evedev configuration via sysctl?
> What should I add to xorg configuration to enable evdev for X?

* Adding Vladimir Kondratyev to Cc since he's contributed evdev patch

Hi Andriy,

evdev works in parallel with standard input system, so you don't
have to worry about console input support. 

Current evdev implementation uses following devices as a source
of input events: ukbd(4), ums(4), atkbd(4), kbdmux(4), sysmouse(4)

As you see three of them are actual hardware and two of them are
virtual aggregating devices. You can enable/disable particular
sources using kern.evdev.rcpt_mask sysctl. There are four controlling
bits to enable/disable driver as a source of events:
bit 0: is set enables sysmouse
bit 1: is set enables kbdmux
bit 2: is set enables ums
bit 3: is set enables atkbd, ukbd

By default sysmouse and kbdmux are enabled. Sysmouse requires
moused to work, so make sure that moused is running on your system.

In your Xorg config you'll need something like this:

Section "InputDevice"
  Identifier "Mouse0"
  Driver "evdev"
  Option "Device" "/dev/input/event0"
EndSection

Section "InputDevice"
  Identifier "Keyboard0"
  Driver "evdev"
  Option "Device" "/dev/input/event1"
EndSection

I didn't test Xorg thoroughly so there might be some undiscovered
bugs. My target use case was Qt in EGLFS mode. If you have any
questions or bugreports - I'll be glad to answer them

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109

[Oleksandr Tymoshenko]

Toomas Soome (tso...@me.com) wrote:
> 
> >> 
> >> From reading U-Boot sources (lib/efi_loader/efi_disk.c) it looks like
> >> names are in the form of typeN:M, where type is interface type,
> >> N is disk id and M is partition id. So 3 disks in my setup
> >> may be mmc0, mmc0:1, mmc0:2. 
> >> 
> >> -- 
> >> gonzo
> > 
> > Okay, so in case of arm or MEDIA_FILEPATH_DP we need to keep the initial 
> > disk handle till there is an disk switch, and use it as first argument for 
> > registering the disk. So the name in last node is probably the same format 
> > and we can identify the disk this way. Worth to check in any case:)
> > 
> 
> 
> Based on current knowledge, I did put together the first sketch of the fix:
> 
> https://reviews.freebsd.org/D9520
> 
> However, it needs to be tested on arm, so I do ask help there:)

Thanks Toomas, rpi3 boots with this patch applied and device
structure is correct:

OK  lsdev
disk devices:
disk0:15564801 X 512 blocks (removable)
  disk0s1: DOS/Windows
  disk0s2: FreeBSD
disk0s2a: FreeBSD UFS
net devices:
net0:

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109

[Oleksandr Tymoshenko]

Toomas Soome (tso...@me.com) wrote:
> 
> > On 9. veebr 2017, at 17:05, Karl Denninger  wrote:
> > 
> > 
> > On 2/9/2017 08:58, Toomas Soome wrote:
> >>> On 9. veebr 2017, at 16:36, Karl Denninger  
> >>>  wrote:
> >>> 
> >>> 
> >>> On 2/8/2017 16:18, Karl Denninger wrote:
>  r313441 blows up on the Pi3 in /boot/loader.efi with:
>  
>  FreeBSD/arm64 EFI loader, Revision 1.1
>  (Tue Feb  7 15:15:52 CST 2017 free...@newfs.denninger.net 
>  )
>  Failed to start image provided by UFS (14)
>  "Synchronous Abort" handler, esr 0x9604
>  ELR: 3af62cec
>  LR:  3af61d60
>  x0 : 0001 x1 : 0001
>  x2 : 3afeb000 x3 : 003f
>  x4 : 0020 x5 : 0010
>  x6 :  x7 : 39b260a4
>  x8 : 3af61d48 x9 : 000d
>  x10: 0030 x11: 
>  x12:  x13: 0002
>  x14:  x15: 
>  x16:  x17: 
>  x18: 3ab30df8 x19: 37a16008
>  x20:  x21: 
>  x22: 39b28000 x23: 39b1d49c
>  x24: 39b28850 x25: 3ab3d740
>  x26: 3af839a0 x27: 39b2e3e8
>  x28:  x29: 3ab2ef60
>  
>  Resetting CPU ...
>  
>  If you copy in a loader.efi from an earlier build (e.g. r313109) then 
>  the system boots but complains about SMP problems, fails to start any of 
>  the other CPUs (although it sees them) and panics before it reaches a 
>  login prompt with what appears to be a problem reading the SD card (I 
>  also get a couple of lor's in here too. not sure if those are "real" 
>  or false positives)
>  
>  B
> >>> This has been isolated to r31 in sys/boot/efi; reverting the EFI
> >>> loader to a previous revision stops the crash.
> >>> 
> >>> Filed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940 
> >>>  
> >>>  
> >>> 
> >>> 
> >> Does it still crash with r313442? I think it does and this is why:
> >> 
> >> From your log above, the hint is "Failed to start image provided by UFS 
> >> (14)”, so what we can guess here is that for some reason the loader.efi 
> >> main() failed to detect the boot device, and did return back to boot1.
> >> 
> >> Boot1 did print out this error message and did call panic(). So, the 
> >> question is, why it is failing to detect the root fs handle. I’ll try to 
> >> check if I can replicate the issue with x86 + ufs.
> >> 
> >> BTW: sorry for trouble:)
> >> 
> >> rgds,
> >> toomas
> >> 
> > Yes.
> > 
> > It's isolated to that particular revision, which appears to have reworked 
> > the enumeration of the available devices to boot from.  Reverting only 
> > sys/boot/efi to anything before 31 (e.g. "svn update -r 313332 ." in 
> > src/sys/boot/efi) and rebuilding results in a loader.efi that successfully 
> > loads and starts the kernel.
> > 
> 
> Well, the x86 version does not appear to have problems with finding the ufs 
> devices. So this has to be some sort of corner case related to arm:( 
> unfortunately I do not have much variants to test arm, except qemu… so some 
> help would be needed there. Since the only crash is from boot1 call to panic, 
> I am pretty sure the disk detection and setup was ok, so we should get disk 
> list if we insert something like:
> 
> for (i = 0; devsw[i] != NULL; i++) {
> if (devsw[i]->dv_print != NULL){
> if (devsw[i]->dv_print(verbose))
> break;
> }
> }
> 
> after dv_init() loop.
> 
> If thats true, then it should not take too much to find why we fail to get 
> the handle for root fs in case of arm… 


On RPi3 U-Boot EFI API provided by U-Boot and it's somewhat non-standard
comapring to x86 EFI or specialized EFI firmwares of ARM64. I did some
debugging and found that U-Boot reports driver with subtype MEDIA_FILEPATH_DP
so it's not recognized by disk handler. Quick hack below fixed boot
but it's not ideal and the device structure looks like this:

disk devices:
disk0:15564801 X 512 blocks (removable)
  disk0s1: DOS/Windows 49MB
  disk0s2: FreeBSD 1856MB
disk0s2a: FreeBSD UFS  1856MB
disk1:102375 X 512 blocks (removable)
disk2:3802112 X 512 blocks (removable)
  disk2a: FreeBSD UFS  1856MB
net devices:
net0:


disk1 and disk2 are actuallypartitions from disk0.
I can work on proper fix but not sure what should be
considered proper in this case. So some guidelines are welcome

Patch:
Index: 

Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109

[Oleksandr Tymoshenko]

Toomas Soome (tso...@me.com) wrote:
> 
> > On 9. veebr 2017, at 23:39, Oleksandr Tymoshenko <go...@bluezbox.com> wrote:
> > 
> > Toomas Soome (tso...@me.com) wrote:
> >> 
> >>> On 9. veebr 2017, at 17:05, Karl Denninger <k...@denninger.net> wrote:
> >>> 
> >>> 
> >>> On 2/9/2017 08:58, Toomas Soome wrote:
> >>>>> On 9. veebr 2017, at 16:36, Karl Denninger <k...@denninger.net> 
> >>>>> <mailto:k...@denninger.net> wrote:
> >>>>> 
> >>>>> 
> >>>>> On 2/8/2017 16:18, Karl Denninger wrote:
> >>>>>> r313441 blows up on the Pi3 in /boot/loader.efi with:
> >>>>>> 
> >>>>>> FreeBSD/arm64 EFI loader, Revision 1.1
> >>>>>> (Tue Feb  7 15:15:52 CST 2017 free...@newfs.denninger.net 
> >>>>>> <mailto:free...@newfs.denninger.net>)
> >>>>>> Failed to start image provided by UFS (14)
> >>>>>> "Synchronous Abort" handler, esr 0x9604
> >>>>>> ELR: 3af62cec
> >>>>>> LR:  3af61d60
> >>>>>> x0 : 0001 x1 : 0001
> >>>>>> x2 : 3afeb000 x3 : 003f
> >>>>>> x4 : 0020 x5 : 0010
> >>>>>> x6 :  x7 : 39b260a4
> >>>>>> x8 : 3af61d48 x9 : 000d
> >>>>>> x10: 0030 x11: 
> >>>>>> x12:  x13: 0002
> >>>>>> x14:  x15: 
> >>>>>> x16:  x17: 
> >>>>>> x18: 3ab30df8 x19: 37a16008
> >>>>>> x20:  x21: 
> >>>>>> x22: 39b28000 x23: 39b1d49c
> >>>>>> x24: 39b28850 x25: 3ab3d740
> >>>>>> x26: 3af839a0 x27: 39b2e3e8
> >>>>>> x28:  x29: 3ab2ef60
> >>>>>> 
> >>>>>> Resetting CPU ...
> >>>>>> 
> >>>>>> If you copy in a loader.efi from an earlier build (e.g. r313109) then 
> >>>>>> the system boots but complains about SMP problems, fails to start any 
> >>>>>> of the other CPUs (although it sees them) and panics before it reaches 
> >>>>>> a login prompt with what appears to be a problem reading the SD card 
> >>>>>> (I also get a couple of lor's in here too. not sure if those are 
> >>>>>> "real" or false positives)
> >>>>>> 
> >>>>>> B
> >>>>> This has been isolated to r31 in sys/boot/efi; reverting the EFI
> >>>>> loader to a previous revision stops the crash.
> >>>>> 
> >>>>> Filed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940 
> >>>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940> 
> >>>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940> 
> >>>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940>
> >>>>> 
> >>>> Does it still crash with r313442? I think it does and this is why:
> >>>> 
> >>>> From your log above, the hint is "Failed to start image provided by UFS 
> >>>> (14)”, so what we can guess here is that for some reason the loader.efi 
> >>>> main() failed to detect the boot device, and did return back to boot1.
> >>>> 
> >>>> Boot1 did print out this error message and did call panic(). So, the 
> >>>> question is, why it is failing to detect the root fs handle. I’ll try to 
> >>>> check if I can replicate the issue with x86 + ufs.
> >>>> 
> >>>> BTW: sorry for trouble:)
> >>>> 
> >>>> rgds,
> >>>> toomas
> >>>> 
> >>> Yes.
> >>> 
> >>> It's isolated to that particular revision, which appears to have reworked 
> >>> the enumeration of the available devices to boot from.  Reverting only 
> >>> sys/boot/efi to anything before 31 (e.g. "svn update -r 313332 ." in 
> >>> src/sys/boot/efi) and rebuilding results in a loader.efi that 

Re: evdev no /dev/input FreeBSD 12.0-CURRENT #0 r311461

[Oleksandr Tymoshenko]

Jesper Schmitz Mouridsen (jesper@schmitz.computer) wrote:
> Hello.
> 
> I'm new to using current and to posting here. 
> I've  a old spare T60 1951-FEG wiith Intel Graphics Media Accelerator 950 
> (info: [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0).
> Intel Core 2 Duo (Merom) T5600.
> My goal is to try out weston /wayland from xserver-mesa-next-udev [2]
> but on offical branch current
> $ kldstat
> Id Refs AddressSize Name
>  1   40 0x8020 202f8a0  kernel
>  21 0x82231000 1051b0   i915kms.ko
>  32 0x82337000 55b0 iicbb.ko
>  45 0x8233d000 7050 iicbus.ko
>  52 0x82345000 45d0 iic.ko
>  62 0x8234a000 8a8c8drm2.ko
>  71 0x823d5000 d1f0 evdev.ko
>  81 0x82621000 36f6 ums.ko
>  91 0x82625000 4fca ng_ubt.ko
> 105 0x8262a000 ce99 netgraph.ko
> 111 0x82637000 a67e ng_hci.ko
> 123 0x82642000 10e7 ng_bluetooth.ko
> 131 0x82644000 e24e ng_l2cap.ko
> 141 0x82653000 1dff9ng_btsocket.ko
> 151 0x82671000 3c28 ng_socket.ko
> (and cuse4bsd when using webcamd for input)
> It works but I have to use webcamd for mouse and keyboard input through 
> /dev/input/event* as in the "test plan" [3] e.g without evdev.
> 
> I'm on FreeBSD 12.0-CURRENT #0 r311461. My understanding is that 
> evdev.ko evdev-enables the kernel, but I've got no /dev/input without
> webcamd and cuse4bsd and webcamd -N 
> 
> TL;DR is FreeBSD 12.0-CURRENT #0 r311461 evdev enabled ?

Yes, it is. But there is a catch. There are two kinds of drivers:
evdev-native and hybrid. evdev-native driver supports only evdev
protocol and its only dependency is evdev KLD. hybrid driver
supports evdev protocol as an option along with old way of reporting
events. So for the latter evdev is compile-time option. And since
it's off in default kernel loading evdev would not help. To enable
evdev support in ums, ukbd, kbdmux, and sysmouse you will need to
rebuild kernel with following option:

options EVDEV_SUPPORT
device  evdev


-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: evdev patches

[Oleksandr Tymoshenko]

> On Aug 5, 2016, at 12:26 PM, Lundberg, Johannes 
>  wrote:
> 
> ​Hi
> 
> The evdev patched kernel found here
> https://wiki.freebsd.org/SummerOfCode2014/evdev_Touchscreens
> is over a year old and does not patch cleanly to current.
> 
> Does anyone have a set of patches for evdev that will apply on current head?
> 
> If not I will try to clean them up so they apply to current.
> 
> What needs to be patched manually is
> 
> atkbd.c
> psm.c
> kbdmux.c
> ukbd.c
> ums.c
> uep.c
> 
> Thanks!​

There is code review for initial evdev support: 
https://reviews.freebsd.org/D6998
It stalled couple of weeks ago, probably now that freeze is over work can be 
resumed. 

It's based on Valdimir Kondratiev's evdev branch: 
https://github.com/wulf7/freebsd

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Dwarf problem with gcc and gdb

[Oleksandr Tymoshenko]

> On Dec 8, 2015, at 10:42 AM, John Baldwin  wrote:
> 
> On Tuesday, December 08, 2015 12:31:11 PM David Chisnall wrote:
>> The gdb in the base system doesn’t support DWARF4.  Use gdb791 or lldb-devel 
>> from ports (I believe gdb791 is probably a better bet on ARM, currently).
> 
> gdb710 in ports does not support arm (yet).

I have half-baked solution for gdb7/arm:

https://people.freebsd.org/~gonzo/arm/gdb7-arm.diff

And cognet@ worked on cross-debugging part, not sure how far he got. 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: am335x-bone.dts not exist

[Oleksandr Tymoshenko]

 On May 23, 2015, at 7:21 PM, Andrey Fesenko f0and...@gmail.com wrote:
 
 # uname -a
 FreeBSD des.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r283306: Sat
 May 23 11:56:46 MSK 2015
 root@des.local:/usr/obj/usr/src/sys/GENERIC  amd64
 
 I'm build BEAGLEBONE with crochet.
 
 build error
 
 Mounting UFS partition 1 at /usr/obj/_.mount.freebsd
 Installing U-Boot from : /usr/local/share/u-boot/u-boot-beaglebone
 Error: beaglebone.dts:29.1-2 syntax error
 FATAL ERROR: Unable to parse input tree
 
 
 file /usr/src/sys/boot/fdt/dts/arm/beaglebone.dts contain #include
 am335x-bone.dts but this file not existence. Need use am335x-evm.dts
 or else?


am335x-bone.dts in in sys/gnu/dts/arm/, it's a file provided by vendor (TI)

I guess crochet does not have this path as include path when compiling
dts files.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: am335x-bone.dts not exist

[Oleksandr Tymoshenko]

 On May 24, 2015, at 12:12 AM, Garrett Cooper yaneurab...@gmail.com wrote:
 
 On May 24, 2015, at 0:07, Oleksandr Tymoshenko go...@bluezbox.com wrote:
 
 On May 23, 2015, at 7:21 PM, Andrey Fesenko f0and...@gmail.com wrote:
 
 # uname -a
 FreeBSD des.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r283306: Sat
 May 23 11:56:46 MSK 2015
 root@des.local:/usr/obj/usr/src/sys/GENERIC  amd64
 
 I'm build BEAGLEBONE with crochet.
 
 build error
 
 Mounting UFS partition 1 at /usr/obj/_.mount.freebsd
 Installing U-Boot from : /usr/local/share/u-boot/u-boot-beaglebone
 Error: beaglebone.dts:29.1-2 syntax error
 FATAL ERROR: Unable to parse input tree
 
 
 file /usr/src/sys/boot/fdt/dts/arm/beaglebone.dts contain #include
 am335x-bone.dts but this file not existence. Need use am335x-evm.dts
 or else?
 
 
 am335x-bone.dts in in sys/gnu/dts/arm/, it's a file provided by vendor (TI)
 
 I guess crochet does not have this path as include path when compiling
 dts files.
 
 Pardon me for being a bit daft potentially, but shouldn’t #include work for 
 all dts files (look for #include in this doc: 
 http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf
  )?
 Thanks!
 


#include in dts file is handled by cpp(1). /include/ is handled
by dtc I believe

You can take a look at how FreeBSD compiles dts files in
sys/tools/fdt/make_dtb.sh

crochet does not have cpp stage of compilation and before my TI
code/devicetree refactoring none of the dts files referenced in
crochet used #include. That's why problem never appeared. 

Fix is just a matter of fixing freebsd_install_fdt in lib/freebsd.sh.
If nobody beats me to it I'll try to fix it and submit pull request to Tim. 

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr)

[Oleksandr Tymoshenko]

On 12/12/2012 9:08 AM, Daisuke Aoyama wrote:

Hi,

I've created FreeBSD clang world for RPI based on svn 244112 + 
eabi.diff(NOT USE) + few NetBSD code.

I didn't test with -mfloat-abi=softfp but it might work.

The first version is released at my Japanese blog:
http://shell.peach.ne.jp/aoyama/archives/2357

Thank you for many comments to previous versions.
Thank you for adding RPI support to FreeBSD.
Thank you for porting latest clang to head!
It's very useful for RPI developing now.

You can get the pre-build image from my archives:

http://www.peach.ne.jp/archives/rpi/
(At this time, freebsd-pi-clang-20121213.img.gz is the latest version.)

Download and decompress it, then write it to SD. This image requires 
SD 4GB or more.
I'm using as headless server. So, you need a serial console for seeing 
the boot log.
If you need to change the value on it, please mount the second 
partition (e.g. /dev/da0s2a).
If you want the video out, please remove the line of set 
console=comconsole in /boot/loader.rc.


Note: first time, it takes about 2 minutes for generating the SSH keys.
This version includes axe(ASIX AX88x7x/760) driver because smsc is not 
stable.
Now cc is clang instead of gcc. If you want to use gcc, specify 
or edit /etc/make.conf.

The initial setup code is taken from NetBSD.

Using config is here:
http://www.peach.ne.jp/archives/rpi/config/RPI-B-test8

Source and pacth is here:
http://www.peach.ne.jp/archives/rpi/patch/


Pre-configured for:

MEM 496MB/GPU 16MB/SWAP 512MB
I/O: multi-console (primary serial)
IP address: 192.168.1.240
Default router: 192.168.1.1
DNS: 192.168.1.1
sshd: enabled

User: pi
Password: raspberry
Password(root): raspberry

kernel section limit:
TS=256MB, DS=1024MB, SS=256MB

example of /etc/make.conf:
--
WITHOUT_X11=yes

WITH_CLANG=yes
WITH_CLANG_IS_CC=yes

# Now cc = clang is default
#CC=clang
#CXX=clang++
#CPP=clang-cpp

# For clang
NO_WERROR=
WERROR=

CFLAGS=-O2 -fno-strict-aliasing -pipe -march=armv6z 
-mtune=arm1176jzf-s -mfloat-abi=soft
COPTFLAGS=-O1 -fno-strict-aliasing -pipe -march=armv6z 
-mtune=arm1176jzf-s -mfloat-abi=soft


# For gcc
#CC=gcc
#CXX=g++
#CPP=cpp
--
How to use GPT USB stick in RPI:

(if you use something, delete/destory it before doing)
# gpart delete -i NN da0
# gpart destroy -F da0

(create new partition and format)
# gpart create -s gpt da0
# gpart add -t freebsd-ufs da0
# gpart show
# newfs -U -j /dev/da0p1

(mount it)
# mount /dev/da0p1 /mnt
--
Known problems:
o SD card is not configured correctly. (power on/off need if it's failed)
o hang the system. (unknown reason)
o smsc is not stable.
o alignment/padding is not same as gcc. (temporary avoid strict 
alignment now)
o call both IDCACHE_WBINV_ALL and DCACHE_WB_RANGE at switch. (can't 
work without both)

o still depend on GNU as (gas syntax).

TODO:
o modify/replace bcm2835 drivers.
o using clang -integrated-as.
o fix alignment with clang.
o self build.
o use EABI if possible.
o create build script :-)

Enjoy clang world in Raspberry Pi!


Amazing! Thank you for working on it
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0

[Oleksandr Tymoshenko]

On 29/04/2012 12:04 PM, Adrian Chadd wrote:

.. and the output from the buildworld:


.. skipped ..


-DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99
-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized
-Wno-pointer-sign -c jemalloc_jemalloc.c -o jemalloc_jemalloc.So
jemalloc_jemalloc.c: In function 'calloc':
jemalloc_jemalloc.c:1027: internal compiler error: in
change_address_1, at emit-rtl.c:1784
Please submit a full bug report,
with preprocessed source if appropriate.
SeeURL:http://gcc.gnu.org/bugs.html  for instructions.
*** Error code 1
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error


This ICE was fixed here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
Unfortunately the fix is GPLv3-licensed, so we can't merge it
back as-is.

I tracked down the cause of the issue to
contrib/jemalloc/include/jemalloc/internal/jemalloc_internal.h line 214.
So possible workaround could be replacing this line to
#if defined(JEMALLOC_DEBUG) || defined(__mips__)

Ugly, yes, but good enough as a band-aid until we figure out what to do
with the real issue
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0

[Oleksandr Tymoshenko]

On 30/04/2012 1:52 PM, Pedro Giffuni wrote:

On 04/30/12 14:04, Oleksandr Tymoshenko wrote:

On 29/04/2012 12:04 PM, Adrian Chadd wrote:

.. and the output from the buildworld:


.. skipped ..


-DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99
-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized
-Wno-pointer-sign -c jemalloc_jemalloc.c -o jemalloc_jemalloc.So
jemalloc_jemalloc.c: In function 'calloc':
jemalloc_jemalloc.c:1027: internal compiler error: in
change_address_1, at emit-rtl.c:1784
Please submit a full bug report,
with preprocessed source if appropriate.
SeeURL:http://gcc.gnu.org/bugs.html for instructions.
*** Error code 1
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error


This ICE was fixed here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
Unfortunately the fix is GPLv3-licensed, so we can't merge it
back as-is.



Actually.. the fix was merged to the gcc 4.1 branch
so we can take it under GPLv2:

http://gcc.gnu.org/viewcvs?view=revisionrevision=128198


Thanks, Pedro! It's GPLv2 indeed. I missed it yesterday.
Will commit.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Status on X220

[Oleksandr Tymoshenko]

On 19/04/2012 8:17 PM, Kevin Oberman wrote:

 I made a quick attempt at the card reader, but had no luck finding a
 driver that would work. Still, the system has worked for me for at
 least 6 months, now.

It seems the driver you need is sdhci (alogn with mmc and mmcsd). X220 card 
reader 
support was added by glebius in r231266. I backported it to 9-STABLE and tested 
a 
little bit - looks fine so far. 
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: DTrace on FreeBSD

[Oleksandr Tymoshenko]

On 17/04/2012 12:11 PM, Adrian Chadd wrote:

On 17 April 2012 01:44, Sevan / Venture37ventur...@gmail.com  wrote:


A part (the simple one) of
the code has been reviewed. Anyone interested in getting KDTRACE_HOOKS
enabled by default is free to do an independent review and post it here.



Adam Leventhal on KDTRACE_HOOKS
https://twitter.com/ahl/statuses/192027893319221248


Let's get Adam to write up a summary and post it here. We'll then flip
the switch.


FWIW I gathered list of files opened by cc1 when building amd64 GENERIC
with KDTRACE_HOOKS disabled and enabled (idea courtesy of brooks@).
Here is the diff:
http://people.freebsd.org/~gonzo/generic-hooks.diff

Looks like no CDDL code is involved.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [head tinderbox] failure on mips/mips

[Oleksandr Tymoshenko]

On 2012-03-27, at 11:14 AM, John Baldwin j...@freebsd.org wrote:

 /obj/mips.mipsel/src/kerberos5/libexec/kimpersonate/../../lib/libvers/libvers.a
 /obj/mips.mipsel/src/tmp/usr/bin/ld: 
 /obj/mips.mipsel/src/tmp/usr/lib/libkafs5.so symbol number 13 references 
 nonexistent SHT_SYMTAB_SHNDX section
 /obj/mips.mipsel/src/tmp/usr/lib/libkafs5.so: could not read symbols: File 
 format not recognized
 *** Error code 1
 
 I got this exact error for my own 'make tinderbox' for both mipsel and mipseb 
 worlds yesterday.  Anyone have any ideas?  Is this some sort of binutils bug?
 

Yes. It's binutils bug. More details in this thread:

http://lists.freebsd.org/pipermail/freebsd-tinderbox/2012-March/009482.html

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: DTrace/MIPS port

[Oleksandr Tymoshenko]

On 01/03/2012 1:49 PM, Oleksandr Tymoshenko wrote:

Hello,

Last few weeks I've been working on DTrace port for MIPS architecture.
I believe that project reached the stage when it's ready for public
review/testing before going into the tree.

Patch and some information could be found here:
http://people.freebsd.org/~gonzo/mips/dtrace/

I'd appreciate review/testing from interested parties and if there are
no major roadblocks the plan is to commit this patch sometime next
week.


These changes are now committed into the FreeBSD HEAD branch
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

DTrace/MIPS port

[Oleksandr Tymoshenko]

Hello,

Last few weeks I've been working on DTrace port for MIPS architecture.
I believe that project reached the stage when it's ready for public
review/testing before going into the tree.

Patch and some information could be found here:
http://people.freebsd.org/~gonzo/mips/dtrace/

I'd appreciate review/testing from interested parties and if there are
no major roadblocks the plan is to commit this patch sometime next
week.

DTrace/MIPS passes substantial part of DTrace suite on my
Octeon-based board.

 TEST RESULTS 

 mode: /usr/sbin/dtrace
   passed: 853
   failed: 74
total: 927

There are some caveats/limitations though:

- fbt, pid, lockstat, profile providers are not implemented

- MIPS passes function arguments in registers and unless they're
saved on stack the value of some might be unavailable in
backtrace. So values of argN variables might be bogus sometimes.

- dtrace uses kldstat(2) to get path to kernel binary and for
embedded systems (e.g. without loader(8)) it's just kernel
So kernel binary should be in current directory so dtrace could
get CTF data from it. We need either command-line switch or env
variable to let dtrace know where to look for binary. I haven't
yet decided which way to go.

- Not really dtrace issue, but somewhat related. FreeBSD/MIPS default
kernel stacks size seems to be insufficient to load kernel
modules with dependency chain longer then three modules
(dtrace_test - dtrace_all - dtrace - cyclic - opensolaris)
Sometimes I get kernel stack exhaustion as a combination of
FS-related calls that goes down to NFS functions + WITNESS code.
No proper solution for it yet. Workaround - load module one by
one.

- Tested only on mips64be platform. mips32be, mips32le, mips64le
were not tested.

Patches:

dtrace-all.diff - is a cumulative patch that contains diff between
HEAD branch and project branch in p4. In order to make code review
easier I split it into several sub-patches based on functionality area.

dtrace-ctf.diff
Current version of ctfmerge assumes that target byte order is the
same as host one. This patch checks byte order of ELF files being
used to decide whether byte order in CTF structures' fields
should be reversed.

dtrace-toolchain.diff
- Disable SGI compatibility for generated DWARF data.
  It confuses ctfconvert.
- Set as(1) default ABI and target size the same as target platform

dtrace-sys.diff
- Kernel part of DTrace code
- More intelligent kernel stack overflow handler

dtrace-userland.diff
- Userland part of DTrace code
- Build DTrace tols as a part of toolchain build if
we're cross-compiling
- Various libraries' plugs for MIPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: add 'ldd' to cross-tools ?

[Oleksandr Tymoshenko]

On 04/01/2012 2:23 PM, Luigi Rizzo wrote:

Hi,
in doing cross-builds of picobsd, i found i need a cross-version
of ldd so i can run it on the host to detect which shared libraries
are used by binaries on the target architecture
(for amd64-i386 there is a partial workaround, but don't know
if it works in other cases)

Is there any concern in adding usr.bin/ldd to the list of cross-tools
in Makefile.inc1 ? It is a small program and should not increase
the build time in any significant way.

Otherwise, does anyone know the magic to build a cross-arch
version of a program in the FreeBSD source tree ?


AFAIK ldd can't be used as a cross-tool. It sets some env
variables for loader (e.g. ld-elf.so), calls execve
or dlopen and relies on ld.so to print all the required data.
You might get away with it on amd64/i386 host-target pair
but it's not going to work for i386/arm or i386/mips pair.


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org