| 10:21 | rabeeh | http://www.marvell.com/company/news/pressDetail.do?releaseID=8317 |
| 10:21 | rabeeh | http://www.marvell.com/embedded-processors/armada-80xx/ |
| 10:21 | rabeeh | and us - https://www.solid-run.com/product/armada-8040-networking-community-board/ |
| 10:22 | rabeeh | new beast |
| 10:24 | vpeter | Always up to date :) |
| 10:27 | rabeeh | vpeter: thanks |
| 10:31 | suihkulokki | rabeeh: bloody cool :) |
| 10:33 | rabeeh | suihkulokki: oh; you are finally satisifed.. we have released 5 product families from last time we meet and this is first time that i see your satisfaction |
| 10:33 | rabeeh | :) |
| 10:34 | rabeeh | if there are inputs on where this can be used (besides ODP and friends) then please let me know |
| 10:34 | rabeeh | we are in a constant discussion with Marvell about more usage cases for this |
| 10:34 | rabeeh | ARM build machines is next ofcourse |
| 10:39 | suihkulokki | rabeeh: the specs are missing from the solid-run page thou |
| 10:43 | rabeeh | suihkulokki: good point; we will redirect back to Marvell for specs |
| 10:43 | rabeeh | Marvell are working on releasing reference manuals and datasheets |
| 10:44 | suihkulokki | this page looks better: https://www.solid-run.com/marvell-armada-family/armada-8040-community-board/ |
| 10:46 | rabeeh | yup; a bit confusing |
| 10:46 | rabeeh | i'll ping Ilya; maybe he can link both pages |
| 13:00 | agraf | rabeeh: nice :) |
| 13:01 | agraf | rabeeh: can you try and push marvell to actually support the whole thing upstream by the time the board is out? |
| 13:01 | agraf | rabeeh: that combined with edk2 should get you an out of the box plethora of distributions you can run |
| 13:03 | jnettlet | as far as I know it will have u-boot by default |
| 13:03 | agraf | that might not be the smartest move :) |
| 13:03 | agraf | unless it's a really recent u-boot, then you can boot uefi systems just as well |
| 13:04 | jnettlet | I am tired of hearing about uefi, it is worse than BIOS. It takes UEFI longer to boot up than Linux on all of my devices. |
| 13:05 | agraf | jnettlet: take a look at my uefi u-boot patches :) |
| 13:05 | agraf | jnettlet: it gets you the best of both worlds |
| 13:05 | agraf | jnettlet: compatibility while still maintaining readable code and fast booting |
| 13:06 | agraf | jnettlet: uefi isn't the problem - most edk2 implementations are just terribly slow |
| 13:06 | jnettlet | the problem I see, is the same problem as u-boot in that you are writing 2 separate sets of drivers for every device. Once for the bootloader and one for the kernel. |
| 13:09 | jnettlet | if anything I would put my time into support coreboot. At least that has a sane architecture. Then you can use Linux/PXE/UEFI/U-Boot as targets. |
| 13:09 | jnettlet | but the main bootloader is just that. a very optimized bootloader |
| 13:09 | jnettlet | not a mini OS |
| 13:10 | agraf | well, go ahead and port then :) |
| 13:10 | agraf | you'll soon realize that 90% of the code you'd write in coreboot is already in u-boot |
| 13:13 | jnettlet | yes but much less buggy. I waste too much time fixing broken u-boot features :\ still |
| 13:14 | jnettlet | it is better, but the project still has no regression testing. For something so big you would have thought someone would be testing. |
| 13:15 | agraf | that is indeed true, automated testing is done by vendors for their individual SoCs they care about |
| 13:15 | agraf | there's basically no CI and no overlooking QA |
| 13:16 | jnettlet | and those vendors don't push things back upstream because the u-boot community tends to push back against vendor code. |
| 13:16 | jnettlet | it is a viscous cycle. |
| 13:16 | jnettlet | the kernel was having the same problem but a few top developers have identified the problem and started to talk about it. |
| 13:18 | jnettlet | agraf, but I will look at your patches. Thanks for pointing them out. |
| 13:19 | agraf | jnettlet: i have seen very little reluctance to take vendor patches |
| 13:19 | agraf | jnettlet: in fact, i almost feel bad when reviewing, since most code basically goes in without anyone steering |
| 13:19 | agraf | jnettlet: so when i review i delay things more than usual :) |
| 13:20 | jnettlet | the iMX6 code took years to get merged upstream in any useable way. |
| 13:20 | jnettlet | and much of the old Armada patches fell into bit rot on the lists and still hasn't been merged. I have a local branch here that I maintain for myself. |
| 13:21 | jnettlet | basically the guy pushing the patches just gave up after a year and a half |
| 13:23 | jnettlet | this is all historic...and I know over the last year a lot has changed |
| 13:26 | bencoh | now I see imx/fsl-related stuff in mainline that haven't even been through fsl repository |
| 13:26 | Artox | I think that is on purpose |
| 13:27 | bencoh | could be, yeah |
| 13:27 | jnettlet | but that is because fsl is dead....nxp |
| 13:27 | jnettlet | they have been very thorough in dumping the Freescale name |
| 13:29 | bencoh | the original fsl repository is still used/updated though |
| 13:31 | agraf | rabeeh: how hot will it get? could you plug a gpu into the pcie slot and use it as workstation? |
| 14:00 | rabeeh | agraf: sorry was out |
| 14:00 | rabeeh | jnettlet: it will have both u-boot and edk2 and other goodies |
| 14:01 | rabeeh | for mainline support; lots of the bits are already integrated since it upgrades already used units |
| 14:02 | rabeeh | actually if you look at Marvell mainline activity it's one of the few companies out there that understand how to get kernel support for the masses instead of patching again and again |
| 14:02 | rabeeh | take for example Armada 388; once we shipped that device most of the support was already mainlined, rmk added SFP and DSA support |
| 14:03 | rabeeh | others added tiny bits; but the major work was already. today you can download latest and greatest and build it for clearfog pro board and it would work |
| 15:02 | agraf | rabeeh: right, I've just seen in too many cases where 95% were upstream but the last 5% to make the systems actually work were not :) |
| 15:02 | agraf | rabeeh: either way, if it's preloaded with edk2 which provides a device tree, users can just grab a standard efi image and run it |
| 15:03 | agraf | rabeeh: for most aarch64 systems we don't even have specific images anymore, it looks much more like x86: https://en.opensuse.org/HCL:AArch64_EFI |
| 15:36 | rabeeh | agraf: 5% are done by us :) |
| 15:36 | rabeeh | agraf: anyhow; i totally agree with the path and EFI |
| 15:37 | rabeeh | jnettlet doesn't like it a lot since he likes to hack everything |
| 15:37 | rabeeh | but in somepoint of time; i wish i can go to any ARM64 bit machine with a CD-ROM / DVD / USB or whatever; boot it up without compiling anything and start working immediately on it. |
| 15:41 | agraf | rabeeh: yup, that's what you get for most servers by now :) |
| 15:41 | agraf | rabeeh: as long as you don't try to run rhel which apparently forces acpi on everyone |
| 15:44 | jnettlet | no I just like things that boot up fast. When my bootloader takes longer to boot then the OS something wasn't designed so well |
| 15:44 | jnettlet | and this is on x86 where the system was designed |
| 15:46 | jnettlet | I loved the idea of UEFI before I had hardware that used it. |
| 16:32 | rabeeh | jnettlet: boot time isn't related to UEFI/ACPI/u-boot/fastboot |
| 16:32 | rabeeh | it's related to good vs. bad engineering |
| 16:33 | jnettlet | rabeeh, yes which makes me question the existing UEFI implementations. It is obvious why Google has steered clear of it completely |
| 16:34 | rabeeh | jnettlet: you have done <5 sec boot; you know that it's all about getting inside the code, removing unneeded things; initialize in parallel and voila you can easily get x3 faster |
| 16:35 | jnettle | 16:35 * jnettlet has done <3 sec boot to gui :P |
| 16:35 | rabeeh | :) |
| 16:35 | rabeeh | exactly; so it is all about good vs. bad engineering |
| 16:35 | rabeeh | i'm sure you can re-do the same thing on x86 / ARM if you have access to the guts |
| 16:36 | rabeeh | one of the issues with x86 machines is their binary blobs that are inaccessible; like MRC which does memory initialization, vbios for video interfaces - they are there and you can't optimize any of them |
| 16:36 | rabeeh | but if you have access then i'm sure that good engineers can optimize the hell out of it. |
| 17:16 | vpeter | my own conclusion: those big companies doesn't have good engineers? |
| 17:21 | KBme | i think it's more like the games microsoft has been playing with the industry for 20 years. gigantic unimplementable specifications. |
| 17:21 | jnettlet | well Microsoft has finally lost those games |
| 17:22 | jnettlet | and now they own LinkedIn |
| 17:23 | bencoh | :] |
| 17:23 | KBme | well, going on how their acquisitons hqve been working out that's a bad sign for linkedin |
| 17:24 | KBm | 17:24 * KBme waits for the moment microsoft acquires yahoo! |
| 17:25 | jnettlet | Yes but they have all the resumes for every engineer in Samsung, Apple, Google, and every startup around the world |
| 17:26 | jnettlet | it is a pretty big deal in that respect and nobody has really talked about it |
| 17:26 | jnettlet | in theory they have access to any logged salary negotiations that have happened over LinkedIn as well |
| 17:27 | KBme | yeah. information. it's true. |
| 17:27 | jnettlet | I am a little surprised antitrust didn't stop this. |
| 17:33 | bencoh | jnettlet: I wouldn't be that worried about the resumes. the connections/messages, on the other hand... |
| 17:55 | rabeeh | vpeter: they have brilliant engineers |
| 17:55 | rabeeh | specifically for the binary blobs; i daily suffer from it |
| 17:56 | rabeeh | for example; i would really like to cut DDR calibration time into third of it's time since I know exactly what is the DDR topology, onboard devices etc... there is no SPD EEPROM detection, multiple calibration of diffenerent ranks etc... |
| 17:57 | rabeeh | i can't do this since MRC is closed... see the point? |
| 18:12 | delete_ | Artox: Fedora 24 is released, it's time to update OBS |
| 18:43 | vpeter | rabeeh: but can't you gave them some specifications and they would make a new blob? |
| 20:22 | Artox | delete: true |
| 20:27 | Artox | the backup is done so I should be able to start fetching the new fedora |
| 20:27 | Artox | since I didnt yet upgrade to obs-2.7, I will do the old way of cloning the everything repo |
| 21:03 | Artox | delete: download started, if I am lucky it'll be done by tomorrow afternoon |
| 21:03 | delete | thanks Artox |