[hbelusca] (and remains on your very own pc on the corner of your dark room?)

[oiaohm] hbelusca: its the fact you have the information from the reversing actions that cause the legal trouble in some places. No redistribution required.

[hbelusca] hyoenmadan: i suppose they should be quite laxist :)

[hbelusca] oiaohm: sounds like the good old "having knowledge makes you dangerous" thingie.

[hyoenmadan] yeh, right that

[hbelusca] oiaohm: about something else, did you program some ARM stuff long time ago?

[hbelusca] (maybe for ROS?)

[oiaohm] hbelusca: not for ros I did some for embedded.

[sanchaez] ught, time to sleep too

[oiaohm] hbelusca: I helped ROS out along time ago getting the mingw build system working.

[hbelusca] out of curiosity, are you interested by any chance about porting some ROS stuff (like, freeldr)? ^^

[oiaohm] hbelusca: Mostly because I had done it 1000s of times before.

[hyoenmadan] <hbelusca>: actually... we would like to wait until alex work in UEFI gets done

[hyoenmadan] as MS has laready a framework for and Windows compatible UEFI on ARM

[hyoenmadan] *ARM64

[oiaohm] On arm you really need uboot support as well as uefi.

[oiaohm] There are a lot of arm chipsets that only fire up with uboot.

[hyoenmadan] <oiaohm>: depends... because ROS Arm64 will have about the same requirements as Win IoT

[hyoenmadan] as an ACPI enumerator working

[hyoenmadan] GIC interrupt controller and such stuff

[hyoenmadan] so we don't need hardwires, or coding different hals

[hyoenmadan] for each custom soc

[oiaohm] hyoenmadan: so only supporting qualcomm chips.

[hyoenmadan] you know, lack of manpower

[hyoenmadan] <oiaohm>: yeh... maybe Qualcomm and RPi broadcom firts

[hyoenmadan] *first

[hyoenmadan] MS has an UEFI emulator full working in the RPi3

[hbelusca] hm

[hyoenmadan] i guess in the RPi2 too

[hbelusca] maybe one "more urgent" thing would be to port the CRT to arm.

[hyoenmadan] yeh, the CRT, ofc

[oiaohm] hyoenmadan: Win IoT arm64 is use Qualcomm. Except odd exception being the cpus in the RPis.

[oiaohm] hyoenmadan: there is work to bring UEFI support to uboot.

[hbelusca] !error 0xc000002a

[hTechBot] 0xc000002a is STATUS_NOT_LOCKED.

[hyoenmadan] that would be nice... hopefully Uboot + ACPI... the most important thing here is the ACPI bits, the GIC interrupt controller and SMM capabilities in the soc

[hyoenmadan] as them are important for the WDM model

[hyoenmadan] which each drivers in ROS are written on

[hbelusca] ok, then see you in 10 years to have all these implemented in ROS LOL.

[oiaohm] hyoenmadan: one of the issues with UEFI is the extra ram and crap that ends up running in background compared to pure uboot.

[hyoenmadan] <oiaohm>: yep, we know that... but UEFI makes almost automatically mandatory the requirements listed before

[hyoenmadan] which are truly essential to ROS, and WDM model

[hyoenmadan] and not so much UEFI

[stevendale] My lappy is UEFI capable but I still boot using BIOS...

[stevendale] It's just more reliable in my experience

[hyoenmadan] in fact, Broadcom microcode for RPi2 and 3 is hacked

[hyoenmadan] to provide these services, in the goal to make it compatible with Windows IoT

[hyoenmadan] <stevendale> My lappy is UEFI capable but I still boot using BIOS... >>> but this will end soon

[hyoenmadan] intel is shutting down BIOS for good

[hyoenmadan] and all the legacy required by it

[stevendale] DX

[stevendale] dies

[hyoenmadan] as the old stytle interrupt controller

[stevendale] never buys a new computer

[hyoenmadan] and the DMA engines

[stevendale] always buys 2nd hand from now on

[hyoenmadan] as i said, Broadcom SoC microcode for production doesn't have the hacks RPis have

[hyoenmadan] so these can't run IoT

[hyoenmadan] Broadcom socs for production are used widely in automotive btw

[hyoenmadan] i guess is possible to run ROS + WDM model in socs with only GIC and SMM capabilities, with Uboot only

[hyoenmadan] but devs need create a device tree parser and engine

[hyoenmadan] no one has tried that since the old NT4 times

[hyoenmadan] when FirmWorks did that for MS

[hyoenmadan] in the goal of producing a machine could run NT, OS/2 and Solaris for PPC

[hyoenmadan] Mac too

[hyoenmadan] i wonder how much work would be adapt a device tree parser driver to the ways WDM woks

[hyoenmadan] *works

[hyoenmadan] old FirmWorks parser was OpenFirmware DT --> ARC tree

[hyoenmadan] in the end, is a bit out of the scope of the ReactOS project

[tfgbd_] So how long untilnI can run ReactOS on my Atom Baytrail tablet PCs?

[hyoenmadan] Baytrail SoCs use UEFI

[hyoenmadan] so, until UEFI loader gets ready

[oiaohm] hyoenmadan: https://www.youtube.com/watch?time_continue=2&v=bNL1pd-rwCU thing to be aware. uboot has a EFI loader. One catch some of the run-time services you can expect to work on a full EFI are dead.

[tfgbd_] VMWare is good enough for now

[oiaohm] hyoenmadan: so when doing EFI loader for reactos testing under uboot and efi would be a good idea. To know when you are using stuff that may not exist.

[hyoenmadan] yeah, testers we will check what happens

[hyoenmadan] hopefully, the gap is closer to a full working UBoot/UEFI shim with runtime services

[hyoenmadan] when the time comes

[hyoenmadan] and ReactOS UEFI loader gets ready

[hyoenmadan] *is -> will be